Re: How does one make not playing nice with each other scale? (Was: net.terrorism)
marcel@our.domaintje.com (Anne Marcel) writes:
There is no need to deaggregate the /16 that contain nullrouted /32's. This information is (in this case) already available from AS7777 as a multihop eBGP feed.
Nope. No part of ORBS is listed in AS7777. The block which inspired this thread is completely private to AS6461 and has to do with that network's AUG.
Ah... In that case they could ask abovenet to leak any nullrouted blocks that are local to abovenet with a community set so they can find another path to dump that traffic. My appologies for assuming that this was was in AS777. - marcel #include <disclaimer.std> On 13 Jan 2001, Paul Vixie wrote:
marcel@our.domaintje.com (Anne Marcel) writes:
There is no need to deaggregate the /16 that contain nullrouted /32's. This information is (in this case) already available from AS7777 as a multihop eBGP feed.
Nope. No part of ORBS is listed in AS7777. The block which inspired this thread is completely private to AS6461 and has to do with that network's AUG.
Paul Vixie wrote:
marcel@our.domaintje.com (Anne Marcel) writes:
There is no need to deaggregate the /16 that contain nullrouted /32's. This information is (in this case) already available from AS7777 as a multihop eBGP feed.
Nope. No part of ORBS is listed in AS7777. The block which inspired this thread is completely private to AS6461 and has to do with that network's AUG.
This sort of brings up an interesting point, though. Has anyone ever thought about adding a mechanism to BGP for advertising "anti-routes?" - routes that you can't, don't want to, or won't carry traffic for? In this case, such a capability could be used to redistribute the 194.178.0.0/16 route from UUNet, and add in a route for !194.178.232.55/32, all without messy deaggregation. Neighbors would have the option of using this as a type of automated blackhole avoidance. There are a few things that would stand in the way of adoption of something like this: first, each anti-route would require manual configuration, and that comes with its own set of problems. Another potential issue (this is purely theoretical, I'm not referring to any past, present, or future situation in particular) is that providers trying to blackhole a certain site for AUP violations may want to negatively impact reachability as much as possible, rather than purely keeping the offending traffic off their network. These folks wouldn't want to advertise anti-routes because the resulting blackhole avoidance would encourage others to take working alternate paths, which does less harm to the site in question. Still, this may be a beneficial, even if little-used, addition. Thoughts? Mark
[ On Saturday, January 13, 2001 at 13:25:39 ( -0500), Mark Mentovai wrote: ]
Subject: Re: How does one make not playing nice with each other scale? (Was: net.terrorism)
Another potential issue (this is purely theoretical, I'm not referring to any past, present, or future situation in particular) is that providers trying to blackhole a certain site for AUP violations may want to negatively impact reachability as much as possible, rather than purely keeping the offending traffic off their network. These folks wouldn't want to advertise anti-routes because the resulting blackhole avoidance would encourage others to take working alternate paths, which does less harm to the site in question.
Ah ha! Now I think you've put your finger on the *real* problem! :-)
Still, this may be a beneficial, even if little-used, addition. Thoughts?
Well if these "anti-routes" really do have to be manually configured then it's still not really scalable. If their advertisement in the routing protocols could somehow be automated and hard to disable then maybe they'd obviously be of some use. If the people using such "hidden" null routes are attributing their invisibility to the fact that de-aggregating the block they are within is difficult and/or bad then clearly an "anti-route" advertisement mechanism would be a potential solution to that problem. Whether it makes life any easier on either side of the fence is the question, and no doubt part of the answer depends on whether or not the users of "hidden" null routes (or other forms of transit packet filtering) are in fact willing to advertise (in a routing protocol sense) what they're really doing so that their peers (in a networking sense) can make better decisions about what to do with their traffic. Clearly a "hidden" null route (or even a real packet filter dropping packets for some subnet) does violate the advertisement of the larger aggregate route, and from what I've seen there are lots of people who are "surprised" (to say the least) to learn that they can't get packets to these null-routed networks via an encompassing route advertised by one of their upstreams. Packets is packets boyz and goilz, and if you're advertising transit across your borders but not actually providing it then you're most definitely not a very good network neighbour. I.e. policy based routing should be either outlawed for transit providers, or required to be clearly advertised in such a way that network peers can automate their routing decisions based on real-time policy changes within their peer's networks (but perhaps that's another non-operational discussion! :-). -- Greg A. Woods +1 416 218-0098 VE3TCP <gwoods@acm.org> <robohack!woods> Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>
Greg A. Woods wrote:
Well if these "anti-routes" really do have to be manually configured then it's still not really scalable. If their advertisement in the routing protocols could somehow be automated and hard to disable then maybe they'd obviously be of some use.
Perhaps "redistribute null" or "redistribute blackhole" (or insert your vendor's equivalent here) could be used to redistribute static null routes as anti-routes. Provided that the violators are being filtered by null routes as opposed to access lists, this could be made to work.
Clearly a "hidden" null route (or even a real packet filter dropping packets for some subnet) does violate the advertisement of the larger aggregate route, and from what I've seen there are lots of people who are "surprised" (to say the least) to learn that they can't get packets to these null-routed networks via an encompassing route advertised by one of their upstreams. Packets is packets boyz and goilz, and if you're advertising transit across your borders but not actually providing it then you're most definitely not a very good network neighbour. I.e. policy based routing should be either outlawed for transit providers, or required to be clearly advertised in such a way that network peers can automate their routing decisions based on real-time policy changes within their peer's networks (but perhaps that's another non-operational discussion! :-).
Trying to keep the politics aside as much as possible, it's conceivable that "not advertising anti-routes for traffic you plan to drop while continuing to advertise routes for the parent network" could in the future come to be seen as bad as "blackholing by advertising (potentially more specific) routes you aren't entitled to advertise" is today. In other words, if an accepted anti-route capability existed, there would no longer be any excuse for effective (as opposed to explicit) blackholing. Mark
On Sat, 13 Jan 2001, Mark Mentovai wrote:
Paul Vixie wrote:
Nope. No part of ORBS is listed in AS7777. The block which inspired this thread is completely private to AS6461 and has to do with that network's AUG.
This sort of brings up an interesting point, though. Has anyone ever thought about adding a mechanism to BGP for advertising "anti-routes?"
Look at: http://www.ietf.org/internet-drafts/draft-chen-bgp-route-filter-01.txt however this functionality was not incorporated into the very recent http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-12.txt Note that you still can't reach the nullroutes in this case if you have the path 6461 702$, so this (or the alternative suggested, community-tagging a nullroute feed for munging localprefs) would have to be deployed amongst every above peer - with their cooperation - to avoid asymmetric peculiarities. Quite a lot of work just to allow orbs to probe you :) although the generic case as addressed in the route-filter draft is quite interesting. joshua
participants (5)
-
Anne Marcel -
Joshua Goodall -
Mark Mentovai -
Paul Vixie -
woods＠weird.com