Re: nested prefixes in Internet

[Owen DeLong <owen () delong com>]

How do you figure that?

Owen

> On Oct 24, 2016, at 06:22 , Luke Guillory <lguillory () reservetele com> wrote:
>
> 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.
>
>
>
> Luke Guillory
> Network Operations Manager
>
> Tel:    985.536.1212
> Fax:    985.536.0300
> Email:  lguillory () reservetele com
>
> Reserve Telecommunications
> 100 RTC Dr
> Reserve, LA 70084
>
> _________________________________________________________________________________________________
>
> Disclaimer:
> 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. .
>
> -----Original Message-----
> From: NANOG [mailto:nanog-bounces () nanog org] On Behalf Of Martin T
> Sent: Monday, October 24, 2016 7:06 AM
> To: Matt Buford; Baldur Norddahl
> Cc: nanog
> 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.
>
>
> Martin
>
> On Thu, Oct 20, 2016 at 1:16 AM, Matt Buford <matt () overloaded net> wrote:
> > On Mon, Oct 10, 2016 at 2:44 PM, Baldur Norddahl
> > <baldur.norddahl () gmail com>
> > wrote:
> >
> >
> > > Is that a real problem? In my experience a /24 is honoured almost
> > > universially.
> >
> > 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.