The SD-Access (SDA) makes up on of the solution products of Ciscos DNA (Digital Network Architecture) – IWAN being the other major solution product. This page focuses on SDA providing general information as well as key sources of information from Ciscos documentation.
Valuable Cisco Docs
Below are some good Cisco Docs to get you started with SDA.
Software-Defined Access 1.0 Solution White Paper – A good place to start with learning SDA.
SDA CVD – Cisco Validated Design Guide for SDA – Solution Overview
Cisco SD-Access Ordering Guide – Detailed Platform Support and Licensing
LISP was chosen because of its poll model (no flooding). It works a bit like DNS asking for information when needed, and caching the replies to not overwhelm the control plane. This also keeps table sizes down. Note, that LISP is only used as a Control Plane protocol for SDA.
VXLAN is used for the Data Plane. With SDA they use Group Based Policy extensions to carry the Virtual Network (VN) (Analogous to a VRF) and the SGT (Scalable Group Tag) information. Specifically the VXLAN header contains a 24 bit (3 byes) VNI field for the VN information, giving us 16 million VXLAN segments (VNs). And Cisco uses 16 bits (2 bytes) of the Reserved fields of the header for the SGT information, giving us 65,000 SGTs! Those numbers should be enough for most implementations. Please note the Scale numbers of the CVD! They are very small to begin with. A future software update should increase these numbers like we saw with the Instant Access technology.
If you have been in the networking business for a while, like I have, this term might be new to you. It was for me at least. Because security is an integrated part of SDA, it makes sense to have this policy plane defined. Like IP connectivity and QoS must be end-to-end, the security policy must also be configured end-to-end. This is where the policy plane comes into play. Having your VN/SGT information not only in the Fabric, but also keeping the policy consistent when leaving/entering the Fabric going elsewhere in the network – to the Data Center or Internet Edge for example.
The underlay of SDA must support at least 1550 bytes frames. If you plan to keep VLAN information across the intermediate devices (forming the underlay), you must remember to add an additional 4 bytes to the MTU. Go for Jumbo MTU of 9216 whenever possible! Like you would also do when configuring MPLS and other overlay technologies.
A simple ping between the Fabric Edge devices with the DF bit set, should let you know if the underlay can carry the packets.
You can leverage macro segmentation using VNs (VRFs) and/or micro segmentation using SGTs within a VN.
Cisco ISE is in charge of providing Authentication and Authorization. It is the enforcement point of security policies (SGACLs). It communicates the SGT information to DNA Center via pxgrid and allows DNAC to help you to build policies ACL like policies in a very easy way.
The FE (Fabric Edge) nodes registers hosts/EID (Endpoint IDs) with the CP router (LISP Map Server). If the host moves to another FE node, this new FE node will update the CP router of the new location. The CP router will then contact the old FE node asking it to update its information. Should any other FE nodes have stale information, they will be redirected to the CP node if trying to send to the old FE node.
Start by defining the VNs you need. Perhaps you have existing VRFs that need to map to the VNs. Or maybe you want to re-define the segmentation of your network completely. Maybe you do not yet have any form of segmentation other than VLANs. For communication to happen between VNs, you need a fusion device (router or firewall) external to the Fabric. This will also be the case when communicating with shared services outside of the Fabric.
Once you get the Fabric configured with the needed VNs and everything is working, you can start the next phase of segmentation, which is segmenting inside a VN using SGTs.
For the physical migration path, you have a couple of options:
- Parallel installation with new Campus Fabric capable hardware.
- Provides easy fallback
- Gives a green field like installation/design
- The downside is that this is the expensive approach and often times not possible due to the physical plant
- Staged migration
- You put in a couple of border and CP nodes and start migrating one access switch to a Fabric Edge node at a time.
Currently there is NO support for FlexConnect with SDA. Either you run your wireless over the top of the Fabric, or you migrate all of your wireless to the Fabric. A cut over migration.
Firewalls are not part of the Fabric. Nor does the SGACLs replace the need for firewalls, so you connect your firewalls external to the Fabric.
If you use Cisco firewalls, you can leverage SGT by using SXP between ISE and the firewall.
If you are using non-Cisco firewalls, your life is still based on IP subnets for your security policies (or whatever the vendor is using).
You have these options for connecting to networks external to your Fabric with SDA:
- MPLS cannot carry SGT information – use SXP!
- SGP is carried in IPsec using Cisco Meta Data (CMD)
- Note! IKEv2 is used to negotiate and inform about SGT capability
- This is a manual configuration (BGP in DNAC only supports IPv4 and VPNv4 AFIs)
Remember two types of border nodes exist with SDA:
- Border Node
- Mutual redistribution between Fabric networks and external networks (known)
- Default Border Node
- One way redistribution (export of Fabric networks only! – NO IMPORT!) between Fabric networks and external networks (unknown)
You could use the roles to optimize traffic forwarding depending on the design, or simply for load balancing purposes. Another use case could be a security policy dictating that traffic to/from unknown external networks must pass through dedicated hardware – hence use default border nodes for this.
If you have an ACI based Data Center, the way your policy plane is maintained with SDA is via ISE, meaning that ISE is responsible for exchanging SGTs with APIC-DC and vice versa.
ISE will convert EPG tag to a SGT tag
In the opposite direction APIC-DC will provision an IP to EPG binding on the ACI border leaf. This is critical, because on the link between the SDA border and the ACI border leaf, NO SGT information exist in the packet! Plain ethernet – no CMD.
DNAC (DNA Center) is just APIC-EM 2.x with some new features for SDA. So to get going with SDA, you first must do a Discovery. This creates an inventory which makes you be able to configure the Campus Fabric (SDA Fabric Domain).
If you use PnP, the devices is automatically added to the inventory.