NX-OS EIGRP default metric on redistribution

[wintermute000]

According to everything I've ever read, for NX-OS and IOS, to redistribute something (say static) into EIGRP, the metric needs to be set, either on the redistribution or via default metric.


I am facing a customer environment where someone has configured a static redistribution with
- no default metric
- no metric under the route map


yet the redistribution is happening. WTF? I am 100% sure its redistributing based on topology table (both itself and its peers).

anyone seen this before?

The only thing I can think of is that the customer screwed up and under the route-map, it references two prefix-lists and the second route-map doesn't exist so its redistributing all. Is this an obscure corner case?
Now t here IS a default metric under show run all, but I thought and all the doco specifics you have to set it explicitly? Or has someone set it as a default metric in the past and the show run just hides it?

i.e.

router eigrp 1
  router-id xxx.xxx.xxx.xxx
  redistribute static route-map rm_static-eigrp1

  default-information originate always
  authentication mode md5
  authentication key-chain eigrp-md5-auth-key



route-map rm_static-eigrp1 permit 10
  match ip address prefix-list pl_static-eigrp1 permit
route-map rm_static-eigrp1 deny 20


that's it.... no metrics being set (except hidden under show run all).. the redistribution happens.


the funny bit here is that the word permit in the match statement is being interpreted as a prefix-list name and what seems to happen is that NX-OS interprets a missing PL as an allow any I"m wondering whether that has anything to do with it as well.

[that1guy15]

Possible solution is the route-map was deleted which set the metric but the peers were never bounced to apply the refreshed route-map.

Or yeah a bug where old route-map still lingering or something. Goblins!

With statics yeah man it dosent make sense, unless I forgot something which is a HUGE possibility.

[wintermute000]

well there clearly IS a default metric but only exposed under show run all. Is this default NX-OS behaviour and more importantly does this mean I don't need to set it explicitly if I change anything?

Moot point I suppose I'll just set it explicitly when I fix the config but would be good to know, really bugging me


EDIT: Tested in VIRL. Aaaaand.... it works fine without specifying a metric. And even more confusingly, in VIRL, show run all does NOT return a hidden default metric. WTF


FWIW the real thing was on 5.2(9).


Just to make y'all as angry as I am, here is the official cisco doco that says you must set a metric.
http://www.cisco.com/c/en/us/td/docs/switches/datacenter/sw/5_x/nx-os/unicast/configuration/guide/l3_cli_nxos/l3_eigrp.html#10172


And here is a cisco support forum post showing how you don't (option 3). Which VIRL and my live example both confirms.
https://supportforums.cisco.com/document/143831/3-ways-redistribute-default-static-route-eigrp-nexus-7000

I hate 7ks so much.

[that1guy15]

Interesting. Good to know.

Yeah agree death to all 7ks and 5ks.

[jason.copas]

I was under the impression that redistributing statics in eigrp broke the rule about needing to specify a metric.  My brain is telling me it uses the egress interface for metrics...

Found it.

[NetworkGroover]

I need a meme:

"And I'm just standing here like... why are people still running EIGRP?"

[NetworkGroover]

I need a meme:

"And I'm just standing here like... why are people still running EIGRP?"

[deanwebb]

WIN!

[wintermute000]

re: jason.copas, yes thats what this topic is all about. NX-OS on live 7k gear does not follow this rule.

re: EIGRP, taking aside the issue of vendor lock-in, there's plenty of situations where it makes perfect sense.

[deanwebb]

re: EIGRP, taking aside the issue of vendor lock-in, there's plenty of situations where it makes perfect sense.

True, especially in the small business market. Ain't nobody got time for OSPF there!

[NetworkGroover]

OSPF is not difficult. You can easily "make time for that". xD

EIGRP may make sense and have some benefits, but it's not going to live forever - open standard routing protocols will.  I've had the stance, before I even started working for a Cisco competitor, of not using EIGRP for that reason among others.

I can't remember off the top of my head.. but I think even the CCNP R&S books didn't cover EIGRP much at all... with a ton of content on OSPF and BGP.. that should be a sign.

[LynK]

@Aspiring,

Who is to say it will not live forever? It may not be proprietary forever, but as of right now EIGRP is a whole heck of a lot more efficient of a routing protocol, and more accurate out of the gate. There are appliances that are being released that do support EIGRP. The tools for implementing EIGRP are already out, and some people have even begun to adopt it.

https://tools.ietf.org/html/draft-savage-eigrp-00

[jason.copas]

re: jason.copas, yes thats what this topic is all about. NX-OS on live 7k gear does not follow this rule.

re: EIGRP, taking aside the issue of vendor lock-in, there's plenty of situations where it makes perfect sense.

It sounds like it is if I understood your post.  EIGRP does not need a seed metric on redistributed static (and connected) routes.  Isn't that what you are seeing?

Sent from my Nexus 6 using Tapatalk

[deanwebb]

OSPF is not difficult. You can easily "make time for that". xD

EIGRP may make sense and have some benefits, but it's not going to live forever - open standard routing protocols will.  I've had the stance, before I even started working for a Cisco competitor, of not using EIGRP for that reason among others.

I can't remember off the top of my head.. but I think even the CCNP R&S books didn't cover EIGRP much at all... with a ton of content on OSPF and BGP.. that should be a sign.

No need to have a lot of detail on EIGRP... it... just... works! Or doesn't, depending. But it's like a golden retriever of routing protocols. "HELLO! I AM EIGRP! I WILL ROUTE FOR YOU! YES I WILL! I WILL ROUTE REAL GOOD FOR YOU! YES I WILL!" If you're a SMB that can't afford a full time network guy and your head of operations is setting up the network, this is the protocol you want him to use because it don't mess up unless you try real hard to mess it up.

[NetworkGroover]

@Aspiring,

Who is to say it will not live forever? It may not be proprietary forever, but as of right now EIGRP is a whole heck of a lot more efficient of a routing protocol, and more accurate out of the gate. There are appliances that are being released that do support EIGRP. The tools for implementing EIGRP are already out, and some people have even begun to adopt it.

https://tools.ietf.org/html/draft-savage-eigrp-00

Yeah - Cisco released it, partially I believe, to claim that it was "open" so they could say they were "open".

I dunno where you're getting your info that "it's a whole heck of a lot more efficient of a routing protocol, and more accurate out of the gate".  Pretty sure there are no cloud titans running it, and if it was so great there'd be a bigger push for competing vendors to implement it.  I work for a competing vendor - there is no push for it.  Folks are running OSPF and BGP.

I think what you may mean is it's "easier" to deploy. 

But don't take my word for it in case you think I'm bias - here's what some Cisco folks had to say about it:
http://www.networkworld.com/article/2347622/cisco-subnet/eigrp-vs-ospf.html

Granted it's from 2007, but I bet most if it not all of it is still valid.

EDIT -  Or this from 2013:
https://keepingitclassless.net/2013/03/a-contest-of-protocols-eigrp-or-ospf/

Speaks to my point about liking it because it's "easier" deployment - OSPF still wins out.

EDIT - Or what this guy says in 2013:

From a practicle perspective I would say that in the case of EIGRP vs OSPF, OSPF always wins for the following reasons:

Convergence Speed:

Everyone always mentioned that EIGRP is faster than OSPF using default settings. If you deploy either protocol without reading about them and use their default settings, then you clearly don't know what you are doing in my opinion. Why would you deploy default settings without knowing what they are, and when you do realise what they are you realise that OSPF supports BFD and becomes lightening quick (as does ISIS).

Traffic Engineering:

Because OSPF like ISIS is based on TLV values, it has been extended quite a lot. It has support for extensions like MPLS-TE and GMPLS.

Continual Expansion

As I mentioned above, OSPF and ISIS have been extended quite a lot and extension drafts are being written fairly regularly and will continue to be. EIGRP doesn't have many of the advanced options these two do.

Scalability

OSPF scales better than EIGRP with its use of areas however, I don't think this really matters either (like the convergence time aregument, due to BFD). Not many people are running 10k routes in one area in OSPF. Typically I would use an IGP for fast routing within a given part of a network, but ultimately iBGP carries all the internal routes. Every single router doesn't need every internal route in its RIB sourced via OSPF if you have hundreds or thousands or routers, some of them are so far away (topologically speaking) it's worthless knowing about them.

Interoperability

Lastly there is the obviously reason that EIGRP is/was a Cisco proprietary technology. Although this has recently been submitted into a draft for other software vendors to start incorporating, it's too late (I believe). No currently running network is going to waste huge sums of money switching from some other IGP to EIGRP, and I don't know why a new network would consider it (if you are going to be mixing Cisco equipment with non-Cisco). Simply because non-Cisco equipment that supports OSPF has been doing so for years. The code is tried and test, many bugs fixed, oodles of information on line etc. It will take years for EIGRP to catch up (if it isn't too late already!).

As Cisco continues to lose market share, and as folks demand more and more to leverage open standards... EIGRP is going to die.  That's my prediction... agree to disagree.