This is a static archive of our old Q&A Site. Please post any new questions and answers at

Capture an IP inside a GRE packet


I'm having a problem with a capture filter. When I capture a host IP (host a.b.c.d) on a vlan with NO GRE tunnel the capture works perfect (I've done it hundres of times). When I move the capture vlan (change the VLAN that it is connected to on the Cisco switch - no physicl cable move just change the monitor port from vlan 500 to vlan 700) the capture stops capturing on a GRE tunnel VLAN. I've downloaded the latest version (3/22/12) with the same results. I know this has worked in the past 6 to 9 months ago. The only way I can get it to capture is to capture everything and then display filter for what I want. The display filture can then display down into the gre part of the package where it appears that the capture filture will not. I really need to only capture 1 IP to keep the size down low.


asked 23 Mar '12, 17:06

bonzadams's gravatar image

accept rate: 0%

One Answer:


Assuming your host a.b.c.d is, then to capture all traffic to/from that GRE-encapsulated IP address, try* a capture filter of "(ip[40:4]==0xC0A80164) or (ip[44:4]==0xC0A80164)".

If you want a capture filter that works* whether the IP address is GRE-encapsulated or not, then use "host or ((ip[40:4]==0xC0A80164) or (ip[44:4]==0xC0A80164))"

*NOTE: The filter, as is, only works as long as the IP header is 20 bytes in length and the GRE header is 8 bytes in length. If your IP or GRE headers differ in length, then the offsets of 40 and 44 will need to be adjusted accordingly.

Refer to FAQ727 at Bluecoat Knowledge for more details, and don't forget about the pcap-filter man page.

answered 23 Mar '12, 19:16

cmaynard's gravatar image

cmaynard ♦♦
accept rate: 20%

edited 23 Mar '12, 20:14

I might agree except that it works fine on one vlan and not on another (with the same capture filter). The difference is the gre tunnel packet header. When I change vlans the capture stops. With no capture filter the GRE vlan packets have the tunnel scr and dst IP's in the first IP header and the gre part of the header has the IP that I'm trying to capture.

IP source ip (a1.b1.c1.d1) destination ip (a2.b2.c2.d2) GRE IP source ip (w1.x1.y1.z1) destination ip (w2.x2.y2.z2) DATA

My capture filter is: host w2.x2.y2.z2. The display filter looks the same and works. This worked before


(23 Mar '12, 20:31) bonzadams

My apologies. I realized that my initial answer wasn't the solution you needed and edited it so that hopefully the one I've provided now will help you.

(23 Mar '12, 20:37) cmaynard ♦♦

If I'm not explaining this good enough I'll try another approach. My last post didn't look like I wanted it to. I'm sending multicast through a tunnel and through 2 different switches. The vlan between the switches has no tunnel and it captures fine. The vlan with the tunnel goes to my edge router and does not capture. I was trying to follow the packet from source to edge router to defend the network.



(23 Mar '12, 20:47) bonzadams

I'll try the "host a.b.c.d or (vlan and host a.b.c.d)" capture Monday but I don't think that is it because 1 vlan on the switch works fine but the 2nd vlan on the same switch with tunneling does not.

(23 Mar '12, 20:57) bonzadams

I don't think it will work either. The filter you intend to try seems to be based on the information I provided in my initial answer, which I don't think will help you for the very reasons you give. My updated answer should have you try an entirely different capture filter, one that I'm confident will work for you, as I have just tested it successfully in my own environment to capture GRE-encapsulated multicast traffic. In my case, the multicast address is and my capture filter is, "ip[44:4]==0xEFC0014E", where the 44 byte offset is based on a 20 byte IP header and 8 byte GRE header.

(23 Mar '12, 21:08) cmaynard ♦♦

Thank you so very much. I too think that 2nd post is my best filter to try even if I have to move the offset. What is bothering me is what has changed. I've done this hundreds of times before with no problems.

Again thanks a ton and I'll update you Monday.


(23 Mar '12, 22:23) bonzadams

I was able to capture the packet with your command. The offset is 40 and it works just like I wanted it to.



(26 Mar '12, 14:50) bonzadams
showing 5 of 7 show 2 more comments