So here is a general summary of RIP.

• All RIP messages are encapsulated in a UDP segment with the source and destination port of 520.

•  The metric that is used by RIP is hop count. A hop count of 1 is a directly connected network. A hop count of 16 is defined as unreachable.  A hop count metric simply counts the am0unt of router hops that is required to reach a network.

• RIP has an administrative distance of 120.

• RIP employs split horizon with poison reverse.  Split horizon is a feature for preventing routing loops in networks. It basically tells the router that when sending updates out of an interface, do not include any networks that were learned from updates received on that same interface. Poison reverse adds an additional feature. When sending updates out of an interface, for any updates learned on that interface the router now marks those networks as unreachable. It’s neighboring router now has positive confirmation that these networks cannot be reached via this source.

RIP Timers

Update Timer

A RIP router sends its entire routing table to its neighbours at regular intervals. This interval is defined using the update timer and by default is set at 30 seconds. The router, however, adds a random variable to the timer to stop the routers’ updates becoming synchronised to each other. A router’s regular update will therefore be between 25 and 35 seconds.

Invalid Timer

The invalid timer is set to 180 seconds whenever a new route is learnt. The timer is reset each time the router receives a update containing that route. If no update is received for a route already in the routing table within 180 seconds, the hop count for that route is changed to 16 (unreachable)

Flush Timer

The flush timer is set at 240 seconds by default. A route marked as unreachable will continue to be advertised by the router until the flush timer has expired. After this time it will be completely removed from the routing table.

Holddown Timer

If a router receives an update that either has a higher or unreachable metric for an active route in the routing table, it will start the holddown timer. The new, less preferred, route entry will not be placed in the table until the holddown timer expires. For RIP the default for the holddown timer is 180 seconds.

RIP Message Format

The RIP protocol defines two RIP message types:

• Request message – used to ask neighbouring routers to send updates
• Response message – carries the updates 

• Each message can contain up to 25 route entires.

• Each entry will contain an Address Family Identifier, the IP address of the route and the metric.

• Command – if set to 1 the message is Request. If set to 2 the message is a Response.

• Addrress Familiy Identifier – is set to 2 for IP.

• Metric – the hop count between 1 and 16.

I hope you will find this article a decent quick study guide about the basic theory of RIP. I hope to do an article at some point on the configuration of RIP.

I thought it would be good to have the CoD available while studying for the written exam as an additional reference .  The other list of learning materials I plan to use are:

• Routing TCP/IP Volume I and II by Jeff Doyle  and Jennifer Carroll (absolutley essential reading for CCIE candidates)
• Relevant parts of LAN Switching by Kennedy Clark and Kevin Hamilton
• CCNP Multilayer Switching Companion Guide by Wayne Lewis
• MPLS Fundamentals by Luc De Ghein
• Cisco QoS Exam Guide by Wendell Odom and Michael J. Cavanaugh
• CCIE Routing and Switching Official Exam Certification Guide by Wendell Odom, Jim Geir and Naren Mehta (this is currently for the 3.0 track as there is currently no 4.0 book available)
• CBT Nugget courses that I purchased for the CCNP
• Cisco Networking Academy Alumini course for CCNP
• Cisco online resources
• Cisco Documentation CD

For the written exam I’ve started off by downloading the R&S 4.0 Written Exam Topics. I plan to study every part of the exam topics, only ticking a part off when I am happy that I fully understand that section. I have decided to renew my CCNP BCSI module on the way, and so I plan to study the routing sections from the topics first. For the first week or so I’m going to go back to basics and study the following topics:

• Format of an IPv4 packet header
• Format of TCP and UDP packet headers
• ICMP format
• IPv4 addressing
• Subnetting and VLSMs

I have not set myself a concrete deadline for completing my study for the written exam. although I would like to have have passed by the end of this year. If anyone would like to add any more useful resources to my list then please let me know and I’ll publish them.

• Cisco Certified Architect
• CCNP Wireless
• DC Unified Computing Design Specialist
• DC Unified Computing Support Specialist

One of my colleagues was able to access two of the core data centre switches but I could only get to one. A very quick trip to the data centre floor and a console cable connection into the core data centre switches revealed the issue.

The two switches in question (Catalyst 4507s) have a 2 x 1Gb EtherChannel configured on either end, connected by fibre connections. One side of the connection reported that both links were active in the Etherchannel. The other side had one link as down and the logs showing that the connection had left the EtherChannel.

The full reason for this is still unknown but this type of issue, where one side sees the link as up but the other sees it as down, is called a unidrectional failure. To solve the matter at hand, we first of all shut down the faulty link at the end that still had the link up. As soon as this was done everything sprung into life and everyone was able to connect to the data centre hosts. While the link was down we quickly swapped out the GBic cards and brought the connection backup. The link joined back into the EtherChannel and everything was back as it should be.

This highlighted an issue with the Etherchannel configuration on these particular switches however. Here is a look at the configuration of one of the Etherchannel interfaces as it stood at that time.

interface GigabitEthernet1/1
description ** link to xxxxxx **
switchport trunk encapsulation dot1q
switchport trunk allowed vlan x,xx,xx,xx-xx,xx-xx,xx
switchport mode trunk
qos trust dscp
channel-group 1 mode on

I have always advised network engineers to use a mode of desirable on either side of an  Etherchannel connection, rather than forcing the Etherchannel up.  The on mode forces a port to join an Etherchannel without any sort of Etherchannel protocol negotiation taking place. Using the desirable keyword instead of the on keyword means that the switch uses the Port Aggregation Protocol (PAgP). When using PAgP the switch learns of partner interfaces on other switches that support PAgP and dynamically groups its interfaces into an Etherchannel. Lets look at an example. I’ve set up two Cisco Catalyst 3550s back to back connecting ports 13 and 14 off each switch together.

Here is the configuration of the ports on either end of the connection.

interface FastEthernet0/13
switchport trunk encapsulation dot1q
switchport mode trunk
channel-group 1 mode desirable
!
interface FastEthernet0/14
switchport trunk encapsulation dot1q
switchport mode trunk
channel-group 1 mode desirable

Once the port channel group on the first configured interface the IOS automatically creates the port channel interafce.

interface Port-channel1
switchport trunk encapsulation dot1q
switchport mode trunk

If the same configuration is applied at both ends then the PAgP protocol will dynamically place each relevant interface into the Etherchannel.

Here is the output of the show etherchannel summary command from SW1

SW1#show etherchannel summary
Flags:  D – down        P – in port-channel
I – stand-alone s – suspended
H – Hot-standby (LACP only)
R – Layer3      S – Layer2
U – in use      f – failed to allocate aggregator
u – unsuitable for bundling
w – waiting to be aggregated
d – default port
Number of channel-groups in use: 1
Number of aggregators:           1

Group  Port-channel  Protocol    Ports
——+————-+———–+———————————————–
1      Po1(SU)         PAgP      Fa0/13(P)   Fa0/14(P)

Lets see what happens if I change port fas0/14 on SW2, removing it from the channel and thus stopping PAgP.

SW2(config-if)#no channel-group 1
SW2(config-if)#do show etherchannel summ
Flags:  D – down        P – in port-channel
I – stand-alone s – suspended
H – Hot-standby (LACP only)
R – Layer3      S – Layer2
U – in use      f – failed to allocate aggregator
u – unsuitable for bundling
w – waiting to be aggregated
d – default port
Number of channel-groups in use: 1
Number of aggregators:           1

Group  Port-channel  Protocol    Ports
——+————-+———–+———————————————–
1      Po1(SU)         PAgP      Fa0/13(P)

On SW1 both fas0/13 and 14 are still configured as part of port channel 1. But as PAgP is used, SW1 drops port14 from the group when it stops seeing PAgP.

SW1#sh etherchannel summ
Flags:  D – down        P – in port-channel
I – stand-alone s – suspended
H – Hot-standby (LACP only)
R – Layer3      S – Layer2
U – in use      f – failed to allocate aggregator
u – unsuitable for bundling
w – waiting to be aggregated
d – default port
Number of channel-groups in use: 1
Number of aggregators:           1

Group  Port-channel  Protocol    Ports
——+————-+———–+———————————————–
1      Po1(SU)         PAgP      Fa0/13(P)   Fa0/14(I)

Port fas0/14 is now operating as a stand-alone port and is now a seperate trunk between the switches.

SW1#sh int trunk

Port        Mode         Encapsulation  Status        Native vlan
Fa0/14      on           802.1q         trunking      1
Po1         on           802.1q         trunking      1

SW2#sh int trunk

Port        Mode         Encapsulation  Status        Native vlan
Fa0/14      on           802.1q         trunking      1
Po1         on           802.1q         trunking      1

In the data centre situation I described above this would have dropped the offending interfaces from the etherchannel as one side would have stopped seeing PAgP. However, it may have been possible for one switch to move the interface into stand-alone mode and pass traffic across a broken link, as it was still seeing this link as up. In order to help in situations like these Cisco developed the Unidirectional Link Dection protocol.

UDLD can now be configured in aggressive mode from IOS Release 12.1(3a)E.  Cisco describe aggressive mode as follows:

” Configure UDLD aggressive mode only on point-to-point links between network devices that support UDLD aggressive mode. With UDLD aggressive mode enabled, when a port on a bidirectional link that has a UDLD neighbor relationship established stops receiving UDLD packets, UDLD tries to reestablish the connection with the neighbor. After eight failed retries, the port is disabled.

To prevent spanning tree loops, nonaggressive UDLD with the default interval of 15 seconds is fast enough to shut down a unidirectional link before a blocking port transitions to the forwarding state (with default spanning tree parameters).

When you enable UDLD aggressive mode, you receive additional benefits in the following situations:

•One side of a link has a port stuck (both Tx and Rx)

•One side of a link remains up while the other side of the link has gone down

In these cases, UDLD aggressive mode disables one of the ports on the link, which prevents traffic from being discarding. “

I use aggressive mode when available. Configuration is simple. To configure non-aggressive udld you would enter the following command.

SW2(config)#int fas0/13
SW2(config-if)#udld port

To configure aggressive mode only one more keyword is required

SW2(config-if)#int fas0/14
SW2(config-if)#udld port aggressive

Using the show udld command you can check to make sure that udld is running as desired.

SW2#sh udld

Interface Fa0/13
—
Port enable administrative configuration setting: Enabled / in aggressive mode
Port enable operational state: Enabled / in aggressive mode
Current bidirectional state: Bidirectional
Current operational state: Advertisement – Single neighbor detected
Message interval: 7
Time out interval: 5

Entry 1
—
Expiration time: 44
Cache Device index: 1
Current neighbor state: Bidirectional
Device ID: CAT0640X09Y
Port ID: Fa0/13
Neighbor echo 1 device: CAT0825X28N
Neighbor echo 1 port: Fa0/13

Message interval: 15
Time out interval: 5
CDP Device name: SW1

Interface Fa0/14
—
Port enable administrative configuration setting: Enabled / in aggressive mode
Port enable operational state: Enabled / in aggressive mode
Current bidirectional state: Bidirectional
Current operational state: Advertisement – Single neighbor detected
Message interval: 15
Time out interval: 5

Entry 1
—
Expiration time: 33
Cache Device index: 1
Current neighbor state: Bidirectional
Device ID: CAT0640X09Y
Port ID: Fa0/14
Neighbor echo 1 device: CAT0825X28N
Neighbor echo 1 port: Fa0/14

Message interval: 15
No timeout interval
No CDP device name

The final configuration of the ports on either end looks like this:

interface FastEthernet0/13
switchport trunk encapsulation dot1q
switchport mode trunk
udld port aggressive
channel-group 1 mode desirable
!
interface FastEthernet0/14
switchport trunk encapsulation dot1q
switchport mode trunk
udld port aggressive
channel-group 1 mode desirable

Etherchannels are wonderful things and in the most part run without any hitches. However, I think that running some sort of protocol to help dynamically manage the participating interfaces and using UDLD to monitor for unidirectional failures is a good safeguard from situations such as the one described above.

As well as the introduction of some new topics such as MPLS VPNs, zone based firewalls and new IPv6 topics, the changes also include new lab equipment and a new lab format. The CCIE lab will now feature 1841 and 3825 ISRs running the newer 12.4T IOS and there will only be 3560-E switches in the rack.

The lab exam will still be done over a total of 8 hours. However the lab now has two completely seperate sections. There wil be a two hour troubleshooting section, followed by a six hour configuration lab.

The written exam will also change and it may well contain simulation questions.

The Internetwork Expert blog has a good overview of the changes and also has a breakdown of how their materials will change to match the new exams.

ipexpert today put out a press release announcing it will be the first training company to offer materials for version 3.0 of the Voice track of the CCIE.

Many of my CCIE chums have used their training materials when studying towards their CCIE certification and they come highly recommended. I will certainly be looking at their Routing and Switching resources when I embark on the lab part of the CCIE.

• dir
• cd
• copy
• verify
• fsck

The video post also contains a link to a corresponding article by David Davis that covers each of the commands in a little more detail.

Cisco have just announced the opening of new a online store focussed on providing learning materials for it’s certifications. The Cisco Learning Network Store is still in it’s early days and courses are still thin on the ground at present, but it already contains a few e-learning packages and some software tools for learning.

Let’s hope that as time goes on the cataolgue increases. More official Cisco e-learning courses would be a welcome addition to the currently  available learning resources.

For interest to CCIE candidates is the Cisco 360 Learning Program for CCIE R&S students. Cisco describe the course as follows.

“The Cisco 360 Learning Program: Essentials for CCIE R&S with Mentoring is a suite of e-learning products, authorized by Cisco, that includes an one-year subscription of the Cisco 360 CCIE R&S Lessons on Demand, four independent graded assessment labs, a learner technical reference library, a practice lab exercise workbook, and curriculum-planning services delivered by an authorized Cisco 360 Learning Program Partner.”

At a wopping $5999.00 I doubt there will be a rush to take up this program, especially when there are many proven CCIE learning materials that are already on the block from the likes of IP Expert, Internetwork Expert and NetMaster Class.

If you purchase any of the materials please feel free to give us your feedback on them.