Difference between revisions of "Hosting Multiple DMVPNs"
(Created page with "It is possible to host multiple DMVPNs on the same router. This could be used for separating services, such as data and voice. It can also be used in an ISP environment ...") |
|||
| (3 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
It is possible to host multiple [[DMVPN]]s on the same router. This could be used for separating services, such as data and voice. It can also be used in an ISP environment for hosting multiple customers. | It is possible to host multiple [[DMVPN]]s on the same router. This could be used for separating services, such as data and voice. It can also be used in an ISP environment for hosting multiple customers. | ||
| − | Firstly, your hub router(s) need a working internet connection. Each DMVPN will require its own publicly routable /32. Assign it to a loopback interface. It's convenient to set the loopback number to the customer account number, if applicable, or to some other sort of unique number. Be sure that the /32 is reachable from the internet. | + | ==Hub Configuration== |
| + | Firstly, your hub router(s) need a working internet connection. I'm not going to cover that part. | ||
| + | |||
| + | Each DMVPN will require its own publicly routable /32. Assign it to a loopback interface. It's convenient to set the loopback number to the customer account number, if applicable, or to some other sort of unique number. Be sure that the /32 is reachable from the internet. | ||
<PRE> | <PRE> | ||
| Line 24: | Line 27: | ||
rd 2112:1 | rd 2112:1 | ||
</PRE> | </PRE> | ||
| + | |||
| + | Now create the tunnel interface for this service. Note I am using the customer number for the tunnel number and the NHRP network ID. The subnet used on the tunnel interface must also be available within the VRF. Also note that the tunnel protection profile is just a generic profile, not specifically tied to one customer. This can be used to offer varying degrees of security and performance. | ||
| + | |||
| + | <PRE> | ||
| + | interface Tunnel2112 | ||
| + | description TUNNEL FOR CUSTOMER #2112 | ||
| + | ip vrf forwarding CUSTOMER2112 | ||
| + | ip address 10.10.10.1 255.255.255.0 | ||
| + | ip nhrp map multicast dynamic | ||
| + | ip nhrp network-id 2112 | ||
| + | ip ospf network broadcast | ||
| + | ip ospf priority 128 | ||
| + | tunnel source Loopback2112 | ||
| + | tunnel mode gre multipoint | ||
| + | tunnel protection ipsec profile DMVPN_PROFILE-AES-MD5 | ||
| + | </PRE> | ||
| + | |||
| + | Create a routing protocol process for the customer. | ||
| + | |||
| + | <PRE> | ||
| + | router ospf 2112 vrf CUSTOMER2112 | ||
| + | router-id 10.10.10.1 | ||
| + | network 10.10.10.0 0.0.0.255 area 0 | ||
| + | </PRE> | ||
| + | |||
| + | This DMVPN service can exist solely on this router, or it can be connected to an existing IPVPN using VRF Lite or MPLS. | ||
| + | |||
| + | ==Spoke Configuration== | ||
| + | As shown in the [[DMVPN]] article, the spoke configuration is largely the same as the hub. This is the same when working with multiple DMVPNs. Multiple VRFs can be created on the spoke, each with its own tunnel interface, network ID, and crypto profile. | ||
| + | |||
| + | Even if only one service is to be configured on the spoke, it is still a good idea to use a VRF. It has the advantage of separating the private network from the internet. This is also good when local internet is not desired at the spoke site, and all traffic should flow through centralized firewalls. A default route can be injected into the VRF. This can easily be accomplished by putting all the DMVPN sites into an OSPF totally stubby area, which also has the benefit of minimizing routing updates sent to the spokes. | ||
Latest revision as of 21:36, 7 April 2015
It is possible to host multiple DMVPNs on the same router. This could be used for separating services, such as data and voice. It can also be used in an ISP environment for hosting multiple customers.
Hub Configuration
Firstly, your hub router(s) need a working internet connection. I'm not going to cover that part.
Each DMVPN will require its own publicly routable /32. Assign it to a loopback interface. It's convenient to set the loopback number to the customer account number, if applicable, or to some other sort of unique number. Be sure that the /32 is reachable from the internet.
interface Loopback2112 description WAN IP FOR CUSTOMER #2112 ip address 192.0.2.1 255.255.255.255
This service will need its own encryption key. This key is then tied to the loopback interface. It is also set to match remote hosts with any IP (0.0.0.0/0)
crypto keyring CUSTOMER2112 local-address Loopback2112 pre-shared-key address 0.0.0.0 0.0.0.0 key aw3s0m3crypt0k3y
Create a VRF for this service. The RD can be assigned from your global MPLS setup, if applicable, or can be anything if you are just running VRF Lite.
ip vrf CUSTOMER2112 description VRF FOR CUSTOMER #2112 rd 2112:1
Now create the tunnel interface for this service. Note I am using the customer number for the tunnel number and the NHRP network ID. The subnet used on the tunnel interface must also be available within the VRF. Also note that the tunnel protection profile is just a generic profile, not specifically tied to one customer. This can be used to offer varying degrees of security and performance.
interface Tunnel2112 description TUNNEL FOR CUSTOMER #2112 ip vrf forwarding CUSTOMER2112 ip address 10.10.10.1 255.255.255.0 ip nhrp map multicast dynamic ip nhrp network-id 2112 ip ospf network broadcast ip ospf priority 128 tunnel source Loopback2112 tunnel mode gre multipoint tunnel protection ipsec profile DMVPN_PROFILE-AES-MD5
Create a routing protocol process for the customer.
router ospf 2112 vrf CUSTOMER2112 router-id 10.10.10.1 network 10.10.10.0 0.0.0.255 area 0
This DMVPN service can exist solely on this router, or it can be connected to an existing IPVPN using VRF Lite or MPLS.
Spoke Configuration
As shown in the DMVPN article, the spoke configuration is largely the same as the hub. This is the same when working with multiple DMVPNs. Multiple VRFs can be created on the spoke, each with its own tunnel interface, network ID, and crypto profile.
Even if only one service is to be configured on the spoke, it is still a good idea to use a VRF. It has the advantage of separating the private network from the internet. This is also good when local internet is not desired at the spoke site, and all traffic should flow through centralized firewalls. A default route can be injected into the VRF. This can easily be accomplished by putting all the DMVPN sites into an OSPF totally stubby area, which also has the benefit of minimizing routing updates sent to the spokes.