Accumulated IGP Metric Attribute (AIGP)

In large networks, you may encounter network designs where the network is under a single administrative authority but divided into multiple ASes, each with its own IGP.

Why do we see networks designed like this? There are several reasons:

• The IGP doesn’t scale for a network of this size.
• One company bought another company, and they haven’t merged their ASes (yet).
• Each business division has a separate network.
• You require a specific routing policy that you can’t do with an IGP.
• You use BGP confederations.
• You use seamless MPLS.

A network with multiple IGPs and BGP in between instead of a single IGP introduces a potential problem. BGP selects a path using the best path selection algorithm, which isn’t based on a “lowest metric” as IGPs do. What happens is that your router will sometimes select sub-optimal paths in your network.

The routers above don’t have any inside metric information about the other ASes. AS 1 can’t know that somewhere inside AS 3, there are slow and fast links.

The solution to this problem is to use a BGP attribute named Accumulated IGP Metric Attribute (AIGP).

AIGP is a non-transitive attribute that includes the accumulated IGP metric. BGP routers advertise this AIGP metric to neighbors in other ASes. This allows BGP routers to select the best path based on the end-to-end IGP metric.

To make this possible, AIGP makes some changes to the BGP best-path algorithm.

Once you enable AIGP, BGP will check the AIGP metric right after step 3 (originate). This means we use the AIGP metric as a tie-breaker before other important attributes like the AS path length or MED.

In this lesson, I’ll show you a “before” and “after” scenario. In the “before” scenario, we look at a network that doesn’t use AIGP and which selects a sub-optimal path. You will also see how other solutions like configuring the MED won’t solve our problem. This example will help to understand why we need AIGP. In the “after” scenario, we’ll configure AIGP, and you’ll see how AIGP solves our sub-optimal routing problem.

Let’s get started!

Configuration

This is the topology we’ll use:

hostname R1
!
ip cef
!
interface Loopback0
 ip address 1.1.1.1 255.255.255.255
 ip ospf cost 10
!
interface GigabitEthernet0/0
 ip address 192.168.12.1 255.255.255.0
 ip ospf cost 10
!
interface GigabitEthernet0/1
 ip address 192.168.13.1 255.255.255.0
 ip ospf cost 30
!
router ospf 1
 network 1.1.1.1 0.0.0.0 area 0
 network 192.168.12.0 0.0.0.255 area 0
 network 192.168.13.0 0.0.0.255 area 0
!
router bgp 123
 network 1.1.1.1 mask 255.255.255.255
 neighbor 2.2.2.2 remote-as 123
 neighbor 2.2.2.2 update-source Loopback0
 neighbor 3.3.3.3 remote-as 123
 neighbor 3.3.3.3 update-source Loopback0
!
end

hostname R2
!
ip cef
!
interface Loopback0
 ip address 2.2.2.2 255.255.255.255
 ip ospf cost 10
!
interface GigabitEthernet0/0
 ip address 192.168.12.2 255.255.255.0
 ip ospf cost 10
!
interface GigabitEthernet0/1
 ip address 192.168.24.2 255.255.255.0
!
router ospf 1
 network 2.2.2.2 0.0.0.0 area 0
 network 192.168.12.0 0.0.0.255 area 0
!
router bgp 123
 neighbor 1.1.1.1 remote-as 123
 neighbor 1.1.1.1 update-source Loopback0
 neighbor 1.1.1.1 next-hop-self
 neighbor 3.3.3.3 remote-as 123
 neighbor 3.3.3.3 update-source Loopback0
 neighbor 3.3.3.3 next-hop-self
 neighbor 192.168.24.4 remote-as 456
!
end

hostname R3
!
ip cef
!
interface Loopback0
 ip address 3.3.3.3 255.255.255.255
 ip ospf cost 10
!
interface GigabitEthernet0/0
 ip address 192.168.13.3 255.255.255.0
 ip ospf cost 30
!
interface GigabitEthernet0/1
 ip address 192.168.35.3 255.255.255.0
!
router ospf 1
 network 3.3.3.3 0.0.0.0 area 0
 network 192.168.13.0 0.0.0.255 area 0
!
router bgp 123
 neighbor 1.1.1.1 remote-as 123
 neighbor 1.1.1.1 update-source Loopback0
 neighbor 1.1.1.1 next-hop-self
 neighbor 2.2.2.2 remote-as 123
 neighbor 2.2.2.2 update-source Loopback0
 neighbor 2.2.2.2 next-hop-self
 neighbor 192.168.35.5 remote-as 456
!
end

hostname R4
!
ip cef
!
interface Loopback0
 ip address 4.4.4.4 255.255.255.255
 ip ospf cost 10
!
interface GigabitEthernet0/0
 ip address 192.168.46.4 255.255.255.0
 ip ospf cost 20
!
interface GigabitEthernet0/1
 ip address 192.168.24.4 255.255.255.0
!
router ospf 1
 network 4.4.4.4 0.0.0.0 area 0
 network 192.168.46.0 0.0.0.255 area 0
!
router bgp 456
 neighbor 5.5.5.5 remote-as 456
 neighbor 5.5.5.5 update-source Loopback0
 neighbor 5.5.5.5 next-hop-self
 neighbor 6.6.6.6 remote-as 456
 neighbor 6.6.6.6 update-source Loopback0
 neighbor 6.6.6.6 next-hop-self
 neighbor 192.168.24.2 remote-as 123
!
end

hostname R5
!
ip cef
!
interface Loopback0
 ip address 5.5.5.5 255.255.255.255
 ip ospf cost 10
!
interface GigabitEthernet0/0
 ip address 192.168.56.5 255.255.255.0
 ip ospf cost 10
!
interface GigabitEthernet0/1
 ip address 192.168.35.5 255.255.255.0
!
router ospf 1
 network 5.5.5.5 0.0.0.0 area 0
 network 192.168.56.0 0.0.0.255 area 0
!
router bgp 456
 neighbor 4.4.4.4 remote-as 456
 neighbor 4.4.4.4 update-source Loopback0
 neighbor 4.4.4.4 next-hop-self
 neighbor 6.6.6.6 remote-as 456
 neighbor 6.6.6.6 update-source Loopback0
 neighbor 6.6.6.6 next-hop-self
 neighbor 192.168.35.3 remote-as 123
!
end

hostname R6

ip cef
!
interface Loopback0
 ip address 6.6.6.6 255.255.255.255
 ip ospf cost 10
!
interface GigabitEthernet0/0
 ip address 192.168.46.6 255.255.255.0
 ip ospf cost 20
!
interface GigabitEthernet0/1
 ip address 192.168.56.6 255.255.255.0
 ip ospf cost 10
!
router ospf 1
 network 6.6.6.6 0.0.0.0 area 0
 network 192.168.46.0 0.0.0.255 area 0
 network 192.168.56.0 0.0.0.255 area 0
!
router bgp 456
 network 6.6.6.6 mask 255.255.255.255
 neighbor 4.4.4.4 remote-as 456
 neighbor 4.4.4.4 update-source Loopback0
 neighbor 5.5.5.5 remote-as 456
 neighbor 5.5.5.5 update-source Loopback0
!
end

We have two ASes. Within each AS, we run OSPF. I changed the cost metric on some of the interfaces. Let’s see how this network behaves when we send traffic between 1.1.1.1 and 6.6.6.6.

I configured these examples on IOSv Software (VIOS-ADVENTERPRISE-M), Version 15.9(3)M2.

Default BGP

We’ll start with a “default” BGP scenario where we don’t have any route-maps to steer traffic in another direction.

From AS 123 to AS 456

Let’s see how R1 wants to reach 6.6.6.6:

R1#show ip bgp 6.6.6.6
BGP routing table entry for 6.6.6.6/32, version 3
Paths: (2 available, best #2, table default)
Flag: 0x100
  Not advertised to any peer
  Refresh Epoch 1
  456
    3.3.3.3 (metric 40) from 3.3.3.3 (3.3.3.3)
      Origin IGP, metric 0, localpref 100, valid, internal
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 1
  456
    2.2.2.2 (metric 20) from 2.2.2.2 (2.2.2.2)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      rx pathid: 0, tx pathid: 0x0

R1 uses R2 as the next hop because it has the lowest IGP metric to the BGP next hop. Traffic enters AS 456 through R4. Let’s check the IGP metric to 6.6.6.6 on R4 and R5:

R4#show ip route 6.6.6.6 | include metric
  Known via "ospf 1", distance 110, metric 30, type intra area
      Route metric is 30, traffic share count is 1

R5#show ip route 6.6.6.6 | include metric
  Known via "ospf 1", distance 110, metric 20, type intra area
      Route metric is 20, traffic share count is 1

Looking from AS 456’s perspective, R5 has the lowest IGP metric to get to 6.6.6.6. However, when we look at the total metric picture, using R4 is the best option:

• The path through R2 = 10 + 20 + 10 = 40
• The path through R3 = 30 + 10 + 10 = 50

So, traffic from R1 to R6 takes the best path, excellent.

From AS 456 to AS 123

What about the other way around? From R6 to R1. Let’s check the BGP table on R6:

R6#show ip bgp 1.1.1.1
BGP routing table entry for 1.1.1.1/32, version 4
Paths: (2 available, best #1, table default)
Flag: 0x100
  Not advertised to any peer
  Refresh Epoch 1
  123
    5.5.5.5 (metric 20) from 5.5.5.5 (5.5.5.5)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      rx pathid: 0, tx pathid: 0x0
  Refresh Epoch 1
  123
    4.4.4.4 (metric 30) from 4.4.4.4 (4.4.4.4)
      Origin IGP, metric 0, localpref 100, valid, internal
      rx pathid: 0, tx pathid: 0

R6 picks R5 because it has the lowest IGP metric to the next hop. Is that a good thing? Well, we know it’s not because we just figured out that the best path is through R4 and R2.

Let’s check it from AS 123’s perspective:

R2#show ip route 1.1.1.1 | include metric
  Known via "ospf 1", distance 110, metric 20, type intra area
      Route metric is 20, traffic share count is 1

R3#show ip route 1.1.1.1 | include metric
  Known via "ospf 1", distance 110, metric 40, type intra area
      Route metric is 40, traffic share count is 1

When we enter AS 123 through R3, we have to use the “slow” link with a higher metric.  The total metric of our paths looks like this:

• The path through R4 = 20 + 10 + 10 = 40
• The path through R5 = 10 + 30 + 10 = 50

The path through R4 would be the better option, but AS 456 can’t know this because it doesn’t know what AS 123 looks like.

BGP MED

You might think, why don’t we use BGP MED or perhaps AS path prepending? That allows us to tell the AS on the other side how we like to receive traffic?

Let me show you what happens when we use MED. This helps to understand why we need AIGP.

MED Configuration

We’ll configure route-maps so that R2, R3, R4, and R5 set the MED based on their IGP metric to reach the loopback interface in their AS.

AS 123

Let’s start with R2:

R2(config)#ip access-list standard R1_L0
R2(config-std-nacl)#permit host 1.1.1.1

R2(config)#route-map R1_L0_METRIC
R2(config-route-map)#match ip address R1_L0
R2(config-route-map)#set metric 20

R2(config)#router bgp 123
R2(config-router)#neighbor 192.168.24.4 route-map R1_L0_METRIC out

Here is R3:

R3(config)#ip access-list standard R1_L0
R3(config-std-nacl)#permit host 1.1.1.1

R3(config)#route-map R1_L0_METRIC
R3(config-route-map)#match ip address R1_L0
R3(config-route-map)#set metric 40

R3(config-route-map)#router bgp 123
R3(config-router)#neighbor 192.168.35.5 route-map R1_L0_METRIC out

That’s all we need to configure in AS 123.

AS 456

Let’s configure R4:

R4(config)#ip access-list standard R6_L0
R4(config-std-nacl)#permit host 6.6.6.6

R4(config)#route-map R6_L0_METRIC
R4(config-route-map)#match ip address R6_L0
R4(config-route-map)#set metric 30

R4(config)#router bgp 456
R4(config-router)#neighbor 192.168.24.2 route-map R6_L0_METRIC out

and R5:

R5(config)#ip access-list standard R6_L0
R5(config-std-nacl)#permit host 6.6.6.6

R5(config)#route-map R6_L0_METRIC
R5(config-route-map)#match ip address R6_L0
R5(config-route-map)#set metric 20

R5(config)#router bgp 456
R5(config-router)#neighbor 192.168.35.3 route-map R6_L0_METRIC out

That’s all we need to configure for MED.

From AS 123 to AS 456

Once again, let’s find out how traffic from R1 reaches R6. We’ll check R1:

R1#show ip bgp 6.6.6.6
BGP routing table entry for 6.6.6.6/32, version 3
Paths: (1 available, best #1, table default)
Flag: 0x100
  Not advertised to any peer
  Refresh Epoch 1
  456
    3.3.3.3 (metric 40) from 3.3.3.3 (3.3.3.3)
      Origin IGP, metric 20, localpref 100, valid, internal, best
      rx pathid: 0, tx pathid: 0x0

R1 has only path now. That’s because R2 prefers the path through R3 over its own eBGP path:

R2#show ip bgp 6.6.6.6
BGP routing table entry for 6.6.6.6/32, version 3
Paths: (2 available, best #2, table default)
  Not advertised to any peer
  Refresh Epoch 1
  456
    192.168.24.4 from 192.168.24.4 (4.4.4.4)
      Origin IGP, metric 30, localpref 100, valid, external
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 1
  456
    3.3.3.3 (metric 50) from 3.3.3.3 (3.3.3.3)
      Origin IGP, metric 20, localpref 100, valid, internal, best
      rx pathid: 0, tx pathid: 0x0

R3#show ip bgp 6.6.6.6
BGP routing table entry for 6.6.6.6/32, version 3
Paths: (1 available, best #1, table default)
  Advertised to update-groups:
     14        
  Refresh Epoch 1
  456
    192.168.35.5 from 192.168.35.5 (5.5.5.5)
      Origin IGP, metric 20, localpref 100, valid, external, best
      rx pathid: 0, tx pathid: 0x0

BGP prefers the path with the lowest MED.

That’s not good. AS 123 now uses R3 to reach AS 456 and we know this is not the path with the lowest total metric.

From AS 456 to AS 123

Let’s check the other way around. What about traffic from R6 to R1?

Here’s R6:

R6#show ip bgp 1.1.1.1
BGP routing table entry for 1.1.1.1/32, version 2
Paths: (1 available, best #1, table default)
  Not advertised to any peer
  Refresh Epoch 1
  123
    4.4.4.4 (metric 30) from 4.4.4.4 (4.4.4.4)
      Origin IGP, metric 20, localpref 100, valid, internal, best
      rx pathid: 0, tx pathid: 0x0

R6 only sees R4 as a possible path. This is because R5 prefers to use R4 over its eBGP path:

R5#show ip bgp 1.1.1.1
BGP routing table entry for 1.1.1.1/32, version 2
Paths: (2 available, best #1, table default)
  Not advertised to any peer
  Refresh Epoch 1
  123
    4.4.4.4 (metric 40) from 4.4.4.4 (4.4.4.4)
      Origin IGP, metric 20, localpref 100, valid, internal, best
      rx pathid: 0, tx pathid: 0x0
  Refresh Epoch 1
  123
    192.168.35.3 from 192.168.35.3 (3.3.3.3)
      Origin IGP, metric 40, localpref 100, valid, external
      rx pathid: 0, tx pathid: 0

R4#show ip bgp 1.1.1.1
BGP routing table entry for 1.1.1.1/32, version 2
Paths: (1 available, best #1, table default)
  Advertised to update-groups:
     11        
  Refresh Epoch 1
  123
    192.168.24.2 from 192.168.24.2 (2.2.2.2)
      Origin IGP, metric 20, localpref 100, valid, external, best
      rx pathid: 0, tx pathid: 0x0

AS 456 is now using the most optimal path. However, AS 123 isn’t.

hostname R1
!
ip cef
!
interface Loopback0
 ip address 1.1.1.1 255.255.255.255
 ip ospf cost 10
!
interface GigabitEthernet0/0
 ip address 192.168.12.1 255.255.255.0
 ip ospf cost 10
!
interface GigabitEthernet0/1
 ip address 192.168.13.1 255.255.255.0
 ip ospf cost 30
!
router ospf 1
 network 1.1.1.1 0.0.0.0 area 0
 network 192.168.12.0 0.0.0.255 area 0
 network 192.168.13.0 0.0.0.255 area 0
!
router bgp 123
 network 1.1.1.1 mask 255.255.255.255
 neighbor 2.2.2.2 remote-as 123
 neighbor 2.2.2.2 update-source Loopback0
 neighbor 3.3.3.3 remote-as 123
 neighbor 3.3.3.3 update-source Loopback0
!
end

hostname R2
!
ip cef
!
interface Loopback0
 ip address 2.2.2.2 255.255.255.255
 ip ospf cost 10
!
interface GigabitEthernet0/0
 ip address 192.168.12.2 255.255.255.0
 ip ospf cost 10
!
interface GigabitEthernet0/1
 ip address 192.168.24.2 255.255.255.0
!
router ospf 1
 network 2.2.2.2 0.0.0.0 area 0
 network 192.168.12.0 0.0.0.255 area 0
!
router bgp 123
 neighbor 1.1.1.1 remote-as 123
 neighbor 1.1.1.1 update-source Loopback0
 neighbor 1.1.1.1 next-hop-self
 neighbor 3.3.3.3 remote-as 123
 neighbor 3.3.3.3 update-source Loopback0
 neighbor 3.3.3.3 next-hop-self
 neighbor 192.168.24.4 remote-as 456
 neighbor 192.168.24.4 route-map R1_L0_METRIC out
!
ip access-list standard R1_L0
 permit 1.1.1.1
!
route-map R1_L0_METRIC permit 10
 match ip address R1_L0
 set metric 20
!
end

hostname R3
!
ip cef
!
interface Loopback0
 ip address 3.3.3.3 255.255.255.255
 ip ospf cost 10
!
interface GigabitEthernet0/0
 ip address 192.168.13.3 255.255.255.0
 ip ospf cost 30
!
interface GigabitEthernet0/1
 ip address 192.168.35.3 255.255.255.0
!
router ospf 1
 network 3.3.3.3 0.0.0.0 area 0
 network 192.168.13.0 0.0.0.255 area 0
!
router bgp 123
 neighbor 1.1.1.1 remote-as 123
 neighbor 1.1.1.1 update-source Loopback0
 neighbor 1.1.1.1 next-hop-self
 neighbor 2.2.2.2 remote-as 123
 neighbor 2.2.2.2 update-source Loopback0
 neighbor 2.2.2.2 next-hop-self
 neighbor 192.168.35.5 remote-as 456
 neighbor 192.168.35.5 route-map R1_L0_METRIC out
!
ip access-list standard R1_L0
 permit 1.1.1.1
!
route-map R1_L0_METRIC permit 10
 match ip address R1_L0
 set metric 40
!
end

hostname R4
!
ip cef
!
interface Loopback0
 ip address 4.4.4.4 255.255.255.255
 ip ospf cost 10
!
interface GigabitEthernet0/0
 ip address 192.168.46.4 255.255.255.0
 ip ospf cost 20
!
interface GigabitEthernet0/1
 ip address 192.168.24.4 255.255.255.0
!
router ospf 1
 network 4.4.4.4 0.0.0.0 area 0
 network 192.168.46.0 0.0.0.255 area 0
!
router bgp 456
 neighbor 5.5.5.5 remote-as 456
 neighbor 5.5.5.5 update-source Loopback0
 neighbor 5.5.5.5 next-hop-self
 neighbor 6.6.6.6 remote-as 456
 neighbor 6.6.6.6 update-source Loopback0
 neighbor 6.6.6.6 next-hop-self
 neighbor 192.168.24.2 remote-as 123
 neighbor 192.168.24.2 route-map R6_L0_METRIC out
!
ip access-list standard R6_L0
 permit 6.6.6.6
!
route-map R6_L0_METRIC permit 10
 match ip address R6_L0
 set metric 30
!
end

hostname R5
!
ip cef
!
interface Loopback0
 ip address 5.5.5.5 255.255.255.255
 ip ospf cost 10
!
interface GigabitEthernet0/0
 ip address 192.168.56.5 255.255.255.0
 ip ospf cost 10
!
interface GigabitEthernet0/1
 ip address 192.168.35.5 255.255.255.0
!
router ospf 1
 network 5.5.5.5 0.0.0.0 area 0
 network 192.168.56.0 0.0.0.255 area 0
!
router bgp 456
 neighbor 4.4.4.4 remote-as 456
 neighbor 4.4.4.4 update-source Loopback0
 neighbor 4.4.4.4 next-hop-self
 neighbor 6.6.6.6 remote-as 456
 neighbor 6.6.6.6 update-source Loopback0
 neighbor 6.6.6.6 next-hop-self
 neighbor 192.168.35.3 remote-as 123
 neighbor 192.168.35.3 route-map R6_L0_METRIC out
!
ip access-list standard R6_L0
 permit 6.6.6.6
!
route-map R6_L0_METRIC permit 10
 match ip address R6_L0
 set metric 20
!
end

hostname R6
!
ip cef
!
interface Loopback0
 ip address 6.6.6.6 255.255.255.255
 ip ospf cost 10
!
interface GigabitEthernet0/0
 ip address 192.168.46.6 255.255.255.0
 ip ospf cost 20
!
interface GigabitEthernet0/1
 ip address 192.168.56.6 255.255.255.0
 ip ospf cost 10
!
router ospf 1
 network 6.6.6.6 0.0.0.0 area 0
 network 192.168.46.0 0.0.0.255 area 0
 network 192.168.56.0 0.0.0.255 area 0
!
router bgp 456
 network 6.6.6.6 mask 255.255.255.255
 neighbor 4.4.4.4 remote-as 456
 neighbor 4.4.4.4 update-source Loopback0
 neighbor 5.5.5.5 remote-as 456
 neighbor 5.5.5.5 update-source Loopback0
!
 exec-timeout 0 0
 login
 transport input none
!
end

AIGP

It’s time for AIGP and to finally configure what you came for. Let’s make sure both AS 123 and AS 456 will use the most optimal path.