EXOS Using new feature "Mirroring to Remote IP Addresses"

[M_Nees]

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

[M_Nees]

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]

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:

ERSPAN:

big data packets are silently dropped - only ACK are seen

[Stephane_Grosj1]

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]

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:

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.