Users Guide

ERPM Behavior on a typical Dell Networking OS
The Dell Networking OS is designed to support only the Encapsulation of the data received / transmitted at the specied source port (Port
A). An ERPM destination session / decapsulation of the ERPM packets at the destination Switch are not supported.
Figure 92. ERPM Behavior
As seen in the above gure, the packets received/transmitted on Port A will be encapsulated with an IP/GRE header plus a new L2 header
and sent to the destination ip address (Port D’s ip address) on the snier. The Header that gets attached to the packet is 38 bytes long.
If the snier does not support IP interface, a destination switch will be needed to receive the encapsulated ERPM packet and locally mirror
the whole packet to the Snier or a Linux Server.
Decapsulation of ERPM packets at the Destination IP/
Analyzer
In order to achieve the decapsulation of the original payload from the ERPM header. The below two methods are suggested :
a Using Network Analyzer
Install any well-known Network Packet Analyzer tool which is open source and free to download.
Start capture of ERPM packets on the Snier and save it to the trace le (for example : erpmwithheader.pcap).
The Header that gets attached to the packet is 38 bytes long. In case of a packet with L3 VLAN, it would be 42 bytes long.
The original payload /original mirrored data starts from the 39
th
byte in a given ERPM packet. The rst 38/42 bytes of the
header needs to be ignored/ chopped o.
Some tools support options to edit the capture le. We can make use of such features (for example: editcap ) and chop the
ERPM header part and save it to a new trace le. This new le (i.e. the original mirrored packet) can be converted back into
stream and fed to any egress interface.
Port Monitoring
567