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 cisco, Dynamips, GNS3, gns3 how-to, multiple configuration, reload with config, save, topology

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:

Cisco-services cisco, IP, monitor, service provider, SLA, terms

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:

Cisco-multicast cisco, dense mode, mroute, multicast, sparse dense mode

Configuring banners on Cisco devices is very easy and it is a study material for CCNA. Even so, I found that not everybody is aware of the importance of the banners or know how banners can be used properly.

There are quite a lot of system banners that can be configured on a Cisco device, but today I will explain only the most used, or let’s say the most that I use, since this is a subjective choice. You will find below the banners name and a short explanation:

• banner motd - add a message-of-the-day (MOTD) banner; usually not so important, but in case of urgent maintenance work can be useful; when someone connects to the router, the MOTD banner appears before the login prompt
• banner exec - display a banner on terminals with an interactive EXEC; after the user successfully logs in to the router, the EXEC banner or incoming banner will be displayed
• banner login - when someone connects to the router, the MOTD banner (if configured) appears first, followed by the login banner and prompts; e.g. it can be useful to display a warning in case that you are not authorized to access the machine
• banner prompt-timeout - it display a message when the user is delaying a login above the definite period of time
  

If I forgot some very important banner or one that you find extremely useful please remind me to add it here or in another post. Please see below how to configure the system banners that I just described:

Cisco-remote-access banner, cisco, exec, login, motd, system banner, timeout

In some previous post we saw how we can manipulate BGP paths using attributes for outgoing traffic. Today we will see how to use another BGP attribute, but this time for manipulating inbound traffic. First I would like to ask you to have a look into the topology file and also to check the config files (if you have a basic idea about how BGP is configured that you don’t need the config files).

From the table above:
we see that the attributes needed for inbound traffic manipulation are AS-Path and MED. Today we will use AS-Path for traffic manipulation (MED sometime in closer future).

Beside using BGP attributes, there are other ways to manipulate traffic and paths in a BGP environment, but usually this need that the provider will support your actions. As an example to understand, you can do route tagging in your network (for example in MPLS on your CE) and your ISP will apply rules based on different tags (on PE side), but this is out of the scope of this tutorial and will be discussed maybe in another tutorial.

For our test environment, that you see in the topology, we advertise everything into BGP domain, exactly as draw, so there will be no problems of reachability.

Please see the tutorial and explanations below:

Cisco-EGP as-path, bestpath, bgp, cisco, inbound, path, prepend

Cisco Policy Based Routing provides a flexible mechanism for network administrators to customize the operation of the routing table and the flow of traffic within their networks. Policy Based Routing (PBR) offers many advanced features, including selection and forwarding of traffic to discreet Virtual Routing and Forwarding (VRF) instances, as well as Enhanced Tracking of the availability of next-hops. More about PBR you can read here.

Before we start this tutorial please download the topology file which contain the routers connection, BGP topology and some explanations. As you can see in the topology file, traffic going from R4 to R5 will choose the shortest path through R1-R2. For this tutorial let’s assume that we want the traffic from R4 to R5 (and viceversa) to flow through path R1-R3-R2 (BGP is full mesh configured among these devices). For this we need to apply Policy Based Routing (PBR) on R1 and R2. What is PBR basically doing? It will change the next-hop for interesting traffic to R3 on this devices.

Please see below the tutorial about how to configure PBR:

Cisco-routing cisco, PBR, policy based routing, traffic, traffic manipulation

NTP (Network Time Protocol) is usually very simple to configure on Cisco devices. Of course you can reach complex configuration, but since I work in this field I didn’t saw somebody to push the things to extreme in NTP configuration.

NTP is based on server - client relation. It is recommended that in a Cisco network environment, you should use online the client part of the NTP, and to choose some external NTP sever to synchronize with.  This is because using a NTP server (master) on your networ  violates NTP’s hierarchical trust model. You should use a NTP master only is there is no possibility to reach an external one or if some corporate policies dictate this.

NTP can operate in 4 different modes. See a short explanation below:
-> Client:  A NTP client is configured to let its clock be set and synchronized by an external NTP timeserver. NTP clients can be configured to use multiple servers to set their local time and are able to give preference to the most accurate time sources. They will not, however, provide synchronization services to any other devices.
-> Server: A NTP server is configured to synchronize NTP clients. Servers can be configured to synchronize any client or only specific clients. NTP servers, however, will accept no synchronization information from their clients and therefore will not let clients update or affect the server’s time settings.
-> Peer: With NTP peers, one NTP-enabled device does not have authority over the other. With the peering model, each device shares its time information with the other, and each device can also provide time synchronization to the other.
-> Broadcast / Multicast: Broadcast/multicast mode is a special server mode with which the NTP server broadcasts its synchronization information to all clients. Broadcast mode requires that clients be on the same subnet as the server, and multicast mode requires that clients and servers have multicast access available and configured.

For our simple NTP configuration we will use the server and  client mode. For this tutorial we will use the same topology like in the post “Cisco: BGP path selection for outgoing traffic” where we have already a working BGP environment. If you do not have the topology, you can download it here. Please see the tutorial below:

Cisco-services cisco, client, network time protocol, ntp, ntp configuration, peer, server

One of the issues that can affect BGP table stability is link flapping. Imagine that if a link to a network is flapping very often, BGP process has to remove the route to that network from the BGP table and implicit from the routing table and then we the link is available again to re-introduce the prefix in these tables. All this means some BGP operations that consume CPU and memory of the machine.

A way to improve the BGP table stability is to use route dampening. This BGP feature monitor the prefixes in the BGP table and when a route to some prefixes flaps more than BGP dampening is set to allow, it will take out the prefixes from the BGP table. In the following tutorial I will show you a way to configure BGP dampening with some explanations.

For this tutorial we will use the same topology like in the post “Cisco: BGP path selection for outgoing traffic” where we have already a working BGP environment. I took out the configuration for BGP path selection, so we have a simple BGP config running. If you do not have the topology, you can download it here and the initial configuration files here.

Please see the tutorial below:

Cisco-EGP bgp, bgp dampening, bgp table, bgp table stability, cisco, dampening