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.