- Test - lists.nanog.org

Boston Fiber Optic Networks
by Rod Beck 15 Nov '19

15 Nov '19

I am looking to discuss off list the fiber optic landscape for greater Boston. Trying to understand who are the key players. Thanks. Regards, Roderick. Roderick Beck VP of Business Development United Cable Company www.unitedcablecompany.com<http://www.unitedcablecompany.com> New York City & Budapest rod.beck(a)unitedcablecompany.com 36-70-605-5144 [1467221477350_image005.png]

3 2

ECN
by Baldur Norddahl 15 Nov '19

15 Nov '19

Hello I have a customer that believes my network has a ECN problem. We do not, we just move packets. But how do I prove it? Is there a tool that checks for ECN trouble? Ideally something I could run on the NLNOG Ring network. I believe it likely that it is the destination that has the problem. Regards, Baldur

16 21

Intergovernmental Advisory Committee: Disaster Response Coordination
by Sean Donelan 14 Nov '19

14 Nov '19

The FCC's IAC has published its report on emergency communication impacts of the various hurricanes and disasters in 2018 and early 2019. These include Hurricanes Harvey, Irma, Maria, Michael and Nate. No surprises. I've seen essentially all of the issues and recommendations in other after action reports. https://www.fcc.gov/document/fcc-issues-advisory-committee-public-safety-an… Intergovernmental Advisory Committee to the Federal Communications Commission Advisory Recommendation No: 2019-3 In the Matter of Intergovernmental Disaster Response Coordination November 7, 2019 The recommendations herein include best practices to promote resilient communications during and after an incident to help ensure first responders and the public have access to reliable communications when disaster strikes. The importance of maintaining resilient communications during and after a disaster cannot be overstated. Sometimes, the ability to communicate during and after a disaster is a matter of life and death. [...] RECOMMENDATIONS In summary, in order to fine-tune preparedness, response and recovery between state, local, and Tribal governments, the IAC recommends: • Regular training, coordination, and communication is a must. It must be conducted during “blue skies.” When an emergency is occurring, it is too late to start coordinating. In addition to training for government workers, Training, outreach, and coordination must be provided for the citizens and “stakeholders” that we are trying to protect. A properly trained and informed community is a resilient community. • A formal infrastructure must be identified with representatives from all stakeholders, who meet throughout the year to familiarize themselves with each other, identify common threats, and coordinate training and response. For example, the South Carolina Emergency Operations Plan is reviewed annually to ensure state agencies and voluntary organizations understand each other’s responsibilities and capabilities. At least twice annually, the South Carolina Emergency Management Division hosts workshops for counties to discuss issues and concerns. Further, regional workshops are conducted quarterly throughout the state. • All involved parties must have open and redundant lines of communication during normal operations, as well as during emergencies. In order to be efficient and effective, state, local, and Tribal government must know what each other is doing. They must also be aware of the general capabilities and the available resources that each agency involved can contribute.

1 0

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