SD-WAN and SDA
Cisco’s Software Defined Access, or SDA, allows the enterprise to introduce macro- and microsegmentation with automation and assurance at the local campus environment. Hosts may be dynamically or statically classified into virtual networks (macrosegmentation) and security groups (microsegmentation). When discussing SDA, it is important to remember that the control plane is based on LISP, whereas the data plane uses VXLAN.
In a multi-site SDA deployment without integration into other domains, the architect must plan for policy enforcement and ensure that the virtual network identifier (VNID) and security group tag (SGT) information is correctly propagated across either an IP transit environment or via SDA-Transit. SD-WAN allows the enterprise to extend the macro- and microsegmentation end to end in a fully integrated fashion. This way, the SGT information can be propagated across the network without additional resource utilization or reclassification as the data re-enters the SDA environment at the remote location. Even if the remote site has not been migrated to SDA, SD-WAN may be utilized to provide Cisco TrustSec policy enforcement at the remote site without the originating site being aware of the destination SGTs.
Cisco product engineering has supported two methods for integrating SDA and SD-WAN: the one-box and the two-box solutions. One of the most essential points to remember is that inline tagging for SD-WAN is only supported on routers based on Cisco platforms such as the ISR 4000 series, ASR 1000 series, and Catalyst 8000 series. Viptela-based routing platforms, such as vEdge 100 and vEdge 1000, are not supported for inline tagging.
One-Box SDA and SD-WAN
One-box SDA and SD-WAN is also known as an integrated solution. In this scenario, the SD-WAN Edge router serves as an SDA control plane and also a border node. For this to occur, the Cisco DNA Center must be integrated with the Catalyst SD-WAN Manager via API integration. The SD-WAN Edge will be a part of the Catalyst SD-WAN Manager inventory and be provisioned as a normal SD-WAN device. When the SDA fabric is created, the Cisco DNA Center will update the Catalyst SD-WAN Manager via the API integration to reprovision the SD-WAN Edge with the appropriate SDA configuration. Figure 3-1 shows how a packet changes as it traverses the one-box solution across SD-WAN from one SDA site to another. Notice that the VNID and SGT information is propagated across the network with the data packet itself.
)
Figure 3.1 SD-WAN-SDA One-Box Topology
There are distinct pros and cons to the one-box approach that must be considered as part of the overall enterprise design. As will be discussed with the two-box approach, the one-box approach removes support for modularity. This is important to consider because most enterprises are divided into multiple organizational units even when considering who manages which part of the network. For instance, one group may manage the WAN while another manages the LAN campus. The one-box approach will make it difficult for the two groups to manage their respective environments.
From a design consideration, it should be noted that the one-box solution requires a router to perform the border node and control plane functionality in the SDA campus. With physical redundancy included, two routers now perform those roles. While this solution works well for the control plane, because the routers have greater routing capabilities, in the data plane, the routers could inadvertently become the logical core of the local area network. In larger locations, additional functional blocks may exist outside of the SDA domain. For instance, where Nexus switches perform a local services aggregation block, an additional pair of switches performing the internal border node functionality at the intended core will better facilitate the required high-speed switching without the traffic traversing the edge routers. Figure 3-2 illustrates how the connectivity between the additional non-SDA fabric at the local site could connect directly to the core of the network while still utilizing the one-box solution. Notice that the core now performs SDA border node functionality. SDA VXLAN traffic that is egressing the location will still utilize the SD-WAN Edges, whereas traffic to these additional services will utilize the core border nodes as their VXLAN termination point.
)
Figure 3.2 One-Box Topology with Additional Service Domains
Catalyst SD-WAN Manager and Catalyst Center Integration
Integrating Catalyst SD-WAN Manager and Catalyst Center is fairly straightforward. From the Cisco Catalyst Center System Settings, navigate to the External Services page and select Catalyst SD-WAN Manager. Depending on the version of Catalyst Center, this selection will navigate to a new page or open a pop-out, allowing you to enter the Catalyst SD-WAN Manager and SD-WAN overlay information shown in Figure 3-3.
The Catalyst Center will use the configured user credentials for its API calls to Catalyst SD-WAN Manager. Therefore, it is recommended that a service account for the integration is created within the enterprise identity store that can be used for auditing purposes. As noted in Figure 3-3, if the Catalyst SD-WAN Manager is authenticated via a root certificate authority, then the Catalyst Center must have a certificate installed through the Certificates page from the same trust chain.
)
Figure 3.3 Catalyst SD-WAN Manager and Catalyst Center Integration Process
Two-Box SDA and SD-WAN
In the two-box SDA–SD-WAN scenario, also known as a nonintegrated solution, both architectures are kept separate, providing for a modular networking approach. The SD-WAN Edge devices each have a physical link to the SDA border nodes that is a dot1Q trunk. On the SD-WAN Edge side of the link, the subinterface is associated with a specific service VPN. On the border node side of the link, the SVI provisioned from Catalyst Center is associated with the corresponding SDA virtual network. In this manner, the VLAN becomes the mapping between the SDA virtual network and the SD-WAN service VPN. By enabling Cisco TrustSec (CTS) inline tagging on both sides of the interface, the SGT value may be propagated as well, maintaining both the macro- and microsegmentation of the environment.
From a design perspective, the two-box scenario allows for both a modular design and phased rollouts at the expense of potentially more hardware to install and manage. Figure 3-4 demonstrates how a data packet traverses the two-box solution while maintaining the VNID and the SGT information with the packet itself.
)
Figure 3.4 SD-WAN-SDA Two-Box Topology
SDA and SD-WAN Segmentation
In SDA, the VNID is a 24-bit value used to identify which virtual network a packet traversing the underlay is associated with. When a new virtual network is created in the Catalyst Center UI, Catalyst Center creates a new VNID for it that is constant across all locations. Whenever that virtual network is provisioned at an SDA site, Catalyst Center uses the VNID as the LISP instance ID, which is mapped to the VRF on the switch with the correct virtual network name. The VNID is carried across the underlay as part of the VXLAN header. Additionally, the VXLAN header carries the SGT value. The SGT is a 16-bit value that indicates to which security group the source of the packet belongs.
For data egressing the SDA environment, it is forwarded as a VXLAN packet to the correct border node. After the packet arrives at the border node, it is decapsulated and forwarded based on the VRF instance associated with the VNID. If the destination security group is known by the border node, it will enforce applicable policy. This is not always the case because it would depend on the configuration of the border node.
With SD-WAN, the service VPN ID is inside the IPsec header prior to forwarding on the transport layer. Additionally, the CMD header commonly associated with Layer 2 frames has been added to the IPsec header on an SD-WAN packet to allow the SGT information to be propagated also.
The last piece of the discussion pertains to connecting the SDA environment and the SD-WAN environment together. Whether the one-box or two-box solution is utilized, there must be a consistent mapping between the two architectures. In the one-box solution, mapping is done via Cisco Catalyst Center. After the Catalyst SD-WAN Manager to Catalyst Center integration has been performed as described previously, the individual SDA virtual networks are mapped to specific SD-WAN service VPNs in the Catalyst Center UI. When an SD-WAN Edge is provisioned at an SDA location, the mapping of Service VPN to VNID configured in the Catalyst Center is used. The SD-WAN Service VPN is used as the name of the VRF on the SD-WAN Edge for all of the SDA and SD-WAN appropriate configurations. When the integration is complete, the Catalyst Center page utilized to tie the SD-WAN Service VPN to the SDA virtual network is shown, as in Figure 3-5.
)
Figure 3.5 One-Box VNID to Service VPN Mapping
In the two-box solution, the mapping between VNID and service VPN is achieved through the use of the VLAN carrying the traffic between the two devices. It is critical to standardize the VLAN mapping across the environment. Doing so facilitates easier operation and troubleshooting of a multi-site environment when operations engineers know that a specific VLAN is used to connect SD-WAN Edge to the border node in the SDA Corporate VN and SD-WAN service VPN 500 at all locations. The VLAN mapping ensures that macrosegmentation is maintained; however, support for the microsegmentation propagation must be intentionally added. This is achieved by configuring inline tagging on both sides of the link, allowing the SGT information to be propagated via the CMD header in the frame. Care should be taken to ensure that the device SGT also is trusted on both sides. In Example 3-1, the inline tagging is configured on both the physical interface and the subinterface carrying the traffic. The SGT with ID number 2 is the All Cisco TrustSec Devices SGT.
Example 3-1 Inline Tagging Configuration
! LAN Interfaces interface GigabitEthernet0/0/0 cts manual policy static sgt 2 trusted ! interface GigabitEthernet0/0/0.100 cts manual policy static sgt 2 trusted !
SDA and SD-WAN Best Practices
As is seen throughout this book, standardization across the environment is critical. When creating any standardized mapping, ensure that future proofing is considered. Is there a potential for additional network devices for horizontal scaling at the location? Will additional macrosegmentation be added to the environment that may need to be considered?
The SDA INFRA_VN, or SDA underlay, should be contiguous with a service VPN in SD-WAN. The SDA underlay may be mapped to a unique SD-WAN service VPN or utilize one used by the general corporate VPN. The former allows the underlay management to be reachable from the local environment without traffic leaving the site, and the latter maintains the macrosegmentation requiring traffic to egress the site, possibly fusing the two routing domains together at a centralized firewall environment.
When the SDA and SD-WAN multi-domain environment is built out, it is recommended to build the centralized data center environment first—the services and SD-WAN Edge headend devices. At the remote sites, the process of building and validating the SD-WAN environment first facilitates a smoother transition to deploying SDA.
When Cisco TrustSec is enabled at a site, care should be taken to ensure one device does not become inaccessible. In a location where physical redundancy exists, the engineer should ensure that the SDA devices are accessible across both pathways prior to enabling CTS. Additionally, it is important to remember that CTS must be enabled on the physical and subinterfaces on the link.
In the event that it is a small site with minimal hardware and connectivity—for instance, a single SD-WAN Edge cabled to a single Fabric-in-a-Box (FiaB) switch—redundant pathways may not exist. In this instance, it is recommended to have the CTS configuration as a simple text file on the flash of the switch. The file may be copied into the running configuration on the switch. At this point, the reachability to the switch will be lost; however, all of the configuration in the text file will be applied. The SD-WAN device may then be reprovisioned to include the CTS, restoring the connectivity.