- Test - lists.nanog.org

Re: Verizon Fios, WashDC gateway problem
by Paul Paukstelis 17 Feb '16

17 Feb '16

I avoided posting traceroute initially after reading the FAQ, but this seems like a case where it can help in diagnostics. Loss starts at the affected device (hop 3) and persists. See mtr report for affected and unaffected gateways: Host Loss% Snt Last Avg Best Wrst StDev 1. Wireless_Broadband_Router.home 0.0% 673 0.5 0.5 0.4 0.6 0.0 2. L100.WASHDC-VFTTP-123.verizon-gni.net 0.0% 673 6.5 8.1 3.7 90.1 9.6 3. G1-7-3-5.WASHDC-LCR-22.verizon-gni.net 11.2% 673 8.2 8.7 5.1 15.8 1.6 4. ??? 5. 0.ae4.BR2.IAD8.ALTER.NET 10.4% 673 9.0 8.0 5.4 22.1 1.4 6. be3018.ccr41.iad02.atlas.cogentco.com 10.3% 673 7.1 8.2 5.9 15.3 1.2 7. 38.122.63.54 12.3% 673 7.0 8.4 6.2 29.3 2.8 8. ae3-asbnvacyj41.lightower.net 9.4% 672 7.1 8.3 5.8 32.0 2.2 9. 172.85.52.94.lightower.net 10.7% 672 10.0 9.6 7.5 14.3 1.0 10. te1-4.css-fw-r1.net.umd.edu 11.0% 672 12.2 14.8 7.6 287.2 27.2 11. gi6-6.ptx-core-r1.net.umd.edu 7.9% 672 10.5 11.0 7.8 340.5 15.2 12. gi3-2.ptx-dual-r1.net.umd.edu 9.7% 672 11.9 13.1 8.3 265.6 14.3 13. 129.2.168.3 12.6% 672 11.2 10.9 8.5 188.4 7.7 Host Loss% Snt Last Avg Best Wrst StDev 1. Wireless_Broadband_Router.home 0.0% 287 0.5 0.5 0.5 1.2 0.1 2. L100.WASHDC-VFTTP-123.verizon-gni.net 0.0% 287 6.6 14.9 3.7 148.3 22.8 3. G0-10-3-4.WASHDC-LCR-21.verizon-gni.ne 0.0% 287 9.4 14.9 5.3 97.2 19.1 4. ??? 5. 0.ae3.BR2.IAD8.ALTER.NET 0.0% 287 7.8 13.6 5.7 93.6 17.7 6. be3018.ccr41.iad02.atlas.cogentco.com 0.0% 287 8.1 14.0 6.0 94.1 18.5 7. 38.122.63.54 0.0% 287 9.7 15.5 6.0 97.1 19.1 8. ae3-asbnvacyj41.lightower.net 0.0% 287 9.4 16.4 5.9 95.7 19.6 9. 172.85.52.94.lightower.net 0.0% 287 9.1 19.0 7.7 99.7 22.6 10. te1-4.css-fw-r1.net.umd.edu 0.0% 287 9.4 23.9 7.7 269.8 35.7 11. gi6-6.ptx-core-r1.net.umd.edu 0.0% 287 10.7 18.2 8.2 100.4 20.6 12. gi3-2.ptx-dual-r1.net.umd.edu 0.0% 287 12.2 20.5 8.5 172.2 23.7 13. 129.2.168.2 0.0% 287 11.1 16.4 7.7 95.8 19.3 On 02/17/2016 02:14 PM, chris wrote: > packet loss in the middle of the path means nothing if you have no > loss at the destination. do you see packet loss on the last mtr hop > which is your destination machine? > > On Tue, Feb 16, 2016 at 8:54 PM, Paul Paukstelis > <shocksofmighty(a)gmail.com <mailto:shocksofmighty@gmail.com>> wrote: > > Apologies for a post as a non-expert, but it was suggested that I > see if any Verizon techs are reading here and to solicit opinions > on fixing a peculiar problem. > > I noticed about a month ago that all upload traffic from my home > router (Fios) to a specific work machine was extremely slow. I > first thought it was an issue with the destination NIC, or > something with the university gateway. I had normal upload speeds > to other destination machines in the same building on the same > subnet, etc. Eventually, I swapped IPs on the two machines, and > found that the problem had to do with routing to a specific IP, > not the destination machine itself. I confirmed first with > wireshark that there was packet loss resulting in constant TCP > Fast Retransmits when uploading to the affected host IP. > traceroute showed that the affected and unaffected traffic went > through different Verizon gateways > (G1-7-3-5.WASHDC-LCR-22.verizon-gni.net > <http://G1-7-3-5.WASHDC-LCR-22.verizon-gni.net> and > G0-10-3-4.WASHDC-LCR-21.verizon-gni.net > <http://G0-10-3-4.WASHDC-LCR-21.verizon-gni.net>, respectively; > I've ultimately found that four different gateways are used > depending on the destination IP). mtr confirmed consistent 10% > packet loss at G1-7-3-5.WASHDC-LCR-22.verizon-gni.net > <http://G1-7-3-5.WASHDC-LCR-22.verizon-gni.net>. This tells me > that there is clearly a problem with this device, but I have yet > to be able to convince Verizon there is a problem. I thought I > might just VPN around it, but as luck would have it the university > VPN IP gets routed through the bad gateway. This has to be > impacting a significant number of Fios customers in the DC/MD > area. 25% of all upload traffic (assuming a normal distribution of > destination IPs) gets routed through this bad device. > > Any thoughts on how to get in touch with someone from Verizon that > can help with this or any specific ideas on what this problem > might be which I can try to pass along? > > Thanks. > >

1 0

libero.it email admin contact
by Techs_Maru 17 Feb '16

17 Feb '16

Hi folks, Now, can not sent mail to libero.it by RBL. I requests to removal from blacklist.... I want to contact libero.it mail adminis. or Anyone knows request form?

1 0

Verizon Fios, WashDC gateway problem
by Paul Paukstelis 17 Feb '16

17 Feb '16

Apologies for a post as a non-expert, but it was suggested that I see if any Verizon techs are reading here and to solicit opinions on fixing a peculiar problem. I noticed about a month ago that all upload traffic from my home router (Fios) to a specific work machine was extremely slow. I first thought it was an issue with the destination NIC, or something with the university gateway. I had normal upload speeds to other destination machines in the same building on the same subnet, etc. Eventually, I swapped IPs on the two machines, and found that the problem had to do with routing to a specific IP, not the destination machine itself. I confirmed first with wireshark that there was packet loss resulting in constant TCP Fast Retransmits when uploading to the affected host IP. traceroute showed that the affected and unaffected traffic went through different Verizon gateways (G1-7-3-5.WASHDC-LCR-22.verizon-gni.net and G0-10-3-4.WASHDC-LCR-21.verizon-gni.net, respectively; I've ultimately found that four different gateways are used depending on the destination IP). mtr confirmed consistent 10% packet loss at G1-7-3-5.WASHDC-LCR-22.verizon-gni.net. This tells me that there is clearly a problem with this device, but I have yet to be able to convince Verizon there is a problem. I thought I might just VPN around it, but as luck would have it the university VPN IP gets routed through the bad gateway. This has to be impacting a significant number of Fios customers in the DC/MD area. 25% of all upload traffic (assuming a normal distribution of destination IPs) gets routed through this bad device. Any thoughts on how to get in touch with someone from Verizon that can help with this or any specific ideas on what this problem might be which I can try to pass along? Thanks.

1 0

Mellanox 100GE switches
by Jay Hanke 16 Feb '16

16 Feb '16

Does anyone have experiences they can share regarding the Mellanox 100GE Ethernet switches? Thanks! Jay

2 1

Call for Presentations - CHI-NOG 06 (May 12th)
by Tom Kacprzynski 16 Feb '16

16 Feb '16

*Call for Presentations* CHI-NOG 06 - (Chicago Network Operators Group) May 12th 2016, Chicago, IL The Chicago Network Operators Group (CHI-NOG) is a vendor neutral organization. Our goal is to create a regional community of network professionals by presenting the latest technology trends, enabling collaboration and providing networking opportunities. CHI-NOG will be hosting its sixth annual conference May 12th, 2016 in downtown Chicago. For more information please see http://chinog.org. The CHI-NOG Program Committee is seeking proposals for presentations on relevant networking technologies with a focus on the following topics: * Network Automation/ DevOps * Interconnection/Peering/Cloud Exchanges * Low Latency Networks/Financial Networks * Network Security * Internet Monitoring * Advanced BGP/MPLS Technologies * Software Defined Networking * Cloud Networking Technologies * Network Operation * Academic Research in Networking and Related Infrastructure Fields * Open Source Networking Tools * Optical Networking/Data Center Interconnect * Data Center Fabric * Wireless * IPv6 *Session Format* Each presentation is 30 minutes, which includes a questions and answers. The duration can be extended per individual request to 60 minutes and will be considered by the program committee. Presentations should not contain any marketing material and should avoid discussion of commercial products but rather focus on the underlying technology. *Key Dates* * Presentation Abstract Submission Deadline ------------------- 3/15/16 * Abstract Selection ---------------------------------------------------- 3/18/16 * Presentation Full Slides Submission Deadline ----------------- 4/15/16 * Final Selection --------------------------------------------------------- 4/29/16 * Conference ------------------------------------------------------------- 5/12/16 *Submission* Please submit presentation’s abstract proposal by filling out the submission form at http://chinog.org/meetings/chi-nog-06/abstract-submission/ . Once your presentation is selected please provide the program committee with your photo and a short bio for web publication. All accepted speakers will receive complimentary tickets to the conference. The program committee is looking forward to your submission and attendance at the conference.

1 0

Automated alarm notification
by Frank Bulk 15 Feb '16

15 Feb '16

Is anyone aware of software, or perhaps a service, that will take SNMP traps, properly parse them, and perform the appropriate call outs based on certain content, after waiting 5 or 10 minutes for any alarms that don't clear? I looked at PagerDuty, but they don't do any SNMP trap parsing, and nothing with set/clear. Frank

10 9

Shared cabinet "security"
by Mike Hammett 15 Feb '16

15 Feb '16

I say "security" because I know that in a shared space, nothing is completely secure. I also know that with enough intent, someone will accomplish whatever they set out to do regarding breaking something of someone else's. My concern is mainly towards mitigation of accidents. This could even apply to a certain degree to things within your own space and your own careless techs If you have multiple entities in a shared space, how can you mitigate the chances of someone doing something (assuming accidentally) to disrupt your operations? I'm thinking accidentally unplug the wrong power cord, patch cord, etc. Accidentally power off or reboot the wrong device. Obviously labels are an easy way to point out to someone that's looking at the right place at the right time. Some devices have a cage around the power cord, but some do not. Any sort of mesh panels you could put on the front\rear of your gear that you would mount with the same rack screw that holds your gear in? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com

12 20

Re: [c-nsp] Cisco Security Advisory: Cisco ASA Software IKEv1 and IKEv2 Buffer Overflow Vulnerability
by Adrian M 15 Feb '16

15 Feb '16

In previous release 9.1(6) this line was ok: nat (inside,outside) source static obj-1.0.0.36_32 obj-1.0.0.36_32 destination static obj-1.0.0.36_32 obj-1.0.0.36_32 In 9.1.(7) wasn't working anymore, so the solution was to add *no-proxy-arp *at the end: nat (inside,outside) source static obj-1.0.0.36_32 obj-1.0.0.36_32 destination static obj-1.0.0.36_32 obj-1.0.0.36_32 *no-proxy-arp* On Mon, Feb 15, 2016 at 1:48 PM, Roberto <roberto(a)ipnetworks.it> wrote: > Hello, > > > > excuse me for this direct email: but about the > https://www.reddit.com/r/networking/comments/433kqx/cisco_asa_not_recording… > > > > " > > upgraded from 9.0(5) to 9.1(7) > > " > > > > Solved ! > > "Disable Proxy ARP" must be checked on NAT bypass rules (former nat 0). > > > > > > > > are you indicating for example > > that previously on 9.0(5) was: > > nat (inside,outside) source static obj-1.0.0.36_32 obj-1.0.0.36_32 > destination static obj-1.0.0.36_32 obj-1.0.0.36_32 route-lookup > > > > and now on 9.1(7) is: > > nat (inside,outside) source static obj-1.0.0.36_32 obj-1.0.0.36_32 > destination static obj-1.0.0.36_32 obj-1.0.0.36_32 *no-proxy-arp* > route-lookup > > > > > > > > > > > > > > Best Regards, > > _________________________________ > > Roberto Taccon > > > > e-mail: roberto(a)ipnetworks.it > > mobile: +39 340 4751352 > > fax: +39 045 4850850 > > skype: roberto.taccon > > > > -----Messaggio originale----- > Da: NANOG [mailto:nanog-bounces@nanog.org] Per conto di Adrian M > Inviato: lunedì 15 febbraio 2016 10.06 > A: nanog(a)nanog.org > Oggetto: Re: [c-nsp] Cisco Security Advisory: Cisco ASA Software IKEv1 and > IKEv2 Buffer Overflow Vulnerability > > > > Solved ! > > "Disable Proxy ARP" must be checked on NAT bypass rules (former nat 0). > > > > On Thu, Feb 11, 2016 at 3:53 PM, Adrian M <adrian.minta(a)gmail.com> wrote: > > > > > Be careful, It appears that something is broken with ARP on this release. > > > We have no ARP on lan interface, and somebody else has a similar problem: > > > > > > https://www.reddit.com/r/networking/comments/433kqx/cisco_asa_not_reco > > > rding_an_arp_entry/ > > > > > > > > > > > > On Wed, Feb 10, 2016 at 10:36 PM, Sadiq Saif <lists(a)sadiqs.com> wrote: > > > > > >> Update your ASAs folks, this is a critical one. > > >> > > >> > > >> -------- Forwarded Message -------- > > >> Subject: [c-nsp] Cisco Security Advisory: Cisco ASA Software IKEv1 > > >> and > > >> IKEv2 Buffer Overflow Vulnerability > > >> Date: Wed, 10 Feb 2016 08:06:51 -0800 > > >> From: Cisco Systems Product Security Incident Response Team > > >> <psirt(a)cisco.com> > > >> Reply-To: psirt(a)cisco.com > > >> To: cisco-nsp(a)puck.nether.net > > >> CC: psirt(a)cisco.com > > >> > > >> Cisco Security Advisory: Cisco ASA Software IKEv1 and IKEv2 Buffer > > >> Overflow Vulnerability > > >> > > >> Advisory ID: cisco-sa-20160210-asa-ike > > >> > > >> Revision 1.0 > > >> > > >> For Public Release 2016 February 10 16:00 GMT (UTC) > > >> > > >> +-------------------------------------------------------------------- > > >> +- > > >> > > >> > > >> Summary > > >> ======= > > >> > > >> A vulnerability in the Internet Key Exchange (IKE) version 1 (v1) and > > >> IKE version 2 (v2) code of Cisco ASA Software could allow an > > >> unauthenticated, remote attacker to cause a reload of the affected > > >> system or to remotely execute code. > > >> > > >> The vulnerability is due to a buffer overflow in the affected code area. > > >> An attacker could exploit this vulnerability by sending crafted UDP > > >> packets to the affected system. An exploit could allow the attacker > > >> to execute arbitrary code and obtain full control of the system or to > > >> cause a reload of the affected system. > > >> > > >> Note: Only traffic directed to the affected system can be used to > > >> exploit this vulnerability. This vulnerability affects systems > > >> configured in routed firewall mode only and in single or multiple > > >> context mode. This vulnerability can be triggered by IPv4 and IPv6 > > >> traffic. > > >> > > >> Cisco has released software updates that address this vulnerability. > > >> This advisory is available at the following link: > > >> > > >> http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/ > > >> cisco-sa-20160210-asa-ike > > >> > > >> > > >> > > >> _______________________________________________ > > >> cisco-nsp mailing list cisco-nsp(a)puck.nether.net > > >> https://puck.nether.net/mailman/listinfo/cisco-nsp > > >> archive at http://puck.nether.net/pipermail/cisco-nsp/ > > >> > > >> > > >> > > > >

1 0

Fiber to the home specialists/consultants?
by Daniel Rohan 15 Feb '16

15 Feb '16

Can anyone point me at a firm that does or consults on FTTH from a technical *and* business perspective? Off-list responses would be appreciated. Thanks, Dan

4 3

Fwd: [c-nsp] Cisco Security Advisory: Cisco ASA Software IKEv1 and IKEv2 Buffer Overflow Vulnerability
by Sadiq Saif 15 Feb '16

15 Feb '16

Update your ASAs folks, this is a critical one. -------- Forwarded Message -------- Subject: [c-nsp] Cisco Security Advisory: Cisco ASA Software IKEv1 and IKEv2 Buffer Overflow Vulnerability Date: Wed, 10 Feb 2016 08:06:51 -0800 From: Cisco Systems Product Security Incident Response Team <psirt(a)cisco.com> Reply-To: psirt(a)cisco.com To: cisco-nsp(a)puck.nether.net CC: psirt(a)cisco.com Cisco Security Advisory: Cisco ASA Software IKEv1 and IKEv2 Buffer Overflow Vulnerability Advisory ID: cisco-sa-20160210-asa-ike Revision 1.0 For Public Release 2016 February 10 16:00 GMT (UTC) +--------------------------------------------------------------------- Summary ======= A vulnerability in the Internet Key Exchange (IKE) version 1 (v1) and IKE version 2 (v2) code of Cisco ASA Software could allow an unauthenticated, remote attacker to cause a reload of the affected system or to remotely execute code. The vulnerability is due to a buffer overflow in the affected code area. An attacker could exploit this vulnerability by sending crafted UDP packets to the affected system. An exploit could allow the attacker to execute arbitrary code and obtain full control of the system or to cause a reload of the affected system. Note: Only traffic directed to the affected system can be used to exploit this vulnerability. This vulnerability affects systems configured in routed firewall mode only and in single or multiple context mode. This vulnerability can be triggered by IPv4 and IPv6 traffic. Cisco has released software updates that address this vulnerability. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-… _______________________________________________ cisco-nsp mailing list cisco-nsp(a)puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/

5 5