For some IETF work in progress related to Source Address Validation (SAV), it is useful to know the purposes for which NO_EXPORT may be attached to routes announced in BGP, especially towards transit providers?
I know it makes sense for an AS to announce an aggregate less-specific prefix to transit providers and peers without NO_EXPORT while announcing some more-specific prefixes (subsumed under the aggregate) with NO_EXPORT towards customer ASes. But are there good reasons when an AS might announce a prefix (route) to a transit provider with NO_EXPORT attached? The IP address space in consideration here is meant to have global reachability.
For some IETF work in progress related to Source Address Validation (SAV), it is useful to know the purposes for which NO_EXPORT may be attached to routes announced in BGP, especially towards transit providers?
I know it makes sense for an AS to announce an aggregate less-specific prefix to transit providers and peers without NO_EXPORT while announcing some more-specific prefixes (subsumed under the aggregate) with NO_EXPORT towards customer ASes. But are there good reasons when an AS might announce a prefix (route) to a transit provider with NO_EXPORT attached? The IP address space in consideration here is meant to have global reachability.
It is also used to manage some aspects of inbound traffic flow, especially when you are peering just for "my customers to talk to your customers."
An obvious use-case would be when there is on-net content or eyeballs in the transit network that you seek, but expressly require that they do not offer transit for your traffic toward their other eBGP neighbors. Mark.
But are there good reasons when an AS might announce a prefix
(route) to a transit provider with NO_EXPORT attached? The IP
address space in consideration here is meant to have global
reachability.
This can be very harmful. Consider IP transit customer of said transit provider that is single homed to said transit provider.
Transit provider will select the aggregate prefix with no-export as best and will not propagate it to its customers while there can be alternative routes available between the prefix owner and transit provider. This will result loss of connectivity for those singlehomed customers.
Right. Just because someone with whom you have an eBGP connection established is also a transit provider doesn’t mean you have to or even want to make use of transiting into other networks across that connection.
We’ve done exactly this to avoid trombone routing to get to a set of customers.
This can be very harmful. Consider IP transit customer of said transit
provider that is single homed to said transit provider.
Transit provider will select the aggregate prefix with no-export as best and
will not propagate it to its customers while there can be alternative routes
available between the prefix owner and transit provider. This will result
loss of connectivity for those singlehomed customers.
Yeah, no. Provided they are singlehomed customers who generally set (or take) a
default route to that transit, they are completely fine. Their transit knows
the prefix and will use it. It gets more problematic for multihomed customers.
As for the original question in the thread...
NO_EXPORT is for us (DNS anycasting) an important tool to keep the "service
cone" limited, and to prevent (esp. bigger) providers from attracting traffic
from further away than we consider reasonable. And yes, we monitor for leaking;
some (again, mostly bigger) providers strip-and-leak...
We're deploying enough nodes to be able to run it that way, and we have - of
course - a few nodes that advertise a supernet without NO_EXPORT to service
whoever isn't peering with us.
For us, NO_EXPORT is an important TE tool; others prefer massaging path preloads
until things look balanced. Others again only peer 1:1 or even over PNIs and
monitor their peers pretty closely.
Yeah, no. Provided they are singlehomed customers who generally set (or take) a
default route to that transit, they are completely fine. Their transit knows
the prefix and will use it. It gets more problematic for multihomed customers.
Well I have no idea why do you say that all such customers always have default route pointed to their transit provider. If that is the case then everything is OK ofc but you can't really take that for granted.
NO_EXPORT can be a useful traffic engineering tool if you want to give a nearby network more specific instructions about how to reach you than you want to give the Internet as a whole. But by its nature, it creates reachability issues — any network who uses your NO_EXPORT prefix won’t export ANY prefix to your address space. If there’s a supernet that covers the smaller NO_EXPORT prefix, that handles the routing issue.
1: They are concerned about bandwidth — if a customer sends a packet and there is no global route, they can drop and not “waste” the transit bandwidth. This is actually useful in some specific niche cases.
but, more likely
2: they want to feel studly. “Real” networks are default-free. Therefore, if I want to be a real network (and feel like a real network engineer), obviously I should do the same…
Ben, Perhaps I am misunderstanding you ... but I am not sure default
routes 'defeat' ROV.
ROV is useful in multi-homed scenarios (simple example: ISP has 1
upstream and is connected to 2 IXPs). Using ROV will mean that in the
face of the ISP having multiple routes to a given destination, the legit
route is more likely to be selected as best path.
If there is no route via any of the peers at the IXPs, the packet goes
to transit: nothing is lost/defeated because there was no alternative
route anyway. The alternative would've been to drop the packet of the
floor, whereas using the default route is a last ditch attempt to
deliver.
I think that having a default route does not take away any value from
applying ROV on EBGP (peering) sessions.
The example you provide is the primary safe use of NO_EXPORT that I’ve seen used in networks. If NO_EXPORT is being used for a prefix and global reachability is needed for the prefix, then there generally needs to be an aggregate/less-specific prefix advertised without NO_EXPORT. I’ve seen plenty of unsafe uses of NO_EXPORT that result in reachability issues.
Several of the responders pointed to using NO_EXPORT as a way of preventing a peer network from advertising your route to their peers and transit neighbors. A couple of responses pointed out the danger of this approach, since it also prevents the network from advertising the route to any of its downstream/customer neighbors. If those customers are expecting to receive a full table, it won’t include the NO_EXPORT tagged routes. These customer networks may, as a result, make a poor routing decision. In a failure situation, where the customer network only has access to this almost full table, they have no path to the NO_EXPORT prefix.
NO_EXPORT isn’t the correct tool to use to both allow a peer to use a route for its customers and prevent the peer from leaking the route to its peers and transit. If we can get our router vendors to implement it, RFC9234 - Route Leak Prevention and Detection Using Roles in UPDATE and OPEN Messages is a much better tool for this problem. Thanks for your work on this RFC.
Thank you, Jeff. My sincere thanks also to all who have offered their perspectives.
Jeff,
I think your observations and advice are well taken and corroborate what some others have also said. This is also helpful for the uRPF/Source Address Validation (SAV) efforts in the IETF. Especially your comment: “If NO_EXPORT is being used for a prefix and global reachability is needed for the prefix, then there generally needs to be an aggregate/less-specific prefix advertised without NO_EXPORT”. SAV techniques need to be inclusive of all feasible prefixes for source addresses (without losing directionality, i.e., without having to resort to loose uRPF) [1][2].
BCP 84 (RFC 8704) [1] also has similar (part (b) below) operational recommendation as yours above:
“… This method relies on either (a) announcements for the same prefixes (albeit some may be prepended to effect lower preference) propagating to all transit providers performing feasible-path uRPF checks or (b) announcement of an aggregate less-specific prefix to all transit providers while announcing more-specific prefixes (covered by the less-specific prefix) to different transit providers as needed for traffic engineering.”
/r