Differences

This shows you the differences between two versions of the page.

--- hardware:erspan [2018/05/01 15:51] – [Configuring] veera
+++ hardware:erspan [2018/05/01 21:38] (current) – [On MTU and packet sizes] veera
@@ Line 2: / Line 2: @@
-ERSPAN (( ERSPAN Cisco IOS XE 3S Configuration Guide : [[https://www.cisco.com/c/en/us/td/docs/switches/datacenter/sw/5_x/nx-os/system_management/configuration/guide/sm_nx_os_cg/sm_erspan.html|Configure ERSPAN]] )) stands for Encapsulated Remote Switch Port ANalayzer or just Encapsulated RSPAN. This is feature available on some of the higher end Cisco Switches such as Catalyst 6500 and 7500s, Nexus, and ASR platforms.
+ERSPAN (( ERSPAN Cisco IOS XE 3S Configuration Guide : [[https://www.cisco.com/c/en/us/td/docs/switches/datacenter/sw/5_x/nx-os/system_management/configuration/guide/sm_nx_os_cg/sm_erspan.html|Configure ERSPAN]] )) stands for Encapsulated Remote Switch Port ANalayzer or just Encapsulated RSPAN. This is feature available on some of the higher end platforms like Catalyst 6500 and 7500s, Nexus, and ASR platforms. Let us see how this feature can be useful in some scenarios.
 ===== What is ERSPAN =====
-ERSPAN allows you to capture network packets from one or more physical ports, then transmit these packets across your network inside a Layer-3 IP tunnel using GRE (Generic Routing Encapsulation).  Since you are transmitting it over a Layer-3 tunnel you need to send it to a particular routable IP address.
+ERSPAN allows you to capture network packets from one or more physical ports, then transmit these packets to a **particular IP address** where your monitoring software is waiting. The captured packet stream is sent inside a Layer-3 IP tunnel using GRE (Generic Routing Encapsulation).
-The following diagram shows a ERSPAN session that captures packets from interface ''GigabitEthernet1/0/1'' and transmits it to the IP address ''10.0.0.21''
+The following diagram shows a ERSPAN session that captures packets from interface ''GigabitEthernet1/0/1'' and transmits it to the IP address ''10.0.0.21'' where TrisulNSM is listening.
@@ Line 16: / Line 16: @@
 There are three port mirroring features in Cisco :
-  - Physical SPAN -- this is the normal port mirror we see used. It is supported on nearly all models of Cisco and allows you to physically mirror one or more ports to a //monitor port//.
+  - Physical SPAN -- this is the common port SPAN. It is supported on nearly all models of Cisco and allows you to physically mirror one or more ports to a //monitor port//.
-  - RSPAN -- Remote SPAN, this is a Layer-2 port mirror where you can capture remote packets over a Layer2 VLAN and bring it across your network to a NSM tool
+  - RSPAN -- Remote SPAN, this is a Layer-2 port mirror where you can capture remote packets over a Layer2 VLAN and bring it across your L2 network
-  - ERSPAN -- Layer3 Remote SPAN, this is what we are talking about.  Allows you to transport a port mirror session over a IP network.
+  - ERSPAN -- Layer3 Remote SPAN, this is what we are talking about in this article.  Allows you to transport a port mirror session over an IP network.
-==== Use case 1 : Virtual Machine ====
+==== ERSPAN Use case 1 : Virtual Machine ====
-One of the use cases of ERSPAN we are seeing is. To provide network packets to  Trisul Network Analytics running inside a Virtual Machine. Particularly when the administrators of the VM are unable to provide a promiscuous mode physical interface.
+To provide network packets to  Trisul Network Analytics or other NSM tool running inside a Virtual Machine. Particularly when the administrators of the VM are unable to provide a promiscuous mode physical interface.
-==== Use case 2 : Temporary monitoring ====
+Recently, we had a customer who was consolidating all their server systems on a Nutanix VM farm. They wanted to put TrisulNSM also on a VM on that farm instead of a physical box. Since the Nutanix does not yet support a physical port mirror at the VM level (( Nutanix [[https://next.nutanix.com/installation-configuration-23/single-vm-in-promiscuous-mode-on-ahv-27096 ]] forum post mentioning  they do not yet support a physical port mirror at the VM Level)) , we use a ERSPAN session to get the packets directly to the TrisulVM.
-Some of the other scenarios we are seeing ERSPAN to be of great use is - when you want to temporarily monitor an interface without having to do any extra cabling that would be required for a physical layer SPAN.
+==== ERSPAN Use case 2 : Temporary monitoring ====
+If you are already doing ERSPAN, then adding an extra port is trivial.  When you want to temporarily monitor an interface without having to do any extra cabling that would be required for a physical layer SPAN. The main disadvantage is ERSPAN is only available on high-end Cisco gear.
@@ Line 34: / Line 36: @@
 ===== Configuring =====
-In ERSPAN, there is a concept of Source and Destination session.  A source session specifies interfaces from which traffic is captured and a destination IP address. A destination session specifies the output port to which the decapsulated traffic is written out.
+In ERSPAN, there is a concept of Source and Destination session. A //source session// specifies interfaces from which traffic is captured  and sent to an analyzers IP address. A //destination session// specifies the output port to which the decapsulated traffic is written out.  You dont have to configure a destination session.
-What we do here is to only configure a //source ERSPAN session// the IP address used will be the IP address of the TrisulNSM Virtual Machine.  When  you do this, the network will just forward the GRE Encapsulated mirror traffic to the TrisulNSM VM.  Since Trisul already supports ERSPAN as a capture mechanism , you can use that to decode the traffic. Here is a sample config from the Cisco manual (( Cisco Guide :  [[https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/lanswitch/configuration/xe-3s/lanswitch-xe-3s-book/lnsw-conf-erspan.html#GUID-A135491D-5FC8-4DF8-BA68-0B825C41B01F|Configuring ERSPAN]]  ))
+Here we only configure a //source ERSPAN session// to the IP address ''10.0.0.21'' of the TrisulNSM Virtual Machine.  When  you do this, the network will just forward the GRE Encapsulated mirror traffic to the TrisulNSM VM.  Since Trisul already supports ERSPAN as a capture mechanism, you can use that to decode the traffic. Here is a sample config from the Cisco manual (( Cisco Guide :  [[https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/lanswitch/configuration/xe-3s/lanswitch-xe-3s-book/lnsw-conf-erspan.html#GUID-A135491D-5FC8-4DF8-BA68-0B825C41B01F|Configuring ERSPAN]]  ))
 <code cisco>
@@ Line 49: / Line 51: @@
 no shutdown
 </code>
+==== On MTU and packet sizes ====
-<note important>
+<note important>Make sure you increase the MTU of the ERSPAN session and the IP path to accommodate the extra 42 bytes of tunnel header </note>
-Note about MTU
-  - **mtu 1900**  -- ERSPAN adds about 48 bytes of extra header bytes by way of Ethernet/IP/GRE header. The default ERSPAN MTU is 1500 bytes, so when you mirror full length packets they can be truncated. Make sure you increase the MTU of the ERSPAN to 1700 or 1900 or even the maximum size of 9000 bytes.
+  - **mtu 1900**  -- ERSPAN adds about 42 bytes of extra header bytes by way of Ethernet/IP/GRE header. The default ERSPAN MTU is 1500 bytes, so when you mirror full length packets they can be truncated. Make sure you increase the MTU of the ERSPAN to 1700 or 1900 or even the maximum size of 9000 bytes.
   - You also need to set the MTU on any bridges you create on the VM infrastructure.
-</note>
+  - If you dont set the MTU to a higher numbers, then packets will be truncated as per the ERSPAN documentation. Some implementations may fragment the IP packets, which will they place a load on the NSM tool to reassemble the packets.
 to view the monitor
@@ Line 68: / Line 72: @@
 ===== Enabling ERSPAN in TrisulNSM =====
-Trisul Network Analytics supports ERSPAN natively.
+Trisul Network Analytics supports ERSPAN natively since version 6.5.2883