cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
7376
Views
5
Helpful
3
Comments
Marcin Latosiewicz
Cisco Employee
Cisco Employee

     

     

    Disclaimer:

    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:

     

     

    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

     

     

     

    Changes on spoke side:

     

    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

     

     

     

    Best practice.

     

    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

     

    Verification:

    Let's check if it's working. I'll compare IPv6 NHRP table before and after.

    Scenario 1

     

    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     <   >

     

     

    Scenario 2.

    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     <   >

     

     

    Considerations.

     

    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.

    Further reading.

     

    IOS configuration guide:

    lhttp://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-dmvpn_ps6441_TSD_Products_Configuration_Guide_Chapter.html

    wikipedia atricle about IPv6:

    http://en.wikipedia.org/wiki/Ipv6

     

     

    Configuration files.

    Configuration files used in the lab are attached below and contain crypto but not best practices.

    Comments

    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.

    ksherwood
    Level 1
    Level 1

    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.

    Marcin Latosiewicz
    Cisco Employee
    Cisco Employee

    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.

    Getting Started

    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: