This document provides the steps to perform an ELAM on the Catalyst 6500 Supervisor 720, explains the most relevant outputs, and how to interpret their results. This example also applies to DFC3 enabled linecards. Please refer to the following document for an overview on ELAM:
In this example, the 6500 is acting as a router on a stick to route traffic between hosts on vlan10 and vlan20. We will use ELAM to validate that an ICMP request from host 10.1.1.100 received on G5/3 VLAN 10 is successfully routed back out to 184.108.40.206 on G5/3 VLAN 20.
For Sup720, each ELAM command will begin with the following syntax: show platform capture elam ...
Determine the ingress FE
We expect the traffic to ingress the switch on port G5/3. Checking the modules in the system we can see that module 5 is the active supervisor. Therefore, we will configure the ELAM on module 5.
For the Sup720, we want to perform the ELAM on the L2 forwarding engine (FE) with internal codenameSuperman. Note that the L2 FE data bus (DBUS) contains original header information before the L2 and L3 lookup and the result bus (RBUS) contains the results after both L3 and L2 lookups.
The service internal command is required to run an ELAM on Sup720. Note that this configuration simply unlocks the hidden commands.
Configure the Trigger
The Superman ASIC supports ELAM triggers for IPv4, IPv6, and Other. The ELAM trigger must align to the frame type. If the frame is an IPv4 frame then the trigger must also be IPv4. An IPv4 frame will not be captured with an "other" trigger. The same logic applies to IPv6. The most commonly used triggers based of frame type are provided below.
IPv4IPv6All Frame Types
L3_PT (ICMP, IGMP, TCP, UDP)
Most of these fields should be self explanatory. For example, SMAC and DMAC refer to the source MAC address and the destination MAC address, IP_SA and IP_DA refer to the source IPv4 address and the destination IPv4 address, L3_PT refers to the L3 protocol (which can be ICMP, IGMP TCP or UDP).
Note that "other" requires the user to provide the exact hex data and mask for the frame in question and is outside of the scope of this document.
For this example we want to capture the frame based off source and destination IPv4 address. Remember that ELAM triggers allow us to be as specific as needed, so we could additional set fields for TTL, TOS, and L3_PT if needed. The Superman trigger for this packet is as follows:
Sup720# show platform capture elam trigger dbus ipv4 if ip_sa=10.1.1.100 ip_da=220.127.116.11
Start the Capture
Now that the ingress FE has been selected and we've configured our trigger, we can start the capture
Sup720#show platform capture elam start
We can check the status of the ELAM via the status command.
i0 - replace bytes from ofs 0 to ofs 11 with seq '00 05 73 A9 55 41 00 14 F1 79 B6 40'.
From the DBUS data above can validate the frame was received on Vlan10 with a source MAC of 0021.5525.423f and a destination MAC of 0014.f179.b640. We can also see that this is an IPv4 frame sourced from 10.1.1.100 destined to 18.104.22.168. There are several other fields not included in this output such as TOS value, IP flags, IP length, L2 frame length, etc... that are also often useful to check.
We can validate what port the frame was received on via the SRC_INDEX (the source LTL). For Sup720, we can map an LTL to a port or group of ports via the following command:
Sup720#remote command switch test mcast ltl-info index 102
index 0x102 contain ports 5/3
The above output shows that SRC_INDEX of 0x102 maps to port G5/3. This confirms that the frame was received on G5/3.
From the RBUS data we can validate that the frame was routed to Vlan 20 and the TTL was decremented from 255 in the DBUS data to 254. The REWRITE_INFO shows that the FE will replace bytes 0 through 11 (the first 12 bytes) representing the MAC rewrite for the destination and source MAC address. Finally, we can validate from the DEST_INDEX (destination LTL) where this frame was sent.
Note that the flood bit is set in RBUS so the DEST_INDEX changes from 0x14 to 0x8014.
Sup720#remote command switch test mcast ltl-info index 8014
index 0x8014 contain ports 5/3
The above output shows that DEST_INDEX of 0x8014 also maps to port G5/3. This confirms that the frame was sent out G5/3.
NOTE: Virtual Switching System
For VSS, you will need to correlate the physical port based off the virtual slot map. Consider the following example where we are trying to map out which ports will forward a frame sent to LTL 0xb42
VSS#remote command switch test mcast ltl index b42
index 0xB42 contain ports 20/1, 36/1
We can see the LTL maps to a virtual slot number of 20 and 36. We can check the virtual slot map via:
VSS#show switch virtual slot-map
Virtual Slot to Remote Switch/Physical Slot Mapping Table:
Virtual Remote Physical Module
Slot No Switch No Slot No Uptime
<some output omitted>
20 1 4 1d07h
21 1 5 1d08h
36 2 4 20:03:19
37 2 5 20:05:44
The output above shows that slot 20 maps to switch 1 module 4 and slot 36 maps to switch 2 module 4. Therefore, LTL 0xb42 maps to ports 1/4/1 and 2/4/1. Note also that if these ports were members of a port-channel then only one port will actual forward the frame based on the configured load-balancing scheme.