To configure vrfs on the DMVPN hub so as to seperate the routing tables for multiple DMVPN clouds.
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.
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 rdroute-distinguishercommand in VRF configuration mode. The rdroute-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.