nested prefixes in Internet
lguillory at reservetele.com
Mon Oct 24 13:22:20 UTC 2016
That only works if the /24 isn't coming from the middle of the /20 block and is on the front end or back end.
Network Operations Manager
Email: lguillory at reservetele.com
100 RTC Dr
Reserve, LA 70084
The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. .
From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Martin T
Sent: Monday, October 24, 2016 7:06 AM
To: Matt Buford; Baldur Norddahl
Subject: Re: nested prefixes in Internet
Thank you all for the replies! I'll go with the solution where "ISP A"
announces both /19 prefix and /24 prefix.
On Thu, Oct 20, 2016 at 1:16 AM, Matt Buford <matt at overloaded.net> wrote:
> On Mon, Oct 10, 2016 at 2:44 PM, Baldur Norddahl
> <baldur.norddahl at gmail.com>
>> Is that a real problem? In my experience a /24 is honoured almost
> Here's a real-world issue I ran into with this. In this case, it
> isn't that someone filtered /24s, but that they didn't have a full
> table (peering routes only plus a default). This resulted in them
> following the less specific route for traffic destined for the /24.
> A customer of mine was advertising only a /20 to me and then only a
> more specific /24 was advertised from a remote site of theirs to a
> different ISP. The customer did have a connection between their two
> sites, so in theory it was OK if the traffic arrived on their "wrong"
> link, except that the customer strongly didn't want this to happen,
> thus the inconsistent routes.
> This customer found that the remote /24 was unable to access a large
> CDN provider. This CDN told them that a traceroute to the /24 went to
> my network (we peered at an exchange) and was then dropped.
> This seemed odd at first, as I confirmed I was not advertising the /24
> to them so why were they routing it to me? It turned out that the CDN
> provider was running a peer-routes-only network with a default to
> their transit. This meant that they saw the /20 from their peer (me)
> but never saw the /24, since they carried no transit routes. This
> resulted in them routing the entire /20 to me.
> My peering router was not willing to route traffic from a peering
> exchange towards transit I had to pay for, so it was dropped.
> The customer's split advertisements didn't seem particularly
> unreasonable or invalid, though perhaps they were not the preferred
> setup. It wasn't unreasonable for me to not route from a peering
> exchange to transit. It wasn't unreasonable of the CDN to have a
> peering-and-default routing table. But, those three things together were not compatible.
> I called the customer and presented them with my findings and some
> potential options to consider, and consistent advertisements was one
> of those options. The customer strongly wanted incoming traffic to
> arrive directly to the correct location so he didn't want to do that.
> I suggested a possible compromise was for him to advertise both the
> /24 and /20 to me, but use communities so that I never advertised his
> /24 to any upstreams or peering exchanges. That way, if traffic for
> the /24 accidentally hit my network like we were running into, I would
> route it to him and he could pass it to the correct site. It meant
> that a little traffic would arrive at the wrong site in his network
> and have to pass over his back-end link, but at least it would be
> fairly limited. He didn't like this either. He didn't want to split
> the /20 advertisement up to no longer cover the /24 either, I think just because "I shouldn't have to do that!"
> The option the customer chose in the end was to use a community on his
> advertisement to instruct my routers to no longer advertise his /20 to
> any peering exchanges at all. That ensured the CDN didn't directly
> send me anything for him (not the /24 or the /20), and the transit
> networks in-between took care of making sure traffic to the /24 didn't
> accidentally end up on my network. While I didn't find it very
> elegant to be shifting traffic from peering exchanges to transit, it
> wasn't a significant amount of traffic and it got him off my back.
More information about the NANOG