DMVPN and SDA
One of the more common DMVPN multi-domain strategies is the integration with SDA. In this scenario, the enterprise has multiple locations where each is an SDA fabric site interconnected via DMVPN. Several approaches may be taken here, depending on the enterprise’s end goals. Therefore, a clear understanding of the extent of macrosegmentation in the DMVPN environment is important for the design. For instance, the goal may be to extend macro- and microsegmentation throughout the DMVPN environment extending into the hub locations. Additionally, what is the design for any guest network or other SDA virtual network that is using VN anchoring? Are there locations where the local DMVPN router should behave as a fusion device between two or more SDA virtual networks?
For each SDA virtual network that requires segmentation across the DMVPN topology, a unique DMVPN tunnel in that VRF must be configured. While existing DMVPN deployments may have already used the global routing table for the DMVPN tunnel source, it is recommended to use an isolated frontdoor VRF (fVRF) for the tunnel source with the service provider. This fVRF provides isolation in the routing table information between the global or corporate routing information that traverses the tunnels and the tunnel source information with the service providers. This also inherently prevents any tunnel recursion issues that must be considered when the tunnel source and the overlay are in the same routing instance. When SDA macrosegmentation integration is added with the DMVPN environment, this will further reduce the overall complexity by having a single VRF used as the fVRF for all of the tunnels across all VRFs.
Note that the various DMVPN tunnels at the spoke sites may not be required at all locations. The tunnel requirement would be based on what SDA virtual networks are configured at a specific location. In Figure 3-11, the red virtual network is extended from one SDA location to one remote location while the blue virtual network exists at both SDA locations and the other remote location. The extension of the SDA virtual network with the DMVPN tunnel topology depends on the placement of the virtual networks, as well as the individual enterprise requirements. From the DMVPN topology to the SDA border node is a dot1Q trunk mapping VLANs to SDA virtual networks. As mentioned in other chapters throughout this book, using standardized VLAN mapping will facilitate smoother and simpler operations in production.
)
Figure 3.11 DMVPN-SDA Topology
After a DMVPN tunnel has been configured for the respective SDA virtual network, adding SGT inline tagging to the tunnel and the interface between the SDA BN and the DMVPN router will allow for microsegmentation propagation.
Example 3-3 illustrates the use of the frontdoor VRF configuration to isolate the transport while the tunnel interface itself is in the corporate VRF with the SGT value propagated. This sample configuration would be for the headend while the remote site would have the relevant NHRP configuration changes.
Example 3-3 DMVPN-SDA Configuration
! Per-VN Tunnel Interface interface Tunnel0 vrf forwarding Corporate ip address 10.0.0.1 255.255.255.0 tunnel vrf Underlay no ip redirects ip mtu 1400 ip nhrp authentication test ip nhrp map multicast dynamic ip nhrp network-id 100000 ip nhrp shortcut ip nhrp redirect ip tcp adjust-mss 1360 tunnel source GigabitEthernet0/0/0 tunnel mode gre multipoint tunnel key 100000 tunnel protection ipsec profile profile-dmvpn shared cts manual propagate sgt !
DMVPN and SDA Policy Enforcement
As mentioned previously, the design requires an understanding of how DMVPN will be utilized to maintain macro- and microsegmentation. As a part of that, the question of policy enforcement should be considered within the DMVPN environment. Will the DMVPN environment simply propagate the segmentation information, will only the headends enforce policy for traffic egressing to the hub locations, or will all DMVPN devices be responsible for policy enforcement?
Based on the answer to this question, configuring policy enforcement on a specific DMVPN device may be required. For instance, if DMVPN is providing enforcement only at the headend locations, then only the hubs will require specific enforcement configuration while the spokes will need only the propagation pieces. This is most likely the most common scenario, as traffic passing between SDA locations will have policy enforcement at the fabric egress point, such as the SDA fabric edge node. There will be migration scenarios where DMVPN is connecting SDA fabric sites with non-SDA sites, including the hub locations.
SDA and DMVPN Best Practices
For migrations to SDA with DMVPN, it would be expected that the DMVPN topology for a single network already exists in the enterprise, and the remote locations are transitioning to SDA. For this scenario, it is recommended to stand up the additional tunnel or tunnels in DMVPN at the hub and required spoke sites first. Routing and connectivity should be validated first prior to the SDA conversion. Here, standardizing tunnel numbers with SDA virtual networks is a good practice to facilitate easier management, operations, and troubleshooting.
Additionally, utilize the existing DMVPN tunnel for the SDA underlay topology. This will ensure that during migration, when devices are being configured in SDA, there will always be connectivity from the SDA underlay management interface with the Catalyst Center in the event that routing or connectivity issues occur in the newly deployed DMVPN tunnels. The overlay traffic will move into the new tunnel topology, leaving just the SDA underlay traffic in the original tunnel system.