On Tue, Nov 8, 2022 at 8:44 AM Grant Taylor via NANOG <nanog@nanog.org> wrote:
> [...] > > I don't understand why you would want to allow packets that couldn't > return the same path. > > As for asymmetrically routed packets, I would still expect a return path > to exist, even if it's not utilized. > > Grant, You're thinking about it from the upstream perspective, where a route could be accepted but depreferenced and thus not actively used. Think about it from the downstream network's perspective, though. If you're my upstream, and I don't want to use your link for inbound traffic, but I'd like to be able to send out some traffic over the link, how can I advertise the prefix to you in a way that would both ensure that you have it in your table locally, so that uRPF is happy, but also to ensure no packets actually make *use* of that routing table entry? Sure, you could tag the routes with 'no-export', but that only prevents the prefix from propagating outward, it doesn't prevent traffic on that router from using the routing table entry. You can try adjusting your MED, and hope the upstream doesn't squash the MED back to a default value it applies to all its customers. For the most part, you're up against a wall. You don't know how your upstream's route selection process is stacked with respect to routes you advertise, so you have no certainty that if you announce a prefix to them, it won't potentially be used to carry all your inbound traffic. The only way to be sure that you won't take inbound traffic on a link is to not advertise the prefix at all across that link. Why might this be necessary, you ask? Imagine you've got links of different sizes on your network. You have a 1G link to provider A You have a 1G link to provider B You have a 10G link to cheap provider C You have a 10G link into a peering exchange Somewhere beyond provider A, someone decides they don't like one of your customers, and sends a 5Gbps DDoS flow at you. If you continue advertising that prefix to provider A, everyone going through provider A will suffer, including all their customers. You have plenty of capacity to take the inbound flow through the exchange point and through cheap provider C. So, you stop advertising the prefix under attack to provider A and provider B, to ensure the traffic doesn't saturate your 1G links. Inbound traffic happily shifts to the exchange point port and provider C's port. Life is good. Oh no! Provider A has implemented uRPF, and now all their customers are unhappy because they can't reach your websites on that prefix, because the *return* traffic is still flowing out the 1G link directly to provider A. Trying to implement a source-based routing filter to redirect all traffic *coming* from the prefix under attack destined to ISP A to instead go through ISP C is a pain in the butt. So, you grudgingly stop accepting routes from ISP A, as that's the only way to make the uRPF pain stop. Now, none of your traffic is flowing out the 1G link to ISP A; their customers are happy again, because they can reach websites on your prefix that is under attack (via ISP C, or the exchange point). At the end of the month, you look at your contracts, and realize that you had to spend a chunk of your limited engineering resources working around the upstream uRPF filter, and ultimately ended up not sending traffic across a link you were paying for. When renewal time comes, you decide it's not worth the headache to pay for a link to ISP A that you can't reliably use, and that requires manual intervention to work around whenever creative routing solutions are necessary. You don't renew your contract with ISP A. As Mr. Bush might say, "I recommend all my competitors implement this in their networks." Thanks! Matt
