MSTP Link cost Calculation

j.samanta · ‎06-07-2006

On a trial basis when we migrated from Rapid PVST+ to MSTP in a network of Cisco 3560G switches, we observed that all the link (FastEthernet) cost which by default is 19 have been increased to 200000. Any idea on what basis this link costs is calculated? Do MSTP use some different formula for link cost calculation.

Can anybody suggest any good MSTP migration guide?

Thanks in advance.

Francois Tallet · ‎06-08-2006

MST only uses the "long path cost" introduced by 802.1t. The cost is now encoded in the whole 32 bit field of the BPDU instead of 16, as it was earlier. This leaves much more granularity, espcially when giving a cost to high speed channels.

The long path cost was an option in pvst modes (spanning-tree pathcost method [long|short]),

It was decided to directly move to the new standard long path cost method. MST requires new configuration anyway and so we don't risk changing the meaning of an existing configuration as a result of a converstion to MST.

Regards,

Francois

j.samanta · ‎06-12-2006

Hi! Francois ... Thanks a lot for your reply. Any idea about the formula for calculating the cost? Can u pls give me some hyperlink about this 802.1t standard? Additionally if you can provide me some link to MSTP documentation specially rapid PVST to MSTP, it will be great !!! Thanks in advance.

Regards,

Jyotirmay.

Francois Tallet · ‎06-13-2006

Hi Jyotirmay,

802.1t was just a revision of 802.1D, it is thus now integrated in 802.1D-2004, that you can download for free from the IEEE website: http://standards.ieee.org/getieee802/802.1.html

Look page 154, around table 17-3.

As for a good documentation about transitioning from Rapid-PVST to MST, it is still to be written I'm afraid:-( I have written two white papers describing at a high level the RSTP and MST:

http://www.cisco.com/warp/public/473/146.html

http://www.cisco.com/warp/public/473/147.html

The MST part is a little bit outdated now, but it covers some of the aspects that make it different from RSTP.

Hope this helps,

Francois

j.samanta · ‎06-13-2006

Thanks Farncois... Infact the MSTP document written by you is the only document detailing MSTP concepts if you search in Google. Your RSTP document was a marvellous one !!! Infact when I was deploying RSTP in our MetroEthernet network, its your document which helped me a lot. But somehow the port roles and step by step process interaction and related details are missing in the MSTP document. Do you have any other MSTP document, which you may have come across. Thanks in advance !!

Francois Tallet · ‎06-16-2006

Thanks! I don't have any document explaining the transition step by step. If you have any specific question, please ask them here.

There are several possible approaches, starting from the core or the access for example. I think I would rather start from the core with MST, but I'm not sure it would make a big difference. I'd be glad to hear feedback from engineers who already went through such a transition btw!

Regards,

Francois

j.samanta · ‎06-18-2006

Hello !

j.samanta · ‎06-18-2006

Hi! Francois,

Sorry for disturbing you once again. I was simulating the MSTP environment in my Lab ... I observed that whenever I map any new vlan to any existing instance the switch stops all communication in all vlans for few seconds. On debug I observed that all the instances are getting deleted and getting re-created. And by that process all the ports are going into disabled state. Is it becoz .... by adding additional vlan to an instance I am actually creating a separate MST region for this switch alone? But even then I am not able to understand what is the need for deleting all the instances?

I am attaching the log with this message, pls refer to the same.

Will be waiting for your comment.

Anybody else faced similar issue? Any related comments are appreciated.

SW-1(config-mst)#instance 2 vlan 15

SW-1(config-mst)#exit

SW-1(config)#

Jun 8 14:02:30.274 UTC: MSTP(2): Fa0/11 State change forwarding -> disabled

Jun 8 14:02:30.274 UTC: MSTP(2): Fa0/13 State change forwarding -> disabled

Jun 8 14:02:30.274 UTC: MSTP(2): Fa0/21 State change forwarding -> disabled

Jun 8 14:02:30.274 UTC: MSTP(2): Fa0/23 State change forwarding -> disabled

Jun 8 14:02:30.274 UTC: MSTP(2): Fa0/24 State change forwarding -> disabled

Jun 8 14:02:30.274 UTC: MST(2): disabled

Jun 8 14:02:30.274 UTC: MST[2] Instance deleted

Jun 8 14:02:30.274 UTC: MSTP(1): Fa0/21 State change forwarding -> disabled

Jun 8 14:02:30.274 UTC: MSTP(1): Fa0/23 State change forwarding -> disabled

Jun 8 14:02:30.274 UTC: MSTP(1): Fa0/24 State change forwarding -> disabled

Jun 8 14:02:30.274 UTC: MST(1): disabled

Jun 8 14:02:30.274 UTC: MST[1] Instance deleted

Jun 8 14:02:30.274 UTC: MSTP(0): Fa0/11 State change forwarding -> disabled

Jun 8 14:02:30.274 UTC: MSTP(0): Fa0/13 State change forwarding -> disabled

Jun 8 14:02:30.274 UTC: MSTP(0): Fa0/21 State change forwarding -> disabled

Jun 8 14:02:30.274 UTC: MSTP(0): Fa0/23 State change forwarding -> disabled

Jun 8 14:02:30.274 UTC: MSTP(0): Fa0/24 State change forwarding -> disabled

Jun 8 14:02:30.274 UTC: MST(0): disabled

Jun 8 14:02:30.274 UTC: MST[0] Instance deleted

Jun 8 14:02:31.280 UTC: MST(0): Initialization

Jun 8 14:02:31.280 UTC: MST(1): Initialization

Jun 8 14:02:31.280 UTC: MSTP: created IST port for 2307590

Jun 8 14:02:31.280 UTC: MSTP(0): Fa0/21 State change disabled -> blocking

Jun 8 14:02:31.280 UTC: MSTP(1): Fa0/21 State change disabled -> blocking

Jun 8 14:02:31.280 UTC: MSTP: created IST port for 230A860

Jun 8 14:02:31.280 UTC: MSTP(0): Fa0/23 State change disabled -> blocking

Jun 8 14:02:31.280 UTC: MSTP(1): Fa0/23 State change disabled -> blocking

Jun 8 14:02:31.280 UTC: MSTP: created IST port for 230C1C8

Jun 8 14:02:31.280 UTC: MSTP(0): Fa0/24 State change disabled -> blocking

Jun 8 14:02:31.280 UTC: MSTP(1): Fa0/24 State change disabled -> blocking

Jun 8 14:02:31.280 UTC: MST(2): Initialization

Jun 8 14:02:31.280 UTC: MSTP(2): Fa0/21 State change disabled -> blocking

Jun 8 14:02:31.280 UTC: MSTP(2): Fa0/23 State change disabled -> blocking

Jun 8 14:02:31.280 UTC: MSTP(2): Fa0/24 State change disabled -> blocking

Jun 8 14:02:31.297 UTC: MSTP: created IST port for 22F7550

Jun 8 14:02:31.297 UTC: MSTP(0): Fa0/11 State change disabled -> blocking

Jun 8 14:02:31.297 UTC: MSTP(0): Fa0/11 State change blocking -> forwarding

Jun 8 14:02:31.297 UTC: MSTP(2): Fa0/11 State change disabled -> blocking

Jun 8 14:02:31.297 UTC: MSTP(2): Fa0/11 State change blocking -> forwarding

Jun 8 14:02:31.297 UTC: MSTP: created IST port for 22FA820

Thanks & Regards,

Jyotirmay.

Francois Tallet · ‎06-18-2006

Hi Jyotirmay,

What you are seeing is expected. As you guessed, changing the vlan to instance mapping also changes the MST configuration. As a result, the ports must be blocked and go through a phase of re-negotiation with their neighbor. The simplest way we found to implement this required stage was to simply restart STP. So we simulate all ports going down and back up again (of course, the link does not flap, it's purely a software thing).

Regards,

Francois

john.graue · ‎09-15-2006

I am actually working in a TELCO planning the MetroEthernet and it is already deployed. We have a problem at the begining because there was two kinds of MST developed. MST Pre-Standard and MST Standard. The "big" Switches supported MST Std but the CPEs dont and that was the reason that lead us to deploy MST std in the backbone and RSTP in the CPEs rings. At this time CPEs like ME-3400 supoort MST Std so we are planning the migration to MST Std in the CPEs rings. For that, we are going to have one MST Region in the Core and 1 region per ring.

Well thats my expierence, hope someone get help.

Asks are welcome.

John.