irp demo
Request Noction IRP Demo

Request a personalized demo/review session of our Intelligent Routing Platform

irp trial
Start Noction IRP Trial

Evaluate Noction IRP, and see how it meets your network optimization challenges

nfa demo
Noction Flow Analyzer Demo

Schedule a one-on-one demonstration of our network traffic analysis product

nfa trial
Free Noction Flow Analyzer Trial

Test drive NFA today with your own fully featured 30-day free trial

Accumulated IGP and BGP

IGP Interior Gateway Protocol and BGP Border Gateway ProtocolRFC 7311 defines an optional non-transitive BGP attribute called the Accumulated IGP Metric Attribute (AIGP).

As we know, IGP stands for Interior Gateway Protocol and represents a group of routing protocols that run within a single administrative domain. IGP selects the shortest path between the two nodes based on distance. The distance here is a sum of metrics of all the links that belong to a given path. Each link is assigned a particular metric value. For instance, OSPF default cost for 1GB, 100MB and loopback interfaces is 1 while the default cost for 10MB link is 10.

Note: BGP routers that do not support the optional non-transitive attributes (e.g. AIGP) must delete such attributes and must not pass them to other BGP peers.

We will discuss AIGP and BGP using the network topology depicted in Picture 1. All routers are running within a single AIGP administration domain that consists of autonomous systems (AS) 200, 300, 400 and 500. According to RFC 7311, AIGP administrative domain is a set of ASes in a common administrative domain. The RFC specifies when a single administration domain is divided into several ASes and when BGP is used for routing between the ASses. For example, BGP might be used when IGP does not scale well or when a finely grained routing policy is desired, one that can not be supported by IGP.  AIGP allows BGP to perform its routing based on the IGP metric so that BGP chooses the shortest path between the two nodes, even if these nodes are in two different ASes within that same administrative domain.

Accumulated IGP

Picture 1: Network Topology


XR1 Configuration

interface Loopback0
 ipv4 address 1.1.1.1 255.255.255.255

interface GigabitEthernet0/0/0/0
 ipv4 address 10.0.0.1 255.255.255.252

interface GigabitEthernet0/0/0/1
 ipv4 address 10.0.0.5 255.255.255.252

The cost must match on both sides of a link.

router ospf MY_OSPF
 area 0
  interface Loopback0

  interface GigabitEthernet0/0/0/0
   cost 40

  interface GigabitEthernet0/0/0/1
   cost 10

The XR2 and XR3 routers redistribute the OSPF 1.1.1.1/32 route into BGP. We will show only the configuration of XR2 and skip the XR3 configuration as they are similar. In regards to the configuration of XR4, it contains only the basic BGP configuration so we will skip it as well.

XR2 Initial Configuration

interface GigabitEthernet0/0/0/0
 ipv4 address 10.0.0.2 255.255.255.252

interface GigabitEthernet0/0/0/1
 ipv4 address 10.0.0.13 255.255.255.252

Route policies are mandatory for eBGP peers to import and export routes. The route-policy PASS passes all routes for processing.

ip route 10.0.0.0 255.255.255.0 Null0
route-policy PASS
  pass
end-policy

Route policy 1.1.1.1 allows only the OSPF route 1.1.1.1/32 to be redistributed into BGP.

route-policy 1.1.1.1
  if destination in (1.1.1.1/32) then
    pass
  else
    drop
  endif
end-policy

router ospf MY_OSPF
 area 0
  interface GigabitEthernet0/0/0/0
   cost 40

router bgp 200
 bgp router-id 2.2.2.2
 address-family ipv4 unicast
  redistribute ospf MY_OSPF route-policy 1.1.1.1

The route-policy PASS is applied to eBGP neighbors XR2 and XR3 for both inbound and outbound routes.

neighbor 10.0.0.1
  remote-as 100
  address-family ipv4 unicast
   route-policy PASS in
   route-policy PASS out

 neighbor 10.0.0.14
  remote-as 500
  address-family ipv4 unicast
   route-policy PASS in
   route-policy PASS out

XR5 Initial Configuration

interface Loopback0
 ipv4 address 5.5.5.5 255.255.255.255

interface GigabitEthernet0/0/0/0
 ipv4 address 10.0.0.14 255.255.255.252

interface GigabitEthernet0/0/0/1
 ipv4 address 10.0.0.18 255.255.255.252

Route policy EBGP matches the route 1.1.1.1/32 and is applied to the outbound routes for eBGP peers XR2 and XR4.

route-policy EBGP
  if destination in (5.5.5.5/32) then
    pass
  else
    drop
  endif
end-policy

route-policy PASS
  pass
end-policy

router bgp 500
 address-family ipv4 unicast
  network 5.5.5.5/32

 neighbor 10.0.0.13
  remote-as 200
  address-family ipv4 unicast
   route-policy PASS in
   route-policy EBGP out

 neighbor 10.0.0.17
  remote-as 400
  address-family ipv4 unicast
   route-policy PASS in
   route-policy EBGP out

Let’s inspect the BGP table of XR5 (Picture 2). Prefix 1.1.1.1/32 is the object of our interest. As we have expected, BGP best-path selection process prefers the shortest AS path 200 via the next-hop 10.0.0.13 (XR2) to the longer AS_PATH via AS 400, 300 (XR4).

BGP Table of XR5

Picture 2: BGP Table of XR5


BGP does not use a metric to select the best path as OSPF does. Instead, it prefers a path based on the below listed criteria in a specific order:

  1. the highest WEIGHT (Cisco only).
  2. the highest LOCAL_PREF.
  3. the path that was locally originated via a network or an aggregate BGP subcommand or through a redistribution from an IGP.
  4. the shortest AS_PATH.
  5. the lowest origin type
  6. the lowest multi-exit discriminator (MED)

etc.

In our case, both routes have the same weight 0, local pref 100 and both have been redistributed from IGP.  Therefore, the shortest AS_PATH is a real tie-breaker here. BGP would choose the shortest path between the nodes, even if the nodes were in different ASes. As a result, the south path (XR5-XR4-XR3-XR1) with a higher bandwidth would be preferred by the BGP best-path selection algorithm to the north path via XR2.

In our case, it would be more convenient for XR5 to perform a best path-selection process based on an IGP metric. For the AIGP metric to be considered first, AIGP criterion must be presented closer to the top of the list, above the shortest AS_PATH.

In some cases, MED could be chosen to carry a value based on the IGP metrics, however it has a lower priority than the shortest AS_PATH criterion so we cannot use it. Instead, we will configure BGP to use the AIGP attribute that carries accumulated IGP metric. When the AIGP attribute is enabled the list changes and looks the following way:  

  1. the highest WEIGHT (Cisco only).
  2. the highest LOCAL_PREF.
  3. the path that was locally originated via a network or aggregate BGP subcommand or through redistribution from an IGP.
  4. the path with the lower AIGP attribute.
  5. the shortest AS_PATH.
  6. the lowest origin type
  7. the lowest multi-exit discriminator (MED)

etc.

AIGP Configuration on XR2

A route-policy SET_AIGP is used to set the OSPF cost into AIGP attribute during the redistribution of OSPF routes.

route-policy SET_AIGP
  if destination in (1.1.1.1/32) then
    set aigp-metric igp-cost
  else
    drop
  endif
end-policy

Redistribute OSPF routes with OSPF cost into AIGP.

router bgp 200
 bgp router-id 2.2.2.2
 address-family ipv4 unicast
  redistribute ospf MY_OSPF route-policy SET_AIGP

AIGP must be enabled on all routers, otherwise, the receiving router will ignore the attribute due to its non-transitive nature.

neighbor 10.0.0.1
  remote-as 100
  address-family ipv4 unicast
   aigp
   route-policy PASS in
   route-policy PASS out

 neighbor 10.0.0.14
  remote-as 500
  address-family ipv4 unicast
   aigp
   route-policy PASS in
   route-policy PASS out

AIGP Configuration on XR3, XR4 and XR5

The configuration of XR3 is very similar to the XR2 one, so we will not show it. As for XR4 and XR5, we only need to enable the AIGP feature for ipv4 address family for all BGP peers.

Let’s inspect the BGP of XR5 (Picture 3). The XR5 router prefers the route 1.1.1.1./32 learned from the BGP peer 10.0.0.17. This route is installed into the routing table of XR5. The south path (XR5-XR4-XR3-XR1) is used to deliver traffic to the 1.1.1.1 prefix even though the AS path is longer than the AS path in the route learned from 10.0.0.13 (XR2). The AIGP metric is now taken into the account by the BGP best path selection process before the AS_PATH criterion.

BGP Table of XR5

Picture 3: BGP Table of XR5


Picture 4 reveals the reason why the BGP route 1.1.1.1/32 learned from XR4 is installed into the routing table of XR5. The AIGP metric learned from the BGP peer 10.0.0.17 (XR4) is 11 (1+10) while the AIGP metric learned from BGP peer 10.0.0.13 (XR2) is 41 (1+40). The fourth criterion states that the path with the lower AIGP attribute is preferred. Therefore, BGP selects a path to the 1.1.1.1./32 prefix via 10.0.0.17 (XR4) as the best path.

BGP Table of XR5 for 1.1.1.1/32

Picture 4: BGP Table of XR5 for 1.1.1.1/32


The OSPF cost reflects the bandwidth of a link, therefore, the higher bandwidth link between XR1 and XR3 with a lower cost 10 will be used. The AIGP metric of value 11 sent from XR3 to XR5 inside the AIGP attribute represents the accumulated OSPF cost of the loopback interface of XR1 and the cost 10 configured on the link between XR1 and XR3.


Conclusion:

The AIGP metric influences the BGP best-path selection process more than AS_PATH or MED, as it is above them in the BGP best path algorithm. The AIGP attribute is standardized in RFC7311 and so far has been successfully implemented by the major network vendors such as Cisco and Juniper. In the future, we shall see more and more deployments where AIGP is taken in the account.

Boost BGP Performance

Automate BGP Routing optimization with Noction IRP

bgp demo


SUBSCRIBE TO NEWSLETTER

You May Also Like