Pathcost method

[gryphon55]

Hello,

I cannot find a great deal of documentation about exactly how the pathcost method operates.

We have a 6509 connecting to a 4006 which in turn connects to several 3550's. The 6509 and the 4006 are in the same MST domain and the 4006/3550's are in a PVST domain.

As far as I can tell, the 6509 default pathcost method is long, whereas the 4006 and 3550 defaults are short. This causes the 4006 to report 'Configured Pathcost method is short (Operational value is long)', however the 3550's report the use of short.

I have three questions;

1. How does the 4006 detect the operational mode for pathcost? Does it simply revert to this method if it detects a larger pathcost number being used?

2. Is the same pathcost method used globally on the switch, or can it perform long method with the 6509 and short with the 3550's?

3. Can a mis-match of pathcost methods cause the 4006 to wrongly detect the spanning-tree type used by the 6509 (if they both reboot at the same time, we see this problem).

Essentially, I would like to know whether forcing the default pathcost method on the 4006 to be long will a) Resolve the incorrect spanning tree type detection. b) Continue to operate in short mode with the 3550s.

Many thanks in advance,

Tom.

[Francois Tallet]

Hi Tom,

1: there is no detection. The trick is that the pathcost has always been encoded in 4 bytes in the BPDUs. It's just that the older version of STP only used two bytes.

2: a bridge only uses a pathcost method on all its ports.

3: no, there will be no impact on STP type.

You spanning tree type issue might be a race condition, you'll have to tell us a little bit more about this. It is possible to have a mix of pathcost method in the network, it's just that it is more complex to administer (the default topology that STP computes might not be the most natural one). BTW, I did not know that the default pathcost method was depending on the platform. The extended sysid is definitely, but I don't see why the default pathcost would be. MST uses the long path cost by default. If some other protocol does this, that's probably a software revision difference more than a platform difference.

Regards,

Francois

[gryphon55]

Hello Francois,

Thank you for your reply.

The "deafult" I was referrring to meant that they act this way without modifying their config, so its quite possible that its based on software revision rather than platform.

What do you mean by race condition and what can I do about it? The 4006 boots up faster than the 6509, what more would you need to know to diagnose this?

Thanks,

Tom.

[Francois Tallet]

Hi Tom,

It is technically possible indeed that there is a change in the default pathcost method based on the software. I'm not aware of this transition from short cost to long cost by default. Normally, this is something that is done step by step in IOS, by first always displaying the default configuration in show run, and then, in a later release, move it to a new default.

I thought that only MST would use the long pathcost, because it has always shipped in customer products this way. PVST was using the short path cost, and we, Cisco, cannot just change the default behavior from one release to another because it would have the potential of silently modifying the customer's configuration as a result of an upgrade. That's basically the reason for those configuration command: we introduced a new behavior, but we could not make them default, so we needed a CLI.

Anyway, this is not really important;-) An alternate port does not send BPDUs. It just remains silent. So at link up, if a port receives a superior BPDU and goes to alternate role, its peer will never hear from it. On the other hand, also at link up, this port might have a chance to first send a BPDU before receiving the superior information. In that case the peer will hear from it.

One case where we had an issue was the detection of pre-standard bridges (Cisco shipped a pre-standard version of MST) for example. That's why I would like to know a little bit more about what you see as a "spanning tree type" detection issue, and the consequence on your network.

Thanks and regards,

Francois

[gryphon55]

Hi Francois,

Thanks again for your thoughrough response.

Unfortuanately, I do not have the exact output during the failure, but I will explain the best I can.

At certain times (usually after a reboot from what I can tell), the "Type" field shown with "show spanning-tree mst" is something that is NOT "P2p" (as you would expect for a link between two mst peers), from what I remember it appears as "P2p Pre-STD-Rx" but that could be wrong. When I mentioned we have a 6509 connecting to the 4006 - its actually 2 6509s, each connecting to 5 4006's. Its always the 4006's which display this incorrect spanning tree type.

The effect it has on our network is that the "wrong" port (in terms of pathcost) becomes designated, blocking what should be the active port. Performing a shut/no shut on the blocked port causes it to re-converge, detect the correct type and block the correct port. I do the same on all the 4006's when this happens.

I realise this information is kind of sketchy, but this has only occured 2-3 times in the last 3 months and wehave to fix the issue as soon as possible rather than capture as much diagnostic details as possible. However, if you could recommend something which would be useful to capture should it happen again, it would be very much appreciated.

Thanks again,

Tom.

[Francois Tallet]

Ah, by coincidence, this looks exactly like the problem I was describing about the pre-standard neigbor detection.

Depending on the IOS release, you have "standard MST" (following the latest IEEE spec) and "pre-standard MST", which was released before MST was finalized in the IEEE. You can easily check if a bridge is standard by looking if it accepts configuring an MST instance ID superior to 15.

MST standard release is able to automagically detect its pre-standard neighbor. Unfortunately, the auto-detection can fail if the neighbor is silent (root port or alternate port), just as I described earlier. If the autodection fails, the pre-standard neighbor will think the standard bridge is in a different MST region and you will loose your vlan load-balancing. That seems to match your description of the problem.

The solution to this is simply to hardcode on the standard bridge the knowledge of its pre-standard neigbhors. On the standard bridge, configure "spanning-tree mst pre-standard" on the ports connected to pre-standard bridges.

In fact, the label "Pre-STD-Rx" means that you have received a pre-standard BPDU on the port (the autodection has worked), but that you did not configure pre-standard on the port. As soon as you make the configuration, it will display "pre-STD" when you receive such a BPDU. In fact, there should also be a syslog warning about the problem the first time you receive a pre-standard BPDU on a port not configured for pre-standard.

You can forget about the P2P, it's a red herring. Whether the port is p2p or not only depends on the duplex setting by default, and can be overriden by configuration using the "spanning-tree link-type" command.

http://www.cisco.com/univercd/cc/td/doc/product/lan/cat3750/12225see/scg/swmstp.htm#wp1143790

http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/122sx/swcg/mst.htm#wp1156732

Regards,

Francois