rapid-pvst向mstp遷移

Google 標籤: rapid-pvst, mstp, loopguard, 遷移

Rapid-pvst是cisco的私有協議，其特點如下：
1，每個vlan一個stp數，因此在vlan多的環境中會比較消耗CPU和MEMORY；
2，RPVST收斂快，視vlan數量而定。一般20-30個vlan的情況下，拓撲收斂會導致4-5個丟包；
3，RPVST內置uplinkfast和backbonefast；
4，RPVST兼容loopguard、rootguard等特性；
5，規劃配置簡單，後續vlan的變更不會影響全局交換網絡環境的收斂。

MSTP是通用標準，各網絡設備廠商都使用此標準。
其特點除了基本包含RPVST所有優點包括上述的後三點外，最重要的特點是：多個vlan可以映射到一個實例，可以從交換網絡中實際存在的stp拓撲來規劃實例。這樣針對多vlan的環境，很好的解決了CPU和MEMORY消耗情況以及收斂時間問題。
但是由於MSTP是基於域協商管理的，在整個域內各交換機必須保持三要素一致才能達到同步。三要素爲domain、reversion以及instance。因此交換網絡維護中需要新增vlan的情況下會導致MSTP域內的instance不一致的情況。通常MSTP規劃時需要做最長遠考慮，儘可能的避免後續vlan的變更導致異常。默認情況下，所有vlan都被映射在內部實例IST0中，不過最好儘可能的不要將業務數據vlan映射在IST0內。
常用的規劃配置如下：
spanning-tree mst configuration
  name xxx.xxx  
  revision 10  
  instance 1 vlan 2-1001  
  instance 2 vlan 1006-4094  
  exit  
spanning-tree mst 0-1 priority 24576
spanning-tree mst 2 priority 28672
spanning-tree mode mst

在做rapid-pvst向mstp遷移時，有以下注意點：
1，確保MSTP規劃考慮全面，儘可能避免後續新增vlan導致MSTP的收斂；
2，與其他stp共存時，確保所有vlan的root爲MST的IST實例；
3，確保任何vlan都開啓stp；
4，確保交換機互聯使用trunk模式；
5，遷移過程需要先將命令配置完成後才能啓用MST模式；
6，遷移過程可以先從分佈層即root層開始處理，然後再配置接入交換機；
7，遷移前關閉所有guard特性，如loopguard、rootguard等，這個非常重要；
8，遷移方案設計之前最好搭建模擬環境進行測試，以儘量避免不可預知的風險。

下面是本人在一個配置了loopguard特性的交換環境中做遷移的試驗情況：

在沒有配置loopguard的情況下的debug span events：

2924#sh log

00:48:47: RSTP(1): updt roles, superior bpdu on Fa0/1 (synced=0)

00:48:47: RSTP(1): synced Fa0/1

00:48:47: RSTP(1): transmitting an agreement on Fa0/1 as a response to a proposal

//在root層遷移過程中，2924的vlan1接收到了2948的vlan1的bpdu信息。

00:48:50: RSTP(19): Fa0/1 rcvd info expired

00:48:50: RSTP(19): updt roles, information on root port Fa0/1 expired

00:48:50: RSTP(19): we become the root bridge

00:48:50: RSTP(19): Fa0/1 is now designated

//在root層遷移過程中，2924的vlan19接收不到2948的vlan19的bpdu信息，所以自認爲root bridge。後面的vlan20和21同樣如此。

00:48:50: RSTP(20): Fa0/1 rcvd info expired

00:48:50: RSTP(20): updt roles, information on root port Fa0/1 expired

00:48:50: RSTP(20): we become the root bridge

00:48:50: RSTP(20): Fa0/1 is now designated

00:48:50: RSTP(21): Fa0/1 rcvd info expired

00:48:50: RSTP(21): updt roles, information on root port Fa0/1 expired

00:48:50: RSTP(21): we become the root bridge

00:48:50: RSTP(21): Fa0/1 is now designated

00:48:52: RSTP(19): updt roles, superior bpdu on Fa0/1 (synced=0)

00:48:52: RSTP(19): Fa0/1 is now root port

//這裏表明2924的vlan19接收到2948的vlan19的bpdu信息並將Fa0/1協商成RP，後續的vlan20和21同樣如此。這個協商過程在2s內完成。Root層在接收到接入層2924的bpdu後識別其處於PVST模式，所以其mst向pvst兼容，並分vlan傳遞bpdu包。

00:48:52: RSTP(20): updt roles, superior bpdu on Fa0/1 (synced=0)

00:48:52: RSTP(20): Fa0/1 is now root port

00:48:52: RSTP(21): updt roles, superior bpdu on Fa0/1 (synced=0)

00:48:52: RSTP(21): Fa0/1 is now root port

00:48:54: RSTP(19): Fa0/1 received a tc ack

00:48:54: RSTP(20): Fa0/1 received a tc ack

00:48:54: RSTP(21): Fa0/1 received a tc ack

2924#

在配置了loopguard的情況下的debug span events：

2924#sh log

00:54:50: RSTP(1): updt roles, superior bpdu on Fa0/1 (synced=0)

00:54:50: RSTP(1): synced Fa0/1

00:54:50: RSTP(1): transmitting an agreement on Fa0/1 as a response to a proposal

00:54:54: RSTP(19): Fa0/1 rcvd info expired

00:54:54: %SPANTREE-2-LOOPGUARD_BLOCK: Loop guard blocking port FastEthernet0/1 on VLAN0019.

00:54:54: RSTP(19): updt roles, information on root port Fa0/1 expired

00:54:54: RSTP(19): we become the root bridge

00:54:54: RSTP(19): Fa0/1 is now designated

00:54:54: RSTP(20): Fa0/1 rcvd info expired

00:54:54: RSTP(20): updt roles, information on root port Fa0/1 expired

00:54:54: RSTP(20): we become the root bridge

00:54:54: RSTP(20): Fa0/1 is now designated

00:54:54: RSTP(21): Fa0/1 rcvd info expired

00:54:54: RSTP(21): updt roles, information on root port Fa0/1 expired

00:54:54: RSTP(21): we become the root bridge

00:54:54: RSTP(21): Fa0/1 is now designated

//可以看出2924在後續接收到2948的各vlan的bpdu之前就被LOOPGUARD_BLOCK擋住了。

繼續分析如下：
Assume that we have a c3560 switch which we call it Switch-A and a c2960 switch called Switch-B.

1. In the normal way, if you don't configure loop guard on the interface of B, before change the RSTP to MST, A will send a BPDU to B every two seconds per VLAN. When we configure A with MST, A will send a new MST BPDU with Vlan1 which is native Vlan to B, but actually only Vlan1 can receive this BPDU, and after 6 seconds the other Vlans don't receive the BPDU, then the other Vlans will think the time is expired and all of the Vlans on B except Vlan1 will become the designated ports. So B is the root bridge of RSTP. Then B sends BPDUs to A with the designated ports, when A receives the BPDUs, it will detect that B is running RSTP, so the interface should be boundary port, and it should send out BPDUs per Vlan so both of the two switch can communicate with each other with all of the configured Vlans.

   When the Vlans receive BPDUs from A again, they will found that the priority of A is higher and they are superior BPDUs, then they will change their roles to root ports. Then everything is working as expected now!!

2. If we configured loop guard on the interface of B, so when B found that it misses 3 BPDUs which is expected to receive from A, then it blocks all Vlans whose role is expired. So only Vlan1 is forwarding because it can receive BPDU. Then here is our problem, Vlan1 is root port, so it would not send BPDU to A, and the other Vlans are blocked so they wouldn't send BPDU to A either, so A will never find that the other end is running RSTP, so it would not treat the interface as boundary port, nor send BPDU per Vlan. Then Vlans of B except vlan1 will keep the status of inconsistent.

So what we must do before change RSTP to MST is remove the loop guard on the interfaces, or shut/no shut the physical interface after the Vlans are blocked.

By the way, here is the Bug ID:CSCtb67958 as bellow. I thinks this is not a real bug because this is the mechanism issue between STP negotiation and loop guard.