Opened 6 years ago

Closed 6 years ago

Last modified 5 weeks ago

#454 closed request (worksforme)

Netalyzr Results

Reported by: eburger@… Owned by: bzeeb+ietf@…
Priority: tbd Milestone: ietf-083
Component: network Keywords:
Cc: Bill Fenner, nweaver@… My Current Location:
My MAC Address: My OS:

Description (last modified by Bill Fenner)

I ran the ICSI Netalyzr, and also came up with the IPv6 frag problem. See <http://n3.netalyzr.icsi.berkeley.edu/restore/id=ae81b058-26597-5a57e9a6-381d-45df-8fcd/rd>. It also detected a 3 second drop.

untitled-part.html

smime.p7s

Attachments (2)

untitled-part.html (446 bytes) - added by eburger@… 6 years ago.
Added by email2trac
smime.p7s (4.8 KB) - added by eburger@… 6 years ago.
Added by email2trac

Download all attachments as: .zip

Change history (13)

Changed 6 years ago by eburger@…

Attachment: untitled-part.html added

Added by email2trac

Changed 6 years ago by eburger@…

Attachment: smime.p7s added

Added by email2trac

comment:1 Changed 6 years ago by bzeeb+ietf@…

Component: incomingnetwork
Owner: changed from llynch@… to bzeeb+ietf@…
Status: newassigned

We had seen the IPv6 frag issue and believe it's a false positive given other tests could not reproduce it for us last week during bring-up.
I have just sent the question to the netalyzr mailing list asking for further details.

With regard to the 3 second outage, I'll have to look into that.

comment:2 Changed 6 years ago by Bill Fenner

Nick Weaver is looking into the apparently-false-positive IPv6 fragmentation report. An example test to run at the cli is, e.g.,

traceroute6 2607:f740:b:0:0:0:0:f93 2000

which tests both IPv6 fragments and IPv6 traceroute.

comment:3 Changed 6 years ago by Bill Fenner

Cc: Bill Fenner added

comment:4 Changed 6 years ago by Bill Fenner

Nick just replied:

It looks like the server side path-MTU traceroute server was down/crashed. Its been problematic, it was in an auto-relaunch loop but apparently that failed.

I've restarted it manually, and I'm now attempting to validate whether this is working or not.

I'm in the hotel, trying to help look at wireless issues here, so Eric, if you're still in the Palais, if you could re-try that'd be great.

comment:5 Changed 6 years ago by anonymous

That exact similar command worked for me on Wed/Thu? when we first discovered this and still does. Can we rule out a host firewall on the testing client?

comment:6 in reply to:  5 Changed 6 years ago by Bill Fenner

Cc: nweaver@… added
Description: modified (diff)

Replying to anonymous:

That exact similar command worked for me on Wed/Thu? when we first discovered this and still does. Can we rule out a host firewall on the testing client?

Who is anonymous?

There's apparently a server involved that was not running; Nick restarted it and is asking for someone to re-test. I can't, because the wireless where I am is useless.

comment:7 Changed 6 years ago by anonymous

I went back to the Palais to re-run a test. It looks like things are working again. The only problem reported now is 310ms TCP setup time, which could be wireless latency plus inter-continental latency.

http://netalyzr.icsi.berkeley.edu/restore/id=43ca253f-13512-3a6cc05c-a005-4bff-8649

IPv6 Path MTU:

Your system can send and receive fragmented traffic with IPv6.
The path between your network and our system supports an MTU of at least 1496 bytes. The path between our system and your network has an MTU of 1500 bytes.

IPv6 Traceroute:

It takes 12 network hops for IPv6 traffic to pass from our IPv6 server to your system, as shown below. For each hop, the time it takes to traverse it is shown in parentheses.

  1. 2607:f740:b::1 (0 ms)
  2. 2607:f108:300::6 (0 ms)
  3. 2001:1900:4:2::29d (0 ms)
  4. vl-70.car2.Washington1.Level3.net (1 ms)
  5. vl-4061.car1.NewYork2.Level3.net (6 ms)
  6. vl-4041.car1.NewYork1.Level3.net (6 ms)
  7. 2001:1900:19:8::8 (56 ms)
  8. FranceTelecom-level3-10g.NewYork1.Level3.net (8 ms)
  9. po0-9-0-0.auvtr1.Aubervilliers.opentransit.net (85 ms)
  10. te0-5-0-7.pastr1.Pastourelle.opentransit.net (87 ms)
  11. te13-1.passe1.Pastourelle.opentransit.net (83 ms)
  12. 2001:688:0:3:4::66 (83 ms)

(I do wonder if "The path between your network and our system" value is a measurement error; it seems unlikely that it is not 1500 bytes)

comment:8 Changed 6 years ago by Bill Fenner

Oh, now I see how easy it is to add a comment without realizing you're anonymous! Grrr....

comment:9 Changed 6 years ago by nweaver@…

OK, it looks like what happened is one of our Netalyzr services crashed, and that was causing Netalyzr to falsely report a fragmentation issue.

And the 'your network and our system' is an 'at least': thats the size of the first fragment received by our server in that test. We can't do detailed path MTU probing from the client to the server since that requires raw packet access.

If this problem returns, please contact me and I'll try to fix it, and apologies for the false positive due to an error in our code.

comment:10 Changed 6 years ago by bzeeb+ietf@…

Resolution: worksforme
Status: assignedclosed

Thanks for your help to solve the mystery:)

comment:11 Changed 5 weeks ago by Rick Alfvin

Milestone: ietf-83ietf-083

Milestone renamed

Note: See TracTickets for help on using tickets.