Miami Tunnelbroker location, IPv6 'pauses'

[cd34]

I'm using the Miami location for my tunnel, and during the middle of the day, IPv6 'pauses'. This happens whether I use interface gif0 on my macbook, or, using openwrt (whiterussian, will retest kamakaze).

Brief network diagram:

Bellsouth/AT&T DSL (not uVerse which filters protocol41) -> WRT160Nv2 -> WRT54GS (openwrt) -> macbook

MTUs on both WRTs are set to Auto (defaults to 1500) and my macbook has it's own IP address set out of the routed block. The behavior experienced is sites loaded over IPv6 get a partial pageload - even those that are 2 hops from the Miami Tunnelbroker site (we buy gigE from HE.Net in Miami), but, the problem occurs on tunnelbroker.net, google.com (using HE.net's IPv6 resolvers that are in the Google network test), www.v6.facebook.com, or any IPv6 site we host. Interruption is usually noted for 45-60 seconds, at which point things go back to normal speed.

telnet to port 80, GET / HTTP/1.0, results in small pages doing fine, larger pages partially loading.

When it happens, I have switched to the Wifi on WRT160Nv2, and started my gif0 tunnel, and the problem is able to be duplicated. I don't see the issue when using a /128 from our Arin allocated block at the data center, which would suggest a problem either on my side with one of the tunnels (macbook or openwrt), or the tunnelserver might be overloaded at some point. I've not tried the gif0 tunnel at the data center to see if I can duplicate it.

It isn't a frequent event, but, when using youtube, videos fail to stream at points, or hang after 30-50 seconds. After a few minutes, things go back to being quick. During an event, IPv4 performance is fine, though, that isn't a great test as those take separate routes. During the day, the problem is more frequent.

Are there issues in Miami that might be causing this? i.e. route reconfigurations as new tunnels are instantiated, etc? Any hints to troubleshoot? tcpdump doesn't really show much other than no traffic received during the period that the browser experiences the partial pageload.  Letting it sit will usually allow the page to load, or, after 45+ seconds, reloading the page usually results in the page loading as expected.

Anyone else in the Miami Tunnelserver seeing similar issues?

[cholzhauer]

About a year ago I had problems with Google services on the Chicago tunnel.  This went on for about a month until it mysteriously fixed itself; I haven't had a problem since.

FWIW everything I've read on the boards says the tunnel servers are no where near capacity.

[cd34]

I just upgraded to openwrt-backfire but haven't really had enough surfing to see if the problem persists. There is one bug report on kamikaze that may be related.

I didn't figure the tunnelservers were at capacity, but, was thinking what I might have been seeing is lag during route reconfiguration or something that was external to me since all sites were affected and I saw it both on the gif0 tunnel and on the openwrt tunnel. Looking at my config, it is possible when I switched between the two, the gif0 tunnel wasn't properly deleted as the script appears to incorrectly call ifconfig delete. It is possible that may have created a loop on my laptop. I've removed the gif0 completely, rebooted, and am running through the WRT54GS right now and it appears to be stable.

[cd34]

Worked fine until about 10 minutes ago, then, this site, www.v6.facebook.com and a few locally hosted sites started doing it again.

Moving back to the gif0 tunnel and will run with that today to see if the issue is something in openwrt causing the problem. Looking at tcpdump at the time one of the sites was having an issue, there was traffic being passed, but, the page wasn't rendering.  Reloading a few times got the page to come through.

[cd34]

Running all day on the gif0 interface. Somehow, latency has dropped about 40ms per ping - I believe he.net opened up a new route with AT&T or something, or, perhaps the return path is now better than it was before. The traceroute in looks almost identical.

In any case, ipv4 to a destination is 12-14ms, ipv6 to the same destination is 40-44ms, which is a decent improvement over last week when I was about 130-140ms away from the same destination over IPv6.

Will continue testing today.

[cd34]

In the past 24 hours, one event, which appeared to be related to he.net/AT&T flap as I got a circular route even on IPv4 to the tunnelserver, so, I'm reasonably convinced the issue is related to either my WRT54GS, openwrt or the network here at the house.

tcpdump does see packets during an event, so, it is a bit odd, but, will go back to testing that as it makes for a more usable IPv6 experience.

[cholzhauer]

I was running openwrt on my WRT54G for a while and ran into issues where my router would randomly reboot and flake out. I flashed to DDWRT and haven't had a problem since.

[cd34]

I actually couldn't get DD-WRT/IPv6 to work correctly on my WRT54GS (revision 1.0 hardware), but, will try that again today. Right now, using the suggested version for my router , lsmod reports an in-use of -1 on ipv6 - and even configuring the tunnel by hand results in no ipv6 settings being accepted. I've doublechecked the modules, they match the kernel version, so, something still isn't right.

Just had 193ms pings over ipv6 using gif0, 14ms pings via IPv4 to same destination - event lasted about 30 seconds.