[192316] in North American Network Operators' Group
Re: nested prefixes in Internet
daemon@ATHENA.MIT.EDU (Owen DeLong)
Tue Oct 25 04:36:57 2016
X-Original-To: nanog@nanog.org
From: Owen DeLong <owen@delong.com>
In-Reply-To: <8D89F96B7AB1B84F9E049CC7BB91BF5CFAF87E4D@RTC-EXCH01.RESERVE.LDS>
Date: Mon, 24 Oct 2016 19:14:55 -0700
To: Luke Guillory <lguillory@reservetele.com>
Cc: nanog <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
How do you figure that?
Owen
> On Oct 24, 2016, at 06:22 , Luke Guillory <lguillory@reservetele.com> =
wrote:
>=20
> 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.
>=20
>=20
>=20
> Luke Guillory
> Network Operations Manager
>=20
> Tel: 985.536.1212
> Fax: 985.536.0300
> Email: lguillory@reservetele.com
>=20
> Reserve Telecommunications
> 100 RTC Dr
> Reserve, LA 70084
>=20
> =
__________________________________________________________________________=
_______________________
>=20
> 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. .
>=20
> -----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
>=20
> Thank you all for the replies! I'll go with the solution where "ISP A"
> announces both /19 prefix and /24 prefix.
>=20
>=20
> Martin
>=20
> 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:
>>=20
>>=20
>>> Is that a real problem? In my experience a /24 is honoured almost
>>> universially.
>>>=20
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> My peering router was not willing to route traffic from a peering
>> exchange towards transit I had to pay for, so it was dropped.
>>=20
>> 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.
>>=20
>> 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!"
>>=20
>> 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.
