North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Re: Comments or suggestions required Internap FCP 500 vs. OER
- From: Matt Buford
- Date: Thu Nov 10 19:28:10 2005
In general, it doesn't do anything (much) for this sort of thing. It does
have a "blackhole detection" feature, but keep in mind how this thing works.
You set a prefix length (which must be equal or more specific than what you
expect to see in BGP, so we use /24 which I believe is the default). It
then takes the top N prefixes (I believe N equals your model number -
FCP5000 monitors your top 5000 /24's). First, it uses passive traffic
sniffing to collect latency and packetloss statistics. Second, it uses
policy routed traceroutes to determine how good things will be if it were to
change the route to another one of your transit links. Finally, if it
determines a change is needed, it injects a /24 route (using localpref to
override anything you might already have) to send that /24 to the new
transit link. You set a max number of advertised routes (say 15000) and it
uses LIFO expiration.
Can you expand a bit on how it dealt with the Level3 meltdown last
So, even with blackhole detection, you're only even potentially "fixing" the
issue for the top 5,000 traffic destination /24s. On future runs you can be
sure a blackholed destination isn't going to be a top destination so you
won't detect any more.
So, does it help? Marketing will tell you yes. In the real world, that
works out to only a little bit of help. A few customers might be helped,
but if someone tried to tell you it will route (everything) around a
blackhole that is absolutely not what it is doing. Only a handful of /24s
are lucky enough to be helped.
I can't guarantee every detail of how I said it operates is exactly right.
This is just how it seems to be behaving based on what I've seen.