How do you figure that? Owen
> On Oct 24, 2016, at 06:22 , Luke Guillory <lguill...@reservetele.com> wrote: > > 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: lguill...@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-boun...@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 <m...@overloaded.net> wrote: >> On Mon, Oct 10, 2016 at 2:44 PM, Baldur Norddahl >> <baldur.nordd...@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.
