The Accumulated IGP Metric Attribute for BGP

This is an interesting draft which can ensure better paths are chosen in certain corner cases. Before this draft, BGP was able to redistribute the IGP metric as a MED value into BGP. The issue with MED is that it’s very low on the BGP best path algorithm. Note that Cisco/Brocade consider weight as primary, but I’ll ignore that for now

  1. Highest Local-Preference
  2. Shortest AS-Path
  3. Lowest Origin Code
  4. Lowest MED
  5. ETC

MED is only number 4 in the pecking order. In a large network it might be difficult to get everything to match up to that point. Accumulated IGP Metric is a new non-transitive BGP path attribute that carries the IGP metric inside the BGP NLRI. Not only that, but the best-path algorithms are changed as follows:

  1. Highest Local-Preference
  2. Lowest AIGP Cost
  3. Shortest AS-Path
  4. Lowest Origin Code
  5. Lowest MED
  6. ETC

As long as your local-preference values match, the lowest AIGP cost is taken into account.

No AIGP

Take the following topology into consideration:
BGP-AIGP
Assuming all link costs are the same, the shortest path for XR2 to get to IOS2 is via path XR1-XR4-IOS2. I’m going to ignore MED on XR2 for now.

Quick relevant configs on XR1 and IOS1:

interface GigabitEthernet0/0/0/1
 description Link to XR2
 ipv4 address 10.0.12.1 255.255.255.0
!
interface GigabitEthernet0/0/0/2
 description Link to XR3
 ipv4 address 10.0.13.1 255.255.255.0
!
prefix-set 20.20.20.20
  20.20.20.20/32
end-set
!
route-policy PASS
  pass
end-policy
!
route-policy IOS2_LOOPBACK
  if destination in 20.20.20.20 then
    done
  else
    drop
  endif
end-policy
!
router isis 1
 is-type level-2-only
 net 49.0001.0000.0000.0001.00
 address-family ipv4 unicast
  metric-style wide
 !
 interface Loopback0
  address-family ipv4 unicast
  !
 !
 interface GigabitEthernet0/0/0/2
  address-family ipv4 unicast
  !
 !
!
router bgp 64512
 address-family ipv4 unicast
  redistribute isis 1 route-policy IOS2_LOOPBACK
 !
 neighbor 10.0.12.2
  remote-as 64513
  address-family ipv4 unicast
   route-policy PASS in
   route-policy PASS out
  !
 !
!
interface Loopback0
 ip address 10.10.10.10 255.255.255.255
 ip router isis 1
!
interface GigabitEthernet0/0
!
interface GigabitEthernet0/0.41
 encapsulation dot1Q 41
 ip address 10.0.41.1 255.255.255.0
 ip router isis 1
!
router isis 1
 net 49.0001.0000.0000.0010.00
 is-type level-2-only
 metric-style wide
!
router bgp 64512
 bgp log-neighbor-changes
 redistribute isis 1 level-2 route-map IOS2_LOOPBACK
 neighbor 10.0.21.2 remote-as 64513
!
ip prefix-list 20.20.20.20 seq 5 permit 20.20.20.20/32
!
route-map IOS2_LOOPBACK permit 10
 match ip address prefix-list 20.20.20.20
!
route-map IOS2_LOOPBACK deny 20

XR2 should now have the 20.20.20.20/32 prefix twice. Let’s check the route that XR2 chose:

RP/0/0/CPU0:XR2#show bgp ipv4 un 20.20.20.20
Mon Aug 11 18:29:47.825 UTC
BGP routing table entry for 20.20.20.20/32
Versions:
  Process           bRIB/RIB  SendTblVer
  Speaker                  5           5
Last Modified: Aug 11 18:24:57.101 for 00:04:50
Paths: (2 available, best #1)
  Advertised to update-groups (with more than one peer):
    0.1
  Path #1: Received by speaker 0
  Advertised to update-groups (with more than one peer):
    0.1
  64512
    10.0.12.1 from 10.0.12.1 (1.1.1.1)
      Origin incomplete, metric 0, localpref 100, valid, external, best, group-best, import-candidate, import suspect
      Received Path ID 0, Local Path ID 1, version 5
      Origin-AS validity: not-found
  Path #2: Received by speaker 0
  Not advertised to any peer
  64512
    10.0.21.1 from 10.0.21.1 (10.10.10.10)
      Origin incomplete, metric 0, localpref 100, valid, external, import-candidate, import suspect
      Received Path ID 0, Local Path ID 0, version 0
      Origin-AS validity: not-found

Currently its going the correct way, however what happens if XR1’s route to 20.20.20.20/32 was increased?

router isis 1
!
 interface GigabitEthernet0/0/0/2
  address-family ipv4 unicast
   metric 100

XR2 still sees the best route via XR1:

RP/0/0/CPU0:XR2#show route ipv4 20.20.20.20
Mon Aug 11 18:31:34.958 UTC

Routing entry for 20.20.20.20/32
  Known via "bgp 64513", distance 20, metric 0
  Tag 64512, type external
  Installed Aug 11 18:24:57.065 for 00:06:37
  Routing Descriptor Blocks
    10.0.12.1, from 10.0.12.1, BGP external
      Route metric is 0
  No advertising protos.

AIGP

In order to send AIGP, you need to ensure that the AIGP metric is being set in your route-policy, as well as turn on the feature under the neighbour address family. I’ll be doing this on XR1:

route-policy IOS2_LOOPBACK
  if destination in 20.20.20.20 then
    set aigp-metric igp-cost
  else
    drop
  endif
end-policy
!
router bgp 64512
 !
 neighbor 10.0.12.2
  address-family ipv4 unicast
   aigp

AIGP has just been added to legacy IOS on version 15.4(3)T which is a version I don’t have in my lab yet. Let’s take a look at the consequences of one setting this value and the other not.

RP/0/0/CPU0:XR2#show route ipv4 20.20.20.20
Mon Aug 11 18:42:42.952 UTC

Routing entry for 20.20.20.20/32
  Known via "bgp 64513", distance 20, metric 120 (AIGP metric)
  Tag 64512, type external
  Installed Aug 11 18:35:09.393 for 00:07:33
  Routing Descriptor Blocks
    10.0.12.1, from 10.0.12.1, BGP external
      Route metric is 120

IOS-XR is preferring the route with the AIGP metric set. You can see the metric value of 120 has been learned. It also sets the local route metric to 120. The update from IOS1 is not preffered so it seems like a non-aigp value is seen as worse than any aigp value that may be set.

I’m going to swap out IOS1 with another IOS-XR box. This new XR box will be advertising the route with the same metric as IOS1 currently is.
BGP-AIGP-2

XR2 should now be seeing both AIGP values and choosing XR5 as the next-hop:

RP/0/0/CPU0:XR2#show bgp ipv4 unicast 20.20.20.20/32
Mon Aug 11 19:33:43.432 UTC
BGP routing table entry for 20.20.20.20/32
Versions:
  Process           bRIB/RIB  SendTblVer
  Speaker                  9           9
Last Modified: Aug 11 19:33:33.101 for 00:00:10
Paths: (2 available, best #2)
  Advertised to update-groups (with more than one peer):
    0.1
  Path #1: Received by speaker 0
  Not advertised to any peer
  64512
    10.0.12.1 from 10.0.12.1 (1.1.1.1)
      Origin incomplete, metric 0, localpref 100, aigp metric 120, valid, external, import suspect
      Received Path ID 0, Local Path ID 0, version 0
      Origin-AS validity: not-found
      Total AIGP metric 120
  Path #2: Received by speaker 0
  Advertised to update-groups (with more than one peer):
    0.1
  64512
    10.0.52.5 from 10.0.52.5 (5.5.5.5)
      Origin incomplete, metric 0, localpref 100, aigp metric 40, valid, external, best, group-best, import-candidate, import suspect
      Received Path ID 0, Local Path ID 1, version 9
      Origin-AS validity: not-found
      Total AIGP metric 40

Once again, the local route metric has been set to match the AIGP metric:

RP/0/0/CPU0:XR2#sh ip route 20.20.20.20
Mon Aug 11 19:34:54.567 UTC

Routing entry for 20.20.20.20/32
  Known via "bgp 64513", distance 20, metric 40 (AIGP metric)
  Tag 64512, type external
  Installed Aug 11 19:33:33.523 for 00:01:21
  Routing Descriptor Blocks
    10.0.52.5, from 10.0.52.5, BGP external
      Route metric is 40

© 2009-2019 Darren O'Connor All Rights Reserved -- Copyright notice by Blog Copyright