A Thing About EIGRP Summaries

Home Lab, Routing

IP route summarization, sometimes called aggregation, allows us to suppress the advertisement of multiple longer prefixes into a shorter prefix that encompasses a range of more specific routes. There are plenty of excellent guides on summarization, so I’ll spare those details here and jump straight into some EIGRP specific things about summaries.

Demo Network

For demonstration I’ll be using the topology below in Cisco Modeling Labs. R3 is connected to 192.168.2.0/24 and 192.168.3.0/24, R4 is connected to 192.168.0.0/24 and 192.168.1.0/24. All routers are running EIGRP AS 1. R3 is advertising summary route 192.168.0.0/22 to R2 to suppress and encompass the 4 /24s mentioned earlier. This means that R2 will only learn 192.168.0.0/22 instead of each /24.

R3(config)#int eth0/1
R3(config-if)#ip summary-address eigrp 1 192.168.0.0/22 
R3(config-if)#
*Oct  2 12:29:55.856: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.0.0.1 (Ethernet0/1) is resync: summary configured
R3(config-if)#

The Summary Metric

When an EIGRP router is configured to send a summary route, by default it will use the lowest feasible distance (metric) of the component routes being suppressed. In this example, R3 will use the metric of directly connected component networks 192.168.2.0/24 or 192.168.3.0/24.

In the R3 EIGRP topology table we can see that the feasible distance of 192.168.2.0/24 is 281600. 192.168.3.0/24 has the same FD. 

R3#show ip eigrp topology 192.168.2.0/24
EIGRP-IPv4 Topology Entry for AS(1)/ID(10.0.0.5) for 192.168.2.0/24
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 281600
  Descriptor Blocks:
  0.0.0.0 (Ethernet0/2.30), from Connected, Send flag is 0x0
      Composite metric is (281600/0), route is Internal
      Vector metric:
        Minimum bandwidth is 10000 Kbit
        Total delay is 1000 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 0
        Originating router is 10.0.0.5

R3’s topology table confirms that the two /24s learned from R4 have a higher FD than the two directly connected 192.168 networks. This confirms that the FD of the 192.168.0.0/22 summary should be 281600 when R3 advertises it toward R2.

R3#show ip eigrp topology 192.168.0.0/24
EIGRP-IPv4 Topology Entry for AS(1)/ID(10.0.0.5) for 192.168.0.0/24
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 307200
  Descriptor Blocks:
  10.0.0.6 (Ethernet0/0), from 10.0.0.6, Send flag is 0x0
      Composite metric is (307200/281600), route is Internal
      Vector metric:
        Minimum bandwidth is 10000 Kbit
        Total delay is 2000 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 1
        Originating router is 10.0.0.6

R2’s EIGRP topology table confirms that the reported distance of 192.168.0.0/22 is 281600.

R2#show ip eigrp topology 192.168.0.0/22
EIGRP-IPv4 Topology Entry for AS(1)/ID(10.0.0.1) for 192.168.0.0/22
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 307200
  Descriptor Blocks:
  10.0.0.2 (Ethernet0/0), from 10.0.0.2, Send flag is 0x0
      Composite metric is (307200/281600), route is Internal
      Vector metric:
        Minimum bandwidth is 10000 Kbit
        Total delay is 2000 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 1
        Originating router is 10.0.0.5

Leaky Abstractions

Now that we’ve looked at how EIGRP summary metrics are derived, let’s consider and explore what happens when 192.168.2.0/24 and 192.168.3.0/24 go down. Even though we’ve summarized, the routes that the summary metric is derived from went away. This will cause an EIGRP update to be sent to raise the summary route metric to use the lowest FD of the remaining component routes. We’d abstracted the specific routes away in lieu of a single summary route but the abstraction leaks when a state change of the more specifics leaks though the summary point.

Let’s check the route metric before again before making any changes. On R2, the 192.168.0.0/22 metric is 307200. This is the reported distance from R3 + the cost to reach R3 from R2’s perspective.

R2#show ip route eigrp 
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, m - OMP
       n - NAT, Ni - NAT inside, No - NAT outside, Nd - NAT DIA
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       H - NHRP, G - NHRP registered, g - NHRP registration summary
       o - ODR, P - periodic downloaded static route, l - LISP
       a - application route
       + - replicated route, % - next hop override, p - overrides from PfR
       & - replicated local route overrides by connected

Gateway of last resort is not set

      10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
D        10.0.0.4/30 [90/307200] via 10.0.0.2, 00:28:14, Ethernet0/0
D     192.168.0.0/22 [90/307200] via 10.0.0.2, 00:00:51, Ethernet0/0
R2#

I enabled EIGRP debugging on R1 and R2, and then shut down R3’s Eth0/2 interface. This causes 192.168.2.0 and 3.0/24 to go away, thus causing a metric increase for the /22 summary route.

R3(config)#int eth0/2
R3(config-if)#shutdown
R3(config-if)#
*Oct  2 12:49:08.591: %LINK-5-CHANGED: Interface Ethernet0/2, changed state to administratively down
*Oct  2 12:49:09.591: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/2, changed state to down
R3(config-if)#

In the output below we can see that R3 sends EIGRP updates to R2 to remove 192.168.2.0/24 and 192.168.3.0/24 even though they were part of the summary. R2 concludes that those routes were never in its routing table and ignores these updates. R2s debugs then show an update for 192.168.0.0/22 with a higher metric than what R2 had previously. R2 accepts this and enters 192.168.0.0/22 in its RIB with feasible distance 332800. This is higher than the distance before the update because the lowest FD of the summary component is higher. R3 is only learning component routes from R4 now.

R2#
*Oct  2 12:49:06.605: EIGRP-IPv4(1): Int 192.168.2.0/24 M 72057594037927935 - 4294967295 281474976710655 SM 72057594037927935 - 4294901760 4294967295
*Oct  2 12:49:06.605: EIGRP-IPv4(1): Int 192.168.3.0/24 M 72057594037927935 - 4294967295 281474976710655 SM 72057594037927935 - 4294901760 4294967295
*Oct  2 12:49:06.608: EIGRP-IPv4(1): Int 192.168.0.0/22 M 332800 - 10000 3000000000 SM 307200 - 2483027968 30517
*Oct  2 12:49:06.617: EIGRP-IPv4(1): table(default): 192.168.2.0/24 - not in IP routing table
*Oct  2 12:49:06.617: EIGRP-IPv4(1): table(default): 192.168.3.0/24 - not in IP routing table
*Oct  2 12:49:06.619: EIGRP-IPv4(1): table(default): 192.168.0.0/22 
R2#- do advertise out Ethernet0/1
*Oct  2 12:49:06.620: EIGRP-IPv4(1): table(default): 192.168.0.0/22 - do advertise out Ethernet0/0
*Oct  2 12:49:06.632: EIGRP-IPv4(1): Int 192.168.0.0/22 M 72057594037927935 - 10000 281474976710655 SM 72057594037927935 - 4294901760 4294967295
*Oct  2 12:49:06.633: EIGRP-IPv4(1): Int 192.168.0.0/22 M 332800 - 10000 3000000000 SM 307200 - 2483027968 30517
*Oct  2 12:49:06.633: EIGRP-IPv4(1): table(default): route installed for 192.168.0.0/22 (90/332800) origin(10.0.0.2)
R2# 

R2#show ip route eigrp 
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, m - OMP
       n - NAT, Ni - NAT inside, No - NAT outside, Nd - NAT DIA
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       H - NHRP, G - NHRP registered, g - NHRP registration summary
       o - ODR, P - periodic downloaded static route, l - LISP
       a - application route
       + - replicated route, % - next hop override, p - overrides from PfR
       & - replicated local route overrides by connected

Gateway of last resort is not set

      10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
D        10.0.0.4/30 [90/307200] via 10.0.0.2, 00:28:36, Ethernet0/0
D     192.168.0.0/22 [90/332800] via 10.0.0.2, 00:00:09, Ethernet0/0
R2#

R2 sends an update to R1 to inform it that the 192.168.0.0/22 distance is now higher. These updates would continue throughout the EIGRP network if there were more routers.

R1#
*Oct  2 12:49:06.620: EIGRP-IPv4(1): Int 192.168.0.0/22 M 358400 - 10000 4000000000 SM 332800 - 1577058304 45776
*Oct  2 12:49:06.620: EIGRP-IPv4(1): table(default): route installed for 192.168.0.0/22 (90/358400) origin(172.16.0.2)
*Oct  2 12:49:06.633: EIGRP-IPv4(1): table(default): 192.168.0.0/22 - do advertise out Ethernet0/0
R1#

R1#show ip route eigrp
Codes: L – local, C – connected, S – static, R – RIP, M – mobile, B – BGP
D – EIGRP, EX – EIGRP external, O – OSPF, IA – OSPF inter area
N1 – OSPF NSSA external type 1, N2 – OSPF NSSA external type 2
E1 – OSPF external type 1, E2 – OSPF external type 2, m – OMP
n – NAT, Ni – NAT inside, No – NAT outside, Nd – NAT DIA
i – IS-IS, su – IS-IS summary, L1 – IS-IS level-1, L2 – IS-IS level-2
ia – IS-IS inter area, * – candidate default, U – per-user static route
H – NHRP, G – NHRP registered, g – NHRP registration summary
o – ODR, P – periodic downloaded static route, l – LISP
a – application route
+ – replicated route, % – next hop override, p – overrides from PfR
& – replicated local route overrides by connected

Gateway of last resort is not set

  10.0.0.0/30 is subnetted, 2 subnets

D 10.0.0.0 [90/307200] via 172.16.0.2, 00:08:57, Ethernet0/0
D 10.0.0.4 [90/332800] via 172.16.0.2, 00:08:57, Ethernet0/0
D 192.168.0.0/22 [90/358400] via 172.16.0.2, 00:00:58, Ethernet0/0
R1#

Summary Metric Update Mitigation

We can suppress summary route metric update propagation by configuring the metric on R3 for the summary route. In this example I used the same input values that R3 would use for its directly connected 192.168.x.x routes, shown below.

R3#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
R3(config)#router eigrp 1
R3(config-router)#summary-metric 192.168.0.0/22 10000 100 255 1 1500 
R3(config-router)#end

With the summary metric set, I shut down R3 Eth0/2 again to remove 192.168.2.0/24 and 192.168.3.0/24 from the network. This time, R3 still sent an update to R2 for these component routes, announcing them as unreachable. R2 ignores this update because it did not have these routes before. The difference this time is that R3 does not send a metric update for 192.168.0.0/22 because of the static metric configuration.

R3#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
R3(config)#interface ethernet 0/2
R3(config-if)#shutdown
R3(config-if)#
*Oct  2 12:56:53.904: %LINK-5-CHANGED: Interface Ethernet0/2, changed state to administratively down
*Oct  2 12:56:54.904: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/2, changed state to down
R3(config-if)#

R2#
*Oct 2 12:56:51.919: EIGRP-IPv4(1): Int 192.168.2.0/24 M 72057594037927935 – 4294967295 281474976710655 SM 72057594037927935 – 4294901760 4294967295
*Oct 2 12:56:51.919: EIGRP-IPv4(1): Int 192.168.3.0/24 M 72057594037927935 – 4294967295 281474976710655 SM 72057594037927935 – 4294901760 4294967295
*Oct 2 12:56:51.932: EIGRP-IPv4(1): table(default): 192.168.2.0/24 – not in IP routing table
*Oct 2 12:56:51.932: EIGRP-IPv4(1): table(default): 192.168.3.0/24 – not in IP routing table

R2#show ip route eigrp 
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, m - OMP
       n - NAT, Ni - NAT inside, No - NAT outside, Nd - NAT DIA
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       H - NHRP, G - NHRP registered, g - NHRP registration summary
       o - ODR, P - periodic downloaded static route, l - LISP
       a - application route
       + - replicated route, % - next hop override, p - overrides from PfR
       & - replicated local route overrides by connected

Gateway of last resort is not set

      10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
D        10.0.0.4/30 [90/307200] via 10.0.0.2, 00:34:31, Ethernet0/0
D     192.168.0.0/22 [90/307200] via 10.0.0.2, 00:02:21, Ethernet0/0
R2#

Because R2’s metric wasn’t updated, no EIGRP updates are sent to R1. R1 is completely unaware that specific networks 192.168.2.0/24 or 192.168.3.0/24 were ever on the network or that they went down. The EIGRP debug was still running on R1 but there is no output because no updates were received by R1.

R1#show ip route eigrp
Codes: L – local, C – connected, S – static, R – RIP, M – mobile, B – BGP
D – EIGRP, EX – EIGRP external, O – OSPF, IA – OSPF inter area
N1 – OSPF NSSA external type 1, N2 – OSPF NSSA external type 2
E1 – OSPF external type 1, E2 – OSPF external type 2, m – OMP
n – NAT, Ni – NAT inside, No – NAT outside, Nd – NAT DIA
i – IS-IS, su – IS-IS summary, L1 – IS-IS level-1, L2 – IS-IS level-2
ia – IS-IS inter area, * – candidate default, U – per-user static route
H – NHRP, G – NHRP registered, g – NHRP registration summary
o – ODR, P – periodic downloaded static route, l – LISP
a – application route
+ – replicated route, % – next hop override, p – overrides from PfR
& – replicated local route overrides by connected

Gateway of last resort is not set

  10.0.0.0/30 is subnetted, 2 subnets

D 10.0.0.0 [90/307200] via 172.16.0.2, 00:14:43, Ethernet0/0
D 10.0.0.4 [90/332800] via 172.16.0.2, 00:14:43, Ethernet0/0
D 192.168.0.0/22 [90/332800] via 172.16.0.2, 00:03:00, Ethernet0/0
R1#

Leave Comment

Your email address will not be published. Required fields are marked *

Time limit exceeded. Please complete the captcha once again.