Christopher / David,
Christopher L. Morrow wrote: if you mean resetting sessions to change keys I believe it's more code dependent than anythingn else.
That was my point: I thought that changing keys without resetting the session was tied to a specific version of the "S" train that I have never seen it on anything lower than a 7200. Anyway, given David Luyer's post, it appears that unless you are willing to accept the risk of an unplanned session reset, you'd better have a planned outage for it.
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?
Christopher L. Morrow wrote: For pure: "Don't blow me up with prefixes" just limit the maximum-prefix to some # over your expected peer's list.
Please allow me to try to make my point again: you store the expected peer maximum-prefix somewhere in your management system. I do understand the added complexity, but in the big scheme of things would it be _that_ more difficult to store a comma-delimited string or something that contains the prefixes that could be announced by that peer instead of the maximum-prefix? Yes, it generates more work to update the database, but OTOH it provides the LIII engineer with a lot more to troubleshoot issues. Is it simply not worth the work at your scale?
- There are cases (such as the peer being a tier-2 customer of UUNET and me being a tier-3 customer of UUNET via a different tier-2) when the routes seen coming from the peer will have the same length AS-PATH than the ones coming from my transit, some other BGP tie-breaking criteria favoring the peer over the transit, leading to disaster.
use a route-map to add/remove metric or localpref? or any other settable thing on your side? or prepend or ....
Based on what criteria? Both the peer and the transit announce the same prefix with the same AS-PATH length. I agree that in many cases, favoring the route coming from the transit provider would work, but what guarantees it? What we are trying to define is the idiot-proof setup for peers; what if the misconfiguration is with the transit?
- In theory, I could add a "route-map blah deny 1" that matches everything, then manipulate the subsequent seqs at will, then remove the "route-map blah deny 1"; in this situation though, I do not see a clear advantage over clearing the session. What am I missing?
you could tftp in your config change, that doesn't cause the problems... then just wait for next update time.
I don't see much of a difference. AFAIK when you tftp a config into the running-config, it is appended to the existing config same as if you pasted the commands into conf t. What happens when the next update time happens in the middle of tftp merging the old route-map with the new one? Michel.