• Welcome to Hurricane Electric's IPv6 Tunnel Broker Forums.

tserv13.ash1.ipv6.he.net

Started by albyva, June 26, 2012, 12:22:56 PM

Previous topic - Next topic

albyva



Is anybody having any odd issue with tserv13.ash1.ipv6.he.net? Just today my v6 link,
which was running smoothly, died. All my settings look good, but nothing seems to work.
I even killed my gif0 interface (running FreeBSD) and rebuilt it and nothing changed.


URL: http://godzilla.empire.org/gif0.html


It seems like all routing for my /64 via HE.NET is working fine. There just seems to be
some issue with the tunnel itself. Ugh!!!...


kasperd

Quote from: albyva on June 26, 2012, 12:22:56 PMIt seems like all routing for my /64 via HE.NET is working fine. There just seems to be
some issue with the tunnel itself.
Could you explain what problem you are seeing?

What do you do to see that there is a problem? What is the result? What did you expect to happen?

Jim Whitby

I've similar problems with tserv2.ash1.ipv6.net.

I've been blaming my Dlink 825, but maybe not.

The tunnel just drops. It *appears* up in the Dlink status screen, but using looking glass at lg.he.net the link is non-existent. Traceroute stops at
tserv2.ash1.he.net (2001:470:0:90::2),

Rebooting the Dlink ( sometimes twice  ) will bring the tunnel back up.

This has been occurring for about 3 weeks.

I have recently been running a ping6 every 30 minutes to try and find a pattern. So far I haven't found one.

Is there anyway to find out for sure where the problem lies?

Should I open a trouble ticket?

kasperd

Quote from: Jim  Whitby on June 28, 2012, 11:12:43 AMRebooting the Dlink ( sometimes twice  ) will bring the tunnel back up.
Such a tunnel is stateless. No communication is needed between the two endpoints after a reboot. Which means most likely the tunnel server would have no way of even knowing that your route was rebooted. If it really is rebooting of your router, which makes the problem go away, then chances are it is a problem with the router.

It might be that the router is trying to do connection tracking and runs out of memory and is unable to deal gracefully with that. Of course since it isn't supposed to do NAT when you are using an IPv6 tunnel, there is no need for connection tracking in the first place.

Quote from: Jim  Whitby on June 28, 2012, 11:12:43 AMThis has been occurring for about 3 weeks.
So it started around 6th of June? Maybe the amount of IPv6 traffic you are doing just increased at that time. Which DNS server are you using?

Quote from: Jim  Whitby on June 28, 2012, 11:12:43 AMI have recently been running a ping6 every 30 minutes to try and find a pattern. So far I haven't found one.

Is there anyway to find out for sure where the problem lies?
Running tcpdump simultaneously on both sides of your router should reveal if the problem is that your router starts dropping packets. Running tcpdump on the outside of the router can be tricky. I have done it myself using a Linux machine configured to bridge between two Ethernet interfaces. If your router has a builtin modem of some sort, and is not using Ethernet on the outside, then dumping traffic on the outside gets more tricky.

Another approach is to setup not just one but two tunnels on your router using different tunnel servers. Then if both goes down at exactly the same time, it is an indication that the problem is with your router. If both tunnels go down periodically but not at the same time, then it might still be your router. But if only one of the tunnels go down, you won't know if it is a problem with the tunnel server, or if it is related to that tunnel being used more.

Since your router might not even support two tunnels, and since you will need to use a tunnel server at a different provider for the other tunnel, and since it isn't going to give a very clear answer about the location of the problem, I admit setting up two tunnels isn't the best way to go about debugging the problem.

Quote from: Jim  Whitby on June 28, 2012, 11:12:43 AMShould I open a trouble ticket?
Personally I'd like to collect more data before I open a ticket. I'd like to be sure the problem is really in the HE systems, or at least that there is a high probability the problem is in the HE systems and further investigation requires access to those systems.

I don't know if there is a policy about how much data you should collect before you open a ticket. Previous messages in the forum seems to imply you shouldn't hesitate to file a ticket. But currently my guess is that the problem is with your router.

Jim Whitby

It appears the problem is in fact in the router.

Even though the router ( Dlink-825 ) thinks its up and running, I can't ping the gateway ( 2001:470:7:XXXX::2 ).
I can ping the local link address.

Reboot cures it.

In any case it is the router, I'm sure.



Jim Whitby

It appears I shouldn't be using the dmz function on the router and the router's tunnel functions.

Having removed the dmz and used port forwarding, everything is working properly.