Ask the Expert- EIGRP Unveiled

[Cisco Moderador]

This topic is a chance to discuss more about Enhanced Interior Gateway Routing Protocol (EIGRP) fundamentals. The session seeks to clarify the status and fundamentals of the EIGRP protocol. In addition, the experts will discuss the common steps used to troubleshoot operations and common issues with EIGRP.

To participate in this event, please use thebutton below to ask your questions

Ask questions from Thursday February 28th to Friday 8th of March, 2019

Featured Speakers

Peter Palúch is a Customer Support Engineer in the EMEA High-Touch Support CX team with a focus on Data Center Switching technologies. In his free time he indulges in all technologies, particularly routing protocols, routed technologies, and MPLS-based services. Before Peter joined Cisco, he worked as a university professor and a Networking Academy instructor and instructor trainer. Peter is an author of the Cisco Press title “CCIE Routing & Switching v5.0 Official Certification Guide, Volume 1”. He holds a CCIE certification on R&S #23527.

Peter has been an active member of the Cisco Community and earned the Cisco Designated VIP award for five years in a row (2011-2016). This year he was recognized as a member of the elite Cisco Community Hall of Fame Program.

David Samuel Peñaloza Seijas works as a Senior Network Consulting Engineer at Verizon Enterprise Solutions in the Czech Republic. Previously, he worked as a Network Support Specialist in the IBM Client Innovation Center in the Czech Republic. David is an expert interested in all topics related to networks. However, he focuses mainly on data centers, enterprise networks, and network design, including software-defined networking (SDN). David has a long relationship with Cisco. He has been a Cisco Instructor for the Cisco Academy and was recognized as a Cisco Champion and a Cisco Designated VIP for 2017, 2018 and 2019. David holds a CCNP R&S, CCDP, CCNA Security, CCNA CyberOps and a CCNA SP certification.

Peter and David might not be able to answer each question due to the volume expected during this event. Remember that you can continue the conversation on the Networking community.

Find other events https://community.cisco.com/t5/custom/page/page-id/Events?categoryId=technology-support  

**Helpful votes Encourage Participation! **
Please be sure to rate the Answers to Questions

[Deepak Kumar]

Hi,

I am using EIGRP MD5 authentication on two routers with the same key-string but with different key IDs. As per documents, it is not mandatory to match the Key-ID number but As per lab testing, it is getting failed.

Here is the lab output:

https://learningnetwork.cisco.com/message/715213#715213

The lab is tested with RIP and EIGRP. Looking expert opinion on the same

Regards,

Deepak Kumar

[Peter Paluch]

Hello Deepak,

Thank you for your question!

If you are using MD5 or SHA-256 authentication, both the key number and the key string must match between the routers. If any documents state otherwise, they are likely incorrect - can you link them here? I would like to have a look.

As you know, a key chain can hold multiple keys, each having a unique key number. This means that an outgoing EIGRP packet can be signed using multiple keys, and an incoming EIGRP packet can be verified against multiple keys - but there has to be a way to uniquely select a particular key to sign a packet, and verify it. So, this is what happens:

When sending packets, EIGRP will pick the first valid key (a key with the lowest key number whose send-lifetime has not expired yet) and authenticate the packet contents. The key number will also be included in the packet. The receiving router will use this key number to select the proper key in the key chain to verify the signature of the packet. Clearly, if the key numbers do not match between routers, the receiving router will be unable to find the correct key to verify the received packet, or will use a different key than intended.

Please feel welcome to ask further!

Best regards,
Peter

[Deepak Kumar]

Hi,

This the example:

https://www.cisco.com/c/en/us/support/docs/ip/routing-information-protocol-rip/13719-50.html

key chain kal
!--- Name a key chain. A key chain may contain more than one key for added security. !--- It need not be identical on the remote router.
key 1
!--- This is the Identification number of an authentication key on a key chain. !--- It need not be identical on the remote router. 
key-string 234
!--- The actual password or key-string. !--- It needs to be identical to the key-string on the remote router. 
!

Regards,

Deepak Kumar

[Deepak Kumar]

Hi @Peter Paluch 

Sorry, This was my misunderstanding about this document. I missed the word "Plain Text Authentication" in the article. Now I went through this link (this is my 5th time, Bad luck) and found missing line. Above statement is only valid with Plain text authentication. 

I am really sorry for this miss understanding.

Regards,

Deepak Kumar

[Peter Paluch]

Hi Deepak,

No apologies needed whatsoever!

Yes, indeed - for plaintext authentication, protocols typically don't include the key number in the authenticated packets. This is, however, entirely up to how the authentication mechanism has been implemented for the protocol, and different protocols may differ in their behavior.

For EIGRP, this does not really apply since EIGRP does not support plaintext authentication. For EIGRP, key numbers must always match as well as key strings.

Thank you for joining, and please keep the questions coming! ;)

Best regards,
Peter

[PetFro]

Hello Peter.

You mentioned that TxLoad and reliability are being added into the composite metric (if enabled through K values), when the route is advertised (snapshot when we are advertising the route). The route is not being advertised when those 2 metric components are changed over time (not causing triggered update, when changed). How they can cause the network unstability then? Can you please explain this further?
Many thanks!

BR

Peter F.

[David Samuel Penaloza Seijas]

Hello Peter, I will try to expand this further.

The main idea behind taking the values only when the route is advertised and not take them dynamically is the stability, as already mentioned. But why? If EIGRP would read dynamically those values, the changes in the topology would be too constant and would make it unstable.

Lets take load as an example: The load on a link is a variable value that changes according to the usage.

Please, consider the topology in the image attached. Assume EIGRP would be reading the values dynamically for this example

Router A has 2 paths to D. The A-B link and the A-C link, both having 10Mb of bandwidth. If the primary path to D is the link between A and C and it would bear a high load (assume a high usage of the bandwidth), then it would be advertised and EIGRP would switch it to the link between A and B. But what would happen if now the A-B link also gets loaded?

Then it would switch again to A-C, because A-C link is not loaded. And then it would switch back quickly to A-B again for the same reason, and this pendulum would be moving back and forth as utilization in the links changes over time. 

It would depend on the traffic volume and how fast the traffic would be bouncing between those links.

The churn in the values and their consequences, which in this case would be instability, are reason to not read these values dynamically.

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

EDIT: Came back to complement the answer:

The route is not being advertised when those 2 metric components are changed over time (not causing triggered update, when changed). How they can cause the network unstability then?

No, they would not cause instability if only taken as snapshots. They are for the most part, useless in that regard. Those metrics were kept as a backwards compatibility mechanism for redistribution to work between IGRP and EIGRP.

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

Hope that helps. Please don't hesitate to ask of anything else can be clarified.

Thanks!

[PetFro]

Hello David.

Thank you for the explanation, it makes sense now :)

Peter F.

[David Samuel Penaloza Seijas]

Hello Peter

Fantastic! I'm glad it was helpful :)

Please, don't hesitate on posting more questions, keep 'em coming! :D 

Thanks!

[Alan Ng'ethe]

In the output of show ip eigrp as# neighbors what does the first column represent? In particular, what does the letter 'H' represent?

[Peter Paluch]

Hi Alan,

Thank you for joining us!

The H stands for Handle. A handle is an internal ID referring to a particular EIGRP neighbor in a protocol-independent way - instead of the software code referring to a neighbor by its address (which would be different for IPv4, IPv6, IPX, or AppleTalk EIGRP used to support), EIGRP instead assigns the particular neighbor a simple, address-family-independent number, and refers to the neighbor through this number. The handle is a value entirely local to the router, and is not advertised in any EIGRP packets.

For all practical purposes, the H column simply enumerates the neighbors in the ascending order in which they have been discovered, starting from 0 upwards.

Please feel welcome to ask further!

Best regards,
Peter

[Alan Ng'ethe]

Thank you. When i was doing my CCNA course work many, many moons ago, this was one of the few unexplained and perhaps undocumented details about EIGRP, and one for which my trainer Jeremy challenged us to find an answer. Better late than never I guess.