[c-nsp] MSTP issue. Isolation of core switch

[Andrey Teslenko]

Hello!

Thanks for you response.

As I know MSTP does not send MSTI’s information in separate BPDUs, this
information is piggybacked into the IST’s BPDUs using special M-Record
fields.

So, I can have multiple MSTI or one with whole vlan range (1-4096) no
matter. Also we not planned to use some load share mechanism, so i did not
see any sense in multiple instance.

In any case, BPDU will be propagated in MST0 (Internal Spanning Tree) and
will consist of such components as configuration name, revision number and
a hash value calculated over VLANs to MSTI mapping table contents

The configuration name and revision parapeters have sense if we used
multiple instase (maybe i'm wrong). But this is not acceptable for us now.

I think that this problem may apear due very large L2 segment. So value
"Max Hops"  exhausts itself in some cases.
As a result sw-core receives BPDU 0 and after that  happens  the following
scenario

sw-Core ceases to receive BPDU from all neighbors and and decides that he
is root.
Upstream switches sends superior root bridge information to the sw-Core
bridge but receives the BPDUs with Designated bit set, the upstream switch
concludes that the downstream does not hear its BPDU’s. The upstream switch
then blocks the downstream port and marks it as STP dispute link

BUT Why sw-CORE ceases to receive BPDU from ALL neighbors?  - a mystery.




2013/1/9 <cnsp at marenda.net>

> On Wed, Jan 09, 2013 at 06:41:34PM +0200, Andrey Teslenko wrote:
> > Hello!
> > We have a large L2 network with one MSTI region and few ring topologies.
> >
> > The topology looks like this:
> [...]
> > It all started after the closure 10G ring.
> >
> > In general periodically from all sides sw-Core sees 'BPDU received 0'.
> >
> > Neighbors in the 0-th (CST) instance sees the packages, but in the 1-st
> > (operating) no.
> >
> > After that  they put the ports into position 'blk disput'.
> > It is understandable, because sw-core does not see BPDU from them, so it
> > can not answer.
> >
> > Here is configuration of MSTP
> >
> > spanning-tree mode mst
> > spanning-tree logging
> > spanning-tree extend system-id
> > !
> > spanning-tree mst configuration
> >  instance 1 vlan 1-4094
>
>
> Give it a Name and a Revision Number.
> dont forget to ACTIVATE the new revision !
>
> On All switches identical mst configuration
> (name, revision, mapping).
>
> Remember you may need to reload after a wr mem to change
> spanning tree version/mode.
>
>
> > *show spanning-tree mst*
> >
> > ##### MST0   vlans mapped:   none
>
> [...]
>
> You wont see here anything since all your vlans have been mapped to
> instance 1, not to instance 0 .
>
>
> For Example:
>
> !
> spanning-tree mode mst
> spanning-tree logging
> spanning-tree portfast default
> spanning-tree portfast bpduguard default
> spanning-tree extend system-id
> !
> spanning-tree mst configuration
>  name MAGIC
>   revision 2
>   instance 1 vlan 500,600,900
>   instance 2 vlan 501-599
>   instance 3 vlan 700-799
>   instance 4 vlan 100
>   instance 5 vlan 800-899
>   instance 6 vlan 601-699
>   !
> ! all other vlans will be in instance 0
>   !
>  spanning-tree mst 2-3 priority 28672
>  spanning-tree mst 5 priority 24576
> !
>
> Maybe that vtp version 3 (on cisco) helps you in distributing the instance
> mapping.
>
> You may want to set the priorities to ensure which switch is your primary
> and second root,
> else they will elect /compute on an fancy mac-adress iand interface speed
> based algorithm.
>
> So do this explicite for each instance.
>
> Remember that some Vendors Switches need to have the vlans created
> (or will do it for you exceeding capabilities)
> and others not.
>
>
> ... and iff you have cisco switches powerfull enought,
> run per-vlan (rapid) spanning tree. This prevents you from getting a knot
> in the head
> and a lot of fun debugging mst.
>
> Hope this help's,
>
> Juergen.
>
>