

Let’s check what happens in Wireshark when we ping to Google or 192.168.1.1. Step5: Stop Wireshark and put “ICMP” as filter in Wireshark. Instead we can do ping to ip address also. That means ICMP request packets = ICMP reply packets. Here is the snapshot for successful ping to Google. I’ll post more solutions as I encounter them.Ping Make sure you have internet connection or ping will be failedJ. Try changing the source interface to source vlan and use the VLAN you want to capture. This might be related to Problem 1, but haven’t confirmed. In some cases I found that capturing an interface would not work reliably, but capturing the VLAN would. Here is an example where I filter down traffic to 8.8.8.8. This statement indicates that the RSPAN traffic wouldn’t be cloned (thus creating an infinite loop of traffic), but I couldn’t get it to work without the filter. Each ERSPAN source session can have either ports or VLANs as sources, but not both.” Source Cisco The documentation indicates that it should work:ĮRSPAN source sessions do not copy ERSPAN GRE-encapsulated traffic from source ports. The fix was to apply an ACL filter and then traffic started showing up. I found that the ERSPAN would not work reliably if it was being transported over the same interface the capture was running on. If all looks correct there, what can we do?

If you don’t see packets in Wireshark then run show monitor session 1 to see the details of the RSPAN. You should now see Wireshark receiving the capture! By default the session is setup in a shutdown state. On the Cisco device enter the monitor session 1 type erspan-source config mode and run no shutdown. To do this enter ip proto 0x2f (GRE is protocol 47 which is 2F in HEX) and then start the capture. On the workstation start Wireshark, but don’t start the capture just yet! First create a capture filter and let’s only capture GRE packets so that we’re only seeing the ERSPAN traffic in Wireshark. Origin ip address is the interface on the Cisco device where the tunnel will be sourced. Ip address is the IP of the workstation where Wireshark is running. Source can either be an interface or VLAN from which you want to pull the capture.Įrspan-id is the ID of the GRE tunnel and can be anything between 1-64. Type erspan-source signifies that this will be an encapsulated SPAN session. The session number is simply the monitor session and can be any available session. On the device where you want to run the capture enter global config mode and enter the following:
#Wireshark filter by ip destination how to#
Here’s how it’s done: How to Setup the ERSPAN Tunnel interfaces by default use GRE and simply require a source and destination address to start encapsulation.Īny destination IP address can be used with ERSPAN, so what happens if the destination address is where Wireshark is running on a computer? Wireshark sees the live capture! The packets are encapsulated in GRE, but Wireshark displays the information of the encapsulated traffic, so it’s not a problem. It’s often paired up with IPSEC and used in VPN scenarios. GRE (generic routing encapsulation) is a common way to tunnel traffic across networks. This week I learned a trick that allows much more flexibility!ĮRSPAN is like RSPAN in that you can send mirrored traffic to other devices, but that “E” (which stands for encapsulated) makes a world of difference! ERSPAN encapsulates SPAN into GRE. Typically when I need to do a packet capture on a remote Cisco IOS/IOS-XE device, I use RSPAN to mirror that traffic someplace where a VM can receive the capture.
