cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
Join Customer Connection to register!
7831
Views
10
Helpful
13
Replies
Highlighted
Beginner

EIGRP ip summary-address with a metrics 255 doesn't advertise

EIGRP Summary route 192.168.255.0/24 with metric 255 doesn't advertised to neighbors..., though with a metrics 254 and lower - advertised successfully.

--------------------------------------------------------------

R1 EIGRP configuration:

--------------------------------------------------------------

!

interface Tunnel1004

description *** GRE to R2 ***

ip address 172.17.254.230 255.255.255.252

...

ip summary-address eigrp 1 192.168.255.0 255.255.255.0

...

!

router eigrp 1

default-metric 5000 5001 255 1 1400

summary-metric 192.168.255.0/24 distance 255

network 172.17.0.0

redistribute bgp 65000 route-map RMAP-BGP-TO-EIGRP

redistribute ospf 1 route-map RMAP-OSPF1-TO-EIGRP

redistribute static route-map RMAP-PERMIT-GATEWAY

passive-interface default

no passive-interface Tunnel1004

eigrp router-id 192.168.255.254

!

--------------------------------------------------------------------

R2 EIGRP configuration:

--------------------------------------------------------------------

!

interface Tunnel1254

description *** GRE to R1 ***

ip address 172.17.254.229 255.255.255.252

...

!

router eigrp 1

redistribute rip metric 100000 10 255 1 1500

passive-interface default

no passive-interface Tunnel1254

network 172.17.0.0

no auto-summary

eigrp router-id 192.168.255.4

eigrp stub connected redistributed leak-map RMAP-SMRA-CE1

!

---------------------------------------------------------------------------------------------------------------------------------------

R2 routing table and EIGRP topology, and R1 EIGRP topology for 192.168.255.0

(R1: summary-metric 192.168.255.0/24 distance 250):

---------------------------------------------------------------------------------------------------------------------------------------

R2#sh ip route 192.168.255.0

Routing entry for 192.168.255.0/24, 2 known subnets

  Attached (1 connections)

  Variably subnetted with 2 masks

  Redistributing via eigrp 1, rip

C       192.168.255.4/32 is directly connected, Loopback0

D       192.168.255.0/24 [90/2304000] via 172.17.254.230, 00:13:59, Tunnel1254

R2#sh ip eigrp topology 192.168.255.0/24

IP-EIGRP (AS 1): Topology entry for 192.168.255.0/24

  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2304000

  Routing Descriptor Blocks:

  172.17.254.230 (Tunnel1254), from 172.17.254.230, Send flag is 0x0

      Composite metric is (2304000/1024000), Route is Internal

      Vector metric:

        Minimum bandwidth is 5000 Kbit

        Total delay is 70000 microseconds

        Reliability is 255/255

        Load is 1/255

        Minimum MTU is 1400

        Hop count is 1

        Internal tag is 144

R1#sh ip eigrp topology 192.168.255.0/24

EIGRP-IPv4 Topology Entry for AS(1)/ID(192.168.255.254) for 192.168.255.0/24

  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 1024000

  Descriptor Blocks:

  0.0.0.0 (Null0), from 0.0.0.0, Send flag is 0x0

      Composite metric is (1024000/0), route is Internal

      Vector metric:

        Minimum bandwidth is 5000 Kbit

        Total delay is 20000 microseconds

        Reliability is 255/255

        Load is 1/255

        Minimum MTU is 1500

        Hop count is 0

        Originating router is 192.168.255.254

        Internal tag is 3216

---------------------------------------------------------------------------------------------------------------------------------------

R2 routing table and EIGRP topology, and R1 EIGRP topology for 192.168.255.0

(R1: summary-metric 192.168.255.0/24 distance 255):

---------------------------------------------------------------------------------------------------------------------------------------

R2#sh ip route 192.168.255.0

Routing entry for 192.168.255.0/24, 2 known subnets

  Attached (1 connections)

  Variably subnetted with 2 masks

  Redistributing via eigrp 1, rip

C       192.168.255.4/32 is directly connected, Loopback0

R2#sh ip eigrp topology 192.168.255.0/24

% IP-EIGRP (AS 1): Route not in topology table

R1#sh ip eigrp topology 192.168.255.0/24

EIGRP-IPv4 Topology Entry for AS(1)/ID(192.168.255.254) for 192.168.255.0/24

  State is Passive, Query origin flag is 1, 0 Successor(s), FD is 4294967295

  Descriptor Blocks:

  0.0.0.0 (Null0), from 0.0.0.0, Send flag is 0x0

      Composite metric is (1024000/0), route is Internal

      Vector metric:

        Minimum bandwidth is 5000 Kbit

        Total delay is 20000 microseconds

        Reliability is 255/255

        Load is 1/255

        Minimum MTU is 1500

        Hop count is 0

        Originating router is 192.168.255.254

        Internal tag is 3216

P.S.: The route, as well as it is necessary, doesn't appear in a R1 routing table, if a metrics 255. But and also doesn't advertised

2 ACCEPTED SOLUTIONS

Accepted Solutions
Highlighted
Hall of Fame Cisco Employee

Hello Giuseppe,

If the EIGRP summay route cannot be installed in the local node IP  routing table because AD=255 means unusable, it cannot be advertised to  other nodes.

If you see this, I would say that what you see is normal.

I respectfully disagree here. The behavior must have changed in recent IOSes. Note the behavior of the 12.4T IOS. I have two routers, R1 and R2, connected back to back.

R1:

interface Loopback0

ip address 192.0.2.1 255.255.255.255

!

interface Serial1/0

ip address 10.0.12.1 255.255.255.0

ip summary-address eigrp 1 192.0.2.0 255.255.255.0 255

serial restart-delay 0

!

router eigrp 1

network 10.0.12.1 0.0.0.0

network 192.0.2.1 0.0.0.0

no auto-summary

!        

R1#show ip route

Codes: 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

       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

       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     10.0.0.0/24 is subnetted, 1 subnets

C       10.0.12.0 is directly connected, Serial1/0

     192.0.2.0/32 is subnetted, 1 subnets

C       192.0.2.1 is directly connected, Loopback0

R1#show ip eigrp topo

IP-EIGRP Topology Table for AS(1)/ID(10.0.12.1)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,

       r - reply Status, s - sia Status

P 10.0.12.0/24, 1 successors, FD is 2169856

        via Connected, Serial1/0

P 192.0.2.0/24, 1 successors, FD is 128256

        via Summary (128256/0), Null0

P 192.0.2.1/32, 1 successors, FD is 128256

        via Connected, Loopback0

R1#show ip eigrp topo 192.0.2.0

IP-EIGRP (AS 1): Topology entry for 192.0.2.0/24

  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 128256

  Routing Descriptor Blocks:

  0.0.0.0 (Null0), from 0.0.0.0, Send flag is 0x0

      Composite metric is (128256/0), Route is Internal

      Vector metric:

        Minimum bandwidth is 10000000 Kbit

        Total delay is 5000 microseconds

        Reliability is 255/255

        Load is 1/255

        Minimum MTU is 1514

        Hop count is 0

R2:

interface Serial1/0

ip address 10.0.12.2 255.255.255.0

serial restart-delay 0

!        

router eigrp 1

network 0.0.0.0

no auto-summary

!        

R2#show ip route

Codes: 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

       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

       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     10.0.0.0/24 is subnetted, 1 subnets

C       10.0.12.0 is directly connected, Serial1/0

D    192.0.2.0/24 [90/2297856] via 10.0.12.1, 00:01:22, Serial1/0

R2#show ip eigrp topo 192.0.2.0

IP-EIGRP (AS 1): Topology entry for 192.0.2.0/24

  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2297856

  Routing Descriptor Blocks:

  10.0.12.1 (Serial1/0), from 10.0.12.1, Send flag is 0x0

      Composite metric is (2297856/128256), Route is Internal

      Vector metric:

        Minimum bandwidth is 1544 Kbit

        Total delay is 25000 microseconds

        Reliability is 255/255

        Load is 1/255

        Minimum MTU is 1500

        Hop count is 1

Here you can see that on R1, I have summarized the 192.0.2.1/32 into 192.0.2.0/24 on S1/0 interface with AD=255. The automatic summary Null0 route is therefore not installed into R1's routing table, yet the topology table on R1 shows this route as being fine and alive and is advertised to R2 just fine.

However, starting with IOS versions somewhere around 15.x, the Command Reference about the ip summary-address eigrp command states indeed:

The summary address is not advertised to the peer if the administrative distance is configured as 255.

http://www.cisco.com/en/US/docs/ios-xml/ios/iproute_eigrp/command/ire-i1.html#GUID-F65B16C1-6E09-4C15-80DC-22B0537B1C9A

So - beware of unstable and changing command behaviors! Anton, what you observe on your 15.x IOS is, according to the documentation, normal. It was not normal on previous IOS versions, though.

Best regards,

Peter

View solution in original post

Highlighted

Giuseppe,

The summary-metric command is used to simplify the summary metric processing in the presence of a large topo table. With legacy behavior, every time a prefix changes we would have to cruise the entire topo table to make sure the metric on our summaries still match the best component. With a large topo table, this will limit the scaling. By specifying the metric directly, we avoid this processing completely.

The reason a seed metric isn't needed in the AD 255 case is that we aren't going to send it out anyway, so no metric is required. By specifying the AD 255 on the summary metric statement, we don't need to put it on each interface command.

Sent from Cisco Technical Support iPad App

View solution in original post

13 REPLIES 13
Highlighted
Hall of Fame Cisco Employee

Hello Anton,

This is an interesting issue. I was not able to reproduce the behavior using 2691 IOSes (on R1, you are not running IOS but an IOS-XR or IOS-XE, am I right? What software is run on R1?).

Your observation about the FD on R1 when AD=255 is very good. No doubt, this is an indication why the 192.168.255.0/24 is not advertised to R2. However, I fail to see the how the administrative distance could have influenced the feasible distance here, as they are totally unrelated values.

I wonder: when the summary address' AD is set to 255, is there any other 192.168.255.0/24 route learned from a different source in your routing table on R1? In other words, when you set the AD of the summary route to 255, what does the command show ip route 192.168.255.0 255.255.255.0 say on R1?

EIGRP by default tries to make sure that it propagates only those entries from its topology table that are also installed into the routing table. If a route recorded in the topology table is not placed in the routing table (because of higher AD, for example), EIGRP will not propagate it. This rule should be relaxed for discard routes to Null0 like this one, and on IOS-based platforms, it indeed is. I wonder if there is anything special to be configured on R1 to allow EIGRP to propagate a route that has not been installed into the routing table although it is present in the topology table.

Once again, what software is being run on R1?

Best regards,

Peter

Highlighted

Hello, Peter!

---------------------------------------------------------------------------

R1:

---------------------------------------------------------------------------

!

router eigrp 1

summary-metric 192.168.255.0/24 distance 255

...

!

router ospf 1

area 16 stub

area 16 range 192.168.255.0 255.255.255.0

...

!

R1#sh ip route 192.168.255.0 255.255.255.0

Routing entry for 192.168.255.0/24

  Known via "ospf 1", distance 110, metric 1, type intra area

  Redistributing via nhrp, eigrp 1, bgp 65000

  Routing Descriptor Blocks:

  * directly connected, via Null0

      Route metric is 1, traffic share count is 1

R1#sh version

Cisco IOS Software, 2800 Software (C2800NM-ADVENTERPRISEK9-M), Version 15.1(4)M, RELEASE SOFTWARE (fc1)

Technical Support: http://www.cisco.com/techsupport

Copyright (c) 1986-2011 by Cisco Systems, Inc.

Compiled Thu 24-Mar-11 14:26 by prod_rel_team

ROM: System Bootstrap, Version 12.4(13r)T, RELEASE SOFTWARE (fc1)

...

With or without AD=255, the route 192.168.255.0/24 is directly connected, via Null0 (from OSPF area range).

Highlighted
Hall of Fame Master

Hello Anton,

first of all, what you call metrics is actually administrative distance that is a locally used parameter to choice between routes coming from different protocols.

AD range is between 0 ( connected routes) and 255. But AD 255 means not usable and this is not related to EIGRP but it is a general concept.  Last usable AD value is 254 as you have noted.

the command that you have used

>> summary-metric 192.168.255.0/24 distance 255

can change the administrative distance of the summary route and not  the EIGRP advertised distance  (the name is similar but they are really different things).

If the EIGRP summay route cannot be installed in the local node IP routing table because AD=255 means unusable, it cannot be advertised to other nodes.

If you see this, I would say that what you see is normal.

The command reference explains the command that you have used

see

http://www.cisco.com/en/US/docs/ios-xml/ios/iproute_eigrp/command/ire-s1.html#GUID-88F572B5-3506-4340-B5B2-2AFA7F069A36

The objective of this  really new command ( introduced in 15.0.1M) is to avoid frequent recalculation of EIGRP metric to be given to the summary route that by default is the lowest among all component routes.

The command accepts the distance parameter but it is the administrative distance not the EIGRP metric.

You can set manually the EIGRP metric (and so the EIGRP advertised distance) of the summary route using the usual array of values (bandwidth.. mtu) see from command reference:

To configure a fixed metric for an Enhanced Interior Gateway Routing Protocol (EIGRP) summary aggregate address, use the              summary-metric command in address family topology configuration mode. To remove a configured metric, use the              no form of this command.

summary-metric network-address subnet-mask {bandwidth delay reliability load mtu [distance administrative-distance] | distance administrative-distance}
no summary-metric network-address subnet-mask

Hope to help

Giuseppe

Highlighted
Hall of Fame Cisco Employee

Hello Giuseppe,

If the EIGRP summay route cannot be installed in the local node IP  routing table because AD=255 means unusable, it cannot be advertised to  other nodes.

If you see this, I would say that what you see is normal.

I respectfully disagree here. The behavior must have changed in recent IOSes. Note the behavior of the 12.4T IOS. I have two routers, R1 and R2, connected back to back.

R1:

interface Loopback0

ip address 192.0.2.1 255.255.255.255

!

interface Serial1/0

ip address 10.0.12.1 255.255.255.0

ip summary-address eigrp 1 192.0.2.0 255.255.255.0 255

serial restart-delay 0

!

router eigrp 1

network 10.0.12.1 0.0.0.0

network 192.0.2.1 0.0.0.0

no auto-summary

!        

R1#show ip route

Codes: 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

       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

       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     10.0.0.0/24 is subnetted, 1 subnets

C       10.0.12.0 is directly connected, Serial1/0

     192.0.2.0/32 is subnetted, 1 subnets

C       192.0.2.1 is directly connected, Loopback0

R1#show ip eigrp topo

IP-EIGRP Topology Table for AS(1)/ID(10.0.12.1)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,

       r - reply Status, s - sia Status

P 10.0.12.0/24, 1 successors, FD is 2169856

        via Connected, Serial1/0

P 192.0.2.0/24, 1 successors, FD is 128256

        via Summary (128256/0), Null0

P 192.0.2.1/32, 1 successors, FD is 128256

        via Connected, Loopback0

R1#show ip eigrp topo 192.0.2.0

IP-EIGRP (AS 1): Topology entry for 192.0.2.0/24

  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 128256

  Routing Descriptor Blocks:

  0.0.0.0 (Null0), from 0.0.0.0, Send flag is 0x0

      Composite metric is (128256/0), Route is Internal

      Vector metric:

        Minimum bandwidth is 10000000 Kbit

        Total delay is 5000 microseconds

        Reliability is 255/255

        Load is 1/255

        Minimum MTU is 1514

        Hop count is 0

R2:

interface Serial1/0

ip address 10.0.12.2 255.255.255.0

serial restart-delay 0

!        

router eigrp 1

network 0.0.0.0

no auto-summary

!        

R2#show ip route

Codes: 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

       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

       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     10.0.0.0/24 is subnetted, 1 subnets

C       10.0.12.0 is directly connected, Serial1/0

D    192.0.2.0/24 [90/2297856] via 10.0.12.1, 00:01:22, Serial1/0

R2#show ip eigrp topo 192.0.2.0

IP-EIGRP (AS 1): Topology entry for 192.0.2.0/24

  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2297856

  Routing Descriptor Blocks:

  10.0.12.1 (Serial1/0), from 10.0.12.1, Send flag is 0x0

      Composite metric is (2297856/128256), Route is Internal

      Vector metric:

        Minimum bandwidth is 1544 Kbit

        Total delay is 25000 microseconds

        Reliability is 255/255

        Load is 1/255

        Minimum MTU is 1500

        Hop count is 1

Here you can see that on R1, I have summarized the 192.0.2.1/32 into 192.0.2.0/24 on S1/0 interface with AD=255. The automatic summary Null0 route is therefore not installed into R1's routing table, yet the topology table on R1 shows this route as being fine and alive and is advertised to R2 just fine.

However, starting with IOS versions somewhere around 15.x, the Command Reference about the ip summary-address eigrp command states indeed:

The summary address is not advertised to the peer if the administrative distance is configured as 255.

http://www.cisco.com/en/US/docs/ios-xml/ios/iproute_eigrp/command/ire-i1.html#GUID-F65B16C1-6E09-4C15-80DC-22B0537B1C9A

So - beware of unstable and changing command behaviors! Anton, what you observe on your 15.x IOS is, according to the documentation, normal. It was not normal on previous IOS versions, though.

Best regards,

Peter

View solution in original post

Highlighted

Hello, Giuseppe!

You helped recently with the solution of problems with redistribution of routes, and now there was a new question

Giuseppe Larosa написал(а):

...

first of all, what you call metrics is actually administrative distance that is a locally used parameter to choice between routes coming from different protocols.

...

The objective of this  really new command ( introduced in 15.0.1M) is to avoid frequent recalculation of EIGRP metric to be given to the summary route that by default is the lowest among all component routes.

The command accepts the distance parameter but it is the administrative distance not the EIGRP metric.

You can set manually the EIGRP metric (and so the EIGRP advertised distance) of the summary route using the usual array of values (bandwidth.. mtu) see from command reference:

....

I apologize, I not absolutely correctly expressed. AD, instead of a metrics meant really.

Peter Paluc написал(а):


...

However, starting with IOS versions somewhere around 15.x, the Command Reference about the ip summary-address eigrp command states indeed:

The summary address is not advertised to the peer if the administrative distance is configured as 255.

http://www.cisco.com/en/US/docs/ios-xml/ios/iproute_eigrp/command/ire-i1.html#GUID-F65B16C1-6E09-4C15-80DC-22B0537B1C9A

So  - beware of unstable and changing command behaviors! Anton, what you  observe on your 15.x IOS is, according to the documentation, normal. It  was not normal on previous IOS versions, though.


...

For some reason didn't find the description of that so shall be in 15.x. But if it so, then this command is senseless in case of AD=255.

Thanks for all for the help!

Highlighted
Hall of Fame Cisco Employee

Hi Anton,

For some reason didn't find the description of that so shall be in 15.x.  But if it so, then this command is senseless in case of AD=255.

Check the following URL:

http://www.cisco.com/en/US/docs/ios-xml/ios/iproute_eigrp/command/ire-i1.html#GUID-F65B16C1-6E09-4C15-80DC-22B0537B1C9A

and look for the exact phrase "summary address is not advertised".

Best regards,

Peter

Highlighted

Yes, it is exact! I initially looked this article, but for some reason thought that it concerns only release 12.2(33)SXJ

Thanks! Theme is closed.

Highlighted

Not quite senseless. I even have a couple of slides on this in my Cisco Live presentation. It's a bit hard to draw out on my iPad, but suffice it to say that there is a use case with dual homed remotes and summarizing to the same prefix as a received route. I'll try to remember to repost from work tomorrow when it will be a bit easier to draw it out.

Sent from Cisco Technical Support iPad App

Highlighted

Hello Peter,

I really appreciate your tests but the new behaviour is more correct in theory for the following reasons:

a) it follows the general meaning that AD=255  is an unusable route

b) it avoids to advertise a route when the summary route to Null0 is not installed in the local node routing table, and this is  considered a good move for routing loop avoidance  ( if a packet is not matching any component route is simply discarded on local node).

Finally this is a very special case, when changing the AD of an EIGRP summary route from default value (5) we usually want to avoid that the summary route to Null0 is preferred to any existing route.

In practice any AD value between 201 and 254 provides the same result to make the EIGRP summary route less preferred than a route generated in any other means.

So for example in my work experience I never tried to set the AD of an EIGRP summary route to 255 considering it dangerous and unneeded.

I have also no problems to admit that I didn't know this new command summary-metric and that in my opinion it should require the settings of seed metric via bandwidth ... mtu values as a required part of the command.

To only change the AD of the summary route we can already set it at interface level with ip summary-address eigrp command.

Hope to help

Giuseppe

Highlighted

Giuseppe,

The summary-metric command is used to simplify the summary metric processing in the presence of a large topo table. With legacy behavior, every time a prefix changes we would have to cruise the entire topo table to make sure the metric on our summaries still match the best component. With a large topo table, this will limit the scaling. By specifying the metric directly, we avoid this processing completely.

The reason a seed metric isn't needed in the AD 255 case is that we aren't going to send it out anyway, so no metric is required. By specifying the AD 255 on the summary metric statement, we don't need to put it on each interface command.

Sent from Cisco Technical Support iPad App

View solution in original post

Highlighted
Hall of Fame Cisco Employee

Hello Don and Giuseppe,

Don: Thanks for joining this thread - and revealing yet another nugget of knowledge about EIGRP! Oh, by the way, I am not saying that the change of the behavior is "senseless" - just unexpected. Perhaps I haven't chosen the words "normal / not normal" in a lucky way - I was merely referring to the behavior I've been used to. Once again, thank you for providing the background info!

Giuseppe: I agree with you. The only thing that I find slightly convoluted is the fact that I have always considered the AD to be a matter of the routing table, and basically a result of what type of network a routing protocol offers to the routing table. For example, in BGP, no setting of AD is going to influence the BGP bestpath algorithm. The AD of BGP routes is determined only afterwards, when the route is being offered from BGP to the routing table (if the route is learned via iBGP, it gets AD=200 by default, eBGP route gets AD=20 by default). The OSPF has had a bug corrected a few years ago in which it was possible to prefer external or inter-area routes to intra-area routes again by modifying the ADs of particular OSPF route types. This was in conflict with RFC 2328 that states strict order of preference between different route types in OSPF. The correction of this bug has made the AD of OSPF routes to again become a result of OSPF shortest path selection, not a parameter influencing OSPF choice making process. In EIGRP, it is different: the AD actually influences the route selection inside EIGRP, and I find that ... well, at least slightly confusing. As Don has noted a couple of times, the interaction is rather cumbersome and it is best to leave the AD of internal/external routes unchanged, especially in presence of multiple EIGRP processes.

The current behavior of not advertising a summary Null0 route with AD=255 actually strongly resembles OSPF's style of area range not-advertise command. The functionality is sligthly duplicated in EIGRP's case, as the same result could be achieved using distribute lists.

Oh, and I also did not know about the new summary-metric command

Don, Giuseppe, thank to you both once again!

Best regards,

Peter

Highlighted

To flesh out the use case, take the following topology:

Internet exit

       |   0.0.0.0  |

       |              V

       |

Core/Customer network

   |                |

Dist1          Dist2

     \            /

      \          /   0.0.0.0 summary on both Dist1 and Dist2 to Spoke

       \        /

        \      /

      Spoke

If you let the AD default on the summary, it's value of 5 wins over the received route for the internet exit point and thus the "real" default can't be followed.  If you set the AD on the summary to a value > real default but less that 255, it works until you have a failure.  When it works, it creates the summary queue entry and suppresses components but fails to install the summary in the rib and thus doesn't send the locally installed summary but sends the received route instead.  All is well.

If, however, the link from Dist1 to the rest of the Core network fails, it loses access to the received 0.0.0.0 and the local summary wins, even with an AD of 254.  If it's the only game in town, even 254 is best.  In this example, Dist1 would then be sending an internal (since that's how a summary appears) and Dist2 would continue to send the received 0.0.0.0.  If the received route is an external, the route on the spoke thru Dist1 wins, sending all of the traffic to the router that doesn't actually have access to anything in the Core or beyond.  Black hole time.

With the AD of 255 on the summary, the components are supressed but the route is not advertised, relying on the received route to make routing work.  Note that if you use AD 255 on the summary toward a single-homed remote, you could end up stranding it in the event that the real received route is lost.

Highlighted
Hall of Fame Cisco Employee

Hello Don,

Nice example! Thank you!

Best regards,

Peter

Content for Community-Ad