Misread the email. Ignore my ignorance. Sent from my iPad
> On Oct 24, 2016, at 9:48 PM, Owen DeLong <o...@delong.com> wrote: > > 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. >
