Showing results for 
Search instead for 
Did you mean: 
Andrew Gossett
Cisco Employee
Cisco Employee



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:


Understanding 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 received on G5/3 VLAN 10 is successfully routed back out to 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. 


Sup720#show module 5

Mod Ports Card Type                              Model              Serial No.

--- ----- -------------------------------------- ------------------ -----------

  5    5  Supervisor Engine 720 10GE (Active)    VS-S720-10G        SAL1429N5ST


For the Sup720, we want to perform the ELAM on the L2 forwarding engine (FE) with internal codename Superman.  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.  



Sup720(config)#service internal

Sup720#show platform capture elam asic superman slot 5


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

  • SMAC
  • DMAC
  • IP_SA
  • IP_DA
  • IP_TTL
  • IP_TOS
  • SMAC
  • DMAC
  • IP6_SA
  • IP6_DA
  • IP6_TTL
    • IP6_L4DATA
  • VLAN


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= ip_da=

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.

Sup720#show platform capture elam status

Active ELAM info:

Slot Cpu   Asic   Inst Ver PB Elam

---- --- -------- ---- --- -- ----

5    0   ST_SUPER 0    2.2    Y


ELAM capture in progress

Once the frame matching the trigger has been received by the FE we will see the ELAM as completed:

Sup720#show platform capture elam status

Active ELAM info:

Slot Cpu   Asic   Inst Ver PB Elam

---- --- -------- ---- --- -- ----

5    0   ST_SUPER 0    2.2    Y


ELAM capture completed


Interpret the Results


We can display the results via the data command.  Below is an excerpt of the ELAM data that is most relevant in this example.

Sup720#show platform capture elam data

(some output omitted)

DBUS data:

VLAN ............................ [12] = 10

SRC_INDEX ....................... [19] = 0x102

L3_PROTOCOL ..................... [4] = 0 [IPV4]

L3_PT ........................... [8] = 1 [ICMP]

DMAC ............................ = 0014.f179.b640

SMAC ............................ = 0021.5525.423f

IP_TTL .......................... [8] = 255

IP_SA ........................... =

IP_DA ........................... =


RBUS data:

FLOOD ........................... [1] = 1

DEST_INDEX ...................... [19] = 0x14

VLAN ............................ [12] = 20

IP_TTL .......................... [8] = 254


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 destined to  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.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Recognize Your Peers
Quick Links