Linux Ethernet Bridging - Jun 2012 - [Bridge] Query on Sapnning tree implementation from standard point of view

Hi ,

I am going through spanning tree protocol and was testing it on Linux. My
observation is there is no validation of timers for configuration BPDU.? Lets
say Root bridge received another BPDU from new bridge with invalid timer values
but less priority, the existing bridge is becoming non-root bridge and is
advertising the invalid timer values.

As i have gone through 802.1D-1998 standard, i understand that 2004 is current
one but i was looking into STP not RSTP, i preferred to read this standard. I
find these lines:

==============================================9.3.3 Validation of received BPDUs

A Bridge Protocol Entity shall process a received BPDU as specified in 8.7 if
and only if the BPDU contains at least four octets and the Protocol Identifier
has the value specified for BPDUs (9.3.2), and
a) The BPDU Type denotes a Configuration BPDU and the BPDU contains at least 35
octets, and the
value of the BPDUs Message Age parameter is less than that of its Max Age
parameter; or

b) The BPDU Type denotes a Topology Change Notification BPDU.
In case a), any octets that are present beyond Octet 35 are ignored, as far as
processing according to this
standard is concerned. Similarly, in case b), any octets beyond Octet 4 are
ignored.

===========================================
Does this implies that any value timer values present within octet 35 is valid
value and there is no validation done. Even if range for hello timer, max age
and forward delay is defined and is limited. Is it an issue or fine within the
standard?

Please help me understand this issue and thanks for any comments.

Regards,
Sujata

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.linuxfoundation.org/pipermail/bridge/attachments/20120614/34f72c52/attachment.html>

On Thu, Jun 14, 2012 at 5:53 PM, Sujata Verma <sujataverma3 at
yahoo.com>wrote:
> Hi ,
>
> I am going through spanning tree protocol and was testing it on Linux. My
> observation is there is no validation of timers for configuration BPDU.
> Lets say Root bridge received another BPDU from new bridge with invalid
> timer values but less priority, the existing bridge is becoming non-root
> bridge and is advertising the invalid timer values.
>
> As i have gone through 802.1D-1998 standard, i understand that 2004 is
> current one but i was looking into STP not RSTP, i preferred to read this
> standard. I find these lines:
>
> ==============================================> 9.3.3 Validation of
received BPDUs
>
> A Bridge Protocol Entity shall process a received BPDU as specified in 8.7
> if and only if the BPDU contains at least four octets and the Protocol
> Identifier has the value specified for BPDUs (9.3.2), and
> a) The BPDU Type denotes a Configuration BPDU and the BPDU contains at
> least 35 octets, and the
> value of the BPDUs Message Age parameter is less than that of its Max Age
> parameter; or
>
> b) The BPDU Type denotes a Topology Change Notification BPDU.
> In case a), any octets that are present beyond Octet 35 are ignored, as
> far as processing according to this
> standard is concerned. Similarly, in case b), any octets beyond Octet 4
> are ignored.
>
> ===========================================>
> Does this implies that any value timer values present within octet 35 is
> valid value and there is no validation done. Even if range for hello timer,
> max age and forward delay is defined and is limited. Is it an issue or fine
> within the standard?
>
>   Not all STP implementation do BPDU validations i.e validates all BPDU
parameters present within 35 octet. The validation checks for invalid
values present in the bpdu,
  if the BPDU validation fails it drops the BPDU. The have seen this
validations in proprietary software.

> Please help me understand this issue and thanks for any comments.
>
> Regards,
> Sujata
>
>
> _______________________________________________
> Bridge mailing list
> Bridge at lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bridge
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.linuxfoundation.org/pipermail/bridge/attachments/20120614/a77d7053/attachment.html>

Thanks. I was doing the same experiment on few switches, i could get hold of and
this is the result:

Cisco Switch catalyst 2950 : Completely ignoring the packet, so validations are
proper.

Netgear FSM726V3 : Hello timer is validated and is propagated as 10 instead of
255 ( which i sent) other max age and forward delay still it accepts as 255.

DLINK-DES-3026 : No validation done and accepts all as 255 ( max age, forward
delay and hello timer)

In both Netgear and Dlink the message age is changed to 16, which i am not sure
why it has happened ?

my setup is simple

? PC1------Switch------PC2

On Friday 15 June 2012 15:25:39 Sujata Verma wrote:
> Thanks. I was doing the same experiment on few switches, i could get hold
> of and this is the result:
>
> Cisco Switch catalyst 2950 : Completely ignoring the packet, so validations
> are proper.
Hello, Sujata!
Would the result of the experiment differ if you set Message Age and Max Age 
to the correct values while leaving Hello Time and Forward Delay incorrect:
Message Age = 19 (encoded as 0x13 0x00)
Max Age = 20 (encoded as 0x14 0x00)
Hello Time = 255 (encoded as 0xFF 0x00)
Forward Delay = 255 (encoded as 0xFF 0x00)

How would Cisco switch handle such BPDUs?

-- 
With Best Regards,
Vitalii Demianets

With below setting I was able to run the test on all 4 devices

Message Age = 19 (encoded as 0x13 0x00)
Max Age = 20 (encoded as 0x14 0x00)
Hello Time = 255 (encoded as 0xFF 0xFF)
Forward Delay = 255 (encoded as 0xFF 0xFF)

The results are:

Linux bridge:

Accepting the new BPDU and accepting all fields as it is given above.


Netgear:

Not accepting the BPDU, advertising its own with values message age:0, max age:
20, hello time :2 and forward delay 15


Dlink:
Not accepting the BPDU , advertising its own with values message age:0, max age:
20,

hello time :2 and forward delay 15 


Cisco: 

Not accepting the BPDU, advertising its own with values message age:0, max age:
20,

hello time :2 and forward delay 15.

In Cisco the configuration is 

2950#show spanning-tree summary
Root bridge for: VLAN0001.
Extended system ID is enabled.
PortFast BPDU Guard is disabled
EtherChannel misconfiguration guard is enabled
UplinkFast is disabled
BackboneFast is disabled
Default pathcost method used is short

Name?????????????????? Blocking Listening Learning Forwarding STP Active
---------------------- -------- --------- -------- ---------- ----------
VLAN0001????????????????? 0??????? 0???????? 0??????? 2????????? 2
---------------------- -------- --------- -------- ---------- ----------
1 vlan??????????????????? 0??????? 0???????? 0??????? 2????????? 2

=====================================
So for the given values except linux all switches are dropping/ignoring the
packet.

Regards,
Sujata

--- On Mon, 6/18/12, Vitalii Demianets <vitas at nppfactor.kiev.ua> wrote:

From: Vitalii Demianets <vitas at nppfactor.kiev.ua>
Subject: Re: [Bridge] Query on Sapnning tree implementation from standard point
of view
To: bridge at lists.linux-foundation.org
Date: Monday, June 18, 2012, 5:18 PM

On Friday 15 June 2012 15:25:39 Sujata Verma wrote:
> Thanks. I was doing the same experiment on few switches, i could get hold
> of and this is the result:
>
> Cisco Switch catalyst 2950 : Completely ignoring the packet, so validations
> are proper.
Hello, Sujata!
Would the result of the experiment differ if you set Message Age and Max Age 
to the correct values while leaving Hello Time and Forward Delay incorrect:
Message Age = 19 (encoded as 0x13 0x00)
Max Age = 20 (encoded as 0x14 0x00)
Hello Time = 255 (encoded as 0xFF 0x00)
Forward Delay = 255 (encoded as 0xFF 0x00)

How would Cisco switch handle such BPDUs?

-- 
With Best Regards,
Vitalii Demianets
_______________________________________________
Bridge mailing list
Bridge at lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bridge
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.linuxfoundation.org/pipermail/bridge/attachments/20120619/c1855a7a/attachment.html>