"Tactical" /24 announcements

Thu Aug 12 17:38:48 UTC 2021

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

> On Thu, Aug 12, 2021 at 9:41 AM Hank Nussbacher <hank at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20210812/edc905e7/attachment.html>