This doument is inteded for educational purposes only.
IPv4 and IPv6 in December 2010.
Migration to IPv6 is somewhat of a buzzword recently.
IPv6 has been around for a while and adoption rate is increasing.
But frankly, things are lagging behind.
- Are all your vendors (software/hardware/network etc.) IPv6 ready? I believe most of them claim they are :-)
- Are your providers providing IPv6 service? Some of them are, some are not.
But how does one evaluate what still needs to be done?
You don't want to wake up in a few days realizing your proxy/loadbalancer/firewall does not pass IPv6. You need to test test test.
I've been thinking about the whole situation and where it leaves a lot of people:
- Multiple branches.
- Restrictions on changes to be done.
- Changes cannot affect existing functionality.
- No scalable way to deploy IPv6 over whole network topology.
Ideally we'd run everything dual stack, in practice though we have to rely on mechanism such as 6to4, ISATAP. GRE and other.
DMVPN is also GRE (over IPSec if one wants added security), which means you can use DMVPN to route both IPv4 and IPv6.
IPv6 over existing DMVPN cloud.
Just a few lines in your tunnel interfaces and you're all set!
Note: that this has been tested on 12.4(20)T6 advanced enterprise k9 image.
Changes on hub side:
interface Tunnel0 bandwidth 8000 ip address 172.16.1.1 255.255.255.0 no ip redirects no ip next-hop-self eigrp 1 ip nhrp map multicast dynamic ip nhrp network-id 1 no ip split-horizon eigrp 1 ipv6 address 2001:DB8::1/64 ipv6 nhrp map multicast dynamic ipv6 nhrp network-id 101
ipv6 eigrp 101
no ipv6 split-horizon eigrp 101 no ipv6 next-hop-self eigrp 101 tunnel source FastEthernet0/0 tunnel mode gre multipoint end
ipv6 router eigrp 101 no shutdown
Changes on spoke side:
interface Tunnel0 bandwidth 8000 ip address 172.16.1.101 255.255.255.0 no ip redirects ip nhrp map multicast 10.0.0.1 ip nhrp map 172.16.1.1 10.0.0.1 ip nhrp network-id 1 ip nhrp nhs 172.16.1.1 ipv6 address 2001:DB8::101/64 ipv6 nhrp map 2001:DB8::1/128 10.0.0.1 ipv6 nhrp map multicast 10.0.0.1 ipv6 nhrp network-id 101 ipv6 nhrp nhs 2001:DB8::1
ipv6 eigrp 101 tunnel source FastEthernet0/0 tunnel mode gre multipoint end
ipv6 router eigrp 101 no shutdown
As Mike comments below.
It's best practice to also adjust MTU and MSS settings.
Changing NHRP timeout from default 7200 seconds saves time during transitions or failures.
ip mtu 1400
ip nhrp holdtime 300
ip tcp adjust-mss 1360
ipv6 mtu 1400
ipv6 nhrp holdtime 300
Let's check if it's working. I'll compare IPv6 NHRP table before and after.
Ping from LAN interface on spoke 1 to LAN interface on spoke 2.
Spoke1#clear ipv6 nhrp
Spoke1#ping 2001:DB8:102:0:C802:3FF:FE08:6 sou fa0/1 re 10
Type escape sequence to abort. Sending 10, 100-byte ICMP Echos to 2001:DB8:102:0:C802:3FF:FE08:6, timeout is 2 seconds: Packet sent with a source address of 2001:DB8:101:0:C801:3FF:FE08:6 ..!!!!!!!! Success rate is 80 percent (8/10), round-trip min/avg/max = 4/8/20 ms
This configuration allows you to use almost any unicast IPv6 subnet. It is intended as possible interim solution until full IPv6 dual stack deployment is reached.
That being said, one can think of a scenario where a service provider gives hub location IPv6 /48 addrss, that pool of addresses can be later on subnetted into /64 bit subnets for spokes and hub locations.
This could allow one to test connectivity via IPv6 to almost anywhere - for testing purposes.