DMVPN With Multiple VRFs - Revision history

Casey at 16:00, 21 December 2017

2017-12-21T16:00:30Z

Casey at 16:00, 21 December 2017

2017-12-21T16:00:21Z

Casey at 16:00, 21 December 2017

2017-12-21T16:00:07Z

Casey at 03:28, 1 July 2015

2015-07-01T03:28:04Z

Casey at 03:27, 1 July 2015

2015-07-01T03:27:39Z

Casey at 03:27, 1 July 2015

2015-07-01T03:27:16Z

Casey at 03:26, 1 July 2015

2015-07-01T03:26:57Z

Casey at 03:24, 1 July 2015

2015-07-01T03:24:18Z

Casey: Created page with "This is similar to Hosting Multiple DMVPNs. In that article, I wrote how a Cisco router can host multiple DMVPNs. This assumes that each CPE router only connects to one..."

2015-07-01T03:18:24Z

Created page with "This is similar to Hosting Multiple DMVPNs. In that article, I wrote how a Cisco router can host multiple DMVPNs. This assumes that each CPE router only connects to one..."

New page

This is similar to [[Hosting Multiple DMVPNs]]. In that article, I wrote how a Cisco router can host multiple DMVPNs. This assumes that each CPE router only connects to one of the VRFs on the headend router(s). This time, I'll show how to set up multiple VRFs on the headend and the CPE.

← Older revision		Revision as of 16:00, 21 December 2017
Line 1:		Line 1:
−	This is similar to [[Hosting Multiple DMVPNs]]. In that article, I wrote how a Cisco router can host multiple DMVPNs. This assumes that each spoke router only connects to one of the VRFs on the ~~hubrouter~~(s). This time, I'll show how to set up multiple VRFs on the hub and the spoke. This would be useful in cases where separate but similar services need to be delivered to a site, for example data and voice access.	+	This is similar to [[Hosting Multiple DMVPNs]]. In that article, I wrote how a Cisco router can host multiple DMVPNs. This assumes that each spoke router only connects to one of the VRFs on the hub router(s). This time, I'll show how to set up multiple VRFs on the hub and the spoke. This would be useful in cases where separate but similar services need to be delivered to a site, for example data and voice access.

	==Spoke Config==		==Spoke Config==

← Older revision		Revision as of 16:00, 21 December 2017
Line 1:		Line 1:
−	This is similar to [[Hosting Multiple DMVPNs]]. In that article, I wrote how a Cisco router can host multiple DMVPNs. This assumes that each spoke router only connects to one of the VRFs on the hubrouter(s). This time, I'll show how to set up multiple VRFs on the ~~huband~~ the spoke. This would be useful in cases where separate but similar services need to be delivered to a site, for example data and voice access.	+	This is similar to [[Hosting Multiple DMVPNs]]. In that article, I wrote how a Cisco router can host multiple DMVPNs. This assumes that each spoke router only connects to one of the VRFs on the hubrouter(s). This time, I'll show how to set up multiple VRFs on the hub and the spoke. This would be useful in cases where separate but similar services need to be delivered to a site, for example data and voice access.

	==Spoke Config==		==Spoke Config==

← Older revision		Revision as of 16:00, 21 December 2017
Line 1:		Line 1:
−	This is similar to [[Hosting Multiple DMVPNs]]. In that article, I wrote how a Cisco router can host multiple DMVPNs. This assumes that each ~~spokerouter~~ only connects to one of the VRFs on the hubrouter(s). This time, I'll show how to set up multiple VRFs on the huband the spoke. This would be useful in cases where separate but similar services need to be delivered to a site, for example data and voice access.	+	This is similar to [[Hosting Multiple DMVPNs]]. In that article, I wrote how a Cisco router can host multiple DMVPNs. This assumes that each spoke router only connects to one of the VRFs on the hubrouter(s). This time, I'll show how to set up multiple VRFs on the huband the spoke. This would be useful in cases where separate but similar services need to be delivered to a site, for example data and voice access.

	==Spoke Config==		==Spoke Config==

@@ Line 26: / Line 26: @@
   tunnel source Ethernet1
   tunnel mode gre multipoint
-  '''tunnel key 2112'''
+  tunnel key 2112
   tunnel protection ipsec profile DMVPN_PROFILE shared
+!

@@ Line 26: / Line 26: @@
   tunnel source Ethernet1
   tunnel mode gre multipoint
-  tunnel key 2112
+  '''tunnel key 2112'''
   tunnel protection ipsec profile DMVPN_PROFILE shared
+!

@@ Line 1: / Line 1: @@
 This is similar to [[Hosting Multiple DMVPNs]].  In that article, I wrote how a Cisco router can host multiple DMVPNs.  This assumes that each spokerouter only connects to one of the VRFs on the hubrouter(s).  This time, I'll show how to set up multiple VRFs on the huband the spoke.  This would be useful in cases where separate but similar services need to be delivered to a site, for example data and voice access.
 First, define any VRFs:
@@ Line 9: / Line 11: @@
 </PRE>
 Next, set up your tunnel interfaces.
 <PRE>

@@ Line 1: / Line 1: @@
-This is similar to [[Hosting Multiple DMVPNs]].  In that article, I wrote how a Cisco router can host multiple DMVPNs.  This assumes that each CPE router only connects to one of the VRFs on the headend router(s).  This time, I'll show how to set up multiple VRFs on the headend and the CPE.  This would be useful in cases where separate but similar services need to be delivered to a site, for example data and voice access.
+This is similar to [[Hosting Multiple DMVPNs]].  In that article, I wrote how a Cisco router can host multiple DMVPNs.  This assumes that each spokerouter only connects to one of the VRFs on the hubrouter(s).  This time, I'll show how to set up multiple VRFs on the huband the spoke.  This would be useful in cases where separate but similar services need to be delivered to a site, for example data and voice access.
 First, define any VRFs:
@@ Line 9: / Line 9: @@
 </PRE>
 Next, set up your tunnel interfaces.
 <PRE>
@@ Line 51: / Line 52: @@
 * The tunnels are using the same WAN interface and the same IPSec profile.
 * The IPSec profile is shared

← Older revision		Revision as of 03:24, 1 July 2015
Line 1:		Line 1:
−	This is similar to [[Hosting Multiple DMVPNs]]. In that article, I wrote how a Cisco router can host multiple DMVPNs. This assumes that each CPE router only connects to one of the VRFs on the headend router(s). This time, I'll show how to set up multiple VRFs on the headend and the CPE.	+	This is similar to [[Hosting Multiple DMVPNs]]. In that article, I wrote how a Cisco router can host multiple DMVPNs. This assumes that each CPE router only connects to one of the VRFs on the headend router(s). This time, I'll show how to set up multiple VRFs on the headend and the CPE. This would be useful in cases where separate but similar services need to be delivered to a site, for example data and voice access.
		+
		+	First, define any VRFs:
		+	<PRE>
		+	ip vrf DATA
		+	rd 1:1
		+	ip vrf VOICE
		+	rd 1:2
		+	</PRE>
		+
		+	Next, set up your tunnel interfaces.
		+	<PRE>
		+	interface Tunnel2112
		+	description DMVPN TUNNEL TO OTHER SITES - DATA
		+	ip vrf forwarding DATA
		+	ip address 10.10.10.3 255.255.255.0
		+	ip nhrp map 10.10.10.1 192.0.2.1
		+	ip nhrp map multicast 192.0.2.1
		+	ip nhrp map 10.10.10.2 203.0.113.28
		+	ip nhrp map multicast 203.0.113.28
		+	ip nhrp network-id 2112
		+	ip nhrp nhs 10.10.10.1
		+	ip nhrp nhs 10.10.10.2
		+	tunnel source Ethernet1
		+	tunnel mode gre multipoint
		+	tunnel key 2112
		+	tunnel protection ipsec profile DMVPN_PROFILE shared
		+	!
		+	interface Tunnel3113
		+	description DMVPN TUNNEL TO OTHER SITES - VOICE
		+	ip vrf forwarding VOICE
		+	ip address 10.11.11.3 255.255.255.0
		+	ip nhrp map 10.11.11.1 192.0.2.1
		+	ip nhrp map multicast 192.0.2.1
		+	ip nhrp map 10.11.11.2 203.0.113.28
		+	ip nhrp map multicast 203.0.113.28
		+	ip nhrp network-id 3113
		+	ip nhrp nhs 10.11.11.1
		+	ip nhrp nhs 10.11.11.2
		+	tunnel source Ethernet1
		+	tunnel mode gre multipoint
		+	tunnel key 3113
		+	tunnel protection ipsec profile DMVPN_PROFILE shared
		+	</PRE>
		+
		+	Note the differences between this and the standard config:
		+	* Each service is in a separate VRF
		+	* Both tunnel interfaces are using the same WAN IPs for the headends. They do have different private IPs mapped to them though.
		+	* Each service uses a separate network-id
		+	* Each service has a tunnel key assigned. The value of the key does not need to match the network-id number.
		+	* The tunnels are using the same WAN interface and the same IPSec profile.
		+	* The IPSec profile is shared