12-24-2010 06:20 AM - edited 08-29-2017 02:40 AM
This doument is inteded for educational purposes only.
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.
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.
ipv6 unicast-routing
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
ipv6 unicast-routing
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 tunnel interface to LAN.
Spoke1#clear ipv6 nhrp
Spoke1#sh ipv6 nhrp brief
Target Via NBMA Mode Intfc Claimed
2001:DB8::1/128 2001:DB8::1 10.0.0.1 static Tu0 < >
FE80::C800:6FF:FE67: FE80::C800:6FF: 10.0.0.1 static Tu0 < >
! This is the IPv6 address on LAN assigned to spoke 2!
Spoke1#ping 2001:DB8:102:0:C802:6FF:FE67:6
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:DB8:102:0:C802:6FF:FE67:6, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/28/96 ms
Spoke1#sh ipv6 nhrp brief
Target Via NBMA Mode Intfc Claimed
2001:DB8::1/128 2001:DB8::1 10.0.0.1 static Tu0 < >
2001:DB8::101/128 2001:DB8::101 10.0.0.101 dynamic Tu0 < >
2001:DB8::102/128 2001:DB8::102 10.0.0.102 dynamic Tu0 < >
FE80::C800:6FF:FE67: FE80::C800:6FF: 10.0.0.1 static Tu0 < >
FE80::C802:6FF:FE67: FE80::C802:6FF: 10.0.0.102 dynamic Tu0 < >
Let's check spoke 2:
Spoke2#sh ipv6 nhrp brief
Target Via NBMA Mode Intfc Claimed
2001:DB8::1/128 2001:DB8::1 10.0.0.1 static Tu0 < >
2001:DB8::101/128 2001:DB8::101 10.0.0.101 dynamic Tu0 < >
FE80::C800:3FF:FE08: FE80::C800:3FF: 10.0.0.1 static Tu0 < >
FE80::C801:3FF:FE08: FE80::C801:3FF: 10.0.0.101 dynamic Tu0 < >
FE80::C802:3FF:FE08: FE80::C802:3FF: 10.0.0.102 dynamic Tu0 < >
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
Spoke1#sh ipv6 nhrp brief
Target Via NBMA Mode Intfc Claimed
2001:DB8::1/128 2001:DB8::1 10.0.0.1 static Tu0 < >
FE80::C800:3FF:FE08: FE80::C800:3FF: 10.0.0.1 static Tu0 < >
FE80::C801:3FF:FE08: FE80::C801:3FF: 10.0.0.101 dynamic Tu0 < >
FE80::C802:3FF:FE08: FE80::C802:3FF: 10.0.0.102 dynamic Tu0 < >
and on spoke 2:
Spoke2#clear ipv6 nhrp
Spoke2#sh ipv6 nhrp brief
Target Via NBMA Mode Intfc Claimed
2001:DB8::1/128 2001:DB8::1 10.0.0.1 static Tu0 < >
FE80::C800:3FF:FE08: FE80::C800:3FF: 10.0.0.1 static Tu0 < >
FE80::C801:3FF:FE08: FE80::C801:3FF: 10.0.0.101 dynamic Tu0 < >
FE80::C802:3FF:FE08: FE80::C802:3FF: 10.0.0.102 dynamic Tu0 < >
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.
IOS configuration guide:
wikipedia atricle about IPv6:
http://en.wikipedia.org/wiki/Ipv6
Configuration files used in the lab are attached below and contain crypto but not best practices.
A decent quick note, but it could be improved by adding the following:
Add recommended tunnel interface commands:
ip mtu 1400
ip nhrp holdtime 300
ip tcp adjust-mss 1360
ipv6 mtu 1400
ipv6 nhrp holdtime 300
Add an example of 'show ipv6 interface brief | section Tunnel' to show both the IPv6 unicast-global and link-local addresses used by EIGRP as the IPv6 next-hop. This will help show how the IPv6 Routing Table entries tie in with the IPv6 NHRP mapping entries.
Also on the output of 'show ipv6 nhrp brief' after the spoke1 to spoke2 tunnel has been built you should have a link-local (no-socket) mapping entry for Spoke1 itself. It should look something like:
FE80::C801:6FF:FE67: FE80::C801:6FF: 10.0.0.101 dynamic Tu0 < >
Mike.
Mike, if you already had an IPv4 DMVPN cloud, could you just add the extra IPv6 commands or would you have to formulate a totally new tunnel ?
Kevin.
Kevin,
There should be no problem to add extra commands to existing config - although caveats apply in same way as IPv4 (for example OSPF process checks MTU to establish relationship).
M.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: