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

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..