cancel
Showing results forĀ 
Search instead forĀ 
Did you mean:Ā 

EXOS Using new feature "Mirroring to Remote IP Addresses"

EXOS Using new feature "Mirroring to Remote IP Addresses"

M_Nees
Contributor III
How can i use this new 22.4 EXOS feature ?

It sounds perfect to troubleshoot / debug unknown client problems from a remote switch.

I configure this on a EXOS switch in the field and grep the data directly on netsight ubuntu appliance via tcpdump. Unfortunately EXOS encapsulated this traffic into GRE Tunnel.

* Slot-1 12.125.37 # sh mirror
DefaultMirror (Enabled)
Description: Default Mirror Instance, created automatically
Mirror to remote IP: 10.2.0.34 VR : VR-Default
From IP : 10.1.12.125 Ping check: On
Status : Up
Source filter instances used : 1
Port 1:40, all vlans, ingress only

Mirrors defined: 1
Mirrors enabled: 1 (Maximum 4)
HW filter instances used: 1 (Maximum 128)
HW mirror instances used: 1 ingress, 0 egress (Maximum 4 total, 2 egress)
* Slot-1 12.125.38 #09:55:18.931614 IP (tos 0x0, ttl 62, id 0, offset 0, flags [none], proto GRE (47), length 84)
10.1.12.125 > 10.2.0.34: GREv0, Flags [none], length 64
gre-proto-0x88be
09:55:18.931642 IP (tos 0xc0, ttl 64, id 58906, offset 0, flags [none], proto ICMP (1), length 112)
10.2.0.34 > 10.1.12.125: ICMP 10.2.0.34 protocol 47 unreachable, length 92
IP (tos 0x0, ttl 62, id 0, offset 0, flags [none], proto GRE (47), length 84)
10.1.12.125 > 10.2.0.34: GREv0, Flags [none], length 64
gre-proto-0x88be
09:55:18.947159 IP (tos 0x0, ttl 62, id 0, offset 0, flags [none], proto GRE (47), length 84)
10.1.12.125 > 10.2.0.34: GREv0, Flags [none], length 64
gre-proto-0x88be
Is there a (easy) way to look into this GRE Tunnel - prefered with tcpdump ? On Netsight ?

I am looking for a fast troubleshooting way without any graphical GUI and without needing Analytics License - just for analysing packets with tcpdump (but remotely from a EXOS Switch)

Regards,
Matthias

9 REPLIES 9

M_Nees
Contributor III

Just a short like what the cisco guys do ā€¦

 

They support truncation:

Configures the MTU size for truncation.
AnySPAN packet that is larger than the configured mtu size is truncated to the configured size with a 4-byte offset.

M_Nees
Contributor III

Working more and more with that feature - very powerfull!

But what about if the packet which needs to be mirrored is at maximum mtu ?

Then the switch is not able to build GRE header around this !

Packets are silently dropped!

 

Thatā€™s very bad for an analysis tool.

 

Does it help to enable jumbo frames from mirror switch to mirror destination ?

But careless if it would work thatā€™s not practicable in the field.

 

See here an example:

Classic mirror:

6616ab3c693c4ed7a392e963e96046d9_a86fd081-e8e0-4b2d-81ac-643efac86d5e.jpg

 

ERSPAN:

big data packets are silently dropped - only ACK are seen

6616ab3c693c4ed7a392e963e96046d9_3858a309-865a-49a9-8178-112dec7fd925.jpg

 

Stephane_Grosj1
Extreme Employee
You should be able to see the GRE traffic from wireshark.

Within wireshark, if you right-click on the ERSPAN header, there is a ā€œprotocol preferencesā€ option where you can set ā€œForce to decode fake ERSPAN frameā€. This will allow the inner frame to be properly decoded in wireshark.

M_Nees
Contributor III
Hi,

i see that Wireshark natively support to decode GRE tunnel.

So i miror the captured packets directly to my pc.
BUT see the following results:

9841920d03e145ed984a28e2a39c4ccf_RackMultipart20180302-19825-1wtfcqp-1_inline.png



Wireshark recognize this as (Ciscos) ERSPAN and cannot decapsulate it.

Is there a chance that wireshark can handle this GRE packets ?

If yes this would be much more easier than configuring a GRE Tunnel on XMC or Analytics, just to have the chance to look into mirror packets.
GTM-P2G8KFN