Work has begun on the dissection of the new 'header-type 3' ERSPAN Type-III header. The current release version of Wireshark does not decode this format at all. We currently have the copy of Wireshark in SVN decoding the new header and identifying the timestamp field which should prove very handy.
In adapting the existing ERSPAN dissector to recognize the new header, I noticed that not only are there several new fields in the new header that I cannot identify, but there are also several fields that were never identified in the old header. Does anyone know if this is documented anywhere? It would be very useful to get these headers defined in Wireshark. It also would be useful to understand the differences in headers produced by different equipment. For example, the headers produced by a Nexus 1000v switch configured with 'header-type 2' seems to differ from that produced by a 6500. (There is a bit that indicates the direction of traffic which seems to move to a different location on the 1000v.)
If anyone could help to identify some of the other unknown fields in these headers or if Cisco would be willing to provide some documentation, it would be greatly appreciated.
I make frequent use of ERSPAN for quick troubleshooting because I can send a capture from any point in the network to my workstation and set a 'ip proto 0x2f' capture filter to isolate the capture from my workstation's traffic. The timestamp in the new header is exciting because it gives a point of reference between packets which greatly increases the reliability of capturing this way. Specifically when a packet is observed to be out of order or delayed there was no way of telling if this was observed in the actual capture or if the delay or change in order occurred after the ERSPAN encapsulation. If you would like to experiment with decoding the new Type-III headers, you can check out revision 34221 or newer of Wireshark from SVN and check it out.
you are making an interesting use of ERSPAN, but it is not the one originally thought: you are capturing packets before de-capsulation if I have understood you correctly.
For this reason you need to inspect ERSPAN packets.
As far as I know ERSPAN is proprietary and this is confirmed for example by the following patent (probably a followup of a previous one)
if ERSPAN is proprietary and part of intellectual property of Cisco as stated in the link above, it is reasonable that ERSPAN details are not available to public audience.
As a result of this, it is reasonable that Wireshark has problems to decode it.
Hope to help
Understood. I actually did a search for patents on ERSPAN but found only the one you linked to and others that mention the technology. Again if anyone has more documentation or information on Cisco's direction and intent for this technology, I would be interested in reviewing it.
There are troubleshooting techniques that can be done today with ERSPAN and Wireshark that cannot be easily accomplished otherwise. For example, by setting up several ERSPAN source sessions, each with a different ID and spanning them all to a single instance of wireshark which is capture filtering for gre you can follow a packet through the switching infrastructure. You will see multiple instances of a packet, but with a different ERSPAN ID in the metadata contained in the header so that you can confirm a packet comes in on one interface and leaves on another or does not leave the switch at all. This is useful for locating where drops are occurring, especially on the 1000v where you have many source sessions available. Using this I was able to see a packet from a virtual machine being forwarded out an incorrect port, causing the upstream infrastructure to learn the MAC on the wrong port and begin forwarding traffic to it which was subsequently dropped by the 1000v loop prevention. This kind of troubleshooting is quick & easy with ERSPAN while it can be tricky to accomplish with other tools.
I understand that Cisco is using ERSPAN primarily to send to their NAM and IDS, but this secondary use is immensely valuable and should not be ignored. More thorough documentation or even Cisco involvement in attempts of projects like Wireshark to understand the protocol only stand to benefit the community.