What appears to be a Cisco Birthday cake is actually the logical Architecture of a Cisco Multi-Layer Switch, starting with Layer 3 down to Layer 2, and the underlying operations that accelerates the power and efficiency of communication of both! Lets get right into it!


The FIB Table (IP Route Table) and a look at IP CEF and the Adjacency Table


The FIB table is the Forwarding Information Base, or the IP route table, which is viewed by using the command “sh ip route” on a switch.

Here is an example configuration for R1 and R2 to communicate with each other, SW1, and a loopback interface to test the switches Layer 3 connectivity:

Adding the loopback interface

SW1(config)#int lo101
SW1(config-if)#ip add

Enabling IP Routing globally

SW1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
SW1(config)#ip routing

Adding the route to the loopback network

SW1(config)#ip route lo101



Assigning an IP Address and bringing up interface Vlan 1***

SW1(config)#int vlan 1
SW1(config-if)#ip add
SW1(config-if)#no shut
*Mar 1 01:26:36.885: %LINK-3-UPDOWN: Interface Vlan1, changed state to up
*Mar 1 01:26:36.893: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan1, changed state to up

To verify now that routing is enabled

SW1#sh ip route
(Route codes redacted)

Gateway of last resort is not set is variably subnetted, 2 subnets, 2 masks

C is directly connected, Vlan1

L is directly connected, Vlan1 is variably subnetted, 2 subnets, 2 masks

C is directly connected, Loopback101

L is directly connected, Loopback101


*** The switch will allow Layer 3 communication between R1 and R2 without the Vlan1 configuration shown above, however for the routers to get Layer 3 connectivity to the Switch itself or the loopback interfaces, the interface of the Vlan1 had to be “no shut” and configured with an IP in the same subnet as the router interfaces directly connected***

Now R1 and R2 can ping both SW1’s IP address, and now can also ping its loopback subnet of /24, so the switch can now be configured with ACL’s as well:


Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to, timeout is 2 seconds:


Success rate is 80 percent (4/5), round-trip min/avg/max = 1/2/4 ms



Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to, timeout is 2 seconds:


Success rate is 80 percent (4/5), round-trip min/avg/max = 1/1/4 ms


So now we have a Topology that looks like this:


MLS switches FIB does use IP CEF and Adjacency Tables just like a router, as can be seen here how to view them, and the output they have in this small scenario:

SW1#sh ip cef
Prefix Next Hop Interface no route drop receive attached Vlan1 receive Vlan1 attached Vlan1 attached Vlan1 receive Vlan1 receive Vlan1 drop attached Loopback101 receive Loopback101 receive Loopback101 receive Loopback101 drop receive drop receive

SW1#sh adj
Protocol Interface Address
IP Vlan1
IP Vlan1

If you have not had the pleasure of ROUTE yet, the IP Route Table is derived from IP CEF for the most concise route to a destination, and CEF uses the Adjacency Table for Layer 2 information involved in routing packets to their destination (such as VLAN info seen in the output above).


The MAC Table vs the CAM Table discussion, and the difference between them


A common misconception is that CAM is the MAC Table, which CAM itself is not a table, but it does build the MAC Table the same way IP CEF builds the IP Route table.

So technically the term CAM Table is incorrect, because it is the MAC table, however in many forums / training materials / documents posted online the term MAC Table and CAM Table are interchangeable.

CAM stands for Content-Addressable Memory, which is a special type of memory on Cisco routers and switches (different from DRAM), which is extremely high speed in how it operates as it checks the entire memory block in a single operation.

It searches on exact matches, and responds to Queries with the single operation that results in either a True (0) or False (1) response, which makes it efficient for MAC Address lookup and forwarding.

The quick response nature of this dedicated memory type within the Switch makes it responsible for handling Frame forwarding decisions, as when a packet comes into the Switch, the Switch DOES NOT query the Frame against the MAC Address Table, it passes the information to CAM to process.

When a new frame hits a switch interface that is not known in CAM, it records the MAC Address / Vlan # / Interface / Timestamp, and from this the MAC address table is derived.

If the Layer 2 information is found in CAM when it is queried, it will only update the timestamp of the entry, so if there is not an exact match CAM updates the entry with the newly received info – So if the MAC is already in CAM but the interface has changed it will completely replace the entry with the updated information from the Frame.

Now for the MAC Address Table itself, it is the formatting of the data contained in CAM, viewed with the command “sh mac address-table” which displays both Static MAC Addresses and Dynamic as seen here:

SW1#sh mac add
Mac Address Table

Vlan Mac Address Type Ports
—- ———– ——– —–
All 0100.0ccc.cccc STATIC CPU
All 0100.0ccc.cccd STATIC CPU
(….. Lots more CPU MAC Addresses)
All 0180.c200.0010 STATIC CPU
All ffff.ffff.ffff STATIC CPU
1 0017.5aa8.a606 DYNAMIC Fa1/0/4
1 001b.5336.f2cd DYNAMIC Fa1/0/11
1 001e.f797.f14b DYNAMIC Fa1/0/12
1 5897.1eab.c803 DYNAMIC Fa1/0/1
Total Mac Addresses for this criterion: 24


The tricky part of “CAM Table” terminology and usage, is that if no static MAC addresses are configured then “sh mac add dynamic” is considered the CAM Table in some discussions, however I would always assume it to mean “sh mac add” table to see all entries static and dynamic that would be present in CAM memory.

Again this is only if the CAM Table terminology is incorrectly used, as CAM has no table, the MAC Table is a format of data contain in CAM memory.


TCAM vs CAM, and what its function is on the MLS


TCAM stands for “Ternary Content-Addressable Memory” which is also a specialized type of memory that uses a similar operation as CAM for data query, using the Same 0 and 1 query responses, however it includes a very important third state of “Any” or X.

This third query state of X means it is not just exact match results, so it is optimal for longest match / prefix lookup operations such as building and querying the routing table, as well as Access-Lists and QoS operations configured for data flows.

TCAM is essentially the Layer 3 equivalent of CAM, Cisco switches use this memory to perform all Layer 3 operations as it is a high-speed dedicated module like CAM (but are not the same physical memory module), as it is also faster than DRAM in performing these operations because of the rapid query / response.

TCAM and CAM also work at the same time, handling Layer 2 and Layer 3 operations concurrently, so both of these specialized memory types in Cisco Multi-Layer switches makes.




The MLS Switch works by the IOS working in conjunction with both CAM and TCAM memory, the IOS querying CAM for near immediate Layer 2 forwarding and TCAM for Layer 3 operations like routing / ACL’s / QoS, which work simultaneously handling entire IP traffic forwarding needs.

All this wonderful resource dedication to push our packets ever faster is the reasoning why SDM (Switching Database Manager) Templates, because you can use the different template options to dedicate more resources to TCAM / Layer 3 operations if the switch is used heavier for Routing, Switching Template for heavier Layer 2 operations and so on.

I have an extensive explanation of SDM Templates and the differences in them here.


And that is about all I have to say about that


My posts will be a bit further apart, as I am both mentally and physically recovering from a recent surgery, but its good to be back at work getting the gears going again and now starting to review previous SWITCH material to get on with the advanced material!