Switching table and switch-port configuration

CAM and TCAM Tables

The MAC address table is stored in Content Addressable Memory (CAM).

  • RAM queries a specific memory address, and then returns the data or content stored at that address location.
  • CAM operates essentially in the reverse, and does not require that a memory address be provided. Instead, CAM queries for the desired content, and then returns all matching results, including any associated content.
  • CAM is significantly faster than RAM, as it searches the entire memory content in one cycle, instead of a single address at a time. However, CAM is more expensive than RAM.

When performing a MAC address table lookup, the MAC address itself is the content being queried. For any matching results, CAM will return the destination port (the associated content).

Cisco uses the terms MAC address table and CAM table interchangeably. This guide will use the term CAM table moving forward. Idle entries in the CAM are purged after 300 seconds, by default. This timer is reset every time a frame is received with the associated MAC address on the correct port. If a host moves to a different port on a switch, the CAM table entry for the previous port will be purged immediately. This is desirable behavior – a MAC address is unique, and should never exist on more than one switch port unless a switching loop or other issue exists.

 Ternary Content Addressable Memory (TCAM) tables provide high-speed lookups for two additional functions:

  • Filtering traffic using access-lists
  • Prioritizing traffic using QoS

Multi-layer switches utilize the Forwarding Information Base (FIB) table for L3 forwarding decisions.

Ternary Content Addressable Memory (TCAM)

Recall that switches utilize TCAM tables for two purposes:

  • Filtering traffic using access-lists
  • Prioritizing traffic using QoS

Some Layer-3 devices store the routing table in TCAM as well. Most Layer-3 switches support multiple TCAM tables, to separately manage the access-lists for inbound and outbound traffic, and for QoS.

The TCAM consists of two components:

  • Feature Manager (FM) – Automatically integrates access-lists intothe TCAM.
  • Switching Database Manager (SDM) – Supports partitioning theTCAM for separate functions (supported on only some Cisco models).

Each entry in the TCAM table contains three components, defined by access-list entries:

Switch(config)# access-list WEB permit tcp 10.1.1.0 0.0.0.255 host 10.2.1.1 eq 443 Switch(config)# access-list WEB deny tcp 10.1.0.0 0.0.0.255 host 10.2.1.1 eq 80

The Feature Manager (FM) will automatically integrate the access-list named WEB into the TCAM. Configuring the TCAM consists solely of creating the necessary access-lists. However, the access-list will not take effect until it’s applied to an interface or VLAN.

SWITCHPORT CONFIGURATION

Cisco operating system – Cisco offers two brands of network switches:

CatOS IOS NX-OS
Catalyst 1200 Catalyst 29xx Nexus 1000V
Catalyst 2948 Catalyst 35xx Nexus 3000
Catalyst 4000 Catalyst 36xx Nexus 4000
Catalyst 4500 Catalyst 37xx Nexus 5000
Catalyst 5000 Catalyst 38xx Nexus 7000
Catalyst 5500 Catalyst 4500 Nexus 9000
Catalyst 6000 Catalyst 4900  
Catalyst 6500 Catalyst 6500  
  Catalyst 6800  
  • Catalyst – Cisco’s flagship switching platform,with a large selection of models spanning access, distribution, and core layers.
  • Nexus –   high-end switches focused at data center environments.

Depending on the brand and model, Cisco supports one of three switch operating systems:

  • Catalyst OS (CatOS) – interface based onset commands, that is almost entirely deprecated. CatOS will not be covered in this guide. IOS – interface that is nearly identical to the Cisco router IOS, except for switching-specific commands.
  • NX-OS – interface supported exclusively on Nexus brand switches.

The following details the supported operating system for various Cisco platforms:

Some catalyst switches support being Switch port error condition stacked – essentially, multiple physical switches connected together to form one logical switch. Configuration commands must reflect the stack, module, and interface number,in the following format: stack/module/interface.

Switch(config)# interface range gi2/3 , gi2/5 , gi2/7

            Switch(config-if-range)#

Macros can be created for groups of interfaces that are configured often:

            Switch(config)# define interface-range Mobatime gi2/10 – 15

            Switch(config)# interface range macro Mobatime

            Switch(config-if-range)#

If an interface does not have an accurate description, there are two methods of determining what is connected to it:

  • Trace the physical cable to the host (always fun).
  • Leverage the CAM table to identify a host by its MAC address.

Switch port error condition

Following events can put a port into err-disable state:

arp-inspection Error with dynamic ARP inspection, used to prevent ARP poisoning.
bpduguard BPDU is received on an interface configured for STP Portfast and BPDU guard.
channel-misconfig Error with an Etherchannel configuration
dhcp-rate-limit Error with DHCP Snooping
dtp-flat Flapping between trunk encapsulation (ISL or 802.1Q)
gbic-invalid Invalid SFP or GBIC module
ilpower Error with inline power
loopback Interface is looped (received a keep alive packet that it sent out).
l2tpguard Error with L2 tunneling
link-flap Interface is flapping between an up or down state
mac-limit Violation of MAC address limit
pagp-flap Flapping of an Etherchannel during PaGP negotiation, usually due to misconfiguration
psecure-violation Violation of port-security
rootguard BPDU from a root bridge received on a non-designated port
security-violation Violation of 802.1x security
storm-control Broadcast storm detected
udld Unidirectional link detected
unicast-flood Violation of unicast flooding limit

All err-disable conditions are enabled by default. To disable a specific err-disable condition:

Switch(config)# no errdisable detect cause link-flap

It is also possible to disable all errdisable conditions:

Switch(config)#  no errdisable detect cause all

To enable errdisable conditions again, either individually or collectively:

Switch(config)#  errdisable detect cause udld

Switch(config)# errdisable detect cause all

An interface can be manually recovered from an errdisable state by performing a shutdown and then no shutdown:

Switch(config)#  interface gi3/10

Switch(config-if)#  shut

Switch(config-if)#  no shut

However, if the error condition still exists, the interface will be placed back into an err-disable state again. Thus, an interface should not be recovered until the root cause is resolved.

Interfaces can also automatically recover from an error condition. First, the errdisable conditions that should auto-recover must be individually or collectively identified:

Switch(config)# errdisable recovery cause udld

Switch(config)# errdisable recovery cause all

By default, an interface will recover from an errdisable state in 300 seconds. This timer can be adjusted:

Switch(config)#  errdisable recovery interval 250

To view which errdisable conditions are currently enabled for recovery:

Switch# show errdisable recovery

By default, automatic err-disable recovery is disabled for all conditions. Note that all err-disable commands are applied globally, and thus apply to all interfaces on the switch.

Switch# show interface status

Switch# show interface status err-disabled

Leave a Reply

Your email address will not be published. Required fields are marked *

Bitnami