⊹ Cisco Catalyst ⊹

switchport nonegotiate

interface gi0/1
 switchport nonegotiate
 no shut

Stops Trunking negotiation on the port

next post


Catalyst check TCAM utilization

show platform hardware fed switch active fwd-asic resource tcam utilization
CAM Utilization for ASIC  [0]
 Table                                              Max Values        Used Values
 --------------------------------------------------------------------------------
 Unicast MAC addresses                               32768/1024      1223/21
 L3 Multicast entries                                 8192/512          0/9
 L2 Multicast entries                                 8192/512          0/11
 Directly or indirectly connected routes             24576/8192      4934/1996
 QoS Access Control Entries                           5120            153
 Security Access Control Entries                      5120            246
 Ingress Netflow ACEs                                  256              8
 Policy Based Routing ACEs                            1024             22
 Egress Netflow ACEs                                   768              8
 Flow SPAN ACEs                                       1024             13
 Control Plane Entries                                 512            255
 Tunnels                                               512             17
 Lisp Instance Mapping Entries                        2048              3
 Input Security Associations                           256              4
 SGT_DGT                                              8192/512          0/1
 CLIENT_LE                                            4096/256         35/0
 INPUT_GROUP_LE                                       1024              0
 OUTPUT_GROUP_LE                                      1024              0
 Macsec SPD                                            256              2

shows TCAM (Ternary Content Addressable Memory) utilisation on a Cisco switch ASIC
AM is a limited hardware resource used to store things like routing entries, ACLs, QoS rules
If it fills up, the switch can’t program new entries in hardware (which can cause drops or punt-to-CPU issues).

Some Max Values have 2 values divided by /
First number = hardware maximum
Second number = software or per-region allocation
such as
Unicast MAC addresses 32768/1024 1223/21
Means:
Currently used = 1223 (hardware), 21 (allocated region)
Max hardware = 32,768 MACs
Allocated region = 1,024

MAC Addressing (Layer 2)

Unicast MAC addresses   32768/1024    1223/21
  • Very low usage → ✅ healthy
  • No concern at all

Routing (Layer 3)

Directly or indirectly connected routes   24576/8192   4936/1996
  • This is important
  • You’re using:
    • ~5K out of 24K hardware → ✅ fine
    • ~2K out of 8K allocated → ⚠️ moderate

Watch this if:

  • You add more routes (e.g. BGP, OSPF growth)
  • You hit the 8192 allocation, not just the 24576 max

ACLs (Security & QoS)

Security ACLs

Security Access Control Entries   5120   246

QoS ACLs

QoS Access Control Entries       5120   153

Both are:

  • Very low usage → ✅ no issue

NetFlow / PBR / SPAN

Ingress Netflow ACEs    256    8
Egress Netflow ACEs 768 8
Policy Based Routing 1024 22
Flow SPAN 1024 13

All low → ✅ healthy

Control Plane (IMPORTANT)

Control Plane Entries   512   255

This is the only line worth attention

  • 255 out of 512 = ~50% used
  • Not critical yet, but:
    • Control plane TCAM is small
    • Can fill faster than expected

If this fills:

  • Routing protocols
  • ARP / ICMP handling
  • CPU-bound traffic
    may be impacted

Multicast

L3 Multicast entries   8192/512   0/9
L2 Multicast entries 8192/512 0/11

Basically unused → ✅ fine

Other (IPSec, LISP, TrustSec, etc.)

All very low usage:

  • Tunnels
  • Security Associations
  • SGT / TrustSec
  • MACsec

No concerns

What Actually Matters (Summary)

✅ Healthy Areas

  • MAC table
  • Routing entries
  • ACLs (QoS & Security)
  • NetFlow / PBR
  • Multicast
  • Tunnels / security features

Nearing the software limit

So what happens if software limit is reached but not hardware limit For example for Routing (Layer 3), 8K allocated is reached Does hardware allocate more to software?

No — the hardware will NOT automatically give more TCAM to that feature.

If the software/allocated limit (e.g. 8K for L3 routes) is reached, you can hit problems even if the total hardware TCAM isn’t full

What’s really going on

Think of TCAM like a building:

  • Hardware limit (24K) = total building capacity
  • Software allocation (8K) = rooms assigned to “routing”
  • Other rooms are assigned to ACLs, QoS, etc.

If routing fills its 8K “room”:

  • It cannot spill into other rooms
  • Even if those rooms are empty

What happens when the 8K allocation is hit?

For L3 routes:

1. New routes fail to install in hardware

  • FIB (Forwarding Information Base) can’t program entries into TCAM

2. Traffic impact

Depending on platform:

  • Packets may be dropped
  • Or punted to CPU (slow path → performance issues)

3. You may see logs like:

  • FIB TCAM full
  • Hardware programming failed
  • CEF adjacency install failed

4. Control plane vs data plane mismatch

  • Route exists in routing table (RIB) ✅
  • But not in hardware (FIB) ❌

This is where things break.

Hardware DOES NOT auto-rebalance

Unlike RAM or CPU:

  • TCAM is statically partitioned
  • No dynamic borrowing between features

So what can you do?

1. Change TCAM allocation (SDM template)

On Cisco switches (e.g. Catalyst), you typically use:

  • sdm prefer routing
  • sdm prefer access
  • sdm prefer dual-ipv4-and-ipv6

This redistributes TCAM between:

  • Routing
  • ACLs
  • QoS
  • etc.

Requires reload

2. Reduce route usage

  • Summarisation
  • Filtering (e.g. in BGP)
  • Remove unnecessary routes

3. Move features off TCAM-heavy usage

  • Large ACLs
  • Excess QoS policies

4. Upgrade hardware (if scaling limit hit)

  • Some platforms just have hard ceilings

next post


Enable logging of commands by DNAC

Configuration

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 

next post


ThousandEyes Enterprise Agent

https://docs.thousandeyes.com/product-documentation/global-vantage-points/enterprise-agents/installing/cisco-devices/installation-methods/installing-enterprise-agents-on-cisco-switches-with-docker

How to install a ThousandEyes Enterprise Agent on a Cisco Catalyst 9000-series switch with Docker

The Cisco IOS XE 16.12.1 release introduced native Docker container hosted on internal flash (in case of no SSD)

Containers connects into the management interface’s network using an internal bridge and also connects to data ports using another seperate internal bridge

Downloading Docker Image

Download the Docker image from the ThousandEyes dashboard and copy it to your Cisco switch using SCP, FTP, TFTP, or USB storage.

If the switch has internet access, download the image directly onto the switch. Download the package from the ThousandEyes downloads site.

Log in to the ThousandEyes platform using a login belonging to the account group that will be associated with the appliance.

Go to Network & App Synthetics > Agent Settings and click Add New Enterprise Agent.

Download the .tar file with the ThousandEyes appliance for Catalyst 9000-series switches.

Use SCP, FTP, TFTP, or USB storage to copy the signed Docker image to the switch’s flash: directory.

copy scp://thousandeyes@10.100.21.239/thousandeyes-enterprise-agent-4.4.2.cisco.tar flash:

Run a checksum (md5) command to verify that the package transfer was successful. The md5 output should match 14b88bfc3ec75a2ff4414d8f39106a29:

catalyst#verify /md5 flash:thousandeyes-enterprise-agent-4.4.2.cisco.tar
-----------------------------------------------------------
verify /md5 (flash:thousandeyes-enterprise-agent-4.4.2.cisco.tar) = 14b88bfc3ec75a2ff4414d8f39106a29

Installing the Docker Container

Enable the IOx framework on the switch:

Enter configuration commands, one per line. End with CNTL/Z.
catalyst(config)#iox
catalyst(config)#end

Wait until all the services are running:

catalyst#show iox-service
​IOx Infrastructure Summary:
---------------------------
IOx service (CAF) 1.11.0.5     : Running
IOx service (HA)               : Running
IOx service (IOxman)           : Running
IOx service (Sec storage)      : Not Running
Libvirtd 1.3.4                 : Running
Dockerd 18.03.0                : Running
Application DB Sync Info       : Available
Sync Status                    : Disabled

Run the install command:

catalyst#app-hosting install appid <app-name> package flash:thousandeyes-enterprise-agent-4.4.2.cisco.tar

Specify your desired app name and the location of the image file you want to use. In this example, we use thousandeyes_enterprise_agent.

Downloading image directly from ThousandEyes

catalyst#app-hosting install appid <app-name> package https://downloads.thousandeyes.com/enterprise-agent/thousandeyes-enterprise-agent-4.4.2.cisco.tar

Your application should now be installed. You can check on it by running the following:

catalyst#sh app-hosting list
App id State
thousandeyes_enterprise_agent DEPLOYED

Configuring the Docker Container

Configure a single virtual network interface card (vNIC) for the appliance
Docker container supports both static IP assignment (Guest IP address) or dynamic IP address

Verify that the front panel data port is running, with Layer-2 VLAN allowed from uplink:

catalyst(config)#interface GigabitEthernet1/0/13
catalyst(config-if)#description Uplink MGMT
catalyst(config-if)#switchport access vlan 21

Verify that the Layer-2 VLAN is created:

catalyst(config)#vlan 21

Configure the AppGigabitEthernet port to allow Layer-2 VLAN:

catalyst(config)#interface AppGigabitEthernet1/0/1
catalyst(config-if)#switchport trunk allowed vlan 21,22,23,24
catalyst(config-if)#switchport mode trunk

Configure the application, either with a static IP or with DHCP IP.

Configuration with Static IP and Gateway

Use a guest IP address to assign a static IP address. In this example, assign 10.100.21.222/24, under VLAN 21 and use Google resolver:

catalyst(config)#app-hosting appid thousandeyes_enterprise_agent
catalyst(config-app-hosting)#app-vnic AppGigabitEthernet trunk
catalyst(config-config-app-hosting-trunk)#vlan 21 guest-interface 0
catalyst(config-config-app-hosting-vlan-access-ip)#guest-ipaddress 10.100.21.222 netmask 255.255.255.0
catalyst(config-config-app-hosting-vlan-access-ip)#exit
catalyst(config-config-app-hosting-trunk)#exit
catalyst(config-app-hosting)#app-default-gateway 10.100.21.1 guest-interface 0
catalyst(config-app-hosting)#name-server0 8.8.8.8
catalyst(config-app-hosting)#name-server1 8.8.4.4

Setup run options
Next, set up the required Docker run options to specify account token. If you want to specify a hostname other than the switch’s name, do this here as well:

catalyst(config-app-hosting)#app-resource docker
catalyst(config-app-hosting-docker)#prepend-pkg-opts
catalyst(config-app-hosting-docker)#run-opts 1 "-e TEAGENT_ACCOUNT_TOKEN=<Token>"
catalyst(config-app-hosting-docker)#run-opts 2 "--hostname Cisco-Docker"
catalyst(config-app-hosting-docker)#exit
catalyst(config-app-hosting)#start
catalyst(config-app-hosting)#end

Configuration with DHCP IP

Read more on https://docs.thousandeyes.com/product-documentation/global-vantage-points/enterprise-agents/installing/cisco-devices/installation-methods/installing-enterprise-agents-on-cisco-switches-with-docker

Use wr mem to ensure that your configuration changes have persisted across reboots:

catalyst#wr mem
Building configuration…
[OK]

Verifying That the Docker Container Is Running

With the (config-app-hosting)#start command, the Docker container should have been started and should be running.

Verify this by running the following:

catalyst# sh app-hosting list
App id                                   State
---------------------------------------------------------
thousandeyes_enterprise_agent            RUNNING

Verify the Docker container’s details:

catalyst#show app-hosting detail appid thousandeyes_enterprise_agent
App id                 : thousandeyes_enterprise_agent
Owner                  : iox
State                  : RUNNING
Application
   Type                 : docker
   Name                 : ThousandEyes Enterprise Agent
   Version              : 4.4.2
   Description          : 
   Author               : ThousandEyes <support@thousandeyes.com>
   Path                 : flash:thousandeyes-enterprise-agent-4.4.2.cisco.tar
   URL Path             : 
Activated profile name : custom

Resource reservation
  Memory               : 500 MB
  Disk                 : 1 MB
  CPU                  : 1850 units
  VCPU                 : 1
Attached devices
  Type              Name               Alias
---------------------------------------------
  serial/shell     iox_console_shell   serial0
  serial/aux       iox_console_aux     serial1
  serial/syslog    iox_syslog          serial2
  serial/trace     iox_trace           serial3

Network interfaces
  ---------------------------------------
eth0:
  MAC address         : 52:54:dd:d:38:3d
  Network name        : mgmt-bridge-v21
Docker
------
Run-time information
  Command              :
  Entry-point          : /sbin/my_init
  Run options in use   : -e TEAGENT_ACCOUNT_TOKEN=TOKEN_NOT_SET
--hostname=$(SYSTEM_NAME) --cap-add=NET_ADMIN --mount
type=tmpfs,destination=/var/log/agent,tmpfs-size=140m --mount
type=tmpfs,destination=/var/lib/te-agent/data,tmpfs-size=200m -v
$(APP_DATA)/data:/var/lib/te-agent -e TEAGENT_PROXY_TYPE=DIRECT -e
TEAGENT_PROXY_LOCATION= -e TEAGENT_PROXY_USER= -e
TEAGENT_PROXY_AUTH_TYPE= -e TEAGENT_PROXY_PASS= -e
TEAGENT_PROXY_BYPASS_LIST= -e TEAGENT_KDC_USER= -e TEAGENT_KDC_PASS=
-e TEAGENT_KDC_REALM= -e TEAGENT_KDC_HOST= -e TEAGENT_KDC_PORT=88 -e
TEAGENT_KERBEROS_WHITELIST= -e TEAGENT_KERBEROS_RDNS=1 -e PROXY_APT=
-e APT_PROXY_USER= -e APT_PROXY_PASS= -e APT_PROXY_LOCATION= -e
TEAGENT_AUTO_UPDATES=1 -e
TEAGENT_ACCOUNT_TOKEN=nfhjzm8e8ikg07d4n31wcsws9bakcloh --hostname
Cisco-Docker

  Package run options  : -e TEAGENT_ACCOUNT_TOKEN=TOKEN_NOT_SET
--hostname=$(SYSTEM_NAME) --cap-add=NET_ADMIN --mount
type=tmpfs,destination=/var/log/agent,tmpfs-size=140m --mount
type=tmpfs,destination=/var/lib/te-agent/data,tmpfs-size=200m -v
$(APP_DATA)/data:/var/lib/te-agent -e TEAGENT_PROXY_TYPE=DIRECT -e
TEAGENT_PROXY_LOCATION= -e TEAGENT_PROXY_USER= -e
TEAGENT_PROXY_AUTH_TYPE= -e TEAGENT_PROXY_PASS= -e
TEAGENT_PROXY_BYPASS_LIST= -e TEAGENT_KDC_USER= -e TEAGENT_KDC_PASS=
-e TEAGENT_KDC_REALM= -e TEAGENT_KDC_HOST= -e TEAGENT_KDC_PORT=88 -e
TEAGENT_KERBEROS_WHITELIST= -e TEAGENT_KERBEROS_RDNS=1 -e PROXY_APT=
-e APT_PROXY_USER= -e APT_PROXY_PASS= -e APT_PROXY_LOCATION= -e
TEAGENT_AUTO_UPDATES=1

Application health information
  Status               : 0
  Last probe error     :
  Last probe output    :

In the ThousandEyes platform, go to Network & App Synthetics > Agent Settings and verify the Docker container’s IP address:

Assigning the Agent to Tests

Now that you have installed, configured, and started your Docker-based agent, you can create tests and assign them to be run by your new agent

Modify the Docker Container

Stopping the application:

catalyst# app-hosting stop appid thousandeyes_enterprise_agent
thousandeyes_enterprise_agent stopped successfully
Current state is: STOPPED

De-activate the application:

catalyst# app-hosting deactivate appid thousandeyes_enterprise_agent
thousandeyes_enterprise_agent deactivated successfully
Current state is: DEPLOYED

Modify the Docker options, and exit three times:

catalyst(config)#app-hosting appid thousandeyes_enterprise_agent
catalyst(config-app-hosting)#app-resource docker
catalyst(config-app-hosting-docker)#prepend-pkg-opts
catalyst(config-app-hosting-docker)#<run-opts command>
catalyst(config-app-hosting-docker)#exit
catalyst(config-app-hosting)#exit
catalyst(config)#exit

Reactivate the application, and confirm that it’s activated:

catalyst# app-hosting activate appid thousandeyes_enterprise_agent
thousandeyes_enterprise_agent activated successfully
Current state is: ACTIVATED

Start the application, and confirm that it is running:

catalyst# app-hosting start appid thousandeyes_enterprise_agent
thousandeyes_enterprise_agent started successfully
Current state is: RUNNING

How do I connect to the agent shell for Cisco agents?

catalyst#app-hosting connect appid {application name} session
#

Once inside the agent shell, you can refer to the agent log for any further troubleshooting:

# tail /var/log/agent/te-agent.log

If connection or DNS resolution errors are found in the log file, your agent cannot connect to the ThousandEyes platform. Check your app-vnic configuration and make sure the agent IP can reach the internet.

next post


dot1x, mab, authenitcation, access-session commands

Command

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):

ModeBehaviour
autoAuthenticate before allowing access
force-authorizedAlways allow access
force-unauthorizedAlways block access
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
RoleDevice
SupplicantClient device
AuthenticatorSwitch
Authentication serverRADIUS / ISE

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)

more…

coming soon

next post