|
tunnel problem with endpoint and subnet
![[se]](/s/countries/se.gif) Shadow Hawkins on Wednesday, 28 September 2011 21:17:53
I also posted this as ticket 5643334.
I have two sixxs-tunnel points with full reachability (both works for general use with IPv6). They are T17188 and T23503 on the same pop (sesto01).
Yesterday I changed the IPv4 endpoint (changed IPv4 address and network) on T17188, and update the tunnel for SixXS accordingly. It seems to work fine, still with full functionality between the sixxs points.
On T23503 I have the subnet R9947. This subnet cannot reach T17188 at all over IPv6. However, the rest of IPv6 space seems to work fine for the clients on the subnet. The only problems I have is the the connectivity between the subnet and the remote endpoint.
What is happening here? Should I change anything more, is there something bad happening at the pop, or what could it be?
This is the traceroute from R9947 to T17188:
tracetwobot$~>traceroute 2001:16d8:ff00:2a9::2
traceroute to 2001:16d8:ff00:2a9::2 (2001:16d8:ff00:2a9::2), 30 hops max, 80 byte packets
1 2001:16d8:cc4f:1001::1 (2001:16d8:cc4f:1001::1) 0.314 ms 0.304 ms 0.461 ms
2 gw-883.sto-01.se.sixxs.net (2001:16d8:ff00:372::1) 2.871 ms 3.410 ms 3.780 ms
3 * * *
On T17188 this is the routing table:
Kernel IPv6 routing table
Destination Next Hop Flag Met Ref Use If
2001:16d8:cc4f:1001::/64 :: U 256 0 0 br0
2001:16d8:ff00:2a9::/64 :: Un 256 0 1 sixxs
fe80::/64 :: U 256 0 0 br0
fe80::/64 :: Un 256 0 0 sixxs
::/0 2001:16d8:ff00:2a9::1 UG 1024 0 0 sixxs
::/0 :: !n -1 1 18981 lo
::1/128 :: Un 0 2 5910 lo
2001:16d8:cc4f:1001::2002/128 :: Un 0 1 8 lo
2001:16d8:ff00:2a9::2/128 :: Un 0 1 17253 lo
fe80::d573:d19/128 :: Un 0 1 0 lo
fe80::230:48ff:fed1:9646/128 :: Un 0 1 0 lo
ff00::/8 :: U 256 0 0 br0
ff00::/8 :: U 256 0 0 sixxs
::/0 :: !n -1 1 18981 lo
And on one of the machines on the subnet R9947 the routing table is like this:
twobot$~>sudo route -6
Kernel IPv6 routing table
Destination Next Hop Flag Met Ref Use If
2001:16d8:cc4f:1001::/64 :: Ue 256 0 11854 br0
2001:16d8:cc4f:1002::/64 :: U 256 0 0 eth0
fe80::/64 :: U 256 0 0 eth0
fe80::/64 :: U 256 0 0 br0
fe80::/64 :: U 256 0 0 vnet0
::/0 fe80::20c:42ff:fe3e:8832 UGDAe 1024 0 0 br0
::/0 :: !n -1 1264520 lo
::1/128 :: Un 0 1 44338 lo
2001:16d8:cc4f:1001::2002/128 :: Un 0 1546195 lo
2001:16d8:cc4f:1001:226:18ff:feaa:62a0/128 :: Un 0 11715621 lo
2001:16d8:cc4f:1002::2002/128 :: Un 0 1 0 lo
fe80::226:18ff:feaa:62a0/128 :: Un 0 1 42904 lo
fe80::226:18ff:feaa:7b23/128 :: Un 0 1 0 lo
fe80::fcad:beff:feef:c0a5/128 :: Un 0 1 0 lo
ff00::/8 :: U 256 0 0 eth0
ff00::/8 :: U 256 0 0 br0
ff00::/8 :: U 256 0 0 vnet0
::/0 :: !n -1 1264520 lo
tunnel problem with endpoint and subnet
Where is the routing table view for the host terminating T23503?
You might want to peek at 'ip -6 ro show" instead of the ancient route command.
Also 'ip -6 ro get <destination address>' is useful to see where a packet gets sent from (the source address that that host would use) and over/to which interface/adress it is sent.
2001:16d8:cc4f:1001::2002/128 seems to exist on both your T17188 host and on the host where you list your R9947, how come?
As your traceroute shows:
1 2001:16d8:cc4f:1001::1 (2001:16d8:cc4f:1001::1) 0.314 ms 0.304 ms 0.461 ms
A host inside R9947, I assume the address of your gateway/tunnel endpoint, but that is odd, as there is only 2001:16d8:cc4f:1001::2002 in your routing table.
Which is why that big yellow/orange box asks for the interfaces list too, as that reveals which address is where.
on that host, so where is 2001:16d8:cc4f:1001::1 located?
Also what is the source address of the traceroute?
2 gw-883.sto-01.se.sixxs.net (2001:16d8:ff00:372::1) 2.871 ms 3.410 ms 3.780 ms
Gateway of T23503 on the PoP, makes sense.
3 * * *
No response from the next hop, which normally would be the 2001:16d8:ff00:372::1 on the other side.
As you didn't show a routing nor an interface table for that one, it is only to wonder why packets are not being send back...
tunnel problem with endpoint and subnet
Shadow Hawkins on Thursday, 29 September 2011 11:13:59
This is fixed. And it was a very stupid mistake that I could really learn from.
And you were right in your first assumption. The address existed on both sides. This was due to a copy&paste error (you should never do that without reading every address at least three times...). So, everything worked after this address was removed.
tunnel problem with endpoint and subnet
This is fixed. And it was a very stupid mistake that I could really learn from.
Nothing stupid, and mistakes are there to be made so one can learn and not make them again and that is one great thing about playing with IPv6.
Can you detail what went wrong and how you determined this and of course what you changed so that it is resolved?
tunnel problem with endpoint and subnet
Shadow Hawkins on Thursday, 29 September 2011 20:31:42
While moving my server to a new location I prepared to make use of a bridged interface for virtualization. So I copied the config from another bridge configuration forgetting to remove the following line from my br0 interface in /etc/network/interfaces
up ifconfig br0 add 2001:16d8:cc4f:1001::2002/64
The reason I forgot to remove it and did not think much about it is that my AICCU configuration was not anywhere in the interfaces file. And when later looking at the interfaces I did not really look at the addresses in there, since IPv6 worked in general.
It first dawned on me when I was doing the configuration of my virtual servers that I did not have a subnet for IPv6, but only using AICCU, and immediately reviewed the interfaces file. Seeing the same IPv6 address as in the subnet I was using... Removing it from the bridge configuration was quick and easy, and everything worked. And then I read your reply stating the obvious. Had I look at that from the beginning I wouldn't have wasted so much time. :)
tunnel problem with endpoint and subnet
Copy and paste is a proper source for these kind of issues; but you won't be making this mistake for quite some time to come now ;)
And I hope it explains why we ask for those interfaces/routing tables etc, as there can always be something that one overlooks.
|
![[ch]](/s/countries/ch.gif)
on Thursday, 29 September 2011 09:12:08
Posting is only allowed when you are