Bah, here i was writing up this big thing with pastes from my routing table, and examples of how I set my static configurations, and hit preview only to see you just figured out the problem.

Good to hear you solved it

But basically I was going to point out that both machines had default routes pointing to the exact same link-local addresses, and to specify the default gw in a config file.

Actually I wasn't getting that problem to ipv6.he.net with traceroute6 or mtr. I just double-checked right now and its still clean even from the tunnel-server itself. Can you retest?

Code:

1  gige-g4-6.core1.lon1.he.net  0.378 ms  0.246 ms  0.137 ms
 2  10gigabitethernet2-3.core1.nyc4.he.net  69.463 ms  69.275 ms  69.308 ms
 3  10gigabitethernet3-1.core1.sjc2.he.net  148.919 ms  148.485 ms  148.567 ms
 4  gige-g1-1.core1.fmt1.he.net  148.874 ms  148.994 ms  148.897 ms
 5  ipv6.he.net  148.875 ms  148.983 ms  149.038 ms

Ok, they got their London peering with us fixed. I notice with a quick tunnel created that traceroute6 seems to kinda stop inside Google's network after their first hop. Running mtr behind the same tunnel gets a different result and actually reaches the site with 1 hop inside Google's network that has no results (just * * *). My guess is that Google is doing something with the traffic which would be outside of our control.

FYI, contacted Google about this and our peering session in London. Waiting to hear back from them regarding this, so I don't have an ETA on a resolution right now.

Well address assignment on the interfaces looks fine, but I don't see any pastes of the routing table on either system.

What is the output from netstat -rn -A inet6 on both machines?

Also one appears to be virutalized, or is that the actual server and not something virutalized?

We don't test on the live tunnel-servers, other than to verify connectivity through them.

The current platform has an issue that we are trying to work out before rolling out a new update. This involves working with vendors, and will take more time until everything is sorted. Until then, we continue to monitor the tunnel-servers and work to resolve connectivity issues for tunnelbroker.net users when they arise.

What IPv6 addresses are configured on the machines?
Are you using RADVD/DHCPv6 or statically assigning those addresses?
Are both machines running the same Linux platform? Kernel?

I see the working machine trace through "1f0f:1ce::2" and the other machine attempt through "1f0f:1ce::1". What IP from your routed /64 is configured on the Cisco interface that for your LAN? That should always be the same IP (and generally "::1").

Poked them some more, and they promised more information for us by Weds. next week, about finalizing the exchange connection. 

You should use the routed /64 we auto-allocate to you for your LAN. You can then use something like RADVD to let your hosts on the LAN autconfigure themselves.

Please retest. The issue is now resolved.

As always, please EMAIL bugs you encounter to ipv6@he.net

If you are reporting an issue with the program, please do so via email at ipv6@he.net as this address is monitored by the Hurricane Electric ticketing system and will result in a much faster response time.

Working on something like this, just working out the logistics.

fixed those to be /10 instead of /8

I think you need a new network map....   

http://www.he.net/Hurricane_Electric_Geographic_Network_Map.jpg

I'm certain once the other remaining 2 locations go live, then whomever made the image will update it.

[*REMINDER*]

The Toronto tunnel-server is now live and available to choose when creating a tunnel. Again if you would like your existing account to use one of the new tunnel-servers, you can create an additional tunnel or delete your existing tunnel then pick the new location to create your tunnel on.

*REMINDER* - Deleting your old tunnel means deallocating your IPv6 blocks, and you will be assigned NEW allocations based on the tunnel server you pick.