- NANOG - lists.nanog.org

Agoda GeoIP issue
by Vireak Ouk 18 Feb '16

18 Feb '16

Greetings from Cambodia Could anyone from Agoda contact me off-list? It's regarding some discrepancies of Agoda rates which could be caused by GeoIP isse. We had tried to report via the normal means but to no avail. Thanks in advance. Vireak

1 0

re: PCH Peering Paper
by Livingood, Jason 18 Feb '16

18 Feb '16

How does it look when you examine it by not the count of sessions or links but by the volume of overall data? I wonder if it may change a little like 50% of the volume of traffic is covered by a handshake. (I made 50% up - could be any percentage.) Jason PS - My email address has changed and I’m trying to send a 3rd time. Apologies if they all suddenly post to the list as duplicates! :-) >On 2/10/16, 6:34 PM, "NANOG on behalf of Patrick W. Gilmore" ><nanog-bounces(a)nanog.org on behalf of patrick(a)ianai.net> wrote: > >>I quoted a PCH peering paper at the Peering Track. (Not violating rules, >>talking about myself.) >> >>The paper is: >> https://www.pch.net/resources/Papers/peering-survey/PCH-Peering-Survey-2 >>0 >>11.pdf >> >>I said ³99.97%² of all peering sessions have nothing behind them more >>than a ³handshake² or an email. It seems I was in error. Mea Culpa. >> >>The number in the paper, on page one is, 99.52%. >> >>Hopefully everyone will read the paper, and perhaps help create better >>data. >> >>-- >>TTFN, >>patrick >> >> >

6 8

Equinix Chicago Cross COnnects
by Mike Hammett 17 Feb '16

17 Feb '16

Yes, another post in this ballpark. I am remembering someone telling me that cross connects from CH3 (Elk Grove Village) to CH1, CH2 or CH4 were not raw glass, but some sort of transport. I lose the details, whether it was wave transport, MPLS or something. I remember the speed of the connection mattering. My Equinix rep tells me that there is no difference from one to the other. I take that to mean that I could put my own wave system on the glass and be fine. I just have a very hard time believing them, based on what I remember and the fact that they've giving me a 25 - 30 mile pair of glass for $350/month. I was hoping to see if anyone else had any experience in this department. Equinix Cermak apparently today has zero available cabinets of any kind in CH1, CH2 or CH4. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com

1 0

Looking for docs on "A" RR duality of functions
by Octavio Alvarez 17 Feb '16

17 Feb '16

Hi. Do you know if there are any docs (RFC, drafts, independent...) that study the tricks being done with the A/AAAA RRs? What I mean is that it is currently being used not only to resolve the IP address of a hostname, but for load-balancing as well, the case being that the hostname is not just a "host"-name anymore, but a "service"-name (?) so to speak. I'd like to know if somebody else has gone deeper into this and if there are related documents on the matter. Thanks.

2 1

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