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

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.

It’s the first time I’ve used this particular module but setting it up as an MGCP gateway is no different from setting up any other MGCP gateway. First of all to access the CMM module you use the session command from enable mode.

6509#session slot 8 processor 0
The default escape character is Ctrl-^, then x.
You can also type 'exit' at the remote prompt to end the session
Trying 127.0.0.80 ... Open

6509-VGW-CMM>en
6509-VGW-CMM#

The voice module is configured through IOS commands just the same as any other Cisco voice modules or cards. However, in this particular setup the endpoint configuration is controlled via Call Manager via MGCP.

To set up the CMM as an MGCP gateway to be controlled by Call Manager you need to issue the two following commands:

ccm-manager config server call_manager_ip_address
ccm-manager config

You can now add this gateway into Call Manager and start configuring the endpoints (or E1 ports) on the device from there. It’s a fairly straightfoward excercise. Just make sure you use the same name in the Call Manager configuration as you have given your gateway.

To add the Gateway in Call Manager select Device > Gateway from the main menu. You should be presented with the Add a New Gateway configuration screen below. On this screen select Communications Media Module as the Gateway type and MGCP as the Device Protocol.

Click on the Next button and you should be presented with the Communications Media Module configuration page.  In the Domain Name field enter the hostname of the CMM module.

Select the WS-X660 for Module one and then select your particular sort of CMM. For our purposes we are using the WS-SVC-CMM-6E1.  After doing this the six E1 endpoints should appear in the configuration and be available for your to configure.

Here is a copy of the full Communications Media Module configuration once the E1 ports have been configured in Call Manager.

version 12.4
no service pad
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname CMM
!
boot-start-marker
boot-end-marker
!
logging buffered 4096 debugging
!
no aaa new-model
!
resource policy
  policy transcode global
   system
   !
  !
!
clock summer-time bst recurring
mmi polling-interval 60
no mmi auto-configure
no mmi pvc
mmi snmp-timeout 180
!
!
ip cef
no ip domain lookup
!
isdn switch-type primary-net5
!
voice call send-alert
voice call convert-discpi-to-prog
voice rtp send-recv
voice dsp release early
!
voice service voip
!
!
!
!
!
!
!
!
!
!
!
!
call-history-mib retain-timer 500
call-history-mib max-size 500
!
!
controller E1 1/0
 clock source line secondary 5
 pri-group timeslots 1-31 service mgcp
!
controller E1 1/1
 clock source internal
 pri-group timeslots 1-31 service mgcp
!
controller E1 1/2
 clock source line primary
 pri-group timeslots 1-31 service mgcp
!
controller E1 1/3
 clock source line secondary 1
 pri-group timeslots 1-31 service mgcp
!
controller E1 1/4
 clock source line secondary 2
 pri-group timeslots 1-31 service mgcp
!
controller E1 1/5
 clock source line secondary 3
 pri-group timeslots 1-31 service mgcp
!
!
!
!
interface GigabitEthernet1/0
 ip address 10.xxx.xxx.xxx 255.255.255.248
 no ip proxy-arp
 no negotiation auto
 no keepalive
!
interface Serial1/0:15
 no ip address
 encapsulation hdlc
 no logging event link-status
 isdn switch-type primary-qsig
 isdn timer T310 120000
 isdn overlap-receiving
 isdn protocol-emulate network
 isdn incoming-voice voice
 isdn bind-l3 ccm-manager
 no cdp enable
!
interface Serial1/1:15
 no ip address
 encapsulation hdlc
 no logging event link-status
 isdn switch-type primary-qsig
 isdn timer T310 120000
 isdn overlap-receiving
 isdn protocol-emulate network
 isdn incoming-voice voice
 isdn bind-l3 ccm-manager
 no cdp enable
!
interface Serial1/2:15
 no ip address
 encapsulation hdlc
 no logging event link-status
 isdn switch-type primary-net5
 isdn incoming-voice voice
 isdn bind-l3 ccm-manager
 no cdp enable
!
interface Serial1/3:15
 no ip address
 encapsulation hdlc
 no logging event link-status
 isdn switch-type primary-net5
 isdn incoming-voice voice
 isdn bind-l3 ccm-manager
 no cdp enable
!
interface Serial1/4:15
 no ip address
 encapsulation hdlc
 no logging event link-status
 isdn switch-type primary-net5
 isdn incoming-voice voice
 isdn bind-l3 ccm-manager
 no cdp enable
!
interface Serial1/5:15
 no ip address
 encapsulation hdlc
 no logging event link-status
 isdn switch-type primary-net5
 isdn incoming-voice voice
 isdn bind-l3 ccm-manager
 no cdp enable
!
interface FastEthernet3/0
 no ip address
 no ip proxy-arp
 shutdown
 full-duplex
!
ip forward-protocol nd
ip route 0.0.0.0 0.0.0.0 GigabitEthernet1/0
!
no ip http server
no ip http secure-server
!
access-list 1 permit 10.xxx.xxx.xxx
snmp-server community ?????????? RO 1
!
control-plane
!
!
voice-port 1/0:15
 cptone GB
!
voice-port 1/1:15
 cptone GB
!
voice-port 1/2:15
 cptone GB
!
voice-port 1/3:15
 cptone GB
!
voice-port 1/4:15
 cptone GB
!
voice-port 1/5:15
 cptone GB
!
ccm-manager redundant-host 10.xxx.xxx.xxx
ccm-manager mgcp
ccm-manager music-on-hold
ccm-manager config server 10.xxx.xxx.xxx 10.xxx.xxx.xxx
ccm-manager config
!
mgcp
mgcp call-agent 10.xxx.xxx.xxx 2427 service-type mgcp version 0.1
mgcp dtmf-relay voip codec all mode out-of-band
mgcp rtp unreachable timeout 1000 action notify
mgcp modem passthrough voip mode nse
mgcp package-capability rtp-package
mgcp package-capability sst-package
mgcp package-capability pre-package
no mgcp package-capability res-package
no mgcp timer receive-rtcp
mgcp sdp simple
mgcp rtp payload-type g726r16 static
!
mgcp profile default
!
mediacard 4
 resource-pool trans dsps 1
 resource-pool transcode dsps 2
!
!
sccp local GigabitEthernet1/0
sccp ccm 10.xxx.xxx.xxx identifier 1 version 4.1
sccp ip precedence 1
sccp
!
sccp ccm group 3
 bind interface GigabitEthernet1/0
 associate ccm 1 priority 1
 associate profile 100 register M08ABC123456789
!
dspfarm
!
dspfarm profile 100 transcode
 rtp timeout 7200
 codec g711ulaw packetization-period 30
 codec g711alaw packetization-period 10
 codec g729r8 packetization-period 30
 codec g729ar8 packetization-period 10
 codec g723r63 packetization-period 30
 codec g723r53 packetization-period 30
 associate resource-pool 100
!

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

I was recently asked by a client to help troubleshoot an issue they were having after upgrading the IOS on two of their core Cisco Catalyst 6509s. The two switches are connected together by three 1Gb fibre links that run about 500m between two buildings (Building A and B). Two of the links are bundled together in an 802.1q Etherchannel. Only one vlan, 100, is allowed to cross the link and this vlan is used purely for traffic to and from a cluster of Call Manager 4 servers. The other link is a 1Gb layer 3 fibre link that is used for any other user traffic across the core switches.

Network Layout

The 6509s also have links to other core switches within the network, so if the layer 3 link goes down traffic should be routed through these other switches.

After the IOS upgrades took place users at Building B had reported that access to a server at Building A was slow or dropping out. The Layer 3 link was up with no errros reported and to the client everything looked fine.

After looking at the routing between both locations I discovered that the traffic was crossing the layer 2 etherchannel passing through the vlan 100 interfaces of both switches. The way the switches were configured, this route was the optimal path for traffic to flow through, although my client was adamant that this had not been the case before. To OSPF, the interior gateway protocol that was used, this path had the lowest cost (due to the higher available bandwidth), and so this path was chosen.

Building A Switch

interface Vlan100
description ** IPTVoice_Server_Vlan **
ip address 10.100.10.3 255.255.255.192
no ip redirects
ip route-cache flow
standby 99 ip 10.100.10.1
standby 99 preempt

router ospf 1
!
network 10.100.10.0 0.0.0.63 area 17

Building B Switch

interface Vlan100
description ** IPT/IPCC Voice_Server_Vlan1 **
ip address 10.100.10.2 255.255.255.192
no ip redirects
standby 99 ip 10.100.10.1
standby 99 priority 105
standby 99 preempt

router ospf 1
!
network 10.100.10.0 0.0.0.63 area 17

Another closer look showed that one of the interfaces of the Etherchannel on the Building A switch was showing a high amount of errors.  Replacing the fibre patch cable soon sorted the issue and users started reporting that all was well again with their connection to the server.

This, however, did not solve the mystery of user traffic suddenly passing over the Voice Server Vlan. A quick download of some archived configurations from Ciscoworks soon revealed what had happend. Before the IOS upgarde interface vlan 100 on Building A 6509 was shutdown. After some confused looks and some discussion, the only reason we could come up with for this being done was that when the voice server solution was deployed by an outside vendor, the vendor encountered the same problem of user traffic flowing over the etherchannel. The design documents stated that the link should only be used for voice server traffic and that HSRP should be up and running. The deployment engineers may have brought the link up and noticed user traffic flowing over it. Instead of working round the problem they may have found the easiest solution was to shut down one of the interface vlan 100 interfaces. I have left the matter of why the deployment was like this with my not so happy client to dicuss with the vendor.

Adjusting the ospf costs would not have made a difference in this case. The users and the users’ servers were in ospf area 17, while the layer 3 link was a backbone link in area 0. Intra-area links will always be preferred over Inter-area ones. We could have, of  course, put the servers network in a different area but, the fastest and simplest solution I could come up with for this problem involved the ospf passive command. OSPF should only generally be run on transit links and I’ve used the passive command in many environments where layer 3 switches have lots of vlan intefaces that have formed braodaast network type adjancies. This also helps to cut down on CPU and memory usage.

The command is implement under the router ospf configuration mode and it’s an easy one to understand. To stop the two vlan 100 interfaces forming an adjaceny I only had to add it to one side of the link.

Building A Switch

router ospf 1
!
passive-interface Vlan100

That one command was enough to take down the ospf adjacency between the two Vlan 100 interfaces and stop the user traffic flowing across the link. The 10.100.100/24 subnet is still advertised out to the rest of the network and now HSRP is running as the designer planned, as both interfaces as are up.