Initial feedback/findings for Cisco 837 + Linux/Win7 clients
Warning: Lengthy post ahead but hopefully some of it might be of interest/use! 
Hi everyone,
I'm seeing some good results in the other threads and if one thing's clear I'd say we're probably all scratching our heads at some stage in the process so I thought I'd share my findings in case they're of any use, and indeed will continue to read what others have to say to fill in my own gaps.
Cisco 837 Router Config
I'm using a Cisco 837 (IOS c837-k9o3sy6-mz.124-25d.bin [24/08/2010]) which was previously configured with a Hurricane Electric IPv6-in-IPv4 tunnel. I stripped the old IPv6-related config (truth be told I initially kept it all in but it made it practically impossible to test the new config properly!) and replaced/added the following:
(Note: Non IPv6/connectivity config removed for clarity - I can post the whole lot if it's of interest)
As you can see I have configured an IPv6 DHCP service for LAN clients however I am only using this to dish out the address of an IPv6-enabled DNS server (at Hurricane Electric) and, notably, will not be using DHCP to provide clients with their IPv6 addresses. Instead, they will be expected to use autoconfiguration (i.e. concatenation of network prefix + MAC/other-identifier) to define their addresses or define their own static address (e.g. on my servers). I did it this way primarily to broaden the scope of the testing.
Router address and DHCP config can be verified with show ipv6 interface brief and show ipv6 dhcp interface respectively:
Linux Client Config
My main Linux box is running Kubuntu 6.06 (yes, it's old!) however its config will be similar across most distros, particular others that are Debian-based. Configuration was done at the command line and so GUI tools might represent things slightly differently.
First off I configured a static IPv6 address (as it acts as a server):
(Note: Again any non-IPv6 config is removed for clarity)
Whilst this gave the server IPv6 connectivity it will still perform DNS lookups over IPv4. In particular, it can fetch IPv6 records (AAAA) but won't be using IPv6 transport. As prepared for on the router, DHCPv6 is one solution and for this I installed a DHCPv6 client apt-get install wide-dhcpv6-client and enabled it on eth0 by specifying INTERFACES="eth0" in /etc/default/wide-dhcpv6-client (method/config might differ on other distros).
A packet trace showed the DHCP solicit/response/request/reply DHCPv6 dialogue with the DNS server address included, however, I was still seeing DNS lookups going over IPv4 to Plusnet's IPv4 DNS servers. This could well be a problem with my old installation so I will need to look into this further. [Edit: It was - having tried a newer version on Debian Squeeze it now comes with a script to automatically put the DHCPv6-obtained DNS servers into /etc/resolv.conf] In the meantime I manually defined an IPv6 DNS server in /etc/resolv.conf:
Now, packet traces showed the Hurricane Electric DNS server taking primacy and queries going over IPv6.
Windows 7 Config
My laptop runs Windows 7 however I only really use it for sat-in-the-lounge web browsing and I am not too familiar with low-level configuration of it, particularly for IPv6. However, I worked out enough to at least get it working.
First off I decided to disable Teredo tunneling because whilst provide IPv6 capability I didn't want it to interfere with the Plusnet trial as there's a very real danger that IPv6 connectivity may well appear to be working but it'd actually be the Teredo tunnel providing it and not Plusnet's native IPv6. I couldn't find a way to do this with the GUI however entering the following in a command prompt (run as administrator) works:
(You may wish to disable 6to4 tunneling with netsh interface 6to4 set state disable if you find that's kicking in too)
Again I wanted to use autoconfiguration for the IPv6 address but ensure that DHCPv6 was used to obtain an IPv6-enabled DNS server. To do this I first had to find the 'Idx' identifier for my wireless adapter:
...and then enable DHCPv6 for this interface:
(Further details of DHCPv6 on Windows can be found here)
The config can now be confirmed working:
So you can see that global IPv6 addresses have been assigned through autoconfiguration (one using the MAC address, another randomly generated), a link-local address (again via autoconfiguration), the link-local address of the gateway (obtained via the router advertisement) and the IPv6-enabled DNS server included in the DNS server lineup. A packet trace confirmed that this server was indeed being used (over IPv6).
Performance
I've got an IPv4/IPv6 dual-stack server in Telehouse (London) and so used this as a test reference as I can rule out a number of external variables that may otherwise impact on performance tests such as server load, distance from Plusnet's peering point, etc.
Firstly, ICMP pings showed comparable results (~40ms):
Whereas traceroutes showed that the IPv6 path was a couple of hops shorter:
Plusnet's peering (to my server on the Jump network) in Telehouse can be seen to be provided for separately for IPv4 (Level3) and IPv6 (Hurricane Electric) but it didn't seem to affect the latency despite the different hop count (there will of course be many differences, particularly at the underlying levels so it's not worth dwelling on too much).
Downstream throughput was tested using iperf by running a TCP stream for 20s over IPv4 then IPv6:
Note that whilst the IPv6 transfer may have seemed quicker (3.6 Mbps compared with 3.24 Mbps) repeated tests showed there was quite a lot of variance and so I will rerun the tests overnight rather than mid-afternoon on a bank holiday! I also tested upload which again was comparable (and maxed out my connection at ~400kbps).
Finally, I have attached the obligatory http://test-ipv6.com result confirming all is hunkydory:
All in all things are looking good so a big well done and thank you, Plusnet!
Mathew
Hi everyone,
I'm seeing some good results in the other threads and if one thing's clear I'd say we're probably all scratching our heads at some stage in the process so I thought I'd share my findings in case they're of any use, and indeed will continue to read what others have to say to fill in my own gaps.
Cisco 837 Router Config
I'm using a Cisco 837 (IOS c837-k9o3sy6-mz.124-25d.bin [24/08/2010]) which was previously configured with a Hurricane Electric IPv6-in-IPv4 tunnel. I stripped the old IPv6-related config (truth be told I initially kept it all in but it made it practically impossible to test the new config properly!) and replaced/added the following:
(Note: Non IPv6/connectivity config removed for clarity - I can post the whole lot if it's of interest)
!
ipv6 unicast-routing ! Enable IPv6 routing between interfaces
ipv6 dhcp pool IPV6DHCP ! Define an IPv6 DHCP pool called 'IPV6DHCP'
dns-server 2001:470:20::2 ! Define an IPv6 DNS resolver for clients to use
! ! Note: Client addresses not being handed out by DHCP!
!
interface Ethernet0 ! LAN switchports
ipv6 address MYPLUSNETPREFIX ::/64 eui-64 ! Autoconfigure an IPv6 address using MYPLUSNETPREFIX+MAC
ipv6 enable ! Enable IPv6 on this interface (LAN)
ipv6 nd other-config-flag ! Announce that non-address info can be obtained by DHCP
ipv6 dhcp server IPV6DHCP ! Provide a DHCP service using my 'IPV6DHCP' pool/config
!
!
interface Dialer1 ! Dialer interface (connects over int atm 0) (=WAN)
encapsulation ppp ! Use PPP encapsulation
dialer pool 1 ! Define dialer pool '1'
ipv6 address autoconfig ! Autoconfigure a (link-local) IPv6 address
ipv6 enable ! Enable IPv6 on this interface (WAN)
ipv6 dhcp client pd MYPLUSNETPREFIX rapid-commit ! Obtain IPv6 prefix via DHCP from Plusnet (and call
! it 'MYPLUSNETPREFIX' for use elsewhere)
ppp chap hostname <removed>@plusdsl.net ! Trial account username from Dave
ppp chap password 7 <removed> ! Trial account password from Dave
!
ipv6 route ::/0 Dialer1 ! Set default route to Dialer 1 (WAN)
!
As you can see I have configured an IPv6 DHCP service for LAN clients however I am only using this to dish out the address of an IPv6-enabled DNS server (at Hurricane Electric) and, notably, will not be using DHCP to provide clients with their IPv6 addresses. Instead, they will be expected to use autoconfiguration (i.e. concatenation of network prefix + MAC/other-identifier) to define their addresses or define their own static address (e.g. on my servers). I did it this way primarily to broaden the scope of the testing.
Router address and DHCP config can be verified with show ipv6 interface brief and show ipv6 dhcp interface respectively:
Cisco837#sh ipv6 int brief
FastEthernet1 [up/up]
FastEthernet2 [down/down]
FastEthernet3 [down/down]
FastEthernet4 [down/down]
Ethernet0 [up/up]
FE80::212:D9FF:FED8:B2EE
2A02:16C8:2000:6000:212:D9FF:FED8:B2EE
ATM0 [up/up]
Ethernet2 [administratively down/down]
Tunnel0 [administratively down/down]
FE80::51AE:8B49
2001:470:1F08:1917::2
Dialer1 [up/up]
FE80::212:D9FF:FED8:B2EE
NVI0 [up/up]
Virtual-Access1 [up/up]
Virtual-Access2 [up/up
Cisco837#sh ipv6 dhcp int
Ethernet0 is in server mode
Using pool: IPV6DHCP
Preference value: 0
Hint from client: ignored
Rapid-Commit: disabled
Dialer1 is in client mode
State is OPEN
Renew will be sent in 7w0d
List of known servers:
Reachable via address: FE80::90:1A00:3A3:BA15
DUID: 000200000A4C453332302F373435414333334558322F03
Preference: 0
Configuration parameters:
IA PD: IA ID 0x000D0001, T1 INFINITY, T2 INFINITY
Prefix: 2A02:16C8:2000:6000::/56
preferred lifetime INFINITY, valid lifetime INFINITY
DNS server: 2001:470:20::2
Prefix name: MYPLUSNETPREFIX
Rapid-Commit: enabled
Linux Client Config
My main Linux box is running Kubuntu 6.06 (yes, it's old!) however its config will be similar across most distros, particular others that are Debian-based. Configuration was done at the command line and so GUI tools might represent things slightly differently.
First off I configured a static IPv6 address (as it acts as a server):
(Note: Again any non-IPv6 config is removed for clarity)
auto eth0
iface eth0 inet6 static
pre-up modprobe ipv6 ! Ensure the IPv6 kernel module is loaded
address 2a02:16c8:2000:6000::50 ! Configure a static IPv6 address
netmask 64 ! Configure the subnet size (a /64 from the /56 allocation)
Whilst this gave the server IPv6 connectivity it will still perform DNS lookups over IPv4. In particular, it can fetch IPv6 records (AAAA) but won't be using IPv6 transport. As prepared for on the router, DHCPv6 is one solution and for this I installed a DHCPv6 client apt-get install wide-dhcpv6-client and enabled it on eth0 by specifying INTERFACES="eth0" in /etc/default/wide-dhcpv6-client (method/config might differ on other distros).
A packet trace showed the DHCP solicit/response/request/reply DHCPv6 dialogue with the DNS server address included, however, I was still seeing DNS lookups going over IPv4 to Plusnet's IPv4 DNS servers. This could well be a problem with my old installation so I will need to look into this further. [Edit: It was - having tried a newer version on Debian Squeeze it now comes with a script to automatically put the DHCPv6-obtained DNS servers into /etc/resolv.conf] In the meantime I manually defined an IPv6 DNS server in /etc/resolv.conf:
# Hurricane Electric DNS server (IPv6)
nameserver 2001:470:20::2
# Plusnet DNS servers - see http://www.plus.net/support/customer_service/using/settings.shtml
nameserver 212.159.13.49
nameserver 212.159.13.50
Now, packet traces showed the Hurricane Electric DNS server taking primacy and queries going over IPv6.
Windows 7 Config
My laptop runs Windows 7 however I only really use it for sat-in-the-lounge web browsing and I am not too familiar with low-level configuration of it, particularly for IPv6. However, I worked out enough to at least get it working.
First off I decided to disable Teredo tunneling because whilst provide IPv6 capability I didn't want it to interfere with the Plusnet trial as there's a very real danger that IPv6 connectivity may well appear to be working but it'd actually be the Teredo tunnel providing it and not Plusnet's native IPv6. I couldn't find a way to do this with the GUI however entering the following in a command prompt (run as administrator) works:
netsh interface teredo set state disable
(You may wish to disable 6to4 tunneling with netsh interface 6to4 set state disable if you find that's kicking in too)
Again I wanted to use autoconfiguration for the IPv6 address but ensure that DHCPv6 was used to obtain an IPv6-enabled DNS server. To do this I first had to find the 'Idx' identifier for my wireless adapter:
C:\>netsh interface ipv6 show interfaces
Idx Met MTU State Name
--- ---------- ---------- ------------ ---------------------------
1 50 4294967295 connected Loopback Pseudo-Interface 1
12 25 1500 connected Wireless Network Connection
16 50 1280 disconnected isatap.{C5817D38-DC03-4DA8-89E5-2318E2AFFCE4}
11 20 1500 disconnected Local Area Connection
...and then enable DHCPv6 for this interface:
netsh interface ipv6 set interface 12 advertise=disable managed=enable
(Further details of DHCPv6 on Windows can be found here)
The config can now be confirmed working:
C:\>ipconfig /all
Wireless LAN adapter Wireless Network Connection:
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Atheros AR5005G Wireless Network Adapter
Physical Address. . . . . . . . . : 00-19-7D-47-E5-86
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
IPv6 Address. . . . . . . . . . . : 2a02:16c8:2000:6000:f820:b600:64c2:f2cd(Preferred)
Temporary IPv6 Address. . . . . . : 2a02:16c8:2000:6000:287c:b3a3:c594:2183(Preferred)
Link-local IPv6 Address . . . . . : fe80::f820:b600:64c2:f2cd%12(Preferred)
IPv4 Address. . . . . . . . . . . : 192.168.1.71(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Lease Obtained. . . . . . . . . . : 30 May 2011 14:15:43
Lease Expires . . . . . . . . . . : 30 May 2011 21:26:20
Default Gateway . . . . . . . . . : fe80::212:d9ff:fed8:b2ee%12
192.168.1.254
DHCP Server . . . . . . . . . . . : 192.168.1.254
DHCPv6 IAID . . . . . . . . . . . : 218110333
DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-12-B1-83-96-00-16-36-D1-05-36
DNS Servers . . . . . . . . . . . : 2001:470:20::2
212.159.13.49
212.159.13.50
NetBIOS over Tcpip. . . . . . . . : Enabled
So you can see that global IPv6 addresses have been assigned through autoconfiguration (one using the MAC address, another randomly generated), a link-local address (again via autoconfiguration), the link-local address of the gateway (obtained via the router advertisement) and the IPv6-enabled DNS server included in the DNS server lineup. A packet trace confirmed that this server was indeed being used (over IPv6).
Performance
I've got an IPv4/IPv6 dual-stack server in Telehouse (London) and so used this as a test reference as I can rule out a number of external variables that may otherwise impact on performance tests such as server load, distance from Plusnet's peering point, etc.
Firstly, ICMP pings showed comparable results (~40ms):
mathew@rugrat:~$ ping -c 5 targur.newtonnet.co.uk
PING targur.newtonnet.co.uk (212.13.195.175) 56(84) bytes of data.
64 bytes from secure.newtonnet.co.uk (212.13.195.175): icmp_seq=1 ttl=54 time=39.2 ms
64 bytes from secure.newtonnet.co.uk (212.13.195.175): icmp_seq=2 ttl=54 time=34.6 ms
64 bytes from secure.newtonnet.co.uk (212.13.195.175): icmp_seq=3 ttl=54 time=39.8 ms
64 bytes from secure.newtonnet.co.uk (212.13.195.175): icmp_seq=4 ttl=54 time=41.0 ms
64 bytes from secure.newtonnet.co.uk (212.13.195.175): icmp_seq=5 ttl=54 time=37.1 ms
--- targur.newtonnet.co.uk ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4014ms
rtt min/avg/max/mdev = 34.635/38.377/41.041/2.267 ms
mathew@rugrat:~$ ping6 -c 5 targur.newtonnet.co.uk
PING targur.newtonnet.co.uk(2001:ba8:1f1:f137::2) 56 data bytes
64 bytes from 2001:ba8:1f1:f137::2: icmp_seq=1 ttl=55 time=40.2 ms
64 bytes from 2001:ba8:1f1:f137::2: icmp_seq=2 ttl=55 time=39.7 ms
64 bytes from 2001:ba8:1f1:f137::2: icmp_seq=3 ttl=55 time=39.3 ms
64 bytes from 2001:ba8:1f1:f137::2: icmp_seq=4 ttl=55 time=41.9 ms
64 bytes from 2001:ba8:1f1:f137::2: icmp_seq=5 ttl=55 time=40.4 ms
--- targur.newtonnet.co.uk ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 6333ms
rtt min/avg/max/mdev = 39.353/40.337/41.920/0.887 ms
Whereas traceroutes showed that the IPv6 path was a couple of hops shorter:
mathew@rugrat:~$ traceroute targur.newtonnet.co.uk
traceroute to targur.newtonnet.co.uk (212.13.195.175), 30 hops max, 40 byte packets
1 192.168.1.254 (192.168.1.254) 1.538 ms 1.477 ms 1.440 ms
2 lo0.plusnet.thn-ag1.plus.net (195.166.128.101) 45.569 ms 40.505 ms 37.733 ms
3 gi1-5-704.thn-gw2.plus.net (84.92.4.248) 40.463 ms 35.753 ms 78.430 ms
4 te-3-4.car5.London1.Level3.net (217.163.45.181) 42.998 ms 39.137 ms 36.721 ms
5 * * *
6 unknown.Level3.net (212.113.15.62) 38.153 ms 103.258 ms 37.881 ms
7 ldn-s10-rou-1041.UK.eurorings.net (134.222.231.26) 42.972 ms ldn-s10-rou-1041.UK.eurorings.net
(134.222.231.30) 40.637 ms 40.631 ms
8 vl327-kpn-gw-sup-tfm4.jump.net.uk (194.153.169.237) 39.963 ms 43.046 ms 38.500 ms
9 faustino.bitfolk.com (212.13.194.217) 41.410 ms 43.332 ms 40.395 ms
10 secure.newtonnet.co.uk (212.13.195.175) 38.183 ms 41.575 ms 39.601 ms
mathew@rugrat:~$ traceroute6 targur.newtonnet.co.uk
traceroute to targur.newtonnet.co.uk (2001:ba8:1f1:f137::2) from 2a02:16c8:2000:6000:240:f4ff:fe54:7310, 30
hops max, 16 byte packets
1 2a02:16c8:2000:6000:212:d9ff:fed8:b2ee (2a02:16c8:2000:6000:212:d9ff:fed8:b2ee) 1.597 ms 1.271 ms 1.128 ms
2 2a02:16c8:0:1::d (2a02:16c8:0:1::d) 49.208 ms 45.303 ms 40.646 ms
3 2a02:16c8:1:8018::1 (2a02:16c8:1:8018::1) 43.581 ms 42.079 ms 38.507 ms
4 lonap.he.net (2001:7f8:17::1b1b:1) 39.029 ms 50.168 ms 38.502 ms
5 linxv6-gw-a.jump.net.uk (2001:7f8:4::22ef:1) 39.337 ms 41.416 ms 48.074 ms
6 jump-gw-2.ipv6.bitfolk.com (2001:ba8:0:1f1::2) 41.018 ms 39.814 ms 43.729 ms
7 faustino.bitfolk.com (2001:ba8:0:1f1:2e0:81ff:fe47:1d16) 40.763 ms 44.476 ms 39.449 ms
8 2001:ba8:1f1:f137::2 (2001:ba8:1f1:f137::2) 49.213 ms 45.636 ms 41.738 ms
Plusnet's peering (to my server on the Jump network) in Telehouse can be seen to be provided for separately for IPv4 (Level3) and IPv6 (Hurricane Electric) but it didn't seem to affect the latency despite the different hop count (there will of course be many differences, particularly at the underlying levels so it's not worth dwelling on too much).
Downstream throughput was tested using iperf by running a TCP stream for 20s over IPv4 then IPv6:
mathew@targur:~$ iperf -t 20 -c rugrat.newtonnet.co.uk
------------------------------------------------------------
Client connecting to rugrat.newtonnet.co.uk, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[ 3] local 212.13.195.175 port 33649 connected with 81.174.139.73 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-20.1 sec 7.77 MBytes 3.24 Mbits/sec
mathew@targur:~$ iperf -V -t 20 -c rugrat.newtonnet.co.uk
------------------------------------------------------------
Client connecting to rugrat.newtonnet.co.uk, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[ 3] local 2001:ba8:1f1:f137::2 port 45936 connected with 2a02:16c8:2000:6000::50 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-20.2 sec 8.67 MBytes 3.60 Mbits/sec
Note that whilst the IPv6 transfer may have seemed quicker (3.6 Mbps compared with 3.24 Mbps) repeated tests showed there was quite a lot of variance and so I will rerun the tests overnight rather than mid-afternoon on a bank holiday! I also tested upload which again was comparable (and maxed out my connection at ~400kbps).
Finally, I have attached the obligatory http://test-ipv6.com result confirming all is hunkydory:
All in all things are looking good so a big well done and thank you, Plusnet!
Mathew
