Why is EIGRP automatically redistributing a static route?

Unanswered Question
Jan 22nd, 2010
User Badges:
  • Bronze, 100 points or more

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

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (4 ratings)
Loading.
Jon Marshall Fri, 01/22/2010 - 18:56
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

johnnylingo wrote:


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



You have a network statement of 198.19.0.0 0.0.1.255 which equals networks -


198.19.0.0

198.19.1.0


you then have a static route pointing to a Nullo interface. This is a static route pointing to a directly connected interface. Because it is directly connected and because you have matching network statement under your EIGRP config the route is showing up in the EIGRP topology table and will be redsitributed to any EIGRP neighbors.


Jon

Peter Paluch Sat, 01/23/2010 - 02:26
User Badges:
  • Cisco Employee,

Hello Johnny,


In addition to Jon's wonderful reply, if you define a static route using an outgoing interface only (i.e. without next hop IP address), it is treated by router as directly connected even though it is statically defined. That is kind of logical because you are saying that "this network is on this interface". Now, for distance vector routing protocols, every directly connected network including those statically defined can be advertised simply using the network command. This goes for RIP, IGRP and EIGRP. That is the reason why the 198.19.0.0/16 network was advertised because the EIGRP treated it as any other directly connected network.


Link-state routing protocols (OSPF, IS-IS) cannot be cheated this way. The network covered by the network command must be indeed a network defined on an interface by the command ip address. Statically defined connected networks created using the ip route command can be advertised only by explicit redistribution in link-state routing protocols.


Best regards,

Peter

marikakis Sat, 01/23/2010 - 12:02
User Badges:
  • Gold, 750 points or more

Hi all,


Jon and Peter, I do appreciate your posts. I still think however that this behavior is weird. Although I haven't come across this from my own experience, there are others who have and I am not suggesting this is a bug. I view it more as a side-effect or gotcha. The explanation that this is a "directly connected" flavored static doesn't seem enough to me to explain why automatic "internal redistribution" is happening. [By the way, as far as I know, a static is always static and has AD higher than AD 0 that only true Connected routes can have. The notation "directly connected" has to do with how the forwarding engine sees the routes]. Maybe this is some sort of historical behavior (e.g. to overcome hop-count limitations in distance vector protocols). I don't know.


Kind Regards,

Maria

Peter Paluch Sat, 01/23/2010 - 13:08
User Badges:
  • Cisco Employee,

Hello Maria,


"The explanation that this is a "directly connected" flavored static doesn't seem enough to me to explain why automatic "internal redistribution" is happening."


I would say that the IOS itself is not consistent about such routes but they do have significant traits of directly connected routes. If you define a static route to a network X using only an outgoing interface, the router tries to talk to each node in network X as if it was indeed directly connected on that interface. If it is an Ethernet, it will ARP for its MAC address. If it is Frame Relay or ATM, it will try to look it in the IP/DLCI or IP/VPI,VCI mappings. If it is a BRI interface, it will look into dialer map tables... so the packet delivery mechanisms indeed treat such network as directly connected.


A routing protocol of course knows that this route is static. Why does the "redistribution" apply in this case is not clear to me, neither. Moreover, the behavior is not consistent - the DV routing protocols do this redistribution, the LS do not. I would personally like better if the networks were not redistributed. What I think about all this is that this is some kind of quirk (or a forgotten functionality) in IOS that has been leveraged by groups programming the DV protocols but that has not been picked up by the teams responsible for LS protocols. I see it as an implementation-dependent issue, not as a principal matter. But then again, somebody else responsible for certification exams might think that this is of utmost importance and shove some questions about it into exams


Best regards,

Peter

Richard Burts Sat, 01/23/2010 - 13:44
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

While it may be intuitive, I believe that it is not correct to refer to this as automatic "internal redistribution" . I believe that there is a significant clue to the behavior in the original post:

"Composite metric is (256/0), Route is Internal"

note that EIGRP is treating this as an internal route (matches a network statement) and not as an external router (result of redistribution).


The behavior of the routing protocol is to look for connected networks that match a network statement and to advertise those networks. That is what EIGRP is doing in this case. It did not redistribute the "static", it is advertising a "connected" route>


HTH


Rick


[edit] It may help Peter and some others to remember one of the distinctions between DV routing protocols and Link State Protocols. DV protocols recognize and advertise networks while Link State advertises links. The static to a connected interface is treated as a connected network, but it is not recognized as a connected link.

Peter Paluch Sat, 01/23/2010 - 13:51
User Badges:
  • Cisco Employee,

Hi Rick,


Thank you for replying. Nobody doubts that the EIGRP sees this network as internal and it also advertises it as such. Nevertheless, the show ip eigrp topology output that you have quoted also contains information that suggest that EIGRP at least understands that it is not a real directly connected route:


  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


Note a couple of "weird" values here:


  • From Rstatic - the same as with all static redistributed routes
  • Delay, reliability and load are set to 0 which no real directly connected network would have (the lowest configurable value is 1, not 0)


Best regards,

Peter


[edit] Yes, of course, I am well aware of the difference between DV and LS protocols but this all boils down into how this is coded inside IOS, and therefore I am afraid we are trying to find a "deeply buried truth" when in fact, it is just the way the IOS does this. The OSPF advertises links - very well but there is no problem in advertising a statically defined connected route as a link to a stub network. This would be identical to OSPF advertising, say, a loopback or a stub FastEthernet network. Once again - it can be done very easily, just the IOS does not do it. In my opinion, it is not an issue of a routing protocol, rather it is an implementation issue. I wish that an IOS programmer read these forums sometimes...

Richard Burts Sat, 01/23/2010 - 14:13
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Peter


From your previous post:

"A routing protocol of course knows that this route is static. Why does the "redistribution" apply in this case is not clear to me, neither. Moreover, the behavior is not consistent - the DV routing protocols do this redistribution, the LS do not."


My point is that it is really not redistribution in EIGRP. And if it is not redistribution then it is not so much inconsistency in IOS as it is differences in the protocols about how they decide what to advertise.


HTH


Rick

Peter Paluch Sat, 01/23/2010 - 14:40
User Badges:
  • Cisco Employee,

Hello Rick,


I understand what you mean. But even so, that does not "ring a bell" for me here. I have no problems accepting that the EIGRP advertises this network as any other directly connected network and that calling it a redistribution is probably not correct. All this is fine by me.


But let's not confuse the fundamental principle of a routing protocol (i.e. what is the actual information it transmits and what data does it base its algorithm on) with a method of choosing which locally known networks it decides to advertise. I agree wholeheartedly that OSPF advertises links. But a  link is just an abstract way of saying "I have a direct access to this object". A link is not an interface per se - it is a more general concept. There is no need to look only for interfaces when advertising links in OSPF, and in fact, if you look closely at links advertised by OSPF, many of them are strongly artificial - each point-to-point interface is represented by two links in LSA1 - the one is for the adjacent router, the other is for the IP network that is present on the point-to-point network. From this viewpoint, it is nothing foreign for OSPF to take a statically created connected route and advertise it as just another link.


Best regards,

Peter

marikakis Sat, 01/23/2010 - 14:36
User Badges:
  • Gold, 750 points or more

Hi all,


Nice discussion we are having here!   Redistribution in general is the sharing of information between different routing protocols. According to Zinin, redistribution is the adoption of routes from the routing table, performed by a dynamic routing protocol that is not the source of these routes. When I said 'redistribution' I didn't refer to an explicit 'redistribute' command, and anyway, that was the problem in this case in the first place (i.e. that it was not explicit). So, allow me to insist on this terminology! Hope this isn't a big problem!


I will also insist on the separation of "directly attached networks" (the well known Connected) from "directly connected routes" (Connected and Static without next-hop information). This is also found in Zinin's Cisco IP Routing. If this distinction is ignored, people start thinking some Static's have a 0 AD, start writing certification books about this gotcha, and takes years for people to clear their understanding about what's going on (I guess the worst kind of gotcha is the one that doesn't even exist).


Kind Regards,

Maria

Jon Marshall Sat, 01/23/2010 - 15:46
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

rburts wrote:


While it may be intuitive, I believe that it is not correct to refer to this as automatic "internal redistribution" . I believe that there is a significant clue to the behavior in the original post:

"Composite metric is (256/0), Route is Internal"

note that EIGRP is treating this as an internal route (matches a network statement) and not as an external router (result of redistribution).


The behavior of the routing protocol is to look for connected networks that match a network statement and to advertise those networks. That is what EIGRP is doing in this case. It did not redistribute the "static", it is advertising a "connected" route>


HTH


Rick


[edit] It may help Peter and some others to remember one of the distinctions between DV routing protocols and Link State Protocols. DV protocols recognize and advertise networks while Link State advertises links. The static to a connected interface is treated as a connected network, but it is not recognized as a connected link.


Rick


You are being slightly selective in which bits you choose from the output


Yes it reports it as internal but as Peter pointed out it also reports it as Rstatic. And there is no denying that there is a static route configured on the router. How EIGRP sees that static route is the matter of debate here but it is a fair statement, it think,  to say their is a dynamic routing protocol (EIGRP) and a static route and the static route has been learnt by EIGRP.


Now using Maria's definition of redistribution you could say that redistribution has therefore occured. Perhaps we are just arguing over semantics !


Lastly i think if you looked at the posts of people on this thread you should probably know that they would be aware of the fundamental difference between DV and Link state protocols. I do think it's important to take into account the experience of the poster when answering.


Jon

Peter Paluch Sat, 01/23/2010 - 16:02
User Badges:
  • Cisco Employee,

Hello Jon,


First of all, thank you very much for joining this discussion. I enjoy it tremendously!


Perhaps this is indeed about semantics. We see a static route being advertised without doing the usual obligatory configuration and now we are confused and trying to measure things by defining properties to sort them out. The problem is perhaps that many of our concepts are not well defined, rather they are intuitive. What exactly does it mean when we write the network or redistribute statement? We know the answer from our experience but that is not an exhaustive, unambiguous definition. It is merely an intuitive understanding. The only conclusive definition here could be given by a person that has access to the IOS source code because that is the ultimate source of information about the machinery behind the network or redistribute commands.


Lastly i think if you looked at the posts of people on this thread you should probably know that they would be aware of the fundamental difference between DV and Link state protocols


This is very considerate of you, Jon, thank you. Nevertheless, Rick - I do not feel offended in any way. I understand that you had to reiterate a fact because it comprised the idea you wanted to convey.


Best regards,

Peter

Jon Marshall Sat, 01/23/2010 - 16:17
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

paluchpeter wrote:


Hello Jon,


First of all, thank you very much for joining this discussion. I enjoy it tremendously!


Perhaps this is indeed about semantics. We see a static route being advertised without doing the usual obligatory configuration and now we are confused and trying to measure things by defining properties to sort them out. The problem is perhaps that many of our concepts are not well defined, rather they are intuitive. What exactly does it mean when we write the network or redistribute statement? We know the answer from our experience but that is not an exhaustive, unambiguous definition. It is merely an intuitive understanding. The only conclusive definition here could be given by a person that has access to the IOS source code because that is the ultimate source of information about the machinery behind the network or redistribute commands.


Lastly i think if you looked at the posts of people on this thread you should probably know that they would be aware of the fundamental difference between DV and Link state protocols


This is very considerate of you, Jon, thank you. Nevertheless, Rick - I do not feel offended in any way. I understand that you had to reiterate a fact because it comprised the idea you wanted to convey.


Best regards,

Peter


Peter


Funnily enough there is a guy called Russ White who works for Cisco and has access to the source code of EIGRP and he used to post on these forums. There are a few times where people have disagreed over specifics on EIGRP and then along came Russ who would say something along the lines of "well i've just checked the code and ...". The discussion kind of ended there


Jon

marikakis Sat, 01/23/2010 - 16:26
User Badges:
  • Gold, 750 points or more

Hi Jon,


I think one of the problems with EIGRP is that it's cisco proprietary and we can't really argue a lot about its logic (that's why it's my least favorite routing protocol). This case brought to me thoughts of Russ as well!


Kind Regards,

Maria

Peter Paluch Sat, 01/23/2010 - 16:38
User Badges:
  • Cisco Employee,

Maria, Jon,


Mr. Russ White? Hmm, I have not had the honor to meet him here in person, I can just look up his posts. I certainly hope he's still around!


Regarding the EIGRP, I have found the its principles very attractive (the diffusing updates by Dijkstra and Scholten, the DUAL by Garcia) but right as Mr. Jeff Doyle pointed out on his blog, the amazement can quickly turn into horror if there is something going wrong with EIGRP-based network and out of sudden, no one seems to have a profound understanding of it. Exactly as Maria said, it is a black box and the details are "leaking out" very slowly. Just how long did it take to tone down the hype that the EIGRP is a "hybrid" protocol? I think it was 5 years at least, and it is still going around.


Best regards,

Peter

marikakis Sat, 01/23/2010 - 17:09
User Badges:
  • Gold, 750 points or more

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 Sat, 01/23/2010 - 19:08
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

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 Sat, 01/23/2010 - 21:56
User Badges:
  • Gold, 750 points or more

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 Sun, 01/24/2010 - 00:33
User Badges:
  • Cisco Employee,

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 Sun, 01/24/2010 - 09:26
User Badges:
  • Gold, 750 points or more

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 Sun, 01/24/2010 - 15:16
User Badges:
  • Cisco Employee,

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 Mon, 01/25/2010 - 03:37
User Badges:
  • Gold, 750 points or more

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 Fri, 01/29/2010 - 08:32
User Badges:
  • Gold, 750 points or more

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 Sat, 01/23/2010 - 16:06
User Badges:
  • Gold, 750 points or more

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 Sat, 01/23/2010 - 16:19
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

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 Mon, 01/25/2010 - 11:58
User Badges:
  • Bronze, 100 points or more

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 Mon, 01/25/2010 - 13:21
User Badges:
  • Gold, 750 points or more

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 Mon, 01/25/2010 - 13:56
User Badges:
  • Bronze, 100 points or more

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 Mon, 01/25/2010 - 14:40
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

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 Mon, 01/25/2010 - 15:34
User Badges:
  • Bronze, 100 points or more

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.

marikakis Mon, 01/25/2010 - 18:40
User Badges:
  • Gold, 750 points or more

Hi Johnny,


It's really past my bedtime and we should not count on my subnetting skills right now. Can you do the following tests?


a. network 10.0.0.0/8 AND static routes with masks /7, /8, /9, /16, /24, /25 (first 2 should contain network and the rest be contained in network)

b. network 10.10.0.0/16 AND static routes with masks /15, /16, /17, /24, /25 (first 2 should contain network and the rest be contained in network)


1. At the beginning of each test put each static route alone and see what happens

2. Then try to add them all from more specific to less specific (maybe it would be interesting to make each specific contained in all the less specific ones)

3. Repeat 2 in reverse order


Kind Regards,

Maria

Peter Paluch Mon, 01/25/2010 - 13:50
User Badges:
  • Cisco Employee,

Hi Johnny,


Please repeat your experiment but any time you change the EIGRP configuration and/or the static routes in your routing table, issue the command clear ip route * on your CORE-2 router and wait up to 15-20 seconds before looking into the EIGRP topology table. I have had somewhat similar experience to yours but it turned out that the EIGRP missed to detect changes in the routing table contents. The clear ip route * should tickle the EIGRP process strong enough to notice that the contents of the routing table have changed.


Best regards,

Peter

johnnylingo Mon, 01/25/2010 - 13:59
User Badges:
  • Bronze, 100 points or more

What I found that clearing the route table doesn't affect the routes, but sometimes changes the FD:



CORE-2#clear ip route *

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

marikakis Mon, 01/25/2010 - 14:18
User Badges:
  • Gold, 750 points or more

Hi Johnny,


When doing explicit redistribution into EIGRP, for Connected and Static routes the metric information is taken from the associated interfaces. Can you check if this makes any sense in the context of your results?


You are taking your revenge now, don't you? I feel under DDoS from test results! I am trying to write down a summary of your results and I feel confused sometimes. Up to now, it is clear that you should not use next-hop information to explore this behavior. There are 3 parameters in your tests. The classful mask of the network you are using, the mask of the network statement,  and the mask of the static route. Try to keep as many parameters constant while exploring possibilities. Also, maybe you should note each time the mask of any interfaces included in the network you are exploring (when such an interface exists).


Kind Regards,

Maria

johnnylingo Mon, 01/25/2010 - 14:58
User Badges:
  • Bronze, 100 points or more

When doing explicit redistribution into EIGRP, for Connected and Static routes the metric information is taken from the associated interfaces. Can you check if this makes any sense in the context of your results?


Absolutely correct.  If I change the static route to Serial0/0, the FD changes from 256 to 2178560.  If I add the new route before deleting the existing one, then "clear ip route *" is needed for the FD change to be picked up.

david scott Thu, 09/11/2014 - 00:06
User Badges:

 

Think of the routing process as advertising connected subnets instead of connected interfaces.

 

A connected Subnet (it's not via any hops):

ip route 198.19.0.0 255.255.0.0 via serial 0

 

Not a connected subnet (it's at least a hop away):

ip route 198.19.1.0 255.255.0.0 via 10.10.10.1

 

 

Actions

This Discussion