Category: Network Technologies

Cisco: Dirty trick to force optimal path in routed environment

Everywhere in the world people try to find the optimal path to achieve something.If we speak about roads, trips and in our case networking, choosing the best path to an end point can have only advantages.

I took the term optimal / suboptimal path from the routing issues that can appear in the OSPF network environment and which are called by the experts suboptimal routing. What I want to explain here, maybe you already seen it, is that in some network environment the best path to a destination is not always preferred by the routing protocol due to some unhappy situations. To understand better what I’m talking here, please have a look at the topology that I will use for this tutorial and for the next one regarding optimal path.

In the example below I will show you a simple and dirty trick how you can escape from this situation. I recommend to use this dirty trick only in urgent cases and only temporary as this can lead to more problems if you have a complex network environment. In the next days I will show you a more elegant method to escape from suboptimal path problem.

As you can see in the topology we have a network environment formed by 4 routers. On R1 we have configured a BGP session with the peer R3 and OSPF with R2. Since the peers are in different autonomous systems the BGP session will be external. For OSPF this does not matter.The Loopback100 interface in R1 is advertised into BGP and OSPF, and it is learned by R2. On R2 the interface 192.168.82.1 arrives on BGP table and OSPF table, but since the Administrative Distance of the eBGP (20) is better that the one of OSPF (110) on the routing table will appear the route through R4. This is bad because without considering the obvious longer path through R4, we can see that the links between R2-R4 and R1-R3 are Serial interfaces and definitely with more limited bandwidth than FastEhernet interface R1-R2 (we assume that we do no have any QoS or other limitation). Last note before we begin, all the routing processes on the devices are completely configured and functional.

Optimal path dirty trick

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

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

Cisco: Simple configuration of IP multicast dense mode

Until now, I did not meet a network engineer to be really “in love” with multicast. Some are considering challenging, interesting, useful but most of the network engineers (I repeat myself, from the persons that I discussed with) are rather preferring do other topics that multicast. If you are curious about my position in regarding multicast, well I’m somewhere in the middle. I consider it challenging, a topic for the future (like IPv6), I MUST know it, but let’s say that is not my strongest topic in networking.

I think that I can share some of my experience here with you, and maybe discuss a little bit on th multicast subject. And since I do not want to enter more complex multicast configuration from the start I said I should take it slow with the easiest one: multicast dense mode configuration. As you know there is also sparse mode configuration which can be configured in a more complex way, and I will do it in next tutorials. For now I only hope that you know what is multicast and words like PIM, IGMP, dense-mode, sparse-mode does not sound like alien descriptions for you. If you are feeling insecure about this topic, please check this link as you might get very good information about IP multicast.

For this tutorial I have a simple point to point router connection (R1 and R2) with a subnet of 10.0.12.0 /24 in between, and each router has an additional host (R1 has the multicast sender connected and R2 has the multicast reveiver connected). Since I have no possibility to test the IP multicast traffic in this configuration, the explanation above is just to have a picture about the environment. I hope that for the multicast sparse mode I will find a way to generate some multicast traffic, when I will write the tutorial somewhere next weeks.

Please see the tutorial by clicking the image below:

Multicast dense mode