While studying to pass the BSCI exam and preparing to earn your CCNP certification, you'll quickly notice that while OSPF and ISIS are both link-state protocols, there are a lot of differences between the two. One major difference is the way the two protocols handle hello packets.
Hello packets are imperative to keeping OSPF and ISIS adjacencies alive. Since they are both link-state protocols, neither of them will send updates at any specified time. Hello packets are the only method by which routers running OSPF and ISIS can see that a neighboring router is still available.
OSPF gives us some great options when it comes to keeping routing table size down via the use of stub and total stub areas, but to OSPF, a hello packet is a hello packet. ISIS routers are capable of sending two different types of hellos - Level 1 and Level 2.
ISIS routers are classified as Level 1 (L1), Level 2 (L2), and Level 1-2 (L1-L2). By default, Cisco routers are L1-L2 routers; this means that every ISIS-enabled interface will send out both L1 and L2 hellos.
If one of the interfaces is forming only an L1 or L2 adjacency, there's no reason to send out hellos for the other adjacency type. For example, if R1 is forming an L1 adjacency with R2 via its ethernet0 interface, there is no reason to allow the router to transmit L2 hellos. To hardcode a router interface to send only L1 or L2 hellos, use the isis circuit-type command.
R1(config)#interface ethernet0
R1(config-if)#isis circuit-type level-1
Note: To configure this interface to send only L2 hellos, the full command is "isis circuit-type level-2-only", not just "level-2".
This configuration would prevent L2 hellos from being transmitted out ethernet0. While this does save router resources and prevents unnecessary bandwidth usage, there is also no way an L2 adjacency can be formed - so double-check your network topology before using this command!
Showing posts with label protocol. Show all posts
Showing posts with label protocol. Show all posts
Thursday, December 25, 2008
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: 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: 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 CCNA Exam Tutorial: Troubleshooting Directly Connected Serial Interfaces
CCNA exam success depends largely on noticing the details, and this is especially true of configurations involving directly connected serial interfaces. And of course, it's not enough to notice these details - you've got to know what to do about them!
A Cisco router is a DTE by default, but directly connecting two DTEs with a DCE/DTE cable is not enough. In the following example, R1 and R3 are directly connected at their Serial1 interfaces. The line goes up briefly after being opened, but the line protocol goes down after about 30 seconds.
R3(config-if)#int s1
R3(config-if)#ip address 172.12.13.3 255.255.255.0
R3(config-if)#no shutdown
2d18h: %LINK-3-UPDOWN: Interface Serial1, changed state to up
2d18h: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to up
R3(config-if)#
2d18h: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to down
The problem is that one of the routers needs to act as the DCE in order for the line protocol to come up and stay up. If this were your CCNA / CCNP home lab, you could just go over and look at the DTE/DCE cable to see which router had the DCE end of the cable attached. In this example, though, we don't have physical access to the routers. How can we tell which router has the DCE end of the cable attached?
R3#show controller serial 1
HD unit 1, idb = 0x1C44E8, driver structure at 0x1CBAC8
buffer size 1524 HD unit 1, V.35 DCE cable
The show controller command gives us this information. (There's a lot more output that this with this command, but it's unimportant for our purposes.) The router with the DCE end of the cable needs to supply a clock rate to the DTE, and we'll do just that with the interface-level clockrate command.
R3#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R3(config)#int serial1
R3(config-if)#clockrate 56000
2d18h: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to up
In just a few seconds, the line protocol goes up and stays up.
When troubleshooting a connection, always run show interface first. If you see the combination shown below, the connection is physically fine but logically down. That's generally the result of a needed keepalive not being present. With Frame Relay, it's probably an LMI issue, but with directly connected serial interfaces the issue is most likely the DCE end of the connection not supplying clockrate.
R3#show interface serial 1
Serial1 is up, line protocol is down
Troubleshooting is a big part of the job, and it's a big part of the Cisco CCNA and CCNP programs as well. Know your show and debug commands and you're on your way to passing the CCNA!
A Cisco router is a DTE by default, but directly connecting two DTEs with a DCE/DTE cable is not enough. In the following example, R1 and R3 are directly connected at their Serial1 interfaces. The line goes up briefly after being opened, but the line protocol goes down after about 30 seconds.
R3(config-if)#int s1
R3(config-if)#ip address 172.12.13.3 255.255.255.0
R3(config-if)#no shutdown
2d18h: %LINK-3-UPDOWN: Interface Serial1, changed state to up
2d18h: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to up
R3(config-if)#
2d18h: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to down
The problem is that one of the routers needs to act as the DCE in order for the line protocol to come up and stay up. If this were your CCNA / CCNP home lab, you could just go over and look at the DTE/DCE cable to see which router had the DCE end of the cable attached. In this example, though, we don't have physical access to the routers. How can we tell which router has the DCE end of the cable attached?
R3#show controller serial 1
HD unit 1, idb = 0x1C44E8, driver structure at 0x1CBAC8
buffer size 1524 HD unit 1, V.35 DCE cable
The show controller command gives us this information. (There's a lot more output that this with this command, but it's unimportant for our purposes.) The router with the DCE end of the cable needs to supply a clock rate to the DTE, and we'll do just that with the interface-level clockrate command.
R3#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R3(config)#int serial1
R3(config-if)#clockrate 56000
2d18h: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to up
In just a few seconds, the line protocol goes up and stays up.
When troubleshooting a connection, always run show interface first. If you see the combination shown below, the connection is physically fine but logically down. That's generally the result of a needed keepalive not being present. With Frame Relay, it's probably an LMI issue, but with directly connected serial interfaces the issue is most likely the DCE end of the connection not supplying clockrate.
R3#show interface serial 1
Serial1 is up, line protocol is down
Troubleshooting is a big part of the job, and it's a big part of the Cisco CCNA and CCNP programs as well. Know your show and debug commands and you're on your way to passing the CCNA!
Cisco CCNA Exam Tutorial: Directly Connected Serial Interfaces
To pass the CCNA exam, you've got to master quite a few services and routing protocols that may be new to you. Between RIP, IGRP, EIGRP, OSPF, and switching, there are hundreds of details you've got to absorb! It's easy to spend all your time on those topics and not pay proper attention to "easier" technologies, and then all of a sudden on exam day you can't quite remember the details of those particular services.
One setup you've got to be more than familiar with is directly connecting serial interfaces on Cisco routers. This is also a valuable skill to have in your home lab, since it allows you to add segments to your network setup.
A Cisco serial interface is operating as a DTE by default. The problem is that when you take a cable and connect two routers directly by their serial interfaces (with a DTE/DCE cable, that is!), they're both waiting for the other to send them a clock rate. One of the interfaces must act as the DCE and that interface must send the clock rate.
If you can see the DTE/DCE cable, you can tell by looking which router has the DCE interface connected to it - the letters "DTE" or "DCE" will either be molded into the connector itself, or if it's an older cable there should be a little piece of tape on the cable that tells you what the interface type is. But what if you have no access to the cable, or there are other cables all around it and you can't see what type it is?
Run the command "show controller serial x", with x representing the interface number the cable's connected to. There will be quite a bit of output from this command, but the information you need is right at the top:
R1#show controller serial 1
HD unit 1, idb = 0x1DBFEC, driver structure at 0x1E35D0
buffer size 1524 HD unit 1, V.35 DTE cable
I left off the 16 or so rows of information that comes after this, but this is the information we need right now. If R1's got the DTE cable end, the other router should have the DCE end:
R3#show controller serial 1
HD unit 1, idb = 0x1C44E8, driver structure at 0x1CBAC8
buffer size 1524 HD unit 1, V.35 DCE cable
We know now that R3 needs to supply a clock rate to R1. There's a hint of a problem in just that little bit of command output - do you see what it is? Let's run show interface serial1 to get more information.
R3#show int s1
Serial1 is up, line protocol is down
The line protocol is down because there is no clockrate being supplied by R3. If there has been, we would have seen that in the output of show controllers serial 1.
This is simple enough to fix, though! We'll use the command clockrate 56000 on R3's serial1 interface, and the line protocol will soon come up.
R3(config)#int s1
R3(config-if)#clockrate 56000
1w2d: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to up
This is a simple concept, but there are a few details you must keep in mind! For a home lab configuration, you'll need a DTE/DCE cable to make this work. If you cannot see the cable connectors, run show controllers serial x to see if the router has the DTE or DCE end of the cable attached. On the interface with the DCE attached, use the clockrate command to bring the line protocol up. It's just that simple!
One setup you've got to be more than familiar with is directly connecting serial interfaces on Cisco routers. This is also a valuable skill to have in your home lab, since it allows you to add segments to your network setup.
A Cisco serial interface is operating as a DTE by default. The problem is that when you take a cable and connect two routers directly by their serial interfaces (with a DTE/DCE cable, that is!), they're both waiting for the other to send them a clock rate. One of the interfaces must act as the DCE and that interface must send the clock rate.
If you can see the DTE/DCE cable, you can tell by looking which router has the DCE interface connected to it - the letters "DTE" or "DCE" will either be molded into the connector itself, or if it's an older cable there should be a little piece of tape on the cable that tells you what the interface type is. But what if you have no access to the cable, or there are other cables all around it and you can't see what type it is?
Run the command "show controller serial x", with x representing the interface number the cable's connected to. There will be quite a bit of output from this command, but the information you need is right at the top:
R1#show controller serial 1
HD unit 1, idb = 0x1DBFEC, driver structure at 0x1E35D0
buffer size 1524 HD unit 1, V.35 DTE cable
I left off the 16 or so rows of information that comes after this, but this is the information we need right now. If R1's got the DTE cable end, the other router should have the DCE end:
R3#show controller serial 1
HD unit 1, idb = 0x1C44E8, driver structure at 0x1CBAC8
buffer size 1524 HD unit 1, V.35 DCE cable
We know now that R3 needs to supply a clock rate to R1. There's a hint of a problem in just that little bit of command output - do you see what it is? Let's run show interface serial1 to get more information.
R3#show int s1
Serial1 is up, line protocol is down
The line protocol is down because there is no clockrate being supplied by R3. If there has been, we would have seen that in the output of show controllers serial 1.
This is simple enough to fix, though! We'll use the command clockrate 56000 on R3's serial1 interface, and the line protocol will soon come up.
R3(config)#int s1
R3(config-if)#clockrate 56000
1w2d: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to up
This is a simple concept, but there are a few details you must keep in mind! For a home lab configuration, you'll need a DTE/DCE cable to make this work. If you cannot see the cable connectors, run show controllers serial x to see if the router has the DTE or DCE end of the cable attached. On the interface with the DCE attached, use the clockrate command to bring the line protocol up. It's just that simple!
Wednesday, December 24, 2008
Cisco CCNA Exam Tutorial: Cisco Discovery Protocol (CDP)
The Cisco Discovery Protocol (CDP) sure looks simple enough, but there are quite a few details to know for success on the CCNA exam. In your CCNP studies, you'll be introduced to additional uses for CDP, but for now it's enough to know that CDP is designed to give you information regarding directly connected Cisco routers and switches.
CDP runs by default between all directly connected Cisco devices. CDP is also a Cisco-proprietary protocol - if the directly connected device is not a Cisco device, you won't see the information you wanted.
The basic CDP command to display information about the directly connected neighbor is "show cdp neighbor".
R2#show cdp neighbor
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
S - Switch, H - Host, I - IGMP, r – Repeater
Device ID Local Intrfce Holdtme Capability Platform Port ID
R1 BRI0 167 R 2521 Dialer1
This command is particularly helpful when troubleshooting Cisco switches. There’s no need to trace wiring in a rack of Cisco devices to see what routers are connected to a Cisco switch when show cdp neighbor can be used. In the above output, you can see the remote device's hostname, what interface on the remote device is connected to the local device, the capability of the remote device, the remote device’s hardware platform, and the local interface that is connected to the remote device.
CDP can be disabled at both the global and interface level. To disable CDP at the interface level, run no cdp enable on the interface, and cdp enable to turn it back on.
cdp timer defines how often CDP packets are transmitted, and cdp holdtime defines how long a device will hold a received packet.
To turn CDP off for the entire router, run no cdp run. To view the current global status of CDP, run show cdp.
R2#show cdp
Global CDP information:
Sending CDP packets every 60 seconds
Sending a holdtime value of 180 seconds
CDP is running by default.
R2#conf t
R2(config)#cdp timer 45
R2(config)#cdp holdtime 100
The CDP timers are changed.
R2#show cdp
Global CDP information:
Sending CDP packets every 45 seconds
Sending a holdtime value of 100 seconds
The CDP values have been successfully changed. “show cdp interface” will give the timer information for each interface on the router.
R2#conf t
R2(config)#interface bri0
R2(config-if)#no cdp enable
CDP is disabled on the BRI interface. This does NOT have to be done to keep the line from dialing.
R2#conf t
R2(config)#no cdp run
CDP is disabled globally.
R2#show cdp
% CDP is not enabled
CDP has been successfully disabled.
Show cdp neighbor gives you a great deal of information, but what if you need the neighbor’s IP address? Just run show cdp neighbor detail. You will get even more information about that directly connected neighbor, including its IP address.
SW2#show cdp neighbor detail
-------------------------
Device ID: R4
Entry address(es):
IP address: 172.12.23.4
Platform: cisco 2520, Capabilities: Router
Interface: FastEthernet0/4, Port ID (outgoing port): Ethernet0
Holdtime : 158 sec
The details of CDP are important to you on the job and in the CCNA exam room. When you find yourself negotiating a badly documented network, you can use CDP to "walk" through the network and create a network map for your client as well. Sometimes the simplest protocols are the most helpful!
CDP runs by default between all directly connected Cisco devices. CDP is also a Cisco-proprietary protocol - if the directly connected device is not a Cisco device, you won't see the information you wanted.
The basic CDP command to display information about the directly connected neighbor is "show cdp neighbor".
R2#show cdp neighbor
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
S - Switch, H - Host, I - IGMP, r – Repeater
Device ID Local Intrfce Holdtme Capability Platform Port ID
R1 BRI0 167 R 2521 Dialer1
This command is particularly helpful when troubleshooting Cisco switches. There’s no need to trace wiring in a rack of Cisco devices to see what routers are connected to a Cisco switch when show cdp neighbor can be used. In the above output, you can see the remote device's hostname, what interface on the remote device is connected to the local device, the capability of the remote device, the remote device’s hardware platform, and the local interface that is connected to the remote device.
CDP can be disabled at both the global and interface level. To disable CDP at the interface level, run no cdp enable on the interface, and cdp enable to turn it back on.
cdp timer defines how often CDP packets are transmitted, and cdp holdtime defines how long a device will hold a received packet.
To turn CDP off for the entire router, run no cdp run. To view the current global status of CDP, run show cdp.
R2#show cdp
Global CDP information:
Sending CDP packets every 60 seconds
Sending a holdtime value of 180 seconds
CDP is running by default.
R2#conf t
R2(config)#cdp timer 45
R2(config)#cdp holdtime 100
The CDP timers are changed.
R2#show cdp
Global CDP information:
Sending CDP packets every 45 seconds
Sending a holdtime value of 100 seconds
The CDP values have been successfully changed. “show cdp interface” will give the timer information for each interface on the router.
R2#conf t
R2(config)#interface bri0
R2(config-if)#no cdp enable
CDP is disabled on the BRI interface. This does NOT have to be done to keep the line from dialing.
R2#conf t
R2(config)#no cdp run
CDP is disabled globally.
R2#show cdp
% CDP is not enabled
CDP has been successfully disabled.
Show cdp neighbor gives you a great deal of information, but what if you need the neighbor’s IP address? Just run show cdp neighbor detail. You will get even more information about that directly connected neighbor, including its IP address.
SW2#show cdp neighbor detail
-------------------------
Device ID: R4
Entry address(es):
IP address: 172.12.23.4
Platform: cisco 2520, Capabilities: Router
Interface: FastEthernet0/4, Port ID (outgoing port): Ethernet0
Holdtime : 158 sec
The details of CDP are important to you on the job and in the CCNA exam room. When you find yourself negotiating a badly documented network, you can use CDP to "walk" through the network and create a network map for your client as well. Sometimes the simplest protocols are the most helpful!
Cisco CCNA Certification Exam Tutorial: The OSPF RID
OSPF is a major topic on your CCNA exam, as well it should be. OSPF is a widely-used WAN protocol, and you need to learn the fundamentals before moving on to more complicated configurations. One such detail is the OSPF Router ID, or RID.
The RID is the dotted decimal value by which other OSPF routers will identify a given OSPF router. There are some interesting defaults for this value, and a command you should know to hardcode the RID. You had also better know what has to happen for this command to take effect, so let's take a more detailed look at the OSPF RID.
In this example, R1 has an adjacency with R2 and R3 over the 172.12.123.0/24 frame network. R1 is the hub, with R2 and R3 as the spokes. No other interfaces are OSPF-enabled on any of the routers. Running show ip ospf neighbor on R1, we see some unusual values under "Neighbor ID", which is another name for the OSPF RID.
R1#show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
3.3.3.3 0 FULL/DROTHER 00:01:57 172.12.123.3 Serial0
2.2.2.2 0 FULL/DROTHER 00:01:57 172.12.123.2 Serial0
Notice the Neighbor ID of each remote address is the loopback address. How can that be if they’re not OSPF-enabled?
When determining the Router ID (RID) of an OSPF-enabled router, OSPF will always use the numerically highest IP address on the router’s loopback interfaces, regardless of whether that loopback is OSPF-enabled.
What if there is no loopback? OSPF will then use the numerically highest IP address of the physical interfaces, regardless of whether that interface is OSPF-enabled.
BOTTOM LINE: An interface does not have to be running OSPF to have its IP address used as the OSPF RID.
The OSPF RID can be changed, but it requires a restart or to reinitialize the OSPF routing process. Use the router-id command to change the default RID of each router as shown, and clear the OSPF process to do so.
R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#router ospf 1
R1(config-router)#router-id 11.11.11.11
Reload or use "clear ip ospf process" command, for this to take effect
R1#clear ip ospf process
Reset ALL OSPF processes? [no]: yes
1d05h: %OSPF-5-ADJCHG: Process 1, Nbr 3.3.3.3 on Serial0 from 2WAY to
DOWN, Neighbor Down: Interface down or detached
1d05h: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on Serial0 from 2WAY to
DOWN, Neighbor Down: Interface down or detached
After entering the router-id command, the router console informed you that you have to reload the router or reset the OSPF processes for this to take effect. You enter the clear ip ospf process command to do this. Notice that when you’re asked if you really want to do this, the prompt is “no”? That’s because all the OSPF adjacencies on this router will be lost and will have to begin the process again. That’s OK on a practice rack, not good in a production network. Don’t use that one at work.
The OSPF RID is not a complicated concept, but the fact that an interface doesn't have to be OSPF-enabled in order to have its IP address act as the RID takes some getting used to. And remember - when the router or switch asks you a question and the prompted answer is "no", take one step back and make sure you really want to do what you're about to do!
The RID is the dotted decimal value by which other OSPF routers will identify a given OSPF router. There are some interesting defaults for this value, and a command you should know to hardcode the RID. You had also better know what has to happen for this command to take effect, so let's take a more detailed look at the OSPF RID.
In this example, R1 has an adjacency with R2 and R3 over the 172.12.123.0/24 frame network. R1 is the hub, with R2 and R3 as the spokes. No other interfaces are OSPF-enabled on any of the routers. Running show ip ospf neighbor on R1, we see some unusual values under "Neighbor ID", which is another name for the OSPF RID.
R1#show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
3.3.3.3 0 FULL/DROTHER 00:01:57 172.12.123.3 Serial0
2.2.2.2 0 FULL/DROTHER 00:01:57 172.12.123.2 Serial0
Notice the Neighbor ID of each remote address is the loopback address. How can that be if they’re not OSPF-enabled?
When determining the Router ID (RID) of an OSPF-enabled router, OSPF will always use the numerically highest IP address on the router’s loopback interfaces, regardless of whether that loopback is OSPF-enabled.
What if there is no loopback? OSPF will then use the numerically highest IP address of the physical interfaces, regardless of whether that interface is OSPF-enabled.
BOTTOM LINE: An interface does not have to be running OSPF to have its IP address used as the OSPF RID.
The OSPF RID can be changed, but it requires a restart or to reinitialize the OSPF routing process. Use the router-id command to change the default RID of each router as shown, and clear the OSPF process to do so.
R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#router ospf 1
R1(config-router)#router-id 11.11.11.11
Reload or use "clear ip ospf process" command, for this to take effect
R1#clear ip ospf process
Reset ALL OSPF processes? [no]: yes
1d05h: %OSPF-5-ADJCHG: Process 1, Nbr 3.3.3.3 on Serial0 from 2WAY to
DOWN, Neighbor Down: Interface down or detached
1d05h: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on Serial0 from 2WAY to
DOWN, Neighbor Down: Interface down or detached
After entering the router-id command, the router console informed you that you have to reload the router or reset the OSPF processes for this to take effect. You enter the clear ip ospf process command to do this. Notice that when you’re asked if you really want to do this, the prompt is “no”? That’s because all the OSPF adjacencies on this router will be lost and will have to begin the process again. That’s OK on a practice rack, not good in a production network. Don’t use that one at work.
The OSPF RID is not a complicated concept, but the fact that an interface doesn't have to be OSPF-enabled in order to have its IP address act as the RID takes some getting used to. And remember - when the router or switch asks you a question and the prompted answer is "no", take one step back and make sure you really want to do what you're about to do!
Cisco CCNA Certification Exam Tutorial: RIP Details You Must Know
RIP isn't exactly the most complex routing protocol on the CCNA exam, but that makes it easy to overlook some of the important details you must keep in mind in order to pass the exam! To help you review for the exam, here are just a few of those details!
RIP’s default behavior is to send version 1 updates, but to accept both version 1 and 2 routing updates.
R2(config)#router rip
R2(config-router)#net 172.16.0.0
R2(config-router)#^Z
R2#show ip protocols
Routing Protocol is "rip"
Sending updates every 30 seconds, next due in 6 seconds
Invalid after 180 seconds, hold down 180, flushed after 240
Outgoing update filter list for all interfaces is
Incoming update filter list for all interfaces is
Redistributing: rip
Default version control: send version 1, receive any version
Interface Send Recv Key-chain
Serial0 1 1 2
By default, RIP v2 autosummarizes routing updates sent across classful network boundaries. To disable this behavior, run no auto-summary under the RIP process.
R1#conf t
R1(config)#router rip
R1(config-router)#version 2
R1(config-router)#no auto-summary
You do not specify a subnet mask or wildcard mask when configuring RIP – just the classful network, even if you’re running RIP v2.
R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#router rip
R1(config-router)#version 2
R1(config-router)#no auto-summary
R1(config-router)#network 172.10.0.0 ?
Debug ip rip displays the routing updates and metrics as the advertisements are sent and requested. To see this in action without waiting for the next regularly scheduled update, run clear ip route *.
R1#debug ip rip
RIP protocol debugging is on
R1#clear ip route *
01:16:54: RIP: sending v1 update to 255.255.255.255 via Loopback1 (1.1.1.1)
01:16:54: network 2.0.0.0, metric 2
01:16:54: network 3.0.0.0, metric 2
01:16:54: network 172.16.0.0, metric 1
01:16:54: network 10.0.0.0, metric 2
01:16:54: RIP: sending v1 update to 255.255.255.255 via Serial0 (172.16.123.1)
01:16:54: subnet 172.16.123.0, metric 1
01:16:54: network 1.0.0.0, metric 1
01:16:54: network 2.0.0.0, metric 2
01:16:54: network 3.0.0.0, metric 2
01:16:54: network 10.0.0.0, metric 2
To see only the routes discovered by a routing protocol, run show ip route followed by the name of the protocol:
R1#show ip route rip
R 2.0.0.0/8 [120/1] via 172.16.123.2, 00:00:26, Serial0
R 3.0.0.0/8 [120/1] via 172.16.13.2, 00:00:09, Serial1
[120/1] via 172.16.123.3, 00:00:09, Serial0
R 10.0.0.0/8 [120/1] via 172.16.13.2, 00:00:09, Serial1
[120/1] via 172.16.123.3, 00:00:09, Serial0
[120/1] via 172.16.123.2, 00:00:26, Serial0
And don't forget - to turn off all currently running debugs, run undebug all.
R1#undebug all
All possible debugging has been turned off
Don't overlook RIP and IGRP when it comes to the CCNA exam. OSPF and EIGRP are more complex to configure, but you need to understand how distance vector protocols work in order to pass the CCNA!
RIP’s default behavior is to send version 1 updates, but to accept both version 1 and 2 routing updates.
R2(config)#router rip
R2(config-router)#net 172.16.0.0
R2(config-router)#^Z
R2#show ip protocols
Routing Protocol is "rip"
Sending updates every 30 seconds, next due in 6 seconds
Invalid after 180 seconds, hold down 180, flushed after 240
Outgoing update filter list for all interfaces is
Incoming update filter list for all interfaces is
Redistributing: rip
Default version control: send version 1, receive any version
Interface Send Recv Key-chain
Serial0 1 1 2
By default, RIP v2 autosummarizes routing updates sent across classful network boundaries. To disable this behavior, run no auto-summary under the RIP process.
R1#conf t
R1(config)#router rip
R1(config-router)#version 2
R1(config-router)#no auto-summary
You do not specify a subnet mask or wildcard mask when configuring RIP – just the classful network, even if you’re running RIP v2.
R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#router rip
R1(config-router)#version 2
R1(config-router)#no auto-summary
R1(config-router)#network 172.10.0.0 ?
Debug ip rip displays the routing updates and metrics as the advertisements are sent and requested. To see this in action without waiting for the next regularly scheduled update, run clear ip route *.
R1#debug ip rip
RIP protocol debugging is on
R1#clear ip route *
01:16:54: RIP: sending v1 update to 255.255.255.255 via Loopback1 (1.1.1.1)
01:16:54: network 2.0.0.0, metric 2
01:16:54: network 3.0.0.0, metric 2
01:16:54: network 172.16.0.0, metric 1
01:16:54: network 10.0.0.0, metric 2
01:16:54: RIP: sending v1 update to 255.255.255.255 via Serial0 (172.16.123.1)
01:16:54: subnet 172.16.123.0, metric 1
01:16:54: network 1.0.0.0, metric 1
01:16:54: network 2.0.0.0, metric 2
01:16:54: network 3.0.0.0, metric 2
01:16:54: network 10.0.0.0, metric 2
To see only the routes discovered by a routing protocol, run show ip route followed by the name of the protocol:
R1#show ip route rip
R 2.0.0.0/8 [120/1] via 172.16.123.2, 00:00:26, Serial0
R 3.0.0.0/8 [120/1] via 172.16.13.2, 00:00:09, Serial1
[120/1] via 172.16.123.3, 00:00:09, Serial0
R 10.0.0.0/8 [120/1] via 172.16.13.2, 00:00:09, Serial1
[120/1] via 172.16.123.3, 00:00:09, Serial0
[120/1] via 172.16.123.2, 00:00:26, Serial0
And don't forget - to turn off all currently running debugs, run undebug all.
R1#undebug all
All possible debugging has been turned off
Don't overlook RIP and IGRP when it comes to the CCNA exam. OSPF and EIGRP are more complex to configure, but you need to understand how distance vector protocols work in order to pass the CCNA!
Tuesday, December 23, 2008
Cisco CCNA / CCNP Certification Exam Review: Protocol Basics
To earn your Cisco CCNA certification and pass the BSCI CCNP exam, you have to know your protocol basics like the back of your hand! To help you review these important concepts, here's a quick look at the basics of RIPv1, RIPv2, IGRP, and EIGRP.
RIPv1: Broadcasts updates every 30 seconds to the address 255.255.255.255. RIPv1 is a classful protocol, and it does not recognize VLSM, nor does it carry subnet masking information in its routing updates. Update contains entire RIP routing table. Uses Bellman-Ford algorithm. Allows equal-cost load-balancing by default. Max hop count is 15. Does not support clear-text or MD5 authentication of routing updates. Updates carry 25 routes maximum.
RIPv2: Multicasts updates every 30 seconds to the address 224.0.0.9. RIPv2 is a classless protocol, allowing the use of subnet masks. Update contains entire RIP routing table. Uses Bellman-Ford algorithm. Allows equal-cost load-balancing by default. Max hop count is 15. Supports clear-text and MD5 authentication of routing updates. Updates carry 25 routes maximum.
IGRP: Broadcasts updates every 90 seconds to the address 255.255.255.255. IGRP is a Cisco-proprietary protocol, and is also a classful protocol and does not recognize subnet masking. Update contains entire routing table. Uses Bellman-Ford algorithm. Equal-cost load-balancing on by default; unequal-cost load-sharing can be used with the variance command. Max hop count is 100.
EIGRP: Multicasts full routing table only when an adjacency is first formed. Multicasts updates only when there is a change in the network topology, and then only advertises the change. Multicasts to 224.0.0.10 and allows the use of subnet masks. Uses DUAL routing algorithm. Unequal-cost load-sharing available with the variance command.
By mastering the basics of these protocols, you're laying the foundation for success in the exam room and when working on production networks. Pay attention to the details and the payoff is "CCNA" and "CCNP" behind your name!
RIPv1: Broadcasts updates every 30 seconds to the address 255.255.255.255. RIPv1 is a classful protocol, and it does not recognize VLSM, nor does it carry subnet masking information in its routing updates. Update contains entire RIP routing table. Uses Bellman-Ford algorithm. Allows equal-cost load-balancing by default. Max hop count is 15. Does not support clear-text or MD5 authentication of routing updates. Updates carry 25 routes maximum.
RIPv2: Multicasts updates every 30 seconds to the address 224.0.0.9. RIPv2 is a classless protocol, allowing the use of subnet masks. Update contains entire RIP routing table. Uses Bellman-Ford algorithm. Allows equal-cost load-balancing by default. Max hop count is 15. Supports clear-text and MD5 authentication of routing updates. Updates carry 25 routes maximum.
IGRP: Broadcasts updates every 90 seconds to the address 255.255.255.255. IGRP is a Cisco-proprietary protocol, and is also a classful protocol and does not recognize subnet masking. Update contains entire routing table. Uses Bellman-Ford algorithm. Equal-cost load-balancing on by default; unequal-cost load-sharing can be used with the variance command. Max hop count is 100.
EIGRP: Multicasts full routing table only when an adjacency is first formed. Multicasts updates only when there is a change in the network topology, and then only advertises the change. Multicasts to 224.0.0.10 and allows the use of subnet masks. Uses DUAL routing algorithm. Unequal-cost load-sharing available with the variance command.
By mastering the basics of these protocols, you're laying the foundation for success in the exam room and when working on production networks. Pay attention to the details and the payoff is "CCNA" and "CCNP" behind your name!
Cisco CCNA / CCNP Certification Exam: Troubleshooting Direct Serial Connections
A prime topic of your CCNA and CCNP CIT exams will be connecting Cisco routers directly via their Serial interfaces, and while the configuration is straightforward, there are some vital details and show commands you must know in order to pass the exams and configure this successfully in production and home lab networks. Let's take a look at a sample configuration.
Connecting Cisco routers directly via their Serial interfaces works really well once you get it running - and getting such a connection up and running is easy enough. You can use show controller serial x to find out which endpoint is acting as the DCE, and it's the DCE that must be configured with the clockrate command.
R3#show controller serial 1
HD unit 1, idb = 0x11B4DC, driver structure at 0x121868
buffer size 1524 HD unit 1, V.35 DCE cable
R3(config)#int serial1
R3(config-if)#ip address 172.12.13.3 255.255.255.0
R3(config-if)#clockrate 56000
R3(config-if)#no shut
Failure to configure the clockrate has some interesting effects regarding the physical and logical state of the interfaces. Let's remove the clockrate from R3 and see what happens.
R3(config)#int s1
R3(config-if)#no clockrate 56000
R3(config-if)#
18:02:19: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to down
The line protocol doesn't drop immediately, but it does drop. Let's run show interface serial1 to compare the physical and logical interface states.
R3#show int serial1
Serial1 is up, line protocol is down
Physically, the interface is fine, so the physical interface is up. It's only the logical part of the interface - the line protocol - that is down. It's the same situation on R1.
R1#show inter serial1
Serial1 is up, line protocol is down
While a router misconfiguration is the most likely cause of a serial connection issue, that's not the only reason for clocking issues. Cisco's website documentation mentions CSU/DSU misconfiguration, out-of-spec cables, bad patch panel connections, and connecting too many cables together as other reasons for clocking problems. Still, the number one reason for clocking problems in my experience is simply forgetting to configure the clockrate command!
Connecting Cisco routers directly via their Serial interfaces works really well once you get it running - and getting such a connection up and running is easy enough. You can use show controller serial x to find out which endpoint is acting as the DCE, and it's the DCE that must be configured with the clockrate command.
R3#show controller serial 1
HD unit 1, idb = 0x11B4DC, driver structure at 0x121868
buffer size 1524 HD unit 1, V.35 DCE cable
R3(config)#int serial1
R3(config-if)#ip address 172.12.13.3 255.255.255.0
R3(config-if)#clockrate 56000
R3(config-if)#no shut
Failure to configure the clockrate has some interesting effects regarding the physical and logical state of the interfaces. Let's remove the clockrate from R3 and see what happens.
R3(config)#int s1
R3(config-if)#no clockrate 56000
R3(config-if)#
18:02:19: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to down
The line protocol doesn't drop immediately, but it does drop. Let's run show interface serial1 to compare the physical and logical interface states.
R3#show int serial1
Serial1 is up, line protocol is down
Physically, the interface is fine, so the physical interface is up. It's only the logical part of the interface - the line protocol - that is down. It's the same situation on R1.
R1#show inter serial1
Serial1 is up, line protocol is down
While a router misconfiguration is the most likely cause of a serial connection issue, that's not the only reason for clocking issues. Cisco's website documentation mentions CSU/DSU misconfiguration, out-of-spec cables, bad patch panel connections, and connecting too many cables together as other reasons for clocking problems. Still, the number one reason for clocking problems in my experience is simply forgetting to configure the clockrate command!
Cisco CCNA / CCNP Certification Exam: Same Command, Different Results
As a CCNA or CCNP, one thing you've got to get used to is that change is constant. Cisco regularly issues new IOS versions, not to mention the many different kinds of hardware they produce! While it's always nice to have "the latest and the greatest" when it comes to routers, switches, firewalls, etc., we have to be prepared for the fact that not all our clients are going to have that latest and greatest!
For instance, there are still quite a few Catalyst 5000 switches out there humming away, and if you're used to working on IOS-driven switches like the 2950, the same command can have dramatically different results.
Let's say you're going to examine the spanning tree protocol (STP) setup of a new client. You're used to working with newer 2950 switches, and you've always run show span on those switches to display spanning-tree information. Then, you run show span on a Catalyst 5000 - and something like this shows:
switch (enable) show span
Destination : Port 6/1
Admin Source : Port 6/2
Oper Source : Port 6/2
Direction : transmit/receive
Incoming Packets: disabled
Learning : enabled
Multicast : enabled
Filter : -
Status : active
Total local span sessions: 1
What's going on here?
The command show span on a 5000 will not show spanning tree stats - instead, what you're going to see are statistics relating to Switched Port ANalyzer (SPAN). Surprise!
Consider an example where you're used to running show span on 5000 switches to see SPAN information. When you run that on a 2950, you know now what you're going to get - spanning tree information! On a 2950, you'll need to run show monitor session, followed by the SPAN session number.
SW1#show monitor session 1
Session 1
---------
Type : Local Session
Source Ports :
Both : Fa0/1
Destination Ports : Fa0/2
Encapsulation : Native
Ingress: Disabled
As a CCNA and CCNP, this is one of those things you just have to get used to. Commands are going to be different, sometimes radically so, between models. That's why you need to be adept with both IOS Help and Cisco's online documentation site. IOS Help is easy, but the online doc site take a little getting used to. Once you learn how to navigate that site, a world of Cisco knowledge is at your fingertips.
Besides, when you sit for the CCIE lab exam, that will be the only friend you have! And a valuable friend it can be - you're just going to have to trust me on that one. :)
For instance, there are still quite a few Catalyst 5000 switches out there humming away, and if you're used to working on IOS-driven switches like the 2950, the same command can have dramatically different results.
Let's say you're going to examine the spanning tree protocol (STP) setup of a new client. You're used to working with newer 2950 switches, and you've always run show span on those switches to display spanning-tree information. Then, you run show span on a Catalyst 5000 - and something like this shows:
switch (enable) show span
Destination : Port 6/1
Admin Source : Port 6/2
Oper Source : Port 6/2
Direction : transmit/receive
Incoming Packets: disabled
Learning : enabled
Multicast : enabled
Filter : -
Status : active
Total local span sessions: 1
What's going on here?
The command show span on a 5000 will not show spanning tree stats - instead, what you're going to see are statistics relating to Switched Port ANalyzer (SPAN). Surprise!
Consider an example where you're used to running show span on 5000 switches to see SPAN information. When you run that on a 2950, you know now what you're going to get - spanning tree information! On a 2950, you'll need to run show monitor session, followed by the SPAN session number.
SW1#show monitor session 1
Session 1
---------
Type : Local Session
Source Ports :
Both : Fa0/1
Destination Ports : Fa0/2
Encapsulation : Native
Ingress: Disabled
As a CCNA and CCNP, this is one of those things you just have to get used to. Commands are going to be different, sometimes radically so, between models. That's why you need to be adept with both IOS Help and Cisco's online documentation site. IOS Help is easy, but the online doc site take a little getting used to. Once you learn how to navigate that site, a world of Cisco knowledge is at your fingertips.
Besides, when you sit for the CCIE lab exam, that will be the only friend you have! And a valuable friend it can be - you're just going to have to trust me on that one. :)
Monday, December 22, 2008
CCNP Certification / BCMSN Exam Tutorial: Getting Started With HSRP
Defined in RFC 2281, HSRP is a Cisco-proprietary protocol in which routers are put into an HSRP router group. Along with dynamic routing protocols and STP, HSRP is considered a high-availability network service, since all three have an almost immediate cutover to a secondary path when the primary path is unavailable.
One of the routers will be selected as the primary ("Active", in HSRP terminology), and that primary will handle the routing while the other routers are in standby, ready to handle the load if the primary router becomes unavailable. In this fashion, HSRP ensures a high network uptime, since it routes IP traffic without relying on a single router.
The hosts using HSRP as a gateway don't know the actual IP or MAC addresses of the routers in the group. They're communicating with a pseudorouter, a "virtual router" created by the HSRP configuration. This virtual router will have a virtual MAC and IP adddress as well.
The standby routers aren't just going to be sitting there, though! By configuring multiple HSRP groups on a single interface, HSRP load balancing can be achieved.
Before we get to the more advanced HSRP configuration, we better get a basic one started! We'll be using a two-router topology here, and keep in mind that one or both of these routers could be multilayer switches as well. For ease of reading, I'm going to refer to them only as routers.
R2 and R3 will both be configured to be in standby group 5. The virtual router will have an IP address of 172.12.23.10 /24. All hosts in VLAN 100 should use this address as their default gateway.
R2(config)#interface ethernet0
R2(config-if)#standby 5 ip 172.12.23.10
R3(config)#interface ethernet0
R3(config-if)#standby 5 ip 172.12.23.10
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
We can see that R3 has been selected as the Active router ("local state is Active"), the virtual router's IP is 172.12.23.10, and R2 is the standby router.
There are some HSRP values that you'll need to change from time to time. What if we want R2 to be the Active router instead? Can we change the MAC address of the virtual router? I'll answer those questions in the next part of this HSRP tutorial!
One of the routers will be selected as the primary ("Active", in HSRP terminology), and that primary will handle the routing while the other routers are in standby, ready to handle the load if the primary router becomes unavailable. In this fashion, HSRP ensures a high network uptime, since it routes IP traffic without relying on a single router.
The hosts using HSRP as a gateway don't know the actual IP or MAC addresses of the routers in the group. They're communicating with a pseudorouter, a "virtual router" created by the HSRP configuration. This virtual router will have a virtual MAC and IP adddress as well.
The standby routers aren't just going to be sitting there, though! By configuring multiple HSRP groups on a single interface, HSRP load balancing can be achieved.
Before we get to the more advanced HSRP configuration, we better get a basic one started! We'll be using a two-router topology here, and keep in mind that one or both of these routers could be multilayer switches as well. For ease of reading, I'm going to refer to them only as routers.
R2 and R3 will both be configured to be in standby group 5. The virtual router will have an IP address of 172.12.23.10 /24. All hosts in VLAN 100 should use this address as their default gateway.
R2(config)#interface ethernet0
R2(config-if)#standby 5 ip 172.12.23.10
R3(config)#interface ethernet0
R3(config-if)#standby 5 ip 172.12.23.10
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
We can see that R3 has been selected as the Active router ("local state is Active"), the virtual router's IP is 172.12.23.10, and R2 is the standby router.
There are some HSRP values that you'll need to change from time to time. What if we want R2 to be the Active router instead? Can we change the MAC address of the virtual router? I'll answer those questions in the next part of this HSRP tutorial!
Subscribe to:
Posts (Atom)
