Hi,

On Fri, Jan 28, 2005 at 09:29:06PM +0100, Gert Doering wrote:
> After comparing the gif/gre sources for a number of hours, to see whether
> GRE does something differently than GIF, I decided to actually test it
> with GIF.  The problem is the same!  (Sparc64, NetBSD-current as of Jan 27).

Michael v. Elst has done some more tests, and the results seem to point
at "it's specific to Sparc64, but not to -current" (reproduction on
NetBSD/i386-1.6.2 and NetBSD/amiga-2.0 was not possible, but as soon
as one tunnel end is NetBSD/sparc64, timings start being weird).

I've repeated my tests with Sparc64/2.0.1 (same tunnel setup), and the
result is the same - ping across the tunnel has weird timings.  

This is how things look if I ping from NetBSD:

16 bytes from 2001:608:4:5555::1, icmp_seq=0 hlim=64 time=1005.55 ms
16 bytes from 2001:608:4:5555::1, icmp_seq=1 hlim=64 time=6.067 ms
16 bytes from 2001:608:4:5555::1, icmp_seq=2 hlim=64 time=491.48 ms
16 bytes from 2001:608:4:5555::1, icmp_seq=3 hlim=64 time=466.519 ms
16 bytes from 2001:608:4:5555::1, icmp_seq=4 hlim=64 time=464.901 ms
16 bytes from 2001:608:4:5555::1, icmp_seq=5 hlim=64 time=1005.23 ms
16 bytes from 2001:608:4:5555::1, icmp_seq=6 hlim=64 time=5.414 ms

and this is ping from Cisco:

cisco2514#ping 2001:608:4:5555::2 repeat 5

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:608:4:5555::2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/536/992 ms


gert

PS: the NetBSD tunnel configuration I've posted has IPv6 and IPv4 addresses
configured as "inside" addresses.  The IPv4 address is a testing leftover,
and is not relevant.  Effect stays the same with IPv6 only.

-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert@greenie.muc.de
fax: +49-89-35655025                        gert@net.informatik.tu-muenchen.de