BGP Route Dampaning - Not directly connected eBGP peers - Events

Question

I struggle a bit with BGP route dampaning. I try to find out which events inside of our network can trigger the route dampaning mechanism at the ISP site.

I break down my topology to the very basic.

• VLAN 11: Interconnection network between ISP and my router. This network is used for the peering.
• VLAN 12: iBGP connection (not relevant for the question)
• VLAN 13: network advertised by my router.

My concern is about the dampaning of our network at ISP site. As you can see, with this topology the BGP neighbors are not directly connected. So I have multiple possibilities of interruptions (not only link flapping). I try to find out how issues along the path influence the BGP peering, especially the dampaning.

I created a lab with the topology above to test and did 2 tests for the beginning.

1. When unplugging and re-plugging the physical link at BGPRT01 site, i see that the penalty is added, etc. as expected. When it exceeds the suppress-limit the route is dampened and removed from the routing table.

So far so good. Next test...

2. When removing vlan 11 from SW1 port facing towards BGPRT01 no dampening takes place. After the hold time expires the BGP session is closed, thats it. When adding back the vlan the session is reestablished, thats it. nothing else. If i add the vlan back before the hold time expires nothing special happen.

I would like to know what are the technical events which are responsible to consider a route as instable? Are there events when two eBGP peers are not directly connected which can leads to dampening my route? I read somewhere when receiving a WITHDRAW and an UPDATE for a route. This might be true for example when two ISPs speaks together about a route from another party. But in my setup is seems more like receiving an OPEN message before the hold-time expires?

Answer 1

Losing and re-establishing the BGP peering session will not increase penalty for BGP route dampening.

Quoting & highlighting from https://supportforums.cisco.com/t5/network-infrastructure-blogs/bgp-route-dampening-confused/ba-p/3101999

Penalty -

An incremented numeric value that is assigned to a route each time it flaps. A route is penalized 1000 every time it flaps. A route is considered to have flapped when we receive a WITHDRAW and then an UPDATE for a route. If we drop and regain our adjacency with a BGP peer we do not assign a penalty to the routes learned from that peer.

In other words: Your test setup and procedure act on the BGP adjacency of the peers. That will not trigger BGP route dampening at either end.

If you want to see BGP route dampening at work, you have to make one of the routers send WITHDRAW/UPDATE messages repeatedly. A simple test case for your lab (should work, I am composing this freehandedly, not from a lab):

• make sure that there is no summarization going on in BGP.
• add "redistribute connected" the BGP routing instance on BGPRT01
• define some loopback interfaces on BGPRT01 with different IP subnets
• verify that these new IP subnets appear as BGP routes on "ISP BGP Peer"
• repeatedly shut/no shut the loopback interfaces on BGPRT01
• you should see WITHDRAWs/UPDATEs on "ISP BGP Peer", and you should see the penalty values increase.

Disclaimer: I am not suggesting to add any form of redistribution of internal routing information to an eBGP peering to an ISP. Please make sure that you know exactly what you are doing (and why), if you consider doing this.

To answer your concerns about the eBGP peers not being directly connected: In that case, the stability of the adjacency is your concern, not BGP route dampening. There's ways to tune or help BGP a bit to allow for faster detection of connectivity issues between peers:

http://www.networkers-online.com/blog/2008/12/bgp-performance-tunning-convergence-stability-scalability-and-nsf-part-2/ http://blog.ine.com/2010/11/22/understanding-bgp-convergence/#S2 , Section "BGP Fast Peering Session Deactivation"

The best option might be to talk to your ISP and ask them if BFD based BGP peering is available, or (big style) what kind of redundancy options they have on offer.