|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
X-Original-To: nanog@nanog.org From: Luke Guillory <lguillory@reservetele.com> To: Owen DeLong <owen@delong.com> Date: Tue, 25 Oct 2016 03:33:43 +0000 In-Reply-To: <BDF56E89-6BF6-4C97-AC80-6DD3C38850D4@delong.com> Cc: nanog <nanog@nanog.org> Errors-To: nanog-bounces@nanog.org Misread the email. Ignore my ignorance.=20 Sent from my iPad > On Oct 24, 2016, at 9:48 PM, Owen DeLong <owen@delong.com> wrote: >=20 > How do you figure that? >=20 > Owen >=20 >> On Oct 24, 2016, at 06:22 , Luke Guillory <lguillory@reservetele.com> wr= ote: >>=20 >> 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. >>=20 >>=20 >>=20 >> Luke Guillory >> Network Operations Manager >>=20 >> Tel: 985.536.1212 >> Fax: 985.536.0300 >> Email: lguillory@reservetele.com >>=20 >> Reserve Telecommunications >> 100 RTC Dr >> Reserve, LA 70084 >>=20 >> ________________________________________________________________________= _________________________ >>=20 >> Disclaimer: >> The information transmitted, including attachments, is intended only for= the person(s) or entity to which it is addressed and may contain confident= ial and/or privileged material which should not disseminate, distribute or = be copied. Please notify Luke Guillory immediately by e-mail if you have re= ceived this e-mail by mistake and delete this e-mail from your system. E-ma= il transmission cannot be guaranteed to be secure or error-free as informat= ion could be intercepted, corrupted, lost, destroyed, arrive late or incomp= lete, or contain viruses. Luke Guillory therefore does not accept liability= for any errors or omissions in the contents of this message, which arise a= s a result of e-mail transmission. . >>=20 >> -----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 >>=20 >> Thank you all for the replies! I'll go with the solution where "ISP A" >> announces both /19 prefix and /24 prefix. >>=20 >>=20 >> Martin >>=20 >>> On Thu, Oct 20, 2016 at 1:16 AM, Matt Buford <matt@overloaded.net> wrot= e: >>> On Mon, Oct 10, 2016 at 2:44 PM, Baldur Norddahl >>> <baldur.norddahl@gmail.com> >>> wrote: >>>=20 >>>=20 >>>> Is that a real problem? In my experience a /24 is honoured almost >>>> universially. >>>>=20 >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> My peering router was not willing to route traffic from a peering >>> exchange towards transit I had to pay for, so it was dropped. >>>=20 >>> 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 we= re not compatible. >>>=20 >>> 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 jus= t because "I shouldn't have to do that!" >>>=20 >>> 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. >=20
|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |