Design a Cisco SD Access solution

2.1.a i Underlay network (IS-IS, manual/PnP)

IS-IS

Intermediate System to Intermediate System

General information on “SDA IS-IS”:

IS-IS is the recommended protocol for the SD-Fabric underlay network because of its scalability, efficiency and simplicity
Uses the same SPF algorithm as OSPF (Dijkstra)
IP-neutral (running on L2), therefore supported IPv6 without any rewrite, just TLV extension
The IS-IS interface MTU is 1497 bytes since there is a 3 byte LLC (Logical-Link Control) field in the header
OSI Terms:
- System = Node
- End System = Host
- Intermediate System = Router
- Circuit = Interface/Link
- Domain = Autonomous System (AS)
Router Types:
- Level-1: Intra-area router. Only exchanges information with other Level-1 routers.
- Level-1 routers only have the visibility of the Level-1 area they’re residing in.
- Level-1-2: Intra-area and inter-area router. Exchanges information with both Level-1 and Level-2 routers.
- Level-2: Inter-area router. Only exchanges information with other Level-2 routers.
- Level1-2 and Level-2 routers have the visibility of everything in the whole domain.
Network Service Access Point (NSAP):
- Equivalent to a Router-ID in the IP world
- Used in IS-IS to identify the router, area and system-id
- Represents a System in a Domain
- 49.0000.0000.0000.0001.00
  - 49 = AFI
  - 0000 = Area
  - 0000.0000.0001 = System ID
  - 00 = NSEL
Network Types:
- Broadcast: Default for Ethernet interfaces. DIS required.
- Point-to-Point: Only two IS nodes can exist on the link. No DIS election.
Area Types:
- A backbone is a contiguous collection of Level-2 routers
- A Level-2 area is comparable to the OSPF backbone area 0
- A single router can only be in one area (defined through the NSAP) but in multiple Levels
Area Design:
- Flat design: Every router is in the same area and has the same Level. No summarization.
- Hierarchical design: Dedicated backbone (Level 2) area. L1-L2 routers at the edge of every area. Summarization at the edge of every area.
- Hybrid design: No dedicated backbone (Level 2) area but multiple areas connected through L1-L2 routers. Summarization at the edge of every area.
Packet Types:
- IS-IS Hello (IIHs): Used to build and maintain adjacencies.
- Link State Packets (LSPs): Used for exchanging prefixes.
- Sequence Number Packets (SNPs): Used for database synchronization.
Adjacencies:
- IS-IS uses Layer 2 for building adjacencies and sending control-plane traffic between devices
- Broadcast networks:
  - Independent adjacencies are formed per Level
  - Separate IIHs are sent per Level
  - DIS election is done per Level
  - DIS = Designated IS. Comparable to OSPF DR. Simplifies the graph to a collection of P2P links towards the pseudo-node.
  - DIS criteria: Highest priority (default 64, range 0 - 127), highest MAC address
  - The DIS can be found out by checking the IS-IS database and looking of LSP IDs other than RID.00-00
- Point-to-Point networks:
  - A single adjacency is formed over the circuit for both Levels
  - A single P2P HELLO is sent over the circuit for both Levels
- Adjacency states:
  - Down (2): Adjacency not established. No HELLOs have been received from the neighbor.
  - Initializing (1): HELLOs received from neighbor but it’s not clear yet if the neighbor received our HELLOs.
  - Up (0): Adjacency established. Bi-directional communication is working.
- Cisco Adjacency-Check:
  - Network Type must match.
  - IS-Type must match.
  - Area ID must match.
  - IPv4 Subnet must match.
  - MTU must match.
  - Authentication must match.
  - System ID needs to be unique.
- Adjacency requirements:

Router Type	L1	L1-L2	L2
L1	Area IDs must match = L1 adjacency.	Area IDs must match = L1 adjacency.	No adjacency.
L1-L2	Area IDs must match = L1 adjacency.	Area IDs must match = L1 adjacency. L2 adjacency will be built regardless of the area ID.	L2 adjacency will be built regardless of the area ID.
L2	No adjacency.	L2 Adjacency will be built regardless of the area ID.	L2 adjacency will be built regardless of the area ID.

Route Types:
- i L1 = IS-IS Level 1
- i L2 = IS-IS Level 2
- i ia = IS-IS inter-area
- i su = IS-IS summary
Prefix Advertisement:
- Prefixes can be either advertised by enabling the process on the interface or by using the passive-interface command under the routing process
- Process on interface = Prefix has a metric of 10
- Passive-interface command under the routing process = Prefix has a metric of 0
- Default IS-IS cost for all interfaces is 10
- Level-1 routes will be automatically propagated into Level-2 areas by L1-L2-routers
Metric Types:
- Narrow Metric: Default metric type in IS-IS. Value range is 6 bit (1 to 63).
- Wide Metric: Used for transporting additional attributes (eg for MPLS-TE, …). Value range is 24 bit (1 to 16,777,214)
- Important: Narrow/Wide metrics are not compatible with each other. Either all routers run narrow metrics or all routers run wide metrics. This can be fixed by using the “transition mode” which generates metrics for both metric types.
Authentication:
- Unlike EIGRP/OSPF, the authentication process within IS-IS is divided into two parts:
  - Auth. of HELLO packets: Each HELLO packet will be authenticated. If not successful, no adjacencies are established. Can be enabled for either L1, L2 or both (default is both).
  - Auth. of LSP packets: Each LSP packet will be authenticated. If not successful, information about networks attached to other routers isn’t received. Can be configured per area (Level-1) and per routing-domain (Level-2). Level can’t be specified.
- Authentication configuration process for IOS/IOS-XE:
  - Auth. of HELLO packets: Configured under the interface.
  - Auth. of LSP packets: Configured under the routing process.
Level-1 Router Default Route:
- ATTACH-Bit: Set by the L1-L2 router so that the L1 router will install a default route. Will be only set if the L1-L2 router is attached to another area.
OVERLOAD-bit:
- Function-wise comparable to the stub-router feature of OSPF (max-metric router-lsa)
- Originally used to signal other routers of system resource exhaustion (CPU and/or memory) so that the given router isn’t used for transit anymore
- Can be set manually forever or temporarily for a given amount of time after startup
Route Leaking:
- Routes can be leaked from Level-2 into Level-1 under the routing process
- For Loop Prevention, there’s a mechanism using the UP/DOWN-Bit:
  - UP bit: If set, then routes are native L1 routes and eligible for leaking.
  - DOWN bit: If set, then routes are already leaked routes and unable for leaking.

“IS-IS” CLI configuration commands:

## Basic IS-IS process configuration
Router(config)# router isis <PID>
Router(config-router)# net [NSAP]

## Basic IS-IS interface configuration
Router(config)# interface <if>
Router(config-if)# ip router isis <pid>

## Basic IS-IS passive-interface configuration
Router(config)# router isis <PID>
Router(config-router)# passive-interface <if>

## IS-IS IIH authentication
Router(config)# interface <if>
Router(config-if)# isis authentication mode <mode>
Router(config-if)# isis authentication key-chain <keychain> <level>

## IS-IS LSP area authentication (level-1)
Router(config)# router isis <PID>
Router(config-router)# area-password <password>

## IS-IS LSP routing-domain authentication (level-2)
Router(config)# router isis <PID>
Router(config-router)# authentication mode <mode>
Router(config-router)# authentication key-chain <keychain> <level>
Router(config-router)# domain-password <password> <options for snp>

## Redistribute IS-IS L2 into L1
Router(config)# router isis <PID>
Router(config-router)# redistribute isis ip level-2 into level-1 route-map [ROUTE-MAP]

## IS-IS set overload-bit
Router(config)# router isis <PID>
Router(config-router)# set-overload-bit <options>

manual/PnP

Plug and Play

General information on “SDA manual/PnP”:

General SDA Underlay Network parameters:
- IPv4 is still required as of DNAC v1.3 (IPv6-only underlay is not possible)
- A system MTU of 9100 is recommended to prevent fragmentation
- Switches need “ip routing” enabled to participate in the fabric
- A Loopback0 interface with a /32 mask, which is used as “Fabric Node Router ID”, is required
Manual SDA Underlay Network:
- Also called “Custom Underlay”
- Used for brownfield and greenfield deployments
- Administrator must provide a fully functional IP-reachable underlay network (physical/logical interface configurations, control-plane protocols, address configurations) between all fabric-enabled devices and Cisco DNAC/ISE
- Configuration can be either done fully manually on the devices themselves or using device templates defined in DNAC
- The Loopback0 interface IP address (= “Fabric Node Router ID”) must be explicitly advertised in the IGP because it is the destination of packets destined from/to the device (eg. LISP Source Locator, …)
- Advantages Manual Underlay:
  - Underlay network is fully known by the administrators
  - Can be customized to fit the own requirements/compliance rules
  - Fabric is capable to run over the top of a legacy (or non-Cisco) IP-based network
- Disadvantages Manual Underlay:
  - Administrators are responsible for all underlay configuration/management
  - Problems must be fixed by the administrators themselves (eg. MTU issues, improper routing/addressing, fragmentation, excessive latency, …)
Automatic SDA Underlay Network (LAN Automation):
- Also called “Automated Underlay”
- Used for greenfield deployments
- LAN Automation = Automatic discovery, provisioning and deployment of the underlay network
- DNAC provisions a fully functional IP-reachable underlay network (physical/logical interface configurations, control-plane protocols, address configurations) between all fabric-enabled devices and Cisco DNAC/ISE
- IS-IS is the only possible underlay routing protocol when using LAN Automation
- IS-IS domain authentication is optional, but recommended
- Advantages LAN Automation:
  - Underlay is fully automated across multiple network layers
  - Eliminates misconfiguration and complexity
  - Heavily simplifies and speeds up the building of the underlay network
- Disadvantages LAN Automation:
  - Cannot be customized to fit the own requirements/compliance rules because standardized design will be used for every DNAC/SDA deployment
  - A manually discovered/configured “seed device” is required
- LAN Automation requirements:
  - A seed device (two recommended for redundancy)
  - A defined global IP address pool and a reserved IP address pool at the site which has the seed devices
  - Full reachability between the seed device(s) and DNAC/ISE
- LAN Automation process:
  - Important: In order for LAN Automation to work, the downstream devices need to be fully wiped to factory settings (everything including any certificates must be removed)!
  1. Seed device/s (at least one, ideally two) must be added to DNAC either manually or via the Device Discovery feature and assigned to a site
  2. A global IP address pool must be created and a part of it (or the whole pool) must be reserved under the site where the seed devices were assigned to
  3. LAN Automation must be initiated where the seed device/s, the reserved IP address pool and the device ports where downstream network devices are attached must be selected
  4. When LAN Automation is started, DNAC will push out a standardized (best practice) configuration to the seed device/s including IS-IS configuration, a temporary DHCP server (will be used for LAN Automation only and is deleted after it is complete) and puts the selected device ports in VLAN1
  5. DNAC starts to discover all attached downstream network devices which are attached to the seed device and configures them
  6. DNAC also discovers all network devices which are attached to already discovered network devices and/or are more than 1 CDP hop away
  7. When everything is discovered and the status shows “Completed”, LAN Automation must be stopped and DNAC will remove some configuration (eg. DHCP server from seed device) and modify some configuration (eg. peer links will be configured to L3 instead of L2)
  8. LAN Automation is completed and the Routed Underlay network is ready to use
Automatic SDA Underlay Network (PnP w/o LAN Automation):
- Day-0 Template/Network Profile (optional):
  - Before using the Lan Automation process, a Day-0 template (“Onboarding Template”) as well as network profile should be created
  - The Day-0 template (“Onboarding Template”) is an initial device configuration applied to the device when claiming it
  - It can include parameters like the hostname, loopback interface, …
  - Additionally a Network Profile must be created which links to the Day-0 Template
  - The Network Profile is attached to the fabric site the device gets assigned to
- “Normal” PnP process for onboarding new network devices afterwards (=not LAN Automation):
  1. Device (router, switches, APs) boots up and tries to acquire an IP address via DHCP on every port
  2. The DHCP server provides the device not only with an IP address but also with the IP address of DNAC, either via…
    - Option A: DHCP Option 43 (if available)
    - Option B: Contact DNS server and ask for a name resolution of “pnpserver.localdomain” (localdomain = Domain provided via DHCP)
    - Option C: Cisco Cloud will be contacted and Daddress will be acquired form the Smart Account
  3. Device will appear under Provision -> Devices -> Plug and Play as unclaimed device
  4. Device must be claimed and a Day-0 template (“Onboarding Template”) can be applied to it which merges with the running-config
- Pre-provisioned PnP process for onboarding new network devices afterwards (= not LAN Automation):
  1. Device must be added to DNAC (Serial number, etc.) and added to a site so that the device will be automatically claimed when it gets added
  2. Device (router, switches, APs) boots up and tries to acquire an IP address via DHCP on every port
  3. The DHCP server provides the device not only with an IP address but also with the IP address of DNAC, either via…
    - Option A: DHCP Option 43 (if available)
    - Option B: Contact DNS server and ask for a name resolution of “pnpserver.localdomain” (localdomain = Domain provided via DHCP)
    - Option C: Cisco Cloud will be contacted and DNAC address will be acquired form the Smart Account
  4. Device will appear under Provision -> Devices -> Plug and Play as claimed device

2.1.a ii Overlay fabric design (LISP, VXLAN, Cisco TrustSec)

LISP

// Graphic missing - Coming soon //

Location/Identifier Separation Protocol

General information on “SDA LISP”:

Used as the control plane within SD-Access
LISP is an overlay protocol (like GRE, IPSEC, …)
LISP is an IP-in-IP/UDP protocol
Aimed to decouple the endpoint identifier from the location
LISP uses a pull model and only requests the information it needs whereas traditional routing protocols (EIGRP, OSPF, …) are push models and share all the information with each other
LISP resolves Locators (RLOC) for queried Identities (EID) (Q: “Where is the EID located?” , A:“Here’s the RLOC which has the EID currently behind it!")
IPv4/IPv6 can be combined in any possible way (eg. IPv4 as EID spaces and IPv6 as transport, IPv6 as EID spaces and transport, …)

LISP terminology:

EID: End-point Identifier (= host)
RLOC: Routing Location (= router id). Comparable to TLOC in SD-WAN.
Map Server (MS): Stores EID to RLOC mappings.
Map Resolver (MR): Accepts MAP-REQUESTS from the ITR and forwards it to the Map Server.
Tunnel Router (xTR): Used to enter/leave LISP overlay. Ingress (ITR), Egress (ETR)
Proxy Tunnel Router (PxTR): Connects LISP and non-LISP domains. Ingress (PITR), Egress (PETR).

LISP tables:

Database: Contains the locally attached EIDs. Reachability of EID space depends on the RIB entry therefore if there’s no RIB entry for a EID Space it will be shown as unreachable.
Map-Cache: Used to build the LISP data plane. Populated through MAP-REQUESTS.

LISP encapsulation types:

LISP encapsulation: Encapsulates only the original IP Packet (default setting in vanilla LISP).
VXLAN encapsulation: Encapsulates the whole original Ethernet Frame (used in SD-Access).

Messages types and communication (vanilla LISP):

MAP-REGISTER: Sent from ETR to Map Server to register EID space/s.
MAP-NOTIFY: Sent from the Map Server to the ETR for notification of successful registration (only if M-bit is set to 1).
MAP-REQUEST: Sent from the ITR to the Map Resolver to request an EID-to-RLOC mapping. The Map Resolver forwards it to the Map Server who forwards the MAP-REQUEST to the correct/authoritative ETR who can provide the mapping.
MAP-REPLY: Sent from the ETR who has the requested EID-to-RLOC mapping directly back to the ITR who requested the EID-to-RLOC mapping.

Message types and communication (SD-Access LISP):

MAP-REGISTER: Sent from Fabric Edge node to Control-Plane node to register EID space/s with P-bit set. Hosts/endpoints will be registered as /32 prefixes since dynamic EIDs are used within SDA LISP.
MAP-NOTIFY: Sent from the Control-Plane node to the Fabric Edge node for notification of successful registration.
MAP-REQUEST: Sent from the Fabric Edge node to the Control-Plane node to request an EID-to-RLOC mapping (for a /32 prefix). A nested map reply is built into the MAP-REQUEST message.
MAP-REPLY: Sent from the Control-Plane node who has the requested EID-to-RLOC mapping directly back to the Fabric Edge node because it is set to send a proxy reply.
Control-Plane nodes act as MS/MR within SD-Access
Control-Plane nodes store IP-to-RLOC and MAC-to-RLOC
Border Nodes act as PxTR within SD-Access
Multi-Instance LISP (aka VRF-aware LISP) is used for SD-Access whereas each VN has its own LISP instance

LISP to LISP communication:

eTR initially registers which EID spaces it has behind its RLOC to the Map Server
Steps for LISP-to-LISP (simplified):
1. iTR will send a MAP-REQUEST to the Map Resolver when it’s not stored in the map-cache
2. Map Resolver forwards the MAP-REQUEST to the Map Server
3. If the Map Server has an registered EID space which fits the request, it will get forwarded to the correct/authoritative eTR
4. eTR will send a MAP-REPLY for the requested EID space directly back the the requesting iTR

LISP to non-LISP communication:

For LISP to non-LISP communication, a PxTR is needed
If a LISP site (whole LISP domain) wants to send traffic to a non-LISP site the traffic will be forwarded natively out of the PxTR (= without LISP)
Steps for LISP-to-non-LISP (simplified):
1. iTR will send a MAP-REQUEST to the Map Resolver when it’s not stored in the map-cache
2. Map Resolver forwards the MAP-REQUEST to the Map Server
3. If the Map Server has NO registered EID space which fits the request, it will send back a negative MAP-REPLY to the requesting iTR
4. - LISP-to-non-LISP: xTR will LISP-encapsulate and forward the traffic to the PxTR. PxTR will decapsulate and forward the traffic natively to the outside destination.
  - Non-LISP-to-LISP: PxTR will LISP-encapsulate and forward the traffic to the xTR. xTR will decapsulate and forward the traffic natively to the attached EID space.

LISP header bits:

P-bit = Proxy-map-reply bit. If set, the MS replies directly to MAP-REQUEST messages.
M-bit = Want-map-notify bit. If set, the MS is required to send a MAP-NOTIFY message.
S-bit = Solicit-map-request bit. Set by the “receiving xTR” to inform that a specific EID is no longer “behind” it. Tells the “sender xTR” that it should send a MAP-REQUEST to the MR/MS to find out where the specific EID is now located.

LISP header specialties:

By default, the outer header uses the IP address of the xTR egress interface as source address, this can be changed by issuing the ip lisp source-locator <if> command under the xTR egress interface configuration
LISP adds an additional 36 byte (20 byte outer IPv4 + 8 byte UDP + 8 byte LISP) or 56 byte (IPv6) (40 byte outer IPv6 + 8 byte UDP + 8 byte LISP) header

Basic LISP configuration:

Optional: Configure Loopback interfaces on each LISP router to be used as RLOCs
Define/configure a router as LISP MS/MR:
- Configure it as map-server
- Configure it as map-resolver
- For each LISP non-MS/MR, configure a site
Define/configure a router as LISP site:
- Configure a database-mapping
- Configure it as itr
- Configure it as etr
- Define the itr map-resolver
- Define the etr map-server

PxTR LISP configuration:

Optional: Configure Loopback interface on LISP PxTR router to be used as RLOC
Configure a router a LISP PxTR:
- Configure it as proxy-itr
- Configure it as proxy-etr
- Define the itr map-resolver
- Define the map-cache [EID Space] map-request for each EID Space within the LISP domain
Configure xTR to use PxTR as PETR:
- Configure the parameter use-petr [RLOC]

Important: LISP router can be xTR and PxTR at the same time!

Disable LISP TTL propagation:

disable-ttl-propagate

VXLAN

Virtual eXtensible LAN

General information on “SDA VXLAN”:

Used as the data-plane within SD-Access
VXLAN is an MAC-in-IP/UDP protocol
VXLAN encapsulates the whole original ethernet frame (L2 header, L3 header and payload)
This results in support for both L3 AND L2 in the SD-Access overlay (compared to vanilla LISP which is L3 only)
VXLAN integration in SD-Access is realized by setting the encapsulation type to VXLAN within LISP
VXLAN header contains VNID (VXLAN Network Identifier) which allows up to 16 million VRFs
VXLAN header also contains GPID (Group Policy ID) which allows up to 64.000 SGTs (Scalable Group Tags)
VXLAN header VNID = SD-Access VN (macro segmentation)
VXLAN header GPID = SD-Access SGT (micro segmentation)
VXLAN adds 50 byte header (14 byte Ethernet, 20 byte outer IP, 8 byte outer UDP, 8 byte VXLAN)
The recommended design is a Spine-Leaf design
Usage of Jumbo MTUs (9100 bytes) is the recommended best practice as of today or else fragmentation will occur because of the increased packet size

VXLAN Terminology:

VNID: VXLAN Network Identifier. 24 bit segment ID that defines the broadcast domain.
VTEP: Virtual Tunnel Endpoint. Device that encapsulates/decapsulates VXLAN packets. Comparable to LISP ITR/ETR. VTEPs store /32 routes of the endpoints (comparable to LISP when dynamic EIDs are used).
NVE: Network Virtualization Edge. Logical interface where the encapsulation/decapsulation occurs. Comparable to virtual LISP tunnel interface.

Modes of VXLAN:

Flood-and-Learn:
- No control plane
- Data driven flood and learning (=> Ethernet in the overlay network)
- All VTEPs are joined to the same multicast group
- Caveats:
  - Limited scale and workload mobility
  - Centralized gateway
  - Security risk (Rouge VTEPs can easily be added since there’s no authentication)
- How it works:
  1. Host/endpoint (locally attached to VTEP-A) sends an ARP request for a remote host/endpoint (locally attached to VTEP-B).
  2. VTEP-A encapsulates the ARP into a VXLAN packet and sends it to the “all-VTEPs-multicast-group”
  3. Packet gets decapsulated by all remote VTEPs. The ARP request is forwarded to the VLAN that has the VNID attached. The IP-to-MAC mapping including VTEP IP address of the source endpoint gets cached for later use. While this happens, all VTEPs now know VTEP-A.
  4. The ARP reply from the local attached host/endpoint hits VTEP-B where it gets encapsulated into a VXLAN packet, but this time the destination IP address is the unicast address of VTEP-A where the former ARP request originated.
  5. ARP reply reaches VTEP-A and now VTEP-A gets to know about VTEP-B.
  - Important: This process gets repeated when the VXLAN cache expires.
BGP EVPN VXLAN:
- MP-BGP EVPN as control plane (Spines as RR)
- VTEPs exchange L2/L3 host and subnet reachability through EVPN control plane
- Advantages:
  - Increased scale/stability and workload mobility
  - Distributed Anycast gateway
  - Increased security (with BGP authentication)
- How it works:
  1. Layer 2 packet: As soon as traffic of a new host/endpoint hits the VTEP, the VTEP will send a BGP EVPN Type-2 MAC update which contains the MAC address of the new host/endpoint, the VTEP it is currently associated to and the L2 VNI it is currently in.
  2. Layer 3 packet: Same as with L2 packet but the BGP EVPN Type-2 update now also includes the IP address and the L3 VNI it is currently in.

BUM Traffic handling:

Flood-and-Learn VXLAN: BUM traffic is flooded throughout the VXLAN domain using the underlay multicast infrastructure. This is because there’s no dedicated control-plane for learning L2 information.
BGP EVPN VXLAN: BUM traffic is not flooded throughout the VXLAN domain. This is because there’s a dedicated control-plane for learning L2 information.

Multicast handling:

Native Multicast: Normally, when VXLAN is deployed, multicast is also deployed for efficient handling of multi-destination traffic. PIM-SM will be activated within the underlay whereas the Spines act as RPs. Multicast traffic will be natively forwarded within the underlay. Mandatory for Flood-and-Learn.
Ingress/Headend Replication: If multicast can’t be deployed for any reason, traffic will be replicated for each remote VTEP via the overlay. Caveat is that this increases the traffic load throughout the network since every multicast packet gets replicated for each remote VTEP. Only possible for BGP EVPN VXLAN.

Cisco TrustSec

General information on “SDA Cisco TrustSec”:

Used as the policy-plane within SD-Access
TrustSec consists of two major components:
- SGTs (Scalable Group Tags): Numeric tags which are applied to end users/devices/… to group them logically together (eg. Employees, Contractors, …).
- SGACLs (“Access contracts” within SDA): Used to control the communication in-between SGTs.

SGTs (Scalable Group Tags):

Vanilla TrustSec:
- Cisco ISE dynamically assigns SGTs to the users/devices/… connecting to the network based on defined Policy Sets
- Alternatively it’s possible to statically assign SGTs to switch/routed ports, individual IPs, subnets or whole VLANs
SD-Access TrustSec:
- Cisco ISE dynamically assigns SGTs to the users/devices/… connecting to the SD-Access fabric based on defined Policy Sets
- Alternatively it’s possible to statically assign SGTs to single switch ports (via manual Host Onboarding) or whole VNs (Host Onboarding -> Add VN -> Add IP Pool to VN -> Assign SGT to IP Pool)
Regardless of the environment, the SGT gets always applied at the same point:
- Ingress Edge Node enforces/sets the sender-SGT
- Egress Edge Node enforces/sets the receiver-SGT
Important: Edge Nodes only knows about SGTs which have locally connected users/devices/…!

SGT propagation:

In order for SGACLs to work, the enforcement device (Egress Edge Node in SDA) needs to know about the SGT of the sender/source
Two methods for SGT propagation are available:
- Inline Tagging: The SGT gets added to the header of the data packets.
- SXP (SGT eXchange Protocol): A protocol for communication between network devices to exchange IP-to-SGT mappings.

SGT Inline Tagging:

Vanilla TrustSec: An additional/special header called “Cisco MetaData” (CMD) which contains the SGT is added to the Ethernet Frame right after the dot1q header. The EtherType is 0x8909. Caveat is that if an intermediate switch doesn’t understand this EtherType the frame will get dropped.
SD-Access TrustSec: The ingress Edge Node adds the SGT to Group ID field in the VXLAN header before it is forwarded into the SD-Access fabric.
Important: Regardless of the SGT placement in the packet header, the field for the SGT is always 16 bit!

SXP (SGT eXchange Protocol):

Used to exchange IP-to-SGT mappings over a non-TrustSec capable environment
SXP device roles:
- Speaker: Sends out mappings
- Listener: Receives mappings
- Both: Sends/Receives mappings

SGACLs (“Access contracts” within SDA):

SGACLs are based on a pull model which means they are only downloaded to an Edge Node when locally connected users/devices/… match the destination-SGT
Enforcement of SGACLs is done at the egress Edge Node for locally attached SGTs
This is because when a device/users/… sends traffic, the ingress Edge Node doesn’t know about the SGT of the receiver which is connected to the egress Edge Node
Every SGACL change (Matrix, Access contracts, …) must be deployed in order to get processed/changed on the Edge Node
Important: SGACLs are not stateful, therefor it’s not enough to configure only destination-based rules but return traffic rules must be configured as well!
Example for two-way SSH-permit SGACL:

// Graphic missing - Coming soon //

“Cisco TrustSec” CLI show commands:

## Showing SGT mappings
Switch# show cts role-based sgt-map vrf [VN] all

## Showing downloaded SGACLs
Switch# show cts role-based permissions

2.1.a iii Fabric domains (single-site and multi-site using SD-WAN transit)

single-site

General information on “SDA single-site”:

SD-Access site design/configuration/deployment process:
1. DNA Center “DESIGN” tab:
  1. Create the physical network hierarchy (areas, buildings, floors)
  2. Configure network services for sites (DHCP, DNS, AAA, NTP, …)
  3. Add device credentials for discovery and management
  4. Define global IP address pools
  5. Reserve IP addresses from the global IP address pools for each site/area/building/…
2. DNA Center “POLICY” tab (optional):
  1. Create global SGTs
  2. Create VNs and add SGTs to it
  3. Create Access Contracts (also known as SGACLs)
  4. Define the policies between the SGTs by assigning Access Contracts
3. DNA Center “DISCOVERY” tool (main dashboard):
  1. Discover devices
4. DNA Center “PROVISION” tab:
  1. Provision the underlay network (Usage of LAN Automation feature)
  2. Provision devices and assign devices to sites
  3. Create transit networks and fabric site
  4. Create fabric overlay network within the fabric site
  5. Onboard wired clients

multi-site using SD-WAN transit

// Graphics missing - Coming soon //

General information on “SDA multi-site using SD-WAN transit”:

Important: The following is additional necessary compared to a single-site fabric design!
SD-Access w/ SD-WAN transit allows for end-to-end segmentation and policing
As of now, only cEdges (VIPTELA running on ISR/ASR) are supported for SD-WAN transit
As of now, DNAC and vManage are needed both needed for configuration since DNAC can’t push down the configuration to the cEdge
cEdge will act as Anywhere Border Node for the SDA part
Integration between SDA and SDW:
- Within DNAC, a VN can be mapped to a vManage VPN ID
- Configured/Done under Policy -> Virtual Network -> [select VN] -> Field “vManage VPN”
- SGTs will be carried inside the SD-WAN VPN Tunnel
- Between Edge Node and Border Node (cEdge) = LISP + VXLAN
- Between Border Nodes (cEdges) = IPSEC + OMP
Border Node (cEdge) port behavior:
- Port facing against SDA fabric: Service VPN (Trunk port or sub interfaces)
- Port facing against WAN: Routed port only
SDA/SDW configuration:
- vManage needs to be added to DNAC under the System Settings page
- DNAC automatically created a Transit/Peer network
- VN needs to be mapped to a vManage Service VPN (VPN information is pulled from the vManage directly)
- Under “vManage -> Integration Management” the SD-WAN transit routers need to be attached to DNAC
- Under DNAC the cEdges will show up under Provision and can be assigned to a site
LAN Automation needs to be done on the cEdges