Re: 64 Megs of Memory...
[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.
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? 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. -Dan
* 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
participants (3)
-
goemon＠sasami.anime.net -
Josh Richards -
Mark Milhollan