Re: nested prefixes in Internet

[Martin T <m4rtntns () gmail com>]

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.