Are you a CCNP or CCIE student looking to challenge your perfect knowledge of Catalyst switchport commands?
Take the latest SWITCH Command Recall exam by clicking the link below. Good luck – and let us know how you scored in the comments area of this post.
Remember to read, AND TYPE, very carefully! I failed my first attempt due to just plain sloppiness. 
SWITCH Command Recall Exam – L2/L3 Ports
Our BGP class is coming up! This class is for learners who are pursuing the CCIP track, or simply want to really master BGP. I have been working through the slides, examples and demos that we’ll use in class, and it is going to be excellent. 
If you can’t make the live event, we are recording it, so it will be available as a class on demand, after the live event. More information, can be found by clicking here.
One of the common questions that comes up is “Why does the router choose THAT route?
We all know, (or at least after reading the list below, we will know), that BGP uses the following order, to determine the “best” path.
So now for the question. Take a look at the partial output of the show command below:
Regarding the 2.2.2.0/24 network, why did this router select the 192.168.68.8 next hop route, over the one just below it?
Post your ideas, and we will have a drawing next week, before the BGP class begins. We’ll give 1 lucky winner some rack tokens for our preferred rack vendor, Graded Labs. Everyone who comments, will be entered into the drawing. I will update the post with the lucky winner.
Thanks for your ideas, and happy learning,
Keith Barker
Thank you to all who responded. eBGP is preferred over iBGP, and that is what it came down to.
The winner of the graded labs tokens is Jon! Congratulations.
One of the features students love in the INE 5-Day CCNP bootcamp is the frequent Exam Challenges that are presented to students. Have fun with this sample from SWITCH.
Q1: Examine the configurations shown and the topology. Identify three errors in the configurations.
Exhibit 1
SW1 interface range fa0/16 – 17 switchport trunk encapsulation dot1q switchport mode dynamic desirable no shutdown channel-group 1 mode on
SW3
interface range fa0/16 – 17
switchport trunk encapsulation dot1q
switchport mode dynamic auto
shutdown
channel-group 3 mode active
In the first part of this series, we subdivided the processes of EIGRP into four discrete steps, and detailed troubleshooting the first two. This is taken from the 5-Day CCNP bootcamp:
Let us now discuss path selection and maintenance troubleshooting.
We should all remember that we can view the topology table of EIGRP with the command show ip eigrp topology. Here we can see the successor routes (these are the best routes that are placed in the routing table) and we can see the second best routes, the feasible successor routes. These feasible successor routes are the key to the lightening fast convergence that EIGRP can offer us. When a speaker loses its successor, it can quickly install a feasible successor route in its place.
We need to remember the important rule of feasible successors. The advertised distance of the proposed feasible successor must be less than the feasible distance of the current successor route. This is actually a loop prevention mechanism.
Another big gotcha when it comes to path selection in EIGRP is the configuration of variance to unequal cost load balance. I can remember fighting with this in an INE practice lab long ago when I was preparing for the exam. Something I had no idea of back then…in order to be considered for the unequal load balancing, the alternate paths must be feasible successors! Older editions of CCNP courses never thought to tell us that little nugget!
We should be careful when modifying bandwidth to effect path selection. Cisco gave us delay for this purpose. Modifying the bandwidth can starve EIGRP updates of bandwidth to use. Remember, by default, EIGRP will only use 50% of an interface’s bandwidth. We can control this with the command ip bandwidth percent eigrp.
For table maintenance, show ip eigrp topology is critical. Note that in this table, passive is what we want to see. Active indicates there is not a feasible successor and neighbors are being queried for an alternative path. SIA log messages indicate a Stuck in Active issue. Here the router is not receiving a reply to queries. The most common reasons this can occur:
When it comes to table maintenance, another excellent troubleshooting command is show ip eigrp topology summary. This command displays the total number of routes in the topology table and the total number of queries the router is waiting on responses for. It also shows a quiescent interface field that shows which interface have no outstanding packets to be sent or acknowledged.
Some of our favorite EIGRP verification commands:
We are so excited here at INE for the live, online 5-Day CCNP bootcamp that starts Monday, August 16, 2010 . I look forward to seeing many of our aspiring CCIE candidates in this course. These students realize that they really need to improve their foundation Tier 1 knowledge as they seek to conquer the Lab Exam beast.
In this blog post, we are going to provide a sneak peek into some of the awesome information shared in the TSHOOT section of the bootcamp regarding the Troubleshooting of EIGRP. This can prove critical in the Troubleshooting and Configuration sections of the CCIE R&S Lab Exam, as well as the TSHOOT CCNP exam (duh!).
Where Is My Neighbor!?!?!?
The first thing that you want to master when it comes to troubleshooting EIGRP is the ‘workflow” that EIGRP follows in its operation. We can subdivide the processes of this exciting protocol into four discrete steps:
Discovery of Neighbors
Remember that EIGRP discovers neighbors through bi-directional multicast by default. IP protocol 88 and 224.0.0.10 are the key parameters we need to watch out for here. Could there be issues with NBMA pseudo-broadcast support or filtering causing neighbor discovery to fail? Certainly things to examine in the topology. Also, watch out for the neighbor command under the EIGRP routing process. This feature causes the use of unicast packets for neighbor creation exclusively and must be agreed upon by BOTH neighbors.
Another area we need to be aware of is the attributes that must match in order for neighbors to form. Sure this list is nowhere near as lengthy as the parameters that we have to watch out for in OSPF networks, but the list is just as critical:
Exchange of Topology Information
When it comes to the exchange of topology information, this is done with unicast. Notice that connectivity for neighborship still requires mutlicast communications (unless you are using the neighbor command).
Remember that EIGRP will only advertise those prefixes that it installs in the routing table. This is an excellent time to review the difference from the Topology Table to the Routing Table.
Important troubleshooting considerations for the exchange of topology information include:
Please consider these troubleshooting aspects for these two phases of EIGRP’s operation. We will cover more in the next installment coming soon…
Are you wondering what the month of August 2010 will bring for INE fans?
Try all new, online bootcamps in the following disciplines:
Watch the blog and your email for all of the exciting new details.
Join the INE Experts Online in August
Starting July 1st, we are introducing downloadable content for the CCSP and CCVP bootcamp class-on-demand courses. This exciting new addition will come as a warm welcome to all those looking to have the world’s best training programs on the go. These courses will be offered in .m4v video format and work seamlessly on the iPhone, iPad, and other mobile devices as well as on your desktop. We will be providing a upgrade option for everyone who currently has these classes as well as a product add-on to those who have held out for this option. The upgrade price will be just $49.95 and give you the freedom to watch Flash free content wherever you go.
There is even more good news! If you purchase either the CCSP Bootcamp Class-on-Demand or the CCVP Bootcamp Class-on-Demand between now and July 1st, you will receive this upgrade at no additional cost, and the downloadable version will be added to your account on July 1st.
Here ye, here ye, VTP experts. (We are not referring to the Vandenberg Test Program, although they are very likely experts in their field as well. )
Can you predict the results of a 3 switch VTP client/server scenario?
SW1-3, are connected, as shown in the diagram.
Here is the initial output of show VTP status, and show VLAN brief on each. Note that SW1 and SW3 are servers, while SW2 is a client. We will be adding a failure to the network in just a moment.
SW1#show vtp status
VTP Version : 2
Configuration Revision : 3
Maximum VLANs supported locally : 1005
Number of existing VLANs : 8
VTP Operating Mode : Server
VTP Domain Name : INE
VTP Pruning Mode : Disabled
VTP V2 Mode : Disabled
VTP Traps Generation : Disabled
MD5 digest : 0x2C 0x04 0x21 0x2B 0x10 0xFE 0x03 0x50
Configuration last modified by 0.0.0.0 at 3-1-93 00:05:40
Local updater ID is 0.0.0.0 (no valid interface found)
SW1#show vlan brief
VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
1 default active Fa0/1, Fa0/2, Fa0/3, Fa0/4
Fa0/5, Fa0/6, Fa0/7, Fa0/8
Fa0/9, Fa0/10, Fa0/11, Fa0/12
Fa0/13, Fa0/14, Fa0/15, Fa0/16
Fa0/17, Fa0/18, Fa0/19, Fa0/20
Fa0/21, Fa0/22, Fa0/23, Gig0/1
Gig0/2
2 VLAN0002 active
3 VLAN0003 active
4 VLAN0004 active
1002 fddi-default active
1003 token-ring-default active
1004 fddinet-default active
1005 trnet-default active
SW1#
SW2#show vtp status
VTP Version : 2
Configuration Revision : 3
Maximum VLANs supported locally : 1005
Number of existing VLANs : 8
VTP Operating Mode : Client
VTP Domain Name : INE
VTP Pruning Mode : Disabled
VTP V2 Mode : Disabled
VTP Traps Generation : Disabled
MD5 digest : 0x2C 0x04 0x21 0x2B 0x10 0xFE 0x03 0x50
Configuration last modified by 0.0.0.0 at 3-1-93 00:05:40
SW2#show vlan brief
VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
1 default active Fa0/2, Fa0/3, Fa0/4, Fa0/5
Fa0/6, Fa0/7, Fa0/8, Fa0/9
Fa0/10, Fa0/11, Fa0/12, Fa0/13
Fa0/14, Fa0/15, Fa0/16, Fa0/17
Fa0/18, Fa0/19, Fa0/20, Fa0/21
Fa0/22, Fa0/23, Gig0/1, Gig0/2
2 VLAN0002 active
3 VLAN0003 active
4 VLAN0004 active
1002 fddi-default active
1003 token-ring-default active
1004 fddinet-default active
1005 trnet-default active
SW2#
SW3#show vtp status
VTP Version : 2
Configuration Revision : 3
Maximum VLANs supported locally : 1005
Number of existing VLANs : 8
VTP Operating Mode : Server
VTP Domain Name : INE
VTP Pruning Mode : Disabled
VTP V2 Mode : Disabled
VTP Traps Generation : Disabled
MD5 digest : 0x2C 0x04 0x21 0x2B 0x10 0xFE 0x03 0x50
Configuration last modified by 0.0.0.0 at 3-1-93 00:05:40
Local updater ID is 0.0.0.0 (no valid interface found)
SW3#show vlan brief
VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
1 default active Fa0/2, Fa0/3, Fa0/4, Fa0/5
Fa0/6, Fa0/7, Fa0/8, Fa0/9
Fa0/10, Fa0/11, Fa0/12, Fa0/13
Fa0/14, Fa0/15, Fa0/16, Fa0/17
Fa0/18, Fa0/19, Fa0/20, Fa0/21
Fa0/22, Fa0/23, Fa0/24, Gig0/1
Gig0/2
2 VLAN0002 active
3 VLAN0003 active
4 VLAN0004 active
1002 fddi-default active
1003 token-ring-default active
1004 fddinet-default active
1005 trnet-default active
SW3#
So here is the scenario for the question. The Fa0/24 connection is suddenly broken between SW1 and SW2, and while that is down, a new VLAN (we will use 999) is created on SW3 like this:
SW3(config)#vlan 999
And then, a few minutes later, SW3 is completely powered off, shipped to another city, and removed completely from this network forever.
If we then restore the Fa0/24 connection between SW1 (the server) and SW2 (the client) what will happen to the VTP/VLAN information on the two switches? Will there be an update on either switch, will SW1 wait for a Server advertisement or will something else happen all together?
Take a moment, and let us know what you think.
Best wishes,
Keith
PS We’ll post the results as a after you have had some time to consider the results.
A few hours have passed, and we have had over 50 comments , ideas and theories.
I appreciate you taking the time to work through this. May your hard work pay off with a successful lab.
SW1, will see that its configuration revision number is lower than SW2, and even though SW2 is a “client” SW1 will use the updated information in the VTP advertisement from SW2 to update to its VLAN database, and get in “sync” with the rest of the VTP domain, including knowing about VLAN 999. The configuration revision number would also move to 4.
Here is SW1, after the connection to SW2 is restored:
SW1#show vtp status
VTP Version : 2
Configuration Revision : 4
Maximum VLANs supported locally : 1005
Number of existing VLANs : 9
VTP Operating Mode : Server
VTP Domain Name : INE
VTP Pruning Mode : Disabled
VTP V2 Mode : Disabled
VTP Traps Generation : Disabled
MD5 digest : 0x45 0x1D 0x6E 0xF0 0xB7 0xC2 0x84 0xFA
Configuration last modified by 0.0.0.0 at 3-1-93 00:11:43
Local updater ID is 0.0.0.0 (no valid interface found)
SW1#show vlan brief
VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
1 default active Fa0/1, Fa0/2, Fa0/3, Fa0/4
Fa0/5, Fa0/6, Fa0/7, Fa0/8
Fa0/9, Fa0/10, Fa0/11, Fa0/12
Fa0/13, Fa0/14, Fa0/15, Fa0/16
Fa0/17, Fa0/18, Fa0/19, Fa0/20
Fa0/21, Fa0/22, Fa0/23, Gig0/1
Gig0/2
2 VLAN0002 active
3 VLAN0003 active
4 VLAN0004 active
999 VLAN0999 active
1002 fddi-default active
1003 token-ring-default active
1004 fddinet-default active
1005 trnet-default active
SW1#
Here is SW2:
SW2#show vtp status
VTP Version : 2
Configuration Revision : 4
Maximum VLANs supported locally : 1005
Number of existing VLANs : 9
VTP Operating Mode : Client
VTP Domain Name : INE
VTP Pruning Mode : Disabled
VTP V2 Mode : Disabled
VTP Traps Generation : Disabled
MD5 digest : 0x45 0x1D 0x6E 0xF0 0xB7 0xC2 0x84 0xFA
Configuration last modified by 0.0.0.0 at 3-1-93 00:11:43
SW2#show vlan brief
VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
1 default active Fa0/1, Fa0/2, Fa0/3, Fa0/4
Fa0/5, Fa0/6, Fa0/7, Fa0/8
Fa0/9, Fa0/10, Fa0/11, Fa0/12
Fa0/13, Fa0/14, Fa0/15, Fa0/16
Fa0/17, Fa0/18, Fa0/19, Fa0/20
Fa0/21, Fa0/22, Fa0/23, Gig0/1
Gig0/2
2 VLAN0002 active
3 VLAN0003 active
4 VLAN0004 active
999 VLAN0999 active
1002 fddi-default active
1003 token-ring-default active
1004 fddinet-default active
1005 trnet-default active
SW2#
Thanks again everyone, and happy studies!
Keith
Sometimes its the simple things that are struggled with. RIP is one of those. Most CCIE candidates understand that we can change the interface or global parameters for updates, unicast, multicast, etc. What does take some time, is figuring out the global timers, especially if a person is not sure how they interact.
In this post, we will address the RIP process level timers for update, invalid, hold down and flush. I don’t want you to sleep during this, so we will save that one for later.
Timers Basic, all in seconds:
Update: how often to send updates in seconds
Invalid: how many seconds, since seeing a valid update, to consider the route invalid, and placing the route into hold down
Hold Down: Once in hold down, how long (in seconds) to “not believe” any equal or less impressive (worse) route updates for routes that are in hold down
Flush: how many seconds, since the last valid update, until we throw that route in the trash (garbage collection for un-loved non-updated routes)
Here is our topology. Keep your attention on R2, and that will be the focal point for this lesson.
Let’s set up some unique values, so we can see the results.
Defaults are:
Update: 30
Invalid: 180
Hold Down: 180
Flush: 240
We will use 30, 40, 10 and 90 respectively.
R2(config)#router rip R2(config-router)#timers basic 30 40 10 90
We can see the results of our changes with show ip protocols.
R2#show ip protocols
Routing Protocol is "rip"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Sending updates every 30 seconds, next due in 23 seconds
Invalid after 40 seconds, hold down 10, flushed after 90
Redistributing: rip
Default version control: send version 2, receive version 2
Interface Send Recv Triggered RIP Key-chain
FastEthernet0/0 2 2
FastEthernet0/1 2 2
Automatic network summarization is not in effect
Maximum path: 4
Routing for Networks:
10.0.0.0
Routing Information Sources:
Gateway Distance Last Update
10.23.0.3 120 00:00:03
Distance: (default is 120)
We can see that R2 is learning 2 routes from R3, the 10.33.0.0/24 and 10.77.0.0/24 R2 received the last update 7 seconds ago, based on the output.
R2#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
10.0.0.0/24 is subnetted, 4 subnets
C 10.12.0.0 is directly connected, FastEthernet0/1
C 10.23.0.0 is directly connected, FastEthernet0/0
R 10.34.0.0 [120/1] via 10.23.0.3, 00:00:07, FastEthernet0/0
R 10.77.0.0 [120/8] via 10.23.0.3, 00:00:07, FastEthernet0/0
Let’s enable debugging so we can see the play by play.
R2#debug ip routing IP routing debugging is on R2#debug ip rip RIP protocol debugging is on
Here is an update from R3. Notice the time stamp of 1:24:23. This will be the last one sent from R3. (Because we’ll configure R3 to go passive in a moment). Also, notice that we are sending and update as well. An update schedule of 30 seconds, based on the RFC for RIP, may be 30 seconds, + or – 5 seconds, to avoid synchronization. Let’s focus on the learned 10.77.0.0 network with a hop count of 8.
R2# 01:24:23: RIP: received v2 update from 10.23.0.3 on FastEthernet0/0 01:24:23: 10.34.0.0/24 via 0.0.0.0 in 1 hops 01:24:23: 10.77.0.0/24 via 0.0.0.0 in 8 hops R2# 01:24:24: RIP: sending v2 update to 224.0.0.9 via FastEthernet0/1 (10.12.0.2) 01:24:24: RIP: build update entries 01:24:24: 10.23.0.0/24 via 0.0.0.0, metric 1, tag 0 01:24:24: 10.34.0.0/24 via 0.0.0.0, metric 2, tag 0 01:24:24: 10.77.0.0/24 via 0.0.0.0, metric 9, tag 0 R2# 01:24:27: RIP: sending v2 update to 224.0.0.9 via FastEthernet0/0 (10.23.0.2) 01:24:27: RIP: build update entries 01:24:27: 10.12.0.0/24 via 0.0.0.0, metric 1, tag 0
After the update from R3, learned on Fa0/0, I used the passive-interface default command on R3 inside of the router rip process. While we wait for the invalid time to occur, due to the missing routes, we can entertain ourselves by seeing updates being sent from R2, at 30 second intervals.
R2# 01:24:53: RIP: sending v2 update to 224.0.0.9 via FastEthernet0/1 (10.12.0.2) 01:24:53: RIP: build update entries 01:24:53: 10.23.0.0/24 via 0.0.0.0, metric 1, tag 0 01:24:53: 10.34.0.0/24 via 0.0.0.0, metric 2, tag 0 01:24:53: 10.77.0.0/24 via 0.0.0.0, metric 9, tag 0 R2# 01:24:56: RIP: sending v2 update to 224.0.0.9 via FastEthernet0/0 (10.23.0.2) 01:24:56: RIP: build update entries 01:24:56: 10.12.0.0/24 via 0.0.0.0, metric 1, tag 0
It has been 40 seconds since the last updates from R3, and 40 seconds was our invalid timer setting. (Our last update was 1:24:23, and now it is 1:25:03). The routes enter hold down, which means the router will not believe any new updates regarding these routes. Hold down is intended to assist in avoiding inaccurate routing by rumor information while the network converges. The exception would be if a route with a better (lower) metric was received by R2 for the 10.77.0.0, R2 would use it. (In our example, 10.77.0.0 had a metric of 8. If R2 learned about the 10.77.0.0 with a metric of 7 or lower from a neighbor, it would use it if learned during the hold down.)
R2# 01:25:03: RT: delete route to 10.34.0.0 via 10.23.0.3, rip metric [120/1] 01:25:03: RT: no routes to 10.34.0.0, entering holddown 01:25:03: RT: NET-RED 10.34.0.0/24 01:25:03: RT: delete route to 10.77.0.0 via 10.23.0.3, rip metric [120/8] 01:25:03: RT: no routes to 10.77.0.0, entering holddown 01:25:03: RT: NET-RED 10.77.0.0/24
R2 advertises a poisoned route for the networks in hold down. This is a triggered update, and not based on the normal 30 second update timer.
R2# 01:25:05: RIP: sending v2 flash update to 224.0.0.9 via FastEthernet0/0 (10.23.0.2) 01:25:05: RIP: build flash update entries 01:25:05: 10.34.0.0/24 via 0.0.0.0, metric 16, tag 0 01:25:05: 10.77.0.0/24 via 0.0.0.0, metric 16, tag 0 01:25:05: RIP: sending v2 flash update to 224.0.0.9 via FastEthernet0/1 (10.12.0.2) 01:25:05: RIP: build flash update entries 01:25:05: 10.34.0.0/24 via 0.0.0.0, metric 16, tag 0 01:25:06: 10.77.0.0/24 via 0.0.0.0, metric 16, tag 0
R1, sends us a poison-reverse update, regarding the same networks. This intentionally overrides the split horizon rule which is in place on Ethernet interfaces by default.
R2# 01:25:08: RIP: received v2 update from 10.12.0.1 on FastEthernet0/1 01:25:08: 10.34.0.0/24 via 0.0.0.0 in 16 hops (inaccessible) 01:25:08: 10.77.0.0/24 via 0.0.0.0 in 16 hops (inaccessible) R2# 01:25:10: RIP: received v2 update from 10.12.0.1 on FastEthernet0/1 01:25:10: 10.34.0.0/24 via 0.0.0.0 in 16 hops (inaccessible) 01:25:10: 10.77.0.0/24 via 0.0.0.0 in 16 hops (inaccessible)
Another normal update, being sent by R2, including the poisoned routes.
R2# 01:25:22: RIP: sending v2 update to 224.0.0.9 via FastEthernet0/1 (10.12.0.2) 01:25:22: RIP: build update entries 01:25:22: 10.23.0.0/24 via 0.0.0.0, metric 1, tag 0 01:25:22: 10.34.0.0/24 via 0.0.0.0, metric 16, tag 0 01:25:22: 10.77.0.0/24 via 0.0.0.0, metric 16, tag 0 01:25:22: RIP: sending v2 update to 224.0.0.9 via FastEthernet0/0 (10.23.0.2) 01:25:22: RIP: build update entries 01:25:22: 10.12.0.0/24 via 0.0.0.0, metric 1, tag 0 01:25:22: 10.34.0.0/24 via 0.0.0.0, metric 16, tag 0 01:25:22: 10.77.0.0/24 via 0.0.0.0, metric 16, tag 0
While the routes are in hold down, the router still forwards packets to those networks, based on the last information that it last learned about how to reach those networks. The routes will show up as “possibly down”.
R2#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
10.0.0.0/24 is subnetted, 4 subnets
C 10.12.0.0 is directly connected, FastEthernet0/1
C 10.23.0.0 is directly connected, FastEthernet0/0
R 10.34.0.0/24 is possibly down,
routing via 10.23.0.3, FastEthernet0/0
R 10.77.0.0/24 is possibly down,
routing via 10.23.0.3, FastEthernet0/0
So were is the removal of the hold down. The timer was only 10 seconds? Better late than never. Even though the hold down timer was set to 10 seconds, the hold down timer has to expire and then the next poisoned route received causes the routes to be removed from hold down. Our routes went into hold down at 25:03, it is now 25:36. Regardless of the hold down timer setting, if we didn’t receive any poisoned updates from neighbors, the hold down would stay until the flush timer removes the route completely.
R2# 01:25:36: RIP: received v2 update from 10.12.0.1 on FastEthernet0/1 01:25:36: 10.34.0.0/24 via 0.0.0.0 in 16 hops (inaccessible) 01:25:36: RT: 10.34.0.0 came out of holddown 01:25:36: 10.77.0.0/24 via 0.0.0.0 in 16 hops (inaccessible) 01:25:36: RT: 10.77.0.0 came out of holddown
Even though the routes are done with their hold down, R2 still will show the route as possibly down, and will continue to do so until the flush timer expires.
R2#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
10.0.0.0/24 is subnetted, 4 subnets
C 10.12.0.0 is directly connected, FastEthernet0/1
C 10.23.0.0 is directly connected, FastEthernet0/0
R 10.34.0.0/24 is possibly down,
routing via 10.23.0.3, FastEthernet0/0
R 10.77.0.0/24 is possibly down,
routing via 10.23.0.3, FastEthernet0/0
Another update clicks off, and then we approach the 90 second flush timer
R2# 01:25:49: RIP: sending v2 update to 224.0.0.9 via FastEthernet0/1 (10.12.0.2) 01:25:49: RIP: build update entries 01:25:49: 10.23.0.0/24 via 0.0.0.0, metric 1, tag 0 01:25:49: 10.34.0.0/24 via 0.0.0.0, metric 16, tag 0 01:25:49: 10.77.0.0/24 via 0.0.0.0, metric 16, tag 0 01:25:49: RIP: sending v2 update to 224.0.0.9 via FastEthernet0/0 (10.23.0.2) 01:25:49: RIP: build update entries 01:25:49: 10.12.0.0/24 via 0.0.0.0, metric 1, tag 0 01:25:49: 10.34.0.0/24 via 0.0.0.0, metric 16, tag 0 01:25:49: 10.77.0.0/24 via 0.0.0.0, metric 16, tag 0
Based on the last valid update of 1:24:23, and now that it is 1:25:53, 90 seconds are up (flush timer) and the routes are deleted.
R2# 01:25:53: RT: delete subnet route to 10.34.0.0/24 01:25:53: RT: NET-RED 10.34.0.0/24 01:25:53: RT: delete subnet route to 10.77.0.0/24 01:25:53: RT: NET-RED 10.77.0.0/24
Now the routes don’t show up in the routing table either.
R2# show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
10.0.0.0/24 is subnetted, 2 subnets
C 10.12.0.0 is directly connected, FastEthernet0/1
C 10.23.0.0 is directly connected, FastEthernet0/0
If we use context sensitive help, we find one more parameter for the timers:
R2(config-router)#timers basic 30 40 10 90 ? <1-4294967295> Sleep time, in milliseconds
And we’ll save that one for another blog.
Best wishes,
Keith
