AIGP Translation
Last updated
Last updated
Topology: ine-spv4
Load bgp.aigp.translation.init.cfg
BGP and AIGP are fully setup in the topology, except AIGP is not enabled for EBGP peers on the ASBRs. Find another way to signal the AIGP without enabling AIGP on the ASBR’s EBGP peers. The local AS should send routes in such a way that the remote AS will always use the lowest AIGP value, no matter what the remote AS’s policies look like.
When configuring AIGP, you have the option to encode the AIGP value as either the MED path attribute, or cost-community extended community. This was used to support routers that did not yet support AIGP but had support for these older attributes (cost-community and MED).
You can simply encode the AIGP as the MED using aigp send med. However, this will not be added end-to-end by a receiving router to its nexthop IGP metric, so this does not do us any good. Additionally, the remote AS is free to use LP to override this.
When translating the AIGP into a cost-community, you have two options:
You can use the IGP-cost POI (point of insertion)
This means that the cost-community is considered as a tie-breaker after the IGP metric step and before the lowest RID step.
You can use the pre-bestpath POI
This means that it is the very first path selection step (even before weight). You may be familiar with pre-bestpath cost-community when using EIGRP as a PE-CE protocol for VPNv4.
Translating the AIGP into an IGP-cost POT cost-community doesn’t help us either, as the routers have different IGP metrics to the nexthop. Additionally, the remote AS is free to override this with LP. Our best option is to use the pre-bestpath POI. This is a “big hammer” approach.
It is important to note that encoding the AIGP as a cost-community is the only time that a cost-community can be transitive and be advertised to an eBGP peer.
When using the cost-community we must specify a community ID in the range 0-255. A lower community ID is always preferred among multiple routes with a cost-community attribute. If the community IDs tie, then the value of the cost-community is compared. So we must use the same community ID on at least each ASBR for each AS. It doesn’t matter what number we pick - it is arbitrary.
The configuration is fairly simple. On each ASBR we translate the AIGP value into a pre-bestpath cost-community. The transitive keyword is necessary to allow the router to advertise this extcommunity to eBGP peers. Without this, the router will not advertise the attribute to its eBGP peer.
Then we must send extcommunities to our peers.
On R1 we should see that the pre-bestpath cost-community is seen on all received routes. R1 will not add this value to its own IGP metric to the nexthop. This is now completely different from true AIGP. Instead, this is a way for AS200 to completely override AS100’s decision on how to route traffic to AS200. In a way it sort of forces AS100 to use the MED. (The pre-bestpath value is the same as the MED, but pre-bestpath is the very first path selection step).
Likewise on XR2, it is preferring the path that results in the lowest cost within AS100, not the end-to-end lowest IGP path.
