PDF(78.2 KB) View with Adobe Reader on a variety of devices
ePub(103.1 KB) View in various apps on iPhone, iPad, Android, Sony Reader, or Windows Phone
Mobi (Kindle)(97.7 KB) View on Kindle device or Kindle app on multiple devices
Updated:May 18, 2021
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This document describes how to configure the Accumulated Interior Gateway Protocol (AIGP) metric attribute that is carried by Border Gateway Protocol (BGP) in the Cisco IOS®.
There are no specific requirements for this document.
This document is not restricted to specific software and hardware versions.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
This section provides an overview of the AIGP metric attribute and some important considerations in regards to its use.
AIGP Metric Attribute Overview
Companies might desire to implement a network design where the network is split with multiple Interior Gateway Protocols (IGPs), each with one BGP autonomous system. This is used for scalability reasons, where the network becomes too large for one IGP. The BGP helps to scale when it carries some of the routes that otherwise would be carried by the IGP. The solution that uses AIGP is intended for networks with different BGP autonomous systems under one administrative control.
Here is an example:
The end-to-end service is Multi-Protocol Label Switching (MPLS) VPN. When there is a large number of Provider Edge (PE) routers in the network, the IGP must carry too many routes. The solution is to have BGP carry the loopback interfaces of the PE routers. The solution that is used in order to ensure that the MPLS Label Switched Path (LSP) is not interrupted end-to-end is to use the BGP IPv4 + label. This means that RFC 3107 is used between the PE routers and the border routers, which connects the different IGP domains.
The issue with this solution is that the border routers or the PE routers can no longer make a decision about the best path, based on the shortest metric end-to-end, because there is no longer one IGP that runs throughout the whole network. The solution to this issue is the new BGP attribute, called the Accumulated IGP Metric Attribute or AIGP metric attribute. This BGP non-transitive attribute carries the accumulated metric for the paths so that the BGP speakers receive knowledge of the end-to-end metric for those paths.
The BGP speakers must add the route to the next-hop metric to the current value in the AIGP metric attribute before the route is forwarded.
Note: The comparison of the paths for one route is performed immediately after the comparison of the local preference. Refer to the BGP Best Path Selection Algorithm Cisco document for more details about the BGP Best Path Selection Algorithm.
This solution is similar to the solution where the Multi Exit Discriminator (MED) is set to the IGP metric. However, in this case, step 6 (the lowest MED) decides the best path. This step comes after step 4, where the shortest path decides the best path. The best path is often already found before step 6 is reached. With the AIGP solution, the normal BGP decision is changed so that the AIGP is checked after step 3 in order to determine whether the route was advertised locally. If different neighbor Autonomous Systems (ASs) peer with the BGP speaker, it means that the always-compare-med value must be enabled.
The AIGP metric attribute is specified in RFC 7311, which is the Accumulated IGP Metric Attribute for BGP. In order to carry the AIGP metric value in the cost community, the procedures specified in draft-retana-idr-aigp-cost-community (Use of the Cost Community to carry the Accumulated IGP Metric) are used.
Note: The BGP AIGP metric attributed provides optimal routing in networks where different routing domains are interconnected through the BGP.
Changes to the BGP Best Path Selection Algorithm
When AIGP is used, these changes to the BGP Best Path Selection Algorithm are made:
The BGP Best Path Selection Algorithm is modified in order to compare the AIGP immediately after step 3 (Locally Advertised Routes) and after verification of the next hop is valid.
When the router considers an AIGP path against an AIGP path, then the value of the AIGP metric is added to the metric towards the next-hop.
When the router considers an AIGP path against a non-AIGP path, then the BGP prefers the path with the AIGP attribute by default.
When the lowest IGP metric is compared to the BGP next hop, then the AIGP cost is taken into account.
If the route towards the next hop has an AIGP metric, the metric is added to the IGP metric towards the next hop. This sum is the new IGP metric (interior cost) for the route. This occurs when a BGP route is recursive to another BGP route.
If the IGPs in the network are of different types (Open Shortest Path First (OSPF), Intermediate System-to-Intermediate System (IS-IS), Enhanced Interior Gateway Routing Protocol (EIGRP)), it is unlikely that the metric that results from the use of the AIGP attribute leads to consistent or sensible results. If the same IGP is used in the different domains, then the same metric settings must be used in order to guarantee consistent results.
In order for the border routers or PE routers to have the ability to decide between multiple paths (based on the AIGP derived metric) they must first receive multiple paths. For this reason, you might be required to enable the Additional Path (ADD-Path) or Advertise Best External BGP feature.
The BGP peers that are enabled for AIGP and those that are not are placed into separate update groups. Additionally, the BGP peers that are enabled for AIGP in the cost community are placed into separate update groups.
Solution for Legacy Routers
If there are routers in the network that are not capable of AIGP (legacy routers), then there are two possible solutions:
A router can translate the AIGP to a cost community, attach it to the route, and advertise the route to the legacy router.
A router can translate the AIGP to the MED, attach it to the route, and advertise the route to the legacy router.
This section describes how to configure the AIGP metric attribute.
Enable Transmission of the AIGP Attribute
The AIGP must be enabled explicitly for internal BGP (iBGP) and external BGP (eBGP) sessions with the neighbor ip-address aigp command.
This is how to verify whether the AIGP is enabled for the BGP peer:
P3#show bgp ipv4 unicast neighbors 10.1.9.2 | in AIGP
For address family: IPv4 Unicast
AIGP is enabled
Originate the AIGP
The AIGP can be set to the IGP metric or to a value. Also, the AIGP can be set for some particular routes only for an IGP via a route-map. When the originator of the AIGP sees a change in the IGP metric, it should send a new BGP update with the new AIGP values for the affected routes.
The AIGP metric can automatically be set to the IGP metric or to some arbitrary 32-bit value:
P1(config-route-map)#set aigp-metric ? <0-4294967295> manual value igp-metric metric value from rib
This example shows how to set the AIGP metric to the metric of the IGP route:
ip prefix-list loopback seq 5 permit 10.100.1.1/32 ! route-map redistribute-loopback permit 10 match ip address prefix-list loopback set aigp-metric igp-metric
Knob to Disable AIGP Tie-Breaking
If this knob is enabled, then the BGP does not use AIGP tie-breaking unless both of the paths have the AIGP metric attribute. This means that the AIGP attribute is not evaluated during the best path selection process between two paths when one path does not have the AIGP attribute.
Here is an example:
router bgp 65000 bgp bestpath aigp ignore
Solution for Legacy Routers
If the router PE2 does not have software that supports the AIGP metric attribute (it is a legacy router), then there are two solutions that you can use.
Translation of the AIGP to Cost Community
Configure the routers P3 and P4 in order to translate the IGP cost into a cost community that the router can advertise to a legacy router:
P3#show run | beg router bgp router bgp 65000 address-family ipv4 neighbor 10.1.9.2 activate neighbor 10.1.9.2 send-community both neighbor 10.1.9.2 aigp send cost-community 100 poi igp-cost transitive
P4#show run | beg router bgp router bgp 65000 address-family ipv4 neighbor 10.1.10.2 activate neighbor 10.1.10.2 send-community both neighbor 10.1.10.2 aigp send cost-community 100 poi igp-cost transitive
You must allow the router that sends to send extended communities. This means that you must specify the send-community extended or send-community both attributes (neighbor x.x.x.x send-community) for the BGP peer.
When you view the image provided in the section of this document, you can see that all of the links in the network AS 6500 have an OSPF cost of 10, the links between the routers P1 and P4 and between P2 and P3 have an OSPF cost of 100, and the link between the routers P3 and P1 has a cost of 5.
This is the route for 10.100.1.1/32, as seen on the router P3:
P3#show bgp ipv4 unicast 10.100.1.1 BGP routing table entry for 10.100.1.1/32, version 9 Paths: (2 available, best #1, table default) Additional-path-install Path advertised to update-groups: 5 Refresh Epoch 5 65001 10.100.1.3 (metric 6) from 10.100.1.7 (10.100.1.7) Origin incomplete, metric 0, localpref 100, valid, internal, best Originator: 10.100.1.3, Cluster list: 10.100.1.7 mpls labels in/out 29/16 rx pathid: 0x0, tx pathid: 0x0 Path not advertised to any peer Refresh Epoch 5 65001 10.100.1.5 (metric 21) from 10.100.1.7 (10.100.1.7) Origin incomplete, metric 0, localpref 100, valid, internal, backup/repair, all Originator: 10.100.1.5, Cluster list: 10.100.1.7 mpls labels in/out 29/16 rx pathid: 0x1, tx pathid: 0x1
This is the route for 10.100.1.1/32, as seen on the router P4:
P4#show bgp ipv4 unicast 10.100.1.1 BGP routing table entry for 10.100.1.1/32, version 9 Paths: (2 available, best #2, table default) Additional-path-install Path not advertised to any peer Refresh Epoch 5 65001 10.100.1.3 (metric 16) from 10.100.1.7 (10.100.1.7) Origin incomplete, metric 0, localpref 100, valid, internal, backup/repair, all Originator: 10.100.1.3, Cluster list: 10.100.1.7 mpls labels in/out 29/16 rx pathid: 0x0, tx pathid: 0x1 Path advertised to update-groups: 35 Refresh Epoch 5 65001 10.100.1.5 (metric 11) from 10.100.1.7 (10.100.1.7) Origin incomplete, metric 0, localpref 100, valid, internal, best Originator: 10.100.1.5, Cluster list: 10.100.1.7 mpls labels in/out 29/16 rx pathid: 0x1, tx pathid: 0x0
This is the route for 10.100.1.1/32, as seen on the router PE2:
The best path on the router P3 is the path with the IGP metric 6, with the router P1 as the next hop. The best path on the router P4 is the path with the IGP metric 11, with the router P2 as the next hop. The routers P3 and P4 send their best path towards router PE2. The router PE2 picks the path from the router P4 as the best one, which was decided because both of the BGP paths on the router PE2 are very similar and step 10 was the tie-breaker: the oldest external path won. This means that the traffic from the router PE2 to the router PE1 takes the path PE2-P4-P2-PE1. However, the shortest overall path, when you consider the IGP cost, is PE2-P3-P1-PE1.
Use the information that follows in order to verify the AIGP metric attribute on the routers P3 and P4 towards the router PE2 (10.100.1.7):
If the path that is received from the router P3 is longer than the path that is received from the router P4 on the router PE2, then the router PE2 still picks the path from the router P3 as the best. You can increase the path that the router P3 advertises by one via a route-map and as-prepending.
router bgp 65000 address-family ipv4 neighbor 10.1.9.2 route-map as_path out
route-map as_path permit 10 set as-path prepend last-as 1
The router PE2 now has the route from the router P3 with one extra AS in the AS path:
Because of the AIGP metric attribute, the router PE2 still picks the path from the router P3 as the best. The AIGP check is performed before the AS path length is checked.
If you remove the ability to send the AIGP on the router P4 towards the router PE2, then the router PE2 receives the path without the AIGP metric attribute from the router P4. However, the router PE2 still has the path from the router P3 with AIGP. The router PE2 prefers the path with AIGP over a path without AIGP, and it picks the path from the router P3 as the best: