BCP38 For BGP Customers

Grant Taylor gtaylor at tnetconsulting.net
Wed Nov 9 05:08:06 UTC 2022


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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4017 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20221108/2582ffb0/attachment.bin>


More information about the NANOG mailing list