Invalid BPDU transmission?

Hello,

in function STP_transmit_check_conditions (rstplib/transmit.c) the case:

    case IDLE:
      if (!port->helloWhen) return STP_hop_2_state (this,
      TRANSMIT_PERIODIC);
      if (!port->sendRSTP && port->newInfo &&
          (port->txCount < TxHoldCount) &&
          (port->role == DesignatedPort) &&
          port->helloWhen)
        return STP_hop_2_state (this, TRANSMIT_CONFIG);
      if (!port->sendRSTP && port->newInfo &&
          (port->txCount < TxHoldCount) &&
          (port->role == RootPort) &&
          port->helloWhen)
        return STP_hop_2_state (this, TRANSMIT_TCN);
      if (port->sendRSTP && port->newInfo &&
          (port->txCount < TxHoldCount) &&
          ((port->role == RootPort) ||         <----
           (port->role == DesignatedPort)))
        return STP_hop_2_state (this, TRANSMIT_RSTP);
      break;

states that a RSTP bpdu can be transmitted even throught a RootPort which, IMHO, is not correct... only topology change BPDU should be sent over the RootPort. That's why I suggest to remove the line with the arrow (<----).

Comments? :)

Ciao,

Rodolfo

GNU/Linux Solutions                  e-mail: [email protected]
Linux Device Driver                          [email protected]
Embedded Systems                     phone:  +39 349 2432127
UNIX programming                     skype:  rodolfo.giometti
Freelance ICT Italia - Consulente ICT Italia - www.consulenti-ict.it

Both CONFIG and TCN BPDUs are used only in STP compatibility mode. In RSTP mode, the BPDUs sent in both directions are RSTP BPDUs. So they can be sent on the root port.

For a description of how topology changes are handled, see the section titled "New Topology Change Mechanisms" in
http://www.cisco.com/en/US/tech/tk389/tk621/technologies_white_paper09186a0080094cfa.shtml

Is this causing any particular issue?

Yes. By using the following connection:

  +---------------+        +----------------------+
  | EXTRA bridge  O <----> O(eth5) bridge on test |
  +---------------+        |      (eth0) (eth1)   |
                           +--------O------O------+
                                    ^      ^
                                    |      |
                                    +------+

where «EXTRA bridge» is a rstp bridge acting as root bridge and NOT running rstpd (but a proprietary rstp implementation), while «bridge on test» is my bridge running rstpd.

«EXTRA bridge» sends to «bridge on test» the following BDPU:

01 80 c2 00 00 00 00 02 3e 99 ba 1c 00 27 42 42 03 00 00 02 02 7e 80 00 00 02 3e 99 ba 1c 00 00 00 00 80 00 00 02 3e 99 ba 1c 80 01 00 00 14 00 02 00 0f 00 00

and «bridge on test» replies on «eth5», which is its root port.

Without my modification «bridge on test» is unstable, in fact the states of eth0 and eth1 ports doesn't fit to Fwd end Blk but they change in a strange manner and don't stabilize... also opening and closing the loop cause more instability and the bridge takes very long time before changing its ports states!

By adding my modification everything works well.

Ciao,

Rodolfo

GNU/Linux Solutions                  e-mail: [email protected]
Linux Device Driver                          [email protected]
Embedded Systems                     phone:  +39 349 2432127
UNIX programming                     skype:  rodolfo.giometti
Freelance ICT Italia - Consulente ICT Italia - www.consulenti-ict.it

Sorry, the correct BDPU is the following:

01 80 c2 00 00 00 00 01  f4 33 1c 54 00 27 42 42
03 00 00 02 02 7e 00 00  00 01 f4 7e a2 57 00 00
00 00 00 00 00 01 f4 7e  a2 57 83 4e 00 00 0a 00

01 00 0f 00 00

Ciao,

Rodolfo

GNU/Linux Solutions                  e-mail: [email protected]
Linux Device Driver                          [email protected]
Embedded Systems                     phone:  +39 349 2432127
UNIX programming                     skype:  rodolfo.giometti
Freelance ICT Italia - Consulente ICT Italia - www.consulenti-ict.it

The 7e in 00 00 02 02 7e ... is a flags value with the proposal flag set (mask 0x02), so it seems correct that the test bridge should respond with agreement flag set (mask 0x40).