In this post we will look at something which is relatively new but not as cool as my previous post on Segment Routing. We will take a look at a new BGP feature called “Accumulated IGP, metric of path to prefix” (RFC 7311 AIGP) which is an optional non-transitive attribute . A new AIGP TLV was created for this which contains the metric.
Today there many networks out there which are in a single administrative domain, but sub-divided into multiple ASN’s for various reasons. May be because the IGP doesn’t scale, one NSP bought another NSP but they still haven’t merged their BGP ASN’s internally, different business divisions have their own separate network internally etc. In networks like these, it can be useful to allow BGP to make its decisions based on the IGP metric, so that BGP chooses the shortest end-to-end path between two nodes, even if the nodes are in two different ASN’s.
One could argue that we have BGP MED which deal with similar problem space, so what’s the need for BGP AIGP. So in order to bring clarity, we will first take a look at a sample problem, try to solve that with BGP MED and then look at BGP AIGP.
So below is ACME network, which is sub-divided into two BGP ASN’s, ASN 1 and ASN 2. They are peering at ASBR’s and the link IGP costs are representing bandwidth. The goal here is to have an end-to-end optimal path between PE1 and PE21.
Solution with MED
So what ACME did was that they set MED 40 for prefix 220.127.116.11 /32 on ASBR21 and MED 20 on ASBR 22 representing there IGP cost for the prefix
So when PE1 receives two routes, one from ASBR11 and another from ASBR12, it goes through its BGP best path selection and picks the next-hop with lowest MED i.e. ASBR12. But the problem is that end to end path from PE1 to PE21 is not through ASBR12 but through ASBR11.
So how nice it would be if BGP considers the end-to-end IGP cost while choosing a path. Situations like this is where AIGP attribute can help us.
In our topology PE1, ASBR11, ASBR12, ASBR21, ASBR22 and PE21 are running BGP and we will enable AIGP attribute on all the BGP neighbor’s.
Once we enable AIGP on eBGP neighbor relationships between ASBR’s and iBGP between PE<=>ASBR’s. ASBR21 and ASBR22 advertise the Prefix 18.104.22.168 /32 to their respective ASBR’s in ASN1 with aigp-metric which contains the IGP-Cost to PE21. When PE1 receives the Prefix 22.214.171.124 /32 with AIGP Metric 30 and 20 from ASBR21 and ASBR22 respectively, representing the IGP cost to PE21 in ASN 2, PE1 adds the IGP cost to the ASBR11 and ASBR12 and chooses the BGP NH i.e. ASBR11 which is on end to end optimal path from an IGP cost perspective.
So we saw that how AIGP can help us in choosing an end-to-end optimal path in a network with two different ASN’s. One caveat though, If a user set an AIGP
Value to represent IGP metric, it can cause BGP route churn if there is a change in the IGP cost. Obviously this is not recommended for Internet or external peering as this breaks the basic principle of scaling, i.e. That changes with only local significance must not have global effects.
BGP Best Path selection
BGP best path selection has been modified to put BGP AIGP after BGP local preference. So if we revisit our topology, in which, if we are doing AS Path prepend on ASBR21, PE1 is still going to look at first the lowest AIGP metric value. Recall that if we would have been MED, PE1 would have preferred ASBR12 as best BGP NH over ASBR11, since MED comes after AS path.
So the modified BGP Best path on Cisco should look like this
- BGP AIGP
- Locally originated Routes
- AS Path
- Lowest Origin type
- eBGP over iBGP
- IGP to next hop
- Blah Blah
But I don’t see AIGP being mentioned anywhere yet on Cisco’s website, though they support AIGP attribute. So maybe its time to update it and also the interview responses when people ask BGP best path selection in there interviews :).
Junos document reflects the modified BGP best path selection appropriately.
Hopefully this post give you a brief overview of the problem space where BGP AIGP attribute can be helpful. For sure this attribute was developed to solve certain niche use-cases and doesn’t apply to everyone.