"Tactical" /24 announcements

Mon Aug 16 14:09:55 UTC 2021

>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.
>
>D broke the Internet. If packets from you reach A at all, they do so
>through an unpermitted path.
>
>Regards,
>Bill Herrin

Ok, I apologize, but I have some dumb questions (because I don't BGP
anymore):

1) I assume in the scenario that A "owns" (ARIN assignment) 10.0.0.0/16 and
if B has a /24 assignment out of the block that A "owns", shouldn't that
mean that B has a business relationship with A and some kind of direct
connectivity to A?

2) If "no", then why is B using a /24 out of A's block? If A sold or gave
the block to B without a connectivity agreement, then A should break up
their announcements appropriately to carve the /24 out of their
announcement, right?

3) If "yes", then the connectivity wouldn't be broken, right?

TIA for the tutoring and bearing with me.

Regards,
Jason K Pope
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20210816/76ea7aca/attachment.html>