|
Statistics reporting 400% loss
![[nl]](/s/countries/nl.gif) Shadow Hawkins on Monday, 11 October 2010 13:15:49
Hi all,
I'm having a strange problem (since 1.5 day).
The SixXS statistics from nlams05 report a loss of 400%. I tried a distributed tracert to my endpoint and that is reachable.
The strangest thing is, that a latency of 10 - 15 ms is reported. So the PoP's endpoint is able to ping my endpoint, but it reports a 400% loss.
Also no ISK's are added this week.
Can someone tell me what is wrong?
Kind regards,
Ralph.
Statistics reporting 400% loss
It seems your host is answering every packet 4 times.... what is your Operating System + AICCU version etc?
Statistics reporting 400% loss
Shadow Hawkins on Monday, 11 October 2010 18:34:24
Hi Jeroen,
thanks for your reply. I'm running a version of Debian Lenny in VMWare. The version of aiccu is: AICCU 2007.01.15-console-linux by Jeroen Massar
The ip6tables firewall is configured like this (in a script):
#!/bin/sh -e
# stel de firewall in
# default policies
ip6tables -P INPUT DROP
ip6tables -P FORWARD DROP
ip6tables -P OUTPUT ACCEPT
# reset configuratie
ip6tables -F
# zorg dat iedereen (en dus ook de PoP) mij kan pingen
ip6tables -A INPUT -p ipv6-icmp -j ACCEPT
# ik moet zelf via IPv6 weg kunnen (onderstaande staat het antwoord toe, OUTPUT is standaard ACCEPT)
ip6tables -A INPUT -i sixxs -m state --state RELATED,ESTABLISHED -j ACCEPT
# het interne netwerk is 'vertrouwd'
ip6tables -A INPUT -i eth0 -j ACCEPT
ip6tables -A INPUT -i lo -j ACCEPT
# rest mag niet
ip6tables -A INPUT -j REJECT --reject-with icmp6-port-unreachable
# zet onderstaande regel aan als de interne hosts gepingt mogen worden
#ip6tables -A FORWARD -p ipv6-icmp -j ACCEPT
# zorg dat iedereen van binnen naar buiten kan
ip6tables -A FORWARD -i eth0 -j ACCEPT
ip6tables -A FORWARD -i sixxs -m state --state RELATED,ESTABLISHED -j ACCEPT
#ip6tables -A FORWARD -i lo -j ACCEPT
#ip6tables -A FORWARD -j REJECT --reject-with icmp6-port-unreachable
echo "IPv6 firewall is configured"
exit 0
aiccu /autotest reports this:
#######
####### AICCU Quick Connectivity Test
#######
####### [1/8] Ping the IPv4 Local/Your Outer Endpoint (192.168.0.166)
### This should return so called 'echo replies'
### If it doesn't then check your firewall settings
### Your local endpoint should always be pingable
### It could also indicate problems with your IPv4 stack
PING 192.168.0.166 (192.168.0.166) 56(84) bytes of data.
64 bytes from 192.168.0.166: icmp_seq=1 ttl=64 time=0.017 ms
64 bytes from 192.168.0.166: icmp_seq=2 ttl=64 time=0.024 ms
64 bytes from 192.168.0.166: icmp_seq=3 ttl=64 time=0.023 ms
--- 192.168.0.166 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1998ms
rtt min/avg/max/mdev = 0.017/0.021/0.024/0.004 ms
######
####### [2/8] Ping the IPv4 Remote/PoP Outer Endpoint (192.87.102.107)
### These pings should reach the PoP and come back to you
### In case there are problems along the route between your
### host and the PoP this could not return replies
### Check your firewall settings if problems occur
PING 192.87.102.107 (192.87.102.107) 56(84) bytes of data.
From 192.168.0.7: icmp_seq=1 Redirect Network(New nexthop: 192.168.0.100)
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst Data
4 5 00 5400 0000 0 0040 3f 01 9853 192.168.0.166 192.87.102.107
64 bytes from 192.87.102.107: icmp_seq=1 ttl=56 time=8.52 ms
64 bytes from 192.87.102.107: icmp_seq=1 ttl=55 time=8.52 ms (DUP!)
64 bytes from 192.87.102.107: icmp_seq=1 ttl=56 time=8.76 ms (DUP!)
64 bytes from 192.87.102.107: icmp_seq=1 ttl=55 time=8.76 ms (DUP!)
From 192.168.0.7: icmp_seq=2 Redirect Network(New nexthop: 192.168.0.100)
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst Data
4 5 00 5400 0000 0 0040 3f 01 9853 192.168.0.166 192.87.102.107
64 bytes from 192.87.102.107: icmp_seq=2 ttl=56 time=11.2 ms
64 bytes from 192.87.102.107: icmp_seq=2 ttl=55 time=11.2 ms (DUP!)
64 bytes from 192.87.102.107: icmp_seq=2 ttl=56 time=11.2 ms (DUP!)
64 bytes from 192.87.102.107: icmp_seq=2 ttl=55 time=11.2 ms (DUP!)
From 192.168.0.7: icmp_seq=3 Redirect Network(New nexthop: 192.168.0.100)
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst Data
4 5 00 5400 0000 0 0040 3f 01 9853 192.168.0.166 192.87.102.107
64 bytes from 192.87.102.107: icmp_seq=3 ttl=56 time=11.7 ms
--- 192.87.102.107 ping statistics ---
3 packets transmitted, 3 received, +6 duplicates, 0% packet loss, time 2013ms
rtt min/avg/max/mdev = 8.523/10.126/11.701/1.345 ms
######
####### [3/8] Traceroute to the PoP (192.87.102.107) over IPv4
### This traceroute should reach the PoP
### In case this traceroute fails then you have no connectivity
### to the PoP and this is most probably the problem
traceroute to 192.87.102.107 (192.87.102.107), 30 hops max, 40 byte packets
1 gw.ontwikkeling.lokaal (192.168.0.100) 0.626 ms 0.730 ms 0.824 ms
2 gw.ontwikkeling.lokaal (192.168.0.100) 0.937 ms 1.521 ms 1.780 ms
3 10.223.40.1 (10.223.40.1) 10.593 ms 10.427 ms 10.085 ms
4 csw2-vlan202.tilbu1.nb.home.nl (213.51.150.193) 10.738 ms asd-tr0409-cr101-ae5-0.core.as9143.net (213.51.158.154) 21.866 ms 21.449 ms
5 asd-tr0409-cr101-ae5-0.core.as9143.net (213.51.158.154) 21.687 ms asd-tr0409-ds101-po2.core.as9143.net (213.51.158.157) 20.943 ms 20.532 ms
6 asd-tr0409-ds101-po2.core.as9143.net (213.51.158.157) 20.667 ms 17.658 ms 17.532 ms
7 private-surfnet-as1103.core.as9143.net (213.51.156.22) 17.747 ms 17.971 ms 17.451 ms
8 AE2.500.JNR01.Asd001A.surf.net (145.145.80.78) 17.694 ms 10.739 ms V1131.sw4.amsterdam1.surf.net (145.145.19.170) 10.392 ms
9 v1131.sw4.amsterdam1.surf.net (145.145.19.170) 10.531 ms sixxs.surfnet.nl (192.87.102.107) 11.323 ms 11.217 ms
######
###### [4/8] Checking if we can ping IPv6 localhost (::1)
### This confirms if your IPv6 is working
### If ::1 doesn't reply then something is wrong with your IPv6 stack
PING ::1(::1) 56 data bytes
64 bytes from ::1: icmp_seq=1 ttl=64 time=0.099 ms
64 bytes from ::1: icmp_seq=2 ttl=64 time=0.060 ms
64 bytes from ::1: icmp_seq=3 ttl=64 time=0.069 ms
--- ::1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 0.060/0.076/0.099/0.016 ms
######
###### [5/8] Ping the IPv6 Local/Your Inner Tunnel Endpoint (2001:610:600:76e::2)
### This confirms that your tunnel is configured
### If it doesn't reply then check your interface and routing tables
PING 2001:610:600:76e::2(2001:610:600:76e::2) 56 data bytes
64 bytes from 2001:610:600:76e::2: icmp_seq=1 ttl=64 time=0.028 ms
64 bytes from 2001:610:600:76e::2: icmp_seq=2 ttl=64 time=0.053 ms
64 bytes from 2001:610:600:76e::2: icmp_seq=3 ttl=64 time=0.056 ms
--- 2001:610:600:76e::2 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1998ms
rtt min/avg/max/mdev = 0.028/0.045/0.056/0.014 ms
######
###### [6/8] Ping the IPv6 Remote/PoP Inner Tunnel Endpoint (2001:610:600:76e::1)
### This confirms the reachability of the other side of the tunnel
### If it doesn't reply then check your interface and routing tables
### Don't forget to check your firewall of course
### If the previous test was succesful then this could be both
### a firewalling and a routing/interface problem
PING 2001:610:600:76e::1(2001:610:600:76e::1) 56 data bytes
64 bytes from 2001:610:600:76e::1: icmp_seq=1 ttl=64 time=11.8 ms
64 bytes from 2001:610:600:76e::1: icmp_seq=1 ttl=64 time=11.8 ms (DUP!)
64 bytes from 2001:610:600:76e::1: icmp_seq=1 ttl=64 time=12.0 ms (DUP!)
64 bytes from 2001:610:600:76e::1: icmp_seq=1 ttl=64 time=12.1 ms (DUP!)
64 bytes from 2001:610:600:76e::1: icmp_seq=2 ttl=64 time=10.1 ms
64 bytes from 2001:610:600:76e::1: icmp_seq=2 ttl=64 time=10.1 ms (DUP!)
64 bytes from 2001:610:600:76e::1: icmp_seq=2 ttl=64 time=10.5 ms (DUP!)
64 bytes from 2001:610:600:76e::1: icmp_seq=2 ttl=64 time=10.6 ms (DUP!)
64 bytes from 2001:610:600:76e::1: icmp_seq=3 ttl=64 time=10.2 ms
--- 2001:610:600:76e::1 ping statistics ---
3 packets transmitted, 3 received, +6 duplicates, 0% packet loss, time 2011ms
rtt min/avg/max/mdev = 10.142/11.070/12.109/0.840 ms
######
###### [7/8] Traceroute6 to the central SixXS machine (noc.sixxs.net)
### This confirms that you can reach the central machine of SixXS
### If that one is reachable you should be able to reach most IPv6 destinations
### Also check http://www.sixxs.net/ipv6calc/ which should show an IPv6 connection
### If your browser supports IPv6 and uses it of course.
traceroute to noc.sixxs.net (2001:838:1:1:210:dcff:fe20:7c7c), 30 hops max, 40 byte packets
1 gw-1903.ams-05.nl.sixxs.net (2001:610:600:76e::1) 12.837 ms 13.486 ms 14.170 ms
2 vl163.sw14.amsterdam1.surf.net (2001:610:1:80bb:192:87:102:97) 15.141 ms 22.305 ms 22.591 ms
3 2001:610:f01:9168::169 (2001:610:f01:9168::169) 22.604 ms 22.788 ms 22.802 ms
4 AE0.500.JNR02.Asd001A.surf.net (2001:610:e08:76::77) 22.810 ms 23.010 ms 23.024 ms
5 ams-ix.ipv6.concepts.nl (2001:7f8:1::a501:2871:1) 23.031 ms 23.217 ms 23.229 ms
6 2001:838:5:a::2 (2001:838:5:a::2) 23.238 ms 13.876 ms 12.879 ms
7 noc.sixxs.net (2001:838:1:1:210:dcff:fe20:7c7c) 17.478 ms 17.882 ms 18.147 ms
######
###### [8/8] Traceroute6 to (www.kame.net)
### This confirms that you can reach a Japanese IPv6 destination
### If that one is reachable you should be able to reach most IPv6 destinations
### You should also check http://www.kame.net which should display
### a animated kame (turtle), of course only when your browser supports and uses IPv6
traceroute to www.kame.net (2001:200:dff:fff1:216:3eff:feb1:44d7), 30 hops max, 40 byte packets
1 gw-1903.ams-05.nl.sixxs.net (2001:610:600:76e::1) 13.494 ms * *
2 vl163.sw14.amsterdam1.surf.net (2001:610:1:80bb:192:87:102:97) 14.134 ms 14.245 ms 14.378 ms
3 2001:610:f01:9168::169 (2001:610:f01:9168::169) 14.782 ms 14.884 ms 15.670 ms
4 ae0.500.jnr02.asd001a.surf.net (2001:610:e08:76::77) 15.808 ms 15.705 ms 16.060 ms
5 surfnet.rt1.ams.nl.geant2.net (2001:798:22:10aa::1) 16.139 ms 16.732 ms 16.970 ms
6 so-6-2-0.rt1.fra.de.geant2.net (2001:798:cc:1401:2201::1) 24.135 ms 17.166 ms 17.171 ms
7 abilene-wash-gw.rt1.fra.de.geant2.net (2001:798:14:10aa::12) 110.383 ms 110.368 ms 113.420 ms
8 2001:468:ff:109::1 (2001:468:ff:109::1) 164.735 ms 164.017 ms 163.937 ms
9 xe-1-0-0.0.rtr.hous.net.internet2.edu (2001:468:ff:1c2::1) 150.242 ms 150.333 ms 150.309 ms
10 2001:468:ff:305::2 (2001:468:ff:305::2) 184.197 ms 184.421 ms 179.925 ms
11 2001:200:e000:853::2d11:2 (2001:200:e000:853::2d11:2) 288.001 ms 288.447 ms 289.212 ms
12 tpr5-ge0-1-0-36.jp.apan.net (2001:200:e000:36::5) 289.490 ms 288.874 ms 290.377 ms
13 2001:200:133::8e (2001:200:133::8e) 461.982 ms 462.210 ms 450.119 ms
14 ve44.foundry6.otemachi.wide.ad.jp (2001:200:0:10::141) 289.859 ms 290.097 ms 287.150 ms
15 ve42.foundry4.nezu.wide.ad.jp (2001:200:0:11::66) 291.268 ms 291.737 ms 290.117 ms
16 cloud-net1.wide.ad.jp (2001:200:0:1c0a:218:8bff:fe43:d1d0) 290.090 ms 288.933 ms 288.983 ms
17 2001:200:dff:fff1:216:3eff:feb1:44d7 (2001:200:dff:fff1:216:3eff:feb1:44d7) 290.279 ms 294.158 ms 287.493 ms
######
###### ACCU Quick Connectivity Test (done)
### Either the above all works and gives no problems
### or it shows you where what goes wrong
### Check the SixXS FAQ (http://www.sixxs.net/faq/
### for more information and possible solutions or hints
### Don't forget to check the Forums (http://www.sixxs.net/forum/)
### for a helping hand.
### Passing the output of 'aiccu autotest >aiccu.log' is a good idea.
This all works fine. Also my Windows 'clients' in my subnet have IPv6 connectivity.
Can you please guide me in figuring out why the 400% loss is reported, although a normal latency is reported?
Kind regards,
Ralph.
Statistics reporting 400% loss
PING 192.87.102.107 (192.87.102.107) 56(84) bytes of data. From 192.168.0.7: icmp_seq=1 Redirect Network(New nexthop: 192.168.0.100) Vr HL TOS Len ID Flg off TTL Pro cks Src Dst Data 4 5 00 5400 0000 0 0040 3f 01 9853 192.168.0.166 192.87.102.107 64 bytes from 192.87.102.107: icmp_seq=1 ttl=56 time=8.52 ms 64 bytes from 192.87.102.107: icmp_seq=1 ttl=55 time=8.52 ms (DUP!) 64 bytes from 192.87.102.107: icmp_seq=1 ttl=56 time=8.76 ms (DUP!) 64 bytes from 192.87.102.107: icmp_seq=1 ttl=55 time=8.76 ms (DUP!) [..]
Can you please guide me in figuring out why the 400% loss is reported, although a normal latency is reported?
As you are replying to every packet 4 times... some kind of box in your network is causing that, it might be vmware, it might be your gateway.
Which host is 192.168.0.7 and what is 192.168.0.100?
Seems you have a rather strange network setup.
Statistics reporting 400% loss
Shadow Hawkins on Monday, 11 October 2010 21:27:07
Hi Jeroen,
thanks for helping me out again. You got me on the right track and the problem seems to be solved.
192.168.0.7 is the (client)machine hosting the VM. 192.168.0.100 is my (IPv6) router.
At first I started out with aiccu on my Windows client, but it turned out that the subnet was not routed by the Windows version of aiccu. So I set up a Debian VM to be my router and restored the setting of my Windows machine.
So I thought... I forgot to disable IP-forwaring and it seems that was the culprit. So I disabled it, rebooted the Windows machine (of course) and started the VM. Performed a ping and no DUP! was echo'ed.
The reported loss dropped to 200%. I'll check in an hour again to see if everything is normal again.
Thanks again for helping out. I think you guys are doing a really great job!
Best regards,
Ralph.
Statistics reporting 400% loss
Shadow Hawkins on Monday, 11 October 2010 21:28:54
Sorry: my 192.168.0.100 is not my IPv6 router of course, but my IPv4 router
|
![[ch]](/s/countries/ch.gif)
on Monday, 11 October 2010 15:59:50
Posting is only allowed when you are