Introduction
This document describes how to configure and verify the Cisco Inline Tagging feature on a Cisco Catalyst Switch 9300.
Requirements
Cisco recommends that you have knowledge of these topics:
You must have Cisco ISE deployed in your network, and end users must authenticate to Cisco ISE via 802.1x (or other method) when they connect wired. Cisco ISE assigns a Security Group Tag (SGT) once they authenticate to your wired network.
Components Used
The information in this document is based on these software and hardware versions:
- Cisco Identity Services Engine that runs 3.0 P5
- Cisco Catalyst 9300 Switch that runs 17.03.02a
- Cisco Catalyst 9300 Switch that runs 17.07.01
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command.
Background Information
Inline tagging is implemented at the Access layer because this is the first point of contact of the information. In other words, all your end devices are connected to the Access layer. Once the Access-layer devices does the classification it is necessary to share this information with the devices that do the enforcement. To do this, the NAS can add 20 bytes to the ethernet frame. This is the CMD (Cisco metadata) field of the frame. Inside of this the SGT is included.
Configure
Network Diagram
Topology diagram
- PC1 authenticates and ISE dynamically assigns SGT3.
- C9300A inline tagging with C9300B
- PC2 authenticates and ISE dynamically assigns SGT 17
- C9300B enforces ICMP traffic from SGT3 to SGT17.
Inline Tagging
C9300A
interface TwoGigabitEthernet1/0/4
switchport trunk allowed vlan 761
switchport mode trunk
cts manual
policy static sgt 2 trusted
end
C9300B
interface GigabitEthernet1/0/4
switchport trunk allowed vlan 761
switchport mode trunk
cts manual
policy static sgt 2 trusted
end
You must use the command cts manual and then policy static to enable inline tagging. The sgt used on the command can be the sgt of the Network device or any other its a placeholder. The function of the trusted command is to instruct the switch to honor the SGT, if it receives traffic with CMD header. Without trusted command, the switch tags all traffic that flows from that interface with the defined SGT.
Checks
Access Session Downloads SGT
PC1
Switch#show authentication session interface Tw1/0/3 details
Interface: TwoGigabitEthernet1/0/3
IIF-ID: 0x1FB0D90E
MAC Address: 507b.9df0.34bb
IPv6 Address: Unknown
IPv4 Address: 10.4.16.142
User-Name: 50-7B-9D-F0-34-BB
Status: Authorized
Domain: DATA
Oper host mode: multi-auth
Oper control dir: both
Session timeout: N/A
Common Session ID: 3D781F0A0000000F2AE95F4A
Acct Session ID: 0x00000005
Handle: 0x02000004
Current Policy: POLICY_Tw1/0/3
Local Policies:
Service Template: DEFAULT_LINKSEC_POLICY_SHOULD_SECURE (priority 150)
Security Policy: Should Secure
Server Policies:
SGT Value: 3
Method status list:
Method State
mab Authc Success
PC2
Switch#show authentication session interface Gi1/0/1 details
Interface: GigabitEthernet1/0/1
IIF-ID: 0x1D1CA5C7
MAC Address: 507b.9df8.02ed
IPv6 Address: fe80::114c:dce1:ffa1:1642
IPv4 Address: 10.4.16.141
User-Name: 50-7B-9D-F8-02-ED
Status: Authorized
Domain: DATA
Oper host mode: multi-auth
Oper control dir: both
Session timeout: N/A
Common Session ID: 21781F0A000000242AF41195
Acct Session ID: 0x00000004
Handle: 0x4300000f
Current Policy: POLICY_Gi1/0/1
Local Policies:
Service Template: DEFAULT_LINKSEC_POLICY_SHOULD_SECURE (priority 150)
Security Policy: Should Secure
Server Policies:
SGT Value: 17
Method status list:
Method State
mab Authc Success
Switch Learns IP-SGT Binding
C9300A
Switch#show cts role-based sgt-map all
Active IPv4-SGT Bindings Information
IP Address SGT Source
============================================
10.4.16.142 3 LOCAL
C9300B
Switch#show cts role-based sgt-map all
Active IPv4-SGT Bindings Information
IP Address SGT Source
============================================
10.4.16.141 17 LOCAL
10.31.120.33 2 INTERNAL
Authorization status between C9300A and C9300B
C9300A
Switch#show cts interface Two 1/0/4
Global Dot1x feature is Disabled
Interface TwoGigabitEthernet1/0/4:
CTS is enabled, mode: MANUAL
IFC state: OPEN
Interface Active for 01:36:44.332
Authentication Status: NOT APPLICABLE
Peer identity: "unknown"
Peer's advertised capabilities: ""
Authorization Status: SUCCEEDED
Peer SGT: 2:TrustSec_Devices
Peer SGT assignment: Trusted
SAP Status: NOT APPLICABLE
Propagate SGT: Enabled
Cache Info:
Expiration : N/A
Cache applied to link : NONE
Statistics:
authc success: 0
authc reject: 0
authc failure: 0
authc no response: 0
authc logoff: 0
sap success: 0
sap fail: 0
authz success: 0
authz fail: 0
port auth fail: 0
L3 IPM: disabled.
C9300B
Switch#show cts interfac Gig 1/0/4
Global Dot1x feature is Disabled
Interface GigabitEthernet1/0/4:
CTS is enabled, mode: MANUAL
IFC state: OPEN
Interface Active for 01:34:18.433
Authentication Status: NOT APPLICABLE
Peer identity: "unknown"
Peer's advertised capabilities: ""
Authorization Status: SUCCEEDED
Peer SGT: 2:TrustSec_Devices
Peer SGT assignment: Trusted
SAP Status: NOT APPLICABLE
Propagate SGT: Enabled
Cache Info:
Expiration : N/A
Cache applied to link : NONE
Statistics:
authc success: 0
authc reject: 0
authc failure: 0
authc no response: 0
authc logoff: 0
sap success: 0
sap fail: 0
authz success: 0
authz fail: 0
port auth fail: 0
L3 IPM: disabled.
Troubleshoot
To troubleshoot any issues, consider:
- Frame is always tagged at ingress port of SGT capable device.
- Tagging process prior to other L2 service such as QoS.
- No impact IP MTU/Fragmentation.
- L2 frame MTU impact: ~ 40 bytes (~1600 bytes with 1552 bytes MTU)
- MACsec is optional for capable hardware.
Packet Capture/EPC
Inline tagging flow
If you want to troubleshoot inline tagging you would need to take a packet capture at the ingress.
Tip: If you take a pcap in the uplink of the SW you do not see the tag since this is included at the interface level so the EPC can be taken before the tag is applied.
Caution: There are some exceptions to this like C4500. Due to the architecture of the C4500, it is not able to detect the CMD header even if you take the pcap at the ingress interface. For this specific cases you can use Netflow, Netflow Trustsec configuration
Take Embedded Packet Capture (EPC) on Ingress Port of the C9300B
Switch#monitor capture test interface Gig 1/0/4 both
Switch#monitor capture test match any
Switch#monitor capture test start
<<Generate traffic from PC1 to PC2>>
Switch#monitor capture test stop
After you take the EPC you can use show monitor capture buffer brief command to check the frame number of the ICMP request.
Switch#show monitor capture test buffer
..
..
44 17.059569 10.4.16.142 b^F^R 10.4.16.141 ICMP 86 Echo (ping) request id=0x0001, seq=147/37632, ttl=128
45 17.061079 10.4.16.141 b^F^R 10.4.16.142 ICMP 74 Echo (ping) reply id=0x0001, seq=147/37632, ttl=128 (request in 44)
..
..
From the previous output its observed that ICMP packet is in frame 44. With this you can now run: show monitor capture <name> buffer detailed | begin Frame <number> to see the content:
..
..
Frame 44: 86 bytes on wire (688 bits), 86 bytes captured (688 bits) on interface 0
Interface id: 0 (/tmp/epc_ws/wif_to_ts_pipe)
Interface name: /tmp/epc_ws/wif_to_ts_pipe
Encapsulation type: Ethernet (1)
Arrival Time: Jun 3, 2022 19:12:00.140014000 UTC
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1654283520.140014000 seconds
[Time delta from previous captured frame: 0.362660000 seconds]
[Time delta from previous displayed frame: 0.362660000 seconds]
[Time since reference or first frame: 17.059569000 seconds]
Frame Number: 44
Frame Length: 86 bytes (688 bits)
Capture Length: 86 bytes (688 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:ethertype:vlan:ethertype:cmd:ethertype:ip:icmp:data]
Ethernet II, Src: 50:7b:9d:f0:34:bb (50:7b:9d:f0:34:bb), Dst: 50:7b:9d:f8:02:ed (50:7b:9d:f8:02:ed)
Destination: 50:7b:9d:f8:02:ed (50:7b:9d:f8:02:ed)
Address: 50:7b:9d:f8:02:ed (50:7b:9d:f8:02:ed)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Source: 50:7b:9d:f0:34:bb (50:7b:9d:f0:34:bb)
Address: 50:7b:9d:f0:34:bb (50:7b:9d:f0:34:bb)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Type: 802.1Q Virtual LAN (0x8100)
802.1Q Virtual LAN, PRI: 0, DEI: 0, ID: 761
000. .... .... .... = Priority: Best Effort (default) (0)
...0 .... .... .... = DEI: Ineligible
.... 0010 1111 1001 = ID: 761
Type: CiscoMetaData (0x8909)
Cisco MetaData <<<<<<<<<<<<<<<<<<<<<<< CMD header
Version: 1
Length: 1
Options: 0x0001
SGT: 3 <<<<<<<<<<<<<<<<<<<<<<<<<< SGT of PC1
Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 10.4.16.142, Dst: 10.4.16.141
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
0000 00.. = Differentiated Services Codepoint: Default (0)
.... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
Total Length: 60
Identification: 0x7d1f (32031)
Flags: 0x0000
0... .... .... .... = Reserved bit: Not set
.0.. .... .... .... = Don't fragment: Not set
..0. .... .... .... = More fragments: Not set
...0 0000 0000 0000 = Fragment offset: 0
Time to live: 128
Protocol: ICMP (1)
Header checksum: 0x887f [validation disabled]
[Header checksum status: Unverified]
Source: 10.4.16.142
Destination: 10.4.16.141
Internet Control Message Protocol
Type: 8 (Echo (ping) request)
Code: 0
Checksum: 0x4cc8 [correct]
[Checksum Status: Good]
Identifier (BE): 1 (0x0001)
Identifier (LE): 256 (0x0100)
Sequence number (BE): 147 (0x0093)
Sequence number (LE): 37632 (0x9300)
Data (32 bytes)
0000 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 abcdefghijklmnop
0010 71 72 73 74 75 76 77 61 62 63 64 65 66 67 68 69 qrstuvwabcdefghi
Data: 6162636465666768696a6b6c6d6e6f707172737475767761...
[Length: 32]
..
..
SGACL Check
The switch only downloads the SGACLs that match the IP-SGT bindings learned from different methods (local, SXP, inline tagging, and so on). C9300B learns the destination security group dynamically from ISE. How does it learn the source security group? With Inline Tagging. As the command show cts role-based sgt-map all does not show the SGTs learned from inline tagging, you can conclude that if the SGACL is downloaded, the switch is aware from both source (inline tagging) and destination (local) security groups.
Switch#show cts role-based permissions
IPv4 Role-based permissions default:
Permit_IP_Log-00
IPv4 Role-based permissions from group 3:DataCenter to group 17:MedicalDevices:
denyJonsICMP-06 <<<<
DENY_PRINTER_80_04-01
permitJons-01
IPv4 Role-based permissions from group 16:IUH_Office to group 17:MedicalDevices:
denyJonsICMP-06
RBACL Monitor All for Dynamic Policies : FALSE
RBACL Monitor All for Configured Policies : FALSE
When you ping from PC1 from PC2, the ICMP is blocked:
cisco>ping -S 10.4.16.142 10.4.16.141
Pinging 10.4.16.141 from 10.4.16.142 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 10.4.16.141:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
Related Information