distance vs metric with int/ext EIGRP

[tato386]

I was under the impression that the admin distance was only used to make routing decisions between different types of routing protocols like RIP vs EIGRP, IGRP vs BGP and so forth.  Howerver I have included an example printout in which apparenly the admin distance is used to make a routing decision between internal and external EIGRP routes.  It seems like if internal and external EIGRP is treated like two different routing protocols.  Is this correct?

In the example below the router is configured so that internal EIGRP has a higher admin distance than external.  Specifically, the command "distance eigrp 180 175" is configured on this particular router.  In example #1 the topology shows two routes to 172.30.6.0 with the external route having a much higer metric BUT the route is external with a distance of 175 so it gets installed in the routing table.  So apparently the metric is ignored and the admin distance is used regardless of the metric.  Example #2 shows the other, internal route with admin distance 180 being installed once the external route is removed.

Am I interpreting this correctly?  Is there a way of modifying this behavior to rely metrics rather than admin distance?

Thanks,

Diego

[Jon Marshall · Accepted solution]

Basically when 2 routes are received to the same destination subnet with the same subnet mask then before metrics are used the AD is used. Once the AD has been compared if there are still multiple routes to the same destination then the metric comes into play.

So what you are seeing is normal ie. the AD is used in your case and the route with an AD if 175 is selected before the metric is ever considerd.

So the AD is not just used to select between routing protocols but also within protocols that have different ADs for different types of routes.

Jon

[Peter Paluch]

Hello Jon,

I have doubts on this, and I concur with Diego. I personally see a problem with the very fact that both the external and internal route come from the same routing process, in this case, EIGRP. It would be logical to assume that the EIGRP makes an internal choice between the internal and external route basing on its inner preferences (perhaps preferring internal routes over external, and/or using the metric to select the best option), and the AD would be simply assigned afterwards according to the route type. Think BGP - in BGP, the AD is not used during the bestpath algorithm - rather it is simply assigned afterwards, depending on whether the route came in through iBGP or eBGP. I would assume the same from EIGRP but Diego obviously proves this otherwise.

Best regards,

Peter

[Jon Marshall]

Hi Peter

Hmmm, i may be misunderstanding but if EIGRP was making an internal choice it would presumably pick the internal route and even if it included the metric, in Diego's example the metric of the external route was much higher. So how would an internal decision be made that would come out with the external route being chosen.

Considering the route chosen was an external route and had a higher metric i can only think it was because the AD was lower. I can't see how the decision could have been made otherwise.

Have i misunderstood ?

I agree BGP is different in the way it does things.

Jon

[tato386]

What surprised me is that I was under the assumption that the metric would the ONLY parameter used to choose within all known/received EIGRP routes.  The EIRGP metrics are quite sophisticated and plentiful.  Why would you need a sixth parameter?

I thought AD was only used to compare non-similar protocols since the metrics of non-similar protocols cannot be directly compared.

Just my 2 cents

[Peter Paluch]

Jon, Diego,

Jon, I agree that it is the AD that caused EIGRP to prefer the external route over the internal. My original complaint is related to the idea whether the AD should influence internal routing protocol's mechanism for best path selection in the first place. In other routing protocols, the AD is a result, not an input into that protocol's best path selection algorithm. OSPF, BGP - they all have their strict internal rules how to compare different types of routes to the same network, and they always offer a single best path candidate, not a best path candidate for every route type (internal, external, intra-area, inter-area).

It really depends on how you perceive the AD. One interpretation is that the routing protocol should have an exact selection algorithm how to compare routes of a different type to the same destination, like in OSPF or BGP. The AD is then used only to compare routes learned by different routing protocols.

Another interpretation is that I want to have an option to tell a routing protocol that I prefer external routes over internal, and I can do that only by mangling the ADs so that the external routes are preferred. In such a case, it is required that the routing protocol uses the AD as a part of its best path selection algorithm. The behavior of EIGRP is then understandable and logical.

The problem is that the behavior is largely and sadly inconsistent. Obviously, EIGRP behaves according to the second interpretation, and uses the AD during its selections to allow me, the admin, to say which kinds of routes I prefer. The OSPF, on the other hand, is very precise in this regard, and RFC 2328 mandates that there is a strict priority ordering on types of routes: O

Any ideas?

Best regars,

Peter

[Jon Marshall]

Peter

Yes i don't actually disagree with anything you say. Obviously when Cisco designed EIGRP they chose AD to distinguish between internal and external routes whereas as you say with other protocols such as OSPF/BGP they have their own internal process for choosing with route to use.

This is the main problem with EIGRP, it is Cisco proprietary so it is more prone to guesswork. Interestingly enough i was rereading an old post the other day which involved myself, you, Maria and Rick and it was a discussion about connected EIGRP routes being seen as redistributed static in EIGRP even though there was no "redistribute static" under the router eigrp config.

I also think my original answer was perhaps too general and i should have been very specific in terms of EIGRP. Part of the problem i think is that i have used EIGRP in a lot on different networks and i take certain things for granted which i probably shouldn't do.

That is also one of the reasons i appreciate your input in these threads because i think without a doubt you have a deeper understanding of protocol details than i have.

By the way, just sent you a response to your message. Need a bit of help with IM

Jon

[Peter Paluch]

Hello Jon,

It is a pleasure, as always, to discuss things with you! And before I start - I have my IM on already, and I've responded to your private message so just in case you're around, let's test it!

The fact is that I have always considered the AD to be used only between routing protocols, not inside them. EIGRP seems here to be an exemption from this rule. On one hand, it is Cisco-specific so that makes it quite understandable - after all, the whole concept of AD is Cisco-specific as well, although other vendors must have similar mechanisms. But if you take OSPF, IS-IS or BGP that do have their concept of network types, they are also already well-defined in the way they distinguish among them. As they were standardized outside of Cisco's AD, they do not use it internally.

Oh well.. I have always admired EIGRP, the theoretical beauty of its internal mechanisms and its good performance in networks. However, despite being documented (more or less), it is still clear that reading a description is not the same as reading the specification - and what we have about EIGRP is just its description, not its precise specification. Here and there, subtle white spots emerge that always surprise you, and just as you have indicated, this is all a guesswork. It is so easy in such an environment to start spreading misinformation (such as EIGRP is a "balanced hybrid protocol" )

Best regards,

Peter

[Jon Marshall]

Peter

Tried your settings and just get connected refused. I spent a lot of time last night with google.talk and jabber and depending on my pidgin settings i get different error messages but the key one seems to be "ssl handshake failed". Did a lot of googling and it does seem to be a common problem.

I suspect part of the problem may be i am running quite an old ubuntu ie. intrepid 8.10 and i cannot seem to get pidgin 2.6 on my laptop ( i am using 2.5.2). I have accounts setup with ICQ and google but still no joy. Google do have a web page you can go to and use messaging on there but it's a bit clumsy so i would prefer to get it working via my pidgin client.

I should really upgrade but am reluctant to do so at present because having just got back into NetPro the last thing i want is no working computer. Leave it with me and i'll keep working on it.

As for EIGRP, I have to say i was thinking about this last night after our correspondence on this and i really do think EIGRP, used correctly, is a great routing protocol as long as you are all Cisco. I actually quite appreciate Cisco using AD to distinguish between internal and external because it saves having to learn all those rules about best path selection, especially relevant to BGP. It seems to be the Cisco designers made a smart decision in that regard.

What i didn't know, until you mentioned it, was that AD is a Cisco specific thing. Not having a huge exposure to other vendors equipment it's not something that has ever occured to me but now you come to mention it, it makes perfect sense. This is part of the reason i enjoy these discussions, i am learning all the time !

Jon

[Peter Paluch]

Jon,

What i didn't know, until you mentioned it, was that AD is a Cisco specific thing

Probably I have made too strong a statement here but the idea remains: each vendor must solve in his own way how to decide which route goes into the routing table if several routing protocols offer their best alternatives. Cisco calls it the AD. Other vendors may choose to do it differently (although from what I have been able to google up, everybody makes pretty much the same thing). In my opinion, that is one of the reasons that routing protocols are not standardized from the beginning taking the administrative distance into account. Another thing to consider is that a routing protocol is generally a self-sustainable and closed unit. Why should, for example, John Moy put any stipulations into RFC 2328 about which OSPF route types are preferred or deferred when in comparison to, say, RIP? That is something that goes beyond a single routing protocol - it is more of an implementor's choice, and hence, there's no point in having it nailed down in a specification.

Regarding the WebEx session - I will probably be there. Are you going to attend as well?

Best regards,

Peter

[Jon Marshall]

Peter

Regarding the WebEx session - I will probably be there. Are you going to attend as well?

I tried but it didn't work which is weird because i have done webexs with Cisco on this laptop before. This time i got error about Java not being enabled even though it was and i tried to manually download meeting place but there was no download for linux.

To be honest i'm a bit annoyed at the moment, can't get IM working, couldn't login to webex meeting, seems like i might be losing my technical touch !

Anyway, if you did attend, hope it was useful and that you found it interesting.

Jon

[Peter Paluch]

Hey Jon,

Don't be annoyed at all. In fact, I have NEVER been able to successfully run WebEx on a Unix/Linux based operating system. The WebEx gets updated every now and then, and what worked a few months ago may not work now. I always have to use either my VirtualBox or a remote desktop connection to actually attend a WebEx meeting, and that is what I've done just now. This is what we get for being ardent Unix users

I am sure the session was recorded so you will have the possibility of seeing it yourself. Yes, I found it interesting and hope that more are coming.

Hey, no hard feelings about this one. Computers fail us all the time, that's what actually gives us work to do

Best regards,

Peter

[Jon Marshall]

By the way, are you doing this VIP Borderless Network thing this afternoon ? I'm a bit behind on technologies like that so i'm still debating.

Jon

[dslice]

Let me shed a little light on this. EIGRP uses the AD to prefer internal over external because the AD value is really a measure of believability of the route. An external EIGRP route is far less "believable" than an internal route because an internal has the metric determined by each link between the any point and the actual source of the route. In other words, it began life as a connected that was directly brought into EIGRP via a network statement and the metric was added for each link crossed.

An external route on the other hand came in through redistribution with the originating metric "made up" by the redistributing metric statement (or default-metric) and any metric and topology info between the redistributing router and the actual source of the route is completely lost.

Therefore if the route is known natively in EIGRP, it's always preferred over a route learned from another source

Clear?

[Peter Paluch]

Hello Donald,

Thank you for joining the discussion. You have summarized the obvious points very well and I agree with what you say. However, it does not really tackle the other issue: that the AD influences internal processes of a single routing protocol. The EIGRP is the only protocol where AD is also used internally as a part of best path selection criteria. As I mentioned quite a number of times, there is BGP with its iBGP/eBGP routes, there is OSPF with its intra-area/inter-area/external routes, and with those, the AD does not influence their internal decision processes at all - on the contrary, the AD is a result of their computation, not an input as with EIGRP. While there is a certain logic to EIGRP's behavior, Jon was very correct about commenting that it is sometimes a guesswork to understand what's going inside.

Best regards,

Peter