> > After a while I decided to change the MD5 key. The session with the new > > key came up and looked fine, but the old session didn't close properly. > > Notice the close is initiated from the Juniper side, and the first > > packet from the Cisco side is now sent with an invalid MD5 digest - it > > turns out that the packet is actually sent with an MD5 digest based on > > the *new* key: > > This is a feature, and hopefully Juniper will also add the same feature > soon. The feature allows you to change the MD5 key without flapping the > BGP session which is very important on large peering sessions. There is > no requirement that MD5 keys must remain constant throughout an entire TCP > session, or to terminate a TCP session when the key changes. As long as > both sides agree, the key can be changed at any time including in the > middle of a TCP session. New packets after the key change are sent with > message digests based on the new key.
But as long as the session *is* reset anyway, the current situation is extremely confusing - the log messages (on both Cisco and Juniper) give no indication that the invalid key in question is for an *old* BGP session, no longer active! Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]