Overview
BGP AS_PATH Prepending is a key component of eBGP policy that allows engineers to influence the path that traffic takes into our Autonomous System (AS). In this lab we will configure AS_PATH prepending on IOS XRd in Cisco Modeling Labs.
This is the second lab in my series on BGP Policy. We will be picking up where we left off in BGP Policy – Configuring BGP Local Preference on IOS XRd.
Scenario
Our ISP peers with Peer_A and Peer_B. We have settlement-free peering with Peer_A so we do not charge each other for incoming or outgoing traffic. However, Peer_B charges us a premium for sending and receiving traffic. In the previous lab we used local preference to direct our outgoing traffic through Peer_A. However, incoming traffic is still following the default BGP rules. This means that Peer_B is still sending us traffic and charging us for it.
Method
We will configure AS_PATH prepending on IE-2 to lengthen the AS_PATH of our eBGP prefixes that we are advertising to Peer_B. Peer_B also has a path to our AS through Peer_A, but by default it prefers to send traffic directly to us at IE-2. By extending the AS_PATH of the prefixes we advertise to Peer_B, we will force it to send traffic to Peer_A since that will become the “best” route. If we lose our connection to Peer_A, Peer_B will take over and begin forwarding us traffic again.
Equipment
I’ll be using the topology from the previous lab BGP Policy – Configuring BGP Local Preference on IOS XRd. You can download the lab.yaml as well as the individual configuration files here.
- Customer Edge Routers (IOSv)
- CE-1
- CE-2
- Provider Edge Routers (XRd)
- PE-1
- PE-2
- Provider Core Routers (XRd)
- P1
- P2
- Internet Edge Routers (XRd)
- IE-1
- IE-2
- Peer ISP Routers (XRd)
- Peer_A
- Peer_B
Prequel: How Traffic Flows Without AS_PATH Prepending
I ran a couple of traceroutes on Peer_B to confirm that it is forwarding traffic directly to us instead of through Peer_A.
Note: 30.0.0.0/30 had to be advertised into iBGP so that CE-1 and CE-2 could respond to the traceroute.
As you can see, traffic from Peer_B is being sent directly to us via IE-2 at 30.0.0.2. Our goal is to make that traffic go through Peer_A at 20.0.0.5 and then IE-1 at 20.0.0.2.
We can also check the BGP database on Peer_B to confirm that it knows both routes to our network.
We can see that the path through Peer_A is known (path #1), but not the best. This is due to the AS_PATH length. Path #2 has 1 AS hop whereas path #1 has 2 AS hops.
Step 1 – Creating and Applying the Route Policy
Like local preference, we will implement AS_PATH prepending by creating a Route Policy and applying it to our eBGP neighborship with Peer_B. The route-policy command for this on IOS XR is prepend as-path [AS #] [count], where count is the number of AS #s we want added to the path. We are going to use a count of 2 to add 2 AS #s to our AS_PATH.
This configuration only needs to be done on IE-2, since that is the router that peers with Peer_B. The full configuration on IE-2 is as follows:
route-policy PREPEND_PEER_B
prepend as-path 500 2
end-policy
router bgp 500
neighbor 30.0.0.1
address-family ipv4 unicast
route-policy PREPEND_PEER_B out
Once this is committed we can move onto verification.
Step 2 – Verifying the AS_PATH Prepending
I’m going to go back to Peer_B and run the command show bgp ipv4 unicast 10.0.0.0/30 again to show the paths it knows to our network.
As you can see, Path 1 (via Peer_A at 20.0.0.5) is now the best path. Path 2 (via IE-2 at 30.0.0.2) now has an AS_PATH of 500 500 500 which is longer than Path 1’s path of 300 500. Because of this Peer_B will prefer to send traffic destined for our network through Path 1 via Peer_A.
We can verify this by running traceroutes from Peer_B to our CE routers again.
We were successful since Peer_B is sending our inbound traffic through Peer_A at 20.0.0.5 instead of directly to IE-2.
Step 3 – Verifying Fail Over
Like I did in the local preference lab, I am going to disable the link between IE-1 and Peer_A in Cisco Modeling Labs.
With this link disabled, I will run the traceroutes from Peer_B again after giving BGP a moment to reconverge.
As you can see in the event of a failure in the IE-1 <-> Peer_A connection, traffic from Peer_B’s AS will flow directly to us via IE-2 at 30.0.0.2.
Conclusion
We have now successfully implemented AS_PATH prepending on IE-2. As a result, Peer_B now sees all routes advertised from IE-2 as having an AS_PATH of 500 500 500. Since this is longer than the path through Peer_A, Peer_B will forward all of our inbound traffic through Peer_A instead of directly to us. We have also confirmed that if our link to Peer_A fails, then Peer_B will take over delivering our inbound traffic. This allows us to leverage our settlement-free peering with Peer_A and avoid charges from Peer_B while maintaining redundancy.
You can download the completed lab.yaml file as well as router configuration files here.