Download CA certificate and upload it to the Trusted store of ISE

We will select this option “Trust for client authentication and Syslog” as certificate presented to ISE during EAP TLS 802.1x authentication will be certificates issued by this same CA

Create CSR for Admin usage

enter DNS Name as $FQDN$
and also enter second DNS name as wildcard with remaining domain name *.or2.sys.cisco
and also add the SAN entry of type IP address with value of 172.16.32.12

ISE gave this error

So I removed first entry of $FQDN$

it is trusted now in browser if we access it on its FQDN

CN is the FQDN of the ISE

coming soon

conf t
!
! Enable the archive feature
archive
 log config
  logging enable
  notify syslog contenttype plaintext
  hidekeys
!
! Optional: Set up where the archived configs are stored
 path flash:config-archive
 write-memory
!
end
!
! Ensure syslog logging is enabled (optional but recommended)
conf t 

logging buffered 64000
service timestamps log datetime msec
!
end 
write mem 

SWIM – Software Image Management

you can only start tagging devices one you have uploaded the image, because we have virtual C9Kv images there is no .bin or .smu images available for them, from ths point on we will have screenshots from lab minutes

One image can be marked as golden image per device type either at the global level or at the site level, then any device that is not running that golden image will be marked as out of compliance

DNAC also supports auto clean up where it cleans up older image files

Using image column and version column with (Latest) means that these are the latest images, these images with (Latest) are being displayed from cisco.com and we can click on star icon to make them golden image

Making image golden enforces that image on that hardware model

Same thing can be repeated for different chassis or hardware types, their recommended Latest images can be marked as golden images

bundle mode images can be pulled from device and made golen image while for install mode we cannot pull from device and mark the image as golden image, instead we can either download from Cisco.com using gui or import image from file

Small “Verified” shows up next to image that shows that DNAC has downloaded the image, clicking that image makes it golden pretty fast because image is already on the DNAC server

Now making an image golden makes it same for all devices of same hardware model same across different “Roles” and all locations (Globally) and sometimes you may not want that, you can click on edit icon in device role column and set golden image per hardware model per device role, such as all “C9300” / “Access” to have a specific image or you can even have golden image per hardware model per role per location – but first you must remove the golden image from global level and then set it on site level, there is no concept of override here, either set at global level or set at all sites independently

Next step is to see which devices are not in compliance and upgrade them in provision > OS image column

DNAC validates Flash, RAM and Reboot required

SMU(0) means that there is no SMU for this image version

one big improvement in version 2.1 is that you can download image from local server instead of DNAC over the WAN

“Provision > provision device” pushes the remaining config as config assigned during assignment of device to site is not full config, full config is deployed when device is provisioned

Mark for replacement is when we have to RMA the device

Compliance > Run Compliance, this is manual trigger of the compliance and checks if device has golden image and if startup-config is same running-config etc

As devices are discovered in DNAC, it is also added in ISE

In ISE live logs we can see entries for devices authenticating to ISE for Trust Sec Device authentication

You can modify these authentication templates but cannot define more

If you want to define different SSID in europe or you want different ISE server for europe then use hierarchy and go to site specific level and override

IP based access control is used when you create non fabric based wireless and this is a very specific use, if we dont use non-fabric wireless then we will not have to touch this page

AI Endpoint Analytics
With new DNAC, AI Endpoint Analytics was introduced and this leverages AI capabilities in cloud and uses deep packet inspection in Catalyst 9K infrastructure to “identify types of endpoints” – this information can then be fed to ISE and can then be used as part of endpoint authentication, this provides additional network packet level context along side the profiling probes that ISE performs on its own and that information is communicated to ISE using PXGrid

Application policies is the feature that was known as Easy QoS and it allows you to deploy QoS end to end in your network, for more details checkout RS0122 – SDA Application Policy (EasyQoS)

Traffic Copy is the way to span traffic from Fabric to a remote destination and this is part of SGT, as you can capture traffic between specific contracts or tags

Finally Virtual networks which are essentially VRFs and separate different (virtual) fabric on same network

Service catalog, these are different services that are offered

User defined network is a cool concept as it allows users to create personal network on top of shared infrastructure, users can then register their personal devices using an app and also invite other users into that network using same app and these networks are like bubbles

These 4 services are also listed under the services section of provision tab

Assurance does not just measures health and experience of network devices but also includes clients and helps us measure client’s experience on the network also and it does not stay at client but its scope one level more deep into application as well

Events are for both Network devices and also for the clients, these are any events that happen in the network for network devices and its connected clients

DNAC offers dedicated sensors that can perform series of tests to gauge performance from client perspective. These wireless sensors join network as wireless device and these can either be dedicated sensors or an AP can also be converted to a wireless sensor

Wi-Fi6 section is for Wi-Fi6 readiness assessment which shows us the percentage of AP and clients that are capable of Wi-Fi6, if large number of clients support Wi-Fi6 then we can think about more APs to be deployed that support Wi-Fi6

Dashboard Library is where we can create our own dashboards

This Trends and Insights leverage AI in Cloud and Machine learning to spot issues in network,
Trends and Insights deals with deviation in capacity and performance

Site comparison shows us how one site compares to another, as in some cases one site can perform worse than the others

Issue settings is where we can control what issues such as P1 and P2 can be raised by DNAC such as Assurance > Issues & Events, we can enable or disable some of these issues if they are not important to us, we can also change priority on them

Health score is where you can turn on or off on what is included in determining device health score, these health score threshold values can be modified as well

Sensor section here we define test settings such as ping, HTTPs, association test etc

Intelligent capture is where you define how and when you want your AP to perform capture of client traffic

Workflows make things easy for us as they are guided configuration wizards that help us configure things easily and quickly without making mistakes

CLI templates is where we create templates, when it is time to apply template then we apply them using Network profiles

Feature templates are graphical UI based configuration unlike CLI template and they dictate best practice rather than manual CLI based templates, this makes configuration like Meraki but we only have this wireless at the moment

Network reasoner helps troubleshoot offered issues in Network reasoner dashboard

Platform section allows us to use DNAC API for automation and API interaction, it is also used to install device packs for non Cisco devices and also 3rd Party integration such as service now

DNAC comes with report templates

Cisco.com Credentials
Cisco credentials is the same credentials we entered after changing password for DNAC admin on first time login

PnP Connect
PnP connect lets you sync your devices from internet based Cisco’s PnP to DNAC directly, this is used for onboarding routers and switches using PnP in Cloud

Cisco Plug and Play (PnP) Connect is a cloud-based onboarding service that helps you automatically provision new Cisco network devices (switches, routers, access points, etc.) with Cisco DNA Center — no manual configuration or console access needed similar to SDWAN or Meraki onboarding

When a new Cisco device boots up:

• It connects to the PnP Cloud portal.
• The PnP Cloud checks the device’s serial number.
• The device is matched to your DNA Center project.
• The device is redirected to your DNA Center for zero-touch provisioning.

Smart account
“Auto register smart license enabled devices” allows devices to register to selectable “Virtual account inside the Smart account”

Smart Licensing
Smart account defined earlier is used in Smart licensing section, register a smart account and virtual account to have DNAC licensed and in compliance state

Device EULA Acceptance
For LAB I will not accept as not sure what might be the impact on CCO account against licenses

Image Distribution Servers
10.21.1.2 (LOCAL) is DNAC itself, but we can define other image distribution servers not to burden the WAN

Network Resync Interval
This is how often DNAC syncs with network devices, default is 24 hours

SNMP
is timeouts and retires

Authentication and Policy Servers
defined ISE servers

Cisco AI Analytics
This is where you configure AI analytics

Destinations
This is to deliver event notifications when events happen on DNAC

Integrity Verification
Checks if device is compromised on software, hardware level using Known Good Values KGV file from Cisco, which also requires updates from Cisco

IP Address Manager
This is integration with IPAM

Machine Reasoning Engine
Download and keep upto date Cisco’s latest machine learned troubleshooting and reasoning database, make sure it is set to auto update

Debugging Logs
This is to debug logs for DNAC itself, specify a syslog server

Search
Search in DNAC is amazing and you can search clients by MAC address or IP address / track clients with Client 360 link in search result and even search IP pools

API Reference
This comes handy when you are working with API

Fabric Site
Fabric Site contains its own components such as border node, control node, access switches and Wireless controllers – imagine a typical site or building or campus that has network components

A fabric site can span multiple building but only over a high speed, low latency network and not WAN connection

Transit Network
Transit Network either connects multiple Fabric Sites together or connects a Fabric site to an external network
and there are different types of transit networks which will be discussed

Fabric Domain
Fabric Domain is made up of one or more Fabric Sites

Geographic distance between buildings and location decides the fabric site’s boundary

Type of WAN decides the Transit Network type

Depending on the version of SDA and cisco documentation, fabric site can only be so big and scale, if fabric site is bigger than what is supported by SDA, then you will have to break up the single fabric site into 2 Fabric sites
So make sure to check scalability number in Cisco documentation

Make sure you have all devices that will be part of the fabric already discovered, reachable, managed and synced and LAN Automated, preferable compliant also

• Second most important thing is that, make sure that your edge devices do not have a route to DNAC via their default route and must have a specific route, I learned this the hard way

SDA-HQ-FES-01#show ip route 10.21.1.2
% Network not in table

SDA-HQ-FBS-01

conf t 
ip route 10.21.1.0 255.255.255.0 172.17.0.3
!
router isis
redistribute static ip

SDA-HQ-FES-01#show ip route 10.21.1.2
Routing entry for 10.21.1.0/24
  Known via "isis", distance 115, metric 10, type level-2
  Redistributing via isis
  Last update from 172.16.0.72 on GigabitEthernet1/0/4, 00:00:05 ago
  Routing Descriptor Blocks:
  * 172.16.0.74, from 172.16.0.64, 00:00:05 ago, via GigabitEthernet1/0/3
      Route metric is 10, traffic share count is 1
    172.16.0.72, from 172.16.0.64, 00:00:05 ago, via GigabitEthernet1/0/4
      Route metric is 10, traffic share count is 1

SDA-HQ-FES-01#ping 10.21.1.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.21.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 114/131/164 ms

SDA-HQ-FES-01#ping 10.21.1.2 source loopback 0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.21.1.2, timeout is 2 seconds:
Packet sent with a source address of 172.16.0.71
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 111/122/134 ms

DNAC comes with default LAN fabric
We can either choose to use this or create a new fabric
We should always create a new fabric and not use the default

authentication periodic

Enables periodic reauthentication of connected devices.

-The switch forces the endpoint to re-authenticate at regular intervals.
-Helps ensure that access permissions stay valid.
-The interval is usually controlled by the RADIUS server (or another timer setting).

Example use case:
If a device changes security posture (e.g., antivirus disabled), access can be revoked after reauthentication.

authentication timer reauthenticate server

Tells the switch to use the reauthentication interval provided by the RADIUS server instead of a locally configured timer.

Common when using Cisco ISE.
Ensures centralized control of session refresh timing.

access-session inherit disable interface-template-sticky

Prevents the port from inheriting sticky interface-template settings after authentication.

Why useful
Avoids persistent policy settings staying applied after the session ends.

access-session inherit disable autoconf

Stops automatic inheritance of autoconfiguration session settings.

Why useful
Gives tighter manual control over authentication behaviour on the interface.

access-session port-control auto

Sets the port to automatic authentication mode.

Meaning:

Port starts unauthorized
Device must authenticate
Access granted only after successful authentication

This is the standard mode for secure access ports.

Other possible modes (for reference):

mab

Enables MAC Authentication Bypass for devices without supplicant

Used when a device does NOT support 802.1X, such as:

printers
IP phones
IoT devices
cameras

Instead of credentials, the switch sends the MAC address to the RADIUS server for authentication.

Typical workflow:

Switch tries 802.1X
If no response → fallback to MAB
MAC checked in RADIUS database

dot1x pae authenticator

Configures the switch port as an 802.1X authenticator.

This command enables the switch to perform authentication enforcement.

dot1x timeout tx-period 5

Sets the interval between EAP request transmissions to 5 seconds.

0 sec → request sent
5 sec → request sent again
10 sec → request sent again

This controls the gap between attempts.

dot1x timeout supp-timeout 5

Sets how long the switch waits for a supplicant response before retrying.

Example:

If client doesn’t respond in 5 seconds → retry

dot1x max-req 3

Maximum number of authentication request retries sent to the supplicant.

After 3 failures:

Switch may fall back to MAB (if enabled).

Retries up to 3 times If no response → tries MAB

dot1x max-reauth-req 3

Maximum number of retries during reauthentication attempts.

If exceeded:

Session may be terminated or fallback triggered depending on policy.

Putting timers together

Switch sends request
Waits 5 seconds (supp-timeout)

Retry after 5 seconds gap (tx-period)

Repeat up to 3 times (max-req)

tx-period – How often I ask – this will be continuous process when port comes up
supp-timeout – How long I wait – this is what triggers retries

Retries are controlled by max-req, and the spacing between retries is controlled by tx-period.

supp-timeout only controls how long the switch waits for a response after sending each request. supp-timeout simply marks the device as having no supplicant

dot1x timeout supp-timeout 3
dot1x timeout tx-period 10
dot1x max-req 3

t=0 send request
t=3 no reply → supp-timeout expires
t=10 next retry sent (tx-period controls this)
t=13 no reply → supp-timeout expires
t=20 next retry sent
t=23 no reply → supp-timeout expires
STOP (max-req reached)

coming soon

coming soon

TBD – to be done

coming soon

LISP vs BGP in Cisco SDA

In Software-Defined Access:

LISP = fabric internal control plane 🧠
(endpoint location + VXLAN tunnel resolution)
BGP = external route exchange 🌍
(connect fabric to outside networks)

They operate in different routing domains but meet at the border node.

BGP runs only at the border node.

Purpose:

• learn external prefixes from fusion routers / upstream
• advertise fabric prefixes outward
• exchange routes between border nodes (iBGP)

Then how is LISP pub sub deployment in SDA different?

Cisco SDA uses a modified LISP publish–subscribe (pub-sub) model, which changes how mappings are distributed, not what LISP does.

Traditional LISP:

Edge nodes ask the control plane for mappings when needed (Map-Request).

SDA LISP pub-sub:

Edge nodes subscribe to mappings, and the control plane pushes updates automatically.

So SDA reduces lookup latency and improves scale ⚡

Classical LISP control-plane behaviour (pull model)

Host A → Host B
Edge node doesn't know B
→ sends Map-Request to control plane
→ receives Map-Reply
→ builds VXLAN tunnel
→ forwards traffic

SDA LISP publish–subscribe model

Edge node registers endpoints
↓
Control plane stores mappings
↓
Other edge nodes subscribe to updates
↓
Mappings pushed proactively

So instead of:

request → reply

you get:

subscribe → push updates automatically

Much faster convergence and fewer queries.

What exactly gets published?

When an endpoint appears:

Host joins fabric
↓
Edge node registers endpoint to Control Plane Node
↓
Control Plane Node distributes mapping to subscribers

Endpoint mappings in its VN (primary subscription)

Example:

If Edge-1 participates in:

VN = Corp

it subscribes to:

All Corp endpoint location updates

So when a device appears anywhere in the Corp VN:

10.10.20.5 → Edge-3 loopback

the Control Plane Node pushes that mapping to Edge-1.

Edge-1 now already knows where that endpoint lives.

No lookup required later.

What triggers subscription updates

Control Plane Node pushes updates when:

New endpoint appears

Host joins fabric

Endpoint roams

Edge changes

Endpoint disappears

Host disconnects

External prefix changes

New route learned via border node

Border nodes also subscribe

Border nodes subscribe too.

They receive:

Internal endpoint mappings

so they know how to forward inbound traffic from:

Fusion router → fabric endpoint

without querying first.

But does it not cause scalability issues and that is why map-request and map-reply model were used if you are learning / pulling all hosts in a VN?

At first glance, pushing all endpoint mappings to all edge nodes in a VN sounds like it would break scalability. That’s exactly why classical LISP used Map-Request / Map-Reply (pull) instead of flooding mappings everywhere.

But Cisco SDA does NOT push all mappings to all edges. It uses a selective pub-sub model, not a full broadcast subscription model.

Here’s how scalability is preserved.

The key clarification

SDA does not mean:

Every edge node learns every endpoint in the VN

Instead it means:

Edge nodes subscribe only to mappings they are likely to need

The control plane node performs selective distribution.

Edges subscribe to:

Local VN mappings (selectively)

Not the entire VN database.

Instead:

• active mappings
• relevant mappings
• recently used mappings
• mobility-related mappings

The control plane node tracks interest dynamically.

Example with numbers (realistic campus)

Suppose:

Fabric size = 10,000 endpoints
Edges = 40
Endpoints per edge ≈ 250

Each edge typically knows:

its own endpoints
+
active remote peers
+
border mappings

NOT:

all 10,000 endpoints

Another hidden scaling mechanism: map-cache still exists

Even in SDA pub-sub mode:

Edge nodes still maintain a map-cache.

So behaviour is actually hybrid:

Push updates when relevant
Pull mappings when unknown
Cache results locally

This keeps control-plane chatter low.

Host-A talked to Edge-1 and Edge-2
Host-A disconnected
→ notify Edge-1 and notify Edge-2

VXLAN looks like an “application” in above picture

Destination Port used by VXLAN is UDP 4’789
Cisco could have used source UDP 4789 to destination UDP 4789 but they wanted the possibility of load balancing through the underlay network that is why Cisco uses random source port because if everything is using same path then we are wasting bandwidth in thet network

Any endpoint that is connected and is picked up by device tracking and it is in this subnet then it is registered in LISP
but anything outside of this range will still be learned in device tracking but not learned in LISP and will not be advertised out by FBS because security wise anything could connect and get advertised out of the fabric, these endpoints will still be able to speak to devices connected on same switch, but not through fabric

In every VRF a loopback is created dynamically and that loopback is not in underlay but on the overlay, and is used for multicasting and it is shown in above screenshot as “Loopback for Multicasting”

Because we have same Anycast IP and same mac address on all edge devices and because of that we should never connect 2 edges together via a layer 2 trunk, if we do then we will see all sorts of instabilities

Local Database is built on the edge switch for both IPv4 instance and ethernet instance and the eid learned from local database are registered to the control plane

Route import tells us how it came into border node,
It then tells us about the locators it knows about
172.31.255.18 is itself marked as “cfg-intf”
and 172.33.250.1 is other border node known through “auto-disc”

Make sure that control plane has actually acknowledged

With LISP Pub/Sub comes with a ‘dynamic default border’ feature that works if we have advertisesed 0.0.0.0/0 into border per VN > then it is put into LISP database and that is how it becomes default ETR for all of the fabric

With LISP BGP we select the nodes as ‘default border’ but because there is no default route tracking or no default route, in case border node looses routes to uplink, traffic gets blackholed

With ‘dynamic default border’ if default route is not present then it will not be put into LISP and if it is not in the LISP then that device will not be used as default border

During troubleshooting with LISP pub sub, if you see fabric cannot get out and if default route is not present in LISP then that is the issue, in that case check if 0.0.0.0 is on the border node

Below we can see Map-server column having same address as border which means control and border are colocated on same node and it also shows ACK, telling us that it has registered these prefixes and sent ACK back to border saying that it has registered this prefix, if we dont see ACK then it means that there is some issue in border and control communication, either key mismatch and packets were sent to control but it was not accepted

This is edge node that is saying that this endpoint EID has matched this dyanmic EID range and state is ‘site-self’ which means I regsitered it and also tells which map servers or control plane nodes it has been registered and ACK was received for the registeration

This do not register is set for SVI IP because it is anycast IP that is available on all edge nodes

There is no communication between the control plane node, if a control plane node goes down and then comes backup then it has to relearn all the EID from all the edge nodes, CP nodes do not sync with one another , so typically when network is stable it can give the illusion that they are synced due to equal number of EID on both but CP nodes do not talk to one another

map request and map reply
map request is not a request to map an entry or register but it is a query to get a reply from control plane node

Last point is saying that in traditional LISP, Map server only responds to the edge that registered the endpoint, but in SDA version of LISP, map server responds to query from anyone by setting the proxy flag on registration time

CP and border still make connections to one another if they are colocated on same box
So in LISP sessions you will see it establishing LISP sessions from itself to itself

On the edge node you will see LISP sessions based on number of control plane nodes you have

Users column is not actual user but how many instance IDs are using it

Checking detailed command shows us the LISP instances using the LISP session

make sure that your session up time is big and if it is small then it indicates some sort of network instability and network issues

This command actually shows us that there are LISP instances exchanging information with Control plane node and not just TCP session on port 4342 that is up

That message at the bottom that is “Capability Echange” means that there is a session trying to establish but there is something wrong like key exchange and state is also in “waiting”

For IPv4 the instance ID start from 4097 and up
for Ethernet instance ID it starts from 8189 and layer 2 instances are used for Layer 2 connectivity and it creates one layer 2 instances per vlan

One VN is one Layer 3 instance and multiple Layer 2 instances

If there are 2 devices in one IP pool across different edges then they will use Layer 2 instance
if 2 devices are on different IP pool or 2 different subnets then they will speak using Layer 3 instance

When you see “server” keyword that means we are asking control plane node

This is imporant command to troubleshoot endpoint and LISP registration, it shows when it first registered and when it last regsitered

This is output from border node and it is showing ETR as edge node behind which this endpoint lives

only server command will show us last registering ETR

server command with prefix will show us the ETRs (borders) that are registering that prefix and notice that because of priority/weight of 10/10

LISP priority uses lowest priority number as preferred
If RLOC1 has Priority 1 and RLOC2 has Priority 10, all traffic goes to RLOC1 (Active/Standby)
if both RLOC have priority of 10, then it means both routes will be used in loadbalancing fashion then weights are considered, how much traffic will be sent if priorities are same

If both RLOCs have the same priority (e.g., 10), they are considered equal, and traffic is distributed based on weight.

Weight is used for traffic engineering when multiple paths have the same priority. 
It specifies the percentage of traffic a particular RLOC should receive relative to other RLOCs in the same priority group.

If weight is set to 0 on an RLOC then no traffic is load balanced to it, unless it is the last one left

Very important command for troubleshooting for a client, may be it got disconnected or roamed or what not

Notice that first entry that is L3 /32 address being registered inside Layer 2 instance that is ARP regsitration and not the real registration that is also regsitered inside Layer 2 instances

Above command is “server address-resolution” on “Layer 2 instance” on “control node”

Due to VXLAN we can only unicast the packets and broadcasting is not supported unless flooding is enabled on the VLAN but for ARP to specifically work there is a special support in order to get the ARP working, switches snoop the ARP packets for destination inside the ARP message but dont actually flood them yet

LISP then asks for control pane for that destination IP from ARP and control responds with layer 2 mac address corresponding to that L3 address (from device tracking)

then LISP simply rewrites or replaces the broadcast address with the MAC address it received from control plane

this ARP packet is now able to be sent over the unicast over the VXLAN tunnel using Layer 2 instance

This is why silent devices are hard to troubleshoot and do not work over the fabric, this is because they do not produce any traffic and simply want to receive traffic, this makes it hard for device tracking and in turn fabric to not work for those devices

edges nodes have multiple probes going on to speak to those silent devices but there are some devices which are ultra silent and dont even respond to those probes

This command helps in troubleshooting those scenarios because if ARP is not working over fabric then communication will not work

This someone pinging 172.20.23.100 and it arrived on Gi1/0/15

If you see entry for API with mac 0000.0000.00fd in command “show device-tracking database” then it means that ARP packet arrived on the edge node but did not have response from Control node over LISP yet and waiting to be resolved to convert ARP broadcast into unicast

After this resolution completes entry becomes “RMT” (which I guess means remote) with L2LI0 as interface

Because device tracking timers age quickly, this process of ARP resolution might be happening again

Important to note that unicast ARP is received on the remote device and sometimes some IoT devices in testing showed that does not like unicast ARP and only respond to broadcast ARP so in that case we will have to enable the Flooding over the VLAN

It is no good to speak to control plane about every packet we get
That is why edge node has map-cache to cache the RLOC received for an endpoint for 24 hours

See action
The reason it is 0.0.0.0/0 has action send-map-request because even if we have default border or even dynamic default border we need to still ask control plane node as there might be a better path for destination

On each edge node in order to reduce queries to control plane node a few “negative” map-cache entries are added in advance with forward native action, forward native on border means to use routing table and not LISP which can have ISIS , OSPF , BGP or static entry for any routes falling under this range but for edge nodes forward-native means connection will be dropped as there is no other means other than LISP

This is done in weird blocks of 0.0.0.0/5 and 8.0.0.0/7 to tell that I dont have routes for those but I have default route 0.0.0.0 and other prefixes we learned from outside fusion world

This is only there for “expires” time which is 15 minutes, the whole function of map-cache is to not consult control node, so this entry means that for those unknonwn destinations do not ask or reach control plane but as this entry expires, edge can reach out to the control plane node instead try to use the routing table (action: forward-native)

0.0.0.0/0, uptime: 1y29w, expires: never, via static-send-map-request
  Encapsulating to proxy ETR
0.0.0.0/5, uptime: 00:00:34, expires: 00:14:25, via map-reply, forward-native
  Encapsulating to proxy ETR
! 0.0.0.1 - 7.255.255.255
8.0.0.0/7, uptime: 38w5d, expires: 00:04:38, via map-reply, forward-native
  Encapsulating to proxy ETR
! 8.0.0.1 - 9.255.255.254
10.16.101.0/24, uptime: 1y29w, expires: never, via dynamic-EID, send-map-request
  Encapsulating to proxy ETR
10.64.0.0/11, uptime: 38w5d, expires: 00:05:08, via map-reply, forward-native
  Encapsulating to proxy ETR
10.116.2.0/24, uptime: 1y29w, expires: never, via dynamic-EID, send-map-request
  Encapsulating to proxy ETR
10.116.3.0/24, uptime: 1y29w, expires: never, via dynamic-EID, send-map-request
  Encapsulating to proxy ETR
10.116.4.0/24, uptime: 1y29w, expires: never, via dynamic-EID, send-map-request
  Encapsulating to proxy ETR

Above slide is little bit wrong

For LISP Pub Sub deployment we see “Negative cache entry, action: forward-native” but for LISP BGP deloyment we see “Encapsulating to proxy ETR” but see below

8.0.0.0/7, uptime: 38w5d, expires: 00:13:47, via map-reply, forward-native
  Sources: map-reply
  State: forward-native, last modified: 38w5d, map-source: 172.20.239.124
  Active, Packets out: 1535384(884381184 bytes), counters are not accurate (~ 00:00:35 ago)
  Encapsulating to proxy ETR

it will use the normal routing table (no VXLAN/LISP encapsulation) because the entry is forward-native, even though a proxy ETR (172.20.239.124) is listed

This line can appear in map-cache entries when:

1. the prefix is learned via map-reply
2. a proxy ETR exists – A Proxy ETR (PETR) in Cisco LISP / SD-Access is typically the Default Border Node, not the Internal Border Node

A Proxy ETR is used when a fabric device needs to send traffic to destinations outside the LISP mapping system (for example: internet prefixes like 8.0.0.0/7).

Instead of dropping the packet (because no mapping exists), the fabric edge or border node:

➡ encapsulates the packet
➡ sends it to the PETR
➡ PETR forwards it toward external networks using normal routing

So PETR acts like an exit gateway for unknown/non-fabric destinations.

the state field of forward-native overrides it and tells to use RIB/FB

Cisco explains proxy-ETR usage like this:

When a destination EID is not reachable via the mapping system, a proxy ETR can be used for encapsulation, But only when the map-cache entry is in encapsulating state.

State	Meaning
forward-native	use RIB/FIB
encapsulating or complete	send to ETR
negative	drop
incomplete	awaiting mapping

Because this is a subnet 10.48.13.0/24 behind a border, we see 2 borders

Whenever we see Pri/Wgt of 10 and 10 on both borders then it means we are load balancing at VXLAN level, like half flows are sent to one border and half flows are sent to another border and it is not gauranteed that VXLAN UDP packets to 172.31.255.18 are taking a single path through network always and not getting load balanced, even these VXLAN tunnel packets are also load balanced

showing ip route in vrf will not show much except on border nodes but on the edge device there is no default route and no other routing present other than LISP VXLAN and fabric stuff
But if we check CEF there is more info because LISP -> CEF directly talks to CEF

Layer 2 forwarding ia s bit different in fabric
Entry for dynamic MAC learning on edge shows CP_LEARN via L2LI0 tells that this MAC belongs to this vlan on a different edge node

For layer 2 flooding to work on a vlan, the underlay multcasting needs to work
If LAN automation is used, it sets up the underlay multicast
Every edge device shows up as source for a multicast group

We can see the 2 instances that are receiving the multicast traffic (flooded traffic)

This is to verify if LISP is programming stuff correctly in hardware and this is where MATM comes in
MATM is CEF equivalent in layer 2

traditionally we could debug dot1x, debug authentication and debug radius etc but now we cannot do that, SMD sits as a seperate process outside of the iosd so we need to follow show logging <process> <name> format

It is very important that RADIUS is up from SMD state as well
in some cases IOS thinks RADIUS server is up, but if it is down for SMD then it will not communicate with RADIUS server and it is waiting on keepalive timer to try again

coming soon

A Security Group Tag is a 16-bit label attached to traffic to identify the security group or role of the source (e.g., Employees, Guests, IoT Devices).
SGTs are used in Cisco TrustSec / SD-Access environments to create role-based access control policies that don’t rely on IP addresses.

SGT is not just used for SGACL or filtering only, because it is a tag on IP packet, this is also being used Policy based routing and also QoS – QoS based on SGT

There are 2 ways of classifying the devices in an SGT group

1. Dynamic
   • ISE
     • 802.1x
     • MAB, profiling
     • pxGrid, Rest API
     • ACI
2. Static
   • IP address
   • Subnets
   • VLANs
   • L3 interface
   • VN
   • Port

Traffic or packets are classified and tagged on ingress into the network which is access layer and filter on the egress of the network

Because classification and tagging on ingress of the network and filtering on egress of the network, it is very important to have tags pushed or transport the tags to all devices on the network

There are 2 ways to do that,

No packet tagging, but use control plane, using SXP (Scalable Group Exchange) protocol to teach foreign devices about the IP to SGT over TCP control plane
This way frame or packet has not been modified or tag is not added in the IP header, and target device also understood the tag that applies to that traffic.

SXP can be activated on a headend only that makes drop or allow policy decisions, it does not have to be applied on all intermediate nodes in the topology hop by hop unlike QoS that requires every hop to do QoS enforcement.

other one is inline tagging

with inline tagging we also have some encryption options such as IPSec or MACsec to prevent people from messing with tags

By default you can go from SXP to inline tagging
to go from inline tagging to SXP you must enable SGT caching

All firewall vendors like Firepower, Checkpoint, Fortigate and Palo Alto, do support pxGrid based implementation for SXP, pxGrid is a publisher and subscriber model where publisher can push information down to subscribers for different topics and one topic can be SXP protocol that has a table that contains IP address to SGT tag mapping

SXP can be activated on a headend only that makes drop or allow policy decisions, it does not have to be applied on all intermediate nodes in the topology hop by hop unlike QoS that requires every hop to do QoS enforcement.

End to end SGT work flow

Filtering with SGTs is always done on egress or last switch where destination is connected,
this is because we do not want to overload our access layer switches with all policies and track of all devices connected on the network ahead of it

This optimizes and keeps memory size smaller for small devices,

Access or ingress will only add tag to the traffic and send,
it is the destination switch after it has received the packet,
checks the SGT on the packet – if not on packet, derive SGT from the SXP learned IP to SGT table.
Find out the mac / destination port + the SGT assigned to host on that port – if not assigned on port derive from SXP learned IP to SGT table for that IP
then egress switch will take a policy decision and drop or allow based on policy,

Switches in aggregation or core can be set to look at the destination IP and determine the SGT from SXP learned IP to SGT tag before sending packet out towards destination, this is to drop traffic in core rather than egress

on destination egress or core a log is generated for all deny or drops, if all switches in network point to central logging server, these logs can tell us about the dropped traffic

This shows the policy matrix and how switches that have hosts with certain SGT only pull “columns” from matrix for those hosts only, as soon as a host is connected that has a new SGT, policy column for that SGT is downloaded on the switch, this is very on demand like fashion where switch does not have to download all the policies of the policy matrix and be light weight

Be careful of platform support for SGT when implementing to make sure that platform does support trustsec for all actions such as Classification, Propagation and Enforcement

on 3850 as a client we are setting SXP peer (almost like a routing peer) to send it the IP to SGT mappings (local mode)

9K is SXP receiver only using “mode local listener” instead of a speaker

Think of Speaker / local as “teacher” and listener as “learner”

show cts role-based sgt-map all details
! check mappings on 3850 switch 

show cts sxp connections brief
! check peers

in above “show cts role-based sgt-map all details” – we can see the one attached host got SGT tag of 6:Full_Access and source is “LOCAL”
similarly not shown here but WLC also a client that got SGT of 3:BYOD and at the bottom we run “show cts role-based sgt-map all details” command on core C9K and we can see both tags learned from SXP (3850 and WLC). Aggregation layer is building table automatically as devices are learned from Access layer devices

Enabling SGT/SGACL Enforcement

Before SGT/SGACL can be enabled on Cisco devices, make sure that SGT tag for network devices TrustSec_Devices is assigned by default to the network device and make a policy that always allows TrustSec_Devices is always allowed to speak to ISE and infrastructure, why is that needed? because there is a default rule in policy, if it is set to deny then all control plane traffic from device to ISE will be dropped

There was a case once when 2000 switches disappeared from the network, that customer did not have network device SGT like TrustSec_Devices above, they also did not have policy against it to make devices from TrustSec_Devices speak to infrastructure servers SGT, third thing is that they turned on default deny rule in policy

Do not turn on that default deny unless you are really sure that every protocol and everything has been taken care off as it will start dropping the Unknown / untagged SGT traffic as well

Unknown SGT refers to the default tag used when a packet, user, or device does not have a valid SGT assigned. In Cisco TrustSec, this value is typically SGT = 0 and is considered unclassified or unauthenticated traffic. Whenever Unknown SGT of 0 is seen on traffic or host, it means following:

-The client is not authenticated via 802.1X/MAB/web-auth
-Even if authenticated from ISE, there was no SGT in Auth Z results from ISE
-The TrustSec policy mapping isn’t configured

Most TrustSec deployments deny or restrict traffic with Unknown SGT:

• Best practice: Block or isolate Unknown to → Protected traffic in policy matrix
• Allow Unknown to → Internet (e.g., guest networks) in policy matrix

Assign TrustSec_Device to network devices

SGT CTS “peer authentication” between ISE and Device is done through EAP-FAST as PAC file is downloaded on the Network device, PAC which is used in case you want password less certificate like authentication without having certificates. This is called PAC bootstrapping, this is used to download policies, SGACLs and SGT tags then later SXP is used to send or download the SGT to IP mapping separately.

look at send from ISE PSN and test connection button

If there are large number of policy changes, having CLI access from ISE is much faster and better at times, for example there was a customer with 200 x 200 policy matric, it took almost 4 hours to finish the update, it was changed to CLI for all devices and all updates completed in 30 mins, if it is small incremental updates, RADIUS CoA is fine

This device ID is the hostname of the device and password corresponds to command

cts credential id DEVICE-ID password PASSWORD

! this is done in non config , enable mode
device>cts credentials id <DEVICE-ID> password <PASSWORD>
show cts credentials
show cts environment-data
show cts role-based permissions

Setting long timers make sure policy is refreshed on devices annually and also only when there is an explicit change in policy

Why the pac key appears under the radius-server host command?
Even though the PAC is used for TrustSec (CTS/NDAC) and not for normal RADIUS authentication, the PAC is delivered through RADIUS using cisco’ vendor attribute, PAC exchange is not a standard RADIUS authentication — it is a special RADIUS message (Cisco-vendor attribute) used only for TrustSec device bootstrapping that is why it is configured under RADIUS server configuration block along with RADIUS shared secret.

cts authorization list <AUTHZ_List_Name> is the list of ISE RADIUS nodes that are running TrustSec

Why Cisco did it this way

Cisco chose to reuse the RADIUS channel rather than invent a new protocol:

• RADIUS is already required for 802.1X authentications
• Switches already have reachability to ISE
• The PAC exchange can ride over the same transport (UDP 1812/1645)

So the PAC bootstrap process piggybacks on RADIUS → therefore, the PAC key configuration lives inside the radius-server settings.

Full configuration of ISE RADIUS Servers with PAC

! Enable AAA
aaa new-model

! Define ISE as a RADIUS server (auth/acct) and include the PAC bootstrap secret
radius server ISE1
 address ipv4 10.10.10.10 auth-port 1812 acct-port 1813
 key RADIUS_SHARED_SECRET
 pac key RADIUS_PAC_SECRET
!

! send vsa or vendor attributes in RADIUS authentication request 
radius-server vsa send authentication

! (Optional) put servers into a group and set a source interface
aaa group server radius ISE-GRP
 server name ISE1
 ip radius source-interface Vlan10

! CTS/NDAC: define the authorization list used for policy download only (not tags - tags are pulled before SGACL or policy is pulled) - as clients connect with new SGT , more policy columns are pulled
cts authorization list CTS-AUTHZ

! 802.1X + CTS use the RADIUS group
aaa authentication dot1x default group ISE-GRP
aaa authorization network CTS-AUTHZ group ISE-GRP
! aaa authorization network command is usually used to allow on network or authorize audience or entity authenticated through network ports and this config says that authorized list of server (which are allowed to make CLI or COA changes) will be downloaded from ISE-GRP

! which makes it look like this 

aaa authorization network ( CTS-AUTHZ ) group ISE-GRP
aaa authorization network ( cts authorization list ) group ISE-GRP

! Define credentials for EAP-FAST I-ID, these are configured under enable mode and not in config mode
cts credential id DEVICE-ID password PASSWORD

! enable 802.1x on system level 
dot1x system-auth-control
! enable CTS enforcement
cts role-based enforcement

SXP does not carry SGACL policies.

SXP only carries IP-to-SGT mappings

SGACL policy travels via DTLS tunnel established using PAC.

Policy matrix is translated or converted into bunch of SGACLs and then sent out to devices

Sequence and use of PAC:
1. Authenticate the switch to ISE for TrustSec
2. Receive the PAC credential
3. Establish a secure, encrypted control channel DTLS for SGACL policy download

It is sent through the PAC → NDAC → Secure DTLS Trust Tunnel that is established after the PAC is provisioned

Switch proves identity to ISE to download PAC -> RADIUS
Policy download (SGACLs and SGT tags – “TrustSec Bootstrapping”) -> PAC established DTLS (UDP)
IP-to-SGT sharing between devices -> SXP (TCP)

First thing to notice in this output is the Local Device SGT that is assigned to network device, any control plane communication from this device will be assigned SGT

Then coming below we can see 3 TrustSec ISE servers are set as servers for downloading SGT tags and SGACL policy (but not SGT to IP mappings which are downloaded over SXP)

We define more tags in ISE, in above picture we can see ACI EPGs (contracts) defined as tags and this is through automation , automatically created through API

These are stateless ACLs unlike firewalls, this is exact filtering as described ACEs
but best thing about these ACEs is there are no IP addresses

One thing to notice in above screenshot is ability to define multiple ACLs in a single cell of the policy matrix but this is turned off by default as it is not supported by all devices yet because WLCs and Nexus only support single ACL for an SGT and DGT filtering

Only IOS XE switches are supporting multiple ACL per cell

above we can see manual IP to SGT map, which can also be pushed from ISE via CLI or from ISE via SXP

Even if switch has policy matrix table downloaded, and switch also has all the SGT tags, switch will not enforce on traffic unless command is “cts role-based enforcement” is defined
Second command allows us to enable on per VLAN, this is very significant because we can enable SGT enforcement incrementally on VLANs

environment data is SGT tags
policy is the policy matrix

As we can see that RADIUS flow is different
“Environmental Data download + Server list” is different flow before SGACL policy is downloaded
SGACL policy download is from the server list, server list was fetched with environment data

This was done because in peak times when RADIUS servers are busy it can be too much load to download the SGACL policy over same ISE PSN nodes and it is better to download over dedicated ISE TrustSec PSN nodes

in above screen shots dynamic author (RADIUS servers allowed to do CoA) are defined
-PAN should be defined for SGT related flows
-PSNs should be configured for 802.1x / MAB

In older versions of ISE, clicking on Deploy is not enough, there is a confirmation icon on top that needs to be click and confirm, only then ISE notifies all switches that there is a change and download the new policy

There is a policy validation button that runs this command “show cts role-based permissions” and validates that ISE has same policy as devices and if there is any mismatch or issue then an Alarm is generated from ISE

SGACL denies will show as log, and you will see that logging hits are shown as well which means that if there are a lot of logs then number of hits accumulated will be reported under logging_interval_hits and log will be generated, but in some cases auditor will come in and say that they need to see a log for every drop and allow, and at that point we need to understand that this is a switch and not the firewall, with SGACL enforcement it is not possible to get log for every hit

show cts role-based counters
! shows * to * default rule 
! also shows from and to columns 
! SGACL is done in hardware, unless needs punting 
! for example TCAM or hardware is full, log in the end of ACE , makes SW counter increment otherwise concentrate on HW-Denied and HW-Permitted columns

Software denies and software permits are for to the box traffic or traffic destined for the switch, including the DHCP and ARP permits will also increment the Software counters, SGACL enforcement is in hardware

One of the examples of confusion with ping is that people test access control by pinging the switch SVI and say why is the hardware counter not increasing, it will be denied in software SW-Denied, the thing with SVI ping is that it is going up through software control plane to the CPU and then responding (punted to CPU)

Wireless APs do “enforcement” with SGACLs

TrustSec implementation in wireless does follow the same principal of tagging on ingress and filtering on egress (APs)
APs do the filtering also on egress in wireless to wireless communication, that confuses people as they see SGACL download on WLC but they do not see permit or deny logs in WLC CLI, it makes sense to check the WLC but enforcement for wireless to wireless traffic is being done on AP for scaling reasons otherwise WLC will be overwhelmed as WLC can do enforcement for wireless to wired communication

Ingress AP will tag the packet and send it across the WLC over CAPWAP due to central switching and egress AP will do the lookup for SGT of the destination client using client table and perform policy enforcement based on that

Skipped Nexus 7000 SGT Considerations

Common issues

SGT trustsec relies on IP device tracking

In case you have SGT disappearing from host, then check if this bug is in effect and usually happens on older unpatched code, the workaround was to turn off ndp (which is IPv6 ARP mechanism) tracking from IP device tracking and also turn off dhcpv6 tracking

in case SGACL download is not happening we need to check following:

Make sure pac is present

show cts pac all

Make sure AAA servers are marked alive

show aaa servers 

Make sure device can reach ISE

show cts environment-data

Check ISE to make sure SGACL is formatted properly

Make sure there are no errors in device-tracking as whole solutions rides on device-tracking to work

Sometimes bad implementation of SDWAN can cause fragmentation of large packets and sometimes that can cause ISE to device download of SGACL of DTLS (PAC based) to break for large packets causing “partial download”, that is why it is so important to first test for fragmentation over greenfield or brownfield deployment and also test large elephant connections with large packets – on the side note large elephant connections over IPSec based tunnels are heavy on platform’s ability to encrypt large traffic

So if you see partial download of SGACL, then always check for fragmentation issue, because by default for this pac based DTLS connections DF bit is set and routers from all vendors do not like DF bit

Software Defined Access (SD – Access) – SGT/VXLAN

These SDA VNs are VRFs but these are campus wide VRFs,

Macro Level segmentation is devices of different management domains go in their own VN

Micro Segmentation is used for access control within the VN

LISP is another great optimization at the access layer and it reduces or optimizes the routes by only installing /32 host routes on access layer switch to which its connected hosts are initiating connections to and from, access layer no longer needs to maintain the large routing tables, LISP installs routes in VRFed routing table of access switches

VXLAN is carried inside UDP just like an layer 7 application and VXLAN carriers the whole original ethernet frame and not just IP packet

VN and SGT are carried inside the VXLAN header
The SGT (Security Group Tag) is not added to the original inner IP packet.
It is carried only in the VXLAN header as metadata, and in order to use SGT capabilities outside of the network with Cisco gear we can use TrustSec which uses SXP and with other vendors we can use PXGrid

Policy matrix is created on DNAC and then pushed to ISE , ISE then pushes the SGT environment data (SGT Tags and Trusted Server list) over TCP, SGACL using NDAC over PAC based DTLS and then finally IP to SGT mapping on border nodes using TCP SXP

ACL or contracts are defined in badge color cells

This is how it is enabled inside LISP

If we have SD Access transit or SDWAN, we can carry SGT to other fabric sites

SDA transit uses LISP as control plane between borders of both fabric sites
and then on data plane we have VXLAN header that crosses between fabric sites
but in order to accommodate the VXLAN header we will need 1588 or better 1600 MTU

Skipped Firewall Integration with SD-Access

Skipped Meraki and 3rdParty Interop

Use Case Review -WAN

-medical devices and servers are assigned SGT and allowed to speak to one another
-Summary SGT of 10.0.0.0/8 in SXP for all users and devices in 10.0.0.0/8 space and this keeps the SGT under 12K
-Create a Policy Matrix that has Known_SGT <-> Known_SGT permit
-Create a Policy Matrix that has Known_SGT <-> Summary_SGT deny
-For Internet traffic default route is tagged as Internet_SGT
-above Internet_SGT leaves reserved tag called Unknown to handle traffic for medical devices that are not tagged

SXP Reflector Like Design

in above SXP connections, if one device speaks (has a speaker role) IP to SGT mapping then on the other end if there is a listener it will listen and learn the IP to SGT mapping and if a device listens (has a listener role) then on SXP connection it can learn IP to SGT mapping from a speaker

once a new mapping of IP to SGT is learned by aggregation Listener, it “speaks” those mapping to all the listeners

Above shows Medical_device <-> Medical_server allow

Above example is the source on 10.0.0.0 network that has fallen on 10.0.0.0/8 SGT of Enterprise and is trying to speak to Medical_device and by policy that is denied

cts manual – tells the router interface to assign sgt manually to traffic over this interface

policy static sgt 2 trusted – All traffic that enters or exits this interface is tagged with SGT = 2
“Trusted” means this interface accepts incoming SGT tags from the peer without overwriting them. If the link partner already sends SGT-tagged frames, the ASR1K trusts them instead of stripping or replacing them.

no cts role-based enforcement – on the router interface or layer 3 interfaces which are in the middle of the path, we have to turn off any kind of enforcement in order to avoid dropping any traffic , Because the ASR1K in this use case is only tagging packets, not enforcing access control. This keeps the device acting as a TrustSec transit / tagging device rather than a policy enforcement point.

cts manual 
policy static sgt 2 trusted
no cts role-based enforcement

so above config achieves – tag outgoing traffic, trust the tag from connected device for incoming traffic and disable enforcement because this is a transit node and not access layer policy point

show platform hardware fed switch active fwd-asic resource tcam utilization

! Max Values column
! Used Values 

! first value is IP "/" second value is SGT

! "Directly or indirectly connected routes"
! for 9300 10K limit officially for both IP and SGT combined

! "Security Access Control Entries" are number of ACEs

! "SGT_DGT" is number of cells from Policy Matrix

This healthcare provider hit the scale limit of SGT on access layer so they moved the enforcement point on routers as router hardware has much more scale

If you want to know that you are tagging traffic, simply turn on netflow with cts with above commands and even if you dont export that flow anywhere, we can see local cache , great for tshoot

use this command to see the tagging info

show flow mon cts-mon cache

you will see that in above output we see destination tag as 0, because we are running this command on ingress or access layer where there is no info about destination host or its assigned SGT

Stealthwatch has ability to specify source and destination tag

Skipped DMVPN SGT tagging

Skipped SGT/ACI

Skipped Cloud

! on ingress or access 
cts sxp enable
cts sxp connection peer 10.1.44.1 source 10.1.11.44 password default mode local

! on core where we just learn from access as listener
cts sxp enable
cts sxp default password cisco123

! peering with Cat3K
cts sxp connection peer 10.1.11.44 source 10.1.44.1 password default mode local listener hold-time 0 0

! peering with WLC 
cts sxp connection peer 10.1.33.24 source 10.1.44.1 password default mode local listener hold-time 0 0

! check IP to SGT table
show cts role-based sgt-map all details

! check SXP connection on on core
show cts sxp connections brief

----------------------------------------------


! Enable AAA
aaa new-model

! Define ISE as a RADIUS server (auth/acct) and include the PAC bootstrap secret
radius server ISE1
 address ipv4 10.10.10.10 auth-port 1812 acct-port 1813
 key RADIUS_SHARED_SECRET
 pac key RADIUS_PAC_SECRET
!

! send vsa or vendor attributes in RADIUS authentication request 
radius-server vsa send authentication

 key RADIUS_SHARED_SECRET
 pac key RADIUS_PAC_SECRET
!

! send vsa or vendor attributes in RADIUS authentication request 
radius-server vsa send authentication

! (Optional) put servers into a group and set a source interface
aaa group server radius ISE-GRP
 server name ISE1
 ip radius source-interface Vlan10

! CTS/NDAC: define the authorization list used for policy download only (not tags - tags are pulled before SGACL or policy is pulled) - as clients connect with new SGT , more policy columns are pulled
cts authorization list CTS-AUTHZ

! 802.1X + CTS use the RADIUS group
aaa authentication dot1x default group ISE-GRP
aaa authorization network CTS-AUTHZ group ISE-GRP
! aaa authorization network command is usually used to allow on network or authorize audience or entity authenticated through network ports and this config says that authorized list of server (which are allowed to make CLI or COA changes) will be downloaded from ISE-GRP

! which makes it look like this 

aaa authorization network ( CTS-AUTHZ ) group ISE-GRP
aaa authorization network ( cts authorization list ) group ISE-GRP

! Define credentials for EAP-FAST I-ID, these are configured under enable mode and not in config mode
cts credential id DEVICE-ID password PASSWORD

! enable 802.1x on system level 
dot1x system-auth-control
! enable CTS enforcement
cts role-based enforcement

----------------------------------------------

show cts environment-data 
! shows local device SGT
! shows servers that are authorized list servers 
! shows downloaded SGT tags on devices

----------------------------------------------

! define SGT for local servers connected to switch
cts role-based sgt-map 192.168.31.1 sgt 100
cts role-based sgt-map 192.168.32.0/24 sgt 20
cts role-based sgt-map 10.x.x.0 sgt 30

! tag default route to Internet_SGT
! This is incase you want to use Unknown tag for something else 
! for default route tag, the device must have defafult route either as a static or dynamic for this tagging to work
! this allows us to do something like Medical_devices <-> Internet_SGT deny
cts role-based sgt-map 0.0.0.0/0 sgt 2500


! enableing SGT enformcement globaly 
cts role-based enforcement

! or on specific vlans for slow rollout
cts role-based enforcement vlan-list 40

----------------------------------------------

! download or refresh SGT tags
cts refresh environment-data

! download or refresh SGACLs or policy 
cts refresh policy

----------------------------------------------

show cts role-based permissions 
! shows SGACLs

show cts policy sgt 4
! shows SGT and its related policies in detail

show ip access-list

show cts role-based counters
! shows * to * default rule 
! also shows from and to columns 
! SGACL is done in hardware, unless needs punting 
! for example TCAM or hardware is full, log in the end of ACE or to the box traffic such as Trust_Devices SGT, makes SW counter increment otherwise concentrate on HW-Denied and HW-Permitted columns

----------------------------------------------

show device-tracking database 

show cts role-based sgt-map 10.0.0.1

show device-tracking database interface gig2/0/11

----------------------------------------------

! If SGACL download errors happen 

show aaa servers
! make sure AAA servers are marked alive 

show cts pac all
! make sure pac is present

show cts environment-data 
! check if device can communicate with ISE 

----------------------------------------------

router(config)#interface Ten1/1/1
cts manual 
policy static sgt 2 trusted
no cts role-based enforcement
! tag outgoing traffic, 
! trust the tag from connected device for incoming traffic
! disable enforcement because this is a transit node and not access layer policy point

show cts interface brief 

----------------------------------------------

show platform hardware fed switch active fwd-asic resource tcam utilization

! Max Values column
! Used Values 

! first value is IP "/" second value is SGT

! "Directly or indirectly connected routes"
! for 9300 10K limit officially for both IP and SGT combined

! "Security Access Control Entries" are number of ACEs

! "SGT_DGT" is number of cells from Policy Matrix

----------------------------------------------

flow record cts-v4
  match ipv4 protocol
  match ipv4 source address 
  match ipv4 destination address
  match transport source-port
  match transport destination-port
  match flow direction
  match flow cts source group-tag <<<<
  match flow cts destination group-tag <<<<
  collect counter bytes
  collect counter packets

flow exporter EXP1
  destination 10.1.1.1
  source Gig1

flow monitor cts-mon
  record cts-v4
  exporter EXP1

interface vlan 10
  ip flow monitor cts-mon input
  ip flow monitor cts-mon output

show flow mon cts-mon cache