Re: Juniper failes to change keys (More MD5 fun: Cisco uses wrongMD5key for old session after key change)
We've experienced this as well, between old versions of IOS without the new feature Sean describes, and newer versions with the new feature.
Between two versions of IOS, we were successful at making this change if we changed both MD5 passwords at the same time:
So if you do this:
a) Configure password in Router A b) Wait till the first keepalive c) Configure password in Router B (at this time getting error message) d) After two keepalives (total three keepalive) the bgp goes down and comes up automatically e) The error messages still seen for 5 minutes
However, if you skip steps b and c, and immediately configure the far end with the new password, there are no flaps, and should be no logs.
Please let me know if this works for you.
It certainly doesn't work between Cisco and Juniper, because the Juniper always resets the session when you configure a new MD5 key. After some more lab testing I have concluded that the key (pardon the pun) to make this work between Cisco and Juniper, and not get a lot of log messages about invalid keys, is to get an orderly termination of the old BGP session. I found two ways to make sure that happens: 1. Configure (and commit) the new key on the Juniper side first. This leads to an orderly termination of the existing BGP session, and then the new key can also be configured on the Cisco side. 2. Do an explicit reset of the BGP session on the Cisco side (which again gives you an orderly termination of the existing BGP session), and then configure the new key on both routers (here it doesn't matter which router gets the new key first). It would Really Nice (tm) if this was documented in the manuals. But to reiterate the original point - if a new key is configured on the Cisco side first, without resetting the existing BGP session, Cisco and Juniper will disagree about the key used to terminate the existing BGP session, with lots of confusing log messages as a result. Now that i understand what's happening, I agree that it would be good for Juniper to implement key change without BGP session reset too - but until that happens, the current situation is rather confusing (how is the user supposed to guess that the "invalid key" messages refer to the old BGP session?). Steinar Haug, Nethelp consulting, sthaug@nethelp.no
On Sun, 2004-04-25 at 04:46, sthaug@nethelp.no wrote:
It certainly doesn't work between Cisco and Juniper, because the Juniper always resets the session when you configure a new MD5 key.
Ah, that explains way I flapped sessions that were juniper/cisco and not ones that were cisco/cisco when setting the key. It looked like this in the logs, this is on a session that did not have a key, previous. Ouch !: Apr 22 14:45:51.105 MDT: %TCP-6-BADAUTH: No MD5 digest from xxx.xxx.xxx.205(1156) to xxx.xxx.xxx.206(179) Apr 22 14:45:51.145 MDT: %TCP-6-BADAUTH: No MD5 digest from xxx.xxx.xxx.205(1156) to xxx.xxx.xxx.206(179) Apr 22 14:45:52.105 MDT: %TCP-6-BADAUTH: No MD5 digest from xxx.xxx.xxx.205(1156) to xxx.xxx.xxx.206(179) Apr 22 14:45:52.917 MDT: %SYS-5-CONFIG_I: Configured from console by vty0 (xxx.xxx.5.205) Apr 22 14:45:54.105 MDT: %TCP-6-BADAUTH: No MD5 digest from xxx.xxx.xxx.205(1156) to xxx.xxx.xxx.206(179) Apr 22 14:45:58.113 MDT: %TCP-6-BADAUTH: No MD5 digest from xxx.xxx.xxx.205(1156) to xxx.xxx.xxx.206(179) Apr 22 14:46:06.105 MDT: %TCP-6-BADAUTH: No MD5 digest from xxx.xxx.xxx.205(1156) to xxx.xxx.xxx.206(179) Apr 22 14:46:22.106 MDT: %TCP-6-BADAUTH: No MD5 digest from xxx.xxx.xxx.205(1156) to xxx.xxx.xxx.206(179) Apr 22 14:46:54.106 MDT: %TCP-6-BADAUTH: No MD5 digest from xxx.xxx.xxx.205(1156) to xxx.xxx.xxx.206(179) Apr 22 14:47:20.295 MDT: %BGP-5-ADJCHANGE: neighbor xxx.xxx.xxx.205 Down BGP Notification sent Apr 22 14:47:20.295 MDT: %BGP-3-NOTIFICATION: sent to neighbor xxx.xxx.xxx.205 4/0 (hold time expired) 0 bytes Apr 22 14:47:39.083 MDT: %BGP-5-ADJCHANGE: neighbor xxx.xxx.xxx.205 Up Apr 22 14:47:58.183 MDT: %TCP-6-BADAUTH: No MD5 digest from xxx.xxx.xxx.205(1156) to xxx.xxx.xxx.206(179) Apr 22 14:49:02.121 MDT: %TCP-6-BADAUTH: No MD5 digest from xxx.xxx.xxx.205(1156) to xxx.xxx.xxx.206(179) Apr 22 14:50:06.113 MDT: %TCP-6-BADAUTH: No MD5 digest from xxx.xxx.xxx.205(1156) to xxx.xxx.xxx.206(179) Apr 22 14:51:10.117 MDT: %TCP-6-BADAUTH: No MD5 digest from xxx.xxx.xxx.205(1156) to xxx.xxx.xxx.206(179) Apr 22 14:52:14.135 MDT: %TCP-6-BADAUTH: No MD5 digest from xxx.xxx.xxx.205(1156) to xxx.xxx.xxx.206(179) Apr 22 14:53:18.125 MDT: %TCP-6-BADAUTH: No MD5 digest from xxx.xxx.xxx.205(1156) to xxx.xxx.xxx.206(179) I am assuming the log entries about BADAUTH after the session came up were the effect of log buffering ?
Aha! An answer to what I saw when configuring a client's box! In my case, the messages stopped after about 10 minutes and everything settled down but it was qute confusing.. On Sun, Apr 25, 2004 at 11:52:45AM -0600, James Edwards wrote:
On Sun, 2004-04-25 at 04:46, sthaug@nethelp.no wrote:
It certainly doesn't work between Cisco and Juniper, because the Juniper always resets the session when you configure a new MD5 key.
Ah, that explains way I flapped sessions that were juniper/cisco and not ones that were cisco/cisco when setting the key. It looked like this in the logs, this is on a session that did not have a key, previous. Ouch !:
Apr 22 14:45:51.105 MDT: %TCP-6-BADAUTH: No MD5 digest from xxx.xxx.xxx.205(1156) to xxx.xxx.xxx.206(179) Apr 22 14:45:51.145 MDT: %TCP-6-BADAUTH: No MD5 digest from xxx.xxx.xxx.205(1156) to xxx.xxx.xxx.206(179) Apr 22 14:45:52.105 MDT: %TCP-6-BADAUTH: No MD5 digest from xxx.xxx.xxx.205(1156) to xxx.xxx.xxx.206(179) Apr 22 14:45:52.917 MDT: %SYS-5-CONFIG_I: Configured from console by vty0 (xxx.xxx.5.205) Apr 22 14:45:54.105 MDT: %TCP-6-BADAUTH: No MD5 digest from xxx.xxx.xxx.205(1156) to xxx.xxx.xxx.206(179) Apr 22 14:45:58.113 MDT: %TCP-6-BADAUTH: No MD5 digest from xxx.xxx.xxx.205(1156) to xxx.xxx.xxx.206(179) Apr 22 14:46:06.105 MDT: %TCP-6-BADAUTH: No MD5 digest from xxx.xxx.xxx.205(1156) to xxx.xxx.xxx.206(179) Apr 22 14:46:22.106 MDT: %TCP-6-BADAUTH: No MD5 digest from xxx.xxx.xxx.205(1156) to xxx.xxx.xxx.206(179) Apr 22 14:46:54.106 MDT: %TCP-6-BADAUTH: No MD5 digest from xxx.xxx.xxx.205(1156) to xxx.xxx.xxx.206(179) Apr 22 14:47:20.295 MDT: %BGP-5-ADJCHANGE: neighbor xxx.xxx.xxx.205 Down BGP Notification sent Apr 22 14:47:20.295 MDT: %BGP-3-NOTIFICATION: sent to neighbor xxx.xxx.xxx.205 4/0 (hold time expired) 0 bytes Apr 22 14:47:39.083 MDT: %BGP-5-ADJCHANGE: neighbor xxx.xxx.xxx.205 Up Apr 22 14:47:58.183 MDT: %TCP-6-BADAUTH: No MD5 digest from xxx.xxx.xxx.205(1156) to xxx.xxx.xxx.206(179) Apr 22 14:49:02.121 MDT: %TCP-6-BADAUTH: No MD5 digest from xxx.xxx.xxx.205(1156) to xxx.xxx.xxx.206(179) Apr 22 14:50:06.113 MDT: %TCP-6-BADAUTH: No MD5 digest from xxx.xxx.xxx.205(1156) to xxx.xxx.xxx.206(179) Apr 22 14:51:10.117 MDT: %TCP-6-BADAUTH: No MD5 digest from xxx.xxx.xxx.205(1156) to xxx.xxx.xxx.206(179) Apr 22 14:52:14.135 MDT: %TCP-6-BADAUTH: No MD5 digest from xxx.xxx.xxx.205(1156) to xxx.xxx.xxx.206(179) Apr 22 14:53:18.125 MDT: %TCP-6-BADAUTH: No MD5 digest from xxx.xxx.xxx.205(1156) to xxx.xxx.xxx.206(179)
I am assuming the log entries about BADAUTH after the session came up were the effect of log buffering ?
--- Wayne Bouchard web@typo.org Network Dude http://www.typo.org/~web/
participants (3)
-
James Edwards -
sthaug＠nethelp.no -
Wayne E. Bouchard