|
|
In a hub-and-spoke DMVPN design, one mGRE interface is required on the hub router for all spokes. Dynamically addressed spokes are supported when using the NHRP registration process. When new spokes are added, no changes are required on the hub configuration. The important thing to note is that spoke-to-spoke traffic will traverse via the hub.
Figure 16-5 shows how the NHRP registration process works in a hub-and-spoke DMVPN design. Spokes register their real address to the hub by using the NHRP registration process for dynamically addressed spokes. Using the NHRP mapping, corresponding routing table entries are created for the neighbor's private subnets.
Based on Figure 16-5, Example 16-1 (Hub), Example 16-2 (Spoke1), and Example 16-3 (Spoke2) provide basic configuration examples using EIGRP in the implementation of a single-hub DMVPN topology scenario in a hub-and-spoke design.
|
Code View: hostname Hub <..> ! Define Phase 1 SA parameters crypto isakmp policy 10 encr 3des authentication pre-share group 2 crypto isakmp key dmvpnkey address 0.0.0.0 0.0.0.0 ! ! Define IPsec encryption and authentication algorithms crypto ipsec transform-set mytran esp-3des esp-sha-hmac ! ! Define Phase 2 Parameters - IPsec Profile (set peer & match ACL not required) crypto ipsec profile vpnprof set transform-set mytran ! ! Interface that is connected to the private side of the network for encryption interface Loopback0 ! description LAN Private Subnet ip address 10.0.0.1 255.255.255.0 ! interface Tunnel0 ! description DMVPN HUB bandwidth 1000 ! Define Tunnel IP address ip address 172.16.1.11 255.255.255.0 ip mtu 1400 ! Define NHRP Server settings ip nhrp authentication cisco ip nhrp map multicast dynamic ip nhrp network-id 123 ip nhrp holdtime 360 no ip split-horizon eigrp 100 delay 1000 ip tcp adjust-mss 1360 tunnel source GigabitEthernet0/0 ! Define Multipoint GRE Type interface tunnel mode gre multipoint ! Define Tunnel key to Secure GRE interface tunnel key 12345 !Apply IPsec profile Tunnel Protection tunnel protection ipsec profile vpnprof ! ! Egress interface with known static IP (No ACL or Crypto map) interface GigabitEthernet0/0 ip address 11.11.11.11 255.255.255.0 <..> ! Define Dynamic Routing Protocol to advertise PRIVATE Subnets via Tunnel router eigrp 100 network 172.16.1.0 0.0.0.255 network 10.0.0.0 0.0.0.255 no auto-summary ! <..> |
Tip
In a hub-and-spoke design, the hub router is configured with a multipoint GRE tunnel interface, and spoke routers are configured with a point-to-point GRE (p-pGRE) tunnel interface.
|
Code View: hostname Spoke1 <..> ! Define Phase 1 SA parameters crypto isakmp policy 10 encr 3des authentication pre-share group 2 crypto isakmp key dmvpnkey address 0.0.0.0 0.0.0.0 ! ! Define IPsec encryption and authentication algorithms crypto ipsec transform-set mytran esp-3des esp-sha-hmac ! ! Define Phase 2 Parameters - IPsec Profile (set peer & match ACL not required) crypto ipsec profile vpnprof set transform-set mytran ! ! Interface that is connected to the private side of the network for encryption interface Loopback0 ! description LAN Private Subnet ip address 10.1.1.1 255.255.255.0 ! interface Tunnel0 ! description DMVPN Spoke1 bandwidth 1000 ! Define Tunnel IP address ip address 172.16.1.1 255.255.255.0 ip mtu 1400 ! Define NHRP Spoke settings with Static Mapping ip nhrp authentication cisco ip nhrp map 172.16.1.11 11.11.11.11 ! Network ID must match with Server ip nhrp network-id 123 ip nhrp holdtime 360 ip nhrp nhs 172.16.1.11 delay 1000 ip tcp adjust-mss 1360 tunnel source FastEthernet0/0 ! Define Point-to-Point GRE Type interface (Spoke-to-Spoke traffic will traverse via the Hub) See the routing table of Spoke1 below tunnel destination 11.11.11.11 ! Define Tunnel key to Secure GRE interface tunnel key 12345 !Apply IPsec profile Tunnel Protection tunnel protection ipsec profile vpnprof ! ! Egress interface with unknown IP (No ACL or Crypto map). In this example, we are statically defining IP, but this can be dynamically obtained interface FastEthernet0/0 ip address 11.11.11.1 255.255.255.0 ! <..> ! Define Dynamic Routing Protocol to advertise PRIVATE Subnets via Tunnel router eigrp 100 network 172.16.1.0 0.0.0.255 network 10.1.1.0 0.0.0.255 no auto-summary ! <..> |
|
Code View: hostname Spoke2 <..> ! Define Phase 1 SA parameters crypto isakmp policy 10 encr 3des authentication pre-share group 2 crypto isakmp key dmvpnkey address 0.0.0.0 0.0.0.0 ! ! Define IPsec encryption and authentication algorithms crypto ipsec transform-set mytran esp-3des esp-sha-hmac ! ! Define Phase 2 Parameters - IPsec Profile (set peer & match ACL not required) crypto ipsec profile vpnprof set transform-set mytran ! ! Interface that is connected to the private side of the network for encryption interface Loopback0 ! description LAN Private Subnet ip address 10.2.2.2 255.255.255.0 ! interface Tunnel0 ! description DMVPN Spoke2 bandwidth 1000 ! Define Tunnel IP address ip address 172.16.1.2 255.255.255.0 ip mtu 1400 ! Define NHRP Spoke settings with Static Mapping ip nhrp authentication cisco ip nhrp map 172.16.1.11 11.11.11.11 ! Network ID must match with Server ip nhrp network-id 123 ip nhrp holdtime 360 ip nhrp nhs 172.16.1.11 delay 1000 ip tcp adjust-mss 1360 tunnel source GigabitEthernet0/0 ! Define Point-to-Point GRE Type interface (Spoke-to-Spoke traffic will traverse via the Hub) See the routing table of Spoke1 below tunnel destination 11.11.11.11 ! Define Tunnel key to Secure GRE interface tunnel key 12345 !Apply IPsec profile Tunnel Protection tunnel protection ipsec profile vpnprof ! ! Egress interface with unknown IP (No ACL or Crypto map). In this example, we are statically defining IP, but this can be dynamically obtained interface GigabitEthernet0/0 ip address 11.11.11.2 255.255.255.0 ! <..> ! Define Dynamic Routing Protocol to advertise PRIVATE Subnets via Tunnel router eigrp 100 network 172.16.1.0 0.0.0.255 network 10.2.2.0 0.0.0.255 no auto-summary ! <..> |
Based on Figure 16-5 and the configuration on the hub-and-spoke routers shown in Examples 16-1, 16-2, and 16-3, Example 16-4 presents outputs that illustrate the verification of the dynamic routing table (EIGRP), the NHRP mapping, and the crypto socket table entries as explained in the "DMVPN Data Structures" section of this chapter.
Hub# show ip route | include 10. 10.0.0.0/24 is subnetted, 3 subnets D 10.2.2.0 [90/2944000] via 172.16.1.2, 00:27:58, Tunnel0 D 10.1.1.0 [90/2944000] via 172.16.1.1, 00:33:16, Tunnel0 C 10.0.0.0 is directly connected, Loopback0 <..> Spoke1# show ip route | include 10. 10.0.0.0/24 is subnetted, 3 subnets D 10.2.2.0 [90/3200000] via 172.16.1.11, 00:27:41, Tunnel0 C 10.1.1.0 is directly connected, Loopback0 D 10.0.0.0 [90/2944000] via 172.16.1.11, 00:33:00, Tunnel0 <..> Spoke2# show ip route | include 10. 10.0.0.0/24 is subnetted, 3 subnets C 10.2.2.0 is directly connected, Loopback0 D 10.1.1.0 [90/3200000] via 172.16.1.11, 00:27:52, Tunnel0 D 10.0.0.0 [90/2944000] via 172.16.1.11, 00:27:52, Tunnel0 <..> |
Tip
Observe the routing table entries on the spokes. All spoke LAN private subnets are routed via the hub router. That is, spoke-to-spoke communication is via the hub in this model. In hub-and-spoke design, routing information is not exchanged with the spoke router because multicast traffic has not been mapped in NHRP settings. This will be addressed in a dynamic mesh spoke-to-spoke design presented later in this chapter.
Hub# show ip nhrp 172.16.1.1/32 via 172.16.1.1, Tunnel0 created 00:41:22, expire 00:04:34 Type: dynamic, Flags: authoritative unique registered NBMA address: 11.11.11.1 172.16.1.2/32 via 172.16.1.2, Tunnel0 created 00:35:17, expire 00:04:36 Type: dynamic, Flags: authoritative unique registered NBMA address: 11.11.11.2 <..> Spoke1# show ip nhrp 172.16.1.11/32 via 172.16.1.11, Tunnel0 created 00:43:02, never expire Type: static, Flags: authoritative NBMA address: 11.11.11.11 <..> Spoke2# show ip nhrp 172.16.1.11/32 via 172.16.1.11, Tunnel0 created 00:35:46, never expire Type: static, Flags: authoritative NBMA address: 11.11.11.11 |
Tip
NHRP mapping table entries on the hub show dynamic type, whereas static type is used on the spokes because they are manually defined on the spoke routers.
|
Code View: Hub# show crypto sockets Number of Crypto Socket connections 2 Tu0 Peers (local/remote): 11.11.11.11/11.11.11.2 Local Ident (addr/mask/port/prot): (11.11.11.11/255.255.255.255/0/47) Remote Ident (addr/mask/port/prot): (11.11.11.2/255.255.255.255/0/47) Socket State: Open Client: "TUNNEL SEC" (Client State: Active) Tu0 Peers (local/remote): 11.11.11.11/11.11.11.1 Local Ident (addr/mask/port/prot): (11.11.11.11/255.255.255.255/0/47) Remote Ident (addr/mask/port/prot): (11.11.11.1/255.255.255.255/0/47) Socket State: Open Client: "TUNNEL SEC" (Client State: Active) Crypto Sockets in Listen state: Client: "TUNNEL SEC" Profile: "vpnprof" Map-name: "Tunnel0-head-0" <..> Spoke1# show crypto sockets Number of Crypto Socket connections 1 Tu0 Peers (local/remote): 11.11.11.1/11.11.11.11 Local Ident (addr/mask/port/prot): (11.11.11.1/255.255.255.255/0/47) Remote Ident (addr/mask/port/prot): (11.11.11.11/255.255.255.255/0/47) Socket State: Open Client: "TUNNEL SEC" (Client State: Active) Crypto Sockets in Listen state: Client: "TUNNEL SEC" Profile: "vpnprof" Map-name: "Tunnel0-head-0" <..> Spoke2# show crypto sockets Number of Crypto Socket connections 1 Tu0 Peers (local/remote): 11.11.11.2/11.11.11.11 Local Ident (addr/mask/port/prot): (11.11.11.2/255.255.255.255/0/47) Remote Ident (addr/mask/port/prot): (11.11.11.11/255.255.255.255/0/47) Socket State: Open Client: "TUNNEL SEC" (Client State: Active) Crypto Sockets in Listen state: Client: "TUNNEL SEC" Profile: "vpnprof" Map-name: "Tunnel0-head-0" |
The deployment of dual hub-and-spoke DMVPN is similar to the previous design of single hub DMVPN, except that there are two hub routers to achieve redundancy for the DMVPN networks. Dual hub design offers two hub-and-spoke topologies in an overlay fashion. It is also important to note that in the dual hub design, both hubs are connected through a LAN interface and should not be logically separated. (They should have the same routing table entries for connected interfaces.) The configuration is similar to previous examples, with one mGRE tunnel interface on each hub router, and two separate point-to-point GRE (p-to-pGRE) tunnel interfaces on each spoke that points to the respective hubs.
Figure 16-6 illustrates the dual hub DMVPN design.
Note
Dual hub-and-spoke dual DMVPN topology also supports the load-balancing feature for routing traffic between selected hubs. This can be controlled via the dynamic routing protocol.
Cisco VPN solution offers various features to provide VPN redundancy and load-balancing capabilities. For small-scale IPsec deployments, a combination of Cisco Hot Standby Router Protocol (HSRP) and Reverse Route Injection (RRI) features can be used to provide redundancy. For large-scale VPN deployments, the Cisco Server Load-Balancing (SLB) feature can be used to provide redundancy as well as load balancing.
The SLB architecture defines a virtual server that combines a group of physical (real) servers in a virtual cluster (also known as a server farm). When the spoke initiates an IPsec tunnel, the SLB server chooses an appropriate physical server for the connection based on the SLB algorithm configured. If the physical server in the cluster goes down, it is removed from the cluster, and all new IPsec connections are rerouted to an alternative physical server dynamically.
Figure 16-7, with the list that follows, explains how SLB works in a DMVPN design:
The SLB design is transparent to the spokes. Spokes are configured with a single Next Hop Server (NHS). Spokes have an NHRP map pointing to the load balancer Virtual IP Address (VIP).
The configuration on the spoke remains the same, as illustrated in the single hub-and-spoke design discussion earlier.
The load balancer must be configured in forwarding mode (with no NAT).
The load balancer owns the VIP.
When IKE, ESP, or GRE packets are targeted at the VIP, the load balancer chooses a hub, based on a predictor policy (weighted round-robin, least-connections). All subsequent packets for that connection go to the same hub (stickiness).
All the hub routers in the server farm have the same configuration as the same tunnel interface, and a loopback address, which is the same as the VIP address on the load balancer.
Figure 16-7 illustrates the converged Server Load Balancing (SLB) in a converged DMVPN design.
Note
Refer to the following Cisco white paper to learn more about Server Load Balancing (SLB) for converged DMVPN and a sample configuration example: http://www.cisco.com/en/US/products/ps6660/products_white_paper0900aecd8051bf3b.shtml.
|
|