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
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, email@example.com