上集提到了RSTP大致的概念，本偏要介紹一些關於應用方面的部分，以及更細節的protocol行為與參數。

Recover的拓樸是否有大小的限制?

在RSTP中有個參數為Max age，最大上限為40，這個參數會限制了整體redundant拓樸的大小，直接參考下圖，以線性舉例最大只能到41台。

Recovery time會是多少呢?

具體來說這個protocol沒有直接宣稱它的recovery time應該要為多少，只是它有限制這些最大拓樸的大小，因此要看你所使用的device它的CPU效能，會影響它的收斂時間，但普遍的來說應該是接近秒等級。

RSTP如何跟STP及MTSP相容?

RSTP與STP相接的該台device就會與其進行相容的運作，因此與RSTP的recovery time仍為秒等級，但與STP的recovery time為30~50秒，因為STP會有forward delay。

與STP相容時

RSTP與MSTP相接的時MSTP透過設定可以使該region算為1台RSTP的device

與MSTP相容

RSTP Edge port 與 Link Type

在RSTP中有個參數為link type，這個參數可以直接設定或設透過Auto的方式。

當link type為auto時，則它會去檢查現在的Switch是全雙工還是半雙工，若為半雙工，就會使用MaxAge time此值預設為30秒，若為全雙工則為Migrate time此值預設為3秒。

這會影響你的Switch剛接上一台新的device時，該port的狀態從blocking轉為forwarding的時間。

當然如果直接將link type設為false時就能強制使接上新device都等30秒才能通。

而強制設為ture則是3秒，不過現在大多都會直接auto nego然後全雙工，因此不太需要特別將該參數給維ture。

RSTP為何可以比STP更快收斂?

在RSTP中為了加速recovery time的時間，因此制定出了一個機制稱為
PA handShake，運作方式為透過每一台device，相互往對接的device丟出proposal的封包，而彼此收到封包後，會相互比較封包內容的參數，比較完較差的一方，就會回傳agreement，因此每一台都快速的與相鄰的device做選舉的機制，加速了整體拓樸的收斂時間。

BPDU持續傳送可以有什麼用途?

當選完後出現Root後，所有的device的destination port還是會定期的根據Hello time繼續傳送BPDU的封包，透過這些BPDU，接收的device每次都會去比較參數，若有發生變化，port role也可以適時的轉換。

當發送BPDU的機器發生異常時，它沒有辦法再丟出BPDU，它相鄰的device會等待3次的hello time，若還未收到就會進行topology change，透過這個機制預防相鄰的機器可能因異常關機，或是異常不轉送封包，趕緊更換新的path來recover整體的拓樸，使封包能藉由新的路徑送到目的端。

使用RSTP與其廠商自己定義的redundant protocol的優劣

優勢

1.相容性
如果你的環境是由多個不同廠牌的機器組成，你如果用各家自訂的redundant protocol通常是組不起來的，但多半的device要做到redundant最起碼有RSTP可以使用，因此他可以最低的確保整個拓樸有redundant protocol可用，且這個protocol也發展很久了，各廠商實作這個功能要讓其彼此相容應該不是困難的事情。

2.普及性
前面提到這個protocol很久了，因此中間負責傳送封包的device，甚至有一些2個port或以上的的end device都有可能支援這個protocol，因此也是許多案場在解決大家redundant protocol彼此不相容的常見解決辦法。

劣勢

1.Recovery time通常會輸給廠商自己出的redundant protocol
通常各廠家推出的redundant protocol主要都打著低回復時間，但這要看你的環境，如果你的環境禁不起1秒等級的回覆時間，那你可能真的必須使用各家廠商自己推出的redundant protocol。

2.各廠商建構出的一些自訂protocol的特殊用法，不一定會支援在RSTP
有可能各廠商，為了解決某些情境，因此它可以在開啟他們自訂的redundant protocol時，又能搭上他們自訂的protocol達到特殊情境的應用。

可能適合及不適合的場域

可能適合的場域: 商業大樓
有些商業大樓的IT機房就會設有這些設備，雖然是商業用但也會需要有這種備援的機制，因此也會需要使用redundant protocol，而在這種商業環境中，秒等級的回覆時間，很有可能是可以被接受的。

可能不適合的場域: 生產製造環境
很多的生產環境它的運行速度是非常快速的，因此他不太能接受recovery time過高的狀況，這個回覆時間可能會影響他的生產導致某些半成品需要報廢。

而有些製造環境可能更嚴格，甚至是需要做到0秒的等級(也就是它可能有辦法馬上備援或是傳送時他就送2份資訊在不同的路徑上，而這種場域也不適合使用這樣的protocol來處理，0秒的回覆的機制，也會有其他為該種環境所產生的相對應protocol來實現。

以上就是下集的分享了，希望我的分享可以幫助到你