Layer 3 Redundancy

Specifying a default gateway leads to a single point of failure. Proxy Address Resolution Protocol (ARP) is one method for hosts to dynamically discover gateways, but it has issues in a highly-available environment. With Proxy ARP:

• Hosts ARP for all destinations, even remote.

• Router responds with its MAC.

• Problem: Slow failover because ARP entries take minutes to timeout.

Instead of making the host responsible for choosing a new gateway, Layer 3 redundancy protocols allow two or more routers to support a shared MAC address. If the primary router is lost, the backup router assumes control of traffic forwarded to that MAC. This section refers to routers, but includes those Layer 3 switches that can also implement Layer 3 redundancy.


Hot Standby Router Protocol (HSRP)

HSRP is a Cisco proprietary protocol.

With HSRP, two or more devices support a virtual router with a fictitious MAC address and unique IP address. Hosts use this IP address as their default gateway, and the MAC address for the Layer 2 header. The virtual router’s MAC address is 0000.0c07.ACxx, where xx is the HSRP group. Multiple groups (virtual routers) are allowed.

The Active router forwards traffic. The Standby is backup. The standby monitors periodic hellos (multicast to 224.0.0.2, UDP port 1985) to detect a failure of the active router. On failure, the standby device starts answering messages sent to the IP and MAC addresses of the virtual router.

The active router is chosen because it has the highest HSRP priority (default priority is 100). In case of a tie, the router with the highest configured IP address wins the election. A new router with a higher priority does not cause an election unless it is configured to preempt— that is, take over from a lower priority router. Configuring a router to preempt also insures that the highest priority router regains its active status if it goes down but then comes back online again.

Interface tracking reduces the active router’s priority if a specified circuit is down. This allows the standby router to take over even though the active router is still up.


HSRP States

HSRP devices move between these states:

• Initial—HSRP is not running.

• Learn—The router does not know the virtual IP address and is waiting to hear from the active router.

• Listen—The router knows the IP and MAC of the virtual router, but it is not the active or standby router.

• Speak—Router sends periodic HSRP hellos and participates in the election of the active router.

• Standby—Router monitors hellos from active router and assumes responsibility if active router fails.

• Active—Router forwards packets on behalf of the virtual router.

Configuring HSRP

To begin configuring HSRP, use the standby group-number ip virtual-IP-address command in interface configuration mode. Routers in the same HSRP group must belong to the same subnet/virtual LAN (VLAN.) Give this command under the interface connecting to that subnet or VLAN. For instance, use the following to configure the router as a member of HSRP group 39 with virtual router IP address 10.0.0.1:


Tune HSRP with four options: Priority, Preempt, Timers, and Interface Tracking.

Manually select the active router by configuring its priority higher than the default of 100:

Along with configuring priority, configure preempt to allow a router to take over if the active router has lower priority, as shown in the following commands. This helps lead to a predictable data path through the network. The second command shown delays preemption until the router or switch has fully booted, and the routing protocol has converged. Time how long it takes to boot and add 50 percent to get the delay value in seconds:


Speed convergence by changing the hello and hold timers. The following sets the hello interval to 2 seconds and the hold time to 7 seconds. They can be set between 1–255 seconds (the default hello is 3 seconds and hold time is 10 seconds):

Tracking an interface can trigger an election if the active router is still up, but a critical interface (such as the one to the Internet) is down. In the following, if serial 1/0/0 is down, the router’s HSRP priority is decremented by 100:

Multiple HSRP standby groups can be configured, and the same router can be active for some groups and standby for others by adjusting priorities. You can have a maximum of 255 groups. When using Layer 3 switches, configure the same switch as the primary HSRP router and the Spanning Tree root.

To view the HSRP status, use the show standby interface interface command, or show standby brief. To monitor HSRP activity, use the debug standby command.

Multilayer Switching

Multilayer Switching (MLS) is a switch feature that allows the switch to route traffic between VLANs and routed interfaces in a highly optimized and efficient manner. Cisco Express Forwarding (CEF) is an example technology used to facilitate MLS (see Figure 4-1). Cisco Express Forwarding (CEF) does the following:


Separates control plane hardware from data plane hardware.

• Controls plane runs in software and builds FIB and adjacency table.
  

• The data plane uses hardware to forward most IP unicast traffic.
  

• Handles traffic that must be forwarded in software (much slower) and includes:

—Packets originating from device.
—Packets with IP header options.
—Tunneled traffic.
—802.3 (IPX) frames.
—Load sharing traffic.
—FIB is an optimized routing table, stored in TCAM.
—Builds adjacencies from ARP data.
—Eliminates recursive loops.


ARP Throttling

ARP throttling is a tool to limit ARPs into a VLAN. ARPs, you may recall, are sent as broadcast. Once an ARP is sent for a given IP, the switch prevents repetitive ARPs for a short period of time:

• First packet to destination forwarded to Route Processor.

• Subsequent traffic dropped until MAC is resolved.

• It prevents overwhelming the Route Processor (RP) with redundant ARP requests.

• It helps during Denial of Service attacks.

• It is removed when MAC is resolved or in two seconds.

Configuring and Troubleshooting CEF

By default, CEF is on and supports per destination load sharing. To disable CEF:

• 4500—Use (config)#no ip cef.
  

• 3500/3700—On each interface, use (config)#no ip routecache cef.
  

• 6550 with policy feature card, distributed FC, and multilayer switch FC—cannot be disabled.

View CEF information with the following:

#show interface fastethernet 2/2 | begin L3


View switching statistics with the following:

#show interface fastethernet 2/2 | include switched


View FIB with the following:

#show ip cef


View detailed CEF FIB entry with the following:

#show ip cef fastethernet 2/2 10.0.0.1 detail


Troubleshoot CEF drops with the following:

#debug ip cef drops


Troubleshoot packets not forwarded by CEF with the following:

#debug ip cef receive


Troubleshoot CEF events with the following:

#debug ip cef events

Multilayer Switching

This next section walks through the switching process and focuses on order of operations. The order things happen is extremely important for two reasons. First, order of events is good test material. Second, understanding the processing order allows you to evaluate how the various filtering and forwarding mechanisms interact (examples include error checking, access-lists, VLAN access-lists, routing, and QoS).


Understanding the Switching Process

Steps involved in layer 2 forwarding are as follows:

• Input

1. Receive frame.
2. Verify frame integrity.
3. Apply inbound VLAN ACL (Virtual Local Area Network
Access List).
4. Look up destination MAC (Media Address Code).

• Output

1. Apply outbound VLAN ACL.
2. Apply outbound QoS ACL.
3. Select output port.
4. Queue on port.


Steps involved in layer 3 forwarding are as follows:

• Input

1. Receive frame.
2. Verify frame integrity.
3. Apply inbound VLAN ACL.
4. Look up destination MAC.

• Routing

1. Input ACL.
2. Switch if entry cached.
3. Identify exit interface and next-hop address using routing table.
4. Output ACL.

• Output

1. Apply outbound VLAN ACL.
2. Apply outbound QoS ACL.
3. Select output port.
4. Queue on port.
5. Rewrite source and destination MAC, IP checksum and frame check sequence, and decrement TTL (Time to Live field in the IP header).
6. Forward.


Understanding the Switching Table

Content Addressable Memory (CAM) is used for MAC tables for layer two switching.

• Used for Catalyst 4500 layer 2 forwarding tables

• Used for Catalyst 6500 layer 2 and Netflow forwarding tables

• Contains binary values (0 or 1)

• Match must be exact

In comparison, MLS uses Ternary Content Addressable Memory (TCAM).

• Used for Catalyst 3500/3700, 4500, and 6500 layer 3 switching

• Ternary (3) values (0, 1, or wildcard)

• Entries are in VMR form

—Value—Pattern to be matched.
—Mask—Masking bits associated with pattern.
—Result—Consequences of a match (permit/deny or more complex information).


Understanding Switch Forwarding Architectures

In a Centralized Forwarding model, the CPU controls forwarding decisions:

• Decision made by single table

• Used by 4500 and 6500

With Distributed Forwarding, the forwarding decisions are spread throughout the interface ASICs:

• Decision made at port or module

• Used by 3500/3700 and 6500 with distributed forwarding card

• NetFlow switching

• Decision made cooperatively by Route Processor and MLS

• First packet switched in software, result cached

• Subsequent packets switched in hardware

Cisco Express Forwarding (CEF) uses a different kind of memory to facilitate forwarding:

• Uses TCAM

• Topology-based switching (via Forwarding Information Base [FIB])

• Can be centralized or distributed

InterVLAN Routing

VLANs divide the network into smaller broadcast domains, but also prohibit communication between domains To enable communication between those groups—without also passing broadcasts—routing is used.


InterVLAN Routing Using Multilayer Switches

Port roles

• Virtual LAN (VLAN) Port—Acts as layer 2 switching port with a VLAN.

• Static VLAN—Use the switchport command to identify VLAN.

• Dynamic VLAN—Use VLAN Membership Policy Server (VMPS).

• Trunk Port—Passes multiple VLANs and differentiates by tagging.

Use the switchport command to set parameters:

• ISL(Interswitch Link) or 802.1Q

• Switched Virtual Interface (SVI)—Virtual routed port in a VLAN

—Use to route or fallback bridge between VLANs
—Default SVI for VLAN 1 automatically created
—Associate with VLAN using interface vlan#

• Routed port—Acts as layer 3 routed port

—Place in layer 3 mode with no switchport
—Not associated with VLAN
—Turn on routing using ip routing
—Assign address and enable routing protocols as needed


InterVLAN Routing

Multilayer switches do the following:

• Enable IP routing using ip routing

• Create SVI using interface vlan#

• Assign an IP address to each interface

A router on a stick attaches the router to the switch using a trunk line (ISL or 802.1Q). Following are features of these:

• Easy to implement

• Use existing equipment

• Much more latency than Multi-layer switching (MLS) solution

• Configure by creating subinterface with interface fastethernet 1/0.7

• Associate the VLAN to the interface with command encapsulation isl 7 or encapsulation dot1q 7

• ISL—No address on main interface

• 802.1Q—Address on main interface for native (untagged) VLAN

Troubleshooting STP

Some common things to look for when troubleshooting Spanning Tree Protocol include:

• Duplex mismatch—When one side of a link is half-duplex and the other is full-duplex. This causes late collisions and FCS errors.

• Unidirectional link failure—The link is up but data flows only in one direction. It can cause loops.

• Frame corruption—Physical errors on the line cause BPDUs to be lost, and the port incorrectly begins forwarding. This is caused by duplex mismatch, bad cable, or cable too long.

• Resource errors—STP is implemented in software, so a switch with an overloaded CPU or memory might neglect some STP duties.

• Port Fast configuration errors—Connecting a switch to two ports that have Port Fast enabled. This can cause a loop.

• STP tuning errors—Max age or forward delay set too short can cause a loop. A network diameter that is set too low causes BPDUs to be discarded and affects STP convergence.

Identifying a Bridging Loop

Suspect a loop if you see the following:

• You capture traffic on a link, and see the same frames multiple times.

• All users in a bridging domain have connectivity problems at the same time.

• There is abnormally high port utilization.

To remedy a loop quickly, shut redundant ports and then enable them one at a time. Some switches allow debugging of STP (not 3550/2950) to help in diagnosing problems.


What to Use Where

Confused by all the acronyms and STP features? Figure 3-3 shows the STP features you might use in your network and where you might use them.

Additional Spanning Tree Features

Some additional features available to help you tune Spanning Tree include:

• BPDU Guard

• BPDU Filtering

• Root Guard

• UDLD

• Loop Guard

BPDU Guard

BPDU Guard is used to prevent loops if another switch is attached to a Portfast port. When BPDU Guard is enabled on an interface, it is put into an error-disabled state (basically, shut down) if a BPDU is received on the interface. It can be enabled at either global config mode—in which case it affects all Portfast interfaces, or at interface mode. Portfast does not have to be enabled for it to be configured at a specific interface. The following configuration example shows BPDU guard being enabled.


BPDU Filtering

BPDU filtering is another way of preventing loops in the network. It also can be enabled either globally or at the interface, and functions differently at each. In global config, if a Portfast interface receives any BPDUs, it is taken out of Portfast status. At interface config mode, it prevents the port from sending or receiving BPDUs. The commands are:

• (config)# spanning-tree portfast bpdufilter default

• (config-if)# spanning-tree bpdufilter enable

Root Guard

Root Guard is meant to prevent the wrong switch from becoming the Spanning Tree root. It is enabled on ports other than the root port and on switches other than the root. If a Root Guard port receives a BPDU that might cause it to become a root port, then the port is put into “rootinconsistent” state and does not pass traffic through it. If the port stops receiving these BPDUs, it automatically re-enables itself.

(config-if)# spanning-tree guard root


Unidirectional Link Detection (UDLD)

A switch notices when a physical connection is broken by the absence of Layer 1 electrical keepalives (Ethernet calls this a link beat). However, sometimes a cable is intact enough to maintain keepalives, but not to pass data in both directions. This is a Unidirectional Link.
Unidirectional Link Detection (UDLD) detects a unidirectional link by sending periodic hellos out to the interface. It also uses probes, which must be acknowledged by the device on the other end of the link. UDLD operates at Layer 2. The port is shut down if a unidirectional link is found.

To enable UDLD on all fiber-optic interfaces, use the following command:
(config)# udld enable

Although this command is given at global config mode, it applies only to fiber ports.

To enable UDLD on non-fiber ports, give the same command at interface config mode.

To disable UDLD on a specific fiber port, use the following command:
(config-if)# udld disable


To disable UDLD on a specific non-fiber port, use the following command:
(config-if)#no udld enable


To re-enable all interfaces shut by UDLD, use the following:
#udld reset

To verify UDLD status, use the following:
#show udld interface


Loop Guard

Loop Guard prevents loops that might develop if a port that should be blocking inadvertently transitions to the forwarding state. This can happen if the port stops receiving BPDUs (perhaps because of a unidirectional link or a software/configuration problem in its neighbor switch). When one of the ports in a physically redundant topology stops receiving BPDUs, the STP conceives the topology as loop-free. Eventually, the blocking port becomes designated and moves to forwarding state, thus creating a loop. With Loop Guard enabled, an
additional check is made.

If no BPDUs are received on a blocked port for a specific length of time. Loop Guard puts that port into “loop inconsistent” blocking state, rather than transitioning to forwarding state. Loop Guard should be enabled on all switch ports that have a chance of becoming root or designated ports. It is most effective when enabled in the entire switched network in conjunction with UDLD.

To enable Loop Guard for all point-to-point links on the switch, use the following command:

(config)# spanning-tree loopguard default


To enable Loop Guard on a specific interface, use the following:

(config-if)# spanning-tree guard loop

Loop Guard automatically re-enables the port if it starts receiving BPDUs again.

EtherChannels

EtherChannel is a way of combining several physical links between switches into one logical connection. Normally, Spanning Tree blocks redundant links; EtherChannel gets around that and allows load balancing across those links. Load is balancing on the basis of such things as source or destination MAC address or IP address. The Etherchannel load-balancing method is configured at global configuration mode.

(config)#port-channel load-balance type

A logical interface—the Port Channel interface—is created. Configuration can be applied to both the logical and physical interfaces.

Some guidelines for EtherChannels are as follows:

• Interfaces in the channel do not have to be physically next to each other or on the same module.

• All ports must be the same speed and duplex.

• All ports in the bundle should be enabled.

• None of the bundle ports can be a SPAN port.

• Assign an IP address to the logical Port Channel interface, not the physical ones.

• Put all bundle ports in the same VLAN, or make them all trunks.

• If they are trunks, they must all carry the same VLANs and use the same trunking mode.

• Configuration you apply to the Port Channel interface affects the entire EtherChannel. Configuration you apply to a physical interface only affects that interface.

Configuring an EtherChannel

Basically, for a Layer 3 EtherChannel, you should configure the logical interface and then put the physical interfaces into the channel group:

(config)#interface port-channel number
(config-if)#no switchport
(config-if)#ip address address mask

Then, at each port that is part of the EtherChannel, use the following:

(config)#interface { number | range interface – interface}
(config-if)#channel-group number mode {auto | desirable | on}

Putting the IP address on the Port Channel interface creates a Layer 3 EtherChannel. Simply putting interfaces into a channel group creates a Layer 2 EtherChannel, and the logical interface is automatically created.

The Cisco proprietary Port Aggregation Protocol (PAgP) dynamically negotiates the formation of a channel. There are three PAgP modes:

• On—The port channels without using PAgP negotiation. The port on the other side must also be set to On.

• Auto—Responds to PAgP messages but does not initiate them. Port channels if the port on the other end is set to Desirable. This is the default mode.

• Desirable—Port actively negotiates channeling status with the interface on the other end of the link. Port channels if the other side is Auto or Desirable.

There is also a non-proprietary protocol called Link Aggregation Control Protocol (LACP), IEEE 802.3ad, which does the same thing. LACP has two modes:

• Active—Port actively negotiates channeling with the port on the other end of the link. A channel forms if the other side is Passive or Active.

• Passive—Responds to LACP messages but does not initiate them. A channel forms if the other end is set to Active.

If you want to use LACP, specify it under the interface and put the interface in either active or passive mode:

(config-if)#channel-protocol lacp


Verifying an EtherChannel

Some typical commands for verifying include:

• #show running-config interface number

• #show interfaces number etherchannel

• #show etherchannel number port-channel

• #show etherchannel summary

Spanning Tree and PVST

With PVST (Per Vlan STP), there is a different instance of STP for each VLAN. To derive the VLAN BID, the switch picks a different MAC address from its base pool for each VLAN. Each VLAN has its own root bridge, root port, and so on. You can configure these so that data flow is optimized, and traffic load is balanced among the switches. Spanning Tree is enabled by default on every VLAN.


Configuring Spanning Tree

To change the STP priority value, use the following:

Switch (config)#spanning-tree vlan vlan_no. priority value


To configure a switch as root without manually changing priority values, use the following:

Switch (config)# spanning-tree vlan vlan_no. root {primary | secondary}


To change the STP port cost for an access port, use the following:

Switch(config-if)# spanning-tree cost value


To change the STP port cost for a VLAN on a trunk port, use the following:

Switch(config-if)# spanning-tree vlan vlan_no. cost value


To display STP information for a VLAN, use the following:

Switch# show spanning-tree vlan vlan_no.


To display the STP information for an interface, use the following:

Switch # show spanning-tree interface interface_no. [detail]


To verify STP timers, use the following:

Switch #show spanning-tree bridge brief


Spanning Tree Enhancements

Cisco has some proprietary enhancements to Spanning Tree that help speed up network convergence. They include:

• PortFast

• UplinkFast

• BackboneFast

Portfast

Portfast is for access (user) ports only. It causes the port to bypass the STP listening and learning states and transition directly to forwarding. Connecting a switch to a Portfast port can cause loops to develop.

(config-if)#spanning-tree portfast


UplinkFast

UplinkFast is for speeding convergence when a direct link to an upstream switch fails. The switch identifies backup ports for the root port (these are called an uplink group). If the root port fails, then one of the ports in the uplink group is unblocked and transitions immediately to forwarding—it bypasses the listening and learning stages. It should be used in wiring closet switches with at least one blocked port. The command to enable uplinkfast is shown below. Please note that uplinkfast is enabled globally, so the command affects all ports and all VLANs.

(config)# spanning-tree uplinkfast


BackboneFast

BackboneFast is used for speeding convergence when a link fails that is not directly connected to the switch. It helps the switch detect indirect failures. If a switch running BackboneFast receives an inferior BPDU from its designated bridge, it knows a link on the path to the root has failed. (An inferior BPDU is one that lists the same switch for root
bridge and designated bridge.)

The switch then tries to find an alternate path to the root by sending a Root Link Query (RLQ) frame out all alternate ports. The root then responds with an RLQ response, and the port receiving this response can transition to forwarding. Alternate ports are determined in this way:

• If the inferior BPDU was received on a blocked port, then the root port and any other blocked ports are considered alternates.

• If the inferior BPDU was received on the root port, then all blocked ports are considered alternates.

• If the inferior BPDU was received on the root port and there are no blocked ports, the switch assumes it has lost connectivity with the root and advertises itself as root.

Configure this command on all switches in the network:

(config)#spanning-tree backbonefast


Rapid Spanning Tree (RSTP)

Rapid Spanning Tree (RSTP) 802.1w is a standards-based, non-proprietary way of speeding STP convergence. Switch ports exchange an explicit handshake when they transition to forwarding. RSTP describes different port states than regular STP, as shown in the Table 3-3.



RSTP Port Roles

RSTP also defines different Spanning Tree roles for ports:

• Root port—The best path to the root (same as STP).

• Designated port—Same role as with STP.

• Alternate port—A backup to the root port.

• Backup port—A backup to the designated port.

• Disabled port—One not used in the Spanning Tree.

• Edge port—One connected only to an end user.

BPDU Differences in RSTP

In regular STP, BPDUs are originated by the root and relayed by each switch. In RSTP, each switch originates BPDUs, whether or not it receives a BPDU on its root port. All eight bits of the BPDU type field are used by RSTP. The TC and TC Ack bits are still used. The other six bits specify the port’s role and its RSTP state, and are used in the port handshake. The RSTP BPDU is set to Type 2, Version 2. PVST is done by Rapid PVST+ on Catalyst switches.


RSTP Fast Convergence

The Rapid Spanning tree process understands and incorporates topology changes much quicker than the previous version.

• RSTP uses a mechanism similar to BackboneFast—When an inferior BPDU is received, the switch accepts it. If the switch has another path the root, it uses that and informs its downstream switch of the alternate path.

• Edge ports work the same as Portfast ports—They automatically transition directly to forwarding.

• Link type—If you connect two switches through a point-to-point link and the local port becomes a designated port, it exchanges a handshake with the other port to quickly transition to forwarding. Full-duplex links are assumed to be point-to-point, half-duplex links are assumed to be shared.
  

• Backup and alternate ports—Ports that can transition to forwarding when no BPDUs are received from a neighbor switch (similar to UplinkFast).

If an RSTP switch detects a topology change, it sets a TC timer to twice the hello time and sets the TC bit on all BPDUs sent out to its designated and root ports until the timer expires. It also clears the MAC addresses learned on these ports.

If an RSTP switch receives a TC BPDU, it clears the MAC addresses on that port and sets the TC bit on all BPDUs sent out its designated and root ports until the TC timer expires.


Multiple Spanning Tree (MST)

With Multiple Spanning Tree (MST), you can group VLANs and run one instance of Spanning Tree for a group of VLANs. This cuts down on the number of root bridges, root ports, designated ports, and BPDUs in your network. Switches in the same MST Region share the same configuration and VLAN mappings. Configure MST with these commands:


To be compatible with 802.1Q trunking, which has one common Spanning Tree (CST) for all VLANs, MST runs one instance of an Internal Spanning Tree (IST). The IST appears as one bridge to a CST area and is MST instance number 0. The original MST Spanning Trees (called M-Trees) are active only in the region—they combine at the edge of the CST area to form one.

Spanning Tree

Ethernet network design balances two separate imperatives. First, Ethernet has no capacity for detecting circular paths. If such paths exist, traffic loops around and accumulates until new traffic is shut out (this is called a broadcast storm). Second, having secondary paths is good preparation for inevitable link failure.

Spanning Tree is a protocol that prevents loop formation by detecting redundant links and disabling them until needed. Designers can therefore build redundant links and the protocol will allow one to pass traffic and keep the other in reserve. When the active link fails, the secondary link is enabled quickly.


Understanding the Spanning Tree Protocol

Switches either forward or filter Layer 2 frames. The way they make the forwarding/filtering decision can lead to loops in a network with redundant links. Spanning Tree is a protocol that detects potential loops and breaks them.

A Layer 2 switch is functionally the same thing as a transparent bridge. Transparent bridges:

• Learn MAC (Media Access Control) addresses by looking at the source address of incoming frames. They build a table mapping MAC address to port number.

• Forward broadcasts and multicasts out all ports except the on which they came. (This is called flooding.)

• Forward unknown unicasts out all ports except the one on which they came. An unknown unicast is a message bound for a unicast MAC address that is not in the switch’s table of addresses and ports.

• Do not make any changes to the frames as they forward them.

Spanning Tree Protocol (STP) works by selecting a root bridge, then selecting one loop-free path from the root bridge to every other switch. (STP uses the term bridge because it was written before there were switches.) Consider the following switched network (see Figure 3-1).


Spanning Tree must select:

• One root bridge

• One root port per nonroot bridge

• One designated port per network segment

Spanning Tree Election Criteria

Spanning Tree builds paths out from a central point along the fastest available links. It selects path according to the following criteria:

1. Lowest root bridge ID (BID)
2. Lowest path cost to the root
3. Lowest sender bridge ID
4. Lowest sender port ID (PID)

When reading the path selection criteria, remember the following:

• Bridge ID—Bridge priority: Bridge MAC address.

• Bridge priority—2-btye value, 0–65,535 (0–0xFFFF).

• Default priority is 32,768 (0x8000).

• Port ID—Port priority: port number.

• Port priority—A 6-bit value, 0–63, default is 32.

• Path cost—This is the cumulative value of the cost of each link between the bridge and the root. Cost values were updated in 2000 and you should see only new cost values, but both are given in the following table (see Table 3-1). Old and new switches work together.

The STP Election

Spanning Tree builds paths out from a starting point, the “root” of the tree. The first step in selecting paths is to identify this root device. Then, each device selects its best path back to the root, according to the criteria laid out in the previous sections (lowest root BID, lowest cost, lowest advertising BID, lowest port).


Root Bridge Election

Looking at Figure 3-1, first select the root bridge. Assume each switch uses the default priority.

• Switch A BID = 80-00-00-0c-11-11-00-11

• Switch B BID = 80-00-00-0c-26-78-10-10

• Switch C BID = 80-00-00-0c-32-1a-bc-de

• Switch D BID = 80-00-00-0c-81-81-11-22

• Switch E BID = 80-00-00-0c-26-79-22-22

Switch A has the lowest BID, so it is the root. Each nonroot switch must now select a root port.


Root Port Election

The root port is the port that leads back to the root. Continuing with Figure 3-1, once A is acknowledged as the root, the remaining bridges sort out their lowest cost path back to the A.

• Switch B—Uses the link to A with a cost of 19 (link speed of 100 Mbps).

• Switch C—The connected link has a cost of 100 (Ethernet), the link through B has a path cost of 38 (two 100 Mbps links), and so B is chosen.

• Switch D—The link through B has a path cost of 119, the path cost through C to A is 119, the path through C then B is 57, so C is chosen.

• Switch E—The lowest path cost is the same for both ports (76 through D to C to B to A). Next check sender BID—sender for both ports is D, so that it does not break the tie. Next check sender Port ID. Assuming default port priority, the PID for 0/1 is lower than the PID for 0/2, so the port on the left is the root port.

Designated Port Election

Designated ports are ports that lead away from the root. Obviously, all ports on the root bridge are designated ports (A-B and A-C in Figure 3-1).

• Segment B-D—B has the lowest path cost to root (19 vs 119), so it is designated for this segment.

• Segment C-D—C has the lowest path cost to the root (100 vs 119), so it is designated for this segment.

• Segment B-C—B has the lowest path cost to the root (19 vs 100), so it is designated for this segment.

• Both segments D-E—D has the lowest cost to the root (57 vs 76), so it is designated for both segments.

Now the looped topology has been turned into a tree with A at the root. Notice that there are no more redundant links.


Bridge Protocol Data Units (BPDUs)

Switches exchange BPDUs. There are two types of BPDUs:
Configuration and Topology Change (TCN).

Configuration BPDUs are sent every two seconds from the root toward the downstream switches. They:

• Are used during an election.

• Maintain connectivity between switches.

• Send timer information from the root.

TCN BPDUs are sent toward the root when:

• There is a link failure.

• A port starts forwarding, and there is already a designated port.

• The switch receives a TCN from a neighbor.

When a switch receives a TCN BPDU, it acknowledges that with a configuration BPDU that has the TCN Acknowledgment bit set.

When the root bridge receives a TCN, it starts sending configuration BPDUs with the TCN bit set for a period of time equal to max age plus forward delay. Switches that receive this change their MAC table aging time to the Forward Delay time, causing MAC addresses to age faster. The topology change also causes an election of the root bridge, root ports, and designated ports.


BPDU Fields

Some of the fields in the BPDU include:

• Root bridge ID—The BID of the current root.

• Sender’s root path cost—The cost to the root.

• Sender’s bridge ID—Sender’s priority concatenated to MAC.

• Sender’s port ID—The port number, transmitted as final tiebreaker.

• Hello time—Two seconds by default.

• Forward Delay—15 seconds by default.

• Max Age—20 seconds by default.

Spanning Tree Port States

When a port is first activated, it transitions through the following stages shown in Table 3-2.




Designing for Spanning Tree

To optimize data flow in the network, design and configure switches for the following STP roles:

• Primary and secondary root bridges (set priority values)

• Designated and root ports (set port priorities/path cost)

• Enable STP enhancements, such as Root Guard

802.1Q Tunnels

Tunneling is a way to send 802.1Q-tagged frames across a foreign network (such as a Service Provider’s network) and still preserve the original 802.1Q tag. The SP configures their end of the trunk link as a tunnel port and assigns a VLAN to carry your traffic within their network. The SP switch then adds a second 802.1Q tag to each frame that came in the tunnel port. Other switches in the SP network see only this second tag, and do not read the original tag. When the frame exits the SP network, the extra tag is removed, leaving the original 802.1Q tag to be read by the receiving switch in your network.


Layer 2 Protocol Tunneling (GBPT)

If a Service Provider separates sections of your network, you can use Layer 2 protocol tunneling to tunnel CDP, Spanning Tree Protocol (STP), and VLAN Trunking Protocol (VTP) frames across the SP’s cloud. This is called Generic Bridge PDU Tunneling (GBPT). Frames from the above control protocols are encapsulated as they enter the SP’s network on a tunnel port, and de-encapsulated when they exit that network.


Troubleshooting Trunking

Troubleshooting trunking links happens mostly at the physical and datalink layers. Start with the most basic assumptions and work your way “up” the OSI model. It is important to show that physical layer connectivity is present, before moving on to, for instance before trying to troubleshoot IP problems.

• Are both sides of the link in the correct trunking mode?

• Is the same trunk encapsulation on both sides?

• If 802.1Q, is the same native VLAN on both sides?

• Are the same VLANs permitted on both sides?

VLAN Trunking Protocol (VTP)

VTP is a protocol that runs over trunk links and synchronizes the VLAN databases of all switches in the VTP domain. A VTP domain is an administrative group—all switches within that group must have the same VTP domain name configured or they do not synchronize databases.
VTP works by using Configuration Revision numbers and VTP advertisements:

• All switches send out VTP advertisements every five minutes, or when there is a change to the VLAN database (when a VLAN is created, deleted, or renamed).

• VTP advertisements contain a Configuration Revision number. This number is increased by one for every VLAN change.

• When a switch receives a VTP advertisement, it compares the Configuration Revision number against the one in its VLAN database.

• If the new number is higher, the switch overwrites its database with the new VLAN information, and forwards the information to its neighbor switches.

• If the number is the same, the switch ignores the advertisement.

• If the new number is lower, the switch replies with the more up-to-date information contained in its own database.

VTP Switch Roles

A switch can be a VTP:

• Server—The default VTP role. Servers can create, delete, and rename VLANs. They originate both periodic and triggered VTP advertisements and synchronize their databases with other switches in the domain.
  

• Client—Clients cannot make VLAN changes. They originate periodic VTP advertisements and synchronize their databases with other switches in the domain.

• Transparent—It can create, delete, and rename VLANs, but its VLANs are only local. It does not originate advertisements or synchronize its database with any other switches. It forwards VTP advertisements out its trunk links, however.

VTP Pruning

By default, switches flood broadcasts, multicasts, and unknown unicasts across trunk links. Suppose a host in VLAN 10 on Switch B sends a broadcast. Hosts in VLAN 10 on Switch C need to see that broadcast, but Switch A has no ports in VLAN 10, so it doesn’t need to receive the broadcast traffic.

Enabling VTP pruning causes the switch to keep track of VLAN port assignments in its downstream switches. The switch then sends flooded traffic only on trunks toward switches that have ports assigned to the VLAN originating the traffic. It prunes flooded traffic from all other trunks. VTP pruning increases the available bandwidth by preventing unnecessary traffic on trunk links.

There are two versions of VTP: Version 1 and Version 2. To use Version 2, all switches in the domain must be capable of using it. Configure one server for Version 2, and the information is propagated through VTP.
Version 2 has the following added features:

• It supports Token Ring VLANs.

• Transparent switches pass along messages from both versions of VTP.

• Consistency checks are performed only when changes are configured through the CLI or SNMP.

Configuring VTP

VTP configuration is done at the global config mode. To configure the switch’s VTP mode:
(config)#vtp {server | client |transparent}

To configure the VTP domain name:
(config)#vtp domain name

To configure a VTP password (all switches in the domain must use the same password):
(config)#vtp password password

To configure the switch to use VTP Version 2:
(config)#vtp version 2

To enable pruning:
vtp pruning

To specify which VLANs are to be pruned:
(config-if)#switchport trunk pruning vlan {add | except | none | remove} vlan-list [,vlan[,vlan[,,,]]


Verifying and Monitoring VTP

To get basic information about the VTP configuration, use show vtp status. The example shows the default settings:

Troubleshooting VTP

The following are some common things to check when troubleshooting problems with VTP:

• Make sure you are trunking between the switches. VTP is sent only over trunk links.

• Make sure the domain name matches on both switches (name is case sensitive).

• If the switch is not updating its database, make sure it is not in transparent mode.

• If using passwords, make sure they all match. To remove a password, use no vtp password.

Adding a New Switch to a VTP Domain

Adding a new switch in client mode does not prevent it from propagating its incorrect VLAN information. A server synchronizes to a client if the client has the higher configuration revision number. You must reset the revision number back to 0 on the new switch. The easiest way to do this is to change the domain name. Then change it back to the correct one, and attach the switch to the network.

VLAN Trunking

A trunk is a link that carries traffic for more than one VLAN. Trunks multiplex traffic from multiple VLANs. Trunks connect switches and allow ports on multiple switches to be assigned to the same VLAN.

Two methods of identifying VLANs over trunk links are:

• Inter-Switch Link (ISL)—A Cisco proprietary method that encapsulates the original frame in a header, which contains VLAN information. It is protocol-independent and can identify Cisco Discovery Protocol (CDP) and bridge protocol data unit (BPDU) frames.
  

• 802.1Q—Standards-based, tags the frames (inserts a field into the original frame immediately after the source MAC address field), and supports Ethernet and Token Ring networks.

When a frame comes into a switch port, the frame is tagged internally within the switch with the VLAN number of the port. When it reaches the outgoing port, the internal tag is removed. If the exit port is a trunk port, then its VLAN is identified in either the ISL encapsulation or the 802.1Q tag. The switch on the other end of the trunk removes the ISL or 802.1Q information, checks the VLAN of the frame, and adds the internal tag. If the exit port is a user port, then the original frame is sent out unchanged, making the use of VLANs transparent to the user.

If a nontrunking port receives an ISL-encapsulated frame, the frame is dropped. If the ISL header and footer cause the MTU size to be exceeded, it might be counted as an error.

If a nontrunking port receives an 802.1Q frame, the source and destination MAC addresses are read, the tag field is ignored, and the frame is switched normally at Layer 2.


Configuring a Trunk Link

Ports can become trunk ports either by static configuration or dynamic negotiation using Dynamic Trunking Protocol (DTP). A switch port can be in one of five DTP modes:

• Access—The port is a user port in a single VLAN.
• Trunk—The port negotiates trunking with the port on the other end of the link.
• Non-negotiate—The port is a trunk and does not do DTP negotiation with the other side of the link.
• Dynamic Desirable—Actively negotiates trunking with the other side of the link. It becomes a trunk if the port on the other switch is set to trunk, dynamic desirable, or dynamic auto mode.

Configure a port for trunking at the interface configuration mode:

(config-if)#switchport mode {dynamic {auto | desirable} | trunk}

If dynamic mode is used, DTP negotiates the trunking state and encapsulation. If trunk mode is used, you must specify encapsulation:

(config-if)#switchport trunk encapsulation {isl | dot1q | negotiate}


Native VLAN with 802.1Q

If you are using 802.1Q, specify a native VLAN for the trunk link with the command:

(config-if)#switchport trunk native vlan vlan no

Frames from the native VLAN are sent over the trunk link untagged. Native VLAN is the VLAN the port would be in if it were not a trunk, and it must match on both sides of the trunk link. VLAN 1 is the default native VLAN for all ports.


VLAN Mapping

ISL trunking recognizes only VLANs numbered 1–1001, but 802.1Q can use VLANs 0–4094. If you are using both ISL and 802.1Q in your network and have VLANs numbered above 1001, you have to map the 802.1Q VLANS to ISL numbers. Some rules about mapping VLANs include:

• You can configure only eight mappings.
• Mappings are local to the switch; the same mappings must be configured on all switches in the network.
• You can map only to Ethernet ISL VLANs.
• The 802.1Q VLANs with the same number as mapped ISL VLANs are blocked. (For example, you map 802.1Q VLAN 1500 to ISL VLAN 150, then 802.1Q VLAN 150 is blocked on that switch.)
• You should not map the 802.1Q native VLAN.

VLANs Allowed on the Trunk

By default, a trunk carries traffic for all VLANs. You can change that behavior for a particular trunk link by giving the following command at the interface config mode:

switchport trunk allowed vlan vlans

Make sure that both sides of a trunk link allow the same VLANs.


Verifying a Trunk Link

Two commands you can use to verify your trunk configuration are:

#show running-config
#show interfaces [interface no.] switchport | trunk


Using the trunk keyword with the show interfaces command gives information about the trunk link:

VLAN Implementation

VLANs are used to break large campus networks into smaller pieces. The benefit of this is to minimize the amount of broadcast traffic on a logical segment.

What Is a VLAN?

A virtual LAN (VLAN) is a logical LAN, or a logical subnet. It defines a broadcast domain. A physical subnet is a group of devices that shares the same physical wire. A logical subnet is a group of switch ports assigned to the same VLAN, regardless of their physical location in a switched network.

Two types of VLANs are:

• End-to-end VLAN—VLAN members are assigned by function and can reside on different switches. They are used when hosts are assigned to VLANs based on functions or workgroups, rather than physical location. VLANs should not extend past the Building Distribution submodule. Figure 2-1 shows end-to-end VLANs.
  

• Local VLAN—Hosts are assigned to VLANs based on their location, such as a floor in a building. A router accomplishes sharing of resources between VLANs. This type is typically found in the Building Access submodule. Figure 2-2 shows an example of local VLANs.

End-To-End VlanS


Local VLANS


VLAN membership can be assigned either statically by port or dynamically by MAC address using a VLAN Membership Policy Server (VMPS).

Creating a VLAN in Global Config Mode:

VLANs must be created before they may be used. VLANs may be created in global configuration mode or in VLAN database mode. Creating VLANs in global configuration is easy—just identify the VLAN number and name it!

(config)#vlan 12
(config-vlan)#name MYVLAN


Creating a VLAN in Database Mode

Creating a VLAN in VLAN database mode is very similar to global configuration. There are no advantages to either method. Either method creates an entry in a VLAN.DAT file. Remember that copying the configuration, by itself, does not move the VLAN information! To do that you must move the VLAN.DAT file.

#vlan database
(vlan)#vlan 12 name MYVLAN

Delete a VLAN by using the same command with no in front of it. There is no need to include the name when deleting.


Assigning Ports to VLANs

When statically assigning ports to VLANs, first make it an access port, and then assign the port to a VLAN. At the interface configuration prompt:

(config-if)#switchport mode access
(config-if)#switchport access vlan 12
The commands are similar when using dynamic VLAN assignment. At interface configuration mode:

(config-if)#switchport mode access
(config-if)#switchport access vlan dynamic

If you use dynamic, you must also enter the IP address of the VMPS server at global configuration mode:

(config-if)#vmps server ip address


Verifying VLAN Configuration

To see a list of all the VLANs and the ports assigned to them, use the command show vlan. To narrow down the information displayed, you can use these keywords after the command: brief, id, vlan-number, or name vlan-name:

Other verification commands include:

show running-config interface interface no.—Use the following to verify the VLAN membership of the port:


show mac address-table interface interface no. vlan vlan no.— Use the following to view MAC addresses learned through that port for the specified VLAN:


show interfaces interface no. switchport—Use the following to see detailed information about the port configuration, such as entries in the Administrative Mode and Access Mode VLAN fields:



Troubleshooting VLAN Issues

The following are three steps in troubleshooting VLAN problems:

• Check the physical connectivity—Make sure the cable, the network adapter, and switch port are good. Check the port’s link LED.
  

• Check the switch configuration—If you see FCS errors or late collisions, suspect a duplex mismatch. Also check configured speed on both ends of the link. Increasing collisions can mean an overloaded link, such as with a broadcast storm.
  

• Check the VLAN configuration—If two hosts cannot communicate, make sure they are both in the same VLAN. If a host cannot connect to a switch, make sure the host and the switch are in the same VLAN.

IPv6 Routing

MP-BGP for IPv6

Multiprotocol BGP (RFC 2858) involves two new extensions to BGP4 that allow BGP to carry reachability information for other protocols, such as IPv6, multicast IPv4, and MPLS. The extensions allow NEXT_HOP to carry IPv6 addresses and NLRI (network layer reachability
information) to an IPv6 prefix.

Example 8-5 shows the BGP commands as they might be applied.


OSPFv3

OSPFv3 is one of the first routing protocols available for IPv6 and. Due to its open-standard heritage, it is widely supported in IPv6. OSPFv3 is the only routing protocol discussed on the BSCI test, so it is covered in more depth here.

OSPFv3, which supports IPv6, is documented in RFC 2740. Like OSPFv2, it is a link-state routing protocol that uses the Dijkstra algorithm to select paths. Routers are organized into areas, with all areas touching area 0.

OSPF speakers meet and greet their neighbors using Hellos, exchange LSAs (link-state advertisements) and DBDs (database descriptors), and run SPF against the accumulated link-state database.

OSPFv3 participants use the same packet types as OSPFv2, form neighbors in the same way, flood and age LSAs identically, and support the same NBMA topologies and rare techniques such as NSSA and ondemand circuits.

OSPFv3 differs from its predecessors principally in its new address format. OSPFv3 advertises using multicast addresses FF02::5 and FF02::6, but uses its link-local address as the source address of its advertisements. Authentication is no longer built in, but relies on the underlying capabilities of IPv6.


OSPFv3 LSAs

OSPFv3 and OSPFv2 use a similar set of LSAs, but version 3 has a few changes from OSPFv2. Types 3 and 4 have been slightly renamed, but still fulfill the same functionality as they did with OSPFv2. Type 8 is new and assists in discovering neighbors. Types 1 and 2 no longer
pass routes. Instead they pass router IDs. Prefixes are associated as leaf objects that hang off those nodes and are advertised using Type 9, which is also new.

LSAs are sourced from the link-local address of an interface and destined for a multicast address. FF02::5 is the “all OSPF routers” address and FF02::6 is the “all OSPF DRs” address.

The OSPFv3 LSA types are collected together in Table 8-1. Notice that types one through seven exactly match their OSPFv2 predecessor, while type 8 and type 9 are new to OSPFv3.


Configuration
OSPF configuration is similar to RIPng and EIGRP. The routing process is created and routing properties are assigned to it. Interfaces are then associated with the process under interface configuration mode. Assuming that ipv6 unicast-routing and interface IP addresses are already in place, the commands to implement OSPFv3 are shown in Example 8-6.


Cost may be overridden with the ipv6 ospf cost command as shown in Example 8-7.

The summary-range command is shown to demonstrate summarization.


Troubleshooting
Troubleshoot OSPFv3 just like OSPFv2. Start by looking at show ipv6 route to verify routes have been advertised. Assuming the route is in the routing table, test reachability using ping ipv6. You can also look at the ospf setup using show ipv6 ospf 1 interface, show ipv6
ospf, or show ipv6 ospf database.


Integrating IPv4 and IPv6

There are several strategies for migrating from IPv4 to IPv6. Each of these strategies should be considered when organizations decide to make the move to IPv6 because each has positive points to aiding a smooth migration. It should also be said that there does not have to be a global decision on strategy—your organization may choose to run dual-stack in the U.S., go completely to IPv6 in Japan, and use tunneling in Europe. The transition mechanisms include:

• Dual stack—Running IPv6 and IPv4 concurrently.
  

• IPv6 to IPv4 tunneling (6-to-4)—Routers that straddle the IPv4 and IPv6 worlds to encapsulate the IPv6 traffic inside IPv4 packets.
  

• Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)—This protocol is similar to 6-to-4, but it treats the IPv4 network as an NBMA network.
  

• Teredo/Shipworm—Encapsulates IPv6 packets in IPv4/UDP segments.

NAT-PT, ALG, and BIA/BIS
Instead of replacing IPv4, there are several ways to coordinate the functioning of IPv4 and v6 concurrently. NAT-protocol translation is an example of this coexistence strategy. NAT-PT maps IPv6 addresses to IPv4 addresses. If IPv6 is used on the inside of your network, a NATPT device will receive IPv6 traffic on its inside interface and replace the IPv6 header with an IPv4 header before sending it to an outside interface. Reply traffic will be able to follow the mapping backward to enable two-way communication. NAT-PT is able to interpret application traffic and understand when IP information is included in the application data. It is also possible to connect IPv4 and IPv6 routing domains using application-level gateways (ALG), proxies, or Bump-in-the-API (BIA) and Bump-in-the-Stack (BIS), which are NAT-PT implementations within a host.

IPv6 Routing

IPv6 is not enabled by default on Cisco routers. To enable IPv6 routing, the command is Router(config)#ipv6 unicast-routing.

After IPv6 is enabled, addresses are assigned to interfaces much like version 4:

Router(config-if)#ipv6 address prefix/prefix-length

To make this less abstract, a more complete example that shows an IPv6 implementation is shown in Example 8-1.


Static Routing

Static routing with IPv6 works exactly like it does with version 4. Aside from understanding the address format, there are no differences. Static routes are not currently on the BSCI test. The syntax for the IPv6 static route command is shown below, and Example 8-2 is supplied so that the command may be viewed in context as it might be applied.

Router(config)# ipv6 route ipv6-prefix/prefix-length {ipv6-address | interface-type interface-number [ipv6-address]} [administrativedistance] [administrative-multicast-distance | unicast | multicast] [tag tag]


RIPng for IPv6

RIPng is the IPv6 of RIP and is defined in RFC 2080. Like RIPv2 for IPv4, RIPng is a distance vector routing protocol that uses a hop count for its metric and has a maximum hop count of 15. RIPng also uses periodic multicast updates—every 30 seconds—to advertise routes. The multicast address is FF02::9.

RIPng is not on the BSCI exam at present, but it is presented here for completeness and to round out your appreciation for IPv6 routing and to prepare the reader for trial implementations of IPv6.

There are two important differences between the old RIP and the nextgeneration RIP. First, RIPng supports multiple concurrent processes, each identified by a process number (this is similar to OSPFv2). Second, RIPng is initialized in global configuration mode and then
enabled on specific interfaces.

Example 8-3 shows the syntax used to apply RIPng to a configuration. Notice that the syntax is very similar to traditional RIP.


Like RIP for IPv4, troubleshoot RIPng by looking at the routing table (show ipv6 route), by reviewing the routing protocols (show ipv6 protocols), and by watching routing updates propagated between routers (debug ipv6 rip).


EIGRP
EIGRP has been expanded to support IPv6, although you’ll need to verify that a specific version of IOS is capable of doing this. EIGRP for IPv6 is based on the IPv4 version. EIGRP is still an advanced distance vector routing protocol that uses a complex metric. EIGRP still has a reliable update mechanism and uses DUAL to retain fall-back paths. Like EIGRP in IPv4, it sends multicast hellos every five seconds (but the multicast address is now FF02::A). EIGRP is enabled as described in the following:

Router(config)#ipv6 router eigrp as
Router(config-rtr)#router-id ipv4-address|ipv6-address
Router(config-rtr)#interface type number
Router(config-if)#ipv6 eigrp as

Like EIGRP for IPv4, troubleshoot by looking at the routing table (show ipv6 route), by reviewing the routing protocols (show ipv6 protocols), and by monitoring neighbors (show ipv6 eigrp neighbors). Example 8-4 shows the configuration for IPv6 EIGRP. Notice that the
routing protocol must be enabled under each interface.

IPv6 Introduction

IPv6 is an extension of IP with several advanced features:

• Larger address space
• Simpler header
• Autoconfiguration
• Extension headers
• Flow labels
• Mobility
• “Baked in” security

Of these, many capabilities have been backported to IPv4. The primary adoption of IPv6 will be driven by the need for more addresses. Given the growth in Internet use and the emergence of large groups of Internet users in developing countries, this is a significant requirement.

IPv6 Routing Prefix

IPv4 addresses are 32 bits long, whereas IPv6 addresses are 128 bits. IPv6 addresses are composed of the following elements (see Figure 8-1):

• The first three bits (/3) of unicast always 001.
• The next 13 bits (/16) are Top-Level Aggregator (TLA) the upstream ISP.
• The next 24 bits (/40) are the next-level aggregator or regional ISP.
• Enterprises are assigned /48 and have 16 bits of subnetting.

IPv6 Interface ID


The host portion of the address is last 64 bits. It can be assigned manually, using DHCP v6, or using stateless autoconfiguration. An end-system uses stateless autoconfiguration by waiting for a router to advertise the local prefix. If the end system has a 64-bit MAC, it concatenates the prefix and its MAC to form an IPv6 address. If the end system has a 48-bit MAC, it flips the global/local bit and inserts 0xFFEE into the middle of the MAC. The resulting 64-bit number is called the EUI64. The prefix and EUI64 are concatenated to form the address. Figure 8-2 shows how a host uses its MAC address to create its IPv6 address.


Simplified Presentation of IPv6 Address
There are two ways to shorten the representation of an IPv6 address. Take the example address
4001:0000:0001:0002:0000:0000:0000:ABCD.

• Leading zeros may be omitted. This makes the example 4001:0:1:2:0:0:0:ABCD.
• Sequential zeros may be shown as double colons once per address. This makes the example 4001:0:1:2::ABCD.

IPv6 Header


The IPv6 header is similar to the IPv4 header. The largest changes have to do with the larger addresses, aligning fields to 64-bit boundaries and moving fragmentation to an extension header.

The fields are:

• Version—6.
• Priority—Similar to DSCP in version 4, this eight-bit field is used to describe relative priority.
• Flow—20-bit flow label allows tagging in a manner similar to MPLS.
• Length—The length of the data in the packet.
• Next Header—Indicates how the bits after the IP header should be interpreted. Could indicate TCP or UDP, or it could show an extension header.
• Hop Limit—Similar to TTL.
• Source and Destination—IPv6 addresses.

Zero or more extension headers could follow, including:

• Hop-by-hop options—Options for intermediate devices.
• Destination options—Options for the end node.
• Source routing—Specifies “way stations” that the route must include.
• Fragmentation—Used to divide packets.
• Authentication—Used to attest to source. Replaces the AH header from IPSec.
• Encryption—Replaces the IPSec ESP header.

Multicast MAC Address

Multicast MAC addresses all start with the first 25 bits 01005E. The last 23 bits are the left-most bits from the IP address. Example 7-4 shows how a MAC address of 0100.5E40.0305 maps to a multicast IP address of 227.64.3.5.


The first four bits of multicast IP addresses are always 1110, and the last 23 bits map to the MAC. That leaves five bits that are dropped. Remember that this is an issue, because every multicast MAC maps to many multicast IPs! Example 7-5 shows how a MAC address of 0100.5E40.0305 could map to several different multicast IP addresses. Notice that the first two octets can vary in the IP addresses.


Multicast IP Addresses

Multicasts use the IP address range 224.0.0.0 to 239.255.255.255. The first four bits of the first octet are always binary 1110, and the remaining 28 bits identify the multicast group. Some addresses are reserved:

• 224.0.0.1 is the all-hosts group.
• 224.0.0.2 is the all-routers group.
• The rest of the 224.0.0.0/24 range is reserved for link-local protocols.
• 224.0.1.0 to 238.255.255.255 are for use over the Internet, and they are called globally-scoped addresses.
• Source-specific multicast uses 232.0.0.0/8 addresses.
• 233.0.0.0/8 is used to assign static multicast addresses for use by an organization. The second and third octets of the address are the organization’s Autonomous System number. This is called GLOP, which is a combination of global and scope.
• 239.0.0.0/8 is for local use within an organization, and it is called a limited scope or an administratively scoped address.

Protocol Independent Multicast (PIM)

PIM is a protocol used between routers to keep track of where to forward traffic for each multicast group. It can use information gathered from any routing protocol. PIM can run in dense mode or sparse mode.

PIM Dense Mode
PIM dense mode uses source-based trees. When running in dense mode, PIM assumes that every router needs to receive multicasts. Any router that doesn’t want to receive it must send a prune message upstream to the server. PIM dense mode is most appropriate when:

• Multicast servers and receivers are near each other.
• There are just a few servers and many receivers.
• You have a high volume of multicast traffic.
• The multicast stream is fairly constant.

PIM Sparse Mode
PIM sparse mode uses shared distribution trees. It does not assume that any routers want to receive the multicast, but instead waits to hear an explicit message from them, joining the group. Then it adds branches to the tree to reach the hosts behind those routers. PIM sparse mode uses RPs to connect hosts and servers. After the connection is made, PIM switches over to a source tree. Sparse mode is used when:

• Pockets of users are widely dispersed around the network.
• Multicast traffic is intermittent.

PIM Sparse-Dense Mode
An interface can be configured in sparse-dense mode. Then, if the router knows of an RP for its group, it uses sparse mode. Otherwise, it uses dense mode. In addition, it makes the interface capable of receiving multicasts from both sparse and dense-mode groups.


Configuring Multicast Routing and PIM

Use the following command to enable multicast routing:

(config)# ip multicast-routing

PIM mode must be configured at each interface with the following command. Configuring PIM on an interface also enables Internet Group Management Protocol (IGMP) on that interface:

(config-if)# ip pim {sparse-mode | dense-mode | sparse-dense-mode}

When using sparse mode, an RP must be specified. A router knows that it is an RP when it sees its own address in the command:

(config)# ip pim rp-address ip-address


Auto-RP
Auto-RP automates the discovery of RPs in a sparse or sparse-dense PIM network. RPs advertise themselves to a router designated as an RP mapping agent. The mapping agent then decides on one RP per group and sends that information to the other routers.

To configure a router as an RP, type the following:

(config)# ip pim send-rp-announce type number scope ttl group-list access-list-number

To configure a router as a mapping agent, type the following:

(config)# ip pim send-rp-discovery scope ttl


PIM Version 2
Cisco routers with recent versions of the IOS use PIM Version 2 by default. Some differences between PIM Version 1 and PIM Version 2 include:

• PIM Version 1 is Cisco proprietary, whereas PIM Version 2 is standards-based.
• Both versions can dynamically map RPs to multicast groups. PIM Version 1 uses an auto-RP mapping agent, and PIM Version 2 uses a bootstrap router (BSR).
• PIM Version 1 uses a Time-to-Live value to bound its announcements, and PIM Version 2 uses a configured domain border.
• In PIM Version 2, sparse and dense mode are group properties, not interface properties.

To configure PIM Version 2, configure at least one router as a BSR, and selected routers as RPs. To configure a BSR, use the following:

(config)# ip pim bsr-candidate interface hash-mask-length [priority]

To configure a router as a candidate RP, use the following:

(config)# ip pim rp-candidate type number ttl group-list access-list-number