Ethereal-dev: [Ethereal-dev] Comments and traces regarding new dissector - packet-extreme.c
Hello Joerg,
I'm was very happy to see the new packet-extreme.c
module. I believe the comments I've made below may
be useful to augment this new Extreme dissector.
I have also attached three example traces that include
both EDP and EAPS data. (When I get some free
time to learn how, I hope to add them to the wiki).
Some of the small problems I see with the current
packet-extreme.c dissector include:
1) The "Info element" TLV values for the "edp.info.slot" and
"edp.info.port" fields are currently off by a value of one. To
correctly display these values it appears that the raw values
must be incremented by one. In the attached file edp1.trace,
my network monitor was physically connected to interface "8:60"
but the "edp" packets are currently reported as the values
"slot 7" and "port 59".
2) The "Null" TLV I believe is actually used to explicitly mark the
end of the Extreme PDU. In my own prototype extreme dissector
I had been referring to this as the "End of EPDU" TLV. In my traces
I have seen this TLV in virtually every EPDU, and it has always
been the last TLV. Instead of referring to this as the "Null" TLV
would it be better to call it the "End of EPDU" or perhaps
"End OF TLVs" or something similar?
3) Instead of dissecting the TLV header as three fields: marker
(one octet), type (one octet) and length (two octets), would it
be better to simply dissect the header as two fields: type (two octets)
and length (2 octets)? The TLV types would then be referenced
as a 16 bit value (i.e. 0x9900, 0x9901, 0x9902, etc).
4) Regarding the flag bit 0x80 seen in some VLAN TLVs. I
believe this bit is set when the advertised VLAN is actually defined
to traverse current interface. I did a series of tests and saw
how each VLAN once created was included in subsequent VLAN
TLVs with the flag bit clear. Whenever I added the monitored
port to a VLAN I saw that the flag bit for that VLAN would be
set. If the interface was a 802.1Q trunk interface then each VLAN
that was added to the trunk appears to have the VLAN flag bit set.
I had NOT come up with a good pair of terms to describe the state
of this bit. In my prototype Extreme dissector I used the text
"Traversing" when the VLAN flag bit 0x80 was set, and the text
"Defined" when VLAN flag bit 0x80 was clear. But I really wasn't
happy with those terms.
Now regarding my three attached trace files:
edp1.trace.gz
eaps.mirror1.trace.gz
eaps.mirro2.trace.gz
The edp1.trace file is a very small trace that shows a typical
type of EDP packet that one would see when attached to an
Extreme switch port. In this case I was attached to port
8:60 of a BD10k but this is currently reported as 7:59
(slot 7, port 59).
The eaps.mirror1.trace and eaps.mirror2.trace files are examples
of what one might see if they use Extreme's mirror command to
present traffic to a monitor port. In this case, mirror1 was made
from one switch, and mirror2 was made (a little while later) from a
second switch. In both cases I was mirroring port 1:3's traffic to
the monitor port 8:60 with 802.1Q VLAN tagging enabled. The typical
EDP packets contained within these traces are reported
as ports 0:2 and 7:59 respectively instead of the expected 1:3
and 8:60.
I was monitoring the EAPS traffic between these two devices
when I had a known physical problem, the 10Gig link between these
two devices was not working (the TX from switch 1 was not making
it to switch 2).
The mirror1 trace file shows all traffic seen coming and going on
switch 1's port 1:3. One can see all the EAPS Type "Health"
message are reporting the EAPS ring as down (EAPS state is
"Failed"). The TX signal from switch 1 was not making it into
switch 2.
The mirror2 trace, taken from switch 2, shows the same EAPS
ring from the peer switch as the 10Gig interface link is restored.
This trace includes EAPS Type "Health" and "Ring up flush fdb"
messages. The EAPS state is seen transitioning from "Failed" to
"Complete". This circuit was defined as a "Shared" EAPS interface
containing three EAPS control VLANS (VLANS 100, 200 and 300).
This mirror2 trace file also includes the more typical EDP packets
exchanged by two EDP enabled switches. Once EDP adjacency
is established it appears that the both Extreme systems advertise
not only their System and Display TLVs but also include the VLAN
TLVS as well as a few as yet unknown TLVs (0x0e and 0x15).
To select out just the EAPS messages from the other Extreme PDUs
use the "edp.eaps.ver" display filter. To select the non-EAPS
messages from the attached trace files use the "!edp.eaps.ver"
display filter.
I've also added the file "exteme-pdu-comment.c" It was the
primary comment block I had in my prototype Extreme dissector.
If you believe it useful please feel free to add it to the
packet-extreme.c file.
I hope you find the above information and the attached files
useful.
Best regards,
Jim Young
Attachment:
edp1.trace.gz
Description: GNU Zip compressed data
Attachment:
eaps.mirror1.trace.gz
Description: GNU Zip compressed data
Attachment:
eaps.mirror2.trace.gz
Description: GNU Zip compressed data
Attachment:
extreme-pdu-comment.c
Description: Binary data
