idnits 2.17.1 draft-foschiano-erspan-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 2017) is 2620 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force M. Foschiano 3 Internet Draft K. Ghosh 4 Category: Informational M. Mehta 5 Expires: August 2017 Cisco Systems 6 February 2017 8 Cisco Systems' Encapsulated Remote Switch Port Analyzer (ERSPAN) 9 draft-foschiano-erspan-03.txt 11 Abstract 13 This document describes an IP-based packet capture format that can 14 be used to transport exact copies of packets to a network probe to 15 analyze and characterize the operational load and protocol 16 distribution of a network as well as to detect anomalies such as 17 network-based worms or viruses. This replication and transport 18 mechanism operates over one or multiple switch or router ports whose 19 traffic can be mirrored and forwarded to a destination device in 20 charge of traffic analysis and reporting. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six 33 months and may be updated, replaced, or obsoleted by other documents 34 at any time. It is inappropriate to use Internet-Drafts as 35 reference material or to cite them other than as "work in progress." 37 This Internet-Draft will expire in August 2017. 39 Copyright Notice 41 Copyright (c) 2017 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with 49 respect to this document. 51 Table of Contents 53 1. Introduction .................................................. 3 54 2. ERSPAN's Basic Principles of Operation ........................ 3 55 3. ERSPAN's Common Encapsulation Components ...................... 4 56 4. ERSPAN Types and Specific Sub-Headers ......................... 5 57 4.1 ERSPAN Type I ............................................. 5 58 4.2 ERSPAN Type II ............................................ 6 59 4.3 ERSPAN Type III ........................................... 9 60 5. ERSPAN Session Numbers ....................................... 15 61 6. Ethernet and IP fields ....................................... 15 62 7. Use of Other Relevant ERSPAN Fields .......................... 16 63 8. Security Considerations ...................................... 16 64 9. IANA Considerations .......................................... 17 65 10. Changes from the Previous Version ........................... 17 66 11. Acknowledgements ............................................ 17 67 12. Normative References ........................................ 17 69 1. Introduction 71 Today one of the most common network monitoring and troubleshooting 72 tools is the so-called Switch Port Analyzer (SPAN) feature, also 73 known as port mirroring. It allows a user to monitor network traffic 74 non-intrusively and send a copy of the monitored traffic to a local 75 or remote device, which can be a sniffer, an intrusion detection 76 system (IDS), or other type of network analysis tool. 78 Some of the most popular use cases of SPAN are: 80 1. Debugging network problems by tracking control/data frames 82 2. Monitoring Voice-over-IP (VoIP) packets for delay and jitter 83 analysis 85 3. Monitoring network transactions for latency analysis 87 4. Monitoring network traffic for anomaly detection 89 SPAN can operate locally and mirror traffic to other ports of the 90 same source device, or it can operate remotely mirroring traffic to 91 a different network device that is layer-2 adjacent to the source. 93 This document describes the frame formats used by the "encapsulated 94 remote" extension of the SPAN feature, which supports remote 95 monitoring of network traffic across a generic IP transport. 97 2. ERSPAN's Basic Principles of Operation 99 The ERSPAN feature enables a network device to deliver a copy of the 100 monitored traffic to a destination system through an IP network. 102 To do so, a source network device filters the portion of the traffic 103 the user is interested in, makes a copy of it and then encapsulates 104 each replicated frame into the payload of a special "container 105 super-frame". Such frame carries enough additional information for 106 it to be properly routed all the way to the receiver device and for 107 such device to be able to extract and fully restore the original 108 monitored Ethernet frame (or a selected portion of it). 110 The receiver device can be another networking device that supports 111 ERSPAN decapsulation or, when direct connectivity is available, even 112 a (non passive) network probe. 114 The frame formats used to enable such capabilities are described in 115 the following sections. 117 3. ERSPAN's Common Encapsulation Components 119 The ERSPAN packet format is GRE-based [RFC1701], and for it most 120 legacy implementations assume an underlying IPv4 [RFC791] over 121 Ethernet [802.3] transport. However, even though IPv4 is normally 122 used, IPv6 support has become a requirement too. 124 The use of the IP protocol as part of the transport is critical to 125 be able to carry the mirrored traffic across any IP-based network. 126 The GRE component instead is particularly important to be able to 127 piggyback different data formats along with the copy of the original 128 frame. 130 The ERSPAN frame format's common components are described below: 132 802.3 Ethernet MAC header (14 octets [0:13]) 133 0 1 2 3 134 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 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 | Destination MAC Address | 137 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 | | | 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 140 | Source MAC Address | 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 | Ethertype/Length | 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 IPv4 header (20 octets [14:33]) [RFC791] 146 0 1 2 3 147 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 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 |Version| IHL |Type of Service| Total Length | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | Identification |Flags| Fragment Offset | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | Time to Live | Protocol | Header Checksum | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | Source IP Address | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | Destination IP Address | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 (Above, for simplicity's sake the described frame format is IPv4's, 161 yet IPv6 can be supported too in certain implementations.) 162 GRE header for ERSPAN encapsulation (8 octets [34:41]) 163 0 1 2 3 164 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 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 |0|0|0|S|0| 000 | 00000 | 000 | Protocol Type for ERSPAN | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | Sequence Number (present only when S is set to 1) | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 Note that in the above GRE header [RFC1701] out of the C, R, K, S, 172 s, Recur, Flags, Version fields only S (bit 03) may be set to 1. The 173 other fields are always set to zero. 175 4. ERSPAN Types and Specific Sub-Headers 177 Different frame variants known as "ERSPAN Types" can be 178 distinguished based on the GRE "Protocol Type" field value: Type I 179 and II's value is 0x88BE while Type III's is 0x22EB [ETYPES]. 181 On top of the GRE header, some ERSPAN formats may include an 182 additional "feature" header described in the sections below. 184 4.1 ERSPAN Type I 186 The Type I ERSPAN frame format is based on the barebones IP+GRE 187 encapsulation (as described above) on top of the raw mirrored frame. 188 The GRE protocol type for Type I must be programmable and is 189 currently set to 0x88BE on supported devices. This format can be 190 terminated in hardware so that the original raw frame is 191 decapsulated and sent to the destination device as originally 192 received on the source device. 194 The various sections of the frame format are described below: 196 MAC header (14 octets [0:13]) 197 0 1 2 3 198 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 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | Destination MAC Address | 201 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | | | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 204 | Source MAC Address | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | Ethertype/Length | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 IPv4 header (20 octets [14:33]) 209 0 1 2 3 210 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 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 |Version| IHL |Type of Service| Total Length | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | Identification |Flags| Fragment Offset | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | Time to Live | Protocol | Header Checksum | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | Source IP Address | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | Destination IP Address | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 GRE header for ERSPAN type I encapsulation (4 octets [34:37]) 225 0 1 2 3 226 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 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 |0|0|0|0|0|00000|000000000|00000| Protocol Type for ERSPAN | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 This encapsulation adds 38 octets to the original frame length: 14 232 (MAC) + 20 (IP) + 4(GRE). The advantage of this format is its size, 233 which is more compact than Type II's and therefore can be less 234 expensive to implement. 236 4.2 ERSPAN Type II 238 Historically, ERSPAN Type II's header was the first variant to be 239 extensively used by Cisco Systems products. 241 In this case, in the GRE header (see below) out of the C, R, K, S, 242 s, Recur, Flags, Version fields the S bit is set to 1 while the 243 others are set to zero, hence a Sequence Number field is present in 244 Type II's GRE header. 246 GRE header for ERSPAN Type II encapsulation (8 octets [34:41]) 247 0 1 2 3 248 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 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 |0|0|0|1|0|00000|000000000|00000| Protocol Type for ERSPAN | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Sequence Number (increments per packet per session) | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 ERSPAN Type II's frame format also adds a special 8-octet ERSPAN 256 "feature" header on top of the MAC/IPv4/GRE headers to enclose the 257 raw mirrored frames. 259 The ERSPAN Type II feature header is described below: 261 ERSPAN Type II header (8 octets [42:49]) 262 0 1 2 3 263 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 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | Ver | VLAN | COS | En|T| Session ID | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | Reserved | Index | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 The above 8-octet header is immediately followed by the original 271 mirrored frame and then by the standard 4-octet Ethernet CRC: 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | Original Mirrored Frame | 275 | ... | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | CRC | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 Therefore, the ERSPAN Type II encapsulation adds to the original 281 frame (sans its FCS) a composite header comprising: 14 (802.3) + 20 282 (IP) + 8 (GRE) + 8 (ERSPAN) octets, in addition to a new trailing 4- 283 octet Ethernet CRC value that is calculated based on the entire 284 ERSPAN frame. 286 Note that an 802.1Q encapsulation [802.1Q] would add 4 additional 287 octets but not reduce the Ethernet MTU size of the container frame. 289 Also note that in this context (and in the context of Type I) the 290 copy of the original mirrored frame does not include the original 291 CRC octets, which are not preserved in the encapsulation process and 292 need to be recomputed in case of decapsulation by a networking 293 device. This means that on the receiving device it is not possible 294 to verify the CRC correctness of the original frame (in these cases 295 the assumption is simply that only uncorrupted frames are mirrored). 297 The various fields of the above header are described in this table: 299 Field Position Length Definition 300 [octet:bit] (bits) 302 Ver [42:0] 4 ERSPAN Encapsulation version. 303 This indicates the version of 304 the ERSPAN encapsulation 305 specification. Set to 0x1 for 306 Type II. 308 VLAN [42:4] 12 Original VLAN of the frame, 309 mirrored from the source. 310 If the En field is set to 11, 311 the value of VLAN is undefined. 313 COS [44:0] 3 Original class of service of the 314 frame, mirrored from the source. 316 En [44:3] 2 The trunk encapsulation type 317 associated with the ERSPAN source 318 port for ingress ERSPAN traffic. 320 The possible values are: 321 00-originally without VLAN tag 322 01-originally ISL encapsulated 323 10-originally 802.1Q encapsulated 324 11-VLAN tag preserved in frame. 326 T [44:5] 1 This bit indicates that the frame 327 copy encapsulated in the ERSPAN 328 packet has been truncated. This 329 occurs if the ERSPAN encapsulated 330 frame exceeds the configured MTU. 332 Session ID [44:6] 10 Identification associated with 333 (ERSPAN ID) each ERSPAN session. Must be 334 unique between the source and the 335 receiver(s). (See section below.) 337 Reserved [46:0] 12 All bits are set to zero 339 Index [47:4] 20 A 20 bit index/port number 340 associated with the ERSPAN 341 traffic's port and 342 direction (ingress/egress). N.B.: 343 This field is platform dependent. 345 4.3 ERSPAN Type III 347 Type III introduces a larger and more flexible composite header to 348 support additional fields useful for applications such as network 349 management, intrusion detection, performance and latency analysis, 350 etc. that require to know all the original parameters of the 351 mirrored frame, including those not present in the original frame 352 itself. 354 The ERSPAN Type III composite header includes a mandatory 12-octet 355 portion followed by an optional 8-octet platform-specific sub-header 356 as described below: 358 ERSPAN Type III header (12 octets) 359 0 1 2 3 360 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 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | Ver | VLAN | COS |BSO|T| Session ID | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | Timestamp | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | SGT |P| FT | Hw ID |D|Gra|O| 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 Platform Specific SubHeader (8 octets, optional) 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | Platf ID | Platform Specific Info | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | Platform Specific Info | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 The above composite header is immediately followed by the original 377 mirrored frame and then by the standard 4-octet Ethernet CRC. 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | Original Mirrored Frame | 381 | ... | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | CRC | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 See section 7 below for a discussion on how to encapsulate the 387 original packet's Ethernet CRC. 389 The various fields of the above header are described in this table: 391 Header Fields in Common with ERSPAN Type II 393 Field Length (bits) Definition 395 Ver 4 ERSPAN Encapsulation version. 396 For Type-III packets it is set to 0x2. 398 VLAN 12 VLAN of the frame monitored by an ERSPAN 399 source session: for ingress monitor this 400 will be the original source VLAN whereas 401 for egress monitor this will be the 402 destination VLAN. 404 COS 3 Class of Service of the monitored frame. 405 Ingress or egress CoS value is to be used 406 depending on the monitor type/direction. 408 T 1 This bit indicates that the frame copy 409 encapsulated in the ERSPAN packet has 410 been truncated. This occurs if the ERSPAN 411 encapsulated frame exceeds the configured 412 MTU and hence has to be truncated. 414 Session ID 10 Identification associated with each ERSPAN 415 (ERSPAN ID) session. Must be unique between the source 416 and the receiver(s). (See section below.) 418 ERSPAN Type-III Header Specific Fields 420 Field Length Definition 421 (bits) 423 BSO (Bad/Short/ 2 A 2-bit value indicating the integrity of 424 Oversized) the payload carried by ERSPAN: 425 00 --> Good frame with no error, or 426 unknown integrity 427 11 --> Payload is a Bad Frame with CRC or 428 Alignment Error 429 01 --> Payload is a Short Frame 430 10 --> Payload is an Oversized Frame 432 Timestamp 32 The timestamp value needs to be derived 433 from a hardware clock which is 434 synchronized to the system-clock. This 32- 435 bit field should support at least a 436 timestamp granularity of 100 microseconds 437 (see the Timestamp Granularity field). 439 SGT 16 Security Group Tag of the monitored frame. 441 P 1 This bit indicates that the ERSPAN payload 442 is an Ethernet protocol frame (PDU frame). 444 FT (Frame Type) 5 This field can be used to reconstruct the 445 original frame's encapsulation if it is 446 supported by the receiver. 447 This field may also be used by ERSPAN 448 engines to indicate that the mirrored 449 frame's L2 encapsulation header (or a 450 portion of it) was skipped and not 451 included in the ERSPAN packet. 452 00000 --> Ethernet frame (802.3 frame) 453 00010 --> IP Packet 454 Other values --> Reserved for future use 456 Hw (Hardware) ID 6 Unique identifier of an ERSPAN engine 457 within a system. 459 D (Direction) 1 Indicates whether the original frame was 460 SPAN'ed in ingress or in egress. 461 Ingress (0) or Egress (1). 463 Gra (Timestamp 464 Granularity) 2 Time unit to be supported for time- 465 stamping: 466 00b --> granularity = 100 microseconds 467 01b --> granularity = 100 nanoseconds 468 10b --> granularity = IEEE 1588 469 TimeRepresentation format (see definition 470 below; with nanoseconds portion stored in 471 the Timestamp field and seconds portion 472 stored in the ERSPAN platform-dependent 473 sub-header) 475 struct TimeRepresentation 476 { 477 UInteger32 seconds; 478 UInteger32 nanoseconds; 479 }; 480 11b --> user configurable time unit 481 (platform dependent, for example specific 482 to an isolated non-synchronized system 483 with very high local accuracy) 485 O (Optional 486 Sub-header) 1 The O flag indicates whether or not the 487 optional platform-specific sub-header is 488 present. If it's present, the next octet 489 indicates the platform specific format 490 used (Platf ID). The ERSPAN payload starts 491 after the O flag when O == 0b or after 8 492 octets when O == 1b. 494 Platf ID 6 Platform identifier that needs to be 495 recognized in order to parse the optional 496 platform-specific sub-header that follows. 498 Platform 499 Specific Info 58 Platform Specific Information field. It 500 is a container for data that is used by 501 a specific set of devices only. 503 Currently only the following Platform ID values are used and 504 correspond to defined Platform Specific Info field formats: 506 Platf ID Value Description 508 0x0 Reserved. In some implementations it is 509 used as an alias to 0x07. 511 0x1 Corresponds to the following format: 513 0 1 2 3 514 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 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | 0x1 | Reserved | VSM Domain ID | 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 | Port_ID/Index | 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 When the 0x1 value is used, the timestamp 522 in the base header is in 100 microseconds 523 and the Gra field is set to '00'. 524 The VSM Domain ID field is the identifier 525 of a Cisco Nexus VSM domain. 527 0x2 Reserved 528 0x3 Corresponds to the following format: 530 0 1 2 3 531 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 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 | 0x3 | Reserved | Port ID/Index | 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 | Timestamp (upper 4 octets of a UInteger64 value) | 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 The granularities supported when the 539 Platform ID is set to 0x3 are 00b 540 (100 microseconds), 01b (100 nanoseconds) 541 and 11b (nanoseconds). 542 An unsigned 64-bit timestamp value can be 543 derived from combining the base ERSPAN 544 header's 32-bit value (lower 4 octets) 545 with the Platform Specific Info's 32-bit 546 value (upper 4 octets) and can be 547 interpreted based on the granularity value 548 set in the Gra field. 550 0x4 Corresponds to the following format: 552 0 1 2 3 553 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 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 | 0x4 | Reserved | Reserved | 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 | Reserved | 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 When the 0x4 value is used, the timestamp 561 value in the base header represents a 562 UInteger32 timestamp value expressed in 563 100 microsecond units (Gra field = '00'). 565 0x5-0x6 Correspond to the following format: 567 0 1 2 3 568 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 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 |0x5 or 0x6 | Switch ID | Port ID/Index | 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 | Timestamp (seconds) | 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 When the 0x5 or the 0x6 value is used, 575 the timestamp value in the base header 576 represents the IEEE 1588 nanoseconds field 577 while the timestamp value in the Platform 578 Specific Info represents the IEEE 1588 579 seconds. The Gra field is set to '10'. 580 Switch ID is a value configurable in the 581 CLI to identify a source switch at the 582 receiving end. Port ID identifies the 583 source switch port for the SPAN'd traffic. 585 0x7 Corresponds to the following format: 587 0 1 2 3 588 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 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 |0x7 or 0x0 | Reserved | Source-Index(SI) | 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 | Timestamp(MSB) | 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 When the 0x7 value is used, an 8-octet 596 timestamp can be derived from the base 597 ERSPAN header's Timestamp field (least 598 significant four octets) combined with 599 the most significant 4 octets present in 600 corresponding field of the sub-header. 601 The "Gra" field value is 0x3(nanoseconds). 602 For ingress ERSPAN the lower 8 octets of 603 the 20-octet SI field are populated with 604 the port index while the upper 12 bits are 605 populated with an index of the group the 606 traffic's source port belongs to. 608 0x8-0x63 Reserved 610 It should be noted that the various supported header fields above 611 can be used in regular ERSPAN applications to mirror even an errored 612 frame or a bridge PDU (BPDU) frame and to preserve the original 613 trunking encapsulation and VLAN number. In addition, crucial time- 614 stamping information as well as other informational fields can be 615 added to each ERSPAN frame on the source device during the frame 616 mirroring/replication process. 618 The use of various feature header fields is discussed in the 619 following sections. 621 5. ERSPAN Session Numbers 623 An ERSPAN session is a configuration parameter that the user can 624 employ to differentiate between mirrored traffic. It is typically 625 associated to a single or to a group of physical or logical 626 entities, such as one or more ports or one or more VLANs, whose 627 traffic requires mirroring. In general, a session number identifies 628 a subset of the traffic of a source device that a user wishes to 629 replicate and analyze. Session numbers therefore represent a context 630 in which a particular stream of mirrored frames can be placed and by 631 which it can be identified. Such context is usually meaningful when 632 associated to a particular source-destination device pair. 634 As a matter of fact, within the ERSPAN IP header two key 635 identification parameters are the source IP address and the 636 destination IP address of the ERSPAN packets: the former uniquely 637 identifies the source device of the mirrored frames while the latter 638 uniquely identifies the destination device, which is to terminate 639 the flow of ERSPAN packets. 641 Different source-destination device pairs can reuse session numbers 642 as long as they represent fully disjoint ERSPAN contexts. 644 6. Ethernet and IP fields 646 Noteworthy parameters in the Ethernet and IP portion of an ERSPAN 647 frame are its Quality of Service (QoS) fields, CoS and ToS, which 648 users can program on a per session basis in such a way as to meet 649 the priority and delay requirements of their traffic analysis 650 applications. 652 For example, in certain conditions of network congestion it may be 653 desirable to configure a higher QoS priority for ERSPAN frames to 654 allow them to reach the analysis device despite congestion and so 655 allow the network administrator to troubleshoot potential bandwidth 656 utilization issues. In other cases, instead, dropping of ERSPAN 657 traffic may not constitute a problem for the network administrator 658 and therefore lowering of the ERSPAN QoS priority can be considered 659 completely acceptable. 661 In addition, the IP Identification field of ERSPAN Type II packets 662 is sometimes used to distinguish between different ERSPAN source 663 engines by writing in the field's upper 6 bits a unique fixed ERSPAN 664 Engine ID value while incrementing the remaining 10 bits for each 665 mirrored frame. This parameter provides an additional level of 666 granularity for traffic identification (and therefore feature 667 flexibility) in addition to the source device's IP address and the 668 ERSPAN session number, as described above. 670 On the other hand, for the purpose of identifying different ERSPAN 671 source engines, ERSPAN Type III uses the dedicated Hardware ID field 672 instead. 674 7. Use of Other Relevant ERSPAN Fields 676 The En(capsulation) field is used to distinguish the VLAN 677 encapsulation format of the original mirrored frame: IEEE 678 802.3/untagged (no VLAN number in the frame), IEEE 802.1Q tagging 679 format or Cisco Systems' ISL tagging format. Some implementations 680 may strip the original VLAN encapsulation during encapsulation (for 681 example due to hardware constraints) while others may preserve it in 682 the frame. Hence this field can be used to differentiate the various 683 cases. 685 The T(runcated) field is an indication of whether the original frame 686 had to be truncated to fit into the MTU used for ERSPAN transmission. 687 Note that ERSPAN may recalculate and overwrite the CRC of the 688 original Ethernet frame when adding the ERSPAN L2/IP/GRE 689 encapsulation, so even truncated frames can reach the analysis 690 device with a good CRC. However, the T field can be used to indicate 691 that the original (good or bad) CRC was preserved (i.e., not 692 truncated from the original frame). 694 8. Security Considerations 696 Source and destination IP addresses used for ERSPAN must be fully 697 routable addresses, so that for example in certain implementations 698 users could even ping such addresses to ascertain the aliveness of 699 the corresponding source or destination device. 701 Moreover, specifically in the case of a destination ERSPAN device, 702 its IP address oftentimes represents a "front end" or proxy to an 703 IP-less device such as a passive sniffer or other analysis tool. 704 This proxying capability is extremely beneficial when the end device 705 acts in stealth mode and cannot appear as an active and reachable 706 node of the network. 708 Although ERSPAN does not offer specific capabilities for security 709 such as authentication or encryption, the IP TTL of the ERSPAN 710 packets is configurable and can be used to limit the reach of ERSPAN 711 packets within an IP cloud. In addition, as any standard IP packet, 712 ERSPAN packets could be transported in regular tunnels, such as 713 IPSec or MPLS tunnels, however by design they have the IP Don't 714 Fragment bit set to avoid the need for packet reassembly. 716 9. IANA Considerations 718 This document has no actions for IANA. 720 10. Changes from the Previous Version 722 Added Kalyan as co-author. Made minor edits. 724 11. Acknowledgements 726 Various people have contributed to the definition of the ERSPAN 727 format and have provided input and reviewed this document. For both 728 contributions the authors would like to thank, in alphabetical order, 729 Ian Cox, Nicolas Delecroix, Sonia Gulrajani, Archana Kamath, 730 Nageswara Ponugoti and Ayushma Sinha, as well as Liangda Ho for 731 finding a typo. For fundamental contributions to the invention of 732 the various ERSPAN types the authors would especially like to thank 733 Tom Edsall and Suresh Gurajapu. 735 12. Normative References 737 [802.3] IEEE Std 802.3-2012, IEEE Standard for Ethernet. 739 [802.1Q] IEEE Std 802.1Q-2003, IEEE Standards for Local and 740 Metropolitan Area Networks: Virtual Bridged Local Area 741 Networks. 743 [RFC791] Postel, J. (ed.), "Internet Protocol - DARPA Internet 744 Program Protocol Specification," RFC 791, USC/Information 745 Sciences Institute, September 1981. 747 [RFC1701] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic 748 Routing Encapsulation", RFC 1701, October 1994. 750 [ETYPES] IEEE Ethertype List: 751 http://standards.ieee.org/develop/regauth/ethertype/eth.txt. 753 Authors' Addresses 755 Marco Foschiano, Cisco Systems, Inc., Via Torri Bianche 7, Vimercate, 756 MI, 20059, Italy, email address: mfoschiano@gmail.com 758 Kalyan Ghosh, Cisco Systems Inc., 3625 Cisco Way, SAN JOSE, 759 CALIFORNIA 95134, USA, email address: kghosh@cisco.com 761 Munish Mehta, Cisco Systems Inc., 3625 Cisco Way, SAN JOSE, 762 CALIFORNIA 95134, USA, email address: mmehta@cisco.com