nanog mailing list archives
Re: 64 Megs of Memory...
From: Josh Richards <jrichard () cubicle net>
Date: Mon, 23 Oct 2000 11:42:18 -0700
* goemon () sasami anime net <goemon () sasami anime net> [20001022 17:34]:
On Sun, 22 Oct 2000, Mark Milhollan wrote:[Sorry for the delay.] Dan Hollis writes:On Fri, 13 Oct 2000, Mark Milhollan wrote:``maximum-prefix n p warning-only'' along with a log analyzer that recognizes the warning, are perhaps a better pair of friends.How so? You recognize the warning, now what?Deliver the notice to NOC personel, via whatever means. Perhaps they'll terminate the session. Perhaps not. Granted in warning-only mode the session won't come back up by itself.And how exactly is this better than a maximum-prefix clause which drops routes instead of dropping the session?
I'd consider dropping arbitrary routes much worse than just pulling the entire session down...otherwise you end up with unpredictable results (i.e. no idea/control over what prefixes get added or withdrawn which is a bad thing). Prefixes change for a reason and you can presume that if a prefix comes in via BGP you should be able to cleanly find another path to that prefix(es) involved via another peer (alright, not absolutely always, but it's a good idea to make sure you're network is capable of that..) so pulling down that session is more deterministic and continues to yield an accurate routing picture rather than an arbitrary and (likely) wrong one due to only partial routes processed from an out of control peer.
With your proposal, by the time the warning has been tripped and the notice delivered to the NOC the routes have probably already gone over the limit and the cisco already dropped the BGP session.
That would depend on the cause of the surge in routes, but, yeah, there's a good chance that's what would happen. Bringing the session down entirely and a method of NOC notification (via syslog or SNMP) seems reasonable to me. Then someone can investigate the anomaly before you start trusting routes from that peer again. -jr ---- Josh Richards [JTR38/JR539-ARIN] <jrichard () geekresearch com/cubicle.net/fix.net/freedom.gen.ca.us> Geek Research LLC - <URL:http://www.geekresearch.com/> IP Network Engineering and Consulting
Current thread:
- Re: 64 Megs of Memory... Mark Milhollan - Franklin Employee (Oct 13)
- <Possible follow-ups>
- Re: 64 Megs of Memory... Mark Milhollan (Oct 22)
- Re: 64 Megs of Memory... goemon (Oct 22)
- Re: 64 Megs of Memory... Josh Richards (Oct 23)
- Re: 64 Megs of Memory... goemon (Oct 22)