In the previous article we talked about BGP Attributes and then how we can use MED (and Local Preference) to influence and control how traffic ingresses and egresses an Autonomous System (AS). But MED and Local Preference are just a couple of a few different techniques, in this article we’re going to explore how AS Path Prepending can be used to make a path (Route) between two AS look “worse” (longer in this case), by artificially adding AS to the AS Path BGP attribute.
So what do we mean by AS Path, well let’s examine what the BGP Route table looks like, notice the final column on the right, AS-Path, this shows the list of AS that this route has come through to get to this particular route. Now in our topology, we currently only have two AS, so in this case the 10.2.0.0/24, 10.2.1.0/24 and 10.2.2.0/24 networks are coming from AS Green (65002), so in the AS-Path, we only see 65002.
But if these networks had instead come from another AS which is connected to AS Green, but not directly to AS Blue, then the AS-Path attribute would contain 65002 and say 65003 (if that were the ASN of another AS).
As we learned in the previous article, the AS Path Length (4) BGP Attribute is used to decide on which path is “best”, we’re going to manipulate this attribute to make our Router A ↔ Router C path look less desirable than the Router B ↔ Router D path, ergo, so our Router A ↔ Router C path will act as the “BACKUP PATH”.
* tris-routerG.1 # show bgp route all
Routes:
Destination Peer Next-Hop LPref Weight MED AS-Path
----------------------------------------------------------------------------------------
*>i 10.1.0.0/24 1.1.1.1 1.1.1.1 100 1 0
*>i 10.1.1.0/24 1.1.1.2 1.1.1.2 100 1 0
*>i 10.2.0.0/24 1.1.1.1 192.168.100.10 100 1 0 65002
i 10.2.0.0/24 1.1.1.2 192.168.100.14 100 1 0 65002
*>i 10.2.1.0/24 1.1.1.1 192.168.100.10 100 1 0 65002
i 10.2.1.0/24 1.1.1.2 192.168.100.14 100 1 0 65002
*>i 10.2.2.0/24 1.1.1.1 192.168.100.10 100 1 0 65002
i 10.2.2.0/24 1.1.1.2 192.168.100.14 100 1 0 65002
...Current Network Topology
We have the topology from the previous article. Nothing has really changed, but what we have done is stated that we want the link between Router A and Router C to be the “backup” path. And we want the link between Router B and Router D to be the “primary” path.
Currently, however if you were to ping from Router G to the Router H (or vice versa) you’d find that it would favour the “BACKUP PATH”, in this article we’re going to explore techniques to influence and control this routing path to how we want it to work.
Path Selection
There are a number of different options for path selection, the key thing to remember is it is influence rather than command. You don’t own the remote Autonomous System (AS) so we can only attempt to influence the best path selection within their network, they are the owners of it though!
We’re going to investigate how we can influence the best path selection by use of AS Path Prepending to basically make the route via Router A ↔ Router C look artificially longer than the one via Router B ↔ Router D by adding another AS into the AS-Path attribute.
AS Path Prepending
So, the first thing you may be asking is we only have two AS’s, how are we going to add another one into the path when we only have 2 in the first place, well, there is nothing saying they all the AS’s in the path have to be unique! You can have the same AS twice (or more if you wanted to), so in our case we’ll create a policy that will add AS Blue (65001) twice to the AS-Path of the routes being sent from Router A to Router C.
Router A
Create a policy as follows:
edit policy BACKUPROUTE-OUTThen add the following content to the policy, you’ll also notice we’re using the supernet for the AS Blue, summarised to 10.1.0.0/16, this is just so we can ensure that any new routes we might add are also included, without us needing to go back and add it manually to this policy. There is also a catch-all, so any other routes will be transmitted, without the extra AS added to the AS-Path attribute . If you don’t add the catch-all, any routes that don’t match the first statement won’t be transmitted at all; which may or may not be what you want, in our case that is not what we want!
entry BACKUPROUTE-OUT {
if match any {
nlri 10.1.0.0/16;
}
then {
as-path 65001;
permit;
}
}
entry BACKUPROUTEOUT-ALL {
if match any {
}
then {
permit;
}
}Check the policy is okay with:
check policy BACKUPROUTE-OUTThen apply it to the BGP Neighbour (peer) configuration between Router A and Router C.
configure bgp neighbor 192.168.100.10 route-policy out BACKUPROUTE-OUTRefresh it with:
refresh policy BACKUPROUTE-OUTThe policy is now applied, so that any routes sent to the BGP Neighbour peer 192.168.100.10, will now have an additional AS added to the AS-Path attribute, so it should show up saying “65001 65001” when examined on Router C, rather than just “65001” as it did previously. But, we’ll check this shortly, there’s something else we need to consider first!
Local Preference
Wait, what why are we moving onto Local Preference? Well, same reason as in the previous article. We need to ensure the paths are symmetrical.
We can illustrate this by looking at the route tables of Router G and Router H, we should be able to track the same path of intermediate routers between them in each direction, but if we have a look we can see this is not the case.
- Router G’s path between RouterG-LAN1 (10.1.2.0/24) is: Router G → Router A → Router C → Router H.
- Router H’s path to RouterG-LAN1 (10.1.2.0/24) is: Router H → Router D – Router B → Router G.
That’s not what we want, although asymmetric routing can sometimes be useful, we want our path to be more deterministic through the network, in the current situation the traffic going between Router G and Router H (and vice-versa) would take one path outbound leg and another on the inbound leg.
So the “AS Path Prepending” technique allows us to influence how the receiving AS will ingress traffic into our AS by making a particular route look less favourable (in our case making the Router A ↔ Router C look less favourable), however, this only deals with ingress traffic (into AS Blue 65001), not how AS Blue 65001 sends the traffic out to AS Green (65002).
So we’ll do the same thing as we did on the previous article and add a policy.
Router A
Create a new policy as follows and apply on the inbound to the BGP Neighbour (peer).
You’ll also notice we’re using the supernet for the AS Green, summarised to 10.2.0.0/16, this is just so if the administrator of AS Green were to add any new networks, we’d not need to add them manually to the policy. Of course, you may not always be able to do this, but this is where communication between the administrators of each AS becomes important to ensure each other’s configurations “dovetail” as much as possible.
entry BACKUPROUTE-IN {
if match all {
nlri 10.2.0.0/16 ;
}
then {
local-preference 50 ;
permit ;
}
}Then apply it to the BGP Neighbour (peer) configuration between Router A and Router C.
configure bgp neighbor 192.168.100.10 route-policy in BACKUPROUTE-INYou may need to refresh with: “refresh policy BACKUPROUTE-IN”, but now if we examine the route table on Router A, we can indeed see that the routes being learned from Router C now have a Local Preference (LPref) applied to them.
In this case the higher the preference the more favourable the route/path, the lower the preference the less favourable the route/path.
* tris-routerA.14 # show bgp routes all
Routes:
Destination Peer Next-Hop LPref Weight MED AS-Path
----------------------------------------------------------------------------------------
*>i 10.1.1.0/24 1.1.1.2 1.1.1.2 100 1 0
*>i 10.1.2.0/24 1.1.1.7 1.1.1.7 100 1 0
*>i 10.2.0.0/24 1.1.1.2 192.168.100.14 100 1 0 65002
i 10.2.0.0/24 192.168.100.10 192.168.100.10 50 1 0 65002
*>i 10.2.1.0/24 1.1.1.2 192.168.100.14 100 1 0 65002
i 10.2.1.0/24 192.168.100.10 192.168.100.10 50 1 0 65002
*>i 10.2.2.0/24 1.1.1.2 192.168.100.14 100 1 0 65002
i 10.2.2.0/24 192.168.100.10 192.168.100.10 50 1 0 65002
Flags: (*) Preferred BGP route, (>) Active, (d) Suppressed, (h) History
(s) Stale, (m) Multipath, (u) Unfeasible
Origin: (?) Incomplete, (e) EGP, (i) IGPVerify
Now let’s examine Router C’s route table, Router C is the peer of Router A, and will be getting the AS Path Prepending. And, yes as you can see there it is, notice that some of the route’s i.e. those with “next-hop” of 192.168.100.9 (i.e. Router A) have an extra AS specified in the path, which makes these routes/paths look longer, and therefore worse.
You can also see therefore that Router C has selected the other route via the next-hop 192.168.100.13 (i.e. Router B) as the “best” path to the AS Blue 65001.
So, the AS Path Prepending at least is working as we want.
OK, so now let’s examine Router G and Router H’s view of the routes, because we want to run some tests between these two routes, it’s what these two see in their route tables is what matters to us in this particular example.
Router G being within AS Blue 65001, should, because of the Local Preference we are setting on Router A, be seeing that the “best” route to the 10.2.0.0/16 networks (in AS Green 65002) as being via Router B ↔ Router D link, which as you can see it is indeed! Additionally, because of our manipulation of the AS Path attribute we are influencing AS Green 65002 to select the Router B ↔ Router D link as the “best” route to the 10.1.0.0/16 networks.
Nice, that shows two things, firstly that the AS Path Prepending is working as we want, and secondly that the paths between Router G and Router H are symmetric, each leg of a connection between these networks (i.e. send and recieve) will go via our “PRIMARY ROUTE” (Router B ↔ Router D) as we also want (thanks to the Local Preference we are also adding).
Also note that we don’t see the extra AS-Path attributes on Router H, we only see these on Router C, this is because Router C is the router actually getting these routes directly from Router A, and so from Router H’s point of view, it’s got these routes from Router C, and Router C isn’t picking it as the best path, so neither is Router H.
Let’s now remove the policies from Router A (AS Path Prepending and Local Preference) and then re-examine the route tables, and see what has changed (i.e. back to before we did anything).
And as you can see, the best path has returned to the Router A ↔ Router C link, which is not what we want, but demonstrates we have successfully manipulated the routes as we wanted via AS Path Prepending.
Conclusion
We’ve seen how AS Path Prepending can be used to attempt to influence the other AS to use the entry point to our network we want others to use. Additionally, we’ve looked at how Local Preference can be used within our own network to control the routing in association with MED to ensure a symmetric routing path.