As you may remember, the BGP Best Path Algorithm decides how the best path to an autonomous system is selected. Probably the most common value that is used to determine the best path is the AS Path length. When two or more routes exist to reach a particular prefix the default in BGP is to prefer the route with the shortest AS Path length.
If we are a multi-homed customer of one or more service providers, we may prefer that incoming traffic take a particular path to reach our network. Perhaps we have two connections, but one costs only half as much as the other. Or, we may have one fast connection and another, much slower connection that we really only want to use a “backup” if our primary connection is down. Regardless of your reasons, AS path prepending is probably the easiest method that one can use to influence inbound routing to your autonomous system.
Consider the following topology:
In this example, we are AS 67. We are multi-homed to our service providers, AS 88 and AS 99, and have a T1 connection to each. AS 88 and AS 99 also peer directly with each other, and have a 100 Mbit/s connection between them. Because we have been experiencing growth, we have added a third connection, a 100 Mbit/s link between R7 and R8
Due to this huge increase in bandwidth, we would prefer that all (or, at least, the majority) of our incoming traffic come in over this much faster Ethernet connection. Since we have a connection directly to R9, however, this results in a very short AS Path in the BGP table to our prefixes. AS 99 will, by default, send any traffic for AS 67 over this 1.5 Mbit/s T1 connection.
How can we cause R9 to, instead, send any traffic destined to AS 67 over the 100 Mbit/s connection to AS 88? In addition, how can we cause AS 88 to send any traffic destined to AS 67 over the 100 Mbit/s connection to R7 in AS 67? Remember that BGP, unlike some other routing protocols (e.g. EIGRP), does not take bandwidth into consideration when deciding on the best path.
The answer is to use AS Path prepending. When using AS Path prepending, we artificially lengthen the AS Path that we advertise to a neighbor to make them think that the path much longer than it actually is.
I’ve included here the initial configurations for each of the routers to get us to the point where we have established connectivity between all routers. Instead of explaining all these configurations, however, I’ll be jumping straight to the good stuff. It is assumed that, if you are playing with AS Path prepending, you have the requisite knowledge for understand the initial configurations.
Since the IP addresses being used are not illustrated in the diagram, here is a table with the IP addresses we are using:
ROUTER INTERFACE IP/MASK
--------------------------------------
R6 Fa0/0 172.31.67.6/24
Se1/0 172.31.68.6/24
R7 Fa0/0 172.31.67.7/24
Fa0/1 172.31.78.7/24
Se1/0 172.31.79.7/24
R8 Fa0/0 172.31.89.8/24
Fa0/1 172.31.78.8/24
Se1/0 172.31.68.8/24
R9 Fa0/0 172.31.89.9/24
Se1/0 172.31.79.9/24
In addition, each router has a loopback address (with a /24 mask). These /24 networks are being advertised into BGP. The loopback addresses are what we’ll use for testing and verifying proper operation.
Okay, so now that we have basic connectivity, we can get down to the fun stuff. First, let’s get out iBGP adjacency between R6 and R7 up and running and start advertising our loopbacks:
R6(config)# router bgp 67
R6(config-router)# network 172.16.66.0 mask 255.255.255.0
R6(config-router)# neighbor 172.31.67.7 remote-as 67
R6(config-router)# neighbor 172.31.67.7 next-hop-self
R6(config-router)# neighbor 172.31.67.7 soft-reconfiguration inbound
R7(config)# router bgp 67
R7(config-router)# network 172.16.67.0 mask 255.255.255.0
R7(config-router)# neighbor 172.31.67.6 remote-as 67
R7(config-router)# neighbor 172.31.67.6 next-hop-self
R7(config-router)# neighbor 172.31.67.6 soft-reconfiguration inbound
Verification:
R6# sh ip bgp | be Network
Network Next Hop Metric LocPrf Weight Path
*> 172.16.66.0/24 0.0.0.0 0 32768 i
*>i172.16.67.0/24 172.31.67.7 0 100 0 i
R7# sh ip bgp | be Network
Network Next Hop Metric LocPrf Weight Path
*>i172.16.66.0/24 172.31.67.6 0 100 0 i
*> 172.16.67.0/24 0.0.0.0 0 32768 i
Let’s go ahead and get the eBGP adjacency between R8 and R9 in place:
R8(config)# router bgp 88
R8(config-router)# network 172.16.88.0 mask 255.255.255.0
R8(config-router)# neighbor 172.31.89.9 remote-as 99
R8(config-router)# neighbor 172.31.89.9 soft-reconfiguration inbound
R9(config)# router bgp 99
R9(config-router)# network 172.16.99.0 mask 255.255.255.0
R9(config-router)# neighbor 172.31.89.8 remote-as 88
R9(config-router)# neighbor 172.31.89.8 soft-reconfiguration inbound
Now, let’s establish eBGP between R6 and R8 over the T1 connection:
R6(config)# router bgp 67
R6(config-router)# neighbor 172.31.68.8 remote-as 88
R6(config-router)# neighbor 172.31.68.8 soft-reconfiguration inbound
R8(config)# router bgp 88
R8(config-router)# neighbor 172.31.68.6 remote-as 67
R8(config-router)# neighbor 172.31.68.6 soft-reconfiguration inbound
At this point, if we take a look at R9′s BGP tables, we can see that it now has routes for all of the loopback networks:
R9# sh ip bgp | be Network
Network Next Hop Metric LocPrf Weight Path
*> 172.16.66.0/24 172.31.89.8 0 88 67 i
*> 172.16.67.0/24 172.31.89.8 0 88 67 i
*> 172.16.88.0/24 172.31.89.8 0 0 88 i
*> 172.16.99.0/24 0.0.0.0 0 32768 i
We can verify that we have connectivity between R6 and R9. First, we’ll ping, then a traceroute:
R9# ping 172.16.67.1 source 172.16.99.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.67.1, timeout is 2 seconds:
Packet sent with a source address of 172.16.99.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/12/20 ms
R9# traceroute 172.16.67.1 source 172.16.99.1
Type escape sequence to abort.
Tracing the route to 172.16.67.1
1 172.31.89.8 4 msec 4 msec 4 msec
2 172.31.68.6 8 msec 8 msec 12 msec
3 172.31.67.7 4 msec * 20 msec
Make a note of how the 172.16.66.0/24 and 172.16.67.0/24 networks appear in R9′s BGP table, specifically, the AS Path (we’ll be coming back to that shortly):
R9# sh ip bgp | in 172.16.6
*> 172.16.66.0/24 172.31.89.8 0 88 67 i
*> 172.16.67.0/24 172.31.89.8 0 88 67 i
In order for R9 to reach R7, it must pass traffic off to R8 (in AS 88). R8 then passes the traffic to R6 (in AS 67) and R6 will deliver it on to R7. Let’s bring up BGP over the T1 between R7 and R9 and see what happens:
R7(config)# router bgp 67
R7(config-router)# neighbor 172.31.79.9 remote-as 99
R7(config-router)# neighbor 172.31.79.9 soft-reconfiguration inbound
R9(config)# router bgp 99
R9(config-router)# neighbor 172.31.79.7 remote-as 67
R9(config-router)# neighbor 172.31.79.7 soft-reconfiguration inbound
Now’s let look at the same routes (172.16.66.0/24 and 172.16.67.0/24) in R9′s BGP table:
R9# sh ip bgp | in 172.16.6
*> 172.16.66.0/24 172.31.79.7 0 67 i
*> 172.16.67.0/24 172.31.79.7 0 0 67 i
Notice the difference in the AS Path? Previously, the best (albeit, only) path R9 had to get to the 172.16.66.0/24 and 172.16.67.0/24 networks was through AS 88. Now there is a direct connection between AS 67 and AS 99 and this new path is shorter (direct, as opposed to traversing AS 88). Because the new path is shorter, it has been identified as the best path. Let’s run that traceroute again and see the difference:
R9# traceroute 172.16.67.1 source 172.16.99.1
Type escape sequence to abort.
Tracing the route to 172.16.67.1
1 172.31.79.7 4 msec * 28 msec
Now, let’s bring up BGP on the 100 Mbit/s connection between R7 and R8:
R7(config)# router bgp 67
R7(config-router)# neighbor 172.31.78.8 remote-as 88
R7(config-router)# neighbor 172.31.78.8 soft-reconfiguration inbound
R8(config)# router bgp 88
R8(config-router)# neighbor 172.31.78.7 remote-as 67
R8(config-router)# neighbor 172.31.78.7 soft-reconfiguration inbound
All of our BGP adjacencies are up at this point, and traffic is flowing normally. Now it’s time to start making it flow the way we want! Let’s take a look at R8′s BGP table, since it is receiving routes over three connections:
R8# sh ip bgp | be Network
Network Next Hop Metric LocPrf Weight Path
* 172.16.66.0/24 172.31.78.7 0 67 i
* 172.31.89.9 0 99 67 i
*> 172.31.68.6 0 0 67 i
* 172.16.67.0/24 172.31.78.7 0 0 67 i
* 172.31.89.9 0 99 67 i
*> 172.31.68.6 0 67 i
*> 172.16.88.0/24 0.0.0.0 0 32768 i
* 172.16.99.0/24 172.31.78.7 0 67 99 i
* 172.31.68.6 0 67 99 i
*> 172.31.89.9 0 0 99 i
Note that AS 88 has two direct paths to AS 67′s advertised networks (172.16.66.0/24 and 172.16.67.0/24). This is evidenced by the AS Path’s for these two routes (“67 i”). AS 88 has picked the path with a next hop of 172.31.68.6, however. Recall that this is the direct T1 connection between R6 and R8. Why did it choose this path instead of the faster (100 Mbit/s) path?
Earlier I stated “…BGP, unlike some other routing protocols (e.g. EIGRP), does not take bandwidth into consideration when deciding on the best path.” Since the two paths are of the same length, R8 continues its way through the “Best Path Selection Algorithm” and eventually chooses the path that was received first. As we were configuring our BGP sessions earlier, we brought up the T1 connection first. AS 88, therefore, received the path from R6 before it did R7. We could bypass this by bringing up the 100 Mbit/s connection first, however this is not always under our control (think about when a router reloads — which connection will come up first? We really don’t know.)
Our best method, then, to influence the routing of traffic coming into our AS (and, indeed, the whole point of this article) is to manipulate the AS Path that we advertise to BGP neighbors. By causing AS 88 to think that the path to AS 67 over the T1 connection is much longer, we can get it to select the path via the 100 Mbit/s connection. We’ll also need to do the same thing to R9 in AS 99. Remember, we want AS 88 to send us traffic over that 100 Mbit/s connection, and we want AS 99 to send us traffic via AS 88.
This is much easier to configure than it might sound. We’ll use a route-map applied to (certain) outbound BGP sessions from AS 67 to do this for us. We’ll create a route-map named “PREPEND” on both R6 and R7 that will prepend our AS number twice to outgoing route advertisements, then apply it to the BGP sessions over the T1 connections (R6 to R8 and R7 to R9):
R6(config)# route-map PREPEND permit 10
R6(config-route-map)# set as-path prepend 67 67
R6(config-route-map)# router bgp 67
R6(config-router)# neighbor 172.31.68.8 route-map PREPEND out
R7(config)# route-map PREPEND permit 10
R7(config-route-map)# set as-path prepend 67 67
R7(config-route-map)# router bgp 67
R7(config-router)# neighbor 172.31.79.9 route-map PREPEND out
That’s all there is to it! Let’s examine R8′s BGP table now:
R8# sh ip bgp | be Network
Network Next Hop Metric LocPrf Weight Path
*> 172.16.66.0/24 172.31.78.7 0 67 i
* 172.31.68.6 0 0 67 67 67 i
*> 172.16.67.0/24 172.31.78.7 0 0 67 i
* 172.31.68.6 0 67 67 67 i
*> 172.16.88.0/24 0.0.0.0 0 32768 i
* 172.16.99.0/24 172.31.78.7 0 67 99 i
* 172.31.68.6 0 67 67 67 99 i
*> 172.31.89.9 0 0 99 i
Look at the paths for 172.16.66.0/24 and 172.16.67.0/24. Note that the path received from 172.31.68.6 is much longer than the path received from 172.31.78.7. There are three AS numbers in the routes received from 172.31.68.6, even though it is the same AS number. Because this path is now much longer, the shorter path via 172.31.78.7 (our 100 Mbit/s connection) will now be the preferred way to get there.
Let’s see how R9 was affected by all of this:
R9# sh ip bgp | be Network
Network Next Hop Metric LocPrf Weight Path
* 172.16.66.0/24 172.31.79.7 0 67 67 67 i
*> 172.31.89.8 0 88 67 i
* 172.16.67.0/24 172.31.79.7 0 0 67 67 67 i
*> 172.31.89.8 0 88 67 i
* 172.16.88.0/24 172.31.79.7 0 67 67 67 88 i
*> 172.31.89.8 0 0 88 i
*> 172.16.99.0/24 0.0.0.0 0 32768 i
We can see that R9 has received updated routing information as well, evidenced by the paths that are prepended. Now, instead of preferring the direct T1 connection into AS 67, R9 will send any traffic destined for AS 67 to 172.31.89.8 in AS 88. We already know from looking at R8′s BGP table that it will pass the traffic on to AS 67 over the 100 Mbit/s link. Let’s run traceroutes from R9 to verify:
R9# traceroute 172.16.66.1 source 172.16.99.1
Type escape sequence to abort.
Tracing the route to 172.16.66.1
1 172.31.89.8 4 msec 8 msec 8 msec
2 172.31.78.7 4 msec 8 msec 8 msec
3 172.31.67.6 12 msec * 36 msec
R9# traceroute 172.16.67.1 source 172.16.99.1
Type escape sequence to abort.
Tracing the route to 172.16.67.1
1 172.31.89.8 4 msec 4 msec 8 msec
2 172.31.78.7 4 msec * 36 msec
This shows us that traffic is behaving exactly as we intended. The first hop after leaving R9 is 172.31.89.8 (R8). It leaves R8 over the 100 Mbit/s connection arrives at 172.31.78.7 (R7). From there it is sent over R7′s 100 Mbit/s connection to R6 (172.31.67.6).
Success! Our job here is done!
Note: One thing that isn’t apparent from this exercise is the path that traffic from R6 (in AS 67) takes to get to R9 (in AS 99). To illustrate, let’s take a look at a traceroute from R6′s loopback to R9′s loopback:
R6# traceroute 172.16.99.1 source 172.16.66.1
Type escape sequence to abort.
Tracing the route to 172.16.99.1
1 172.31.67.7 4 msec 4 msec 8 msec
2 172.31.79.9 8 msec * 48 msec
Notice anything weird there? Yeah, traffic from R6 is first going to R7, then to R9 over that T1 connection, NOT the much faster 100 Mbit/s connection! How can we change that? The next article will continue on from here and we’ll change the configuration of our routers in AS 67 to address that.
Refer to http://evilrouters.net/
