Catalyst 4000 6000配置經驗談（四）

2019-11-04 23:23:09

字體：大中小

來源：轉載

供稿：網友

　　生成樹協議(STP)
　　基本含義
　　　　生成樹是一個交換網絡中檢測交消除冗余鏈路以防止出現二層循環的一個協議。假如不運行STP，幀有可能會在網絡中循環發送，流量極劇升高，最后使整個網絡徹底癱瘓。STP最初是一個較慢的基于軟件實現的一個橋接規范(IEEE802.1D)，現在已經是一個相當成熟的協議了，可以在一個具有多VLAN、大量交換機、多廠商的復雜環境中很好的實施。
　　
　　　　CatOS 6.x繼續進行一些新的STP的開發，如多實例生成樹(MISTP)、loop-guard、root-guards和 BPDU 到達時間檢測等，在CatOS7.x版本中，支持新的一些標準化協議，如分享生成樹(IEEE802.1S)和快速收斂生成樹(IEEE802.1w)等。
　　
　　運行機制
　　　　具有最低的橋ID(BID)的交換機每個VLAN的根橋(root bridge)，BID由橋優先級和交換機的MAC地址組成。
　　
　　　　最初，所有的交換出都將發出包括自己BID及到達自己的路徑代價(path cost)在內的橋接協議數據單元(BPDUs)，這樣就可以檢測出root bridge和到達root bridge的最小代價的路徑，從root bridge發出的BPDUs中包含的附加設置將覆蓋交換機的本地配置，這樣整個網絡就使用一個一致的時鐘。
　　
　　　　網絡拓樸將按照下述步驟進行收斂：
　　
　　在整個生成樹域中選舉出一個唯一的root bridge；
　　
　　在每個非root bridge的交換機上選舉出一個root端口(面向root bridge)；
　　
　　在每一段中選舉出一個designated端口用于轉發BPDU；
　　
　　非designated端口切換到block狀態。
　　　

　　在生成對中有兩種BPDUs：用于配置的BPDUs和拓樸變化提示(TCN)BPDUs.
　　
　　用于配置的BPDU流量
　　　　用于配置的BPDUs每隔一個hello間隔從Root Bridge的所有端口發到葉交換機上面，用于維護整個生成樹的狀態。在穩定狀態，BPDU流量是單向的，Root端口和blocking端口僅接收用于配置的BPDUs，而指定端口只發送用于配置的BPDUs.
　　
　　　　假如Root Bridge失效或所有連接到Root Bridge的鏈路都失效了，在Maxage計時器超時后重新進行選舉。
　　
　　拓樸變化提示(TCN)BPDUs流
　　　　拓樸變化提示BPDUs在檢測到生成樹的拓樸發生改變時由葉交換發到Root Bridge，Root端口只發送TCNs，而指定端口只接收TCNs.
　　
　　　　TCN BPDU在發向Root Bridge中的每一步都被確認，這是一個可靠的機制，一旦到達Root Bridge，Root Bridge將通過一個將TCN標記設置為Maxage+Fwddely(缺省為35秒)的用于配置的BPDU向整個生成樹域宣告這個拓樸變化的發生，使所有的交換機將它們的CAM老化計時器從5分鐘(缺省的)修改為Fwddelay(缺省為15秒)所規定的時間間隔。
　　
　　生成樹模式
　　　　VLAN和生成樹之間的關聯有如下幾種模式：
　　
　　所有VLAN使用同一個生成樹，稱為Mono生成樹，如IEEE802.1Q
　　
　　每個VLAN一個生成樹，或叫做分離生成樹，如Cisco PVST。
　　
　　幾個VLAN一個生成樹，或稱為多生成樹，如Cisco MISTP、IEEE802.1s等。
　　
　　　　所有VLAN使用同一個生成樹的模式只有一個活動的拓樸，無法進行負載均衡，一個STP blocked端口將對所有的VLAN均為Blocked狀態，在所有的VLAN中都不轉發數據。
　　
　　　　每個VLAN一個生成樹的模式提供負載均衡功能，但在VLAN數目增長是會消耗更多的CPU處理能力用于處理BPDU。在CatOS的發行公告中提供單個交換機中能支持的生成樹個數的指導性意見，對于6000 SUP1的公式為：
　　
　　　　端口數 + (Trunk數 * Trunk上的VLAN的數目) < 4000
　　
　　　　Cisco MISTP和新的802.1s標準是一個發展方向，例如可以只定方兩個STP進程，將所有的VLAN映射到這個兩生成樹中，這個技術可以在啟用負載均衡的情況下支持到數千個VLAN。
　　
　　BPDU 格式
　　　　為了支持IEEE 802.1Q標準, Cisco將現有的STP實現擴展為以支持穿越802.1Q單生成樹域，這樣PVST+同時支持802.1Q的MST和Cisco的PVST，而不需要額外的命令或配置。另外, PVST+提供用于確認交換機之間的Trunking和VLAN IDs不會出現不一致的配置的驗證機制。
　　
　　　　運行PVST+協議有如下注重事項：
　　
　　PVST+通過在802.1Q trunk鏈路上的稱做通用生成樹(CST)的協議來實現和802.1Q MST的互操作。CST永遠運行在VLAN1上面，為了和其它廠商的設備實現互操作，VLAN1在鏈路上應該存活。CST BPDUs是透明傳輸的，不打標記，發送到IEEE標準橋組地址(MAC地址01-80-c2-00-00-00, DSAP 42, SSAP 42). 為了描述的完整性，一組BPDUs被并行地發送到VLAN1上的Cisco分享生成樹的MAC地址
　　
　　PVST+將PVST BPDUs以組播數據的形式穿越802.1Q VLAN域. Trunk上每個VLAN中Cisco's分享生成樹BPDUs被發送到MAC 地址01-00-0c-cc-cc-cd (SNAP HDLC協議類型0x010b)，Native VLAN上的BPDUs不做標記，其它所有VLAN中的BPDUs將打上相應的標記。
　　
　　PVST+檢查端口和VLAN的沖突，PVST+阻塞收到不一致的BPDU的端口以避免出現循環，也通過syslog信息提示檢測到的任何錯誤配置。
　　
　　PVST+在運行在ISL trunk上的PVST提供后向的兼容，ISL封裝的同樣通過IEEE MAC進行接收和發送，換句話說，每個BPDU的類型都是針對一個鏈路的，不存在轉換的說法。
　　
　　建議
　　　　所有的交換機在缺省狀態下都是啟用了STP的，就算在不存在二層循環的情況下仍然推薦使用。因為如下原因，Cisco建議啟用STP：
　　
　　假如出現了循環(包括插錯了線、電纜有問題等), STP可以防止由于組播和廣播所引起的網絡破壞。
　　
　　保護EtherChannel不中斷。
　　
　　絕大多數網絡配置了STP，最大限度地提高網絡的透明度，越透明就意味著越穩定。
　　
　　避免雙網卡的誤操作或服務器啟用了橋接所導致的嚴重后果；
　　
　　許多協議(如PAgP、IGMP snooping和trunking)的軟件都和STP緊密相關，所以不運行STP將引起一些不必要的麻煩。
　　
　　　　不要改變計時器，這可能會影響網絡的穩定性。在絕大多數網絡布署中都沒有修改計時器，因為雖然可以很方便地通過命令行進行修改，但很難周全地考慮修改后所引起的各個可能的變化。
　　
　　　　在理想狀態下，不應該上用戶數據在治理VLAN上傳送，非凡是在老的Catalyst交換機處理器的尾部　下，最好將用戶數據和治理VLAN相分離以避免STP出現問題，一個有問題的工作問可以使用超級引擎疲于處理廣播包而無法處理BPDU。
　　
　　　　不要設計過量的冗余，這會造成故障診斷的惡夢－－太多的blocking端口將嚴重影響網絡的穩定性。保持整個STP直徑在七跳以內，條件答應的情況下，在設計中使用多層模塊，減小交換域和，使用確定的blocked端口。
　　
　　　　手工設計Root特性和Blocked端口，并在拓樸圖上明確標注，STP的故障診斷往往從blocked端口開始，使Block端口從blocking狀態切換到轉發狀態是診斷過程中的一個要害組成部分，選擇分布層或核心層交換機做為Root/Secondary Root Bridge，因為這是整個網絡中最為穩定的，使用最優化的第三層和HSRP來覆蓋每二層數據轉發路徑，可以使用下述宏命令將交換機設置為Root或secondary root：
　　
　　set spantree root
　　　　注重：這個宏命令將交換機的優先級設置為8192(缺省狀態下)、當前root優先級減1(假如存在另一個root bridge)或當前root優先級(交換機Mac地址比當前Root Bridge小)。
　　
　　　　在Trunk端口上清楚不需要的VLAN，(需要進行雙向配置)，這可以限制STP的范圍并減輕NMP的處理負擔， VTP的自動修剪不會將這些VLAN從STP計算中移除。從CatOS5.4開始，VLAN1同樣可以從Trunk鏈路上修剪掉。
　　
　　其它選項
　　　　Cisco還有一個叫做VLAN-Bridge的STP協議，它使用01-00-0c-cd-cd-ce的目標MAC地址，協議類型為0x010c.
　　
　　　　當需要在VLAN間橋接不可路由的信息或使用一些無法和IEEE生成樹無法協同工作的傳統協議時這是一個相當有用的功能。假如VLAN間的橋接因為第二層被阻塞時，第三層的流量同樣會出被阻塞掉，這是一個不希望發生的副作用，這時使用VLAN-bridge就可以創建一個獨立于STP的單獨的實例，提供一個單獨的拓樸，這樣就可以不會影響到第三層的ip流量。
　　
　　　　Cisco建議在需要在如MSFC之類的路由器上VLAN之間做橋接時使用VLAN-bridge。
　　
　　PortFast
　　　　PortFast用于在訪問層端口上跳過正常的生成樹操作，加快終端工作站接入到網絡中的速度，在一些如IPX/SPX中，需要工作站一接入網絡就立即轉發數據以避免出現GNS的問題。
　　
　　運行機制
　　　　當一臺主機接入到網絡時，PortFast跳過了STP正常的listening和learning狀態，直接從blocking狀態進入到轉發狀態，假如沒有啟用這個特性，STP在它認為端口可以進入轉發狀態前將拋棄所有的用戶數據包，這會用到兩個ForwardDelay計時器(在缺省情況下是30秒)。
　　
　　　　PortFast模式也避免了端口狀態改變發出STP TCN后需要眾learning狀態到forwarding狀態的轉變。STP PortFast在Catalyst 5000多層交換網絡和Multicast CGMP中都相當重要，這些環境中的TCNs可能會引起CGMP CAM表超時。結果就會丟失在下一個IGMP報前的組播包，也會引起多層交換Cache的清空，并增加router CPU的負擔。(對Catalyst 6000中的MLS實現沒有影響)
　　
　　建議
　　　　Cisco建議在所有接計算機端口上啟用portfast，在所有接交換機或未使用的端口上禁用portfast.
　　
　　　　在接計算機的端口上同樣應該禁用Trunking和Channeling，在缺省狀態下，每個訪問層端口都是啟用了Trunk和channeling的。假如任由這些協議的協商，將引起一些不希望發生的后或，如DHCP請求不被發送等。使用如下宏命令達到上述要求：
　　
　　　　set port host
　　
　　　　該命令是如下三個命令的集合：
　　　　set spantree portfast enable
　　　　set trunk off
　　　　set port channel mode off
　　
　　
　　　　注重:PortFast并不意味著生成樹協議在這些端口上完全不運行了，實際上BPDU仍然在發送、接收并處理。
　　
　　其它選項
　　　　PortFast BPDU-Guard提供了一個防止循環的機制，在一個Portfast端口上收至BPDU時，將會把該端口設置為errdisable狀態。
　　
　　　　在一個接入層端口上應該不會收到BPDU包，因為這些端口不是接在交換機上面。一但在這上面收到了BPDU包，就說明出現非常危險的錯誤配置，需要治理員及時采取行動。當啟用BPDU-Guard特性后，生成樹協議將關閉portfast配置，并將這些端口設置為生成樹Blocking狀態。
　　
　　　　使用如下命令進行配置：
　　
　　set spantree portfast bpdu-guard enable
　　
　　
　　　　可以使用SNMP trap或syslog消息通知治理員這個端口down了，也可以為ErrDisabled的端口配置一個自動恢復時間。
　　
　　　　注重：從CatOS7.x版本開始提供Trunk端口上的PortFast特性，Trunk口上的Port特性用于加快第三層網絡的收斂，為了實現這個特性，CatOS7.x也提供了每端中的PortFast BPDU-Guard配置命令。
　　
　　UplinkFast
　　　　UplinkFast在接入層提供了一個在出現直接鏈路失效時的STP快速收斂功能。它不需要改變STP協議，就可以在非凡環境中將收斂時間從30秒減少到3秒
　　
　　運行機制
　　　　在接入層使用Cisco的多層交換模型進行設計，假如轉發的上行鏈路出現了問題，則處于blocking狀態的上行鏈路可以直接轉換為轉發狀態，而不必經過listening和learning狀態。
　　
　　　　每個VLAN中的一個上行組由一個root端口和備份root端口組成，在通常情況下，root端中保證到root bridge的連接能，假如主"root-connection"因為任何原因而失效，備用root鏈路立即成為轉發狀態，而不必要經過傳統的30秒收斂延時。
　　
　　　　因為這個特性跳過了通常的STP拓樸收斂，在域中的交換機上一個候選的拓樸修正機制，以便能夠通過候選的鏈路到達本地終端工作端。這樣，運行UplinkFast的接入層交換機將會把它的CAM表的每一個MAC地址放到一個多播幀中傳送到01-00-0c-cd-cd-cd( HDLC 協議類型0x200a)，用于更新域中其它交換機的CAM表。
　　
　　建議
　　　　Cisco建議在有block端口的交換機上啟用UlinkFast，典型的就是接入層交換機，不要在沒分布層或核心層交換機上使用uplinkfast，使用如下命令:
　　
　　set spantree uplinkfast enable
　　
　　　　這個命令同時也會提高bridge優先級和port優先級以降低交換機成為root bridge和指定端口的風險。
　　
　　　　注重: 在啟用"PRotocol filtering"特性的情況下，需要使用 "all protocols"要害字，因為CAM表中會和MAC、VLAN信息一樣記錄協議類型。UplinkFast需要產生每個MAC地址的每個協議，"rate"要害字指出每秒產生一個Uplink拓樸更新幀。
　　
　　Backbone Fast
　　　　Backbone Fast通過在STP協議上增加功能的方式提供間接失效環境下的快速收斂，典型地，收斂時間可以從缺省的50秒減少到30秒。
　　
　　運行機制
　　　　在一個root端口或blocked端口從它的指定bridge收到"inferior BPDUs"就進行初始化，這可能會在下級交換機在丟失它到root的接時并發出它自己的BPDUs的時候發生，inferior BPDU意味著交換機即是一個root bridge又是一個指定gridge。
　　
　　　　根據通常的生成樹規則，收到BPDU的交換機將根據配置的Maxage計時器(缺省為20秒)忽略該BPDU，然而在配置了backbone Fast的情況下，交換機在收到inferior BPDU時就認為拓樸可能發生了改變，并開始嘗試通過Root鏈路查詢(RLQ) BPDUs檢測是否存在一個通向root bridge的候選路徑，不管root是否可用，這個協議都答應交換機進行檢測，并以更少的時間將block端口切換為轉發狀態，并提示發出inferior BPDU的交換機root仍然可用。
　　
　　　　該協議應該注重如下事項：
　　
　　只在root端口上發送RLQ包。
　　
　　假如收到RLQ的交換機是root交換機或丟失了到root的連接，則這個交換機則會進行回復，假如它不知道這些情況，它必須從它的root端口轉發這些查詢。
　　
　　假如一個交換機丟失了到root的連接，它必須回答一個否定答案。
　　
　　只能在收到查詢的端口上發出答復
　　
　　Root交換機必須給一個肯定的答復
　　
　　丟棄在非Root端口上收到的答復
　　
　　　　這樣STP的收斂時間可以減少約20秒，因為不需要等待Maxage超時。
　　
　　建議
　　　　Cisco建議在所有支持STP的交換機上啟用Backbone Fast，它不會造成生產環境的中斷。使用如下命令配置Backbone Fast：
　　
　　set spantree backbonefast enable
　　
　　
　　　　注重：需要在域中的所有交換機上配置這條全局命令，這樣才能理解這個增加的特性。
　　
　　其它說明
　　　　2900xl和3500xl系列交換機不支持BackboneFast，在有這些交換機的環境中不能啟用Backbone Fast.在未來，IEEE 802.1w快速收斂STP將提供類似的功能，這樣就可以和其它廠商的設備進行互操作了。
　　
　　(未完，待續下一節：EtherChannel)

上一篇：Catalyst 2948G-L3 with QoS

下一篇：Cisco 3550的配置命令手冊-目錄