Accumulated IGP and BGP

Accumulated IGP and BGP

    IGP Interior Gateway Protocol and BGP Border Gateway Protocol

    RFC 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 Preformance

    Automate BGP Routing optimization with Noction IRP

    NO COMMENTS

    Leave a Reply