Why is EIGRP automatically redistributing a static route?

[johnnylingo]

Spotted this in my CCIE lab and am rather baffled.  Why would EIGRP redistribute a static route even though I've configured it not to?

Configuration:

ip classess

!

router eigrp 65100
network 198.19.0.0 0.0.1.255
no auto-summary
!

ip route 198.19.0.0 255.255.0.0 Null0

CORE-2#sh ip eigrp top 198.19.0.0/16
IP-EIGRP (AS 65100): Topology entry for 198.19.0.0/16
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 256
  Routing Descriptor Blocks:
  0.0.0.0, from Rstatic, Send flag is 0x0
      Composite metric is (256/0), Route is Internal
      Vector metric:
        Minimum bandwidth is 10000000 Kbit
        Total delay is 0 microseconds
        Reliability is 0/255
        Load is 0/255
        Minimum MTU is 1500
        Hop count is 0

[marikakis]

Hi all,

I haven't looked at the source code, but according to the following cisco document "redistribution" of statics to an interface happens  (under the circumstances described in this thread) because EIGRP considers the route as "directly attached":

http://www.ciscosystems.com/en/US/tech/tk365/technologies_white_paper09186a0080094cb7.shtml#statictointerface

I still don't see anywhere why EIGRP thinks this way.

Kind Regards,

Maria

[Richard Burts]

First let me say that I believe that a LOT of this thread is about semantics. Several of the early posts in this thread were talking about redistribution of static routes and about inconsistencies in IOS about this. The major part of what I have been trying to say is that it is really not redistribution. (if it were redistribution then EIGRP would advertise the route as external, and in fact EIGRP advertises these routes as internal). And I believe that once we get away from understanding this as an issue of redistribution, then instead of being concerned about inconsistencies in IOS, that we are dealing with differences in how different protocols choose what to advertise.

Jon - you are quite right that I was selective in what I chose to discuss from the original post. I clearly said "here is a clue to what is going on". I did not indicate that I had a comprehensive discussion of the topology entry, but did think that there was something there that spoke clearly to the question of whether this route was external (the result of redistribution) or was internal (the result of advertisement not of redistribution).  --- and for the record I acknowledge that there are inconsistencies in the complete topology entry which reflect inconsistency about static route vs truly connected interface..

Jon - about the remark about considering the level of understanding of the participants. I regard all the people participating in this discussion as having very good level of understanding of Cisco and of routing protocols. I do not believe that anything that I have said was above their level of understanding.

Maria - thanks for this link which clearly does discuss this issue. I am disappointed to see that the discussion refers to it as redistribution, and repeat my position that this is EIGRP advertising a "connected" network and not redistributing a static. I believe that the question of how it starts off as a static route and winds up being considered as a connected route was dealt with very well by Jon and Peter in the early posts of this thread.

HTH

Rick

[marikakis]

Hi Rick,

I also thought that Jon and Peter's posts were good (and rated them). I am glad that we agree on this. Sorry for the confusion. My purpose was not to get into the discussion of what redistribution is. My question was more: why OSPF doesn't exhibit this behavior while EIGRP does?  I haven't found or seen an answer to this yet. I am more of an OSPF fan and if an OSPF router would advertise any static route (implicitly or explicitly) using any type of LSA (not just external), I would call this "redistribution". By the way, if creation of externals defines redistribution and vice versa, how would we define redistribution in the context of say RIPv1?

Kind Regards,

Maria

[Peter Paluch]

Hello Rick, Maria, Jon,

Rick, you wrote:

if it were redistribution then EIGRP would advertise the route as
external, and in fact EIGRP advertises these routes as internal

I think that this statement goes to the core of your understanding of the issue, and its logic is very clear - if something is redistributed, it is supposed to be advertised as external information. But it seems here that this implication cannot be used as a defining property of what redistribution is or when does it happen.

As Maria has pointed out, and I agree with her completely, a redistribution to me is a process of injecting routing information into a particular routing protocol from a different source of routing information. Whether the target routing protocol decides to mark such information as external or internal, however, that depends on its capabilities and on its particular implementation, and is not a clear or unambiguous indication of redistribution. Seeing a route as external clearly indicates it has been redistributed. But seeing a route as internal does not necessarily indicate it was injected using the network command - some protocols like RIP do not even have the ability to distinguish an internal route from an external, and right now we see that RIP/EIGRP like to advertise directly connected routes (i.e. static routes using an outgoing interface) as internal. Does that information come from a different source of routing information? I would say so - it is by all means a static route, not a network on a local interface. Yet, it is advertised in EIGRP as internal. For you, it is an indication that it is not a redistribution right because it is advertised as internal. For me, it still looks like redistribution because it is injected into EIGRP from a different routing information source (Rstatic) - it is just advertised in an unexpected way as internal.

Once again, I have a strong feeling that we are seeking for a big logical and stunning explanation of this behavior when really there may be none. It may be as simple and flat as saying that "somebody coded the algorithm to select the routes to be advertised by the network command to work in this way for the ancient RIP and the IGRP/EIGRP codebase reuses that code". As far as I have heard, the RIP/IGRP/EIGRP codebase is maintained by the same group of people.

Nevertheless, if the RIP/IGRP/EIGRP didn't behave this way, nobody would complain, I believe. It is not a particularily useful feature, but merely a curiosity - and a pretty confusing one.

Best regards,

Peter

[marikakis]

Hi all,

Since we brought pretty much all the routing protocols into the discussion, why should we leave BGP outside complaining? It's really unfair, especially if we take into account its associated alchemy tricks to turn questionable, unknown heritage, incomplete routes into pure and clean routes with IGP origin that keep everybody happy.

Just because we can't see a reason for something happening, it doesn't mean one doesn't exist. My favorite TV series is Dr House. Doctors perform a procedure called differential diagnosis to find the most possible disease based on the symptoms of the patient (in our profession we call this debugging or troubleshooting). In one of the cases, one of the doctors says: Maybe it's idiopathic . House responds: Idiopathic means we do not know the underlying cause. It means we are and can't figure what is causing this! Of course Peter could be right and this might have been something started in a specific manner and left like that to avoid confusing people about the expected behavior.

Anyway, I guess what usually matters the most is to know how to configure something, its expected behavior, and fix it if it's broken.

Kind Regards,

Maria

p.s. When the author of the thread resumes control of the thread he is gonna be like: "what happened to my thread?"

[Peter Paluch]

Hello Maria,

I will not attempt to introduce the BGP here for three reasons: first, it is not really to the point of this thread as the BGP is supposed to take whatever route it finds in the routing table if it matches a network command; second, because all the quirks and miracles of BGP require their own thread; and third, because you happen to know too much about BGP, anyway

When the author of the thread resumes control of the thread he is gonna be like: "what happened to my thread?"

Yes - poor guy! He had such a simple question, and we have made such abhorrently lengthy debate around it Shall we continue?

Best regards,

Peter

[marikakis]

Hi Peter,

It's Monday now, so I guess the game is over. Author might be coming anytime soon. He's working towards dual CCIE, so he should know by now that dual CCIE means double damage! I do not claim to possess the absolute truth. Still, I get the feeling he could say something like: Sure this is redistribution people! Can't you just read the title of the thread?

Kind Regards,

Maria

[marikakis]

Hi all,

Sorry for bringing this lengthy discussion back to life. After almost a week has passed and I can see things from some distance, I feel like apologising not so much about the length of the discussion, but rather about being involved in a disagreement that makes me recall the history of how the payload of 48 bytes in ATM cells was chosen.

"ATM broke up all packets, data, and voice streams into 48-byte chunks, adding a 5-byte routing header to each one so that they could be reassembled later. The choice of 48 bytes was political rather than technical. When the CCITT was standardizing ATM, parties from the United States wanted a 64-byte payload because this was felt to be a good compromise between larger payloads optimized for data transmission and shorter payloads optimized for real-time applications like voice; parties from Europe wanted 32-byte payloads because the small size (and therefore short transmission times) simplify voice applications with respect to echo cancellation. Most of the European parties eventually came around to the arguments made by the Americans, but France and a few others held out for a shorter cell length. With 32 bytes, France would have been able to implement an ATM-based voice network with calls from one end of France to the other requiring no echo cancellation. 48 bytes (plus 5 header bytes = 53) was chosen as a compromise between the two sides. 5-byte headers were chosen because it was thought that 10% of the payload was the maximum price to pay for routing information. ATM multiplexed these 53-byte cells instead of packets. Doing so reduced the worst-case jitter due to cell contention by a factor of almost 30, minimizing the need for echo cancellers." (source: wikipedia)

I guess Rstatic and internal is a good compromise. Only problem is that the echo wasn't cancelled so effectively in our case!

Kind Regards,

Maria

[marikakis]

Jon,

Don't worry, I don't think anyone has a problem with Rick's comments. I have learned things from him in the past and I do enjoy this discussion.  I agree that we should generally be careful with terminology when it causes confusion or be careful at least during times when the network isn't falling apart and we have plenty of time for semantics! I myself have sent a couple of e-mails to cisco press in the past about the AD of statics and have seen at least one book corrected some time later. Some of them are still out there however.

Kind Regards,

Maria

[Jon Marshall]

marikakis wrote:
Jon,
Don't worry, I don't think anyone has a problem with Rick's comments. I have learned things from him in the past and I do enjoy this discussion.  I agree that we should generally be careful with terminology when it causes confusion or be careful at least during times when the network isn't falling apart and we have plenty of time for semantics!  I myself have sent a couple of e-mails to cisco press in the past about the AD of statics and have seen at least one book corrected some time later. Some of them are still out there however.
Kind Regards,
Maria

Maria

Don't worry, I don't think anyone has a problem with Rick's comments. I have learned things from him in the past and I do enjoy this discussion.

Agreed. I have learned from Rick as well so it was not meant to offend but it is important to understand the level of expertise of people you are responding to.

Jon

[johnnylingo]

Wow, well let's just say I'm glad all forum replies go to my work e-mail.   I'm glad I was able to spend the weekend in complete ignorance to the fury of replies

I did some more toying around, and found this behavior is specific to EIGRP when there is a Null route, as proven by this:

no ip route 198.19.0.0 255.255.0.0 Null0

ip route 198.19.0.0 255.255.0.0 198.19.0.1

CORE-2#sh ip ro st
S    198.19.0.0/16 [1/0] via 198.19.0.1

CORE-2#sh ip eigrp top 198.19.0.0/16
% IP-EIGRP (AS 65100): Route not in topology table

If I go back to using Null0 and switch the mask, the route re-appears with that mask:

no ip route 198.19.0.0 255.255.0.0 198.19.0.1

ip route 198.19.0.0 255.255.252.0 Null0

CORE-2#sh ip eigrp top 198.19.0.0/22
IP-EIGRP (AS 65100): Topology entry for 198.19.0.0/22
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 256

What if I just use class Cs instead?

no ip route 198.19.0.0 255.255.252.0 Null0

ip route 198.19.0.0 255.255.255.0 Null0

ip route 198.19.1.0 255.255.255.0 Null0

The behavior stops.  198.19.0.0/24 is directly connected, but why wasn't 198.19.1.0/24?   This is where it gets really interesting.

Maybe it's an IOS bug that considers 198.19.0.0/24 and 198.19.0.0/16 the same.   So what if I change my network statement to 198.19.0.0/16?

router eigrp 65100
no network 198.19.0.0 0.0.1.255

network 198.19.0.0 0.0.255.255

!

Still no 198.19.1.0/24!   What if I use something from a totally different range, like 198.19.128.0/20?

no ip route 198.19.0.0 255.255.255.0 Null0

no ip route 198.19.1.0 255.255.255.0 Null0

ip route 198.19.128.0 255.255.240.0 Null0

CORE-2#sh ip eigrp top 198.19.128.0/20
IP-EIGRP (AS 65100): Topology entry for 198.19.128.0/20
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 256

It's baaaack.  Note that I do not have any interfaces in the 198.19.128.0/20 prefix.  Now what if I change my network statement to be more specific?

router eigrp 65100

no network 198.19.0.0 0.0.255.255
network 198.19.128.0 0.0.63.255

!

My EIGRP neighbors drop, yet EIGRP still shows it in the topology:

CORE-2#sh ip eigrp top           
IP-EIGRP Topology Table for AS(65100)/ID(198.19.255.2)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - reply Status, s - sia Status

P 198.19.128.0/20, 1 successors, FD is 256
        via Rstatic (256/0)

OK, so it seems that this behavior correlates to the network statement, not the interfaces.   So what what if I do this?

router eigrp 65100
network 10.0.0.0
network 172.16.0.0 0.15.255.255

!

ip route 10.10.10.0 255.255.255.0 Null0
ip route 172.20.0.0 255.252.0.0 Null0

They appear:

CORE-2#sh ip eigrp top
P 10.10.10.0/24, 1 successors, FD is 256
        via Rstatic (256/0)
P 198.19.128.0/20, 1 successors, FD is 256
        via Rstatic (256/0)
P 172.20.0.0/14, 1 successors, FD is 256
        via Rstatic (256/0)

The best conclusion I can make is that when EIGRP sees a Null static route and it is contained in the network statement, it automatically redistributes the static route.  However, remember when I had this:

router eigrp 65100

network 198.19.128.0 0.0.63.255

!

ip route 198.19.100.0 255.255.255.0 Null0

ip route 198.19.200.0 255.255.255.0 Null0

198.19.100.0/24 should be advertised, and 198.19.200.0/24 should not, correct?  Nope!   Neither are!

CORE-2#sh ip eigrp top 198.19.100.0/24
% IP-EIGRP (AS 65100): Route not in topology table
CORE-2#sh ip eigrp top 198.19.200.0/24
% IP-EIGRP (AS 65100): Route not in topology table

OK, what about if the routes are **not** classful?

ip route 198.19.132.0 255.255.252.0 Null0
ip route 198.19.196.0 255.255.252.0 Null0

CORE-2#sh ip eigrp top 198.19.132.0/22
IP-EIGRP (AS 65100): Topology entry for 198.19.132.0/22
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 256
  Routing Descriptor Blocks:
  0.0.0.0, from Rstatic, Send flag is 0x0
      Composite metric is (256/0), Route is Internal
      Vector metric:
        Minimum bandwidth is 10000000 Kbit
        Total delay is 0 microseconds
        Reliability is 0/255
        Load is 0/255
        Minimum MTU is 1500
        Hop count is 0

CORE-2#sh ip eigrp top 198.19.196.0/22
% IP-EIGRP (AS 65100): Route not in topology table

Bam.   So if the static route to null is contained in the network statement and is NOT classful, EIGRP seems to think it's a sumary route and will redistribute the static route.

I'd really like to see the documentation on this one

[marikakis]

Hi Johnny,

Thanks for posting your test results. I will look at them more closely soon. From a quick look I just have one question for the time being: Did you test static routes referencing any other interface besides Null0? Also, in such a test it is important to not include a next-hop IP address in the static route.

Kind Regards,

Maria

p.s. All, see what the author was doing while we were chatting? Let's try to argue with that!

[johnnylingo]

Yes, it persists if the static route points to an interface, ie.

ip route 10.10.10.0 255.255.255.0 Serial0/0

CORE-2#sh ip eigrp topology 10.10.10.0/24
IP-EIGRP (AS 65100): Topology entry for 10.10.10.0/24
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 28160
  Routing Descriptor Blocks:
  0.0.0.0, from Rstatic, Send flag is 0x0
      Composite metric is (28160/0), Route is Internal

And I have confirmed it is always advertised as an Internal route (AD = 90), even if you add "redistribute static" to the EIGRP configuration.

However, if you have a static route that starts outside the network statement, then "redistribute static" is required and it will sent it as External (AD = 170).

It's been very interesting for me to see which routes it will advertise and which it will not.  Check this out:

router eigrp 65100

network 172.16.0.0 0.15.255.255

!

ip route 172.0.0.0 255.0.0.0 Null0
ip route 172.10.0.0 255.254.0.0 Null0
ip route 172.20.0.0 255.252.0.0 Null0
ip route 172.30.0.0 255.255.0.0 Null0

ip route 172.31.123.0 255.255.255.0 Null0

CORE-2#sh ip eigrp top | inc 172\.
P 172.30.0.0/16, 1 successors, FD is 28160
P 172.20.0.0/14, 1 successors, FD is 28160

Why were the last two static routes not included?  And why is the FD now 28160 rather than 256?

[Jon Marshall]

Hi all

Having a nice relaxing evening so had to think long and hard as to whether i really wanted to get involved with this thread again

Johnny, from your first test post -

The best conclusion I can make is that when EIGRP sees a Null static route and it is contained in the network statement, it automatically redistributes the static route.  However, remember when I had this:

router eigrp 65100

network 198.19.128.0 0.0.63.255

!

ip route 198.19.100.0 255.255.255.0 Null0

ip route 198.19.200.0 255.255.255.0 Null0

198.19.100.0/24 should be advertised, and 198.19.200.0/24 should not, correct?  Nope!   Neither are!

Neither should be advertised because 198.10.128.0  0.0.63.255 = network 198.10.128 -> 198.10.191 and neither of your static routes fall into that range.

Jon

[johnnylingo]

Neither should be advertised because 198.10.128.0  0.0.63.255 = network 198.10.128 -> 198.10.191 and neither of your static routes fall into that range.

Touché.  I had originally used 198.19.0.0 0.0.63.255 as my network statement, but didn't want overlap with my directly connected networks of 198.19.0.0/24 and 198.19.254.252/30.  Going back to the same config and using 198.19.150.0/24 cause it to show in the topology table.

The conclusion that I gained from it (that classful routes aren't inserted in to the table) would therefor be invalid.   However, I was on the right track.  Here's why:

ip classless

!

router eigrp 65100
network 172.16.0.0 0.15.255.255
no auto-summary

!

ip route 172.18.0.0 255.254.0.0 Null0
ip route 172.20.0.0 255.255.0.0 Null0
ip route 172.22.0.0 255.255.128.0 Null0
ip route 172.24.0.0 255.255.192.0 Null0

CORE-2#sh ip eigrp top | inc 172\.
P 172.20.0.0/16, 1 successors, FD is 256
P 172.18.0.0/15, 1 successors, FD is 256

Keep in mind there are no references to 172.16.0.0/12 addresses anywhere on this route or in the entire lab. 

Why were the first two routes put in the Topology table and the last two were not?  Clearly classful is in play here.