DMVPN

One of the parts of my CCIE study is DMVPN’s. With this technique it’s very easy to built full meshed VPN networks without the need to connect every (branch) office physically with each other. DMVPN’s are built in a hub and spoke manner. Between the hub and the spoke tunnels (VPN’s) are built for connectivity. It’s also possible to connect a branch to a branch, without sendig all the traffic to the Hub, but directly to the spoke site.
To make all of this happen, DMVPN’s use a technique which is called NHRP.

NHRP*
In a computer network, the Next Hop Resolution Protocol (NHRP) is a protocol or method that can be used so that a computer sending data to another computer can learn the most direct route (the fewest number of hops to the receiving computer. If the receiving computer is in the same subnetwork, the use of NHRP will tell the sending computer that the receiving computer is local and it can send subsequent data packets directly to the receiving computer using its subnetwork address rather than its global network address. If the receiving computer is not in the same subnetwork, the use of NHRP will tell the sending computer the computer in the subnetwork whose router provides the most direct path to the receiving computer and the sender can now forward subsequent data packets to that router. In a way NHRP functions almost as a DNS server.

In the picture below the topology I used for this case study. The internetcloud is in my GNS3 configuration a router which routes the used subnets.

DMVPN

 

First configure the DMVPN hub, in my case this is router R1. I think configuring the local and external addresses a pretty forward, so I will only show the tunnel configuration.

R1 Tunnel0
!
interface Tunnel0
ip address 10.0.0.1 255.255.255.0
no ip redirects
ip nhrp authentication DMVPN
ip nhrp network-id 1
tunnel source FastEthernet1/0
tunnel mode gre multipoint
tunnel protection ipsec profile MGRE
!

As can be seen in the above configuration there is no tunnel destination configured. Instead of this the tunnel mode is configured as “tunnel mode gre multipoint”. With this configuration it is possible to connect several branches (spokes) to the same interface.

To connect a spoke to the hub location the following configuration is necessary on the spoke router.

R2
!
interface Tunnel0
ip address 10.0.0.2 255.255.255.0
no ip redirects
ip nhrp authentication DMVPN
ip nhrp map 10.0.0.1 201.1.1.1
ip nhrp network-id 1
ip nhrp nhs 10.0.0.1
tunnel source FastEthernet1/0
tunnel mode gre multipoint
tunnel protection ipsec profile MGRE
!

To connect a branch office to the hub location, you have to point the tunnel to the tunnel and external address of the hub location.

To check if the connection succeeded, use the “show dmvpn” command on the hub and spoke router.

R1
show_dmvpn_R1

R2
show_dmvpn_R2

As can be seen there is DMVPN connectivity between the hub and the spoke router. Only the traffic is not encrypted yet. For that we have to configure a crypto IPSEC profile. This can be done as below, I will not discuss this part of the configuration. For this I will write a seperate blogpost.

Configure on router R1
!
crypto isakmp policy 1
encr aes
hash md5
authentication pre-share
group 2
crypto isakmp key HEGGEL address 0.0.0.0 0.0.0.0
!
!
crypto ipsec transform-set MYSET esp-aes esp-md5-hmac
!
crypto ipsec profile MGRE
set security-association lifetime seconds 86400
set transform-set MYSET
!

Configure on router R2
!
crypto isakmp policy 1
encr aes
hash md5
authentication pre-share
group 2
crypto isakmp key HEGGEL address 0.0.0.0 0.0.0.0
!
!
crypto ipsec transform-set MYSET esp-aes esp-md5-hmac
!
crypto ipsec profile MGRE
set security-association lifetime seconds 86400
set transform-set MYSET
!

Now the traffic between hub and spoke are encrypted. To check this, you can make use of wireshark. I will ping the 10.10.10.254 interface of router R1 with a source address of 192.168.1.254.

wireshark_encr

When you open one of these packets you can see that ESP is used to encypt the packet

ESP

ESP*
Encapsulating Security Payload (ESP) is a member of the IPsec protocol suite. In IPsec it provides origin authenticity, integrity and confidentiality protection of packtes. ESP also supports encryption-only and authentication-only configurations, but using encryption without authentication is strongly discouraged because it is insecure. Unlike AH, ESP in transport mode does not provide integrity and authentication for the entire IP packet. However, in Tunnel mode, where the entire original IP packet is encapsulated with a new packet header added, ESP protection is afforded to the whole inner IP packet (including the inner header) while the outer header (including any outer IPv4 options or IPv6 extension headers) remains unprotected. ESP operates directly on top of IP, using IP protocol number 50.

To create a spoke-to-spoke connection, let’s say between R2 and R4, only the routes necessary have to be configured on R2 and R4. In a large scale full mesh network it’s easier to use a dynamic routing protocol. But in my example I want to show it’s also possible to connect only two spoke’s instead of a totally meshed network.

Configure on R2 the route to the LAN of R4
!
ip route 192.168.2.0 255.255.255.0 10.0.0.4
!

Configure on R4 the route to the LAN of R2
!
ip route 172.18.1.o 255.255.255.0 10.0.0.2
!

If you use the “show dmvpn” command on R2 and R4, there is an extra tunnel built between spoke routers R2 and R4.

R2
show_dmvpn_R2_HS

R4
show_dmvpn_R4_HS

As can be seen in the picture above, the tunnel between R2 and R4 is a dynamic tunnel. If you remove the previously created routes, the tunnel will be terminated.

 

 

*Source is http://www.cisco.com

Advertisements

IPv6 Fundamentals

While learning for my CCIE exam I realized that my understanding of IPv6 was really mediocre, although it was enough to clear the CCNP and CCDP exams. But I have to level up my knowledge of IPv6 to even think of passing the CCIE exam. Besides the cisco.com website I used two books: “IPv6 Fundamentals” written by Rick Graziani and “IPv6 for Enterprise Networks” written by Shannon McFarland, Muninder Sambi, Nikhil Sharma and Sanjay Hooda.
After reading these books and reading some config guides from the cisco.com website, my understanding of IPv6 had leveled up about 10 levels.

Therefore I thought it was time to create a case study. Below is the topology I used. Of course I used my great study companion GNS3 to create and configure my case study.

IPv6 Topology

First I configured routers R1 to R3. This is the basic network, which uses OSPFv3. Below the configs of routers R1 to R3.

R1:

!
interface FastEthernet1/0
no ip address
duplex auto
speed auto
ipv6 address 2001:DB8:CAFE:A001::1/64
ipv6 ospf 10 area 0
!
interface FastEthernet2/0
no ip address
duplex auto
speed auto
ipv6 address 2001:DB8:CAFE:A003::1/64
ipv6 ospf 10 area 0
!
interface FastEthernet3/0
no ip address
duplex auto
speed auto
ipv6 address 2001:DB8:CAFE:C001::1/64
ipv6 ospf 10 area 0
!
ipv6 router ospf 10
router-id 1.1.1.1
log-adjacency-changes

R2:

!
interface FastEthernet1/0
no ip address
duplex auto
speed auto
ipv6 address 2001:DB8:CAFE:A001::2/64
ipv6 ospf 10 area 0
!
interface FastEthernet2/0
no ip address
duplex auto
speed auto
ipv6 address 2001:DB8:CAFE:C002::1/64
ipv6 ospf 10 area 0
!
interface FastEthernet3/0
no ip address
duplex auto
speed auto
ipv6 address 2001:DB8:CAFE:A002::1/64
ipv6 ospf 10 area 0
!
ipv6 router ospf 10
router-id 2.2.2.2
log-adjacency-changes
!

 

R3:

!
interface FastEthernet1/0
no ip address
duplex auto
speed auto
ipv6 address 2001:DB8:CAFE:C003::1/64
ipv6 ospf 10 area 0
!
interface FastEthernet2/0
no ip address
duplex auto
speed auto
ipv6 address 2001:DB8:CAFE:A003::2/64
ipv6 ospf 10 area 0
!
interface FastEthernet3/0
no ip address
duplex auto
speed auto
ipv6 address 2001:DB8:CAFE:A002::2/64
ipv6 ospf 10 area 0
!
ipv6 router ospf 10
router-id 3.3.3.3
log-adjacency-changes
!

As can be seen in the configurations, IPv6 isn’t that different than IPv4. Two things to remember, first the ospf configuration is done on the interface itself. Second, the router-id in OSPFv3 is a 32-bit dotted decimal number, yes indeed a IPv4 address format.

Check out the IPv6 routing table to confirm the configuration is working:

IPv6 route table R2

 

To test ip connectivity use Ping. This works the same as in IPv4:

ping_test_R2

As can be seen in the topology overview there is an IPv6 “island” that has only IPv4 connectivity to the “main” network. Here “6to4” tunnels come in handy. To create IPv6 connectivity between the main network and the IPv6 island, we create a 6to4 tunnel on routers R1 and R4. These tunnels encapsulate IPv6 traffic into IPv4 packtes. To make this happen the following configuration on R1 and R4 are necessary:

R1:

!
interface Tunnel0
no ip address
ipv6 enable
tunnel source FastEthernet0/0
tunnel destination 10.10.10.2
tunnel mode ipv6ip
!
interface FastEthernet0/0
no switchport
ip address 10.10.10.1 255.255.255.252
!
ipv6 route 2001:DB8:CAFE:F001::/64 Tunnel0
ipv6 route 2001:DB8:CAFE:F002::/64 Tunnel0
!
ipv6 router ospf 10
router-id 1.1.1.1
log-adjacency-changes
redistribute static metric 5
!

 

R4:

!
interface Tunnel0
no ip address
ipv6 enable
tunnel source FastEthernet1/0
tunnel destination 10.10.10.1
tunnel mode ipv6ip
!
interface FastEthernet1/0
ip address 10.10.10.2 255.255.255.252
duplex auto
speed auto
!
ipv6 route 2001:DB8:CAFE::/48 Tunnel0
!
ipv6 router ospf 11
router-id 4.4.4.4
log-adjacency-changes
redistribute static metric 5
!

The configuration is pretty straight forward. Create the tunnel, give in source and destination (in this case the IPv4 address of the other site) and create a statis route for the subnet that has to be reached pointing to the tunnel interface.
Don’t forget to redistribute the static route into the routing protocol. This works the same for OSPFv3 as it works in IPv4 OSPF. The only down-side of a manual 6to4 tunnel is that it doesn’t scale very well in large enterprise networks.
To verify the Tunnel configuration use the “show interface tunnel 0” command:

Tunnel 0 R1

Now it is possible to ping from C1 to C5:

Ping_C1-C5

To verify that the IPv6 traffic is indeed encapsulated in an IPv4 packet use the “debug ip packet detail” command. Protocol 41 has to be present in the packet header:

debug packet

After reading the books and make some configurations, I must conclude that IPv6 isn’t that hard at all. Maybe it is even more straightforward than IPv4, because there is little need for NAT and stuff. Offcourse there are some things to get used like the link local addresses or SLAAC e.g (in a later post more about this). In my opinion it’s just a change of mindset, after doing this IPv6 is easier than IPv4!

To be fully complete below the configuration of router R5:

R5:

!
interface FastEthernet1/0
no ip address
duplex auto
speed auto
ipv6 address 2001:DB8:CAFE:F002::1/64
ipv6 ospf 11 area 0
!
interface FastEthernet2/0
no ip address
duplex auto
speed auto
ipv6 address 2001:DB8:CAFE:F001::2/64
ipv6 ospf 11 area 0
!
ipv6 router ospf 11
router-id 5.5.5.5
log-adjacency-changes
!