|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical 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, [email protected]
|