AIGP
AIGP
Introduction
IETF has recently introduced a draft document which describes a new BGP Path Attribute called Accumulated IGP (AIGP). The idea is fairly simple - if a network of multiple, contiguous BGP ASes is managed by a single administrative domain, the BGP speakers can perform a best path-selection for a prefix based on IGP metric even if the nodes are in two different ASes. The draft calls the set of ASes as an "AIGP Administrative Domain".
AIGP Attribute
AIGP is an optional, non-transitive attribute and the type code is 26. The format of the attribute is shown below -
In the Attribute Flags (1 byte long), the high-order bit indicates Optional bit (set to 1) and the second high-order bit indicates Non-Transitive bit (set to 0). The AIGP attribute is encoded in the value field of the TLV. The AIGP TLV type is set to 1 and the IGP metric value is 4 bytes.
Network Topology
Consider the following network topology.
Routers R2, R3, R4, R6 and R9 form a single IGP administrative domain and configured with BGP AS numbers as shown in the figure. In this network,
- R2 has EBGP session with R4
- R3 has EBGP session with R6
- R9 has EBGP sessions with R4 and R6
The arrows indicate the metric within the domain to reach other BGP speaker, for example, distance from R2 to R4 is 10.
Of particular interest in this article is the prefix 1.1.1.1/32 advertised by R1. Here, OSPF is used to demonstrate the functionality of carrying IGP metric, but other IGPs like ISIS, iBGP, eBGP and Static routes are supported.
AIGP is disabled for eBGP session by default.
R2 and R3 run OSPF with R1 and learn prefix 1.1.1.1/32 via normal OSPF procedures. On these routers, OSPF is redistributed into BGP. The configuration of R2 (IOS-XR) is shown below -
R2 configuration
router bgp 200
bgp router-id 2.2.2.2
address-family ipv4 unicast
redistribute ospf 110 route-policy SET_AIGP
!
neighbor 4.4.4.4
remote-as 400
ebgp-multihop 255
update-source Loopback0
address-family ipv4 unicast
aigp
route-policy EBGP in
route-policy EBGP out
!
route-policy EBGP
pass
end-policy
!
route-policy SET_AIGP
set aigp-metric igp-cost
end-policy
!
Note that AIGP is enabled under the AFI IPv4. Also, a route-policy is configured to set the OSPF cost into AIGP attribute during redistribution. A similar configuration on R3 applies with eBGP session to R6, and hence not shown here for brevity.
Next, the configuration of R4 (IOS-XR) is shown.
R4 Configuration
router bgp 400
bgp router-id 4.4.4.4
address-family ipv4 unicast
!
neighbor 2.2.2.2
remote-as 200
ebgp-multihop 255
update-source Loopback0
address-family ipv4 unicast
aigp
route-policy EBGP in
route-policy EBGP out
!
!
neighbor 9.9.9.9
remote-as 900
ebgp-multihop 255
update-source Loopback0
address-family ipv4 unicast
aigp
route-policy EBGP in
route-policy EBGP out
!
Note that AIGP must be enabled on all routers, otherwise, the receiving router will ignore the attribute due to non-transitive nature.
Verification
Let's first verify the metric of the prefix 1.1.1.1/32 on R2 and R3.
RP/0/RSP0/CPU0:R2# show route 1.1.1.1/32
Thu Aug 15 12:56:35.745 UTC
Routing entry for 1.1.1.1/32
Known via "ospf 110", distance 110, metric 2, type intra area
Installed Aug 15 11:29:06.754 for 01:27:29
Routing Descriptor Blocks
172.1.2.1, from 1.1.1.1, via GigabitEthernet0/0/1/0.12
Route metric is 2
No advertising protos.
RP/0/RSP0/CPU0:R3# show route 1.1.1.1/32
Thu Aug 15 12:56:15.297 UTC
Routing entry for 1.1.1.1/32
Known via "ospf 110", distance 110, metric 2, type intra area
Installed Aug 15 11:35:14.626 for 01:21:00
Routing Descriptor Blocks
172.1.3.1, from 1.1.1.1, via GigabitEthernet0/0/1/0.13
Route metric is 2
No advertising protos.
Both routers learn the prefix 1.1.1.1/32 as OSPF route with a metric of 2. Next, let's check that when R2 and R3 advertise the prefix in BGP, what is the AIGP metric as received by R4 and R6 in BGP UPDATE message.
RP/0/RSP0/CPU0:R4# show bgp ipv4 unicast 1.1.1.1/32
Thu Aug 15 13:03:35.010 UTC
BGP routing table entry for 1.1.1.1/32
Versions:
Process bRIB/RIB SendTblVer
Speaker 5 5
Last Modified: Aug 15 11:28:50.879 for 01:34:44
Paths: (1 available, best #1)
Advertised to update-groups (with more than one peer):
0.2
Path #1: Received by speaker 0
Advertised to update-groups (with more than one peer):
0.2
200
2.2.2.2 (metric 10) from 2.2.2.2 (2.2.2.2)
Origin incomplete, metric 2, localpref 100, aigp metric 2, valid, external, best, group-best
Received Path ID 0, Local Path ID 1, version 5
Origin-AS validity: not-found
Total AIGP metric 12
RP/0/RSP0/CPU0:R6# show bgp ipv4 unicast 1.1.1.1/32
Thu Aug 15 13:03:03.527 UTC
BGP routing table entry for 1.1.1.1/32
Versions:
Process bRIB/RIB SendTblVer
Speaker 3 3
Last Modified: Aug 15 11:38:00.866 for 01:25:02
Paths: (2 available, best #1)
Advertised to update-groups (with more than one peer):
0.2
Path #1: Received by speaker 0
Advertised to update-groups (with more than one peer):
0.2
300
3.3.3.3 (metric 25) from 3.3.3.3 (3.3.3.3)
Origin incomplete, metric 2, localpref 100, aigp metric 2, valid, external, best, group-best
Received Path ID 0, Local Path ID 1, version 3
Origin-AS validity: not-found
Total AIGP metric 27
Both routers receive the AIGP metric value of 2. Note the total AIGP metric is the AIGP metric plus the IGP metric to the BGP speaker. R4 finds the route to R2, and increases the AIGP attribute value to original attribute value (2) + the IGP distance to R2 (10). Hence, the term accumulated IGP metric. Same is true for R6.
At this point, the AIGP metric value as advertised by R2 and R3 cannot be re-advertised as it is due to the attribute being non-transitive (a receiving AS cannot re-advertise a non-transitive attribute across its AS border). However, if the value is reset or changed, it can be re-advertised. Let's check what R9 receives as the AIGP metric from R4 and R6.
RP/0/RSP0/CPU0:R9# show bgp ipv4 unicast 1.1.1.1/32
Thu Aug 15 13:09:58.585 UTC
BGP routing table entry for 1.1.1.1/32
Versions:
Process bRIB/RIB SendTblVer
Speaker 4 4
Last Modified: Aug 15 11:29:55.925 for 01:40:02
Paths: (2 available, best #1)
Advertised to update-groups (with more than one peer):
0.2
Path #1: Received by speaker 0
Advertised to update-groups (with more than one peer):
0.2
400 200
4.4.4.4 (metric 25) from 4.4.4.4 (4.4.4.4)
Origin incomplete, localpref 100, aigp metric 12, valid, external, best, group-best
Received Path ID 0, Local Path ID 1, version 4
Origin-AS validity: not-found
Total AIGP metric 37
Path #2: Received by speaker 0
Not advertised to any peer
600 300
6.6.6.6 (metric 15) from 6.6.6.6 (6.6.6.6)
Origin incomplete, localpref 100, aigp metric 27, valid, external, group-best
Received Path ID 0, Local Path ID 0, version 0
Origin-AS validity: not-found
Total AIGP metric 42
As seen above, the AIGP metrics are accumulated IGP costs to the BGP speakers.
Best Path Selection
AIGP attribute impacts the BGP best path selection process by considering the AIGP metric after the local-preference rule. So, if local-preference for a prefix is same, AIGP metric is considered as a tie-breaker. The interior cost rule is also impacted. Without AIGP enabled, the rule is to prefer the path with lowest IGP metric to the BGP next-hop. However, with AIGP enabled, the resolving AIGP metric is added to the interior cost to the BGP next-hop.
So, in this case, R9 installs the path with lowest AIGP metric.
RP/0/RSP0/CPU0:R9# show route 1.1.1.1/32
Thu Aug 15 13:26:31.520 UTC
Routing entry for 1.1.1.1/32
Known via "bgp 900", distance 20, metric 37 (AIGP metric)
Tag 400, type external
Installed Aug 15 11:29:56.187 for 01:56:35
Routing Descriptor Blocks
4.4.4.4, from 4.4.4.4, BGP external
Route metric is 37
No advertising protos.
Summary
AIGP is definitely meant for corner-cases. The draft mentions those use cases and the applicability of AIGP attribute. This also requires the BGP speakers to understand this attribute otherwise it will be discarded during further re-advertisement.
References: