To pass the BCMSN exam and earn your CCNP, you've got to know HSRP inside and out! Part of that is knowing how the MAC address of the virtual router is derived, and another part is knowing how to change this address. We'll look at both features in this tutorial.
We've got two routers on a segment running HSRP, so first we need to find out what the MAC address of the HSRP virtual router is. The show command for HSRP is show standby, and it's the first command you should run while configuring and troubleshooting HSRP. Let's run it on both routers and compare results.
R2#show standby
Ethernet0 - Group 5
Local state is Standby, priority 100
Hellotime 3 sec, holdtime 10 sec
Next hello sent in 0.776
Virtual IP address is 172.12.23.10 configured
Active router is 172.12.23.3, priority 100 expires in 9.568
Standby router is local
1 state changes, last state change 00:00:22
R3#show standby
Ethernet0 - Group 5
Local state is Active, priority 100
Hellotime 3 sec, holdtime 10 sec
Next hello sent in 2.592
Virtual IP address is 172.12.23.10 configured
Active router is local
Standby router is 172.12.23.2 expires in 8.020
Virtual mac address is 0000.0c07.ac05
2 state changes, last state change 00:02:08
R3 is in Active state, while R2 is in Standby. The hosts are using the 172.12.123.10 address as their gateway, but R3 is actually handling the workload. R2 will take over if R3 becomes unavailable.
An IP address was statically assigned to the virtual router, but not a MAC address. However, there is a MAC address under the show standby output on R3, the active router. How did the HSRP process arrive at a MAC of 00-00-0c-07-ac-05?
Well, most of the work is already done before the configuration is even begun. The MAC address 00-00-0c-07-ac-xx is reserved for HSRP, and xx is the group number in hexadecimal. That's a good skill to have for the exam, so make sure you're comfortable with hex conversions. The group number is 5, which is expressed as 05 with a two-bit hex character. If the group number had been 17, we'd see 11 at the end of the MAC address - one unit of 16, one unit of 1.
On rare occasions, you may have to change the MAC address assigned to the virtual router. This is done with the standby mac-address command. Just make sure you're not duplicating a MAC address that's already on your network!
R2(config-if)#standby 5 mac-address 0000.1111.2222
1d12h: %STANDBY-6-STATECHANGE: Ethernet0 Group 5 state Active -> Learn
R2#show standby
Ethernet0 - Group 5
Local state is Active, priority 150, may preempt
Hellotime 4 sec, holdtime 12 sec
Next hello sent in 3.476
Virtual IP address is 172.12.23.10 configured
Active router is local
Standby router is 172.12.23.3 expires in 10.204
Virtual mac address is 0000.1111.2222 configured
4 state changes, last state change 00:00:00
1d12h: %STANDBY-6-STATECHANGE: Ethernet0 Group 5 state Listen -> Active
The MAC address will take a few seconds to change, and the HSRP routers will go into Learn state for that time period.
A real-world HSRP troubleshooting note: If you see constant state changes with your HSRP configuration, do what you should always do when troubleshooting - check the physical layer first. Best of luck on your BCMSN exam!
Showing posts with label bcmsn. Show all posts
Showing posts with label bcmsn. Show all posts
Thursday, December 25, 2008
Cisco CCNP Certification / BCMSN Exam Tutorial: Uplinkfast
You remember from your CCNA studies that when a port goes through the transition from blocking to forwarding, you're looking at a 50-second delay before that port can actually begin forwarding frames. Configuring a port with PortFast is one way to get around that, but again, you can only use it when a single host device is found off the port. What if the device connected to a port is another switch?
A switch can be connected to two other switches, giving that local switch a redundant path to the root bridge, and that's great - we always want a backup plan! However, STP will only allow one path to be available, but if the available path to the root switch goes down, there will be a 50-second delay due to the STP timers MaxAge and ForwardDelay before the currently blocked path will be available.
The delay is there to prevent switching loops, and we can't use PortFast to shorten the delay since these are switches, not host devices. What we can use is Uplinkfast.
The ports that SW3 could potentially use to reach the root switch are collectively referred to as an uplink group. The uplink group includes the ports in forwarding and blocking mode. If the forwarding port in the uplink group sees that the link has gone down, another port in the uplink group will be transitioned from blocking to forwarding immediately. Uplinkfast is pretty much PortFast for wiring closets. (Cisco recommends that Uplinkfast not be used on switches in the distribution and core layers.)
Some additional details regarding Uplinkfast:
The actual transition from blocking to forwarding mode takes about three seconds.
Uplinkfast cannot be configured on a root switch.
Uplinkfast is configured globally. You can't run Uplinkfast on some ports or on a per-VLAN basis - it's all or nothing.
The original root port will become the root port again when it detects that its link to the root switch has come back up. This does not take place immediately. The switch uses the following formula to determine how long to wait before transitioning back to the forwarding state:
( 2 x FwdDelay) + 5 seconds
Uplinkfast will take immediate action to ensure that the switch upon which it is configured cannot become the root switch. First, the switch priority will be set to 49,152, which means that if all other switches are still at their default priority, they'd all have to go down before this switch can possibly become the root switch. Additionally, the STP Port Cost will be increased by 3000, making it highly unlikely that this switch will be used to reach the root switch by any downstream switches.
And you just know there's got to be at least one option with this command, right? Let's run IOS Help and see.
SW2(config)#spanning-tree uplinkfast ?
max-update-rate Rate at which station address updates are sent
When there is a direct link failure, dummy multicast frames are sent to the MAC destination 0100.0ccd.cdcd. The max-update-rate value determines how many of these frames will be sent in a 100-millisecond time period.
Mastering the details of UplinkFast, BackboneFast, BPDU Guard, and Loop Guard are vital to your success on the CCNP exams, and one or more of these features are in use on almost every network in the world. Learn these features for success in both the exam room and the real world!
A switch can be connected to two other switches, giving that local switch a redundant path to the root bridge, and that's great - we always want a backup plan! However, STP will only allow one path to be available, but if the available path to the root switch goes down, there will be a 50-second delay due to the STP timers MaxAge and ForwardDelay before the currently blocked path will be available.
The delay is there to prevent switching loops, and we can't use PortFast to shorten the delay since these are switches, not host devices. What we can use is Uplinkfast.
The ports that SW3 could potentially use to reach the root switch are collectively referred to as an uplink group. The uplink group includes the ports in forwarding and blocking mode. If the forwarding port in the uplink group sees that the link has gone down, another port in the uplink group will be transitioned from blocking to forwarding immediately. Uplinkfast is pretty much PortFast for wiring closets. (Cisco recommends that Uplinkfast not be used on switches in the distribution and core layers.)
Some additional details regarding Uplinkfast:
The actual transition from blocking to forwarding mode takes about three seconds.
Uplinkfast cannot be configured on a root switch.
Uplinkfast is configured globally. You can't run Uplinkfast on some ports or on a per-VLAN basis - it's all or nothing.
The original root port will become the root port again when it detects that its link to the root switch has come back up. This does not take place immediately. The switch uses the following formula to determine how long to wait before transitioning back to the forwarding state:
( 2 x FwdDelay) + 5 seconds
Uplinkfast will take immediate action to ensure that the switch upon which it is configured cannot become the root switch. First, the switch priority will be set to 49,152, which means that if all other switches are still at their default priority, they'd all have to go down before this switch can possibly become the root switch. Additionally, the STP Port Cost will be increased by 3000, making it highly unlikely that this switch will be used to reach the root switch by any downstream switches.
And you just know there's got to be at least one option with this command, right? Let's run IOS Help and see.
SW2(config)#spanning-tree uplinkfast ?
max-update-rate Rate at which station address updates are sent
When there is a direct link failure, dummy multicast frames are sent to the MAC destination 0100.0ccd.cdcd. The max-update-rate value determines how many of these frames will be sent in a 100-millisecond time period.
Mastering the details of UplinkFast, BackboneFast, BPDU Guard, and Loop Guard are vital to your success on the CCNP exams, and one or more of these features are in use on almost every network in the world. Learn these features for success in both the exam room and the real world!
Cisco CCNP / BSCI Exam Tutorial: ISIS Router Types
To pass the BSCI exam and earn your CCNP, you've got to know ISIS inside and out. There are many similarities between ISIS and OSPF, but one major difference is that ISIS has three different types of routers - Level 1 (L1), Level 2 (L2), and L1/L2.
L1 routers are contained in a single area, and are connected to other areas by an L1/L2 router. The L1 uses the L1/L2 router as a default gateway to reach destinations contained in other areas, much like an OSPF stub router uses the ABR as a default gateway.
L1 routers have no specific routing table entries regarding any destination outside their own area; they will use an L1/L2 router as a default gateway to reach any external networks. ISIS L1 routers in the same area must synchronize their databases with each other.
Just as we have L1 routers, we also have L2 routers. Anytime we're routing between areas (inter-area routing), an L2 or L1/L2 router must be involved. All L2 routers will have synchronized databases as well.
Both L1 and L2 routers send out their own hellos. As with OSPF, hello packets allow ISIS routers to form adjacencies. The key difference here is that L1 routers send out L1 hellos, and L2 routers send out L2 hellos. If you have an L1 router and an L2 router on the same link, they will not form an adjacency.
An ISIS router can act as an L1 and an L2 router at the same time; these routers are L1/L2 routers. An L1/L2 router can have neighbors in separate ISIS areas. The L1/L2 router will have two separate databases, though - one for L1 routes and another for L2 routes. L1/L2 is the default setting for Cisco routers running ISIS. The L1/L2 router is the router that makes it possible for an L1 router to send data to another area.
In the next part of my ISIS tutorial, we'll take a more detailed look at those ISIS hellos!
L1 routers are contained in a single area, and are connected to other areas by an L1/L2 router. The L1 uses the L1/L2 router as a default gateway to reach destinations contained in other areas, much like an OSPF stub router uses the ABR as a default gateway.
L1 routers have no specific routing table entries regarding any destination outside their own area; they will use an L1/L2 router as a default gateway to reach any external networks. ISIS L1 routers in the same area must synchronize their databases with each other.
Just as we have L1 routers, we also have L2 routers. Anytime we're routing between areas (inter-area routing), an L2 or L1/L2 router must be involved. All L2 routers will have synchronized databases as well.
Both L1 and L2 routers send out their own hellos. As with OSPF, hello packets allow ISIS routers to form adjacencies. The key difference here is that L1 routers send out L1 hellos, and L2 routers send out L2 hellos. If you have an L1 router and an L2 router on the same link, they will not form an adjacency.
An ISIS router can act as an L1 and an L2 router at the same time; these routers are L1/L2 routers. An L1/L2 router can have neighbors in separate ISIS areas. The L1/L2 router will have two separate databases, though - one for L1 routes and another for L2 routes. L1/L2 is the default setting for Cisco routers running ISIS. The L1/L2 router is the router that makes it possible for an L1 router to send data to another area.
In the next part of my ISIS tutorial, we'll take a more detailed look at those ISIS hellos!
Cisco CCNP / BCMSN Exam Tutorial: Static VLANs
BCMSN exam success and earning your CCNP certification requires you to add to your knowledge of VLAN configuration. When you studied for your CCNA exam, you learned how to place ports into a VLAN and what the purpose of VLANs was, but you may not be aware that there are two types of VLAN membership. To pass the BCMSN exam, you must know the details of both types.
In this tutorial, we'll take a look at the VLAN type you are most familiar with, the "static VLAN". As you know, VLANs are a great way to create smaller broadcast domains in your network. Host devices connected to a port belonging to one VLAN will receive broadcasts and multicasts only if they were originated by another host in that same VLAN. The drawback is that without the help of a Layer 3 switch or a router, inter-VLAN communication cannot occur.
The actual configuration of a static VLAN is simple enough. In this example, by placing switch ports 0/1 and 0/2 into VLAN 12, the only broadcasts and multicasts hosts connected to those ports will receive are the ones transmitted by ports in VLAN 12.
SW1(config)#int fast 0/1
SW1(config-if)#switchport mode access
SW1(config-if)#switchport access vlan 12
% Access VLAN does not exist. Creating vlan 12
SW1(config-if)#int fast 0/2
SW1(config-if)#switchport mode access
SW1(config-if)#switchport access vlan 12
One of the many things I love about Cisco switches and routers is that if you have forgotten to do something, the Cisco device is generally going to remind you or in this case actually do it for you. I placed port 0/1 into a VLAN that did not yet exist, so the switch created it for me!
There are two commands needed to place a port into a VLAN. By default, these ports are running in dynamic desirable trunking mode, meaning that the port is actively attempting to form a trunk with a remote switch in order to send traffic between the two switches. The problem is that a trunk port belongs to all VLANs by default, and we want to put this port into a single VLAN only. To do so, we run the switchport mode access command to make the port an access port, and access ports belong to one and only one VLAN. After doing that, we placed the port into VLAN 12 with the switchport access vlan 12 command. Running the switchport mode access command effectively turns trunking off on that port.
The hosts are unaware of VLANs; they simply assume the VLAN membership of the port they're connected to. But that's not quite the case with dynamic VLANs, which we'll examine in the next part of this BCMSN tutorial.
In this tutorial, we'll take a look at the VLAN type you are most familiar with, the "static VLAN". As you know, VLANs are a great way to create smaller broadcast domains in your network. Host devices connected to a port belonging to one VLAN will receive broadcasts and multicasts only if they were originated by another host in that same VLAN. The drawback is that without the help of a Layer 3 switch or a router, inter-VLAN communication cannot occur.
The actual configuration of a static VLAN is simple enough. In this example, by placing switch ports 0/1 and 0/2 into VLAN 12, the only broadcasts and multicasts hosts connected to those ports will receive are the ones transmitted by ports in VLAN 12.
SW1(config)#int fast 0/1
SW1(config-if)#switchport mode access
SW1(config-if)#switchport access vlan 12
% Access VLAN does not exist. Creating vlan 12
SW1(config-if)#int fast 0/2
SW1(config-if)#switchport mode access
SW1(config-if)#switchport access vlan 12
One of the many things I love about Cisco switches and routers is that if you have forgotten to do something, the Cisco device is generally going to remind you or in this case actually do it for you. I placed port 0/1 into a VLAN that did not yet exist, so the switch created it for me!
There are two commands needed to place a port into a VLAN. By default, these ports are running in dynamic desirable trunking mode, meaning that the port is actively attempting to form a trunk with a remote switch in order to send traffic between the two switches. The problem is that a trunk port belongs to all VLANs by default, and we want to put this port into a single VLAN only. To do so, we run the switchport mode access command to make the port an access port, and access ports belong to one and only one VLAN. After doing that, we placed the port into VLAN 12 with the switchport access vlan 12 command. Running the switchport mode access command effectively turns trunking off on that port.
The hosts are unaware of VLANs; they simply assume the VLAN membership of the port they're connected to. But that's not quite the case with dynamic VLANs, which we'll examine in the next part of this BCMSN tutorial.
Cisco CCNP / BCMSN Exam Tutorial: Multicasting And The RPF Check
Multicasting is a vital topic on your BCMSN, CCNP, and CCIE exams, and it can also be very confusing when you first start studying it. Multicasting uses concepts that are unlike anything you've run into in your routing protocol studies, and that can throw you at first. I speak from experience that multicasting is like any other Cisco technology - learn the basics, master the fundamentals, and then build your skills on that foundation.
One such fundamental is the RPF Check, or Reverse Path Forwarding Check.
A fundamental difference between unicasting and multicasting is that a unicast is routed by sending it toward the destination, while a multicast is routed by sending it away from its source.
"toward the destination" and "away from its source" sound like the same thing, but they're not. A unicast is going to follow a single path from source to destination. The only factor the routers care about is the destination IP address - the source IP address isn't a factor.
With multicast routing, the destination is a multicast IP group address. It's the multicast router's job to decide which paths will lead back to the source (upstream) and which paths are downstream from the source. Reverse Path Forwarding refers to the router's behavior of sending multicast packets away from the source rather than toward a specific destination.
The RPF Check is run against any incoming multicast packet. The multicast router examines the interface that the packet arrived on. If the packet comes in on an upstream interface - that is, an interface found on the reverse path that leads back to the source - the packet passes the check and will be forwarded. If the packet comes in on any other interface, the packet is dropped.
The RPF Check serves to verify the integrity of your multicasting network, and also serves as a reminder that the basic operation of multicasting is a lot different than unicasting!
One such fundamental is the RPF Check, or Reverse Path Forwarding Check.
A fundamental difference between unicasting and multicasting is that a unicast is routed by sending it toward the destination, while a multicast is routed by sending it away from its source.
"toward the destination" and "away from its source" sound like the same thing, but they're not. A unicast is going to follow a single path from source to destination. The only factor the routers care about is the destination IP address - the source IP address isn't a factor.
With multicast routing, the destination is a multicast IP group address. It's the multicast router's job to decide which paths will lead back to the source (upstream) and which paths are downstream from the source. Reverse Path Forwarding refers to the router's behavior of sending multicast packets away from the source rather than toward a specific destination.
The RPF Check is run against any incoming multicast packet. The multicast router examines the interface that the packet arrived on. If the packet comes in on an upstream interface - that is, an interface found on the reverse path that leads back to the source - the packet passes the check and will be forwarded. If the packet comes in on any other interface, the packet is dropped.
The RPF Check serves to verify the integrity of your multicasting network, and also serves as a reminder that the basic operation of multicasting is a lot different than unicasting!
Cisco CCNP / BCMSN Exam Tutorial: Changing Root Bridge Election Results
Your BCMSN and CCNP studies will include mastering the details of Spanning Tree Protocol (STP). While you learned some of these details in your CCNA studies, quite a bit of it may be new to you. Before going on to the intermediate and advanced STP features, let's review the root bridge election process and learn how to change these results.
Each switch will have a Bridge ID Priority value, more commonly referred to as a BID. This BID is a combination of a default priority value and the switch's MAC address, with the priority value listed first. For example, if a Cisco switch has the default priority value of 32,768 and a MAC address of 11-22-33-44-55-66, the BID would be 32768:11-22-33-44-55-66. Therefore, if the switch priority is left at the default, the MAC address is the deciding factor.
Switches are a lot like people - when they first arrive, they announce that they are the center of the universe! Unlike some people, the switches will soon get over it. BPDUs will be exchanged until one switch is elected Root Bridge, and it's the switch with the lowest BPDU that will end up being the Root Bridge.
If STP is left totally alone, a single switch is going to be the root bridge for every single VLAN in your network. Worse, that single switch is going to be selected because it has a lower MAC address than every other switch, which isn't exactly the criteria you want to use to select a single root bridge.
The time will definitely come when you want to determine a particular switch to be the root bridge for your VLANs, or when you will want to spread the root bridge workload. For instance, if you have 50 VLANs and five switches, you may want each switch to act as the root bridge for 10 VLANs each. You can make this happen with the spanning-tree vlan root command.
SW1(config)#spanning-tree vlan 1 ?
forward-time Set the forward delay for the spanning tree
hello-time Set the hello interval for the spanning tree
max-age Set the max age interval for the spanning tree
priority Set the bridge priority for the spanning tree
root Configure switch as root
In this example, we've got two switches, and SW1 has been elected the root bridge for VLANs 10, 20, and 30. We'll use the spanning-tree vlan root command on SW2 to make it the root bridge for VLANs 20 and 30.
SW2(config)#spanning-tree vlan 20 root primary
SW2(config)#spanning-tree vlan 30 root primary
SW2#show spanning vlan 20
VLAN0020
Spanning tree enabled protocol ieee
Root ID Priority 24596
Address 000f.90e2.1300
This bridge is the root
SW2#show spanning vlan 30
VLAN0030
Spanning tree enabled protocol ieee
Root ID Priority 24606
Address 000f.90e2.1300
This bridge is the root
SW 2 is now the root bridge for both VLAN 20 and 30. Notice that the priority value has changed from the default of 32768.
In the next CCNP / BCMSN tutorial, we'll take a look at more STP features.
Each switch will have a Bridge ID Priority value, more commonly referred to as a BID. This BID is a combination of a default priority value and the switch's MAC address, with the priority value listed first. For example, if a Cisco switch has the default priority value of 32,768 and a MAC address of 11-22-33-44-55-66, the BID would be 32768:11-22-33-44-55-66. Therefore, if the switch priority is left at the default, the MAC address is the deciding factor.
Switches are a lot like people - when they first arrive, they announce that they are the center of the universe! Unlike some people, the switches will soon get over it. BPDUs will be exchanged until one switch is elected Root Bridge, and it's the switch with the lowest BPDU that will end up being the Root Bridge.
If STP is left totally alone, a single switch is going to be the root bridge for every single VLAN in your network. Worse, that single switch is going to be selected because it has a lower MAC address than every other switch, which isn't exactly the criteria you want to use to select a single root bridge.
The time will definitely come when you want to determine a particular switch to be the root bridge for your VLANs, or when you will want to spread the root bridge workload. For instance, if you have 50 VLANs and five switches, you may want each switch to act as the root bridge for 10 VLANs each. You can make this happen with the spanning-tree vlan root command.
SW1(config)#spanning-tree vlan 1 ?
forward-time Set the forward delay for the spanning tree
hello-time Set the hello interval for the spanning tree
max-age Set the max age interval for the spanning tree
priority Set the bridge priority for the spanning tree
root Configure switch as root
In this example, we've got two switches, and SW1 has been elected the root bridge for VLANs 10, 20, and 30. We'll use the spanning-tree vlan root command on SW2 to make it the root bridge for VLANs 20 and 30.
SW2(config)#spanning-tree vlan 20 root primary
SW2(config)#spanning-tree vlan 30 root primary
SW2#show spanning vlan 20
VLAN0020
Spanning tree enabled protocol ieee
Root ID Priority 24596
Address 000f.90e2.1300
This bridge is the root
SW2#show spanning vlan 30
VLAN0030
Spanning tree enabled protocol ieee
Root ID Priority 24606
Address 000f.90e2.1300
This bridge is the root
SW 2 is now the root bridge for both VLAN 20 and 30. Notice that the priority value has changed from the default of 32768.
In the next CCNP / BCMSN tutorial, we'll take a look at more STP features.
Cisco CCNP / BCMSN Exam Tutorial: The Four (Or Five) STP Port States
As a CCNP candidate and a CCNA, you may be tempted to skip or just browse the many details of Spanning Tree Protocol. After all, you learned all of that in your CCNA studies, right? That's right, but it never hurts to review STP for a switching exam! Besides, many of us think of the four STP port states - but officially, there's a fifth one!
Disabled isn't generally thought of as an STP port state, but Cisco does officially consider this to be an STP state. A disabled port is one that is administratively shut down.
Once the port is opened, the port will go into blocking state. As the name implies, the port can't do much in this state - no frame forwarding, no frame receiving, and therefore no learning of MAC addresses. About the only thing this port can do is accept BPDUs from neighboring switches.
A port will then go from blocking mode into listening mode. The obvious question is "listening for what?" Listening for BPDUs - and this port can now send BPDUs as well. The port still can't forward or receive data frames.
When the port goes from listening mode to learning mode, it's getting ready to send and receive frames. In learning mode, the port begins to learn MAC addresses in preparation for adding them to its MAC address table.
Finally, a port can go into forwarding mode. This allows a port to forward and receive data frames, send and receive BPDUs, and place MAC addresses in its MAC table.
To see the STP mode of a given interface, use the show spanning-tree interface command.
SW1#show spanning-tree interface fast 0/11
Vlan Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- ----------
VLAN0001 Desg FWD 19 128.11 P2p
To see these states in action, shut a port down in your CCNA / CCNP home lab and continually run the show spanning interface command. Once you see this in action on real Cisco equipment, you'll have no problem with BCMSN exam questions. Just don't practice this or any other Cisco command on a production network!
Disabled isn't generally thought of as an STP port state, but Cisco does officially consider this to be an STP state. A disabled port is one that is administratively shut down.
Once the port is opened, the port will go into blocking state. As the name implies, the port can't do much in this state - no frame forwarding, no frame receiving, and therefore no learning of MAC addresses. About the only thing this port can do is accept BPDUs from neighboring switches.
A port will then go from blocking mode into listening mode. The obvious question is "listening for what?" Listening for BPDUs - and this port can now send BPDUs as well. The port still can't forward or receive data frames.
When the port goes from listening mode to learning mode, it's getting ready to send and receive frames. In learning mode, the port begins to learn MAC addresses in preparation for adding them to its MAC address table.
Finally, a port can go into forwarding mode. This allows a port to forward and receive data frames, send and receive BPDUs, and place MAC addresses in its MAC table.
To see the STP mode of a given interface, use the show spanning-tree interface command.
SW1#show spanning-tree interface fast 0/11
Vlan Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- ----------
VLAN0001 Desg FWD 19 128.11 P2p
To see these states in action, shut a port down in your CCNA / CCNP home lab and continually run the show spanning interface command. Once you see this in action on real Cisco equipment, you'll have no problem with BCMSN exam questions. Just don't practice this or any other Cisco command on a production network!
Cisco CCNP / BCMSN Exam Tutorial: The Core Layer Of Cisco's Three-Layer Model
In this section, you're going to be reintroduced to a networking model you first saw in your CCNA studies. No, it's not the OSI model or the TCP/IP model - it's the Cisco Three-Layer Hierarchical Model. Let's face it, just about all you had to do for the CCNA was memorize the three layers and the order they were found in that model, but the stakes are raised here in your CCNP studies. You need to know what each layer does, and what each layer should not be doing. This is vital information for your real-world network career as well, so let's get started with a review of the Cisco three-layer model, and then we'll take a look at each layer's tasks. Most of the considerations at each layer are common sense, but we'll go over them anyway!
Today we’ll take a look at the core layer of the Cisco model.
The term core switches refers to any switches found here. Switches at the core layer allow switches at the distribution layer to communicate, and this is more than a full-time job. It's vital to keep any extra workload off the core switches, and allow them to do what they need to do - switch! The core layer is the backbone of your entire network, so we're interested in high-speed data transfer and very low latency - that's it!
Core layer switches are usually the most powerful in your network, capable of higher throughput than any other switches in the network. Remember, everything we do on a Cisco router or switch has a cost in CPU or memory, so we're going to leave most frame manipulation and filtering to other layers. The exception is Cisco QoS, or Quality of Service. QoS is generally performed at the core layer. We'll go into much more detail regarding QoS in another tutorial, but for now, know that QoS is basically high-speed queuing where special consideration can be given to certain data in certain queues. (You’ll soon find that this is a very basic definition!)
We always want redundancy, but you want a lot of redundancy in your core layer. This is the nerve center of your entire network, so fault tolerance needs to be as high as you can possibly get it. Root bridges should also be located in the core layer.
The importance of keeping unnecessary workload off your core switches cannot be overstated. In the next part of this BCMSN tutorial, we’ll take a look at how the other layers of the Cisco three-part model do just that.
Today we’ll take a look at the core layer of the Cisco model.
The term core switches refers to any switches found here. Switches at the core layer allow switches at the distribution layer to communicate, and this is more than a full-time job. It's vital to keep any extra workload off the core switches, and allow them to do what they need to do - switch! The core layer is the backbone of your entire network, so we're interested in high-speed data transfer and very low latency - that's it!
Core layer switches are usually the most powerful in your network, capable of higher throughput than any other switches in the network. Remember, everything we do on a Cisco router or switch has a cost in CPU or memory, so we're going to leave most frame manipulation and filtering to other layers. The exception is Cisco QoS, or Quality of Service. QoS is generally performed at the core layer. We'll go into much more detail regarding QoS in another tutorial, but for now, know that QoS is basically high-speed queuing where special consideration can be given to certain data in certain queues. (You’ll soon find that this is a very basic definition!)
We always want redundancy, but you want a lot of redundancy in your core layer. This is the nerve center of your entire network, so fault tolerance needs to be as high as you can possibly get it. Root bridges should also be located in the core layer.
The importance of keeping unnecessary workload off your core switches cannot be overstated. In the next part of this BCMSN tutorial, we’ll take a look at how the other layers of the Cisco three-part model do just that.
Cisco CCNP / BCMSN Exam Tutorial: Switches, QoS, And Cisco's Networking Model
QoS is a big topic on your BCMSN and CCNP exams, and for good reason. As more and more traffic flows through today's networks, accurately applying QoS to both your routers and switches becomes more important.
Note the phrase "accurately applying". You must have a plan in place before you start configuring QoS on your switches, and to create such a plan you should use Cisco's Three-layer Hierarchical Model.
This model breaks switches down into three main groups - Access, Distribution, and Core. You're familiar with these groups from your CCNA studies, and now you've got to apply this knowledge.
The QoS workload should be borne by the Access and Distribution layers, because the Core layer switches need to be left alone as much as possible to their primary purpose - switching!
Traffic should generally be classified and marked at the Access layer. This allows traffic to be assigned the desired QoS values and carry that value throughout the network.
If you choose to change CoS-DSCP mappings, this will generally be done at the Distribution layer. Since distribution layer switches will be receiving frames and packets with QoS values from the access layer switches, the appropriate "trust" and "no trust" statements should be configured on the appropriate distribution layer switches.
Any traffic received by core switches should already be classified and marked as needed. The key with core switches is to use a simple queuing setup to keep the switching process fast. Fast, fast, fast!
Real-world note - Low Latency Queuing (LLQ) is an excellent choice for core switches. The name says it all - low latency! The configuration of LLQ is not a BCMSN topic, but a quick search on the term low latency queuing will quickly bring up several Cisco LLQ configuration documents.
Knowing the three layers of Cisco's networking model and the basic QoS operation and commands is vital to passing the CCNP exams, but even more importantly, you've got to apply this knowledge carefully and accurately to make QoS work for you in today's production networks.
Note the phrase "accurately applying". You must have a plan in place before you start configuring QoS on your switches, and to create such a plan you should use Cisco's Three-layer Hierarchical Model.
This model breaks switches down into three main groups - Access, Distribution, and Core. You're familiar with these groups from your CCNA studies, and now you've got to apply this knowledge.
The QoS workload should be borne by the Access and Distribution layers, because the Core layer switches need to be left alone as much as possible to their primary purpose - switching!
Traffic should generally be classified and marked at the Access layer. This allows traffic to be assigned the desired QoS values and carry that value throughout the network.
If you choose to change CoS-DSCP mappings, this will generally be done at the Distribution layer. Since distribution layer switches will be receiving frames and packets with QoS values from the access layer switches, the appropriate "trust" and "no trust" statements should be configured on the appropriate distribution layer switches.
Any traffic received by core switches should already be classified and marked as needed. The key with core switches is to use a simple queuing setup to keep the switching process fast. Fast, fast, fast!
Real-world note - Low Latency Queuing (LLQ) is an excellent choice for core switches. The name says it all - low latency! The configuration of LLQ is not a BCMSN topic, but a quick search on the term low latency queuing will quickly bring up several Cisco LLQ configuration documents.
Knowing the three layers of Cisco's networking model and the basic QoS operation and commands is vital to passing the CCNP exams, but even more importantly, you've got to apply this knowledge carefully and accurately to make QoS work for you in today's production networks.
Cisco CCNP / BCMSN Exam Tutorial: Spanning Tree Protocol (STP) Timers
In your BCMSN / CCNP exam study, it's easy to overlook some of the details of Spanning Tree Protocol (STP). After all, you learned all of that in your CCNA studies, right? Not necessarily! While some of the BCMSN material will be a review for you, there are some details regarding familiar topics that you need to learn. That includes the timers for STP - Hello Time, MaxAge, and Forward Delay.
You may remember these timers from your CCNA studies as well, and you should also remember that these timers should not be changed lightly. What you might not have known is that if you decide to change any and all of these timers, that change must be configured on the root bridge! The root bridge will inform the nonroot switches of the change via BPDUs.
Hello Time is the interval between BPDUs, two seconds by default.
Forward Delay is the length of both the listening and learning STP stages, with a default value of 15 seconds.
Maximum Age, referred to by the switch as MaxAge, is the amount of time a switch will retain a BPDU's contents before discarding it. The default is 20 seconds.
The value of these timers can be changed with the spanning-tree vlan command shown below. Verify the changes with the show spanning-tree command.
SW1(config)#spanning-tree vlan 1 ?
forward-time Set the forward delay for the spanning tree
hello-time Set the hello interval for the spanning tree
max-age Set the max age interval for the spanning tree
priority Set the bridge priority for the spanning tree
root Configure switch as root
SW1(config)#spanning-tree vlan 1 hello-time 5
SW1(config)#spanning-tree vlan 1 max-age 30
SW1(config)#spanning-tree vlan 1 forward-time 20
SW1(config)#^Z
SW1#show spanning-tree vlan 1
VLAN0001
Spanning tree enabled protocol ieee
Root ID Priority 32769
Address 000f.90e1.c240
This bridge is the root
Hello Time 5 sec Max Age 30 sec Forward Delay 20 sec
Bridge ID Priority 32769 (priority 32768 sys-id-ext 1)
Address 000f.90e1.c240
Hello Time 5 sec Max Age 30 sec Forward Delay 20 sec
Aging Time 300
Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Fa0/11 Desg FWD 19 128.11 P2p
Fa0/12 Desg FWD 19 128.12 P2p
Again, you should always take great care in changing these timers. Those defaults are set for a reason - helping to prevent switching loops!
You may remember these timers from your CCNA studies as well, and you should also remember that these timers should not be changed lightly. What you might not have known is that if you decide to change any and all of these timers, that change must be configured on the root bridge! The root bridge will inform the nonroot switches of the change via BPDUs.
Hello Time is the interval between BPDUs, two seconds by default.
Forward Delay is the length of both the listening and learning STP stages, with a default value of 15 seconds.
Maximum Age, referred to by the switch as MaxAge, is the amount of time a switch will retain a BPDU's contents before discarding it. The default is 20 seconds.
The value of these timers can be changed with the spanning-tree vlan command shown below. Verify the changes with the show spanning-tree command.
SW1(config)#spanning-tree vlan 1 ?
forward-time Set the forward delay for the spanning tree
hello-time Set the hello interval for the spanning tree
max-age Set the max age interval for the spanning tree
priority Set the bridge priority for the spanning tree
root Configure switch as root
SW1(config)#spanning-tree vlan 1 hello-time 5
SW1(config)#spanning-tree vlan 1 max-age 30
SW1(config)#spanning-tree vlan 1 forward-time 20
SW1(config)#^Z
SW1#show spanning-tree vlan 1
VLAN0001
Spanning tree enabled protocol ieee
Root ID Priority 32769
Address 000f.90e1.c240
This bridge is the root
Hello Time 5 sec Max Age 30 sec Forward Delay 20 sec
Bridge ID Priority 32769 (priority 32768 sys-id-ext 1)
Address 000f.90e1.c240
Hello Time 5 sec Max Age 30 sec Forward Delay 20 sec
Aging Time 300
Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Fa0/11 Desg FWD 19 128.11 P2p
Fa0/12 Desg FWD 19 128.12 P2p
Again, you should always take great care in changing these timers. Those defaults are set for a reason - helping to prevent switching loops!
Cisco CCNP / BCMSN Exam Tutorial: Multicasting And Reserved Addresses
Ever since you picked up your first CCNA book, you've heard about multicasting, gotten a fair idea of what it is, and you've memorized a couple of reserved multicasting addresses. Now as you prepare to pass the BCMSN exam and become a CCNP, you've got to take that knowledge to the next level and gain a true understanding of multicasting. Those of you with an eye on the CCIE will truly have to become multicasting experts!
Having said that, we're going to briefly review the basics of multicasting first, and then future tutorials will look at the different ways in which multicasting can be configured on Cisco routers and switches.
What Is Multicasting?
A unicast is data that is sent from one host to another, while a broadcast is data sent from a host that is destined for "all" host addresses. By "all", we can mean all hosts on a subnet, or truly all hosts on a network.
There's a quite a bit of a middle ground there! A multicast is that middle ground, as a multicast is data that is sent to a logical group of hosts, called a multicast group. Hosts that are not part of the multicast group will not receive the data.
Some other basic multicasting facts:
There's no limit on how many multicast groups a single host can belong to.
The sender is usually unaware of what host devices belong to the multicast group.
Multicast traffic is unidirectional. If the members of the multicast group need to respond, that reply will generally be a unicast.
The range of IP addresses reserved for multicasting is the Class D range, 224.0.0.0 - 239.255.255.255.
That range contains a couple of other reserved address ranges.
224.0.0.0 - 224.0.0.255 is reserved for network protocols only on a local network segment. Packets in this range will not be forwarded by routers, so these packets cannot leave the segment.
Just as Class A, Class B, and Class C networks have private address ranges, so does Class D. The Class D private address range is 239.0.0.0 - 239.255.255.255. Like the other private ranges, these addresses can't be routed, so they can be reused from one network to another.
The remaining addresses fall between 224.0.1.0 and 238.255.255.255. That's the "normal" range of multicast addresses. These addresses can be routed, so they must be unique and should not be duplicated from one network to the next.
In my next BCMSN / CCNP multicasting tutorial, we'll take a look at the different ways in which Cisco routers and switches interact to forward multicast traffic.
Having said that, we're going to briefly review the basics of multicasting first, and then future tutorials will look at the different ways in which multicasting can be configured on Cisco routers and switches.
What Is Multicasting?
A unicast is data that is sent from one host to another, while a broadcast is data sent from a host that is destined for "all" host addresses. By "all", we can mean all hosts on a subnet, or truly all hosts on a network.
There's a quite a bit of a middle ground there! A multicast is that middle ground, as a multicast is data that is sent to a logical group of hosts, called a multicast group. Hosts that are not part of the multicast group will not receive the data.
Some other basic multicasting facts:
There's no limit on how many multicast groups a single host can belong to.
The sender is usually unaware of what host devices belong to the multicast group.
Multicast traffic is unidirectional. If the members of the multicast group need to respond, that reply will generally be a unicast.
The range of IP addresses reserved for multicasting is the Class D range, 224.0.0.0 - 239.255.255.255.
That range contains a couple of other reserved address ranges.
224.0.0.0 - 224.0.0.255 is reserved for network protocols only on a local network segment. Packets in this range will not be forwarded by routers, so these packets cannot leave the segment.
Just as Class A, Class B, and Class C networks have private address ranges, so does Class D. The Class D private address range is 239.0.0.0 - 239.255.255.255. Like the other private ranges, these addresses can't be routed, so they can be reused from one network to another.
The remaining addresses fall between 224.0.1.0 and 238.255.255.255. That's the "normal" range of multicast addresses. These addresses can be routed, so they must be unique and should not be duplicated from one network to the next.
In my next BCMSN / CCNP multicasting tutorial, we'll take a look at the different ways in which Cisco routers and switches interact to forward multicast traffic.
Cisco CCNP / BCMSN Exam Tutorial: Dynamic VLANs and VMPS
Knowledge of Dynamic VLANs and VMPS is important in your efforts to pass the BCMSN exam and earn your CCNP, and it's also a great skill to have for your networking career.
As a CCNA and CCNP candidate, you know how and why to configure static VLANs. Static VLANs can be a powerful tool for reducing unnecessary broadcast and multicast traffic, but if hosts are moved from one switch port to another, you've got to make those changes manually on the switch. With Dynamic VLANs, the changes are made - how else? - dynamically.
The actual configuration of dynamic VLANs is out of the scope of the BCMSN exam, but as a CCNP candidate you need to know the basics of VMPS - a VLAN Membership Policy Server.
Using VMPS results in port VLAN membership changes being performed dynamically, because the port's VLAN membership is decided by the source MAC address of the device connected to that port. (Yet another reason that the first value a switch looks at on an incoming frame is the source MAC address.)
In my home lab network, I've got a host connected to switch port fast0/1 that resides in VLAN 12. What if we had to move Host 1's connection to the switch to port 0/6? With static VLANs, we'd have to connect to the switch, configure the port as an access port, and then place the port into VLAN 12. With VMPS, the only thing we'd have to do is reconnect the cable to port 0/6, and the VMPS would dynamically place that port into VLAN 12.
I urge you to do additional reading regarding VMPS. Use your favorite search engine for the term configuring vmps and you'll quickly find some great official Cisco documentation on this topic.
To review, the VLAN membership of a host is decided by one of two factors. With static VLANs, the host's VLAN membership is the VLAN to which its switch port has been assigned. With dynamic VLANs, it is dependent upon the host's MAC address.
As a CCNA and CCNP candidate, you know how and why to configure static VLANs. Static VLANs can be a powerful tool for reducing unnecessary broadcast and multicast traffic, but if hosts are moved from one switch port to another, you've got to make those changes manually on the switch. With Dynamic VLANs, the changes are made - how else? - dynamically.
The actual configuration of dynamic VLANs is out of the scope of the BCMSN exam, but as a CCNP candidate you need to know the basics of VMPS - a VLAN Membership Policy Server.
Using VMPS results in port VLAN membership changes being performed dynamically, because the port's VLAN membership is decided by the source MAC address of the device connected to that port. (Yet another reason that the first value a switch looks at on an incoming frame is the source MAC address.)
In my home lab network, I've got a host connected to switch port fast0/1 that resides in VLAN 12. What if we had to move Host 1's connection to the switch to port 0/6? With static VLANs, we'd have to connect to the switch, configure the port as an access port, and then place the port into VLAN 12. With VMPS, the only thing we'd have to do is reconnect the cable to port 0/6, and the VMPS would dynamically place that port into VLAN 12.
I urge you to do additional reading regarding VMPS. Use your favorite search engine for the term configuring vmps and you'll quickly find some great official Cisco documentation on this topic.
To review, the VLAN membership of a host is decided by one of two factors. With static VLANs, the host's VLAN membership is the VLAN to which its switch port has been assigned. With dynamic VLANs, it is dependent upon the host's MAC address.
Cisco CCNP / BCMSN Exam Tutorial: Dynamic Trunking Protocol (DTP)
When you're studying to pass the BCMSN exam on the way to earning your CCNP certification, you're going to add to your CCNA knowledgebase every step of the way. Nowhere is that more than configuring a trunk between two switches.
You know that IEEE 802.1Q ("dot1q") and ISL are your two choices of trunking protocols, and you know the main differences between the two. What you might not have known is that there's a third trunking protocol that's running between your Cisco switches, and while it's a transparent process to many, you had better know about it for your BCMSN and other CCNP exams!
The Cisco-proprietary Dynamic Trunking Protocol (DTP) actively attempts to negotiate a trunk link with the remote switch. This sounds great, but there is a cost in overhead - DTP frames are transmitted every 30 seconds. If you decide to configure a port as a non-negotiable trunk port, there's no need for the port to send DTP frames.
DTP can be turned off at the interface level with the switchport nonegotiate command, but as you see below, you cannot turn DTP off until the port is no longer in dynamic desirable trunking mode. (Dynamic desirable is the default mode for most Cisco switch ports.)
SW2(config)#int fast 0/8
SW2(config-if)#switchport nonegotiate
Command rejected: Conflict between 'nonegotiate' and 'dynamic' status.
SW2(config-if)#switchport mode ?
access Set trunking mode to ACCESS unconditionally
dynamic Set trunking mode to dynamically negotiate access or trunk mode
trunk Set trunking mode to TRUNK unconditionally
SW2(config-if)#switchport mode trunk
SW2(config-if)#switchport nonegotiate
When you're working with Cisco switches in a home lab or rack rental environment, run IOS Help regularly to see what options are available for the commands you're practicing with. Cisco switch ports have quite a few options, and the best way to find them is with one simple symbol - the question mark!
You know that IEEE 802.1Q ("dot1q") and ISL are your two choices of trunking protocols, and you know the main differences between the two. What you might not have known is that there's a third trunking protocol that's running between your Cisco switches, and while it's a transparent process to many, you had better know about it for your BCMSN and other CCNP exams!
The Cisco-proprietary Dynamic Trunking Protocol (DTP) actively attempts to negotiate a trunk link with the remote switch. This sounds great, but there is a cost in overhead - DTP frames are transmitted every 30 seconds. If you decide to configure a port as a non-negotiable trunk port, there's no need for the port to send DTP frames.
DTP can be turned off at the interface level with the switchport nonegotiate command, but as you see below, you cannot turn DTP off until the port is no longer in dynamic desirable trunking mode. (Dynamic desirable is the default mode for most Cisco switch ports.)
SW2(config)#int fast 0/8
SW2(config-if)#switchport nonegotiate
Command rejected: Conflict between 'nonegotiate' and 'dynamic' status.
SW2(config-if)#switchport mode ?
access Set trunking mode to ACCESS unconditionally
dynamic Set trunking mode to dynamically negotiate access or trunk mode
trunk Set trunking mode to TRUNK unconditionally
SW2(config-if)#switchport mode trunk
SW2(config-if)#switchport nonegotiate
When you're working with Cisco switches in a home lab or rack rental environment, run IOS Help regularly to see what options are available for the commands you're practicing with. Cisco switch ports have quite a few options, and the best way to find them is with one simple symbol - the question mark!
Cisco CCNP / BCMSN Exam Tutorial: Configuring CGMP On Routers & Switches
If a Layer Two switch doesn't have the capabilities to run IGMP Snooping, it will be able to run CGMP - Cisco Group Membership Protocol. CGMP allows the multicast router to work with the Layer Two switch to eliminate unnecessary multicast forwarding.
CGMP will be enabled on both the multicast router and the switch, but the router's going to do all the work. The router will be sending Join and Leave messages to the switch as needed. PIM must be running on the router interface facing the switch before enabling CGMP, as you can see:
R1(config)#int e0
R1(config-if)#ip cgmp
WARNING: CGMP requires PIM enabled on interface
R1(config-if)#ip pim sparse
R1(config-if)#ip cgmp
When CGMP is first enabled on both the multicast router and switch, the router will send a CGMP Join message, informing the switch that a multicast router is now connected to it. This particular CGMP Join will contain a Group Destination Address (GDA) of 0000.0000.0000 and the MAC address of the sending interface. The GDA is used to identify the multicast group, so when this is set to all zeroes, the switch knows this is an introductory CGMP Join, letting the switch know that the multicast router is online.
The switch makes an entry in its MAC table that this router can be found off the port that the CGMP Join came in on. The router will send a CGMP Join to the switch every minute to serve as a keepalive.
A workstation connected to the switch on port 0/5 now wishes to join multicast group 225.1.1.1. The Join message is sent to the multicast router, but first it will pass through the switch. The switch will do what you'd expect it to do - read the source MAC address and make an entry for it in the MAC address table as being off port fast 0/5 if there's not an entry already there. (Don't forget that the MAC address table is also referred to as the CAM table or the bridging table.)
The router will then receive the Join request, and send a CGMP Join back to the switch. This CGMP Join will contain both the multicast group's MAC address and the requesting host's MAC address. Now the switch knows about the multicast group 225.1.1.1 and that a member of that group is found off port fast 0/5. In the future, when the switch receives frames destined for that multicast group, the switch will not flood the frame as it would an unknown multicast. Instead, the switch will forward a copy of the frame to each port that it knows leads to a member of the multicast group.
Two major benefits of CGMP are the explicit Join and Leave Group messages. In the next part of this BCMSN exam tutorial, we’ll take a look at the Leave Group messages.
CGMP will be enabled on both the multicast router and the switch, but the router's going to do all the work. The router will be sending Join and Leave messages to the switch as needed. PIM must be running on the router interface facing the switch before enabling CGMP, as you can see:
R1(config)#int e0
R1(config-if)#ip cgmp
WARNING: CGMP requires PIM enabled on interface
R1(config-if)#ip pim sparse
R1(config-if)#ip cgmp
When CGMP is first enabled on both the multicast router and switch, the router will send a CGMP Join message, informing the switch that a multicast router is now connected to it. This particular CGMP Join will contain a Group Destination Address (GDA) of 0000.0000.0000 and the MAC address of the sending interface. The GDA is used to identify the multicast group, so when this is set to all zeroes, the switch knows this is an introductory CGMP Join, letting the switch know that the multicast router is online.
The switch makes an entry in its MAC table that this router can be found off the port that the CGMP Join came in on. The router will send a CGMP Join to the switch every minute to serve as a keepalive.
A workstation connected to the switch on port 0/5 now wishes to join multicast group 225.1.1.1. The Join message is sent to the multicast router, but first it will pass through the switch. The switch will do what you'd expect it to do - read the source MAC address and make an entry for it in the MAC address table as being off port fast 0/5 if there's not an entry already there. (Don't forget that the MAC address table is also referred to as the CAM table or the bridging table.)
The router will then receive the Join request, and send a CGMP Join back to the switch. This CGMP Join will contain both the multicast group's MAC address and the requesting host's MAC address. Now the switch knows about the multicast group 225.1.1.1 and that a member of that group is found off port fast 0/5. In the future, when the switch receives frames destined for that multicast group, the switch will not flood the frame as it would an unknown multicast. Instead, the switch will forward a copy of the frame to each port that it knows leads to a member of the multicast group.
Two major benefits of CGMP are the explicit Join and Leave Group messages. In the next part of this BCMSN exam tutorial, we’ll take a look at the Leave Group messages.
Cisco CCNP / BCMSN Exam Tutorial: Changing The Active Router In HSRP
To pass the BCMSN exam and earn your CCNP certification, you've got to know HSRP inside and out. While the operation and basic commands of HSRP are pretty simple, there are some important details that are easily overlooked but are vital in getting HSRP to work the way you want it to. Let's take a look at using the priority command correctly on both the exam and in production networks.
A key value in the show standby command is the priority. The default is 100, and the router with the highest priority will be the primary HSRP router. We'll raise the default priority on R2 and see the results. R3 is currently the Active router and R2 the standby, so let's raise the priority on R2 and see what happens.
R2(config)#interface ethernet0
R2(config-if)#standby 5 priority 150
R2#show standby
Ethernet0 - Group 5
Local state is Standby, priority 150
Hellotime 4 sec, holdtime 12 sec
Next hello sent in 0.896
Virtual IP address is 172.12.23.10 configured
Active router is 172.12.23.3, priority 100 expires in 8.072
Standby router is local
1 state changes, last state change 00:14:24
R2 now has a higher priority, but R3 is still the active router. R2 will not take over as the HSRP primary until R3 goes down - OR the preempt option is configured on R2.
R2(config-if)#standby 5 priority 150 preempt
1d11h: %STANDBY-6-STATECHANGE: Ethernet0 Group 5 state Standby -> Active
R2#show standby
Ethernet0 - Group 5
Local state is Active, priority 150, may preempt
Hellotime 4 sec, holdtime 12 sec
Next hello sent in 1.844
Virtual IP address is 172.12.23.10 configured
Active router is local
Standby router is 172.12.23.3 expires in 10.204
Virtual mac address is 0000.0c07.ac05
2 state changes, last state change 00:00:13
In just a few seconds, a message appears that the local state has changed from standby to active. Show standby confirms that R2, the local router, is now the active router - the primary. R3 is now the standby. So if anyone tells you that you have to take a router down to change the Active router, they're wrong - you just have to use the preempt option on the standby priority command.
Another vital part of HSRP configurations is knowing how to change the MAC address of the virtual router, as well as interface tracking. We'll look at those features in the next part of my HSRP tutorial!
A key value in the show standby command is the priority. The default is 100, and the router with the highest priority will be the primary HSRP router. We'll raise the default priority on R2 and see the results. R3 is currently the Active router and R2 the standby, so let's raise the priority on R2 and see what happens.
R2(config)#interface ethernet0
R2(config-if)#standby 5 priority 150
R2#show standby
Ethernet0 - Group 5
Local state is Standby, priority 150
Hellotime 4 sec, holdtime 12 sec
Next hello sent in 0.896
Virtual IP address is 172.12.23.10 configured
Active router is 172.12.23.3, priority 100 expires in 8.072
Standby router is local
1 state changes, last state change 00:14:24
R2 now has a higher priority, but R3 is still the active router. R2 will not take over as the HSRP primary until R3 goes down - OR the preempt option is configured on R2.
R2(config-if)#standby 5 priority 150 preempt
1d11h: %STANDBY-6-STATECHANGE: Ethernet0 Group 5 state Standby -> Active
R2#show standby
Ethernet0 - Group 5
Local state is Active, priority 150, may preempt
Hellotime 4 sec, holdtime 12 sec
Next hello sent in 1.844
Virtual IP address is 172.12.23.10 configured
Active router is local
Standby router is 172.12.23.3 expires in 10.204
Virtual mac address is 0000.0c07.ac05
2 state changes, last state change 00:00:13
In just a few seconds, a message appears that the local state has changed from standby to active. Show standby confirms that R2, the local router, is now the active router - the primary. R3 is now the standby. So if anyone tells you that you have to take a router down to change the Active router, they're wrong - you just have to use the preempt option on the standby priority command.
Another vital part of HSRP configurations is knowing how to change the MAC address of the virtual router, as well as interface tracking. We'll look at those features in the next part of my HSRP tutorial!
Cisco CCNP / BCMSN Exam Tutorial: BPDU Skew Detection
You may look at that feature's name and think, "What is a BPDU Skew, and why do I want to detect it?" What we're actually attempting to detect are BPDUs that aren't being relayed as quickly as they should be.
After the root bridge election, the root bridge transmits BPDUs, and the non-root switches relay that BPDU down the STP tree. This should happen quickly all around, since the root bridge will be sending a BPDU every two seconds by default ("hello time"), and the switches should relay the BDPUs fast enough so every switch is seeing a BPDU every two seconds.
That's in a perfect world, though, and there are plenty of imperfect networks out there! You may have a busy switch that can't spare the CPU to relay the BDPU quickly, or a BPDU may just simply be lost in transmission. That two-second hello time value doesn't give the switches much leeway, but we don't want the STP topology recalculated unnecessarily either.
BDPU Skew Detection is strictly a notification feature. Skew Detection will not take action to prevent STP recalculation when BDPUs are not being relayed quickly enough by the switches, but it will send a syslog message informing the network administrator of the problem. The amount of time between when the BDPU should have arrived and when it did arrive is referred to as "skew time" or "BPDU latency".
A busy CPU could quickly find itself overwhelmed if it had to send a syslog message for every BPDU delivery that's skewed. The syslog messages will be limited to one every 60 seconds, unless the "skew time" is at a critical level. In that case, the syslog message will be sent immediately with no one-per-minute limit.
And what is "critical", according to BDPU Skew Detection? Any value greater than 1/2 of the MaxAge value, making the critical skew time level 10 seconds or greater.
After the root bridge election, the root bridge transmits BPDUs, and the non-root switches relay that BPDU down the STP tree. This should happen quickly all around, since the root bridge will be sending a BPDU every two seconds by default ("hello time"), and the switches should relay the BDPUs fast enough so every switch is seeing a BPDU every two seconds.
That's in a perfect world, though, and there are plenty of imperfect networks out there! You may have a busy switch that can't spare the CPU to relay the BDPU quickly, or a BPDU may just simply be lost in transmission. That two-second hello time value doesn't give the switches much leeway, but we don't want the STP topology recalculated unnecessarily either.
BDPU Skew Detection is strictly a notification feature. Skew Detection will not take action to prevent STP recalculation when BDPUs are not being relayed quickly enough by the switches, but it will send a syslog message informing the network administrator of the problem. The amount of time between when the BDPU should have arrived and when it did arrive is referred to as "skew time" or "BPDU latency".
A busy CPU could quickly find itself overwhelmed if it had to send a syslog message for every BPDU delivery that's skewed. The syslog messages will be limited to one every 60 seconds, unless the "skew time" is at a critical level. In that case, the syslog message will be sent immediately with no one-per-minute limit.
And what is "critical", according to BDPU Skew Detection? Any value greater than 1/2 of the MaxAge value, making the critical skew time level 10 seconds or greater.
Monday, December 22, 2008
Cisco CCNA / CCNP / BCMSN Exam Review: Trunking And Trunking Protocols
To earn your CCNA or CCNP certification, you've got to understand the basics of trunking. This isn't just a CCNA topic - you must have an advanced understanding of trunking and etherchannels to pass the BCMSN exam and earn your CCNP as well. Before we address those advanced topics, though, you need to master the fundamentals!
A trunk allows inter-VLAN traffic to flow between directly connected switches. By default, a trunk port is a member of all VLANs, so traffic for any and all VLANs can travel across this trunk. That includes broadcast traffic!
The default mode of a switch port does differ between models, so always check your documentation. On Cisco 2950 switches, every single port is in dynamic desirable mode by default, meaning that every port is actively attempting to trunk. On these switches, the only action needed from us is to physically connect them with a crossover cable. In just a few seconds, the port light turns green and the trunk is up and running. The command show interface trunk will verify trunking.
How does the receiving switch know what VLAN the frame belongs to? The frames are tagged by the transmitting switch with a VLAN ID, reflecting the number of the VLAN whose member ports should receive this frame. When the frame arrives at the remote switch, that switch will examine this ID and then forward the frame appropriately.
There are two major trunking protocols you must understand and compare successfully, those being ISL and IEEE 802.1Q. Let's take a look at the details of ISL first.
ISL is a Cisco-proprietary trunking protocol, making it unsuitable for a multivendor environment. That's one drawback, but there are others. ISL will place both a header and trailer onto the frame, encapsulating it. This increases the overhead on the trunk line.
You know that the default VLAN is also known as the "native VLAN", and another drawback to ISL is that ISL does not use the concept of the native VLAN. This means that every single frame transmitted across the trunk will be encapsulated.
The 26-byte header that is added to the frame by ISL contains the VLAN ID; the 4-byte trailer contains a Cyclical Redundancy Check (CRC) value. The CRC is a frame validity scheme that checks the frame's integrity.
In turn, this encapsulation leads to another potential issue. ISL encapsulation adds 30 bytes total to the size of the frame, potentially making them too large for the switch to handle. (The maximum size for an Ethernet frame is 1518 bytes.)
IEEE 802.1q differs substantially from ISL. In contrast to ISL, dot1q does not encapsulate frames. A 4-byte header is added to the frame, resulting in less overhead than ISL. If the frame is destined for hosts residing in the native VLAN, that header isn't added. Since the header is only 4 bytes in size, and isn't even placed on every frame, using dot1q lessens the chance of oversized frames. When the remote port receives an untagged frame, the switch knows that these untagged frames are destined for the native VLAN.
Knowing the details is the difference between passing and failing your CCNA and CCNP exams. Keep studying, get some hands-on practice, and you’re on your way to Cisco certification success!
A trunk allows inter-VLAN traffic to flow between directly connected switches. By default, a trunk port is a member of all VLANs, so traffic for any and all VLANs can travel across this trunk. That includes broadcast traffic!
The default mode of a switch port does differ between models, so always check your documentation. On Cisco 2950 switches, every single port is in dynamic desirable mode by default, meaning that every port is actively attempting to trunk. On these switches, the only action needed from us is to physically connect them with a crossover cable. In just a few seconds, the port light turns green and the trunk is up and running. The command show interface trunk will verify trunking.
How does the receiving switch know what VLAN the frame belongs to? The frames are tagged by the transmitting switch with a VLAN ID, reflecting the number of the VLAN whose member ports should receive this frame. When the frame arrives at the remote switch, that switch will examine this ID and then forward the frame appropriately.
There are two major trunking protocols you must understand and compare successfully, those being ISL and IEEE 802.1Q. Let's take a look at the details of ISL first.
ISL is a Cisco-proprietary trunking protocol, making it unsuitable for a multivendor environment. That's one drawback, but there are others. ISL will place both a header and trailer onto the frame, encapsulating it. This increases the overhead on the trunk line.
You know that the default VLAN is also known as the "native VLAN", and another drawback to ISL is that ISL does not use the concept of the native VLAN. This means that every single frame transmitted across the trunk will be encapsulated.
The 26-byte header that is added to the frame by ISL contains the VLAN ID; the 4-byte trailer contains a Cyclical Redundancy Check (CRC) value. The CRC is a frame validity scheme that checks the frame's integrity.
In turn, this encapsulation leads to another potential issue. ISL encapsulation adds 30 bytes total to the size of the frame, potentially making them too large for the switch to handle. (The maximum size for an Ethernet frame is 1518 bytes.)
IEEE 802.1q differs substantially from ISL. In contrast to ISL, dot1q does not encapsulate frames. A 4-byte header is added to the frame, resulting in less overhead than ISL. If the frame is destined for hosts residing in the native VLAN, that header isn't added. Since the header is only 4 bytes in size, and isn't even placed on every frame, using dot1q lessens the chance of oversized frames. When the remote port receives an untagged frame, the switch knows that these untagged frames are destined for the native VLAN.
Knowing the details is the difference between passing and failing your CCNA and CCNP exams. Keep studying, get some hands-on practice, and you’re on your way to Cisco certification success!
CCNP Certification / BCMSN Exam Tutorial: QoS Service Types
To pass the CCNP exams, you’ve got to master Quality of Service, and the first step in doing so is knowing the differences between the different QoS types.
Now this being Cisco, we can't just have one kind of QoS! We've got best-effort delivery, Integrated Services, and Differentiated Services. Let's take a quick look at all three.
Best-effort is just what it sounds like - routers and switches making their "best effort" to deliver data. This is considered QoS, but it's kind of a "default QoS". Best effort is strictly "first in, first out" (FIFO).
An entire path from Point A to Point B will be defined in advance when Integrated Services are in effect. Integrated Services is much like the High-Occupancy Vehicle lanes found in many larger cities. If your car has three or more people in it, you're considered a "priority vehicle" and you can drive in a special lane with much less congestion than regular lanes. Integrated Services will create this lane in advance for "priority traffic", and when that traffic comes along, the path already exists. Integrated Services uses the Resource Reservation Protocol (RSVP) to create these paths. RSVP guarantees a quality rate of service, since this "priority path" is created in advance.
Integrated Services is defined in RFC 1613. Use your favorite search engine to locate a copy online and read more about this topic. It's a good idea to get into the habit of reading RFCs!
Of course, if you've got a lot of different dedicated paths being created that may or not be used very often, that's a lot of wasted bandwidth. That leads us to the third QoS model, the Differentiated Services model. Generally referred to as DiffServ, there are no advance path reservations and there's no RSVP. The QoS policies are written on the routers and switches, and they take action dynamically as needed. Since each router and switch can have a different QoS policy, DiffServ takes effect on a per-hop basis rather than the per-flow basis of Integrated Services. A packet can be considered "high priority" by one router and "normal priority" by the next.
Believe me, this is just the beginning when it comes to Quality of Service. It's a huge topic on your exams and in the real world's production networks, and as with all other Cisco topics, just master the fundamentals and build from there - and you're on your way to CCNP exam success!
Now this being Cisco, we can't just have one kind of QoS! We've got best-effort delivery, Integrated Services, and Differentiated Services. Let's take a quick look at all three.
Best-effort is just what it sounds like - routers and switches making their "best effort" to deliver data. This is considered QoS, but it's kind of a "default QoS". Best effort is strictly "first in, first out" (FIFO).
An entire path from Point A to Point B will be defined in advance when Integrated Services are in effect. Integrated Services is much like the High-Occupancy Vehicle lanes found in many larger cities. If your car has three or more people in it, you're considered a "priority vehicle" and you can drive in a special lane with much less congestion than regular lanes. Integrated Services will create this lane in advance for "priority traffic", and when that traffic comes along, the path already exists. Integrated Services uses the Resource Reservation Protocol (RSVP) to create these paths. RSVP guarantees a quality rate of service, since this "priority path" is created in advance.
Integrated Services is defined in RFC 1613. Use your favorite search engine to locate a copy online and read more about this topic. It's a good idea to get into the habit of reading RFCs!
Of course, if you've got a lot of different dedicated paths being created that may or not be used very often, that's a lot of wasted bandwidth. That leads us to the third QoS model, the Differentiated Services model. Generally referred to as DiffServ, there are no advance path reservations and there's no RSVP. The QoS policies are written on the routers and switches, and they take action dynamically as needed. Since each router and switch can have a different QoS policy, DiffServ takes effect on a per-hop basis rather than the per-flow basis of Integrated Services. A packet can be considered "high priority" by one router and "normal priority" by the next.
Believe me, this is just the beginning when it comes to Quality of Service. It's a huge topic on your exams and in the real world's production networks, and as with all other Cisco topics, just master the fundamentals and build from there - and you're on your way to CCNP exam success!
Subscribe to:
Posts (Atom)
