Hurricane Electric's IPv6 Tunnel Broker Forums

Advanced search  


Welcome to Hurricane Electric's forums!

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - rdk

Pages: [1]
IPv6 on Linux & BSD & Mac / Re: IPv6 tunnel delays, CentOS 7
« on: January 18, 2018, 04:11:37 PM »

I placed a port-mirroring switch between my centos/linux router and my AT&T modem.

After capturing tunnel traffic, I have concluded that the delay is NOT being introduced by my CentOS/Linux router.  The delay is being introduced either by the modem or by AT&T backbone.  Most likely, its the modem.



IPv6 on Linux & BSD & Mac / IPv6 tunnel delays, CentOS 7
« on: December 24, 2017, 01:14:02 PM »

I recently changed way too many variables and now my IPv6 HE tunnel has very very high delay (~750 ms).

I changed ISPs from Charter to AT&T for fiber speeds and I built a new router and installed Centos 7 (was FC17).

Tunnel is up and working but when I ping across it, I see delays on order of 750ms.

IPv4 traceroute to my tunnel endpoint shows 38ms delay.

IPv4 traceroute to my tunnel endpoint with proto=41 shows delay about 30ms.

This leads me to conclude that its something getting groked in my CentOS7 box.

Any suggestions or pointers as to what might be causing these large delays?  My configuration is fairly similar to my old box.  One small change though is that my external interface is a non-routable subnet to my modem.  I don't believe my modem is introducing the delays because of the traceroute data above.




Yes, I can ping6 the website in question so i believe the ipv6 route to/from works.  I can telnet port 80 to the website address and get back a proxy error when I don't tell the proxy which host I'm trying to reach.

I did some experimenting on a windows pc with selectively changing bytes in the static ipv6 host portion. 

The host's original static IPv6 address was 2001:470:e499:2::75  That system was not able to connect to the webserver.

When I changed the ipv6 address to 2001:470:e499:2:200:200:0:0:75, it was able to connect to the website.

2001:470:e499:2:2000:2000:0:75 fails

2011:470:e499:2:0:1:0:75 works

Lots of other variants worked, didnt work, etc.  I couldnt really discern a pattern based on the IPv6 addressing constraints that I'm aware of.

Also, the router I'm using is a linux box I've built/configured and am routing through my HE ipv6 tunnel.




I've been struggling to understand this for a few days now.

I have an HE IPv6 tunnel and its really nice.  (Thanks by the way).

I have a /48 and use a mixture of autoconf and static IPv6 addresses.

I noticed the other day that I could not get to website from my desktop.  I dug further and it appears that incapsula is blocking my queries.  I have a static IPv6 address 2001:470:e499:1::7b

On a windows 10 PC, I have a EUI-64 or privacy/autoconf IPv6 address.  It could talk just fine to the t-mobile website via my HE tunnel.

As soon as I configured the windows 10 box to use a static assigned IPv6 address  2001:470:e499:2::75 and not the autoconf one, the t-mobile website stopped responding.  When I re-enabled autoconf address on this box, started working again.

From other devices in my network (ipads, linux laptops, android phones), I can get to the t-mobile website.  These devices all have auto-configured IPv6 addresses.

t-mobile's website is behind an incapsula proxy of some sort.

Why would incapsula block some IPv6 addresses in my net and not others?  Seems like a strange security parameter or setting.

Note that I can ping6 any of these ipv6 website addresses and they respond so I don't believe its a IP-layer issue.

Same goes for trying to connect to -- blocks static ipv6 addresses, allows dynamic ipv6 addresses.  They won't respond to support emails since I'm not a customer.  And, would not be fun to try to get through the phalanx of support people at t-mobile to get them to explain whats going on either.

Hoping some folks in HE land have heard of this.

I can post data to back up my hypothesis if need be.



Pages: [1]