blog
    What? You won't tell me t ...
    20 November 09

    What? You won't tell me the K values? No problem.

    Posted byINE
    facebooktwitterlinkedin
    news-featured

    Every once in a while I come across a tip that is so exciting I want to share it with the world. I was recently going through one of the many posts I read, and saw the answer to a question that I have been wondering about for many years. Awesome job to Steve Shaw who came up with this. Here is the scenario. We are running EIGRP, and have a neighbor, but no console access to that neighbor. We get the message on our local router saying “%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor A.B.C.D (Fa0/1) is down: K-value mismatch”.

    Now for the tricky part. There are 5 K values, each K value supporting a value between 0-255 inclusive.  It would take a long time to test all of the possible values of K1-K5 until we “crack the code” and get the right values.

    Here is a solution to discover which K values are in use on the remote neighbor. Locally, create an access-list to match on EIGRP updates:

    access-list 100 permit ip host 136.1.45.4 host 224.0.0.10

    Be sure to pick a free ACL #. For the source address, use the IP address of the neighbor.

    Then use the following debug command:

    debug ip packet 100 detail dump

    Context sensitive help may not show the "dump" keyword as an option at the end, but it is most likely still available.  Make sure to log to a location where the output of the debug may be seen, such as the buffer, console or a syslog server.

    If our neighbor has K values of:
    EIGRP metric weight K1=1, K2=1, K3=1, K4=1, K5=1
    On our local router we would should see the debug output similar to this:

    01:04:28: IP: s=136.1.45.4 (FastEthernet0/1), d=224.0.0.10, len 60, rcvd 2, proto=88
    0F4019C0: 0100 5E00000A ..^...
    0F4019D0: 00444444 44440800 45C0003C 00000000 .DDDDD..E@.<....
    0F4019E0: 0158239B 88012D04 E000000A 0205EDC9 .X#...-.`.....mI
    0F4019F0: 00000000 00000000 00000000 00000001 ................
    0F401A00: 0001000C 01010101 0100000F 00040008 ................
    0F401A10: 0C040102 ....

    The 16th byte from the end (or the 4th grouping from the end), is where the K values begin. The K values are in bold. There is one byte per K value, represented in the output as 2 hex characters.

    If our neighbor has K values as:
    EIGRP metric weight K1=1, K2=1, K3=0, K4=0, K5=0
    Our output from the debug would resemble the output below.

    01:04:28: IP: s=136.1.45.4 (FastEthernet0/1), d=224.0.0.10, len 60, rcvd 2, proto=88
    0F4019C0: 0100 5E00000A ..^...
    0F4019D0: 00444444 44440800 45C0003C 00000000 .DDDDD..E@.<....
    0F4019E0: 0158239B 88012D04 E000000A 0205EDC9 .X#...-.`.....mI
    0F4019F0: 00000000 00000000 00000000 00000001 ................
    0F401A00: 0001000C 01010000 0000000F 00040008 ................
    0F401A10: 0C040102 ....

    The K values are conveniently displayed in order in the debug output. Remember, when you implement K values under the EIGRP routing process using the metric weights command, the first value is the TOS bit, and then the remaining 5 values are the K values in order 1-5.

    One more example is called for, because the K values are not restricted to the values of 0 or 1. What if the remote neighbor had used the following under the EIGRP routing process:
    metric weights 0 225 1 1 1 1
    Then, on the local router, the debug output would look similar to the following:

    01:23:07: IP: s=136.1.45.4 (FastEthernet0/1), d=224.0.0.10, len 60, rcvd 2, proto=88
    0F8000E0: 0100 5E00000A ..^...
    0F8000F0: 00444444 44440800 45C0003C 00000000 .DDDDD..E@.<....
    0F800100: 0158239B 88012D04 E000000A 02050EC9 .X#...-.`......I
    0F800110: 00000000 00000000 00000000 00000001 ................
    0F800120: 0001000C E1010101 0100000F 00040008 ....`...........
    0F800130: 0C040102 ....

    225 in binary is 1110 0001. If we convert 1 nibble at a time to Hexadecimal, it would become E1 as shown in the debug output. We could then set our K values to match the neighbor and form a working adjacency.

    Of course, in an environment where we manage both routers, we could just look at the output of "show ip protocols", or "show run | section router", and solve it immediately, but where is the challenge in that!

    Good luck with your studies.

    If you know of other solutions, please add it as a post, and share it with your peers, (assuming your K-values match your peers ;-).

    Hey! Don’t miss anything - subscribe to our newsletter!

    © 2022 INE. All Rights Reserved. All logos, trademarks and registered trademarks are the property of their respective owners.
    instagram Logofacebook Logotwitter Logolinkedin Logoyoutube Logo