IPv6 tunnel over vDSL

[Kokel]

Hello Guys,

I'm From germany and since I got my new vDSL connection I have a bandwidth, probably MTU problem with my IPv6 Tunnel.

My Setup:

VDSL Modem Speedport 300HS --> MikroTik Routerboard 450G

The MikroTik does the pppoe dial and my MTU setup looks as follows:

Interface ether1(uplink to vdsl modem): 1500 (L2MTU 1522)
Interface VDSL(just a vlan interface, my provider expects pppoe packet in vlan 7): 1500 (L2MTU 1516)
Interface ppp: max mtu: 1492; max mru 1492

Before I changed to VDSL I got a adsl2+ connection and nearly the same setup(without vlan interface) but no problem with my IPv6 he.net tunnel.
Since I changed to VDSL the downstream bandwidth decreased to 10 KiB/s, but it has to be at about 5 MiB/s.

Anyone here with similar problems or hints to get this problem solved?

Please help me,

Greetz,

Kokel

MikroTik export code:

/interface ethernet
set 0 arp=enabled auto-negotiation=yes bandwidth=unlimited/unlimited comment=\
   "Uplink to DSL Modem" disabled=no full-duplex=yes l2mtu=1520 mac-address=\
   00:0C:42:AF:49:B1 master-port=none mtu=1500 name=ether1 speed=100Mbps

/interface vlan
add arp=enabled comment="vid 7 for Telekom VDSL2" disabled=no interface=ether1 l2mtu=1516 \
   mtu=1500 name=VDSL2 use-service-tag=no vlan-id=7

/interface pppoe-client
add ac-name="" add-default-route=yes allow=pap,chap comment="T-Online PPP Dial" \
   dial-on-demand=no disabled=no interface=VDSL2 max-mru=1492 max-mtu=1492 mrru=disabled \
   name=T-Online password=xxxxxx profile=default service-name="" use-peer-dns=no user=\
   xxxxxxxxxxxxxx@t-online.de

/interface 6to4
add comment="he.net 6in4 Tunnel" disabled=no local-address=xxx.xxx.xxx.xxx mtu=1280 name=sit1 \
   remote-address=216.66.80.30

/ipv6 address
add address=2001:470:1f0a:17c0::2/64 advertise=no comment="Tunnelinterface he.net" \
   disabled=no eui-64=no interface=sit1

[Kokel]

Nobody any suggestions? Problem isn't solved yet.

Thanks,

Kokel

[packetmail]

At the risk of being wrong (fellow HE friends please correct me if this is indeed the case), it is my understanding that:

You take the Ethernet default MTU of 1500 bytes.  PPPoE overhead takes about 8 bytes.  An IPv6 6in4 tunnel takes another 20 bytes.  Your ppp0 MTU of 1492 reflects the 8 bytes of PPPoE overhead.

An MTU of 1280 is too low which likely explains your poor performance.  You want an MTU of 1472.

I'm ADSL2+ and that's what I did.  I'm away from my configuration and going from memory for something I setup nearly a year ago so please forgive me.  My 6in4 router/firewall is Ubuntu GNU/Linux 2.6.32.

Cheers!

[Kokel]

Thanks for your reply packetmail,

right know I'm not quite sure it's a mtu problem anymore. Because with my adsl2+ connection there was no bandwidth problem with quite the same mtu parameters.
I run wireshark on the outgoing interface of my router and when I download a big file there are a lot of duplicate acknowledgements, retransmission and window updates.
So maybe a TCP Problem. I tested it with ubuntu 11.04 and windows 7. pcap file is attached.

I don't get why I have this problem since I got the vDSL connection. Are here any users of Telekom Germany with a vDSL connection?

Greetz, kokel

[packetmail]

Kokel, thank you for your reply.  I do think you have MTU issues but I am not certain if it is the root issue.

For example, below is my HE 6in4 tunnel configuration for a ADSL2+ DSL line using PPPoE:

Code Select Expand


$ ifconfig -a
eth1      Link encap:Ethernet  HWaddr 00:a0:8e:22:5a:84 
          inet addr:192.168.1.4  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: 2001:db8:8::1/64 Scope:Global
          inet6 addr: fe80::/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1492  Metric:1
          RX packets:33256 errors:0 dropped:0 overruns:0 frame:0
          TX packets:32633 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:9889560 (9.8 MB)  TX bytes:5535918 (5.5 MB)

eth2      Link encap:Ethernet  HWaddr 00:a0:8e:22:5a:85 
          inet6 addr: fe80::/64 Scope:Link
          UP BROADCAST RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:65427 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:15350421 (15.3 MB)

eth3      Link encap:Ethernet  HWaddr 00:a0:8e:22:5a:83 
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

he-ipv6   Link encap:IPv6-in-IPv4 
          inet6 addr: 2001:db8:7::2/64 Scope:Global
          inet6 addr: 2001:db8:8::2/64 Scope:Global
          inet6 addr: fe80::c0a8:104/128 Scope:Link
          UP POINTOPOINT RUNNING NOARP  MTU:1472  Metric:1
          RX packets:3301 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3022 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:2295363 (2.2 MB)  TX bytes:263271 (263.2 KB)

lo        Link encap:Local Loopback 
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

sit0      Link encap:IPv6-in-IPv4 
          NOARP  MTU:1480  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)


I am using an MTU of 1472 as described as 1500 - 8 bytes PPPoE overhead - 20 bytes 6in4 overhead.  It works well and maximizes my MTU.  Since IPv6 cannot be fragmented as a MTU of 1280 is the *minimum* acceptable MTU for IPv6 I believe by setting this to 1280 you are degrading performance.  Perhaps this is exacerbated by the faster vDSL speeds.

Perhaps you have PMTU issues?  Have you tried http://test-ipv6.com to see if there are any bad findings?

Cheers and good luck!

[Kokel]

So, these are the results from test-ipv6.com:

Test with IPv4 DNS record
ok (1.155s) using ipv4
http://ipv4.test-ipv6.com/ip/?callback=?
   
Fetches an object that has just an A record in DNS. This is expected to use IPv4. IPv6-only users might still reach this, if their provider has employed a NAT64/DNS64 or proxy solution.
Test with IPv6 DNS record
ok (1.867s) using ipv6
http://ipv6.test-ipv6.com/ip/?callback=?
   
Fetches an object that has just an AAAA record in DNS. This is expected to use IPv6. Users not yet on the IPv6 Internet are likely to see this fail. As long as it fails quickly, it will be OK - for now.
Test with Dual Stack DNS record
ok (0.813s) using ipv6
http://ds.test-ipv6.com/ip/?callback=?
   
This is the most important test. This verifies your browser can connect to a site that has both IPv4 and IPv6 records published. IPv4 only hosts should connect fine (using IPv4).

If this test fails or times out, you can expect major problems as publishers start offering their sites on IPv6.
Test for Dual Stack DNS and large packet
ok (1.403s) using ipv6
http://ds.test-ipv6.com/ip/?callback=?&size=1600&fill=xxx...xxx
   
Validates that you can connect to a dual-stack server (like the ds test); and that you can send/receive large packets on that connection. If this test times out for any reason, it indicates trouble for World IPv6 Day.
Test IPv4 without DNS
ok (1.531s) using ipv4
http://216.218.228.114/ip/?callback=?
   
This will try connecting with a literal IPv4 numeric address. This should work for most people, unless they are running IPv6-only. If the first test worked, but this fails, it likely confirms your provider is using NAT64/DNS64; you'll need to only try connecting using hostnames instead of numeric IP addresses.
Test IPv6 without DNS
ok (0.342s) using ipv6
http://[2001:470:1:18::114]:80/ip/?callback=?
   
This will try connecting with a literal IPv6 hexadecimal address. The primary purpose of this test is to separate out your connectivity on IPv6 from your ability to fetch DNS for it. A secondary purpose is to see if you have Teredo enabled; some systems may only use Teredo when an IPv6 address is in the URL.
Test IPv6 large packet
ok (0.343s) using ipv6
http://ipv6.test-ipv6.com/ip/?callback=?&size=1600&fill=xxx...xxx
   
Validates that IPv6 requests with large packets work. If this test times out, but other IPv6 tests work, it suggests that there may be PMTUD issues; possibly involving IP tunnels.
Test if your ISP's DNS server uses IPv6
timeout (14.998s)
http://ds.v6ns.test-ipv6.com/ip/?callback=?
(This is bonus credit)
   
This is a test of your ISP's resolver (instead of a test of your host). If this test passes, your DNS server (often run by your ISP) is capable of reaching IPV6-only DNS authoritative servers on the Internet. This is not critical (at this time) for you to reach sites via IPv6.

[packetmail]

Validates that IPv6 requests with large packets work. If this test times out, but other IPv6 tests work, it suggests that there may be PMTUD issues; possibly involving IP tunnels.
Test if your ISP's DNS server uses IPv6
timeout (14.998s)
http://ds.v6ns.test-ipv6.com/ip/?callback=?
(This is bonus credit)

Hi, I believe you may have missed this in the tests you've run.  Again, I think an MTU of 1280 is way too small and an MTU of 1472 is better suited to your environment of PPPoE DSL and a 6in4 tunnel.  I recommend setting the MTU to 1472, re-running the tests, and seeing if you pass IPv6 large packet tests.  I suspect this is the crux of your issue.

Cheers!

[edit - fixed spelling mistake]

[Kokel]

Hi packetmail,

thanks for your hint. But I passed this test. It's a little bit confusing because the formatting of the results isn't so good.
Here the right format:

Test with IPv4 DNS record
ok (1.155s) using ipv4
http://ipv4.test-ipv6.com/ip/?callback=?
Fetches an object that has just an A record in DNS. This is expected to use IPv4. IPv6-only users might still reach this, if their provider has employed a NAT64/DNS64 or proxy solution.

Test with IPv6 DNS record
ok (1.867s) using ipv6
http://ipv6.test-ipv6.com/ip/?callback=?
Fetches an object that has just an AAAA record in DNS. This is expected to use IPv6. Users not yet on the IPv6 Internet are likely to see this fail. As long as it fails quickly, it will be OK - for now.

Test with Dual Stack DNS record
ok (0.813s) using ipv6
http://ds.test-ipv6.com/ip/?callback=?
This is the most important test. This verifies your browser can connect to a site that has both IPv4 and IPv6 records published. IPv4 only hosts should connect fine (using IPv4).
If this test fails or times out, you can expect major problems as publishers start offering their sites on IPv6.

Test for Dual Stack DNS and large packet
ok (1.403s) using ipv6
http://ds.test-ipv6.com/ip/?callback=?&size=1600&fill=xxx...xxx
Validates that you can connect to a dual-stack server (like the ds test); and that you can send/receive large packets on that connection. If this test times out for any reason, it indicates trouble for World IPv6 Day.

Test IPv4 without DNS
ok (1.531s) using ipv4
http://216.218.228.114/ip/?callback=?
This will try connecting with a literal IPv4 numeric address. This should work for most people, unless they are running IPv6-only. If the first test worked, but this fails, it likely confirms your provider is using NAT64/DNS64; you'll need to only try connecting using hostnames instead of numeric IP addresses.

Test IPv6 without DNS
ok (0.342s) using ipv6
http://[2001:470:1:18::114]:80/ip/?callback=?
This will try connecting with a literal IPv6 hexadecimal address. The primary purpose of this test is to separate out your connectivity on IPv6 from your ability to fetch DNS for it. A secondary purpose is to see if you have Teredo enabled; some systems may only use Teredo when an IPv6 address is in the URL.

Test IPv6 large packet
ok (0.343s) using ipv6
http://ipv6.test-ipv6.com/ip/?callback=?&size=1600&fill=xxx...xxx
Validates that IPv6 requests with large packets work. If this test times out, but other IPv6 tests work, it suggests that there may be PMTUD issues; possibly involving IP tunnels.

Test if your ISP's DNS server uses IPv6
timeout (14.998s)
http://ds.v6ns.test-ipv6.com/ip/?callback=?
(This is bonus credit)
This is a test of your ISP's resolver (instead of a test of your host). If this test passes, your DNS server (often run by your ISP) is capable of reaching IPV6-only DNS authoritative servers on the Internet. This is not critical (at this time) for you to reach sites via IPv6.

Only the test if my ISP's DNS server uses IPv6 fails.

Greetz, kokel

[packetmail]

Kokel thank you for the correction I apologize, it is me who can't read :)

I am sorry but I don't have more suggestions to offer other than adjusting the MTU.  Perhaps others here in the forum can make some additional recommendations that may resolve your isssue.  If latency and the routes are similar between your ADSL and vDSL and you don't believe it to be MTU related (1280 vs 1472) then I am sorry but I do not have any other suggestions to help.

Cheers and I wish you the best!  Please keep us updated.  Thank you

[cholzhauer]

I would change the MTU as suggested.  If it doesn't help, you can always set it back

[Kokel]

Well, i have to thank you guys for your suggestions.

Sorry, maybe I didn't mentioned before. I have changed the MTU to 1472.

But when this is an mtu issue, I will have had the same problem before with my adsl2+ connection. At that time the MTU was 1280 and the bandwidth was to the maximum of 16MBit/s.

Greetz, Kokel

[kasperd]

On the virtual device an MTU of 1280 should give you the most reliable connectivity. The performance difference between an MTU of 1280 and 1472 should be really small. I'd be surprised if you could measure the difference, as long as you have a setting that isn't completely broken.

The physical interface that you are running the tunnel over should have a larger MTU. Otherwise there won't be enough room for the headers. The difference between 1280 (which is the smallest MTU value permitted by IPv6) and the 1500 bytes which is the limit on regular Ethernet is sufficient to handle all the protocol stacks commonly in use.

So all you have to do to get MTU settings that will work is figure out how the MTU values are ordered from the lowest level to the highest level, and ensure that between every pair there is enough difference to accommodate for the headers needed at that level.

I don't see any obvious configuration mistakes in your MTU settings, so I am suspecting your problem might be something completely different.