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 <[email protected]> wrote: > On Mon, Oct 10, 2016 at 2:44 PM, Baldur Norddahl <[email protected]> > 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.
