On Tue, 20 Apr 2004, Michel Py wrote:
Christopher / Patrick,
Christopher L. Morrow wrote: I wasn't clear and for that I'm sorry. Except in the later code trains, or until the recent past (1 year or so) changing the BGP MD5 auth bits required the session to be reset.
Then I'm the one sorry because I never got it to work (I have not tried hard, I have to say); I always considered the session reset to be annoyance that was part of life. Dumb question: on what platforms is
its annoying until you drop customer traffic over and over on thousands of bgp sessions... eh? doing this is not nice.
this working? If my memory is correct nothing below the 7200; I have seen numerous cases of peering with platforms such as 3600.
if you mean md5 auth, it works from atleast 2501->12008. if you mean resetting sessions to change keys I believe it's more code dependent than anythingn else.
no, removing a route-map or adding a new one is painful, changing it is just normal, no bounce required.
Maybe I have something to learn here.
- The reason I have a route-map in for a peer's BGP session is that I want to want to shield myself against a misconfigured peer that announces the entire world to me.
caution: there are several ways to do bgp configs, i am comfortable with the way I do it daily (or how I deal with it daily). Route-maps we use to massage routes and add/change/delete communities or the like... or for redist from proto to proto. Not for limiting routes injected, prefix-lists are better/more efficient for that. For pure: "Don't blow me up with prefixes" just limit the maximum-prefix to some # over your expected peer's list.
- 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 ....
- I have equally been burned by filtering using a regexp that accepts only routes that appear to originate from the peer. Looks good on paper but when the peer configures aggregates of their own that leak in their BGP, becomes messy. Also been burned with peers configuring next-hop-self.
as-path filters are nice for bogon asn's not for limiting peer prefixes :(
- I think I have a reasonably good understanding of route-maps; however I have not found so far a mechanism that could guarantee that, when adding/removing seqs from it, there is no transient condition that causes the peer wrongly announcing the entire world to you to get all his crud into my own table.
limit the max prefixes in cisco it's someting akin to: neighbor <neighbor-ip> maximum-prefix 1000
- 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.
wrong program, I was referring to his reset_tcp.c program,
Oh, I see. I thought that you meant that saving the password somewhere was useless, as any side could recover it by decrypting it from the config. My mistake.
that too, but the main thing was: "once you write it down you will start a clock to change time else it's useless"