BGP - Part 3: BGP and the attributes of summarizing damp 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.

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 unti 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 0.0.0.0?
• 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 14.1.1.1 through R3 with R2 acting as a backup route. You are not alloed to make any changes on R2 or R3
2. R1 must prefer the route to 14.1.1.1 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 14.1.1.1 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:

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

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

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:

And the router's routing table confirms this:

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.

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:

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

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

And if we check out the bgp tables:

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

And the effect? It looks good:

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:

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:

That the path on R1 to 14.1.1.1 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 summarizes 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 10.1.0.0/24 10.1.1.0/24, 10.1.2.0/24 and 10.1.3.0/24 by using the aggregate-address command:

aggregate-address 10.1.0.0 255.255.252.0

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 10.1.0.0 255.255.252.0 summary-only 

We can also choose to summarize specific routes (known as suppressing):

access-list 5 permit 10.1.2.0 0.0.0.255
access-list 5 permit 10.1.3.0 0.0.0.255

route-map SUPPRESSION permit 10
match ip address 5

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

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

aggregate-address 10.1.0.0 255.255.252.0 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 10.1.2.0/24
ip prefix-list DAMPLIST seq 20 permit 10.1.3.0/24

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, forcong rhe IGP route to be preferred:

router bgp 100
network 10.1.5.0 mask 255.255.255.0 backdoor

Wrap-up

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.

BGP - Part 1: Basic Setup

BGP or Border Gateway Protocol is a pretty big topic, so we will be looking at it over the course of three different posts.

Part one (this post) will cover the background, and basics of iBGP and eBGP peering, as well as route advertisement, part two and part three will cover route advertisements in more detail, as well as covering route injection, route filtering and path attributes.

BGP Background

BGP is an exterior gateway protocol, as opposed to RIP, EIGRP and OSPF which are interior gateway protocols. Version 4 of BGP is the current standard. It is a path vector routing protocol, designed to route between Autonomous Systems (AS's), and each AS is assigned an Autonomous System Number (ASN).

For BGP to work it must form a BGP peer (a neighbor relationship). There are two types of peers:

• iBGP (peers within the same AS)
• eBGP (connecting between separate AS's)

Once a peer is formed the neighbors share their full routing table, and after that only forward updates to their peers, which saves on bandwidth and time.

eBGP peers are assumed to be a maximum of one hop away, though this can be bypassed using the ebgp-multihop option with the neighbor command, which we will cover later.

iBGP peers are reliant on the underlying igp (such as RIP, OSPF or EIGRP) to connect the peers together. By default all iBGP peers must be fully meshed with in the AS.

A BGP router can only belong to one AS, and Cisco IOS only allows one BGP process to run.

The AD for routes learned outside the AS (eBGP) is 20, the AD for iBGP and locally originated routes is 200.

BGP Peering messages

BGP uses several message types to communicate between the peers:

OPEN - to initiate the session - contains BGP version which must match, the local AS number and the BGP router ID.
KEEPALIVE - keepalives are sent every 60 seconds, if no replies are received within the hold-time period (180 seconds) the router declares the peer dead.
UPDATE - used to exchange routes
NOTIFICATION - sent when there is a fatal error. BGP session is torn down and reset.

BGP Peering states (BGP Finite-State Machine / FSM)

BGP goes through several states (as do the igp's) as a peer is established. These states are:

Idle - initial state
Connect - waits for TCP connection from remote peer. Results in either OPEN message if successful, or placed in an Active state if unsuccessful.
Active - Attempts to initiate a TCP connection with the peer. If successful results in OPEN message, or if unsuccessful then waits for ConnectRetry timer to expire and goes back to Connect state
OpenSent - Session is established and an OPEN message is sent, once it receives a reply the peer will send a KEEPALIVE
OpenConfirm - BGP listens for a reply KEEPALIVE message
Established - BGP peer session is fully established. UPDATE messages now sent containing the routing information.

Configuring BGP

If you have configured any igp in the past then the basics of configuring BGP will not offer any surprises.

We start by specifying the AS

RouterB(config)# router bgp 100

Next it is generally good practice to set the bgp router id. The router id (if not specified) will use the highest IP address of any loopback interface, and if no loopback interface exists, the the highest IP address of any physical interface.

The BGP router id is set using the command "bgp router-id x.x.x."

Next we set the neighbors

RouterB(config-router)# neighbor 10.1.1.1 remote-as 100
RouterB(config-router)# neighbor 12.1.1.2 remote-as 400

For stability we can use a loopback address as the source

RouterB(config-router)# neighbor 12.1.1.2 update-source lo0

RouterC must then point to the loopback ip of routerB

RouterC(config)# router bgp 400
RouterC(config-router)# neighbor 1.1.1.1 remote-as 100

In order to use a loopback address as a source the peer must have a static route to the other router's loopback in its routing table.

If we use the loopback as a source then then this is more than one hop away. Therefore the multi-hop feature must be used. If the number at the end is omitted then the default of 255 is used:

RouterC(config)# router bgp 400
RouterC(config-router)# neighbor 1.1.1.1 ebgp-multihop 2

BGP authentication

BGP authentication is very straightforward:

RouterB(config)# router bgp 100
RouterB(config-router)# neighbor 12.1.1.2 password CISCO

Now we have had a quick over view, let's start configuring!

We have three AS's
AS 100:
       R1 - IP address 10.1.1.1 - BGP router-id = 1.1.1.1
AS 200:
      R2 - IP address 10.1.1.2 / 12.1.1.2 - BGP router-id = 2.2.2.2
      R3 - IP address 12.1.1.3 / 12.1.1.4 - BGP router-id = 3.3.3.3
      R4 - IP address 12.1.1.5 / 13.1.1.1 - BGP router-id = 4.4.4.4
AS 300:
      R5 - IP address 13.1.1.2 - BGP router-id = 5.5.5.5

1. AS 100 and 300 are separate AS's, connecting to AS 200
2. BGP password authentication will be used between R1 and R2
3. R4's loopback address will be used for the update-source between R4 and R5
5. We will also need to set up and IGP in AS 200.

We can see by just using the neighbor command that its easy to set up BGP ebgp peers, below is the "show run" from R1 and R2:

And the others are (at the moment set fairly similarly). Looking at the output from "sh ip bgp summary" we can see that each can see their immediate neighbor:

BGP update-source using a loopback

Now lets configure R4 to use its loopback as the source, and get R5 to talk to that IP instead of the 13.1.1.1 address:

We add a loopback to each side, and set the update-source on R4 to be lo0

On R5 add a route to 15.1.1.1 using the serial 0/0 interface:

Next we remove the original bgp neighbor statement, and then add one back in, this time using the loopback address on R4, remembering to use the command "neighbor 15.1.1.1 ebgp-multihop 2".

And we confirm that all is still well with the two BGP peers

Usually you would configure BOTH sides to use the loopback as the update source, this is intended to be for stability after all!

BGP Transit AS and the BGP synchronization rule

So we can see that AS 100 can talk to R2 in AS 200, the three routers in AS 200 can all see each other, and AS 200 and AS 300 are seeing each other as well. But there is no communication between them. AS 200 is acting as a transit AS. If an AS is acting as a transit AS it is governed by the BGP synchronization rule.

The BGP synchronization rule states that all routers in a transit AS (including non-BGP routers) must learn of a route before BGP can advertise it to an external peer.

So lets add an igp into the mix and see what happens...

The configurations look like this:

And now we can see from the "sh ip route" command that R5 can see all the way over to R1

Well, its in the routing table at any rate, but pings fail. Lets look at the routing table for R1:

Well, there is not much in there, which brings us onto the next topic.

Originating prefixes in BGP

We have three ways to originate a prefix (advertise a network) into BGP

• Using the network statement
• Using aggregate-address statements
• Redistributing an IGP into BGP

Lets use the network address first.

For this to work we need to specify which networks we are going to advertise out of R2.

So on R2 we will add the following statements:

Now lets have a look at R1...

This looks much better now!

And we can do and end to end ping test to confirm:

Issues with advertising a loopback across OSPF

I did encounter one issue. R1 was not picking up the 15.1.1.0/24 network.

We can see that R3 does not have an issue:

R2 however sees it as a /32 subnet:

Its coming in through OSPF, so we can pinpoint the issue pretty quickly (i.e. we know that its not a BGP issue).

By default OSPF will advertise a loopback interface with a /32 mask, even if another mask has been set. It's defined under RFC2328. We can circumvent this by using the command "ip ospf network point-to-point" in the loopback interface on R4:

And now if we look at the tables for R2 and R1...

And we can see that R1 has full end-to-end connectivity!

I'd like to thank my colleague Muhammed for his help in this last bit. he's also going for his CCIE at the moment and to this useful post on OSPF advertising a loopback with a /32 subnet.

Troubleshooting BGP

One last thing to add before we wrap this up and get the second part of this trilogy underway is the very useful command "sh ip bgp neighbor <neighbor ip> advertised-routes - its great to see what routes are being advertised between peers:

Very useful. And that's it for now, you can read part two here.

When Route Redistribution goes bad - Routing Loops and Route feedback (2.90)

When we are redistributing from one protocol into another, we find that with one point of redistribution everything is fine, but when we have multiple points of redistribution we can start to encounter problems, namely routing loops and route feedback. Thankfully these can be fixed with a few commands.

Routing loops

In the diagram above we are redistributing RIP into OSPF, and from OSPF into RIP. Ignore the mis-labelled interface for Router C (the interface in the RIP network is actually e0/1), I made a mistake in my original netmap. I wondered why things didn't work properly. Originally I did this in Packet Tracer, only to find a serious limitation was the lack of distribute-lists and limitations on the distance command.

If you want to follow this post through, then you can download the IOU lab from here.

First we begin with very straight-forward ospf and rip networks. Picking RouterA and RouterF, we quickly check that the basics are all plumbed in:

OSPF looks good, so lets just check rip

OK, all looks good.

The routing tables on routers C and D look like this

Lets have a quick look at the routing tables of routers A and F

Making a routing loop

To create the routing loop we need to mutually redistribute OSPF and RIP on routers C and D. The commands are identical for both.

And we can see (using the "sh ip route" command) the contents of the routing table:

Now we can start to see the problem.

Router C which has an interface in the RIP network, has a route to the 10.1.X.0 through router A (apart from its own directly connected 10.1.1.0/24 network) - which is kind of in the wrong direction. Similarly Router D has routes all of the 10.1.X networks (apart from its own directly connected 10.1.5.0/24 network) through Router B. Again really this is in the wrong direction.

The reason for this because the AD (Administrative Distance) of OSPF (110) is lower than the AD for RIP (120), and therefore is the prefered route. The AD can be seen as the first number in the square brackets [110/1] and [120/1]. Therefore to reach the non-connected networks, Routers C and D will prefer the sub-optimal path through OSPF.

The end effect is that if Router C sends a a packet destined for the 10.1.5.0/24 network it will go to Router A first (192.168.1.1). This is Router A's routing table:

Router A will pass the packet to Router B, and from B it passes to Router D. This does not present its-self as much of an issue, but look at the routes for the 10.1.4/0/24 network.

A packet to the 10.1.4.0/24 network originating from Router C would pass to Router A. From Router A it would pass to Router B, and from B to D. Now here we see the loop:

The routing table for Router B is on the left and for Router D is on the right. As you can see Router B prefers Router D as the best route to the 10.1.4.0 network, and Router D prefers Router B as the best route. Thus we have a loop.

Fixing a routing loop

Thankfully all is not lost (well, maybe a few packets along the way), and we have two ways of fixing this scenario.

Fixing a routing loop with a distribution-list

The first method is to use a distribution-list and attach it to the interface we want to prevent accepting routes from the wrong side. The configuration on Router C would be as follows:

RouterC(config)# access-list 10 deny 10.1.2.0 0.0.0.255

RouterC(config)# access-list 10 deny 10.1.3.0 0.0.0.255

RouterC(config)# access-list 10 deny 10.1.4.0 0.0.0.255

RouterC(config)# access-list 10 deny 10.1.5.0 0.0.0.255

RouterC(config)# access-list 10 permit any

RouterC(config)# router opsf 1

RouterC(config-router)# distribute-list 10 in ethernet0/0

And Router D would look similar:

RouterC(config)# access-list 10 deny 10.1.1.0 0.0.0.255

RouterC(config)# access-list 10 deny 10.1.2.0 0.0.0.255

RouterC(config)# access-list 10 deny 10.1.3.0 0.0.0.255

RouterC(config)# access-list 10 deny 10.1.4.0 0.0.0.255

RouterC(config)# access-list 10 permit any

RouterC(config)# router opsf 1

RouterC(config-router)# distribute-list 10 in ethernet0/0

These access-lists deny the RIP networks specified, whilst permitting all the other networks. We can see this taking effect immediately in the routing table:

The downside of this method is that any form of redundancy is also lost. If Router C lost its e0/1 interface it would not be able to select an alternative path (i.e. through the RIP network) for the other OSPF networks.

Fixing a routing loop with the distance command

The second method we have available is to tweak the AD for the specific routes. it is very similar to the first method, but with a few changes, we can either lower the AD of the routes learned through RIP, or raise the AD of the external OSPF learned routes. Again we start with an access list:

RouterC(config)# access-list 10 permit 10.1.2.0 0.0.0.255

RouterC(config)# access-list 10 permit 10.1.3.0 0.0.0.255

RouterC(config)# access-list 10 permit 10.1.4.0 0.0.0.255

RouterC(config)# access-list 10 permit 10.1.5.0 0.0.0.255

RouterC(config)# access-list 10 deny any

RouterC(config)# router rip

RouterC(config-router)# distance 70 10.1.1.0 0.0.0.255 10

Here we are applying a an AD of 70 for the routes specified in access list 10. Again Router D's config would be similar, but I think you can see what needs changing, so I wont put the config here.

The end result is that the routes originating from RIP will now have a lower AD than the routes that have been redistributed from OSPF. This eliminates the routing loop.

If we decided that we wanted to use the second method and raise the AD for the external OSPF learned routes then we can do this with one line, and do not need the access list:

RouterC(config)# router ospf 1

RouterC(config-router)# distance ospf external 240

Router C and Router D then replaced the externally learned routes with the routers learned by its own RIP process:

Router D is probably the best example of the process, as the screenshot managed to catch the transition in routes, firstly as their AD is increased to 240, and then, moments later, as these routes are replaced by the ones originating from within RIP.

So that's routing loops taken care of, now lets move on.

Route feedback

The OSPF routes that have been redistributed into RIP by Router C will also reach Router D, and will again be redistributed back into OSPF. hence the term "feedback".

The feedback could very well cause Router B to prefer the route through RouterD for the 192.168.2.0/24 network. This is called suboptimal routing.

clearly we want to make sure that no re-injection occurs. We can do this through distribution lists and by using the distance command, but lets look at route tags instead.

We can tag routes in order to identify and filter them. The tag is retained as it passes from router to router. So a tag that is applied when it is redistributed into RIP (say from Router C) retains its tag and can be used by another router (Router D) to be filtered out.

We use route-maps in order to apply tags, these are similar to access-lists by using permit or deny statements but also allow attributes to be matched and set.

Using RouterC are the example, the route maps would look like this (I have added line numbers for reference later on) :

1. RouterC(config)# route-map ospf->rip deny 5

2. RouterC(config-route-map)# match tag 33

3. RouterC(config)# route-map ospf->rip permit 15

4. RouterC(config-route-map)# set tag 44

5. RouterC(config-route-map)# exit

6. RouterC(config)# router rip

7. RouterC(config-router)# redistribute ospf 1 route-map ospf->rip

8. RouterC(config)# route-map rip->ospf deny 5

9. RouterC(config-route-map)# match tag 44

10. RouterC(config-route-map)# route-map rip->ospf permit 15

11. RouterC(config-route-map)# set tag 33

12. RouterC(config)# router ospf 1

13. RouterC(config-router)# redistribute rip route-map rip->ospf

So here any OSPF routes that are being redistributed into RIP have a tag of 44 set (line 4). When RIP is redistributed back into OSPF any tag that matches 44 is denied (lines 8 and 9).

When RIP routes are being redistributed into OSPF they have a tag of 33 set (line 11). These routes are denied (line 1) when being redistributed from OSPF back into RIP (line 2). The ordering of these statements is crucial.

We can see above the tag being added to the routes. Unfortunately I could not get and routes to feedback to show you this in action, sometimes its annoying when things work properly!

Nonetheless, the end result is that routes will not be redistributed back into the routing domain from where they originated.

I hope you have found this useful.