Configure the AIGP Metric Attribute for BGP

Introduction

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^®.

Prerequisites

Requirements

There are no specific requirements for this document.

Components Used

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.

Background Information

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.

Important Considerations

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.

Configure

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.

Here is an example:

PE2#show bgp ipv4 unicast 10.100.1.1
BGP routing table entry for 10.100.1.1/32, version 6
Paths: (2 available, best #1, table default)
  Advertised to update-groups:
     6        
  Refresh Epoch 2
  65000 65001
    10.1.9.4 from 10.1.9.4 (10.100.1.4)
      Origin incomplete, localpref 100, valid, external, best
      Extended Community: Cost(transitive):igp:100:6
      mpls labels in/out 17/16
      rx pathid: 0, tx pathid: 0x0
  Refresh Epoch 15
  65000 65001
    10.1.10.6 from 10.1.10.6 (10.100.1.6)
      Origin incomplete, localpref 100, valid, external
      Extended Community: Cost(transitive):igp:100:11
      mpls labels in/out 17/30
      rx pathid: 0, tx pathid: 0

As shown, the router PE2 picked the path with the lowest cost (100:6 versus 100:11) as the best path.

Translation of the AIGP to MED

Configure the routers P3 and P4 in order to translate the IGP cost into the MED that the router can advertise to a legacy router.

Here is the configuration on the router P3:

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 med

Here is the configuration on the router P4:

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 med

Verify

The output of the debug bgp ipv4 unicast updates in command shows the usage of the AIGP metric attribute:

PE2#
BGP(0): 10.1.9.4 rcvd UPDATE w/ attr: nexthop 10.1.9.4, origin ?, aigp-metric 22,
 merged path 65000 65001, AS_PATH

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:

PE2#show bgp ipv4 unicast 10.100.1.1
BGP routing table entry for 10.100.1.1/32, version 4
Paths: (2 available, best #2, table default)
  Advertised to update-groups:
     5        
  Refresh Epoch 1
  65000 65001
    10.1.9.4 from 10.1.9.4 (10.100.1.4)
      Origin incomplete, localpref 100, valid, external
      mpls labels in/out 18/17
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 1
  65000 65001
    10.1.10.6 from 10.1.10.6 (10.100.1.6)
      Origin incomplete, localpref 100, valid, external, best
      mpls labels in/out 18/30
      rx pathid: 0, tx pathid: 0x0

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):

Here is the output for the router P3:

router bgp 65000
 address-family ipv4
  bgp additional-paths select all
  bgp additional-paths receive
  bgp additional-paths install
  neighbor 10.1.9.2 activate
  neighbor 10.1.9.2 aigp
  neighbor 10.1.9.2 send-label
  neighbor 10.100.1.7 activate
  neighbor 10.100.1.7 aigp
  neighbor 10.100.1.7 next-hop-self
  neighbor 10.100.1.7 send-label

Here is the output for the router P4:

router bgp 65000
 address-family ipv4
  bgp additional-paths select all
  bgp additional-paths receive
  bgp additional-paths install
  neighbor 10.1.10.2 activate
  neighbor 10.1.10.2 aigp
  neighbor 10.1.10.2 send-label
  neighbor 10.100.1.7 activate
  neighbor 10.100.1.7 aigp
  neighbor 10.100.1.7 next-hop-self
  neighbor 10.100.1.7 send-label

You can see that the router P3 now has:

P3#show bgp ipv4 unicast 10.100.1.1
BGP routing table entry for 10.100.1.1/32, version 30
Paths: (2 available, best #2, table default)
  Additional-path-install
  Path not advertised to any peer
  Refresh Epoch 11
  65001
    10.100.1.5 (metric 21) from 10.100.1.7 (10.100.1.7)
      Origin incomplete, aigp-metric 0, metric 0, localpref 100, valid, internal,
       backup/repair, all
      Originator: 10.100.1.5, Cluster list: 10.100.1.7
      mpls labels in/out 28/31
      rx pathid: 0x1, tx pathid: 0x1
  Path advertised to update-groups:
     5         
  Refresh Epoch 11
  65001
    10.100.1.3 (metric 6) from 10.100.1.7 (10.100.1.7)
      Origin incomplete, aigp-metric 0, metric 0, localpref 100, valid, internal, best
      Originator: 10.100.1.3, Cluster list: 10.100.1.7
      mpls labels in/out 28/30
      rx pathid: 0x0, tx pathid: 0x0

The router P4 now has:

P4#show bgp ipv4 unicast 10.100.1.1
BGP routing table entry for 10.100.1.1/32, version 30
Paths: (2 available, best #1, table default)
  Additional-path-install
  Path advertised to update-groups:
     35        
  Refresh Epoch 11
  65001
    10.100.1.5 (metric 11) from 10.100.1.7 (10.100.1.7)
      Origin incomplete, aigp-metric 0, metric 0, localpref 100, valid, internal, best
      Originator: 10.100.1.5, Cluster list: 10.100.1.7
      mpls labels in/out 16/31
      rx pathid: 0x1, tx pathid: 0x0
  Path not advertised to any peer
  Refresh Epoch 11
  65001
    10.100.1.3 (metric 16) from 10.100.1.7 (10.100.1.7)
      Origin incomplete, aigp-metric 0, metric 0, localpref 100, valid, internal,
       backup/repair, all
      Originator: 10.100.1.3, Cluster list: 10.100.1.7
      mpls labels in/out 16/30
      rx pathid: 0x0, tx pathid: 0x1

The IGP metric for the paths on the routers P3 and P4 did not change, but the router PE2 now receives the routes with the AIGP attribute from the routers P3 and P4.

The router PE2 sees the two paths. Each path has the AIGP attribute, and the path with the lowest AIGP metric attribute now wins:

PE2#show bgp ipv4 unicast 10.100.1.1
BGP routing table entry for 10.100.1.1/32, version 6
Paths: (2 available, best #1, table default)
  Advertised to update-groups:
     5        
  Refresh Epoch 1
  65000 65001
    10.1.9.4 from 10.1.9.4 (10.100.1.4)
      Origin incomplete, aigp-metric 6, localpref 100, valid, external, best
      mpls labels in/out 18/17
      rx pathid: 0, tx pathid: 0x0
  Refresh Epoch 1
  65000 65001
    10.1.10.6 from 10.1.10.6 (10.100.1.6)
      Origin incomplete, aigp-metric 11, localpref 100, valid, external
      mpls labels in/out 18/30
      rx pathid: 0, tx pathid: 0

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:

PE2#show bgp ipv4 unicast 10.100.1.1
BGP routing table entry for 10.100.1.1/32, version 7
Paths: (2 available, best #1, table default)
  Advertised to update-groups:
     5        
  Refresh Epoch 1
  65000 65001 65001
    10.1.9.4 from 10.1.9.4 (10.100.1.4)
      Origin incomplete, aigp-metric 6, localpref 100, valid, external, best
      mpls labels in/out 18/nolabel
      rx pathid: 0, tx pathid: 0x0
  Refresh Epoch 1
  65000 65001
    10.1.10.6 from 10.1.10.6 (10.100.1.6)
      Origin incomplete, aigp-metric 11, localpref 100, valid, external
      mpls labels in/out 18/30
      rx pathid: 0, tx pathid: 0

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:

PE2#show bgp ipv4 unicast 10.100.1.1
BGP routing table entry for 10.100.1.1/32, version 2
Paths: (2 available, best #2, table default)
  Advertised to update-groups:
     6        
  Refresh Epoch 1
  65000 65001
    10.1.10.6 from 10.1.10.6 (10.100.1.6)
      Origin incomplete, localpref 100, valid, external
      mpls labels in/out 17/30
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 1
  65000 65001 65001
    10.1.9.4 from 10.1.9.4 (10.100.1.4)
      Origin incomplete, aigp-metric 6, localpref 100, valid, external, best
      mpls labels in/out 17/nolabel
      rx pathid: 0, tx pathid: 0x0

Note: If you want the router PE2 to ignore the AIGP during the BGP best path selection process, then configure the bgp bestpath aigp ignore command.

Troubleshoot

There is currently no specific troubleshooting information available for this configuration.