Running MST between 2960 & HP7510

[c.walsh]

Does anyone know if this will work, is supported on a 2960 running c2960-lanlitek9-mz.12.2.50.SE5?

Customer has tried to implement this & looses connectivity as soon as config applied

cheers

Colin

[Peter Paluch]

Hi Colin,

It would be very helpful if you could post the entire MST configuration from both switches so that we can have an idea what we are dealing here with. Also, any logging messages displayed during the network outage from any of these switches are necessary to narrow down the possible cause of the problem.

A couple of hints:

• The connectivity outage must be caused by some ports becoming Discarding for whatever reason. We must identify that reason. It would be helpful to see the output of the show spanning-tree from both switches during the network outage
• Check the output of the show spanning-tree inconsistentports on the 2960 if there are any ports identified as inconsistent during the network outage. The type of their inconsistency may point out to the cause of this issue.
• The MST region configuration must be absolutely identical on both switches. I suggest comparing the MD5 digest from the 2960 (displayed on 2960 by the show spanning-tree mst configuration digest) with the MD5 digest on the HP (displayed on HP by the show spanning-tree)

Looking forward to reading from you.

Best regards,

Peter

[c.walsh]

Peter,

     I went to the customer site to test the scenario...

HP Core 1 -------- HP Core 2

        |                         |

        |                         |

Cisco 2950---------Cisco 2960

We got this error message when connecting the second link.

%SPANTREE-2-PVSTSIM_FAIL: Blocking designated port Fa0/1: Inconsitent superior PVST BPDU received on VLAN 899, claiming root 0:0024.a83c.8600

config on 2960

spanning-tree mode mst

spanning-tree extend system-id

!

spanning-tree mst configuration

instance 0 vlan 1 - 4094

name GNET

revision 1

spanning-tree mode mst

no spanning-tree optimize bpdu transmission

spanning-tree extend system-id

!

spanning-tree mst configuration

instance 0 vlan 1 - 4094

name GNET

revision 1

int g0/1

spanning-tree mst pre-standard

spanning-tree mode mst
spanning-tree extend system-id

!

interface connecting to 2950

int g0/1
spanning-tree mst pre-standard

config on 2950

spanning-tree mode mst
no spanning-tree optimize bpdu transmission
spanning-tree extend system-id
!
spanning-tree mst configuration
instance 0 vlan 1 - 4094
name GNET
revision 1

any idea's

[Peter Paluch]

Colin,

So far, I can tell that the 2950 is - for some so far unknown reason - receiving PVST+ BPDUs on its Fa0/1 port, and this BPDU fails to meet special criteria that allows the MSTP and PVST+ to seamlessly interoperate. That is why the port declares the PVST Simulation Inconsistency.

If the entire network was properly configured for MST, there should be no PVST+ BPDUs present at all. I am therefore wondering where do these PVST+ BPDUs come from. Are both HP switches properly configured to run MSTP? Are there any other Catalyst switches in this network that are still running PVST+? Where should the STP root be placed?

Providing me with the requested output of the commands I specified in my first response would be a good starting point. Without knowing more about your topology and the configuration of its elements, it is hard to tell anythng else.

Best regards,

Peter

[c.walsh]

Peter,

    The problem is that i am not on the custoers site.

They have the core HP switches running MSTP & the edge switches (2960/50's) running PVST & the request is to migrate all to MSTP.

However, the issue seen above was when we converted a 2950 & a 2960 to MSTP.

The connectivity is all over the place, with switches daisy chained to one another.

Is there a way of stopping the port from blocking when this BPDU is seen, as they have around 75 switches to migrate & we don't really want to have to connect via the console to each device, if possible.

Thanks

Colin

[Peter Paluch]

Hello Colin,

I apologize for answering lately.

Ah, I see. The issue you are seeing is caused by Cisco's own mechanism of cooperation between MSTP and PVST+, and the HP switches are not contributing in any way to the problems you are experiencing.

In short and without going into much detail, in order for a Cisco running MSTP to properly interact with PVST+ region without causing network outages, two configuration options must be met:

• Either the MSTP region must contain a root bridge for MST instance 0 whose priority in this instance 0 is the lowest among all PVST+ switches in any VLAN. Each PVST+ switch in any VLAN that is created on it must have a strictly numerically higher bridge priority than the priority of the root bridge for MST instance 0. In other words, the root bridge for MST instance 0 must have a numerically lower priority than any PVST+ switch in any VLAN. This MST switch will then become the root switch for the PVST+ region and each VLAN in it.
• Or the PVST+ region must be configured so that it contains the root bridge for each existing VLAN this way:
  • For VLAN 1 the priority of the PVST+ root bridge must be numerically lower than the priority of any MSTP switch for MST instance 0.
  • For VLANs 2-4094, respective root bridges must have a numerically lower priority than the PVST+ root bridge for VLAN 1.

Only if one of these requirements is met, the cooperation of MSTP and PVST+ region will not lead to permanently blocked ports. Before gradually migrating to MSTP, you have to decide which scenario you want to implement and make necessary precautions before actually starting to modify the STP mode.

Best regards,

Peter