Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 

Using VRFs to segregate DMVPN clouds on Hub

Objective:

To configure vrfs on the DMVPN hub so as to seperate the routing tables for multiple DMVPN clouds.

Problem Description:

In some cases users want to deploy DMPVN for multiple customers from the same hub site. In this case it makes sense both in terms of security as well as usability to completely segregate the routing for each cloud. The VRF feature, also known as VPN Route Forwarding can help us do exactly this.

Prerequisites:

  1. DMVPN Design guide
  2. Basic DMVPN configuration guide
  3. VRF integrated DMVPN

Scenario:

DMVPN with VRFs.png

Solution:

A VRF instance is a per-VPN routing information repository that defines the VPN membership of a customer site attached to the Provider Edge (PE) router. A VRF comprises an IP routing table, a derived Cisco Express Forwarding (CEF) table, a set of interfaces that use the forwarding table, and a set of rules and routing protocol parameters that control the information that is included in the routing table. A separate set of routing and Cisco Express Forwarding (CEF) tables is maintained for each VPN customer. For more information regarding the VRF aware IPSEC feature, please refer to the previous document.

Usually this feature is used in tandem with MPLS VPN to provide per customer VPN  membership. However, in this particular set up we will only be configuring the hub with VRFs to distinguish the routing tables for each customer LOCALLY on the hub. The configuration on the spokes need not be modified from the generic DMVPN configuration in any way, unless the spokes  are also being shared by multiple customers. In this particular design only the hub is being shared by customers.

There are two attributes that are used by the VRF to distinguish which route belongs to which routing table:

1. Route Distinguisher:

To make the VRF functional, a route distinguisher (RD) must be created using the rd route-distinguishercommand in VRF configuration mode. The rd route-distinguisher command creates the routing and forwarding tables and associates the RD with the VRF instance named vrf-name. The RD value only has local significance to the router on which it is configured. This value is not propagated in anyway to any upstream or downstram routers, but it is used by the router itself to identify which VRF a particular route/packet belongs to. In our current setup, this is the only attribute that is important.

The same RD value cannot be configured in multiple VRFs. There are two formats for configuring the route distinguisher argument. It can be configured in the autonomous-system-number:network-number format, or it can be configured in the IP address:network-number format.

An RD is either:

•autonomous system-related—Composed of an autonomous system number and an arbitrary number.

•IP address-related—Composed of an IP address and an arbitrary number.

2. Route Target:

The distribution of VPN routing information is controlled through the use of VPN route target communities, implemented by border gateway protocol (BGP) extended communities. This attribute is of use when you want to import routes learnt via one vpn system into another. In our particular set up we will not be using Route Targets. For more information on Route Targets please refer to the document VPN Route Target Communities

Once the VRF is created a particular interface can be mapped to a specific VRF by using the ip vrf forwarding <vrf_name> command under that particular interface.

Configuration:

Configuration on Hub:

hostname Hub1

!

ip vrf CuA

  rd 1:1

!

ip vrf CuB

  rd 1:2

!

ip cef

!

crypto isakmp policy 1

  encr 3des

  hash md5

  authentication pre-share

  group 2

crypto isakmp key cisco123 address 0.0.0.0 0.0.0.0

!

crypto ipsec transform-set dmvpn-trans esp-3des esp-md5-hmac

  mode transport

!

crypto ipsec profile dmvpn-pro

  set transform-set dmvpn-trans

!

interface Tunnel1

  ip vrf forwarding CuA

  ip address 172.16.0.1 255.255.255.0

  no ip redirects

  ip mtu 1400

  ip nhrp authentication cisco123

  ip nhrp map multicast dynamic

  ip nhrp network-id 1

  ip nhrp holdtime 600

  no ip split-horizon eigrp 1

  tunnel source Ethernet0/1

  tunnel mode gre multipoint

  tunnel key 10000

  tunnel protection ipsec profile dmvpn-pro shared

!

interface Tunnel2

  ip vrf forwarding CuB

  ip address 172.16.2.1 255.255.255.0

  no ip redirects

  ip mtu 1400

  ip nhrp authentication cisco123

  ip nhrp map multicast dynamic

  ip nhrp network-id 2

  ip nhrp holdtime 600

  no ip split-horizon eigrp 2

  tunnel source Ethernet0/1

  tunnel mode gre multipoint

  tunnel key 20000

  tunnel protection ipsec profile dmvpn-pro shared

!

interface Ethernet0/0

  ip vrf forwarding CuA

  ip address 10.10.10.1 255.255.255.0

!

interface Ethernet0/1

ip address 1.1.1.1 255.255.255.0

!

interface Ethernet0/2

  ip vrf forwarding CuB

  ip address 10.10.10.1 255.255.255.0

!

router eigrp 1

  auto-summary

  address-family ipv4 vrf CuA

    network 10.10.10.0 0.0.0.255

    network 172.16.0.0 0.0.0.255

    auto-summary

    autonomous-system 1

  exit-address-family

!

router eigrp 2

  auto-summary

  address-family ipv4 vrf CuB

    network 10.10.10.0 0.0.0.255

    network 172.16.2.0 0.0.0.255

    auto-summary

    autonomous-system 2

  exit-address-family

!

ip forward-protocol nd

ip route 0.0.0.0 0.0.0.0 1.1.1.2

!

!

end

Configuration on Spoke 1:

hostname Spoke1

!

ip cef

!

crypto isakmp policy 1

  encr 3des

  hash md5

  authentication pre-share

  group 2

crypto isakmp key cisco123 address 0.0.0.0 0.0.0.0

!

crypto ipsec transform-set dmvpn-trans esp-3des esp-md5-hmac

  mode transport

!

crypto ipsec profile dmvpn-pro

  set transform-set dmvpn-trans

!

interface Tunnel1

  ip address 172.16.0.2 255.255.255.0

  ip mtu 1400

  ip nhrp authentication cisco123

  ip nhrp map multicast 1.1.1.1

  ip nhrp map 172.16.0.1 1.1.1.1

  ip nhrp network-id 1

  ip nhrp holdtime 600

  ip nhrp nhs 172.16.0.1

  no ip split-horizon eigrp 1

  tunnel source Ethernet0/1

  tunnel destination 1.1.1.1

  tunnel key 10000

  tunnel protection ipsec profile dmvpn-pro

!

interface Ethernet0/0

  ip address 192.168.10.1 255.255.255.0

!

interface Ethernet0/1

  ip address 4.4.4.1 255.255.255.0

!

router eigrp 1

  network 172.16.0.0 0.0.0.255

  network 192.168.10.0

  auto-summary

!

ip forward-protocol nd

ip route 0.0.0.0 0.0.0.0 4.4.4.2

!

end

Configuration on Spoke 2:

hostname spoke2

!

ip cef

no ipv6 cef

!

crypto isakmp policy 1

  encr 3des

  hash md5

  authentication pre-share

  group 2

crypto isakmp key cisco123 address 0.0.0.0 0.0.0.0

!

crypto ipsec transform-set dmvpntrans esp-3des esp-md5-hmac

  mode transport

!

crypto ipsec profile spoke2prof

  set transform-set dmvpntrans

!

interface Loopback0

  ip address 30.30.30.1 255.255.255.0

!

interface Tunnel2

  ip address 172.16.2.2 255.255.255.0

  ip mtu 1400

  ip nhrp authentication cisco123

  ip nhrp map multicast 1.1.1.1

  ip nhrp map 172.16.2.1 1.1.1.1

  ip nhrp network-id 2

  ip nhrp holdtime 600

  ip nhrp nhs 172.16.2.1

  no ip split-horizon eigrp 2

  tunnel source Ethernet0/0

  tunnel destination 1.1.1.1

  tunnel key 20000

  tunnel protection ipsec profile dmvpn-pro

!

interface Ethernet0/0

  ip address 3.3.3.1 255.255.255.0

!

router eigrp 2
  network 30.30.30.0 0.0.0.255
  network 172.16.2.0 0.0.0.255
  auto-summary
!
ip forward-protocol nd
ip route 0.0.0.0 0.0.0.0 3.3.3.2
!
end

Related Commands:

  1. show ip route vrf <vrf_name>
  2. ping vrf <vrf_name> <destination_ip_address>
  3. show crypto isakmp sa
  4. show crypto ipsec sa vrf <vrf_name>

Suggested Reading:

  1. VRF-Aware IPsec
  2. Next Generation Enterprise MPLS VPN-Based WAN Design and Implementation Guide
  3. Using FVRF and IVRF in DMVPN
Comments
New Member

What if I have two hub routers with two different dmvpn tunnels going to one customer router. Would I need to configure VRF on the customer router?

New Member

You have an issue in configuration that if you disabled Tunnel 2 >> Tunnel 1 HUB and it's spokes will be Fine .

But Enabling Tunnel 2 >> will cause Tunel 1 Spokes Not fully authenticated into HUB .

Had the same Issue .

your should Configure this command in each HUB Tunnel  :

 ip tcp adjust-mss 1360

Best Regards .

no, if u have only 1 customer u don't need VRF. VRF separate different networks , so u may have the same ip addressing scheme  in 2 diff. VRF , because they create 2 diff. routing tables.  Only the reason to have 2 HUB routers for 1 spoke is to have redundancy .

17473
Views
20
Helpful
3
Comments