|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Comments or suggestions required Internap FCP 500 vs. OER
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 month? 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.
|