MLS_Architecture

I’ve decided to scrap my original post on Multi-Layer switches to break it up into several posts covering Fundamentals / Components / Packet Switching methods discussed in this post, and some labbing of Layer 3 Routing configuration in following posts.

Multi-Layer Switching Fundamentals and Packet Switching methods

Multi-Layer Switches allow for “inter-vlan” communication, by allowing Layer 3 logical and physical interfaces to be configured as IP gateways for their respective subnet, allowing the IP Routing to occur directly on the MLS Switch.

The logical interfaces are SVI (Switched Virtual Interface), which are used for inter-vlan communication, and a Layer 2 switchport can be configured to be a Layer 3 routed port for communication to routing devices throughout the network such as Routers / Firewalls.

Layer 3 routing is turned off by default on a Cisco switch, so a Multi-Layer Switch will not perform any sort of routing until it is configured globally with the “ip routing” command in global configuration:

SW1(config)#ip routing ?
protocol IP routing protocol
<cr>

It can also be turned off the same way using “no ip routing” in global config mode, however it is turned off by default, so if you are not seeing routing related information populating such as the IP Route table then IP Routing probably needs to be turned on.

SVI and Layer 3 port configuration will be covered / labbed in depth in my next posts.

 

Packet Switching method #1 – Route Caching / Flow-Based / Route once, Switch many

 

This method uses a Route Processor, Switch Engine, and ASICs (Application Specific Integrated Circuits) to perform switching of traffic flows based on the first received packet in the traffic flow in the following order per traffic flow:

  1. The first packet in a traffic flow is processed by the Route Processor, which is a combination of hardware and software, to decide how to handle the flow
  2. The Switch Engine detects the incoming traffic flow, detects the Route Processors decision, then caches this incoming / destination information for handling all following packets in the traffic flow
  3. The Switch Engine re-writes or “programs” the ASICs involved with the traffic forwarding decision made by the Route Processor for the traffic flow
  4. The ASICs will now take over the handling of the traffic flow, and perform Layer 2 overwriting of MAC Address information as the traffic flow traverses the network

The Route Processor basically tells the switch how the traffic flow will be routed, the Switch Engine tells the ASICs how to handle the traffic flow, and the ASICs handle a majority of the workload from there!

I keep referring to the “Traffic Flow” because it is a large part as to why this MLS method gets hefty, because the traffic flow is a unidirectional combination of source / destination IP / MAC / Protocol (Port #), which means every between the same two hosts using different protocols like SMTP / HTTP / HTTPS / FTP will all be different traffic flows.

This in turn means that the Route Processor is hitting the CPU for resources for EACH of these flows! This gives it the name “Route once, switch many” method, and also makes it the less preferred of the two methods discussed here for CCNP SWITCH studies, as there is an alternative Hardware Switching method that is faster and uses less CPU.

The Route Processor is also called the Layer 3 or L3 Engine within an MLS context, and the method of “Route Caching” is considered a legacy or first generation MLS switching method, as the next method is considered the new standard for MLS switching methods.

 

Packet Switching method # 2 – CEF / Topology-Based / Hardware Switching

 

CEF (Cisco Express Forwarding) packet switching method is a hardware driven packet switching, which uses specialized hardware to perform the packet switching operations, which stores Layer 2 and Layer 3 tables in a database on the hardware for rapid lookup.

I have two posts from my CCNP ROUTE notes on CEF, one explains it in great detail here, and another post which is more like a quick reference guide for exam day here.

The first link is a very in depth lab demonstrating some CEF behaviors which I won’t go into here, so for a more in depth look at CEF on the CLI, check those links out!

CEF is comprised of the FIB (Forwarding Information Base), which is what the IP Route Table derives its routing information from, as well as the AT (Adjacency Table) which gathers Layer 2 information via ARP to discover and maintain a database of all next-hop hosts / devices MAC Address information.

CEF is running by default on a Cisco Catalyst switch, however for it to begin population routing information, you must configure “ip routing” in global configuration mode to turn Layer 3 routing on for the switch!

Here is a gotcha found on the lab reviewing output with and without routing enabled:

Before turning on “ip routing”

SW1(config)#do sh ip cef
Prefix Next Hop Interface
0.0.0.0/0 receive
0.0.0.0/8 drop
0.0.0.0/32 receive
127.0.0.0/8 drop
224.0.0.0/4 drop
224.0.0.0/24 receive
240.0.0.0/4 drop
255.255.255.255/32 receive

Note highlighted in red that the default route shows ‘receive’, because it is not yet performing Layer 3 routing, so it has no default route with a destination configurable!

After turning on “ip routing”

SW1(config)#ip routing
SW1(config)#do sh ip cef
Prefix Next Hop Interface
0.0.0.0/0 no route
0.0.0.0/8 drop
0.0.0.0/32 receive
127.0.0.0/8 drop
224.0.0.0/4 drop
224.0.0.0/24 receive
240.0.0.0/4 drop
255.255.255.255/32 receive

So for exam day and on the job, seeing “receive” in the default route portion will indicate that only Layer 2 is running on the switch, whereas Layer 3 will indicate a route or show “no route” if no default route is set.

For the Adjacency Table, to view this information the following command is used:

SW1(config)#do sh adj
Protocol Interface Address
SW1(config)#

This indicates this switch has not detected any hosts, however here is some input from the above mentioned link, from a ROUTE lab I was working with at that time:

R1(config)#do sh adj
Protocol Interface Address
IP Serial0/0 172.12.123.3(7)
IP Serial0/0 172.12.123.2(5) (incomplete)

The incomplete shown there from my ROUTE post indicates an issue between Layer 2 and Layer 3, resulting in the “incomplete” showing up next to the entry, again I highly recommend checking out the first link posted above for a full throated explanation of CEF / FIB / AT.

So FIB = Layer 3 routing information AKA IP Route table, AT = Layer 2 information that corresponds with the Layer 3 FIB information, CEF = The combination of both FIB and AT to derive the most accurate routes possible to be used in Packet Switching.

Being that there is already a very in depth article I wrote in my ROUTE studies on the topic I will leave it at this for the explanation, for further reading again the link is here!

 

A necessary review of the CAM vs MAC Table before reviewing TCAM

 

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
SW1#

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 table, and its function on a Multi-Layer Switch

 

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.

 

How and why SDM Templates come into the Multi-Layer Switch equation

 

The Multi-Layer 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.

 

That is all I have for the fundamentals and considerations of Multi-Layer Switching!

 

Next up will be some labbing of SVI’s and Layer 3 Switchport configuration, now that all that dreaded theory is out of the way, if you made it through that wall of explanation you are well on your way to becoming a fellow Cisco Geek! 🙂