Cisco: How to improve BGP table stability with route dampening

[UPDATE Feb 13, 2013]
After gaining some more years of experience, playing more with BGP also from SP perspective, I would recommend to be careful with this feature. It can help in your enterprise environment, where you have access to BGP routers and can clean the dampened prefixes. If you have your Service Provider involved in routing your prefixes, I would prefer that the SP does not enable this feature. Imagine that because of some flaps your provider dampen all your prefixes. Or negotiate your SLA in such way that the provider can support if the BGP dampening feature is active and you need support.

———-

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: BGP path selection for outgoing traffic

Before going further on, please download the topology and the initial configuration files and have a close look into them (mostly into topology drawing). Also, this tutorial is addressed to people that know what is BGP and how to do a basic configuration for peering establishing.

For modifying the BGP automate selection of the best path, we have to modify some of BGP attributes from the table below:
Since today we will deal with outgoing traffic, we are interested in Weight and Local preference attributes, which we have to modify to reach our desired result. For the incoming traffic I will make another tutorial in some days.

So, let assume that we have some networks in the LAN after R1 in the topology and we advertise this into the BGP network. On R3, we will learn this prefixes by the way of R1 as it is the shortest path. But in our case the shortest path does not mean the fastest one. As you can see the connection between R1 and R3 is a Serial connection (let’s assume E1). The connections between R1 – R2 and R2 – R3 are FastEthernet connections. Even if this a longer path, for us would be better to reach the LAN subnets in behind R1 through R2, as this is more faster (bigger bandwidth and lower latency). We will force the outgoing traffic through R2 by modifying the Weight and Local preference attribute.

Please see the tutorial below:

Cisco: Layer 2 traffic filtering

Layer 2 traffic filtering can be very useful when you want to drop packets closer to
the source because you can do this on L2 next-hop which is the switch where the
devices are connected. Based on mac-address, Layer 2 filtering can be apply using
one of the two most common method: Port Security and MAC Access Groups.

Port Security is the more secure method of the two. To use it, map a switch port to the
specific MAC address of the connected device. It gives you more possibility than just
drop the packets from a specific source, depending on what you want to achieve on
the interface where it is applied.

MAC Access Groups are generally used for small networks of 20 devices or less. Add
a permit statement for all of your devices interface MAC addresses and apply the access
list to switch interface. This will limit inbound traffic to that interface to only those
MAC addresses on your list. Is not recommended when you have many MAC addresses,
because MAC access-list are the same like IP address access-list, so they consume a
lot of resources of the machine where it is applied.

For this tutorial we will use a Cisco 3750 in which it is connected a router ( R4 ). To test
Layer 2 traffic filtering, we have a point-to-point Layer 3 connection in between
( 10.0.0.0 /30 ), with physical interface used on the R4 and a Vlan 4 interface on the
switch. The port on the switch were R4 is connected is an access port in vlan 4.

Please see the tutorial below:

Cisco: Packet sniffing

The official term of Cisco for Packet sniffing isĀ  SPAN ( Switched Port Analyzer ) also called sometimes port mirroring or port monitoring and it’s purpose is to select traffic from a source and send to a destination with a network analyzer tool. You can find out there terms like RSPAN, PSPAN, VSPAN, ESPAN, but this are at their basic functionality nothing more than SPAN with some enhanced features ( e.g. ESPAN – Enhanced SPAN ) or describing their primary functionality ( e.g. VSPAN – Vlan SPAN – used to monitor vlans ).

Now, depending on you Cisco platform some of this xSPAN can be supported or not. A list with them you can find here.
On the high-class products, like 6500, you can find another device called NAM ( Network Analysis Module ) which enhance SPAN by providing a web interface and a local embedded traffic analyzer. Maybe someday, if I have a spare device I will make a short tutorial about NAM module.

For the basic SPAN configuration purpose I will use a c3750 as this method is supported on many more devices ( e.g. 3550, 3560, 2950, 2900XL). One notice before we begin. On the port where you redirect your SPAN traffic and where you connect your device with traffic analyzer, you don’t need a Layer 3 address. So, just let that port with plain Layer 2 configuration.

Please see the tutorial below:

Cisco: SSH enable | disable | reconfigure tutorial

One of the most used method for remote access today is SSH protocol. Even most on the network engineer say what is so complicated in the process of the enable , disable , reconfigure of the SSH process, my experience proved me that it can be really complicated, if you mess up stuff there.

One of the situation that I see very often, is that after a network engineer (administrator, beginner…) reconfigure SSH or hostname / domain-name on the Cisco routers is that they tell that is not working anymore with some errors like “key missing” or “key not matching” or more errors relating to the RSA keys. And in almost 90% from the cases was due to wrong order of operation during the SSH reconfigure.

Let’s say that we have a functional SSH access, and then we have to change the hostname and domain-name of the Cisco machine. As you know, SSH relay on RSA keys for connectivity, which relay on hostname and domain-name of the machine when the keys are creating. Most common error is that the network person change the hostname, domain-name, then delete the keys and reconfigure a new one…this is the happy case and for some routers and IOS platform is working. But, there is the worst one, when the person in charge change the domain-name and the hostname and then, he/she expect ssh to work like before. But it does not!

Please check the tutorial below for the correct order of operation in enabling, disabling or reconfiguring the SSH protocol on a Cisco device. For this tutorial I will use 2 point-to-point connected routers R0 and R1. I will enable SSH on R1 and then connect to it from R0.

SSH