on 04-15-2011 03:02 AM
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:
Scenario:
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
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
!
Related Commands:
Suggested Reading:
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?
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 .
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: