nanog mailing list archives

Re: "Tactical" /24 announcements


From: Amir Herzberg <amir.lists () gmail com>
Date: Thu, 12 Aug 2021 13:38:48 -0400

On Thu, Aug 12, 2021 at 1:22 PM William Herrin <bill () herrin us> wrote:

On Thu, Aug 12, 2021 at 9:41 AM Hank Nussbacher <hank () interall co il>
wrote:
On 12/08/2021 17:59, William Herrin wrote:
If you prune the routes from the Routing Information Base instead, for
any widely accepted size (i.e. /24 or shorter netmask) you break the
Internet.

How does this break the Internet?  I would think it would just result in
sub-optimal routing (provided there is a covering larger prefix) but
everything should continue to work.  Clue me in, please.

A originates 10.0.0.0/16 to paid transit C
B originates 10.0.1.0/24 also to paid transit C
C offers both routes to D. D discards 10.0.1.0/24 from the RIB based
on same-next-hop
You peer with A and D. You receive only 10.0.0.0/16 since A doesn't
originate 10.0.1.0/24 and D has discarded it.
You send packets for 10.0.1.0/24 to A (the shortest path for
10.0.0.0/16), stealing A's paid transit to C to get to B.

Unless A filters C-bound packets purportedly from 10.0.1.0/24. B
doesn't currently transit for A so from B's perspective that's not an
allowed path. In which case, your path to 10.0.1.0/24 is black holed.


Bill, I beg to respectfully differ, knowing that I'm just a researcher and
working `for real' like you guys, so pls take no offence.

I don't think A would be right to filter these packets to 10.0.1.0/24; A
has announced 10.0.0.0/16 so should route to that (entire) prefix, or A is
misleading its peers.

If A doesn't, though, then B receives a packet from A to 10.0.1.0/24.
Unless B is filtering based on the specific IP prefixes of A - which seems
to me unlikely - then B has no way to know that this packet is from `you'
rather than from A itself (or a customer of A). So B will carry this
traffic, imho.

So A is just paying for the traffic since it announced the prefix.

Such situations, to best of my knowledge, actually happen on the Internet
when a subprefix is filtered for different reasons. We observed it happens
with ROV , in our ROV++ simulations, but I'll refrain
from attaching the URL again so not to be `plugging' that paper (and since
I'm lazy to look it up hhh)

have great day and I'll be happy to learn if I'm wrong. Amir

Current thread: