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.

I’d say its possible to do around 80% of the CCVP without any hardware purchase, the other 20% being to do with voice port modules, such as FXO modules, FXS modules, DSP modules and also areas such as MGCP voice gateways. If you do want to get hands on practice in those areas you coud purchase a second hand router that can handle these modules and also act as an MGCP gateway. In my voice lab, I’ve used an old Cisco 3640 router for this purpose. To support the FXO and FXS modules I had to purchase a NM-2V module for the router. The FXO and FXS cards then slot into the NM-2V. I’ll supply a full breakdown of the hardware I’ve used in a later post.

To build the software only part of the lab you are going to need the following:

• A PC with a decent up to date processor. I’d recommend having at least 2Gig of RAM. However you may be able to get away with less. My PC specs are Intel Quad Core Q9450 overclocked to 3Ghz, 4Gig RAM and Vista Home Premium. I have also set up this sort of lab using Ubuntu Linux.
• A copy of Cisco Unified Communications Manager (search on ebay for Cisco Call Manager). There are sellers selling legitimate copies. I paid around £60 for the discs.
• VMware Server 
• GNS3. You could use dynampis/dynagen if you are familiar with the software. However, I find the speed and ease with which you can now set up labs with GNS3 makes it much more useable.
• A copy of a relevant IOS for a Cisco 3725 router. I would recommend getting an IOS that can support a version of Call Manager Express. That way you can get some practice setting up H323 trunks. You can even use a H323 gateway to simulate being your PSTN router. One other benefit is that you can practice CME SRST fallback. Getting an IOS can be a stumbling block for many people and unfortunately I can’t help you there. Please remember that the Cisco IOS is a licensed proprietry piece of software. If you have an appropriate CCO login you should be able to download an IOS to use.
• A copy of Cisco IP Communicator. This is a software phone that you use to register with your CUCM servers and CME routers. Again this is available to download from Cisco if you have an appropriate CCO account.
• I also recommend buying a second-hand hardware Cisco phone as its good to learn how to support the sort of phone that your users will be using. I managed to gt a Cisco 7940 from ebay for about £35 including shipping.

Installing VMare

I am currently using version 1.0.6 on a Windows Vista PC, so my instructions will pertain to that version of VMWare Server. The latest version of VMWare Server is currently 2.0.1 and this should also be fine for running a CUCM server installation.

First of all go to the download section of the VMWare site and download the version of VMWare for your OS. As part of the download process you will have to obtain a serial number. Please take a note of this serial number.

After the installation of VMWare is complete you will need to set up a virtual machine with the correct settings to support a CUCM6.0 server. The specifications for this are:

• Red Hat Enterprise Linux 3 virtual OS
• I used bridge networking so that I could give the CUCM server an address on my home LAN.
• 80Gb disk capactiy. I know this seems a lot but CUCM will only install if the disk is at least 72Gb
• 1GB of RAM, although I tried 512Mb and this seemed to work ok.

Once you have the virtual machine set up then just place your CUCM DVDs in your DVD  tray and boot up the machine. Alternatively, you can use an ISO image and use that to boot from. You can do this by editing the CD ROM settings of your virtual machine.

You should hopefully now hear the wirring noise of your DVD loading and, after seeing some Linuxy type boot messages, you should be presented with the CUCM 6 installation. You should now be able to run through the installation wizard and install CUCM 6.0

There is an excellent post  by Josh on the blindhog site with a video showing a step by step guide on setting up CUMC 6 using VMWare. It even takes you through the CUCM 6 installation wizard. In fact the inspiration for my lab came from doing some reasearch on building a home voice lab and coming across another brilliant post from Josh. This post should give you a good idea of just what is possible using GNS3, VMWare and some hardware.

In the next part of this article I’ll detail how to set up GNS3 and interface this with your physical network and CUCM server.

What I didn’t expect was to be called out to a site where the comms room did have air con but the air con had been put up to 29C. After picking myself up off the floor after opening the door to the room, I turned the air con down to an acceptable level and rebooted the two switches that had clearly overheated due to the environmental conditions.

The moral of the story is to please check your air con on a regular basis and wear a jumper in the comms room if you get cold. Now where did I put those Bermuda Shorts?

• 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.

In the meantime I have my final CCVP exam on Tuesday the 16th of June. It’s the Troubleshooting Unified Communications exam. Fingers crossed. I’m desperate now to get the CCVP out the way so that I can concentrate on the big one (gulp).

I then went on a weeks holiday to Rhodes in Greece to relax for a bit and I highly recommend the place to anyone in Europe looking for a nice break.

There will be a couple of new posts on the way soon. One about an incident I helped out with involving Etherchannels, the other the first instalment of setting up a CCVP Voice lab. In the meantime I’ve started studying for my last CCVP exam which is the Troubleshooting Unified Communcations (TUC) exam.

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.