Re: Juniper failes to change keys (More MD5 fun: Cisco uses wrong MD5key for old session after key change)

[sthaug () nethelp no]

> > 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, sthaug () nethelp no