DMVPN and ACI
DMVPN with ACI is similar to SD-WAN with ACI with the exception that there is no integration of the APIC with another controller. Just as with the SD-WAN–ACI integration, it is normally expected that macrosegmentation will be maintained between DMVPN and ACI, whereas microsegmentation propagation may not be a requirement. However, just as with the former, microsegmentation propagation may be configured, but again, with the limitation that the EPG mapping is limited to a single ACI context.
As seen in the DMVPN-SDA discussion, multiple DMVPN tunnels will be required on each DMVPN speaker with one tunnel per VRF required for macrosegmentation. It is recommended to use a fVRF for the tunnel source to reduce the complexity associated with ensuring tunnel route recursion does not occur.
Additionally, as discussed in the “SD-WAN and ACI” section earlier, the use of an aggregation layer between the ACI, DMVPN, and legacy environments will facilitate smoother migrations to either ACI, multi-tenant DMVPN, or both.
ACI and DMVPN Segmentation
It is possible with DMVPN to extend both the macrosegmentation and the microsegmentation created in ACI across the WAN topology; however, both are more complicated to configure and manage via the CLI as compared to the Cisco SD-WAN solution.
For macrosegmentation, the DMVPN environment may be made VRF aware by creating multiple DMVPN tunnels on each router for each required VRF. For each tunnel system, a unique NHRP ID and tunnel key should be utilized to ensure the various tunnels remain isolated. The use of CLI templates will greatly reduce the management overhead.
Extending microsegmentation from the ACI environment to the DMVPN environment is much more complicated and requires more manual configuration. In the preceding chapter discussing SDA, the SDA integration with ACI was shown using ISE pxGrid. Via ISE, the ACI EPG information is translated to the Cisco TrustSec SGT information. Using SDA, the Cisco DNA Center facilitates the management of the ISE deployment. With DMVPN, the Cisco TrustSec SGTs would have to be manually administered on ISE and connected to the appropriate ACI EPGs. Additionally, all of the Cisco TrustSec configuration must be manually configured. This would include adding SGT propagation on the DMVPN tunnels themselves, as shown previously, and including SXP peerings to the ISE for each VRF managed.
ACI and DMVPN Best Practices
It is best practice to standardize the DMVPN tunnel numbering for each ACI context with the VLAN used to interconnect the two at the hub locations. If an ACI tenant does not need to be extended to a specific remote site, do not configure that tenant’s tunnel at that site. This will limit the number of IPsec SAs required on each router, as well as the number of NHRP registrations.
If macrosegmentation is to be extended to the remote locations, then the macrosegmentation is inherently maintained via the various VRF tunnels. Microsegmentation propagation must be configured, if desired, using inline tagging on the tunnel configuration. For the remote endpoints in DMVPN to support Cisco TrustSec, they will need to support SXP communication with ISE. The scaling of the latter should be carefully considered because one pair of ISE nodes supports only 200 SXP peerings, which are counted as per VRF per device. Therefore, 20 devices with 10 VRFs each can reach the maximum limitation easily. ISE can scale to support 800 total SXP peerings with eight ISE nodes; however, a better scaling mechanism would be to utilize an SXP reflector—a dedicated router capable of handling a higher quantity of SXP peerings. As shown in Figure 3-12, the user creates an IP-to-SGT mapping on the ISE Policy Administration Node (PAN). This also could have been created dynamically by ISE. The IP-SGT mapping is forwarded to the policy node with the SXP support enabled. The SXP Policy Service Node (PSN) will forward the update to the configured peer SXP Reflectors. The SXP Reflector could be an ASR1002HX or a Catalyst 8500 to facilitate the scaling. On the SXP Reflector side, the SXP peerings are per-VRF; therefore, the SXP Reflector updates only the DMVPN remote endpoints that have the specific VRF. Updates are not sent to other locations. When the SXP Reflector system is used, the load is reduced on the ISE environment while increasing the scale limitations. This does increase the count of devices to manage; however, these additional routers may be considered as server functionality similar to BGP route reflectors because they do not need to participate in the data path.
)
Figure 3.12 SXP Reflector System