Michael,
David Luyer wrote: Have done around 100 of these in the past 24 hours. It's not related to platform AFAIK - we've successfully done the changes on a lowly 2651 and 3620 without outages, but a 7200 with older IOS did have an outage.
Given the context, I assume that you have added MD5 to sessions that did not have it previously, I am correct? Then, do you mean by "without outages" that the session was not reset by the password add/change? If I may ask, how many out of 100 did not reset?
98 of the first 100 did not reset. Today, I did another 12 and only one failed. The 2 to fail were one with 12.2(17a) and 12.2(23) where we got the timing a couple of seconds off -- not sure if the reason was IOS or timing -- and one with a 12.0S release where the reset is automatic. Testing also revealed that 12.1 had an automatic reset, just we didn't run into it in production. The one which failed today was another case of 12.0S. However some providers run 12.0S exclusively so I'd expect they'd see every single session reset. And when it comes to Juniper/Foundry/Extreme, I haven't set up passwords on any of the sessions to these vendors yet. The important thing is the IOS - as I stated earlier, it's easy to test in a lab and see if the router syslogs a reset on putting in a password, if it doesn't syslog one then you have a very strong chance it won't reset, but if it's a critical BGP session it would still be sensible to do it in an off-peak window (which happens to be why I haven't done any of the BGP sessions to peers using Juniper/Foundry/Extreme yet). If you have a fully redundant internal BGP, and are running all 12.2S/12.3/12.2T, then you can rather safely do the internal BGP passwords without a customer notice, expecting no session drop but knowing if one did you'd have routes via a second BGP reflector anyway. One note - when you do this, the table version shown in 'show ip bgp sum' resets to zero in some IOS versions. This appears cosmetic; routing is not impacted and this can also occur when simply putting a description against a BGP peer. David.