- NANOG - lists.nanog.org

Re: packet loss question
by Ken Chase 07 Jul '16

07 Jul '16

On Thu, Jul 07, 2016 at 08:32:19PM +0000, Mel Beckman said: >Yes. It indicates that there was never a time when you did not know everything :) > > -mel beckman The issue isnt knowing everything, it's making accusations of issues while you still dont know how much you dont know. (~D. Rumsfeld) -- My customers in a nutshell (they pay to be able to yell about random stuff I guess, and I provide that service!). The OP didnt make any accusations however, and just asked what was going on (sorry if I sounded harsh in reply). Once, Google having a 8.8.8.8 failure locally on its (anycast?) dns servers resulted in dozens of calls to us "your server hosting our site must be down!! Our website isnt working! People are calling us!". Most of my work is with these situations is spent proving it's not our fault. Mtr makes it very hard because it's a very subtle tool, and only gives partial information. (I still think mtr is a killer app though!) consider this (fake, example) trace: 6. 100ge13-1.core1.chi1.he.net 0.0% 10 7. 100ge14-1.core2.chi1.he.net 0.0% 10 8. 100ge3-1.core1.sjc2.he.net 30.0% 10 9. ??? 10. UNKNOWN-216-115-101-X.yahoo.com 10.0% 10 11. routerer-ext.ysv.freebsd.org 20.0% 10 12. wfe0.ysv.freebsd.org 30.0% 10 First off, the OP may have asked "who's fault is hop 9, yahoo or HE?" and seen it as an issue. Ignoring that for now, the rest of the packetloss is an issue -- where is the problem though? This is very tricky - it looks like hop 8 is at fault of course - or is it just dropping ICMP as it's allowed to? How did hop 10 get only 10% loss then if 8 has 30? Is 8 then dropping ~20% (not statistically correct..) of ICMP just cuz it can, and then having a 'real' 10% loss on top of that? Or it's hop 11? But hop 12 has more PL, perhaps hop 12 is the issue all along and 8 10 and 11 are just dropping ICMP? Or it's 8, 11 and 12 doing ~10% each? (not statistically correct.) Can't say for sure - it's a probabilities game - and being completely correct about it, hop 6 isn't blameless either (just very unlikely to be at fault statistically, though not impossible with only 10 pings per hop - a statistician can calculate it for us). This is why more pings are required to be sure of the situation - I like to do -i 0.1 -c 100 so it's completed quickly before conditions change. Then you can make a statistically valid pronouncement of where the problem MIGHT BE within a useful confidence interval - however, without the return route we're still largely in the dark as to the actual location of the issue. You cant be '100% sure' with this stuff - technically speaking, it's all 'luck of the draw'. (Beware: this one time, at band camp, some etherchannel or equiv at HE was showing PL only for specific ips in any target subnet -- because they were xor'ing the source & target IP to load balance and one channel was wonky. Fun times debugging that one: "WFM from here, what's your issue?") /kc -- Ken Chase - ken(a)heavycomputing.ca skype:kenchase23 +1 416 897 6284 Toronto Canada Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front St. W.

3 2

google routing noc/looking glass/contact
by Joe Maimon 07 Jul '16

07 Jul '16

I would appreciate it if anyone could put me in touch or send me any tips to deal with packet loss and problems routing to google, but only along certain paths from certain points in the network (like as in ecmp problems) from as21719 I would like to rule out local issues if possible and that would certainly help. Joe

1 0

New ICANN registrant change process
by Jay R. Ashworth 07 Jul '16

07 Jul '16

I'll go ahead and assume I wasn't the last person to get this memo (courtesy Lauren Weinstein's PRIVACY Digest): https://opensrs.com/blog/2016/06/icanns-new-transfer-policy-will-impact-bus… It does seem that this is going to make life difficult for a bunch of pretty normal business processes. If you didn't know about it either... ask yourself why not. Cheers, -- jra -- Jay R. Ashworth Baylink jra(a)baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274

9 16

Experience on Wanguard for 'anti' DDOS solutions
by Marcel Duregards 06 Jul '16

06 Jul '16

Dear Nogers, We are currently evaluating some DDOS detection/mitigation solutions. Do you have any inputs/experiences on Wanguard from Andrisoft, please ?https://www.andrisoft.com/software/wanguard Currently we are just interested on the packets/flows sensors with the console for detection and RTBH trigger. Maybe the packet filtering (for scrubbing) will come later. Best Regards,-Marcel Duregards

14 16

Re: NAT firewall for IPv6?
by Scott Weeks 05 Jul '16

05 Jul '16

--- sethm(a)rollernet.us wrote: From: Seth Mattinen <sethm(a)rollernet.us> On 7/1/16 19:28, Edgar Carver wrote: > Hello NANOG community. I was directed here > by our network administrator since she is > on vacation. Luckily, I minored in Computer > Science so I have some familiarity. :: This is not legit, ya'll are being trolled. -------------------------------------------- Luckily, I can't imagine having such a sh!++y life that this is seen as fun. Apparently, the high school kids got tired of ordering pizza to the next door neighbors house and watching them get mad. scott

1 0

Office 365
by Ryan Finnesey 05 Jul '16

05 Jul '16

I was hoping to touch base with providers that are offering office 365 or would like to offer office 365. Please ping me off list I have a few questions. Cheers Ryan

1 0

Re: NAT firewall for IPv6?
by J Edgar Carver 05 Jul '16

05 Jul '16

On Fri, 1 Jul 2016 21:28:54 -0500 Edgar Carver <dredgarcarver(a)gmail.com> wrote: > Hello NANOG community. I was directed here by our network administrator > since she is on vacation. Luckily, I minored in Computer Science so I have > some familiarity. Luckily! > router. Or, ideally, is there an easy way to turn off IPv6 completely? I > really don't see a need for it, any legitimate service should have an IPv4 > address. Obvious troll is obvious after we just spent a week on this ...

1 0

Gmail down
by Josh Luthman 05 Jul '16

05 Jul '16

Web interface is broken, downdetector sure sees activity. This attempt is from mobile. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373

14 21

Recommendations for used satellite decoder resellers
by Jason Lixfeld 05 Jul '16

05 Jul '16

Hello, I’m wondering if anyone can refer me to a company they’ve used in the past who may have (access to) used satellite decoder equipment. I’m in the market for some used Sencore kit. Thanks in advance!

2 1

RE: IPv6 deployment excuses - IPv6 only resources
by Jacques Latour 04 Jul '16

04 Jul '16

Is there a list of IPv6 only ISP or services? I'd be curious to trend that somehow, by geography, service type, etc... if any. >-----Original Message----- >From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Mark Andrews >Sent: July-04-16 9:49 AM >To: Matt Hoppes >Cc: Tore Anderson; nanog(a)nanog.org >Subject: Re: IPv6 deployment excuses > > >In message <B9CDA0F3-AE6F-435D-9904- >C2AE05BCCCCB(a)rivervalleyinternet.net>, Matt Hoppes writes: >> I disagree. Any data center or hosting provider is going to continue >> to offer IPv4 lest they island themselves from subscribers who have >> IPv4 only - which no data center is going to do. >> >> One can not run IPv6 only because there are sites that are only IPv4. >> >> Thus, as an ISP you can safely continue to run IPv4. Ipv4 won't be >> going away for at least ten years or more - if ever. >> >> I'm not saying don't be ready for IPv6. I'm not saying don't >> understand how it works. But doomsday isn't here. > >There are ISP's that are essentially IPv6 only today as they do not have enough >IPv4 addresses to give all their customers a public >IPv4 address. > >Once you need to run a GGN you may as well run DS-Lite, MAP* or >(shudder) DNS64/NAT64 as NAT444. There is no need to talk IPv4 to your >customers today. You still need a small number of IPv4 address to talk to >legacy IPv4 servers on the internet. Just because there owners don't know they >are legacy servers doesn't mean they aren't. > >Mark >-- >Mark Andrews, ISC >1 Seymour St., Dundas Valley, NSW 2117, Australia >PHONE: +61 2 9871 4742 INTERNET: marka(a)isc.org

2 1