On 11/8/22 2:01 PM, Matthew Petach wrote:
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.
Interesting points Matt. Hence why I asked. :-)
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.
I agree that's the only way to be absolutely certain. I would naively wonder if AS Path pre-pends would help mitigate this.However, based on the RIB vs FIB sub-threads in this larger thread, I'm beginning to doubt that such will work with uRPF because the route would be depreffed and thus not in the FIB thereby would be filtered by uRPF.
As Mr. Bush might say, "I recommend all my competitors implement this in their networks."
*nod*nod* Thank you for the understandable explanation Matt. -- Grant. . . . unix || die
smime.p7s
Description: S/MIME Cryptographic Signature
