November 2019 - Test - lists.nanog.org

someone, probably someone who scraped your group, sent me a virus as a .doc file
by Large Hadron Collider 14 Nov '19

14 Nov '19

enjoy, boys & girls https://www.virustotal.com/gui/file/d0737edbc17741ab9ee251586cf514552da0992…

1 0

Re: ECN
by Toke Høiland-Jørgensen 14 Nov '19

14 Nov '19

On 13 November 2019 17:20:18 CET, Matt Corallo <netadmin(a)as397444.net> wrote: >This sounds like a bug on Cloudflare’s end (cause trying to do anycast >TCP is... out of spec to say the least), not a bug in ECN/ECMP. Even without anycast, an ECMP shouldn't hash on the ECN bits. Doing so will split the flow over multiple paths; avoiding that is the whole point of doing the flow-based hashing in the first place. Anycast "only" turns a potential degradation of TCP performance into a hard failure... :) -Toke

5 5

Brocade CER MPLS
by Fawcett, Nick 14 Nov '19

14 Nov '19

I have one CER (let's call him Charlie) that is not able to build an LSP tunnel to another CER. Shows "Currently found no route. Will schedule for retry". Both CER's can ping and traceroute each other. When I had the LSP to the destination router (Snoopy) it adds the LSP and shows UP in status field. Both have the same number of routes in their ospf table. Charlie has other LSP's built to other CER's on the network with productive VLL's and VPLS's. I have removed both lsp's from both Charlie and Snoopy and re-added them and only one Snoopy's LSP comes up. Any ideas? Nick -- Checked by SOPHOS http://www.sophos.com

2 1

Apple http/https
by ahmed.dalaali＠hrins.net 13 Nov '19

13 Nov '19

Does anyone know if there is an apple cache? Today we noticed that apple store applications and updates are not caching anymore by HTTPs cache servers, and when we checked through DPI, we found that it's been changed into HTTPS! Does anyone know what is going on? Ahmed

4 3

RE: Brocade CER MPLS
by Fawcett, Nick 13 Nov '19

13 Nov '19

All mpls-interfaces are listed and policy is just traffic-eng ospf. Nick From: James Cornman <james(a)atlanticmetro.net> Sent: Wednesday, November 13, 2019 2:43 PM To: Fawcett, Nick <nfawcett(a)corp.mtco.com> Cc: nanog(a)nanog.org Subject: Re: Brocade CER MPLS Ensure that 'mpls-interface xxx' is on for all of the interfaces, and also ensure that any traffic-engineering options match on both sides. "show mpls lsp detail" should show some other info that may be helpful here. On Wed, Nov 13, 2019 at 3:24 PM Fawcett, Nick via NANOG <nanog(a)nanog.org<mailto:nanog@nanog.org>> wrote: I have one CER (let’s call him Charlie) that is not able to build an LSP tunnel to another CER. Shows “Currently found no route. Will schedule for retry”. Both CER’s can ping and traceroute each other. When I had the LSP to the destination router (Snoopy) it adds the LSP and shows UP in status field. Both have the same number of routes in their ospf table. Charlie has other LSP’s built to other CER’s on the network with productive VLL’s and VPLS’s. I have removed both lsp’s from both Charlie and Snoopy and re-added them and only one Snoopy’s LSP comes up. Any ideas? Nick -- Checked by SOPHOS http://www.sophos.com -- James Cornman Chief Technology Officer jcornman(a)atlanticmetro.net<mailto:jcornman@atlanticmetro.net> 212.792.9950 - ext 101 Atlantic Metro Communications 4 Century Drive, Parsippany NJ 07054 Cloud Hosting • Colocation • Network Connectivity • Managed Services Follow us on Twitter: @atlanticmetro<https://twitter.com/atlanticmetro> • Like us on Facebook<https://www.facebook.com/atlanticmetro> www.atlanticmetro.net<https://www.atlanticmetro.net/> -- Checked by SOPHOS http://www.sophos.com

2 1

2000::/3 Being Announced and Accepted
by Douglas Fischer 13 Nov '19

13 Nov '19

I have been recommending to many friends to check in daily at http://irrexplorer.nlnog.net/ to make sure everything is healthy with their prefixes ... Today a colleague reported a problem with an AS58299 ad appearing in "their prefixes". I went look and was showing up on our ASNs too. It took me a while (dããã) to understand what was going on ... Why was irrexplorer showing that prefix in our query? Could anyone reach somebody from OpenFactory/NetShelter/level66network about this? http://lg.ring.nlnog.net/prefix_bgpmap/lg01/ipv6?q=2000::/3 2000::/3 [LEVEL66NETWORK1 11:35:27 from 2a09:11c0::1] * (100/-) [AS58299i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 209844 49697 58299 BGP.next_hop: 2a09:11c0::1 BGP.local_pref: 100 BGP.community: (49697,1000) (49697,1007) (49697,2302) BGP.ext_community: (RPKI Origin Validation State: not-found) BGP.large_community: (209844, 100, 13) -- Douglas Fernando Fischer Engº de Controle e Automação

2 2

Re: Marseille Colocation
by Jürgen Jaritsch 13 Nov '19

13 Nov '19

+1 for the IX in Marseille! Cross-connect charges are always the same with IX: you need to buy the pre-cabling (see below) and afterwards you pay CC with MRC: Costs for pre-cabling from your rack to the MMR (NRC): 6 SMD pairs: 2.475,00 Eur 12 SMD pairs: 4.125,00 Eur 24 SMD pairs: 5.960,00 Eur Copper-CC pre-cabling from your rack to the MMR (NRC): 6x UTP/STP RJ45: 1.950,00 Eur 12x UTP/STP RJ45: 2.600,00 Eur 24x UTP/STP RJ45: 3.650,00 Eur Copper CC MRC (same building): 45,00 Eur Copper CC MRC (doesn't matter to which IX building on the IX campus): 85,00 Eur Copper CC MRC (between your own racks): 25,00 Eur SMD CC MRC (same building): 85,00 Eur SMD CC MRC (doesn't matter to which IX building on the IX campus): 85,00 Eur SMD CC MRC (between your own racks): 45,00 Eur I heard something about a raise from 85,00 to 95,00 Eur MRC, but as of yet I didn't have a proof for this. Connecting the CC to your equipment: 275,00 Eur NRC Best regards Jürgen

1 0

Disney+ Geolocation Issues
by Mat Perkins 12 Nov '19

12 Nov '19

Hey Everyone, I'm working with 3 ISPs currently who are having Geo Location issues with clients being told they are out of the US. When their IPs are checked via a free Geo IP tool everything is showing up correctly. Anyone have any insight on who Disney+ is using for their GeoLocation services and if anyone here can help out with getting updated to be in the correct location / type of service provider? Mat

1 0

Re: Disney+ Streaming
by Clayton Zekelman 12 Nov '19

12 Nov '19

At 03:17 PM 12/11/2019, Brian J. Murrell wrote: >Fair enough, in the cases where operators are Netflix OC partners and >might see a shift in network use from a Netflic OC appliance to >external their network to other streaming services. > >But for an operator who doesn't have an OC Appliances, is there likely >to be much difference? I suppose that was the context I was thinking >in. Sure. You could see changes in where traffic comes from. It may shift from peering to transit. >That said, I (admittedly, idly) wonder what percentage of users (world- >wide, by nation, geographical area, etc.) are served by OC Appliances. >I really have no clue as to the penetration of OC Appliances. OCAs make a huge difference in our network. Between the two ASs we operate in different regions - to the tune of maybe 40 Gbps. -- Clayton Zekelman Managed Network Systems Inc. (MNSi) 3363 Tecumseh Rd. E Windsor, Ontario N8W 1H4 tel. 519-985-8410 fax. 519-985-8409

1 0

Re: Disney+ Streaming
by Clayton Zekelman 12 Nov '19

12 Nov '19

Netflix has done a great job deploying OC Appliances. A Netflix user != Amazon, Hulu, etc... At 02:58 PM 12/11/2019, Brian J. Murrell wrote: >On Tue, 2019-11-12 at 19:49 +0000, Justin Krejci wrote: > > > > As the service grows in popularity, and its breadth of content and > > manageable price is likely to attract a lot of growth, I'd like to > > plan for any necessary augmentations to the network. > > From the end-user/viewer network capacity perspective is a new >streaming service likely to (significantly) "add new viewers" or more >likely to just shift existing viewers away from an existing service >(i.e Netflix, Amazon, Hulu, etc.) to Disney, resulting in a net-wash >from the end-user/viewer network capacity perspective? > >I guess the question is, will Disney content compel users who are not >already streaming to start streaming? > >Cheers, >b. > > -- Clayton Zekelman Managed Network Systems Inc. (MNSi) 3363 Tecumseh Rd. E Windsor, Ontario N8W 1H4 tel. 519-985-8410 fax. 519-985-8409

2 1