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.