BGP Summarization, dampening and backdoors

In this final part of our BGP trilogy we are going to pick up on something from part two, and look at serval ways of resolving it, as well as looking at summarization, dampening and backdoors.

Let’s have a quick recap.

BGP route summarization
We have one router (R1) acting as a route reflector client for R2 and R3, within AS 100. R2 and R3 connect to R4 and R5 in AS 200. Now everything is working fine, but R1 is preferring the route to R3’s AS 200 interface through R2, R4 and R5.


That’s hardly the best route now really, is it? But with a little tweaking of BGP attributes we should be able to modify the routes used by R1 around the network. The other alternative is to reboot R2 until we get the preferred route in the the routing table, but let’s face it, this isn’t really the way we would be able to do it in a production environment.

BGP attributes

BGP uses a number of attributes in the way it determines the best path to a destination, and within these attributes are sub categories, namely well-known and optional.

  • Well-known mandatory – supported by all BGP implementations, and are always included in every BGP update.
  • Well-known discretionary – supported by all BGP implementations, but are optionally included in BGP updates.
  • Optional Transitive – May not be supported by all implementations of BGP. Transitive means that a non-compliant BGP router will forward the unsupported attribute unchanged, when sending updates to peers
  • Optional Non-Transitive – As above, but the router will strip out the unsupported attribute when sending updates to peers.

So we have types of attribute covered, lets look at what we can actually tweak…

  • AS-Path (Code 2, well-known, mandatory) – The path of traversed AS’s to reach a destination
  • Next-hop (Code 3, well-known, mandatory) – next-hop ip address to reach a destination
  • Origin (Code 1, well-known, mandatory) – Identifies the originator of the route
  • Local Preference (Code 5, well-known, discretionary) – provides a preference to determine a path for outbound traffic
  • Atomic Aggregate (Code 6, well-known, discretionary) – identifies routes that have been summarized
  • Aggregator (Code 7, optional transitive) – Identifies the BGP router that performed address summarization
  • Community (Code 8, optional transitive) – tags routes that share common characteristics into a community
  • Muti-Exit-Descriminator (MED) (Code 4, optional non-transitiive) – provides a preference to eBGP peers for a specific inbound router
  • Weight (Cisco Proprietary) – similar to local preference, provides a local weight to determine the best path for outbound traffic

Best Path determination

We know what attributes can be sent within a BGP update, but the list above does not follow the order in which two routes to the same destination are actually compared:

  • Weight – applied to inbound routes to influence the best outbound path, highest wins
  • Local preference – applied to inbound routes to influence the best outbound path, highest local preference wins
  • Locally Originated – is the next hop
  • AS-Path – applied to outbound routes to influence the best inbound path, which route has the shortest AS-Path, this is between AS’s
  • Origin Code – IGP, EGP or ? (unknown)
  • MED – applied to outbound routes to influence the best inbound path, lowest wins
  • BGP Router type – eBGP or iBGP? eBGP wins
  • Age – oldest preferred
  • BGP Router-ID lowest sending router id wins.

What should we use where? Well, lets think about this in terms of a lab task. We could have a couple of different tasks that would control where we are making the changes. Let’s have a look at a couple of different tasks:

1. R1 must prefer the route to through R3 with R2 acting as a backup route. You are not allowed to make any changes on R2 or R3
2. R1 must prefer the route to through R3 with R2 acting as a backup route. You are not allowed to make any changes on R1 or R2
3. R1 must prefer the route to through R3 with R2 acting as a backup route. You are not allowed to make any changes on R1 or R3

So here we can see that in task 1 we are allowed to make changes on R1, in task 2 we can only change R3, and in task 3 we can only change R2.

So following these we can start to see what we can change, and where:

Task 1 – Weight, local preference
Task 2 – MED
Task 3 – BGP Router-ID

Influencing BGP paths using the Weight attribute

With weight the highest number wins. By default the weight advertised in a BGP route from another router will be 0. Weight can be any number between 0 and 65535.

As we can see from the below screen shot, we are just using the defaults for our topology at the moment:

BGP weight

On R1 we can either use the weight command in conjunction with the neighbor command to influence all routes (here we would use “neighbor weight 200”), but we only want to affect the network, and we can do this through an access-list (or an ip prefix-list) and a route-map:

route map

We start with an access list, reference this in the route-map and then assign route-map to neighbor for R3:

BGP neighbor route map

Lastly we need to clear the BGP process using the “clear ip bgp 100” command.

Then we can take another look at our BGP table and see that now that route is favoured due to the higher weight:

BGP weight

And the router’s routing table confirms this:

BGP routing

Influencing BGP paths using the local pref attribute

If we reset R1 and keep our fingers crossed, then thankfully it comes up as it was before, preferring the path through R2 to reach R3’s far end.

BGP local preference

Now we can tune the local preference. which can range from 0 to 4294967295 (it’s a 32 bit number). The default, as we can see from the pictures above, is 100. The highest local preference is preferred.

Let’s create an ip prefix-list this time to go along with our route-map:

BGP prefix list

And we implement it in our BGP configuration in the same manner as before:

neighbor route map

Lastly we need to reload BGP using the “clear ip bgp” command again, and we can see that the new route has taken effect:

clear bgp route

And if we check out the BGP tables:

BGP table

We can see that the local pref now shows 200 instead of 100.

Influencing BGP paths using the MED attribute

With MED a lower value is preferred, so we could increase the MED on R2

BGP med

And the effect? It looks good:

BGP routing MED

BGP routing through MED

Influencing BGP paths using the BGP Router-ID

We have seen that we can control how a route is perceived as it comes into a router, and so far how to reduce it’s preference as it leaves a router, but if we wanted to change how R3 is selected in R1’s path choices, well, not much is actually left for us to change.

But we do have the router-id still, so lets change that and see what happens;

Firstly we change the router-id on R3:

BGP router ID

Notice that changing the router-id drops all the BGP adjacencies, and we must wait for about a minute for it to rebuild all the adjacencies, but once everything is back up and running we can see on R1:

BGP router id

That the path on R1 to will be through R3 and not through R2, but annoyingly, so is everything else. We could combine some of the methods we have used earlier and make R3 less preferred for some of the other routes.

BGP Summarization

BGP performs summarization on redistributed routes by default. As with other routing protocols we can disable this by using the “no auto-summary” command.

We can create a summary address for, and by using the aggregate-address command:


The default for BGP is to send both the aggregate address as well as the specific routes, we can modify this behaviour by adding the summary-only statement:

aggregate-address summary-only

We can also choose to perform summarization on specific routes (known as suppressing):

access-list 5 permit
access-list 5 permit

route-map SUPPRESSION permit 10
match ip address 5

router bgp 100
aggregate-address summary-only suppress-map SUPRESSION

Lastly, we can allow the summarized routes to retain their AS-Path informations by appending as-set:

aggregate-address summary-only suppress-map SUPRESSION as-set

BGP Dampening

Route dampening suppresses flapping routes. When a route flaps it is assigned a penalty, and upon reaching a penalty threshold the route is supressed, until the line stabilizes, the penalties decrease and the line is deemed usable again.

Dampening can be tweaked as follows:

ip prefix-list DAMPLIST seq 10 permit
ip prefix-list DAMPLIST seq 20 permit

route-map DAMPMAP permit 10
match ip address prefix-list DAMPLIST
set dampening 15 750 2000 60

router bgp 100
bgp dampening route-map DAMPMAP

We have a number of figures for dampening:

15 (minutes) – half-life timer, if a penalty has been assigned to a route then half the penalty will decay after this timer expires
750 (penalty measurement) – bottom threshold, once a penalized route falls below this threshold with will no longer be suppressed.
2000 (penalty measurement) – top threshold – if a flapping route’s penalties exceed this threshold then it will be suppressed
60 (minutes) maximum amount of time a route can be suppressed.

BGP Backdoors

If an IGP route and an eBGP route exist for the same network then we can find that we have sub-optimal routing where the eBGP route is preferred. We can change this in one of two ways, by changing BGPs default AD, or using the network backdoor command.

Changing default AD values is not recommended, so we can use option B.

Using the network backdoor command adjusts the AD for a specific eBGP route from 20 to 200, forcing the IGP route to be preferred:

router bgp 100
network mask backdoor


And there we are for BGP.

We have covered the basics, reflection, confederation, peer groups, changing attributes to tune routing, summarization, supression, and backdoors.  I hope you have found it useful.

If you want a great book on BGP, then make sure you check out BGP for Cisco Networks.