i Have R1 CONNECTED TO R2.EIGRP 2 Runs BETWEEN These 2 routers.but the routes r unstable from R2.I Receive K-Value Mismatch.how can i find out the VALue on r2.btw i dont have access to R2.How to fix this problem fom my side?
pls post a link likes this issues
Actually it is most likely not an issue with the K values on R2 (which are most likely set to default values) but is an issue of mismatched versions of IOS between R2 and R1. In more recent versions of IOS (which is probably running on R2) if EIGRP is going to tear down the neighbor relationship (missed hello messages are a frequent cause) it will send a "goodby" message to its neighbor. And in the goodby message the K values are set to 255. If the neighbor receives the goodby message but is running older code (which is probably the case on R1) then it generates an error message about mismatched K value.
The easy solution is to get compatible versions of code on each neighbor (either they both understand the goodby message or neither understands the goodby message). The better long term solution is to figure why the neighbor is dropping the EIGRP neighbor session.
as I Mentioned on my POST.i dont have access to ther neighbors Routers..But on otherer side they add the command i think weigh metric under the eigrp procees.wich debug its powerfull to get the valus(TOS) aDDES THERE.BTY I HAVE USED ALL DEBUGS RELEATED TO EIGRP
if the interface is a LAN interface you can think to insert a switch configure SPAN and have packets replicated to a sniffer.
otherwise you can try to change the weights on your side
router eigrp ASN
metric weights tos k1 k2 k3 k4 k5
default values are:
1 0 1 0 0
The command defaults to a setting of 0 1 0 1 0 0,
meaning that only bandwidth and delay are used to calculate the metric. (The examples in this
chapter usually use the settings 0 0 0 1 0 0, which removes bandwidth from the calculation and
makes the metrics in the examples a little more obvious.)
you could try to use a brute force attack using all 32 values using 1 or 0 for each weight.
but the k values can be set to values bigger then 1 so this approach is not viable.
Actually, I think you are right I didn't found an example of an eigrp debug that shows this info
I was looking at the debug command reference
try to use
debug eigrp packet hello verbose
it should provide more info on the packets notice the missing ip keyword.
Hope to help
In your original post you described the problem as the routers being unstable. That implies that they form a neighbor relationship and process successfully for a while and then break the neighbor relationship. Is that correct?
If there really were a mismatch in K values and it would need change in the K values on your side then the routers would not form a neighbor relationship at all.
If you are really concerned about this issue then I suggest that you plan to upgrade the code on your router to a more recent version. I believe that this will resolve your issue.
Is there any kind of work around? Right now upgrading the IOS isn't an option. Im running a 3745 thats eight years old and a 3845 thats running an IOS thats a year old.
As I suggested to Ali there are 2 parts to this issue:
1) mismatch in versions leads to different behaviors about the Goodby message
2) something is causing the router with the newer code to drop the neighbor relationship.
I do not believe that there is any workaround for 1) other than code upgrade/downgrade.
If you can address the issue that is causing the neighbor relationship to drop then it is a workaround for 2)