EIGRP K -value mismatch issue

Unanswered Question
Mar 6th, 2008

Hi ,

Can any one tell me what is this K- value mismatch issue. IS it occurs due to the packet loss and Hold down time increases.

Appreciate fast response.

Thanks,

Akber.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (3 ratings)
Nagendra Kumar ... Thu, 03/06/2008 - 22:04

Hi,

When a routers receives a EIGRP hello packet, it will check few parameters before establishing neighborship with tht neighbor. One of the few parameter is K-value. This should match between the routers inorder to establish the neighborship.

Check the routing protocol config and see if the "metric weight" command is configured with same value in both the routers.

Alternatively, you can also check the K value using the below command,

"sh ip protocols | inc K"

HTH,

Nagendra

mirzaakberali Thu, 03/06/2008 - 22:43

hi Nag,

Thanks for the input!

Does this K-Value changes because of any link Flap ?

Thanks,

Akber.

Nagendra Kumar ... Thu, 03/06/2008 - 23:11

Hi Akber,

No. Link flap will not change the K-Value.

HTH,

Nagendra

Richard Burts Sat, 03/08/2008 - 10:51

Nagendra (and Akber)

I believe that there is an explanation for what Akber is asking about and it does involve link flapping. It may occur when there is a version of IOS mismatch between the neighbors.

Cisco introduced a new feature in IOS for EIGRP providing for "goodby" messages to be sent when the EIGRP process was about to tear down the neighbor realtionship (including because of link flaps). In the goodby message EIGRP sets all the K values to maximum value. When one neighbor does have the goodby message feature and the other neighbor does not have this feature then the one neighbor sends the goodby message and the other neighbor receives a message that it does not recognize and has all the K values set to max value and it generates the message about K value mismatch.

Akber this message does not indicate any real problem and would be resolved if you get both neighbors to run the same version of IOS.

HTH

Rick

zoltron30 Fri, 02/25/2011 - 20:57

hmm very cool answer... i was just going this in one jeremy cioara's old bsci video's.... interesting indeed

Richard Burts Sat, 02/26/2011 - 12:48

Ian

I am always glad when someone finds one of my older responses and finds it still useful. Thanks for reminding us of this issue and for the feedback that you found it interesting.

HTH

Rick

esundberg Fri, 10/10/2014 - 05:57

Had the Same Issue

R1 - Cisco 12K - 12.0(33)S9

R2 - Cisco 7301 - 15.0(1)M10

R1 – Log
Oct 10 07:31:28.657 CDT: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1234: Neighbor 2.2.2.1 (GigabitEthernet1/1/8.466) is up: new adjacency
Oct 10 07:32:46.037 CDT: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1234: Neighbor 2.2.2.1 (GigabitEthernet1/1/8.466) is down: K-value mismatch
Oct 10 07:32:47.269 CDT: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1234: Neighbor 2.2.2.1 (GigabitEthernet1/1/8.466) is up: new adjacency
Oct 10 07:33:47.314 CDT: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1234: Neighbor 2.2.2.1 (GigabitEthernet1/1/8.466) is down: K-value mismatch
Oct 10 07:33:47.738 CDT: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1234: Neighbor 2.2.2.1 (GigabitEthernet1/1/8.466) is up: new adjacency

R2- Log
Oct 10 07:32:46.044 CDT: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1234: Neighbor 2.2.2.2 (GigabitEthernet0/0) is down: retry limit exceeded
Oct 10 07:32:47.268 CDT: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1234: Neighbor 2.2.2.2 (GigabitEthernet0/0) is up: new adjacency
Oct 10 07:33:47.264 CDT: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1234: Neighbor 2.2.2.2 (GigabitEthernet0/0) is down: retry limit exceeded
Oct 10 07:33:47.668 CDT: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1234: Neighbor 2.2.2.2 (GigabitEthernet0/0) is up: new adjacency

 

The K-Values on both routers were the same when i did a show ip protocols, but noticed the MTU was different.

 

Resolved by specifying the ip mtu on the interfaces of the Circuit between the router
R1(config)#int g1/1/8.466
R1(config-subif)#ip mtu 1500

R1 - Interface MTU was 1500


R2(config)#int g0/0
R2(config-if)#ip mtu 1500

R2 - Interface MTU was 9216

Richard Burts Fri, 10/10/2014 - 06:09

Thanks for adding something to this old thread. I believe that there is an explanation for this behavior. It looks like the routers send hello messages and initially form a neighbor relationship. But then based on MTU issue R2 decides to terminate the neighbor relationship. R2 with newer code sends the EIGRP goodbye message, which changes the K values. R1 receives the goodbye message but because of its older code does not recognize it and reacts to the changed K values.

 

HTH

 

Rick

Actions

Login or Register to take actions

This Discussion

Posted March 6, 2008 at 9:49 PM
Stats:
Replies:8 Overall Rating:5
Views:9280 Votes:0
Shares:0
Tags: No tags.