https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5244
--- Comment #10 from Jason Masker <jason@xxxxxxxxxx> 2010-09-23 05:27:51 PDT ---
(In reply to comment #9)
> I will merge the dissectors.
That is fine. Expanding the existing dissector was my first thought. I only
opted to go with a new one because of the new GRE protocol indicator.
This header is referred to as a "ERSPAN Type III header" in Cisco
documentation, but there is little documentation speaking about what it is
exactly. For example, here
http://www.cisco.com/en/US/docs/switches/datacenter/nexus1000/sw/4_0_4_s_v_1_3/system_management/configuration/guide/n1000v_system_9span.html
it is mentioned at the bottom of the page in the feature history. Elsewhere
documentation can be found referring to the existing ERSPAN header as Type II.
If there is a Type I header I have not seen it and I do not have access to any
equipment that generates it.
Also, I am generating these headers with a Cisco Nexus 1000v virtual switch. In
the latest version of code, the command to get Type III headers is to enter
'header-type 3' in erspan-src configuration mode. The only other option is
'header-type 2' which is the default.
The only documentation I have found about the fields added in the new header
mentions the timestamp. This is the functionality I was interested in
accessing. With the type II header there is no way to know if packets were
delayed or delivered out of order when encapsulated and sent to the capture
destination and not in the traffic actually being captured. I was able to
determine the format of the timestamp and get it displayed in seconds. As far
as I can tell this is an arbitrary, running counter used to provide a running
timestamp. At least I cannot determine any clock to which this running seconds
field is synchronized. When I do captures now from the same device from which I
provided the sample, that running field now indicates 190096 seconds which is
over 52 hours. So as far as I can tell it is only provided to indicate relative
times between packets.
Also, in the case of my headers the incoming/outgoing bit switch is clearly in
the fourth octet of the unknown field after the timestamp. In the type II
headers I've looked at it appears this switch is in the first octet of the last
unknown header. Has anyone seen captures where the switch appears higher in the
header where it is currently decoded? I do see this switch flipped in some
cases, but it does not indicate direction in any of the captures from my
devices.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.