nested prefixes in Internet

Wed Oct 19 22:16:35 UTC 2016

On Mon, Oct 10, 2016 at 2:44 PM, Baldur Norddahl <baldur.norddahl at 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.