Cisco: Layer 1 link failure detection

It has been a while since I didn’t post anything here, but it was holidays and I used that time to relax and rest after a year of work. Following this idea I wish you all “Happy New Year” and all the best in 2009.

Today I planned to write about something easy to implement (just to get in shape), but ignored by some network engineer. For me, Layer 1 issues are very annoying, and here I’m talking mostly about the cases when everything look perfect on your side, cable is plugged in, you have green light for the link, but nothing is working.

Luckily some smart engineers think to develop and implement a feature called Unidirectional Link Detection (UDLD). UDLD is used to detect when the send channel (Tx) of a cable is down, but not the receive channel (Rx) and vice versa. This situation typically can occur in a fiber optic cable when there is a break on one side of the cable run or in copper cable when Rx or Tx pair is broken. When UDLD detects this situation the interface is brought down to prevent spanning-tree loops and black holes due to  unidirectional links.Remember, UDLD is a Layer 2 protocol that with Layer 1 mechanisms to determine the physical status of a link.

Please have a look below for a configuration example:

UDLD

GNS3: How-to save multiple topology configurations for good

GNS3 is an extremely useful tool if you are using Dynamips to emulate Cisco devices. It is a graphical environment in which even a newbie can do complex configuration by clicking and dragging routers, switches, connections into a topology that can be saved.

The problem that occurred to me in the past (and maybe to you also) is the following. Let’s assume that we create a configuration with routers named R0 and R1 and you save the topology config and also the routers config (“copy run start”). All the files (GNS3 topology config and Dynamips files created for R0 / R1 saved config) will be put into the default GNS3 project directory (e.g. /tmp in Linux or other directory if you are using Windows system). For now it is perfect. You have everything fine.

Next time when you start a topology, by default GNS3 will start with the same routers R0 and R1, and we you boot them, they will load your ex-saved config files, because GNS3 will look for config files into it’s default project directory, and since the name of the routers are the same, it will think that this have to be loaded. So, what you will do when you have 10 topologies that you save. Give all the time different routers name? Even so you will end with a mess in your default GNS3 project directory.

I have a solution for this issue, that you might like. I’m not saying that I have discovered this solution…for sure there is somewhere out there on the Internet, but I think of it by my own and I said that maybe others will use it.

This how-to assume that you know what Dynamips, GNS3 and Linux (any distribution) are. The same steps can be applied on Windows system also. Please check the tutorial by clicking the image below:
*Note:  As the file is flash and it’s quite big please have patience until it is loaded*

GNS3 topology config save

Cisco: How to configure simple IP SLA monitor

Before we begin let’s see what is this SLA term, for those of us who are not very familiar with the Service Provider terms. IP Service Level Agreements (SLAs) enable customers to assure new business-critical IP applications, as well as IP services that utilize data, voice, and video, in an IP network. With Cisco IOS IP SLAs, users can verify service guarantees, increase network reliability by validating network performance, pro actively identify network issues assure an easy way to deploy new IP services. Cisco IOS IP SLAs use active monitoring, enabling the measurement of network performance and health.

For the following how-to please have a quick look into the topology. As you can see I have a basic routing topology, imported from another tutorial from FirstDigest, and let’s assume that we want to monitor the line between R1 and TEST-RT. For this we will configure a very simple IP SLA monitor, based on icmp echo packets, which will measure our RTT (Round Trip Time) or latency and provide us with valuable informations. For example in case of VoIP problems we can check the latency and in case of a value bigger than 200 ms (220 ms maximum accepted for the voice service to function properly) we will know from where are the problems generated.  Of course IP SLA can have more complex configuration under Cisco IOS (e.g. http or ftp transfer to check if the service provider assure us the bandwidth specified in the contract).

One personal advice from my experience. Even if all the data and information provided by IOS IP SLA monitor can be checked with “show…” commands, I would advice you to get a third party software that can interpret this data for you and draw nice graphs or store them in an archive for you. This kind of software are MRTG, Weathermap, Nagios, RRDtool and others (I put here only the free ones).

Please check the how-to by clicking the image below:

IP SLA monitor