[c-nsp] MST to Rapid PVST+ interaction.

[Kevin Barrass]

Hi

Thank you for the below, looking through the document im not sure it
will resolve my problem. The problem we have is that a switch running
rapid PVST+ 802.1w connecting to the MST core using 802.1q trunks it is
detected as a 802.1D on the MST core and operates at the boundary as
802.1D but if we set the links from the switch running 802.1w to the MST
core as access ports it works fine as the MST core detects the
neighbouring switch as operating in 802.1w and sets the boundary to
operate 802.1w.

Regards

Kev


-----Original Message-----
From: Michael K. Smith - Adhost [mailto:mksmith at adhost.com] 
Sent: 01 October 2007 21:29
To: Kevin Barrass; cisco-nsp at puck.nether.net
Subject: RE: [c-nsp] MST to Rapid PVST+ interaction.

Hello Kevin:

> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp- 
> bounces at puck.nether.net] On Behalf Of Kevin Barrass
> Sent: Monday, October 01, 2007 5:56 AM
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] MST to Rapid PVST+ interaction.
> 
> 
> Hi
> 
> On a test network we have an MST core network that we are testing how 
> to connect clients to resiliently.
> Most of our clients use Rapid PVST+. If we simulate the clients
network
> with a single switch running Rapid PVST+ and connect two access ports 
> from this to the MST core network one interface is set to BLK-ALT as 
> expected and the 2 ports on the MST core and client network switch
runs
> in rapid spanning compatibility mode giving fast convergence using the

> MST IST.
> 
> The problem is when we configure the 2 interface on both the MST core 
> network and client network switch to be dot1q trunks even with only
one
> vlan allowed all works the same other than the ports on the MST core 
> show as operating in Standard spanning tree mode, loosing the fast 
> convergence of MST or Rapid PVST+.
> 
> Has anyone come across this as there is very little documentation out 
> there for this kind of setup. Ive even tried the Cisco.com Forums.
> The hardware is MST core made of Cisco 4507s running 12.1(19)EW1 and a

> Cisco 2950s.
> If this is too vague please let me know and I can provide more info.
> 
> Kev Barrass

Check out:

http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.1E/nati
ve/configuration/guide/spantree.html#wp1050781

Specifically, this:

Restarting Protocol Migration
A switch running both MSTP and RSTP supports a built-in protocol
migration process that enables the switch to interoperate with legacy
802.1D switches. If this switch receives a legacy 802.1D configuration
BPDU (a BPDU with the protocol version set to 0), it sends only 802.1D
BPDUs on that port. An MSTP switch can also detect that a port is at the
boundary of a region when it receives a legacy BPDU, or an MST BPDU
(version 3) associated with a different region, or an RST BPDU (version
2). 

However, the switch does not automatically revert to the MSTP mode if it
no longer receives 802.1D BPDUs because it cannot determine whether the
legacy switch has been removed from the link unless the legacy switch is
the designated switch. A switch also might continue to assign a boundary
role to a port when the switch to which it is connected has joined the
region. 

To restart the protocol migration process (force the renegotiation with
neighboring switches) on the entire switch, you can use the clear
spanning-tree detected-protocols privileged EXEC command. To restart the
protocol migration process on a specific interface, enter the clear
spanning-tree detected-protocols interface interface-id privileged EXEC
command. 


Might that be the issue?

Regards,

Mike