I am testing 802.1s with two Cisco Catalyst 29xx switch,
and run into the same problem as described by Alois. Examining the
packet dump further, it seems to me that the problem is more than the interpretation
of the version 3 length field as have been discussed in various emails
at ethereal-users. I will present my interpretation of the Alois
dump as below. (By the way, I double check my interpretation with no msti,
and 1 msti with my Catalyst 2950)
The version 3 length field in the Cisco BPDU is in
the wrong location. It seems to me that the version 3 length field
in the Cisco BPDU is a one byte field at location 0x37 (0 relative from
the beginning of the Ethernet packet) with a value "c2".
Basically, the version 3 length field in the Cisco BPDU occupies the same
location as the format selector defined in the 802.1s.
With the Cisco version 3 length field using the same
byte as the format selector, the format selector in Cisco BPDU becomes
invalid because the format selector is supposed to be 0 as defined in 802.1s
13.7 (1). (Or there is no format selector in Cisco's MSTP world?)
I guess the version 3 length of "c2" in
the Cisco BPDU below means 194 bytes of mstp information. Subtracting the
64 bytes of msti configuration id, cist internal root path cost, cist bridge
id, and cist remaining hop, there are 130 bytes for msti messages. However,
130 bytes does not represent an integral number of msti messages which
is 16 bytes each. From my experience with no msti, and 1 msti configuration,
it seems to me Cisco' msti message is 26 bytes long. 130 bytes
is 5 * 26. (With no msti the value is 0x40, and 1 msti, the
value is 0x5a.). I do not fully understand all the extra 10 bytes
in each MSTI message. My best guess is there are two "mysterious"
bytes between the MSTI flags and the MSTI regional root id. Instead
of using 1 byte MSTi bridge priority, Cisco uses an 8 byte bridge id. Instead
of using 1 byte Msti port priority, Cisco uses a 2 byte port priority.
Furthermore, using no msti, and 1 msti, I think
the 16 bytes configuration digest in the BPDU from Cisco does not follow
the recommendation of the 802.1s draft either. They have different
values compared with those value shown in 802.1s Table 13-2. So Cisco
may not use HMAC-MD5 or the signature key as specified in 802.1s 13-7 (4),
and Table 13-1.
With the above information, Ethereal may be
able to interpret Cisco mstp bpdu with some twists. Does any one
use Ethereal to decode bpdu from other MSTP switches? Other than
Ethereal reporting malformed Cisco bpdu, the impact from the LAN
perspective is that MSTP switches from other vendors and Cisco MSTP switch
can/will share the same MSTP region.
Best regards Allen
Hello,
I just captured a 802.1s BPDU and it was not decoded.
I captured on a trunk link and it was on the region boundary (maybe thats
the problem ?) on a cisco-switch.
I think there are 3 considerations applicable:
1.) ehtereal does not decode the whole packet if the MST Extension lengt
==
0 (maybe it does if it is >=1 and <=64)
2.) maybe cisco does not comply the IEEE 802.1s spec ?
3.) such a BPDU is normal on a region boundary
==> Anybody with further ideas ?
I just append the whole packet with some extractions:
Frame 1 (250 bytes on wire, 250 bytes captured)
Arrival Time: Sep 12, 2003 16:20:25.000000000
Time delta from previous packet: 0.000000000 seconds
Time relative to first packet: 0.000000000 seconds
Frame Number: 1
Packet Length: 250 bytes
Capture Length: 250 bytes
IEEE 802.3 Ethernet
Destination: 01:80:c2:00:00:00 (01:80:c2:00:00:00)
Source: 00:50:73:69:17:fa (00:50:73:69:17:fa)
Length: 236
Logical-Link Control
DSAP: Spanning Tree BPDU (0x42)
IG Bit: Individual
SSAP: Spanning Tree BPDU (0x42)
CR Bit: Command
Control field: U, func = UI (0x03)
000. 00.. = Unnumbered Information
.... ..11 = Unnumbered frame
Spanning Tree Protocol
Protocol Identifier: Spanning Tree Protocol (0x0000)
Protocol Version Identifier: Multiple Spanning Tree (3)
BPDU Type: Rapid/Multiple Spanning Tree (0x02)
BPDU flags: 0x3c (Forwarding, Learning, Port Role: Designated)
0... .... = Topology Change Acknowledgment:
No
.0.. .... = Agreement: No
..1. .... = Forwarding: Yes
...1 .... = Learning: Yes
.... 11.. = Port Role: Designated (3)
.... ..0. = Proposal: No
.... ...0 = Topology Change: No
Root Identifier: 32768 / 00:09:e8:99:85:80
Root Path Cost: 0
Bridge Identifier: 32768 / 00:09:e8:99:85:80
Port identifier: 0x8103
Message Age: 0
Max Age: 20
Hello Time: 2
Forward Delay: 15
Version 1 Length: 0
MST Extension, Length: 0
[Malformed Packet: STP]
