Author: Calin

Calin is a network engineer, with more than 20 years of experience in designing, installing, troubleshooting, and maintaining large enterprise WAN and LAN networks.

Cisco: Engineer’s trick to avoid suboptimal path

I was explaining in the previous post what is the difference between optimal and suboptimal path and how to avoid the use of not such a good path in your routed environment. Also there I presented this so call “dirty trick” you can use to force the routing protocol to choose the path that you want, based on the Administrative distance modification.

As I said there is another way (for sure more than one) to do it, using a more elegant approach and from the networking point of view more safe considering the complex routing environment. I will use the same topology like in the previous post to offer you the possibility to compare these 2 methods presented and to choose the one that you understand and fit better to your needs. Also there are some other ways to do it and please feel free to discussed them in the comments section and maybe to present them here in a future post.

We will achive the desired results by setting one community on R1 for the advertised network 192.168.82.1 and dropping the prefixes, marked with the same community, on R2. Please be aware that for this method to work you have to allowed BGP peers to send communities list with the command “neighbor xx.xx.xx.xx send-community …” under “router bgp xxx” process.

Please see the example by clicking the image below:

Optimal path engineer trick

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

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