以太網(wǎng)存儲(chǔ)網(wǎng)絡(luò)的擁塞管理連載案例（六）

消除或減少無(wú)損以太網(wǎng)網(wǎng)絡(luò)擁塞的高級(jí)方法與光纖通道結(jié)構(gòu)相同。幾十年來(lái)，不同的傳輸類型都采用了類似的方法，只是略有不同。第6 章已詳細(xì)介紹了在光纖通道Fabric 中防止擁塞的方法。由于逐跳流量控制在兩種網(wǎng)絡(luò)中都會(huì)導(dǎo)致?lián)砣麛U(kuò)散，因此盡管在實(shí)現(xiàn)上存在差異，但相同的概念也適用于無(wú)損以太網(wǎng)網(wǎng)絡(luò)。

Eliminating or Reducing Congestion — An Overview

回想一下，"罪魁禍?zhǔn)?是指造成存儲(chǔ)網(wǎng)絡(luò)擁塞的任何設(shè)備。受害者是受網(wǎng)絡(luò)擁塞不利影響的任何設(shè)備。

為了讓存儲(chǔ)網(wǎng)絡(luò)在發(fā)生擁塞時(shí)自動(dòng)消除或減少擁塞，以下是高級(jí)方法：

斷開(kāi)故障設(shè)備：斷開(kāi)慢速設(shè)備的連接可消除擁塞源，從而恢復(fù)網(wǎng)絡(luò)擁塞。這通常需要監(jiān)控來(lái)自終端設(shè)備的入口暫停幀，并在邊緣交換端口長(zhǎng)時(shí)間（如幾百毫秒）無(wú)法傳輸時(shí)禁用（或關(guān)閉）該端口。目前，許多生產(chǎn)網(wǎng)絡(luò)都采用這種方法，但這是一種"大錘"方法，因?yàn)閿嚅_(kāi)連接的設(shè)備無(wú)法實(shí)現(xiàn)其目的，也無(wú)法對(duì)其進(jìn)行監(jiān)控以了解問(wèn)題是否繼續(xù)存在。請(qǐng)參閱第6 章"通過(guò)斷開(kāi)罪魁禍?zhǔn)自O(shè)備的連接來(lái)恢復(fù)擁塞"一節(jié)，了解更多注意事項(xiàng)以及必要時(shí)如何斷開(kāi)連接。

提前丟棄幀：丟棄幀可釋放緩沖區(qū)，使其可重新使用，從而恢復(fù)擁塞狀態(tài)。后面的章節(jié)將使用Cisco Nexus 9000 交換機(jī)上的暫停幀超時(shí)和PFC 看門(mén)狗功能解釋這種方法。

流量隔離：將流向罪魁禍?zhǔn)自O(shè)備的流量與其他流量隔離，可以避免擁塞對(duì)其他設(shè)備的影響?？梢酝ㄟ^(guò)創(chuàng)建多個(gè)VLAN 并將ISL 專用于VLAN 來(lái)隔離流量。另一種方法是創(chuàng)建多個(gè)無(wú)損類，并將流量分配給不同的類。在撰寫(xiě)本文時(shí)，這些方法在無(wú)損以太網(wǎng)網(wǎng)絡(luò)中的使用情況尚不清楚。如果您想在無(wú)損以太網(wǎng)網(wǎng)絡(luò)中嘗試使用類似方法，請(qǐng)參閱第6 章"流量隔離"一節(jié)，了解更多詳情。

通知終端設(shè)備擁塞情況：向終端設(shè)備發(fā)出擁塞通知可使其采取預(yù)防措施，如降低流量速率。本章將介紹在路由無(wú)損以太網(wǎng)網(wǎng)絡(luò)上使用顯式擁塞通知(ECN) 進(jìn)行RoCEv2 擁塞管理(RCM)。IEEE 802.1Qau 標(biāo)準(zhǔn)化了第2 層域內(nèi)的類似方法，后來(lái)又將其納入IEEE 802.1Q。這種方法在RoCEv1（非路由）和FCoE 網(wǎng)絡(luò)中可能很有用，但在撰寫(xiě)本文時(shí)，這種方法的實(shí)施并不常見(jiàn)，而且在未來(lái)發(fā)展的可能性也很小。因此，本章不對(duì)第2 層域內(nèi)的IEEE 802.1Qau 擁塞通知進(jìn)行解釋。

限制流向擁塞設(shè)備的流量：限制流向慢速設(shè)備或過(guò)度使用鏈路的流量可以消除擁塞。

可在終端設(shè)備上配置流量速率限制器。在撰寫(xiě)本文時(shí)，這種方法在無(wú)損以太網(wǎng)網(wǎng)絡(luò)中的應(yīng)用尚不清楚。當(dāng)有了這種實(shí)施方法后，第6 章"在存儲(chǔ)陣列上使用速率限制器防止擁塞"一節(jié)中的詳細(xì)信息也將適用于無(wú)損以太網(wǎng)網(wǎng)絡(luò)。

另外，網(wǎng)絡(luò)交換機(jī)還可以檢測(cè)擁塞情況，并動(dòng)態(tài)調(diào)整流量速率，使其適應(yīng)擁塞設(shè)備。Cisco MDS 交換機(jī)使用這種動(dòng)態(tài)入口速率限制（DIRL）方法來(lái)防止光纖通道結(jié)構(gòu)中的擁塞。雖然從理論上講，DIRL 也可以在無(wú)損以太網(wǎng)網(wǎng)絡(luò)中使用，但在本文撰寫(xiě)時(shí)還沒(méi)有實(shí)現(xiàn)。有關(guān)詳細(xì)信息，請(qǐng)參閱第6 章"使用動(dòng)態(tài)入口速率限制防止擁塞"一節(jié)。

重新設(shè)計(jì)網(wǎng)絡(luò)：重新設(shè)計(jì)網(wǎng)絡(luò)可以消除或降低擁塞的嚴(yán)重程度或蔓延范圍。例如，將擁有數(shù)千臺(tái)設(shè)備的大型網(wǎng)絡(luò)轉(zhuǎn)換為較小的網(wǎng)絡(luò)孤島，可限制故障設(shè)備僅在孤島內(nèi)產(chǎn)生影響。有關(guān)詳細(xì)信息，請(qǐng)參閱第6 章"網(wǎng)絡(luò)設(shè)計(jì)注意事項(xiàng)"部分。

升級(jí)：很多時(shí)候，升級(jí)故障設(shè)備是解決擁塞的最終辦法。例如，當(dāng)鏈路使用率很高（可能因使用率過(guò)高而導(dǎo)致?lián)砣r(shí)，最終的解決方案是提高鏈路速度或增加額外的鏈路。詳情請(qǐng)參閱第6 章"鏈路容量"一節(jié)。

Congestion Recovery by Dropping Frames

在擁塞期間，幀在交換機(jī)中停留的時(shí)間比典型的端口到端口交換延遲時(shí)間要長(zhǎng)得多。當(dāng)故障設(shè)備長(zhǎng)時(shí)間無(wú)法接收幀時(shí)，與其讓幀永遠(yuǎn)停留在交換機(jī)內(nèi)，不如在超時(shí)后丟棄幀。丟棄這些幀后，緩沖區(qū)就可以重新使用，從而有助于從擁塞中恢復(fù)。丟棄這些幀至少有兩種方法。

Dropping Frames Based on their Age in the Switch

使用這種方法進(jìn)行擁塞恢復(fù)時(shí)，如果幀在超時(shí)持續(xù)時(shí)間內(nèi)沒(méi)有離開(kāi)出口端口，交換機(jī)就會(huì)丟棄該幀。

Cisco MDS 交換機(jī)的FCoE 端口可采用這種方法?？梢允褂肕DS NX-OS 命令system timeout fcoe pause-drop 進(jìn)行配置。這與光纖通道端口的擁塞-中斷超時(shí)類似。有關(guān)其優(yōu)缺點(diǎn)，請(qǐng)參閱第6 章"根據(jù)幀在交換機(jī)中的時(shí)間丟棄幀"一節(jié)。

Dropping the Frames based on Slow-Drain on an Edge Port

使用這種方法進(jìn)行擁塞恢復(fù)時(shí)，交換機(jī)會(huì)丟棄發(fā)送到慢速設(shè)備的幀。通常，這種方法需要監(jiān)控邊緣交換端口因接收到連接設(shè)備的暫停幀而無(wú)法傳輸?shù)某掷m(xù)時(shí)間。如果該持續(xù)時(shí)間超過(guò)超時(shí)時(shí)間，則會(huì)丟棄前往該設(shè)備的幀。當(dāng)幀被丟棄時(shí)，緩沖區(qū)利用率最終會(huì)低于接收流量的端口的恢復(fù)閾值，這些流量將從與慢耗設(shè)備相連的端口發(fā)送出去。因此，交換機(jī)會(huì)停止向上游直接連接的設(shè)備發(fā)送暫停幀，允許其開(kāi)始傳輸。罪魁禍?zhǔn)自O(shè)備的流量可能仍然會(huì)被丟棄，但受害者可能會(huì)從中受益。

從理論上講，這種方法類似于Cisco MDS 交換機(jī)上光纖通道端口的無(wú)credit-drop 超時(shí)功能。有關(guān)受害設(shè)備如何從中受益的詳細(xì)解釋，請(qǐng)參閱第6 章"基于邊緣端口的慢排空丟棄幀"一節(jié)。本節(jié)不再重復(fù)所有這些細(xì)節(jié)。

無(wú)損以太網(wǎng)交換機(jī)上丟棄幀的實(shí)現(xiàn)方式（何時(shí)開(kāi)始丟棄、何時(shí)停止丟棄以及粒度）各不相同。本節(jié)將介紹基于這種方法的兩種實(shí)現(xiàn)方式。

1. 暫停超時(shí)：針對(duì)FCoE 流量。

2. PFC 看門(mén)狗：主要針對(duì)RoCEv2 流量，但任何無(wú)損以太網(wǎng)流量（包括FCoE）都可能從中受益。

Pause Timeout

使用暫停超時(shí)功能，如果端口在超時(shí)時(shí)間內(nèi)因接收到暫停幀而無(wú)法傳輸，則會(huì)丟棄所有出口流量。此外，只要該端口一直處于Rx 暫停狀態(tài)，交換機(jī)上其他端口上所有新到達(dá)的、注定要從該端口出去的幀都會(huì)被立即丟棄。如前所述，丟棄邊緣端口上的罪魁禍?zhǔn)琢髁靠勺屔嫌卧O(shè)備開(kāi)始傳輸，從而使受害設(shè)備擺脫擁塞影響。

請(qǐng)注意以下幾點(diǎn)：

1. 在撰寫(xiě)本文時(shí)，暫停超時(shí)僅適用于思科交換機(jī)上的FCoE 端口，但在不同平臺(tái)上的實(shí)施有所不同，下文將對(duì)此進(jìn)行說(shuō)明。

2.盡管使用了PFC，但暫停超時(shí)功能會(huì)丟棄端口上的所有流量，而不僅僅是FCoE 使用的無(wú)損類中的流量。如果端口專門(mén)用于無(wú)損類流量，如Cisco MDS 交換機(jī)上的FCoE 端口，那么這種行為是可以接受的。但如果端口承載的流量屬于無(wú)損類和其他類，則這種行為可能不可接受。

該功能的具體實(shí)現(xiàn)可能因交換機(jī)類型而異。例如：

1. Cisco MDS 交換機(jī)：對(duì)于Cisco MDS 交換機(jī)上的FCoE 端口，該功能稱為Pause-Drop超時(shí)，默認(rèn)為500 ms。如有需要，可使用MDS NX-OS 命令system timeout fcoe pause-drop 進(jìn)行更改。

2. Cisco Nexus 交換機(jī)：對(duì)于Cisco Nexus 交換機(jī)上的FCoE 端口，該功能稱為"暫停超時(shí)"，默認(rèn)情況下已禁用。使用NX-OS 命令系統(tǒng)默認(rèn)接口暫停模式邊緣啟用時(shí)，超時(shí)值為500ms?？梢允褂妹顂ystem default interface pause timeout mode edge 在100ms 至500ms 之間以100ms 為增量更改超時(shí)值。

3. 思科UCS：在Cisco UCS 服務(wù)器中，可通過(guò)慢耗計(jì)時(shí)器啟用此功能。默認(rèn)超時(shí)值為500 毫秒，可在100 毫秒至1000 毫秒之間以100 毫秒為增量進(jìn)行自定義。在早期版本的Cisco UCS Manager 中，該功能默認(rèn)啟用500 毫秒超時(shí)值。后續(xù)版本默認(rèn)禁用此功能并啟用PFC 看門(mén)狗。有關(guān)詳細(xì)信息，請(qǐng)參閱Cisco UCS Manager 發(fā)行說(shuō)明。

PFC Watchdog

PFC 進(jìn)程看門(mén)狗的工作原理與暫停超時(shí)類似，但它只會(huì)丟棄隊(duì)列中因收到PFC 暫停幀而無(wú)法在超時(shí)時(shí)間內(nèi)連續(xù)傳輸?shù)牧髁俊?/p>

根據(jù)實(shí)施情況，PFC 看門(mén)狗可觸發(fā)以下操作：

1. 端口翻轉(zhuǎn)或關(guān)閉：當(dāng)檢測(cè)到隊(duì)列上存在PFC 進(jìn)程看門(mén)狗時(shí)，端口將被翻轉(zhuǎn)或關(guān)閉，從而影響該端口上的所有流量類別。這與暫停超時(shí)功能的作用相同。有人稱其為破壞性看門(mén)狗。

2. 僅警報(bào)：當(dāng)檢測(cè)到PFC 看門(mén)狗時(shí)，它會(huì)生成警報(bào)（如Syslog），但不會(huì)采取任何進(jìn)一步措施來(lái)丟棄流量。有人稱其為日志看門(mén)狗。

3. 關(guān)閉隊(duì)列：這是本文撰寫(xiě)時(shí)最常見(jiàn)的實(shí)現(xiàn)方式。當(dāng)檢測(cè)到PFC 看門(mén)狗處于無(wú)損隊(duì)列中時(shí)，將采取以下操作：

a. 該隊(duì)列中的所有幀都會(huì)被丟棄。

b. 只要該隊(duì)列仍處于Rx Pause（接收暫停）狀態(tài)，該交換機(jī)其他端口上所有新到達(dá)的、注定要從該隊(duì)列流出的幀都會(huì)被立即丟棄。

c. 該端口上屬于相同流量類別（如出口無(wú)損類別）的所有入口流量也會(huì)被丟棄。所有入口暫停幀也會(huì)被丟棄。這是PFC 看門(mén)狗的獨(dú)特區(qū)別。請(qǐng)注意，暫停超時(shí)（在Cisco MDS、Nexus 和UCS 的FCoE 端口上可用）和無(wú)損信元超時(shí)（在Cisco MDS 交換機(jī)的FC 端口上可用）不會(huì)影響端口上的入口流量。這些功能無(wú)損入口流量的理由是，擁塞是定向的，因此反向流量不應(yīng)受到影響。與此相反，PFC 看門(mén)狗拒絕接收入口流量的理由是，在慢排空設(shè)備上運(yùn)行的應(yīng)用程序不會(huì)因?yàn)閱蜗蛄髁浚趴赵O(shè)備的出口流量與啟用了PFC 看門(mén)狗的交換端口的入口流量相同）而受益。事實(shí)上，如前面"I/O 操作、流量模式和網(wǎng)絡(luò)擁塞的相關(guān)性"一節(jié)所述，慢排空設(shè)備的出口流量可能會(huì)增加擁塞的持續(xù)時(shí)間和嚴(yán)重程度。

PFC 看門(mén)狗功能的具體實(shí)現(xiàn)可能因開(kāi)關(guān)類型而異。例如：

1. Cisco MDS 交換機(jī)：在撰寫(xiě)本文時(shí)，Cisco MDS 交換機(jī)上不提供PFC 看門(mén)狗功能。使用暫停超時(shí)功能是一種有效的替代方法，因?yàn)镸DS 交換機(jī)只對(duì)FCoE 流量使用單一的無(wú)損類。

2. Cisco Nexus 交換機(jī)：Cisco Nexus 9000 和Nexus 3000 交換機(jī)上提供PFC 看門(mén)狗功能。支持和操作（端口翻轉(zhuǎn)、僅警報(bào)、隊(duì)列關(guān)閉）取決于型號(hào)類型和NX-OS 版本。有關(guān)最新信息，請(qǐng)參閱發(fā)布說(shuō)明。

3. 思科UCS：Cisco UCS 服務(wù)器在4.2 版以后的UCS 管理器中支持PFC 看門(mén)狗。暫停超時(shí)和PFC 進(jìn)程監(jiān)控相互排斥。在以后的版本中，PFC 看門(mén)狗默認(rèn)已啟用。

以下是NX-OS 10.3(1) 中Cisco Nexus 9000 交換機(jī)上PFC 看門(mén)狗的配置詳情。

1. 使用NX-OS 命令priority-flow-control watch-dog-interval 啟用PFC 看門(mén)狗。

2. 該命令允許軟件進(jìn)程每隔一段時(shí)間輪詢一次禁丟隊(duì)列。默認(rèn)情況下，輪詢間隔為100 毫秒。要更改輪詢間隔，請(qǐng)使用NX-OS 命令priority-flow-control watch-dog interval <100 - 1000>，在100 ms 和1000 ms 之間以100 ms 為增量。

3. 隊(duì)列關(guān)閉的快慢取決于shutdown-multiplier。默認(rèn)情況下，其值為1，可使用NX-OS 命令priority-flow-control watch-dog shutdown-multiplier <1 - 10> 更改。無(wú)損隊(duì)列的關(guān)閉時(shí)間為（看門(mén)狗間隔x 關(guān)閉乘數(shù)）。因此，默認(rèn)情況下，隊(duì)列會(huì)在Rx 暫停狀態(tài)持續(xù)100 毫秒時(shí)關(guān)閉。當(dāng)關(guān)閉乘數(shù)為2 時(shí)，隊(duì)列將在200 毫秒時(shí)關(guān)閉，依此類推。

4. 隊(duì)列處于關(guān)閉狀態(tài)后，可以使用NX-OS 命令priority-flow-control recover interface qos-group 手動(dòng)恢復(fù)。qos-group 值標(biāo)識(shí)了與被PFC 進(jìn)程看門(mén)狗關(guān)閉的不丟棄隊(duì)列相關(guān)聯(lián)的流量類別。

5. 另外，還可以使用兩種方案自動(dòng)恢復(fù)隊(duì)列。

a. 固定恢復(fù)倍增器在（看門(mén)狗間隔x 固定恢復(fù)倍增器）之后恢復(fù)隊(duì)列，而與Rx 暫停無(wú)關(guān)。換句話說(shuō)，即使設(shè)備仍然是慢耗空設(shè)備，隊(duì)列也會(huì)恢復(fù)。固定恢復(fù)乘數(shù)默認(rèn)為禁用（值為0）。可以使用NX-OS 命令priority-flow-control fixed-restore multiplier <0 - 100> 啟用它。

b. 只有在該隊(duì)列連續(xù)（看門(mén)狗間隔x 自動(dòng)恢復(fù)乘數(shù)）未收到Rx Pause 后，自動(dòng)恢復(fù)乘數(shù)才會(huì)恢復(fù)隊(duì)列。換句話說(shuō)，只有在設(shè)備停止造成慢排空"之后"，隊(duì)列才會(huì)恢復(fù)。自動(dòng)恢復(fù)的默認(rèn)值為10，可以使用NX-OS 命令priority-flow-control auto-restore multiplier <0 - 100> 進(jìn)行更改。

考慮一臺(tái)設(shè)備，該設(shè)備在時(shí)間= T1 時(shí)開(kāi)始造成慢排空。其連接的交換端口配置了PFC 看門(mén)狗，時(shí)間間隔為100ms，關(guān)機(jī)倍率為1，自動(dòng)恢復(fù)倍率為10。設(shè)備連續(xù)發(fā)送暫停幀，從而停止所連接交換端口上的傳輸。當(dāng)交換端口在100 毫秒內(nèi)無(wú)法連續(xù)傳輸時(shí)，它會(huì)關(guān)閉隊(duì)列，從而丟棄隊(duì)列中的所有數(shù)據(jù)包，并執(zhí)行前面描述的其他操作。這發(fā)生在T1 + 100ms 時(shí)。時(shí)間= T2 時(shí)，設(shè)備停止發(fā)送PFC 暫停幀。如果交換端口在最后1 秒內(nèi)沒(méi)有收到該免丟包類的PFC 暫停幀，隊(duì)列將自動(dòng)恢復(fù)。

如例7-12 所示，要驗(yàn)證Cisco Nexus 9000 交換機(jī)上的PFC 進(jìn)程看門(mén)狗配置和隊(duì)列的當(dāng)前狀態(tài)，請(qǐng)使用NX-OS 命令show queuing pfc-queue。如圖所示，以太網(wǎng)1/3 和以太網(wǎng)1/5 啟用了PFC 進(jìn)程監(jiān)視。如VL bmap 所示，兩個(gè)接口上的CoS 1 流量都啟用了PFC。只有在以太網(wǎng)1/5 上，分配給CoS 1 流量的無(wú)損隊(duì)列處于關(guān)閉狀態(tài)。

Example 7-12Verifying PFC watchdog on Cisco Nexus 9000 switches

switch# show queuing pfc-queue

+----------------------------------------------------+

Global watch-dog interval [Enabled]

+----------------------------------------------------+

+----------------------------------------------------+

Global PFC watchdog configuration details

PFC watch-dog poll interval : 100 ms

PFC watch-dog shutdown multiplier : 1

PFC watch-dog auto-restore multiplier : 10

PFC watch-dog fixed-restore multiplier : 0

PFC watchdog internal-interface multiplier : 2

+----------------------------------------------------+

+-------------------------------------------------------------+

| Port PFC Watchdog (VL bmap) State (Shutdown) |

+-------------------------------------------------------------+

Ethernet1/1 Disabled ( 0x0 ) - - - - - - - -

Ethernet1/2 Disabled ( 0x0 ) - - - - - - - -

Ethernet1/3 Enabled ( 0x2 ) - - - - - - N -

Ethernet1/4 Disabled ( 0x0 ) - - - - - - - -

Ethernet1/5 Enabled ( 0x2 ) - - - - - - Y -

Ethernet1/6 Disabled ( 0x0 ) - - - - - - - -

使用NX-OS 命令show queuing pfc-queue interface（顯示隊(duì)列pfc-queue 接口）查找PFC 進(jìn)程看門(mén)狗導(dǎo)致的數(shù)據(jù)包丟棄統(tǒng)計(jì)。例7-13 顯示了該命令的輸出。按以下方式解釋Stats 列：

1.關(guān)閉：分配給QoS 組1 (CoS 1) 流量的隊(duì)列被關(guān)閉的次數(shù)。

2.恢復(fù)：分配給QoS 組1 (CoS 1) 流量的隊(duì)列被恢復(fù)的次數(shù)。

3.已排空的數(shù)據(jù)包總數(shù)：上次關(guān)閉隊(duì)列時(shí)隊(duì)列中已丟棄的數(shù)據(jù)包數(shù)量。

4.丟棄的總數(shù)據(jù)包數(shù)：上次關(guān)閉隊(duì)列后，交換機(jī)上其他端口到達(dá)Eth1/5 上試圖通過(guò)此隊(duì)列退出并被丟棄的數(shù)據(jù)包數(shù)量。

5.排空的總件數(shù)+ 丟失的總件數(shù)：排空的數(shù)據(jù)包總數(shù)(3) + 丟失的數(shù)據(jù)包總數(shù)(4)。

6.累計(jì)丟失的pkts：這與(4) 相同，但它顯示的是之前多個(gè)關(guān)閉/未關(guān)閉實(shí)例的總計(jì)數(shù)。

7.丟棄的入口數(shù)據(jù)包總數(shù)：屬于同一QoS 組1 (CoS 1) 的數(shù)據(jù)包到達(dá)Eth 1/5 的入口時(shí)被丟棄

8.丟棄的入口pkts 總量：這與(7) 相同，但它顯示的是多個(gè)先前關(guān)閉/未關(guān)閉實(shí)例的總計(jì)數(shù)。

Example 7-13PFC watchdog counters on Cisco Nexus 9000 switches

switch# show queuing pfc-queue interface e1/5 detail

+----------------------------------------------------+

Ethernet1/5 Interface PFC watchdog: [Enabled]

+----------------------------------------------------+

+----------------------------------------------------+

| QOS GROUP 1 [Active] PFC [YES] PFC-COS [1]

+----------------------------------------------------+

| | Stats |

+----------------------------------------------------+

| Shutdown| 4|

| Restored| 4|

| Total pkts drained| 752|

| Total pkts dropped| 2197357321|

| Total pkts drained + dropped| 2197358073|

| Aggregate pkts dropped| 53487546587|

| Total Ingress pkts dropped| 66649|

| Aggregate Ingress pkts dropped| 34987434|

+----------------------------------------------------+

要清除這些計(jì)數(shù)器，請(qǐng)使用NX-OS 命令clear queuing pfc-queue。

Cisco Nexus 9000 交換機(jī)通過(guò)Syslog 消息通知PFC 看門(mén)狗隊(duì)列關(guān)閉/恢復(fù)操作。例7-14 顯示了隊(duì)列關(guān)閉Syslog 消息。

Example 7-14Syslog message when a queue is shut down due to PFC watchdog

2021 Aug 18 1051 N9K %$ VDC-1 %$ %TAHUSD-SLOT1-2-

TAHUSD_SYSLOG_PFCWD_QUEUE_SHUTDOWN: Queue 1 of Ethernet1/5 is shutdown due to PFC

watchdog timer expiring

例7-15 顯示了隊(duì)列恢復(fù)Syslog 消息。請(qǐng)注意入口和出口丟棄數(shù)據(jù)包的數(shù)量。

Example 7-15Syslog message when a queue is restored after being shut down by PFC watchdog

2021 Aug 18 1058 N9K %$ VDC-1 %$ %TAHUSD-SLOT1-2-

TAHUSD_SYSLOG_PFCWD_QUEUE_RESTORED: Queue 1 of Ethernet1/5 is restored due to PFC

watchdog timer expiring; 2197358073 egress packets/66649 ingress packets dropped

during the event

The Granularity of Pause Timeout and PFC Watchdog

暫停超時(shí)的配置粒度為100 毫秒，與PFC 看門(mén)狗間隔相同。這兩個(gè)功能都依賴于軟件每100 毫秒輪詢一次。因此，兩者都會(huì)將動(dòng)作和恢復(fù)時(shí)間延遲長(zhǎng)達(dá)99 毫秒。換句話說(shuō)，PFC看門(mén)狗關(guān)機(jī)動(dòng)作可能需要長(zhǎng)達(dá)199 毫秒，而不是在100 毫秒時(shí)準(zhǔn)確執(zhí)行。

請(qǐng)參閱第6 章"行動(dòng)中的無(wú)貸記掉線超時(shí)"一節(jié)和第3 章"TxWait、Slowport-monitor 和Tx-credit-not-available 之間的差異"一節(jié)，了解使用軟件輪詢的結(jié)果和基于ASIC 實(shí)現(xiàn)的額外優(yōu)勢(shì)。在Cisco MDS 交換機(jī)上，光纖通道無(wú)credit-drop 超時(shí)功能于2015 年轉(zhuǎn)為基于ASIC 的實(shí)現(xiàn)。在撰寫(xiě)本文時(shí)，基于ASIC 的暫停超時(shí)和PFC 進(jìn)程看門(mén)狗實(shí)施尚未推出。

The Benefits and the Limitations

暫停超時(shí)和PFC 看門(mén)狗會(huì)丟棄發(fā)送給慢速設(shè)備的幀，從而釋放緩沖區(qū)，使受害設(shè)備擺脫擁塞影響。丟棄幀偏離了無(wú)損網(wǎng)絡(luò)的無(wú)丟棄行為，但當(dāng)罪魁禍?zhǔn)自O(shè)備無(wú)法接收幀時(shí)，與其永遠(yuǎn)等待并讓其他設(shè)備受害，不如丟棄罪魁禍?zhǔn)自O(shè)備的幀。由于上述原因，我們建議根據(jù)環(huán)境的可用性和設(shè)備供應(yīng)商推薦的閾值啟用這些功能。

在使用這些方法時(shí)，請(qǐng)注意以下限制：

1. 在撰寫(xiě)本文時(shí)，暫停超時(shí)和PFC 看門(mén)狗的大多數(shù)實(shí)現(xiàn)都基于軟件輪詢，這可能會(huì)延遲操作并降低恢復(fù)的有效性。請(qǐng)參閱前面的"暫停超時(shí)和PFC 看門(mén)狗的粒度"部分。

2. 暫停超時(shí)和PFC 看門(mén)狗有助于從慢排空造成的擁塞中恢復(fù)。如果擁塞是由邊緣鏈路的過(guò)度使用造成的，這些方法就無(wú)能為力了。

3. 暫停超時(shí)和PFC 看門(mén)狗的最小粒度為100 毫秒。因此，當(dāng)傳輸停止的時(shí)間較短時(shí)（如50 毫秒），這些方法就無(wú)能為力了。

4. 暫停超時(shí)和PFC 看門(mén)狗超時(shí)僅對(duì)連續(xù)停止傳輸?shù)臅r(shí)段起作用。即使暫停幀不連續(xù)，慢速設(shè)備也會(huì)造成嚴(yán)重?fù)砣?/p>

這些限制不應(yīng)妨礙使用暫停超時(shí)和PFC 看門(mén)狗。但要注意它們能實(shí)現(xiàn)什么，不能實(shí)現(xiàn)什么。

Congestion Notification in Routed Lossless Ethernet Networks

終端設(shè)備及其應(yīng)用程序可能無(wú)法察覺(jué)網(wǎng)絡(luò)擁塞。肇事設(shè)備可能會(huì)繼續(xù)在網(wǎng)絡(luò)上發(fā)送（或請(qǐng)求）更多流量，使擁塞的嚴(yán)重程度惡化或持續(xù)時(shí)間延長(zhǎng)。為了解決這個(gè)問(wèn)題，網(wǎng)絡(luò)交換機(jī)可以在檢測(cè)到擁塞時(shí)立即"明確"通知終端設(shè)備。作為回應(yīng)，肇事設(shè)備可采取預(yù)防措施。

這種通過(guò)通知終端設(shè)備來(lái)防止擁塞的方法適用于各種網(wǎng)絡(luò)，其實(shí)施和采用程度各不相同。第6 章"通過(guò)通知終端設(shè)備防止擁塞"一節(jié)詳細(xì)介紹了在光纖通道Fabric 中使用Fabric Performance Impact Notifications (FPIN) 和Congestion Signals 的實(shí)施情況。第8 章"TCP 存儲(chǔ)網(wǎng)絡(luò)中的擁塞通知"一節(jié)介紹了TCP/IP 存儲(chǔ)網(wǎng)絡(luò)中的這種方法。

如前所述，這種方法在FCoE 和RoCE 環(huán)境中的實(shí)施和采用并不常見(jiàn)。因此，本節(jié)不對(duì)其進(jìn)行解釋。本節(jié)的重點(diǎn)是RoCEv2 擁塞管理(RCM) 路由無(wú)損以太網(wǎng)網(wǎng)絡(luò)中的擁塞通知。

Solution Components

通過(guò)通知終端設(shè)備來(lái)防止擁塞的方法是否成功取決于以下因素：

1. 擁塞檢測(cè)：交換機(jī)（稱為擁塞點(diǎn)）必須能夠檢測(cè)到擁塞癥狀。

2. 發(fā)送通知：檢測(cè)到擁塞后，交換機(jī)必須能夠?qū)⑵渫ㄖK端設(shè)備。為此，光纖通道交換機(jī)會(huì)發(fā)送特殊幀（稱為FPIN）和擁塞信號(hào)。相比之下，RoCEv2 和TCP/IP 網(wǎng)絡(luò)通過(guò)在報(bào)頭中標(biāo)記特殊位，將此信息編碼到數(shù)據(jù)包中。

3. 接收通知：終端設(shè)備必須能夠理解交換機(jī)發(fā)出的通知。這取決于終端設(shè)備的硬件和/或軟件能力。

4. 預(yù)防擁塞行動(dòng)：在收到網(wǎng)絡(luò)擁塞通知后，終端設(shè)備必須采取預(yù)防措施，如降低速率。這是最重要的組成部分。

以下各節(jié)將使用RoCEv2 擁塞管理(RCM) 對(duì)這些組件進(jìn)行說(shuō)明。

RoCEv2 Transport Overview

RoCEv2 數(shù)據(jù)包有一個(gè)IP 報(bào)頭，因此可以使用IPv4 或IPv6 報(bào)頭中的DSCP 字段進(jìn)行分類。請(qǐng)參閱前面的"優(yōu)先級(jí)流量控制"一節(jié)，了解在路由第3 層網(wǎng)絡(luò)中如何對(duì)流量進(jìn)行分類并將其分配到無(wú)損類。第1 章圖1-10 顯示了RoCEv2 數(shù)據(jù)包格式。

為了通知終端設(shè)備擁塞情況，使用了IP 報(bào)頭中的"顯式擁塞通知"（ECN）字段。

請(qǐng)注意以下幾點(diǎn)：

1. 通常，以太網(wǎng)VLAN CoS 值會(huì)映射到IP 報(bào)頭中的DSCP 字段。表7-1 提供了這種映射。

2. 在路由網(wǎng)絡(luò)中，以太網(wǎng)報(bào)頭在每一跳都會(huì)改變，因此除非另行配置，否則不會(huì)保留CoS 值。但I(xiàn)P 報(bào)頭中的DSCP 字段在源和目的地之間保持不變。

3. 在不使用VLAN 的網(wǎng)絡(luò)中，使用IP 標(biāo)頭中的DSCP 字段是對(duì)流量進(jìn)行分類的唯一選擇，因?yàn)镃oS 是VLAN 標(biāo)頭的一部分。

4. 重疊網(wǎng)絡(luò)（如虛擬可擴(kuò)展局域網(wǎng)(VXLAN)）通常會(huì)在封裝原始數(shù)據(jù)包之前將DSCP 和ECN 值復(fù)制到外部IP 標(biāo)頭，并將這些值從外部標(biāo)頭復(fù)制到解封裝數(shù)據(jù)包，因此在使用IP 標(biāo)頭對(duì)流量進(jìn)行分類時(shí)，會(huì)保留不丟棄行為和ECN。有關(guān)詳情，請(qǐng)參閱"使用VXLAN 的無(wú)損以太網(wǎng)"一節(jié)。

RoCEv2 Congestion Management

交換機(jī)檢測(cè)到擁塞時(shí)，會(huì)在IP 報(bào)頭的ECN 字段中標(biāo)記擁塞。目的地接收到帶有ECN 標(biāo)記的數(shù)據(jù)包后，會(huì)將此信息反映給信源，信源會(huì)通過(guò)限制流量速率做出反應(yīng)。RFC 3168 解釋了使用TCP 作為第4 層協(xié)議的顯式擁塞通知（ECN）。RCM 依賴于相同的機(jī)制，但由于RoCEv2 使用的是UDP（而非TCP），因此有一些不同之處，下文將對(duì)此進(jìn)行說(shuō)明。

請(qǐng)參考圖7-17，它是圖7-8 所解釋的脊葉網(wǎng)絡(luò)的一個(gè)子集。以下是概要步驟：

Figure 7-17RoCEv2 Congestion Management (RCM)

1.是否愿意使用RCM：終端設(shè)備（Target-1 和Host-1）支持RCM 時(shí)，會(huì)在IPv4 或IPv6 標(biāo)頭中設(shè)置ECN-capable Transport（ECT）標(biāo)志。ECT 標(biāo)志在IP 報(bào)頭的ECN 字段中用b'01' 或b'10' 設(shè)置。ECN 字段中的b'00' 表示端點(diǎn)不支持ECN，也不支持RCM。

2. 擁塞檢測(cè)：當(dāng)隊(duì)列利用率超過(guò)配置的閾值時(shí)，端到端數(shù)據(jù)路徑中的交換機(jī)（Leaf-6）會(huì)檢測(cè)到擁塞。隊(duì)列利用率增加的原因是慢排空（出口交換端口上的Rx 暫停）或交換端口利用率過(guò)高。

3. 發(fā)送通知：交換機(jī)檢測(cè)到隊(duì)列擁塞時(shí)，會(huì)在IPv4 或IPv6 報(bào)頭中設(shè)置擁塞體驗(yàn)(CE) 標(biāo)志。CE 標(biāo)志在ECN 字段中用b'11' 設(shè)置。擁塞交換端口只為啟用了ECT 標(biāo)志（b'01' 或b'10'）的數(shù)據(jù)包設(shè)置CE 標(biāo)志。非ECN 功能數(shù)據(jù)包（ECN 值為b'00'）將保持不變地轉(zhuǎn)發(fā)。與光纖通道不同，在RoCEv2 網(wǎng)絡(luò)中，交換機(jī)不會(huì)發(fā)送任何特殊數(shù)據(jù)包（或幀或信號(hào)）來(lái)通知終端設(shè)備。

4. 接收通知：目的地（主機(jī)-1）在收到帶有CE 標(biāo)志的數(shù)據(jù)包時(shí)會(huì)檢測(cè)到網(wǎng)絡(luò)擁塞。由于CE 標(biāo)志是標(biāo)準(zhǔn)IP 報(bào)頭的一部分，因此主機(jī)-1 不需要任何特殊機(jī)制來(lái)解釋新型數(shù)據(jù)包。但是，它必須能夠檢測(cè)到CE 標(biāo)志并對(duì)其采取行動(dòng)。當(dāng)主機(jī)-1 接收到CE 標(biāo)記數(shù)據(jù)包時(shí)，它會(huì)向啟用了CE 標(biāo)記的入口數(shù)據(jù)包的源端（目標(biāo)-1）發(fā)送擁塞通知數(shù)據(jù)包（CNP），從而向源端反映擁塞情況。由于CNP 是一種特殊的數(shù)據(jù)包，因此目標(biāo)和源都必須能夠發(fā)送和接收CNP，以及發(fā)送CNP 的頻率、停止發(fā)送的時(shí)間和內(nèi)容等其他細(xì)節(jié)。此外，還要配置網(wǎng)絡(luò)QoS 策略，以高優(yōu)先級(jí)對(duì)CNP 進(jìn)行分類和轉(zhuǎn)發(fā)。

5. 預(yù)防擁塞行動(dòng)：發(fā)送方（目標(biāo)-1）收到CNP 后，會(huì)降低發(fā)送CNP 的目的地的流量。如前所述，由于CNP 是一種特殊數(shù)據(jù)包，發(fā)送方必須能夠監(jiān)聽(tīng)并采取行動(dòng)。此外，在初始降低速率行動(dòng)后，發(fā)送方必須能夠調(diào)整其速率，以便在未充分利用和過(guò)度利用之間達(dá)到最佳平衡。

RoCEv2 Congestion Management Considerations

圖7-17 對(duì)RCM 進(jìn)行了過(guò)于簡(jiǎn)化的解釋。但是，在生產(chǎn)環(huán)境中，成百上千臺(tái)設(shè)備可能會(huì)以多對(duì)一的流量模式連接到同一個(gè)Fabric。

本節(jié)介紹了RoCEv2 網(wǎng)絡(luò)的一些重要注意事項(xiàng)。這些注意事項(xiàng)在新建環(huán)境中可能并不明顯，但隨著網(wǎng)絡(luò)的發(fā)展或成熟，應(yīng)了解其局限性并采取積極措施。

請(qǐng)參考圖7-8，并思考圖7-17 所解釋的RCM 如何運(yùn)行。然后，考慮以下幾點(diǎn)：

1. 混合環(huán)境：根據(jù)RoCEv2 標(biāo)準(zhǔn)，RCM 是可選項(xiàng)。需要特別注意支持RCM 和不支持RCM 終端設(shè)備的混合環(huán)境。當(dāng)許多設(shè)備向同一設(shè)備發(fā)送流量時(shí)，如果少數(shù)發(fā)送方不支持RCM，它們的流量不會(huì)被CE 標(biāo)記，而來(lái)自其他支持RCM 的設(shè)備的流量則會(huì)被CE 標(biāo)記。因此，慢耗設(shè)備（目的地）只向支持RCM 的設(shè)備發(fā)送CNP。因此，支持RCM 的設(shè)備會(huì)降低流量速率，而不支持RCM 的設(shè)備則不會(huì)。這種情況可能會(huì)導(dǎo)致支持RCM 的設(shè)備流量不足，因?yàn)樗鼈兛赡軙?huì)不斷降低速率，而不支持RCM 的設(shè)備可能會(huì)消耗掉所有鏈路容量。在混合TCP 和UDP 流量的IP 網(wǎng)絡(luò)中，這種情況類似于UDP 流量導(dǎo)致的TCP 饑餓。通常情況下，較新的設(shè)備更有可能支持RCM。如果現(xiàn)有設(shè)備不支持RCM，較新的設(shè)備可能會(huì)受到更多懲罰。

2. 速率降低算法：RoCEv2 標(biāo)準(zhǔn)提到，發(fā)送方應(yīng)在收到CNP 后降低流量速率，但沒(méi)有解釋速率降低或恢復(fù)的算法。由于缺乏標(biāo)準(zhǔn)方法，供應(yīng)商只能開(kāi)發(fā)不同的實(shí)施方案，在相同的環(huán)境中做出不同的反應(yīng)。用戶只能承受非統(tǒng)一實(shí)施的結(jié)果，或被迫鎖定供應(yīng)商以實(shí)現(xiàn)統(tǒng)一。

3. 同步：接收CNP 的流量源不知道其他向同一目的地發(fā)送流量的流量源。多個(gè)此類源的集體行動(dòng)可能會(huì)導(dǎo)致反應(yīng)過(guò)度或反應(yīng)不足。例如，在圖7-8 中，如果每個(gè)目標(biāo)將速率降低5%，則五個(gè)目標(biāo)的集體速率降低行動(dòng)會(huì)導(dǎo)致速率降低25%（反應(yīng)過(guò)度）。之后，當(dāng)目標(biāo)調(diào)整/提高速率時(shí)，五個(gè)獨(dú)立工作的此類設(shè)備可能會(huì)再次導(dǎo)致最初的問(wèn)題，從而引發(fā)最初的擁塞事件。在TCP/IP 網(wǎng)絡(luò)中，這種情況類似于TCP 全局同步。

4. 延遲行動(dòng)：在某些突發(fā)流量模式的存儲(chǔ)環(huán)境中，RCM（以及其他通過(guò)通知終端設(shè)備來(lái)防止擁塞的方法）可能無(wú)法奏效，因?yàn)閺臋z測(cè)到擁塞到采取預(yù)防措施之間存在延遲。在圖7-17 中，Leaf-6 檢測(cè)到擁塞，Host-1 接收到CE 標(biāo)記數(shù)據(jù)包，向源發(fā)送CNP，最后源降低速率。這些步驟在Leaf-6 觀察到變化時(shí)都會(huì)產(chǎn)生延遲。此時(shí)，原來(lái)的擁塞癥狀可能會(huì)自行消失。引用RFC 3168（這與RCM 使用的機(jī)制相同）的一句話："CE 數(shù)據(jù)包表示持續(xù)性擁塞，而不是瞬時(shí)性擁塞，因此收到CE 數(shù)據(jù)包時(shí)的反應(yīng)應(yīng)與持續(xù)性擁塞相適應(yīng)"。

5.配置復(fù)雜：RCM 的成功與否取決于其在網(wǎng)絡(luò)中的配置。在交換機(jī)上標(biāo)記CE 標(biāo)志通常使用加權(quán)隨機(jī)早期檢測(cè)(WRED) 等檢測(cè)方案。有關(guān)詳細(xì)信息，請(qǐng)參閱第8 章"主動(dòng)隊(duì)列管理"一節(jié)。應(yīng)配置這些機(jī)制的閾值，以便在隊(duì)列滿之前在交換機(jī)上觀察到降低速率的操作。這些值還取決于交換機(jī)的類型，因?yàn)椴煌慕粨Q機(jī)有不同的架構(gòu)和緩沖區(qū)容量。在終端設(shè)備上，CNP 的頻率是一個(gè)重要的考慮因素。過(guò)多的CNP 可能會(huì)增加終端設(shè)備的負(fù)載，而過(guò)少的CNP 可能會(huì)延遲終端設(shè)備的操作。此外，速率降低算法也可能存在變數(shù)。

這些問(wèn)題不應(yīng)妨礙RCM 的啟用。請(qǐng)遵循供應(yīng)商的建議，并根據(jù)您的環(huán)境完善配置。需要記住的重要一點(diǎn)是，不能因?yàn)槟承〇|西在較新（新建環(huán)境）中運(yùn)行良好，就不再需要監(jiān)控?fù)砣Y狀。

打個(gè)比方，新車(chē)的輪胎充有氮?dú)?。起初，它們可能幾個(gè)月甚至一年都不需要充氣。這些新車(chē)工作得非常好，以至于有些司機(jī)幾乎忘記了輪胎需要?dú)鈮簷z查，結(jié)果導(dǎo)致他們的不太新的汽車(chē)爆胎。他們本可以通過(guò)每月主動(dòng)檢查來(lái)避免這一問(wèn)題。不要成為這樣的司機(jī)。問(wèn)題會(huì)隨著環(huán)境的成長(zhǎng)或成熟而顯現(xiàn)。如果您已經(jīng)意識(shí)到潛在的問(wèn)題，那么當(dāng)問(wèn)題出現(xiàn)時(shí)，就能幫助您更快地解決問(wèn)題。

PFC and ECN

PFC 是一種逐跳流量控制機(jī)制。相比之下，ECN 會(huì)通知目的地，而目的地又會(huì)通知發(fā)送方降低流量速率以防止擁塞。如前所述，從檢測(cè)到擁塞（標(biāo)記CE 標(biāo)志時(shí)）到擁塞交換端口觀察到降低的速率之間存在延遲。這大約是往返時(shí)間和終端設(shè)備處理延遲的兩倍。在此期間，擁塞交換端口上的隊(duì)列可能會(huì)填滿。逐跳PFC 可能會(huì)被激活，而不是丟棄數(shù)據(jù)包，從而導(dǎo)致?lián)砣诓粊G棄類中擴(kuò)散。

同時(shí)使用ECN 和PFC 可以發(fā)揮兩者的優(yōu)勢(shì)。ECN 基于流量，但其效果可能會(huì)延遲。與此相反，PFC 基于優(yōu)先級(jí)（類別或類型），但其及時(shí)行動(dòng)可避免丟包。同時(shí)使用這兩種方法，可以使操作既迅速又基于流量。

Configuring PFC and ECN Parameters

通知終端設(shè)備（通過(guò)ECN 和CNP）后的速率降低操作應(yīng)消除擁塞原因。沒(méi)有擁塞時(shí)，就沒(méi)有必要調(diào)用PFC。因此，正常工作的ECN 應(yīng)能很快減少PFC 暫停。但在交換機(jī)上配置ECN 門(mén)限需要特別考慮。具體數(shù)值取決于交換機(jī)類型，請(qǐng)參考供應(yīng)商文檔。本節(jié)僅解釋概念性概述。

Note the following points.請(qǐng)注意以下幾點(diǎn)。

1.入口隊(duì)列/緩沖區(qū)只有在出口隊(duì)列被大量使用后才會(huì)開(kāi)始填滿。這一點(diǎn)在前面的"入口和出口隊(duì)列及微突發(fā)檢測(cè)"一節(jié)中已有解釋。

2.ECN 標(biāo)記（如WRED）的閾值應(yīng)用于出口隊(duì)列，而PFC 暫停閾值和恢復(fù)閾值則應(yīng)用于入口隊(duì)列/緩沖區(qū)。

3.暫停閾值和恢復(fù)閾值應(yīng)根據(jù)前面"暫停閾值和恢復(fù)閾值"一節(jié)中的詳細(xì)說(shuō)明進(jìn)行配置。對(duì)于距離較短的數(shù)據(jù)中心內(nèi)鏈路，通常不需要更改默認(rèn)的暫停閾值和恢復(fù)閾值。

4. ECN 門(mén)限應(yīng)足夠低，以便更早地標(biāo)記CE 標(biāo)志，從而有足夠的時(shí)間在擁塞端口上觀察到速率降低操作。

5. 閾值應(yīng)足夠大，至少能容納幾個(gè)數(shù)據(jù)包。例如，在啟用巨型幀時(shí)，9000 字節(jié)的最小大小甚至無(wú)法在隊(duì)列中保留一個(gè)完整大小的巨型數(shù)據(jù)包。

圖7-18 至圖7-23 展示了PFC 和ECN 的共同功能。需要了解的一個(gè)要點(diǎn)是，即使調(diào)整了閾值，也不能完全消除逐跳擁塞傳播。如果瞬間調(diào)用PFC，擁塞擴(kuò)散是可以接受的。PFC 本身是有益的，因?yàn)樗梢员苊鈹?shù)據(jù)包丟棄，但它的副作用是會(huì)降低所有具有相同優(yōu)先級(jí)的流量的速度。如果ECN 能盡快降低部分流量的傳輸速率，就能限制PFC 造成的逐跳擁塞擴(kuò)散和持續(xù)時(shí)間。如前所述，配置時(shí)應(yīng)力求兩種方法的最佳效果，而不是以消除PFC 為目標(biāo)。

Figure 7-18PFC and ECN working together in a RoCEv2 network — Step — 1

Figure 7-19PFC and ECN working together in a RoCEv2 network — Step — 2

Figure 7-20PFC and ECN working together in a RoCEv2 network — Step — 3

Figure 7-21PFC and ECN working together in a RoCEv2 network — Step — 4

Figure 7-22PFC and ECN working together in a RoCEv2 network — Step — 5

Figure 7-23PFC and ECN working together in a RoCEv2 network — Step — 6

Lossless Traffic with VXLAN

虛擬可擴(kuò)展局域網(wǎng)（VXLAN）可傳輸無(wú)損流量，與任何其他路由IP/ 以太網(wǎng)網(wǎng)絡(luò)類似。因此，擁塞檢測(cè)、故障排除和預(yù)防都與此類似。

VXLAN Overview

虛擬可擴(kuò)展局域網(wǎng)（VXLAN）將第2 層域擴(kuò)展到第3 層數(shù)據(jù)中心網(wǎng)絡(luò)。這樣就可以靈活部署需要跨第3 層邊界的第2 層鄰接的工作負(fù)載。VXLAN 的另一個(gè)優(yōu)點(diǎn)是規(guī)模更大。以太網(wǎng)VLAN ID 是一個(gè)12 位字段，這將VLAN 的數(shù)量限制在4096 個(gè)。相比之下，VXLAN 網(wǎng)絡(luò)標(biāo)識(shí)符（VNI）是一個(gè)24 位字段，允許多達(dá)1600 萬(wàn)個(gè)第2 層域。VXLAN 還得益于第3 層底層網(wǎng)絡(luò)的等成本多路徑（ECMP）路由，從而實(shí)現(xiàn)第2 層域之間的高速無(wú)阻塞連接。

VXLAN Transport

VXLAN 采用MAC-in-UDP 封裝，將第2 層域擴(kuò)展到第3 層網(wǎng)絡(luò)。有關(guān)VXLAN 幀格式，請(qǐng)參閱圖7-24。兩個(gè)獨(dú)立的第2 層網(wǎng)絡(luò)通過(guò)VXLAN 隧道端點(diǎn)（VTEP）連接到第3 層網(wǎng)絡(luò)。顧名思義，VTEP 通過(guò)VXLAN 隧道連接。它們知道本地第2 層域中可到達(dá)的MAC 地址以及通過(guò)遠(yuǎn)程VTEP 可到達(dá)的MAC 地址。當(dāng)VTEP 接收到要發(fā)送給遠(yuǎn)程第2 層域中設(shè)備的第2 層幀時(shí)，它會(huì)將第2 層幀封裝到IP/UDP 數(shù)據(jù)包中，并通過(guò)路由網(wǎng)絡(luò)發(fā)送給遠(yuǎn)程VTEP。遠(yuǎn)程VTEP 對(duì)數(shù)據(jù)包進(jìn)行解封裝，并將底層第2 層幀發(fā)送到目的地。

Figure 7-24VXLAN frame format

Physical Topology

VXLAN 第3 層網(wǎng)絡(luò)通常采用脊葉拓?fù)洳渴穑愃朴趫D7-8）。這就是所謂的底層網(wǎng)絡(luò)。底層網(wǎng)絡(luò)中的數(shù)據(jù)包轉(zhuǎn)發(fā)由IS-IS 和OSPF 等IP 路由協(xié)議之一啟用。

Cisco Nexus 9000 等葉子交換機(jī)可充當(dāng)基于硬件的VTEP。每個(gè)VTEP 有兩個(gè)接口。一個(gè)是第2 層接口，用于連接本地端點(diǎn)通信的本地第2 層域。另一個(gè)是路由底層網(wǎng)絡(luò)上的第3 層接口。

兩個(gè)VTEP 之間的流量通過(guò)多個(gè)骨干交換機(jī)使用ECMP。終端設(shè)備可能不知道，VTEP 會(huì)將發(fā)往目的地的數(shù)據(jù)包封裝在VXLAN 數(shù)據(jù)包中。同樣，位于入口和出口VTEP 之間的脊柱交換機(jī)也可能不知道數(shù)據(jù)包屬于VXLAN 隧道。它只會(huì)查找外部IP 報(bào)頭，然后發(fā)送到目的地VTEP。

審核編輯：劉清