BGP is fully setup in the above topology. OSPF is used as the IGP.
Currently, R1 is taking a higher end-to-end metric path (130) via R3 to XR2’s loopbacks. Use AIGP so that R1 will prefer the lower overall cost (120) via R4.
AIGP (Accumulated IGP) is a “new” path attribute that works like MED but that is cumulative end-to-end. The local IGP cost is added to the AIGP value. This makes for an end-to-end lowest IGP cost decision, instead of only using the MED alone. This assumes that the remote AS’s IGP costs and the local IGP costs are directly comparable.
There are two parts to AIGP: injecting the prefix with the AIGP attribute, and passing this attribute along to peers.
To insert the AIGP path attribute with a prefix, you must do this upon injection. You cannot take an iBGP-learned route and add an AIGP value to it with a route-map. This is why we inject the prefixes at R1 and XR2 with the AIGP value. Another option could be to re-inject the prefixes at the ASBRs with a network statement that has a route-map setting aigp-metric.
Next, you must enable sending and receiving of the AIGP path attribute for each neighbor. We can do this using a peer-policy template on IOS-XE or using the neighbor-group on IOS-XR. Note that we do not technically need to enable this on XR1. The router will process received AIGP path attributes automatically. (But it doesn’t hurt to add it.)
Let’s first examine the issue before we add AIGP. R1’s bestpath to XR2’s prefixes is via R3 due to the lower MED value received from R3 compared to R4.
Above, we can easily see that the end-to-end path via R4 is actually best. The paths though R4 have a MED of 102 with a nexthop metric of 21 = 123. The paths through R3 have a MED of 31 with a nexthop metric of 101 = 132.
R1 sends the update with the AIGP path attribute. Notice this is not a community, it is a full path attribute, just like MED.
The ASBRs in AS200 are not receiving the AIGP yet. We must configure R3 and R4 to send the AIGP to eBGP neighbors and accept the AIGP from R1. We must also configure R5 and R6 to accept the AIGP. Accepting and sending the AIGP value is accomplished using the same single command (aigp).
We can now see the AIGP value on R5 and R6 from their eBGP peers but not from the iBGP path yet. This is because we did not enable AIGP for iBGP sessions in AS200 yet.
AIGP is sort of like a negotiated capability, but it’s not actually negotiated between peers. You simply must enable it on a peer so that the router will locally accept the AIGP PA and send the AIGP PA. You can verify this using show bgp neighbor:
We now configure AIGP everywhere, and configure AIGP on XR2.
Looking at R1 we can see that it has AIGP values for the two paths to XR2 now, and it uses the path via R4 this time because of the lower end-to-end path:
XR2 has better output, because it actually shows the cumulative AIGP value and explicitly states why one path is better than another.
AIGP is inserted in the BGP bestpath decision before the AS_PATH length check. This means that LP is a stronger attribute than AIGP. You can disable AIGP using bgp bestpath aigp ignore under the BGP process on both IOS-XE and IOS-XR. (However, this does not appear to actually work for me on either R1 or XR2. They are still preferring the lower AIGP metric instead of the lower MED.)
Also note that AIGP uses a “missing-as-worst” behavior, in which a path with no AIGP attribute is worse than a path with an AIGP attribute with any value. Also, if two paths have the same AIGP value (after adding the nexthop IGP metric to the AIGP metric), the next step in the path selection process continues like normal.
