AS-PATH prepending is an important tool in BGP toolbox to influence the return traffic back to your networks ( or prefixes as they are called with BGP). Let’s get some terminology out of the way first.
Also, a note about load balancing. There is no possible way to create a policy that load balances BGP traffic in a 50/50 manner. There are path selection rules that always come down to preferring a one path over another. The more source and destinations in BGP the better the distribution of traffic. If you have a single route to advertise – then all return traffic will mostly take a single link (aka the best path). If you receive a single default route from your upstream peer, then all your traffic will take a single link from your network. More advertised routes from your network the better the return traffic to your network – More routes received from your upstream peers the better the outbound distribution of traffic from your network. Got it?
Now, lets look at AS-PATH prepending. AS-PATH prepending changes the way that your advertised prefixes appear to the rest of the Internet. The as-path length is evaluated early on in the path select process so this is a powerful tool to use with BGP. The shorter the AS-PATH the more preferred a prefix becomes. AS-PATH prepending is used to make a route less desirable, along a specific path, by making the AS-PATH longer.
Lets look at a simple topology:
The topology shows four routers; R1, R2, R3, R4 – which are all eBGP
peers of each other. We will be doing all of the configuration and
policy changes on R1, but observing the effects of our policy on the
other three routers. I’m using standard eBGP interface peering. By
default, I’ll advertise the 172.16/16 network to the other BGP peers to
make sure everything is working correctly. The relevant configuration
is posted below.
To make sure we at least accomplished what we set out to do, let’s do a quick ping check from R4 to make sure the preferred path is now through R2.
- Prefix(es) – these are your routes or networks in BGP
- Attributes – these are the special BGP values in the advertisement that you can adjust
- BGP Peer/Speaker/Neighbor – these are all essentially neighbors configured as “peers”
Also, a note about load balancing. There is no possible way to create a policy that load balances BGP traffic in a 50/50 manner. There are path selection rules that always come down to preferring a one path over another. The more source and destinations in BGP the better the distribution of traffic. If you have a single route to advertise – then all return traffic will mostly take a single link (aka the best path). If you receive a single default route from your upstream peer, then all your traffic will take a single link from your network. More advertised routes from your network the better the return traffic to your network – More routes received from your upstream peers the better the outbound distribution of traffic from your network. Got it?
Now, lets look at AS-PATH prepending. AS-PATH prepending changes the way that your advertised prefixes appear to the rest of the Internet. The as-path length is evaluated early on in the path select process so this is a powerful tool to use with BGP. The shorter the AS-PATH the more preferred a prefix becomes. AS-PATH prepending is used to make a route less desirable, along a specific path, by making the AS-PATH longer.
Lets look at a simple topology:
Router R1 should now be advertising the 172.16/16 network to peers R2 and R3. Router R4 should be receiving the prefix from R2 & R3.[edit] jparks@J2300-R1# show protocols bgp group ebgp { type external; export advertise-local-subnet; neighbor 10.0.4.6 { description R2; peer-as 65100; } neighbor 10.0.4.13 { description R3; peer-as 65200; } } [edit] jparks@J2300-R1# show policy-options policy-statement advertise-local-subnet { term 1 { from { protocol static; route-filter 172.16.0.0/16 exact; } then accept; } }
The 172.16/16 network is being recieved on R4 from both downstream peers as expected. But it is selecting the path through R3 as the best path back to R1. Why is that? It is because R3 has a lower IP address, 10.0.2.5 for R3 vs 10.0.4.10 for R2. We will use AS-PATH prepending to change the way R4 selects the best path back to 172.16/16. To verify path selection, we can use a simple tool like ping.[edit] jparks@J2350-2-R4# run show route 172.16/16 exact inet.0: 17 destinations, 18 routes (17 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 172.16.0.0/16 *[BGP/170] 00:04:50, localpref 100 AS path: 65200 65000 I > to 10.0.2.5 via ge-0/0/0.40 [BGP/170] 00:04:50, localpref 100 AS path: 65100 65000 I > to 10.0.4.10 via ge-0/0/0.20
This ping verifies that the preferred path is through R3. Now for the fix. I will prepend autonomous system number of Router R1 twice to the advertisement going to R3 only. The advertisement to R2 will be unchanged. The routing policy looks like this:[edit] jparks@J2350-2-R4# run traceroute 172.16.1.1 source 10.0.3.4 traceroute to 172.16.1.1 (172.16.1.1) from 10.0.3.4, 30 hops max, 40 byte packets 1 10.0.2.5 (10.0.2.5) 4.437 ms 6.161 ms 4.442 ms 2 172.16.1.1 (172.16.1.1) 7.021 ms 4.109 ms 3.796 ms
Now, let’s look at the preferred path for R4 back to R1.[edit] jparks@J2300-R1# show policy-options policy-statement advertise-local-and-prepend { term 1 { from { protocol static; route-filter 172.16.0.0/16 exact; } then { as-path-prepend "65000 65000"; accept; } } } [edit] jparks@J2300-R1# show protocols bgp group ebgp { type external; export advertise-local-subnet; neighbor 10.0.4.6 { description R2; peer-as 65100; } neighbor 10.0.4.13 { description R3; export advertise-local-and-prepend; peer-as 65200; } }
What happened to the second path? Should there be two equal paths back to R1? Hmmm… We need to do a little digging around to find the answer. I’m going to guess the problem is at R3.[edit] jparks@J2350-2-R4# run show route 172.16/16 exact inet.0: 17 destinations, 17 routes (17 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 172.16.0.0/16 *[BGP/170] 00:42:23, localpref 100 AS path: 65100 65000 I > to 10.0.4.10 via ge-0/0/0.20
There is the problem. Router R3 sees two equal cost paths back to the 172.16/16 network. Both paths have a AS-PATH length of 3 AS numbers, but the tie breaker is the lowest advertising router IP address (10.0.2.6). This means that the best path from Router R3 to 172.16/16 is R4 -R2 – R1, even though that R3 is directly attached to R1. So why doesn’t R4 see two paths? BGP only advertises the best path for any given prefix to its neighbors. Since Router R3 receives two advertisements and the best path is through R4, R3 doesn’t advertise the 172.16/16 to any neighbors toward its best path (R4).[edit] jparks@J2350-1-R3# run show route 172.16/16 exact inet.0: 18 destinations, 20 routes (18 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 172.16.0.0/16 *[BGP/170] 00:04:05, localpref 100 AS path: 65300 65100 65000 I > to 10.0.2.6 via ge-0/0/0.40 [BGP/170] 00:03:53, localpref 100 AS path: 65000 65000 65000 I > to 10.0.4.14 via ge-0/0/0.10
To make sure we at least accomplished what we set out to do, let’s do a quick ping check from R4 to make sure the preferred path is now through R2.
Router R4 is routing traffic appropriately.[edit] jparks@J2350-2-R4# run traceroute 172.16.1.1 source 10.0.3.4 traceroute to 172.16.1.1 (172.16.1.1) from 10.0.3.4, 30 hops max, 40 byte packets 1 10.0.4.10 (10.0.4.10) 4.781 ms 6.206 ms 5.832 ms 2 172.16.1.1 (172.16.1.1) 4.344 ms 6.407 ms 4.450 ms
