Today, while troubleshooting a reported SIP trunking issue, I was seeing a firewall claiming it was transmitting packets, but they were not seen by the downstream endpoint. I didn’t trust the ASA packet capture in this case, so I decided to collect traffic from its immediately-connected device, a Nexus 7009, to verify. Cisco has a technote for a configuration example on this platform.

ERSPAN is handy to be able to do ad-hoc troubleshooting when you need to a packet capture from a remote device, so I configured an erspan-source session to capture traffic on that particular interface and sent it to a remote Linux machine.

This deployment has multiple VDCs on the chassis, so the source IP of the ERSPAN GRE tunnel needs to be configured in the admin VDC of the box with the global keyword. Note that you cannot use the management interface on this platform. In my particular case I used an IP of a loopback interface in the VDC and VRF I was sourcing the traffic from. (I haven’t tested if this is required, maybe you can use any IP?)

monitor erspan origin ip-address 192.0.2.1 global

Then, in the VDC containing the source interface, I created a monitor session to the destination IP of the target machine. Note that the session is administratively disabled by default and must be manually no shut to start the capture. The exec command show monitor was helpful in telling the current state of the session and whether anything is missing from the configuration.

monitor session 1 type erspan-source
  erspan-id 10
  vrf default
  destination ip 198.51.100.100
  source interface Ethernet3/23 both
  no shut

Traffic is encapsulated and sent to the target device. Wireshark will fully decode the traffic including the original packet in the GRE payload. In this particular situation, though, there was lots of other traffic and I needed to filter only the packets I was concerned about. I used packet offsets in the tcpdump filter expression to match UDP (protocol 17, 0x11) source port 5060 (SIP, 0x13c4).

# echo 'obase=16;5060' | bc
13C4
# tcpdump -w /tmp/erspan.pcap -c 100 -vni eth0 'proto gre and ip[59]=0x11 and ip[70:2]=0x13c4'

By doing a simultaneous capture both locally on the ASA and via ERSPAN on the adjacent switch, I was able to prove that the packets in question were indeed not on the wire. The actual issue isn’t solved, but this allowed me to quickly isolate the problem to one device.