Forum - Multiple IPv6 interfaces causes 100% packet loss to :: SixXS

Multiple IPv6 interfaces causes 100% packet loss to

Carmen Sandiego on Saturday, 31 July 2010 04:53:16

Hi there. I have a sixxs interface (sit1) and an he.net interface (sit2). For reasons beyond the scope of this post, he.net is my default route. I keep up my SixXS tunnel so it can remain to ping and gather credits so sometime in the near future I can get a subnet delegated and drop the he.net tunnel/prefix which I'm using for my network. The question is: Since I enabled the he.net tunnel as my default gateway, the packet loss percentage graph for my SixXS tunnel has stated 100% packet loss. Manually pinging my side of the SixXS tunnel from abroad doesn't garner the same results. After further investigation, it seems that the ping response is not sourced through the SixXS tunnel but rather through the HE.net tunnel which the stats seems to think means its not there. 1) Will this cause me to not gain credits? 2) If so, is there any way to fix this? Capturing on the SixXS interface to external pings coming in:

[root@cerberus ~]# tcpdump -s 0 -npvvi sit1 ip6 and proto 58 19:49:49.711784 IP6 (hlim 52, next-header: ICMPv6 (58), length: 64) 2a01:30:100a:0:203:baff:fe2d:6efa > 2001:1938:81:102::2: [icmp6 sum ok] ICMP6, echo request, length 64, seq 0 19:49:50.709236 IP6 (hlim 52, next-header: ICMPv6 (58), length: 64) 2a01:30:100a:0:203:baff:fe2d:6efa > 2001:1938:81:102::2: [icmp6 sum ok] ICMP6, echo request, length 64, seq 1 19:49:51.708851 IP6 (hlim 52, next-header: ICMPv6 (58), length: 64) 2a01:30:100a:0:203:baff:fe2d:6efa > 2001:1938:81:102::2: [icmp6 sum ok] ICMP6, echo request, length 64, seq 2 19:49:52.708894 IP6 (hlim 52, next-header: ICMPv6 (58), length: 64) 2a01:30:100a:0:203:baff:fe2d:6efa > 2001:1938:81:102::2: [icmp6 sum ok] ICMP6, echo request, length 64, seq 3 19:49:53.708888 IP6 (hlim 52, next-header: ICMPv6 (58), length: 64) 2a01:30:100a:0:203:baff:fe2d:6efa > 2001:1938:81:102::2: [icmp6 sum ok] ICMP6, echo request, length 64, seq 4

The response is sent out the he.net tunnel interface, SrcAddr is the SixXS tunnel address as you can see:

[root@cerberus ~]# tcpdump -s 0 -npvvi sit2 ip6 and host 2a01:30:100a:0:203:baff:fe2d:6efa and proto 58 19:49:49.711811 IP6 (hlim 64, next-header: ICMPv6 (58), length: 64) 2001:1938:81:102::2 > 2a01:30:100a:0:203:baff:fe2d:6efa: [icmp6 sum ok] ICMP6, echo reply, length 64, seq 0 19:49:50.709264 IP6 (hlim 64, next-header: ICMPv6 (58), length: 64) 2001:1938:81:102::2 > 2a01:30:100a:0:203:baff:fe2d:6efa: [icmp6 sum ok] ICMP6, echo reply, length 64, seq 1 19:49:51.708878 IP6 (hlim 64, next-header: ICMPv6 (58), length: 64) 2001:1938:81:102::2 > 2a01:30:100a:0:203:baff:fe2d:6efa: [icmp6 sum ok] ICMP6, echo reply, length 64, seq 2 19:49:52.708922 IP6 (hlim 64, next-header: ICMPv6 (58), length: 64) 2001:1938:81:102::2 > 2a01:30:100a:0:203:baff:fe2d:6efa: [icmp6 sum ok] ICMP6, echo reply, length 64, seq 3 19:49:53.708917 IP6 (hlim 64, next-header: ICMPv6 (58), length: 64) 2001:1938:81:102::2 > 2a01:30:100a:0:203:baff:fe2d:6efa: [icmp6 sum ok] ICMP6, echo reply, length 64, seq 4

And finally, my interfaces and routing table:

[root@cerberus ~]# ifconfig sit1 sit1 Link encap:IPv6-in-IPv4 inet6 addr: 2001:1938:81:102::2/64 Scope:Global inet6 addr: fe80::402e:a3e/128 Scope:Link UP POINTOPOINT RUNNING NOARP MTU:1480 Metric:1 RX packets:56 errors:0 dropped:0 overruns:0 frame:0 TX packets:37 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:5824 (5.6 KiB) TX bytes:4636 (4.5 KiB) [root@cerberus ~]# ifconfig sit2 sit2 Link encap:IPv6-in-IPv4 inet6 addr: 2001:470:a:240::2/64 Scope:Global inet6 addr: fe80::402e:a3e/128 Scope:Link UP POINTOPOINT RUNNING NOARP MTU:1480 Metric:1 RX packets:588157 errors:0 dropped:0 overruns:0 frame:0 TX packets:628213 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:265377692 (253.0 MiB) TX bytes:239492609 (228.3 MiB) [root@cerberus ~]# ip -6 ro sh unreachable ::/96 dev lo metric 1024 expires 21273049sec error -101 mtu 16436 advmss 16376 hoplimit 4294967295 unreachable ::ffff:0.0.0.0/96 dev lo metric 1024 expires 21273049sec error -101 mtu 16436 advmss 16376 hoplimit 4294967295 2001:470:a:240::/64 via :: dev sit2 metric 256 expires 21273040sec mtu 1480 advmss 1420 hoplimit 4294967295 2001:470:e86e:80::/64 dev vlan128 metric 256 expires 21273045sec mtu 1500 advmss 1440 hoplimit 4294967295 2001:470:e86e:82::/64 dev vlan130 metric 256 expires 21273049sec mtu 1500 advmss 1440 hoplimit 4294967295 unreachable 2001:470:e86e::/48 dev lo metric 256 expires 21292928sec error -101 mtu 16436 advmss 16376 hoplimit 4294967295 2001:1938:81:102::/64 via :: dev sit1 metric 256 expires 21273040sec mtu 1480 advmss 1420 hoplimit 4294967295 unreachable 2002:a00::/24 dev lo metric 1024 expires 21273049sec error -101 mtu 16436 advmss 16376 hoplimit 4294967295 unreachable 2002:7f00::/24 dev lo metric 1024 expires 21273049sec error -101 mtu 16436 advmss 16376 hoplimit 4294967295 unreachable 2002:a9fe::/32 dev lo metric 1024 expires 21273049sec error -101 mtu 16436 advmss 16376 hoplimit 4294967295 unreachable 2002:ac10::/28 dev lo metric 1024 expires 21273049sec error -101 mtu 16436 advmss 16376 hoplimit 4294967295 unreachable 2002:c0a8::/32 dev lo metric 1024 expires 21273049sec error -101 mtu 16436 advmss 16376 hoplimit 4294967295 unreachable 2002:e000::/19 dev lo metric 1024 expires 21273049sec error -101 mtu 16436 advmss 16376 hoplimit 4294967295 unreachable 3ffe:ffff::/32 dev lo metric 1024 expires 21273049sec error -101 mtu 16436 advmss 16376 hoplimit 4294967295 fe80::/64 via :: dev sit1 metric 256 expires 21273040sec mtu 1480 advmss 1420 hoplimit 4294967295 fe80::/64 via :: dev sit2 metric 256 expires 21273040sec mtu 1480 advmss 1420 hoplimit 4294967295 fe80::/64 dev eth0 metric 256 expires 21273043sec mtu 1500 advmss 1440 hoplimit 4294967295 fe80::/64 dev vlan128 metric 256 expires 21273043sec mtu 1500 advmss 1440 hoplimit 4294967295 fe80::/64 dev vlan130 metric 256 expires 21273045sec mtu 1500 advmss 1440 hoplimit 4294967295 fe80::/64 dev vlan1000 metric 256 expires 21273049sec mtu 1500 advmss 1440 hoplimit 4294967295 unreachable fe80::/64 dev lo metric 256 expires 21292928sec error -101 mtu 16436 advmss 16376 hoplimit 4294967295 default dev sit2 metric 1 expires 21273040sec mtu 1480 advmss 1420 hoplimit 4294967295

Multiple IPv6 interfaces causes 100% packet loss to

Shadow Hawkins on Saturday, 31 July 2010 11:07:49

You need policy routing. * define a routing table echo "200 sixxs" >> /etc/iproute2/rt_tables * fill the table ip route add default via <sixxs_gateway> dev sit1 table sixxs ip route add blackhole <your_sixxs_subnet> dev lo metric 65535 table sixxs * use the table ip -6 rule add from <your_sixxs_tunnelendpoint> table sixxs ip -6 rule add from <your_sixxs_subnet> table sixxs

Multiple IPv6 interfaces causes 100% packet loss to

Shadow Hawkins on Saturday, 31 July 2010 11:23:34

Well, crud. I had a long-ish reply typed up and was going to copy it to clipboard before posting, but I accidentally hit tab and then backspace and lost it anyway. First, try pinging 2001:1938:81:102::1 from cerebus. If that doesn't get a reply, then troubleshoot your tunnel. If it does reply, then add a route. I'm not familiar with the rules the previous poster mentioned; I add mine manually and/or via /etc/network/interfaces. But his example seems to make SixXS the default route which is not what you wanted. The ping IP you show above is an HE address, so that I suppose is not the actual pings sent by SixXS. So you'll have to modify the following for where the SixXS monitor ping is actually originating. Example manual routes: ## Route for just the one address only: /sbin/ip -6 route add 2a01:30:100a:0:203:baff:fe2d:6efa/128 dev sit1 ## Route for the /64, the subnet only /sbin/ip -6 route add 2a01:30:100a::/64 dev sit1 ## Route for the /48, the probable site /sbin/ip -6 route add 2a01:30:100a::/48 dev sit1 ## Route for the /40, the probable organization /sbin/ip -6 route add 2a01:30:1000::/40 dev sit1 I would probably add this to /etc/network/interfaces under iface sit1 : post-up /sbin/ip -6 route add 2a01:30:100a::/48 dev $IFACE || true Except you need to route the prefix where the SixXS ping actually comes from.

Multiple IPv6 interfaces causes 100% packet loss to

Carmen Sandiego on Monday, 02 August 2010 09:48:18

Thanks to both of you for your reply. The tunnel works, I can ping the ::1 side of it ... it seems that the statistics tunnelrobot doesn't ping from ::1 so it's response is subject to the default routing policy. What I think I'll do is try and figure out what address the SixXS tunnelrobot is pinging from and manually add a route (via /etc/network/interfaces) for that address to be routed out the sixxs tunnel interface (for now) until I can just be using SixXS for everything anyways then it'll be moot. Thanks again!

Multiple IPv6 interfaces causes 100% packet loss to

Jeroen Massar SixXS Staff

on Monday, 02 August 2010 10:57:46

Capturing on the SixXS interface to external pings coming in:

[root@cerberus ~]# tcpdump -s 0 -npvvi sit1 ip6 and proto 58

19:49:49.711784 IP6 (hlim 52, next-header: ICMPv6 (58), length: 64) 2a01:30:100a:0:203:baff:fe2d:6efa > 2001:1938:81:102::2: [icmp6 sum ok] ICMP6, echo request, length 64, seq 0

2a01:30:100a:0:203:baff:fe2d:6efa = sun.blazing.de. Which is some 'IPv6 ping site' on the random internet. The 'hlim 52' also indicates that most likely the TTL was 64 and thus the source host is 12 hops away, quite clear that that is thus not the PoP. The PoP will ping you from 2001:1938:81:102::1, that is in this case.

Multiple IPv6 interfaces causes 100% packet loss to

Carmen Sandiego on Monday, 02 August 2010 23:14:35

Which is some 'IPv6 ping site' on the random internet. The 'hlim 52' also indicates that most likely the TTL was 64 and thus the source host is 12 hops away, quite clear that that is thus not the PoP.

I never said that this was the POP. This random ping site was used to demonstrate the routing of ping responses on that interface. Am I incorrect in assuming that pings from 2001:1938:81:102::1 to 2001:1938:81:102::2 would not automatically be routed back through the same interface since it's a connected route? The doesn't seem to be happening. I've had a packet capture on that interface since last night and actually I don't see anything coming in over sit1.

Multiple IPv6 interfaces causes 100% packet loss to

Jeroen Massar SixXS Staff

on Monday, 02 August 2010 23:28:32

If you have properly configured your tunnel you have a more specific route for your tunnel, in your case 2001:1938:81:102::/64, as such the other routes don't take a preference, especially when you have a different default route over a different interface; thus yes there is a big difference. Maybe you should try and configure things properly like everybody else!?

Please note Posting is only allowed when you are logged in.