Question about the use of NO_EXPORT in BGP route announcements
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. Sriram
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."
:-) /r
On 9/19/24 19:26, Sriram, Kotikalapudi (Fed) via NANOG wrote:
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.
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.
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. -----Original Message----- From: Mark Tinka <mark@tinka.africa<mailto:Mark%20Tinka%20%3cmark@tinka.africa%3e>> To: nanog@nanog.org<mailto:nanog@nanog.org> Subject: Re: Question about the use of NO_EXPORT in BGP route announcements Date: Fri, 20 Sep 2024 16:51:03 +0200 On 9/19/24 19:26, Sriram, Kotikalapudi (Fed) via NANOG wrote: 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. 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.
hey,
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. -- tarko
Hi Tarko, folks, tarko@lanparty.ee (Tarko Tikan) wrote:
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. Cheers, Elmar.
hey,
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. -- tarko
Why would a single homed customer not take a default route?
On Sep 20, 2024, at 1:25 PM, Tarko Tikan <tarko@lanparty.ee> wrote:
hey,
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.
-- tarko
On Fri, Sep 20, 2024 at 2:36 PM, <sronan@ronan-online.com> wrote:
Why would a single homed customer not take a default route?
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… W
On Sep 20, 2024, at 1:25 PM, Tarko Tikan <tarko@lanparty.ee> wrote:
hey,
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.
-- tarko
One example is if the customer is doing ROKI ROV validation (and their upstream isn't) having a default would defeat ROV validation On Fri, Sep 20, 2024, 20:40 <sronan@ronan-online.com> wrote:
Why would a single homed customer not take a default route?
On Sep 20, 2024, at 1:25 PM, Tarko Tikan <tarko@lanparty.ee> wrote:
hey,
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.
-- tarko
On Tue, Sep 24, 2024 at 02:57:21PM +0200, Ben Cartwright-Cox via NANOG wrote:
One example is if the customer is doing ROKI ROV validation (and their upstream isn't) having a default would defeat ROV validation
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. Kind regards, Job
On Sep 20, 2024, at 8:59 AM, Elmar K. Bins <elmi@4ever.de> wrote:
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.
The supernet piece of this is key. 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. -Steve
Hello Sriram, 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](https://datatracker.ietf.org/doc/rfc9234/) is a much better tool for this problem. Thanks for your work on this RFC. Jeff -- Jeff Bartig Interconnection Architect Internet2 [AS11164](https://as11164.peeringdb.com) / AS11537 +1-608-616-9908 jbartig@internet2.edu On 19 Sep 2024, at 12:26, Sriram, Kotikalapudi (Fed) via NANOG wrote:
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.
Sriram
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." Sriram [1] BCP 84 (RFC 8704) https://www.rfc-editor.org/rfc/rfc8704.pdf [2] BAR-SAV: https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-bar-sav-04 From: Jeff Bartig <jbartig@internet2.edu> Sent: Wednesday, September 25, 2024 1:24 PM To: Sriram, Kotikalapudi (Fed) <kotikalapudi.sriram@nist.gov> Cc: nanog@nanog.org Subject: Re: Question about the use of NO_EXPORT in BGP route announcements Hello Sriram, 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<https://datatracker.ietf.org/doc/rfc9234/> is a much better tool for this problem. Thanks for your work on this RFC. Jeff -- Jeff Bartig Interconnection Architect Internet2 AS11164<https://as11164.peeringdb.com/> / AS11537 +1-608-616-9908 jbartig@internet2.edu<mailto:jbartig@internet2.edu> On 19 Sep 2024, at 12:26, Sriram, Kotikalapudi (Fed) via NANOG wrote: 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. Sriram
participants (12)
-
7riw77＠gmail.com -
Ben Cartwright-Cox -
Elmar K. Bins -
Jeff Bartig -
Job Snijders -
Justin Krejci -
Mark Tinka -
Sriram, Kotikalapudi (Fed) -
sronan＠ronan-online.com -
Steve Gibbard -
Tarko Tikan -
Warren Kumari