Ticket ID: SIXXS #954873 Ticket Status: User PoP: dedus01 - SpeedPartner GmbH (Duesseldorf)
Tunnel went down at 9am this morning
Shadow Hawkins on Wednesday, 28 January 2009 15:59:17
I have read and followed the "Reporting Problems" section on the Contact page and am providing the following details for this report based on the list of items stated there:
I created a new tunnel yesterday that worked perfectly until approximately 9am this morning.
No configuration changes were made, rather I simply noticed that the tunnel statistics page showed that my tunnel was no longer able to be pinged.
I can also no longer ping the POP over IPv6 from my server.
Details -
NIC - DB7729-RIPE
Tunnel - T19454
POP - dedus01
Host IP v6 - 2a01:198:200:341::2
Host IP v4 - 78.47.170.25
This tunnel is running on a Debian Etch installation.
I can ping the IPv4 address of the pop (91.184.37.98) without problems from my server.
Using the SIXXS system, I can ping my IPv4 address from the POP - see here
IPv4 & IPv6 firewall rules are empty.
ip(6)tables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Strangely, with tcpdump, I can see the pings from the POP to my server and the replies being sent.
tcpdump -i eth0 ip proto 41 -n -s 1500 | grep echo
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 1500 bytes
14:34:11.035611 IP 91.184.37.98 > 78.47.170.25: IP6 2a01:198:200:341::1 > 2a01:198:200:341::2: ICMP6, echo request, seq 8195, length 64
14:34:11.035642 IP 88.198.38.247 > 91.184.37.98: IP6 2a01:198:200:341::2 > 2a01:198:200:341::1: ICMP6, echo reply, seq 8195, length 64
14:34:26.907500 IP 91.184.37.98 > 78.47.170.25: IP6 2a01:198:200:341::1 > 2a01:198:200:341::2: ICMP6, echo request, seq 8195, length 64
14:34:26.907529 IP 88.198.38.247 > 91.184.37.98: IP6 2a01:198:200:341::2 > 2a01:198:200:341::1: ICMP6, echo reply, seq 8195, length 64
.....
My pings to the POP are not returned however.
14:40:02.461136 IP 88.198.38.247 > 91.184.37.98: IP6 2a01:198:200:341::2 > 2a01:198:200:341::1: ICMP6, echo request, seq 1, length 64
14:40:03.462284 IP 88.198.38.247 > 91.184.37.98: IP6 2a01:198:200:341::2 > 2a01:198:200:341::1: ICMP6, echo request, seq 2, length 64
My IPv4 pings to the POP show that IPv4 routes are okay.
My IPv6 routing table is below and seems to also be okay.
route --inet6
Kernel IPv6 routing table
Destination Next Hop Flags Metric Ref Use Iface
::1/128 :: U 0 917 3 lo
2a01:198:200:341::2/128 :: U 0 100 1 lo
2a01:198:200:341::/64 :: U 256 111 0 sixxs
fe80::4e2f:aa19/128 :: U 0 0 1 lo
fe80::4e2f:aa1a/128 :: U 0 0 1 lo
fe80::4e2f:aa1b/128 :: U 0 0 1 lo
fe80::4e2f:aa1c/128 :: U 0 0 1 lo
fe80::4e2f:aa1e/128 :: U 0 0 1 lo
fe80::58c6:26f7/128 :: U 0 0 1 lo
fe80::213:d3ff:fea8:49fe/128 :: U 0 0 1 lo
fe80::/64 :: U 256 0 0 eth0
fe80::/64 :: U 256 0 0 sixxs
ff00::/8 :: U 256 0 0 eth0
ff00::/8 :: U 256 0 0 sixxs
::/0 2a01:198:200:341::1 UG 1024 1758 0 sixxs
It must be stressed that no configuration changes were made to this machine at all between when it was working yesterday and stopped working this morning.
I would be very grateful for any advice on how this problem could be resolved.
Thanks in advance,
David
State change: user
Jeroen Massar on Wednesday, 28 January 2009 17:09:00
The state of this ticket has been changed to user
Tunnel went down at 9am this morning
Jeroen Massar on Wednesday, 28 January 2009 17:10:17 14:34:11.035611 IP 91.184.37.98 > 78.47.170.25: IP6 2a01:198:200:341::1 > 2a01:198:200:341::2: ICMP6, echo request, seq 8195, length 64
91.184.37.98 = dedus01, 78.47.170.25 = your endpoint
14:34:11.035642 IP 88.198.38.247 > 91.184.37.98: IP6 2a01:198:200:341::2 > 2a01:198:200:341::1: ICMP6, echo reply, seq 8195, length 64
But what is 88.198.38.247 doing there replying to packets?
Please fix your setup.
Tunnel went down at 9am this morning
Shadow Hawkins on Wednesday, 28 January 2009 18:08:41
Well spotted, thank you for your help with this.
My server has multiple IP addresses, so I have resolved the issue by forcing all traffic to the POP to be sourced from the relevant IP address.
In case this information may be of value to someone else -
ip route add POPADDRESS via GATEWAYADDRESS src SOURCEIPADDRESS
I don't know why the problem only originated at 9am, but it is solved now.
Thank you for your help,
David
Tunnel went down at 9am this morning
Jeroen Massar on Wednesday, 28 January 2009 18:09:48
Or you could just use the 'local' setting for the static tunnel.
(ip tunnel set local <your local ip> dev <devicename>'
Tunnel went down at 9am this morning
Shadow Hawkins on Wednesday, 28 January 2009 18:19:40
A much cleaner solution, thank you.
I added the following statement to my /etc/network/interfaces file -
local [My IPv4 Endpoint]
Might I suggest that this line be added to the example given here to avoid possible future issues for other users?
Thanks again,
David
Tunnel went down at 9am this morning
Jeroen Massar on Wednesday, 28 January 2009 18:23:25
The FAQ entries and especially the examples in the setup cases cover COMMON examples. Most users have one IP address on their host and don't have that issue.
If we add that option there, a lot of people will not know what to fill in or will fill in wrong things which will break even more things...
If you are setting up multiple IP addresses on your host, you most likely and hopefully also read the documentation about the problems what comes along with it.
Posting is only allowed when you are logged in. |