Internet Engineering Task Force M. Foschiano
Internet Draft M. Mehta
Category: Informational Cisco Systems
Expires: August 2017 February 2017
Cisco Systems' Encapsulated Remote Switch Port Analyzer (ERSPAN)
draft-foschiano-erspan-02.txt
Abstract
This document describes an IP-based packet capture format that can
be used to transport exact copies of packets to a network probe to
analyze and characterize the operational load and protocol
distribution of a network as well as to detect anomalies such as
network-based worms or viruses. This replication and transport
mechanism operates over one or multiple switch or router ports whose
traffic can be mirrored and forwarded to a destination device in
charge of traffic analysis and reporting.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
This Internet-Draft will expire in August 2017.
Encapsulated Remote Switch Port Analyzer August 2017
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document.
Table of Contents
1. Introduction .................................................. 3
2. ERSPAN's Basic Principles of Operation ........................ 3
3. ERSPAN's Common Encapsulation Components ...................... 4
4. ERSPAN Types and Specific Sub-Headers ......................... 5
4.1 ERSPAN Type I ............................................. 5
4.2 ERSPAN Type II ............................................ 6
4.3 ERSPAN Type III ........................................... 9
5. ERSPAN Session Numbers ....................................... 15
6. Ethernet and IP fields ....................................... 15
7. Use of Other Relevant ERSPAN Fields .......................... 16
8. Security Considerations ...................................... 16
9. IANA Considerations .......................................... 17
10. Changes from the Previous Version ........................... 17
11. Acknowledgements ............................................ 17
12. Normative References ........................................ 17
Foschiano [Page 2]
Encapsulated Remote Switch Port Analyzer August 2017
1. Introduction
Today one of the most common network monitoring and troubleshooting
tools is the so-called Switch Port Analyzer (SPAN) feature, also
known as port mirroring. It allows a user to monitor network traffic
non-intrusively and send a copy of the monitored traffic to a local
or remote device, which can be a sniffer, an intrusion detection
system (IDS), or other type of network analysis tool.
Some of the most popular use cases of SPAN are:
1. Debugging network problems by tracking control/data frames
2. Monitoring Voice-over-IP (VoIP) packets for delay and jitter
analysis
3. Monitoring network transactions for latency analysis
4. Monitoring network traffic for anomaly detection
SPAN can operate locally and mirror traffic to other ports of the
same source device, or it can operate remotely mirroring traffic to
a different network device that is layer-2 adjacent to the source.
This document describes the frame formats used by the "encapsulated
remote" extension of the SPAN feature, which supports remote
monitoring of network traffic across a generic IP transport.
2. ERSPAN's Basic Principles of Operation
The ERSPAN feature enables a network device to deliver a copy of the
monitored traffic to a destination system through an IP network.
To do so, a source network device filters the portion of the traffic
the user is interested in, makes a copy of it and then encapsulates
each replicated frame into the payload of a special "container
super-frame". Such frame carries enough additional information for
it to be properly routed all the way to the receiver device and for
such device to be able to extract and fully restore the original
monitored Ethernet frame (or a selected portion of it).
The receiver device can be another networking device that supports
ERSPAN decapsulation or, when direct connectivity is available, even
a (non passive) network probe.
The frame formats used to enable such capabilities are described in
the following sections.
Foschiano [Page 3]
Encapsulated Remote Switch Port Analyzer August 2017
3. ERSPAN's Common Encapsulation Components
The ERSPAN packet format is GRE-based [RFC1701], and for it most
legacy implementations assume an underlying IPv4 [RFC791] over
Ethernet [802.3] transport. However, even though IPv4 is normally
used, IPv6 support has become a requirement too.
The use of the IP protocol as part of the transport is critical to
be able to carry the mirrored traffic across any IP-based network.
The GRE component instead is particularly important to be able to
piggyback different data formats along with the copy of the original
frame.
The ERSPAN frame format's common components are described below:
802.3 Ethernet MAC header (14 octets [0:13])
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination MAC Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethertype/Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 header (20 octets [14:33]) [RFC791]
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(Above, for simplicity's sake the described frame format is IPv4's,
yet IPv6 can be supported too in certain implementations.)
Foschiano [Page 4]
Encapsulated Remote Switch Port Analyzer August 2017
GRE header for ERSPAN encapsulation (8 octets [34:41])
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|0|S|0| 000 | 00000 | 000 | Protocol Type for ERSPAN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number (present only when S is set to 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note that in the above GRE header [RFC1701] out of the C, R, K, S,
s, Recur, Flags, Version fields only S (bit 03) may be set to 1. The
other fields are always set to zero.
4. ERSPAN Types and Specific Sub-Headers
Different frame variants known as "ERSPAN Types" can be
distinguished based on the GRE "Protocol Type" field value: Type I
and II's value is 0x88BE while Type III's is 0x22EB [ETYPES].
On top of the GRE header, some ERSPAN formats may include an
additional "feature" header described in the sections below.
4.1 ERSPAN Type I
The Type I ERSPAN frame format is based on the barebones IP+GRE
encapsulation (as described above) on top of the raw mirrored frame.
The GRE protocol type for Type I must be programmable and is
currently set to 0x88BE on supported devices. This format can be
terminated in hardware so that the original raw frame is
decapsulated and sent to the destination device as originally
received on the source device.
The various sections of the frame format are described below:
MAC header (14 octets [0:13])
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination MAC Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethertype/Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Foschiano [Page 5]
Encapsulated Remote Switch Port Analyzer August 2017
IPv4 header (20 octets [14:33])
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
GRE header for ERSPAN type I encapsulation (4 octets [34:37])
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|0|0|0|00000|000000000|00000| Protocol Type for ERSPAN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This encapsulation adds 38 octets to the original frame length: 14
(MAC) + 20 (IP) + 4(GRE). The advantage of this format is its size,
which is more compact than Type II's and therefore can be less
expensive to implement.
4.2 ERSPAN Type II
Historically, ERSPAN Type II's header was the first variant to be
extensively used by Cisco Systems products.
In this case, in the GRE header (see below) out of the C, R, K, S,
s, Recur, Flags, Version fields the S bit is set to 1 while the
others are set to zero, hence a Sequence Number field is present in
Type II's GRE header.
GRE header for ERSPAN Type II encapsulation (8 octets [34:41])
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|0|1|0|00000|000000000|00000| Protocol Type for ERSPAN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number (increments per packet per session) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Foschiano [Page 6]
Encapsulated Remote Switch Port Analyzer August 2017
ERSPAN Type II's frame format also adds a special 8-octet ERSPAN
"feature" header on top of the MAC/IPv4/GRE headers to enclose the
raw mirrored frames.
The ERSPAN Type II feature header is described below:
ERSPAN Type II header (8 octets [42:49])
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | VLAN | COS | En|T| Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The above 8-octet header is immediately followed by the original
mirrored frame and then by the standard 4-octet Ethernet CRC:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Original Mirrored Frame |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Therefore, the ERSPAN Type II encapsulation adds to the original
frame (sans its FCS) a composite header comprising: 14 (802.3) + 20
(IP) + 8 (GRE) + 8 (ERSPAN) octets, in addition to a new trailing 4-
octet Ethernet CRC value that is calculated based on the entire
ERSPAN frame.
Note that an 802.1Q encapsulation [802.1Q] would add 4 additional
octets but not reduce the Ethernet MTU size of the container frame.
Also note that in this context (and in the context of Type I) the
copy of the original mirrored frame does not include the original
CRC octets, which are not preserved in the encapsulation process and
need to be recomputed in case of decapsulation by a networking
device. This means that on the receiving device it is not possible
to verify the CRC correctness of the original frame (in these cases
the assumption is simply that only uncorrupted frames are mirrored).
Foschiano [Page 7]
Encapsulated Remote Switch Port Analyzer August 2017
The various fields of the above header are described in this table:
Field Position Length Definition
[octet:bit] (bits)
Ver [42:0] 4 ERSPAN Encapsulation version.
This indicates the version of
the ERSPAN encapsulation
specification. Set to 0x1 for
Type II.
VLAN [42:4] 12 Original VLAN of the frame,
mirrored from the source.
If the En field is set to 11,
the value of VLAN is undefined.
COS [44:0] 3 Original class of service of the
frame, mirrored from the source.
En [44:3] 2 The trunk encapsulation type
associated with the ERSPAN source
port for ingress ERSPAN traffic.
The possible values are:
00-originally without VLAN tag
01-originally ISL encapsulated
10-originally 802.1Q encapsulated
11-VLAN tag preserved in frame.
T [44:5] 1 This bit indicates that the frame
copy encapsulated in the ERSPAN
packet has been truncated. This
occurs if the ERSPAN encapsulated
frame exceeds the configured MTU.
Session ID [44:6] 10 Identification associated with
(ERSPAN ID) each ERSPAN session. Must be
unique between the source and the
receiver(s). (See section below.)
Reserved [46:0] 12 All bits are set to zero
Index [47:4] 20 A 20 bit index/port number
associated with the ERSPAN
traffic's port and
direction (ingress/egress). N.B.:
This field is platform dependent.
Foschiano [Page 8]
Encapsulated Remote Switch Port Analyzer August 2017
4.3 ERSPAN Type III
Type III introduces a larger and more flexible composite header to
support additional fields useful for applications such as network
management, intrusion detection, performance and latency analysis,
etc. that require to know all the original parameters of the
mirrored frame, including those not present in the original frame
itself.
The ERSPAN Type III composite header includes a mandatory 12-octet
portion followed by an optional 8-octet platform-specific sub-header
as described below:
ERSPAN Type III header (12 octets)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | VLAN | COS |BSO|T| Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SGT |P| FT | Hw ID |D|Gra|O|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Platform Specific SubHeader (8 octets, optional)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Platf ID | Platform Specific Info |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Platform Specific Info |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The above composite header is immediately followed by the original
mirrored frame and then by the standard 4-octet Ethernet CRC.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Original Mirrored Frame |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Foschiano [Page 9]
Encapsulated Remote Switch Port Analyzer August 2017
The various fields of the above header are described in this table:
Header Fields in Common with ERSPAN Type II
Field Length (bits) Definition
Ver 4 ERSPAN Encapsulation version.
For Type-III packets it is set to 0x2.
VLAN 12 VLAN of the frame monitored by an ERSPAN
source session: for ingress monitor this
will be the original source VLAN whereas
for egress monitor this will be the
destination VLAN.
COS 3 Class of Service of the monitored frame.
Ingress or egress CoS value is to be used
depending on the monitor type/direction.
T 1 This bit indicates that the frame copy
encapsulated in the ERSPAN packet has
been truncated. This occurs if the ERSPAN
encapsulated frame exceeds the configured
MTU and hence has to be truncated.
Session ID 10 Identification associated with each ERSPAN
(ERSPAN ID) session. Must be unique between the source
and the receiver(s). (See section below.)
ERSPAN Type-III Header Specific Fields
Field Length Definition
(bits)
BSO (Bad/Short/ 2 A 2-bit value indicating the integrity of
Oversized) the payload carried by ERSPAN:
00 --> Good frame with no error, or
unknown integrity
11 --> Payload is a Bad Frame with CRC or
Alignment Error
01 --> Payload is a Short Frame
10 --> Payload is an Oversized Frame
Timestamp 32 The timestamp value needs to be derived
from a hardware clock which is
synchronized to the system-clock. This 32-
bit field should support at least a
Foschiano [Page 10]
Encapsulated Remote Switch Port Analyzer August 2017
timestamp granularity of 100 microseconds
(see the Timestamp Granularity field).
SGT 16 Security Group Tag of the monitored frame.
P 1 This bit indicates that the ERSPAN payload
is an Ethernet protocol frame (PDU frame).
FT (Frame Type) 5 This field can be used to reconstruct the
original frame's encapsulation if it is
supported by the receiver.
This field may also be used by ERSPAN
engines to indicate that the mirrored
frame's L2 encapsulation header (or a
portion of it) was skipped and not
included in the ERSPAN packet.
00000 --> Ethernet frame (802.3 frame)
00010 --> IP Packet
Other values --> Reserved for future use
Hw (Hardware) ID 6 Unique identifier of an ERSPAN engine
within a system.
D (Direction) 1 Indicates whether the original frame was
SPAN'ed in ingress or in egress.
Ingress (0) or Egress (1).
Gra (Timestamp
Granularity) 2 Time unit to be supported for time-
stamping:
00b --> granularity = 100 microseconds
01b --> granularity = 100 nanoseconds
10b --> granularity = IEEE 1588
TimeRepresentation format (see definition
below; with nanoseconds portion stored in
the Timestamp field and seconds portion
stored in the ERSPAN platform-dependent
sub-header)
struct TimeRepresentation
{
UInteger32 seconds;
UInteger32 nanoseconds;
};
11b --> user configurable time unit
(platform dependent, for example specific
to an isolated non-synchronized system
with very high local accuracy)
Foschiano [Page 11]
Encapsulated Remote Switch Port Analyzer August 2017
O (Optional
Sub-header) 1 The O flag indicates whether or not the
optional platform-specific sub-header is
present. If it's present, the next octet
indicates the platform specific format
used (Platf ID). The ERSPAN payload starts
after the O flag when O == 0b or after 8
octets when O == 1b.
Platf ID 6 Platform identifier that needs to be
recognized in order to parse the optional
platform-specific sub-header that follows.
Platform
Specific Info 58 Platform Specific Information field. It
is a container for data that is used by
a specific set of devices only.
Currently only the following Platform ID values are used and
correspond to defined Platform Specific Info field formats:
Platf ID Value Description
0x0 Reserved. In some implementations it is
used as an alias to 0x07.
0x1 Corresponds to the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x1 | Reserved | VSM Domain ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port_ID/Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
When the 0x1 value is used, the timestamp
in the base header is in 100 microseconds
and the Gra field is set to '00'.
The VSM Domain ID field is the identifier
of a Cisco Nexus VSM domain.
0x2 Reserved
Foschiano [Page 12]
Encapsulated Remote Switch Port Analyzer August 2017
0x3 Corresponds to the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x3 | Reserved | Port ID/Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp (upper 4 octets of a UInteger64 value) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The granularities supported when the
Platform ID is set to 0x3 are 00b
(100 microseconds), 01b (100 nanoseconds)
and 11b (nanoseconds).
An unsigned 64-bit timestamp value can be
derived from combining the base ERSPAN
header's 32-bit value (lower 4 octets)
with the Platform Specific Info's 32-bit
value (upper 4 octets) and can be
interpreted based on the granularity value
set in the Gra field.
0x4 Corresponds to the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x4 | Reserved | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
When the 0x4 value is used, the timestamp
value in the base header represents a
UInteger32 timestamp value expressed in
100 microsecond units (Gra field = '00').
0x5-0x6 Correspond to the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0x5 or 0x6 | Switch ID | Port ID/Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp (seconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Foschiano [Page 13]
Encapsulated Remote Switch Port Analyzer August 2017
When the 0x5 or the 0x6 value is used,
the timestamp value in the base header
represents the IEEE 1588 nanoseconds field
while the timestamp value in the Platform
Specific Info represents the IEEE 1588
seconds. The Gra field is set to '10'.
Switch ID is a value configurable in the
CLI to identify a source switch at the
receiving end. Port ID identifies the
source switch port for the SPAN'd traffic.
0x7 Corresponds to the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0x7 or 0x0 | Reserved | Source-Index(SI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp(MSB) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
When the 0x7 value is used, an 8-octet
timestamp can be derived from the base
ERSPAN header's Timestamp field (least
significant four octets) combined with
the most significant 4 octets present in
corresponding field of the sub-header.
The "Gra" field value is 0x3(nanoseconds).
For ingress ERSPAN the lower 8 octets of
the 20-octet SI field are populated with
the port index while the upper 12 bits are
populated with an index of the group the
traffic's source port belongs to.
0x8-0x63 Reserved
It should be noted that the various supported header fields above
can be used in regular ERSPAN applications to mirror even an errored
frame or a bridge PDU (BPDU) frame and to preserve the original
trunking encapsulation and VLAN number. In addition, crucial time-
stamping information as well as other informational fields can be
added to each ERSPAN frame on the source device during the frame
mirroring/replication process.
The use of various feature header fields is discussed in the
following sections.
Foschiano [Page 14]
Encapsulated Remote Switch Port Analyzer August 2017
5. ERSPAN Session Numbers
An ERSPAN session is a configuration parameter that the user can
employ to differentiate between mirrored traffic. It is typically
associated to a single or to a group of physical or logical
entities, such as one or more ports or one or more VLANs, whose
traffic requires mirroring. In general, a session number identifies
a subset of the traffic of a source device that a user wishes to
replicate and analyze. Session numbers therefore represent a context
in which a particular stream of mirrored frames can be placed and by
which it can be identified. Such context is usually meaningful when
associated to a particular source-destination device pair.
As a matter of fact, within the ERSPAN IP header two key
identification parameters are the source IP address and the
destination IP address of the ERSPAN packets: the former uniquely
identifies the source device of the mirrored frames while the latter
uniquely identifies the destination device, which is to terminate
the flow of ERSPAN packets.
Different source-destination device pairs can reuse session numbers
as long as they represent fully disjoint ERSPAN contexts.
6. Ethernet and IP fields
Noteworthy parameters in the Ethernet and IP portion of an ERSPAN
frame are its Quality of Service (QoS) fields, CoS and ToS, which
users can program on a per session basis in such a way as to meet
the priority and delay requirements of their traffic analysis
applications.
For example, in certain conditions of network congestion it may be
desirable to configure a higher QoS priority for ERSPAN frames to
allow them to reach the analysis device despite congestion and so
allow the network administrator to troubleshoot potential bandwidth
utilization issues. In other cases, instead, dropping of ERSPAN
traffic may not constitute a problem for the network administrator
and therefore lowering of the ERSPAN QoS priority can be considered
completely acceptable.
In addition, the IP Identification field of ERSPAN Type II packets
is sometimes used to distinguish between different ERSPAN source
engines by writing in the field's upper 6 bits a unique fixed ERSPAN
Engine ID value while incrementing the remaining 10 bits for each
mirrored frame. This parameter provides an additional level of
granularity for traffic identification (and therefore feature
flexibility) in addition to the source device's IP address and the
ERSPAN session number, as described above.
Foschiano [Page 15]
Encapsulated Remote Switch Port Analyzer August 2017
On the other hand, for the purpose of identifying different ERSPAN
source engines, ERSPAN Type III uses the dedicated Hardware ID field
instead.
7. Use of Other Relevant ERSPAN Fields
The En(capsulation) field is used to distinguish the VLAN
encapsulation format of the original mirrored frame: IEEE
802.3/untagged (no VLAN number in the frame), IEEE 802.1Q tagging
format or Cisco Systems' ISL tagging format. Some implementations
may strip the original VLAN encapsulation during encapsulation (for
example due to hardware constraints) while others may preserve it in
the frame. Hence this field can be used to differentiate the various
cases.
The T(runcated) field is an indication of whether the original frame
had to be truncated to fit into the MTU used for ERSPAN transmission.
Note that ERSPAN may recalculate and overwrite the CRC of the
original Ethernet frame when adding the ERSPAN L2/IP/GRE
encapsulation, so even truncated frames can reach the analysis
device with a good CRC. However, the T field can be used to indicate
that the original (good or bad) CRC was preserved (i.e., not
truncated from the original frame).
8. Security Considerations
Source and destination IP addresses used for ERSPAN must be fully
routable addresses, so that for example in certain implementations
users could even ping such addresses to ascertain the aliveness of
the corresponding source or destination device.
Moreover, specifically in the case of a destination ERSPAN device,
its IP address oftentimes represents a "front end" or proxy to an
IP-less device such as a passive sniffer or other analysis tool.
This proxying capability is extremely beneficial when the end device
acts in stealth mode and cannot appear as an active and reachable
node of the network.
Although ERSPAN does not offer specific capabilities for security
such as authentication or encryption, the IP TTL of the ERSPAN
packets is configurable and can be used to limit the reach of ERSPAN
packets within an IP cloud. In addition, as any standard IP packet,
ERSPAN packets could be transported in regular tunnels, such as
IPSec or MPLS tunnels, however by design they have the IP Don't
Fragment bit set to avoid the need for packet reassembly.
Foschiano [Page 16]
Encapsulated Remote Switch Port Analyzer August 2017
9. IANA Considerations
This document has no actions for IANA.
10. Changes from the Previous Version
Added a new section about Type I and made various minor edits.
11. Acknowledgements
Various people have contributed to the definition of the ERSPAN
format and have provided input and reviewed this document. For both
contributions the author would like to thank, in alphabetical order,
Ian Cox, Nicolas Delecroix, Kalyan Ghosh, Sonia Gulrajani, Archana
Kamath, Nageswara Ponugoti and Ayushma Sinha, as well as Liangda Ho
for finding a typo. For fundamental contributions to the invention
of the various ERSPAN types the author would also like to thank Tom
Edsall and Suresh Gurajapu.
12. Normative References
[802.3] IEEE Std 802.3-2012, IEEE Standard for Ethernet.
[802.1Q] IEEE Std 802.1Q-2003, IEEE Standards for Local and
Metropolitan Area Networks: Virtual Bridged Local Area
Networks.
[RFC791] Postel, J. (ed.), "Internet Protocol - DARPA Internet
Program Protocol Specification," RFC 791, USC/Information
Sciences Institute, September 1981.
[RFC1701] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic
Routing Encapsulation", RFC 1701, October 1994.
[ETYPES] IEEE Ethertype List:
http://standards.ieee.org/develop/regauth/ethertype/eth.txt.
Authors' Addresses
Marco Foschiano, Cisco Systems, Inc., Via Torri Bianche 7, Vimercate,
MI, 20059, Italy, email address: mfoschiano@gmail.com
Munish Mehta, Cisco Systems Inc., 3625 Cisco Way, SAN JOSE,
CALIFORNIA 95134, USA, email address: mmehta@cisco.com
Foschiano [Page 17]