第5篇????BGP/MPLS ×××

第15章????MPLS技術(shù)基礎(chǔ)

15.2????MPLS起源

????隨著Internet的迅速普及，傳統(tǒng)的路由器設(shè)備因其轉(zhuǎn)發(fā)性能低下，逐漸成為網(wǎng)絡(luò)的瓶頸。

????首先，路由器采用的轉(zhuǎn)發(fā)算法效率不高。路由器普遍采用IP轉(zhuǎn)發(fā)。IP轉(zhuǎn)發(fā)的原則是最長匹配算法。路由器在判斷該如何轉(zhuǎn)發(fā)一個數(shù)據(jù)包時，需要遍歷整個路由表，找出最能精確表達該數(shù)據(jù)目的地址所在位置的那一條路由。

????此外，當時路由器多采用通過CPU進行轉(zhuǎn)發(fā)處理，性能有限，對IP地址和路由的匹配運算需要耗費較多的處理器時間。

????MPLS（Multiprotocol Label Switching，多協(xié)議標簽交換）的基本概念是用一個短而定長的標簽來封裝網(wǎng)絡(luò)層分組，并將標簽封裝后的報文轉(zhuǎn)發(fā)到已升級改進過的交換機或者路由器，交換機或路由器根據(jù)標簽值轉(zhuǎn)發(fā)報文。后文將詳細闡述MPLS的具體實現(xiàn)過程。

????MPLS中的多協(xié)議有多層含義。一方面是指MPLS協(xié)議可以承載在多種二層協(xié)議之上，如常見的PPP、ATM、幀中繼（FR）、以太網(wǎng)等等；另一方面多種報文也可以承載在MPLS之上，如IPv4報文、IPv6報文等，甚至也包括各種二層報文。與多種協(xié)議的兼容性是MPLS協(xié)議得以普及的重要原因之一。

15.3????MPLS網(wǎng)絡(luò)組成

????MPLS網(wǎng)絡(luò)架構(gòu)與普通的IP網(wǎng)絡(luò)相比，并無任何特殊性。普通的IP網(wǎng)絡(luò)、其路由器只要經(jīng)過升級，支持MPLS功能，就成了MPLS網(wǎng)絡(luò)。在MPLS網(wǎng)絡(luò)中的路由器，具有標簽分發(fā)能力和標簽交換能力，被稱之為LSR。此外，MPLS網(wǎng)絡(luò)可以與非MPLS網(wǎng)絡(luò)共存，報文可在非MPLS網(wǎng)絡(luò)和MPLS網(wǎng)絡(luò)之間進行轉(zhuǎn)發(fā)。

????MPLS網(wǎng)絡(luò)的基本構(gòu)成單元是LSR（Lable Switching Router），是具有標簽分發(fā)能力和標簽交換能力的設(shè)備。

????MPLS網(wǎng)絡(luò)包括以下幾個組成部分：

????·????入節(jié)點Ingress：報文的入口LSR，負責為進入MPLS網(wǎng)絡(luò)的報文添加標簽。

????·????中間節(jié)點Transit：MPLS網(wǎng)絡(luò)內(nèi)部的LSR，根據(jù)標簽沿著由一系列LSR構(gòu)成的LSP將報文傳送給出口LSR。

????·????出節(jié)點Egress：報文的出口LSR，負責剝離報文中的標簽，并轉(zhuǎn)發(fā)給目的網(wǎng)絡(luò)。

????FEC（Forwarding Equivalence Class，轉(zhuǎn)發(fā)等價類）是MPLS中的一個重要概念。MPLS將具有相同特征（目的地相同或具有相同服務等級等）的報文歸為一類，稱為FEC。屬于相同F(xiàn)EC的報文在MPLS網(wǎng)絡(luò)中將獲得完全相同的處理。

????屬于同一個FEC的報文在MPLS網(wǎng)絡(luò)中經(jīng)過的路徑稱為LSP（Label Switched Path，標簽交換路徑）。LSP是一條單向報文轉(zhuǎn)發(fā)路徑。在一條LSP上，沿數(shù)據(jù)傳送的方向，相鄰的LSR分別稱為上游LSR和下游LSR。

15.4.2????MPLS標簽分配協(xié)議分類

15.4.3????LDP消息類型

????LDP協(xié)議定義了以下四類消息：

????·????發(fā)現(xiàn)消息（Discovery message）：用于LDP鄰居的發(fā)現(xiàn)和維持。

????·????會話消息（Session message）：用于LDP鄰居會話的建立、維持和中止。

????·????通告消息（Advertisement message）：用于LSR向LDP鄰居宣告Label、地址等信息。

????·????通知消息（Notification message）：用于向LDP鄰居通知事件或者錯誤。

????所有的LDP消息都采用TLV結(jié)構(gòu)，具有很強的擴展性。

注意：

????具體的LDP消息有很多種，包括Notification、Hello、Initialization、KeepAlive、Address、Address Withdraw、Label Mapping、Label Request、Label Abort Request、Label Withdraw、Label Release等，這些消息都可以分別歸入上述四類之中。

15.4.4????標簽分配過程

15.4.5????標簽分配和管理方式

????在標簽分配的過程中，存在很多種方式，這些方式一般情況下可以在設(shè)備上進行配置，各種不同的方式適合不同的MPLS應用。

????標簽通告模式包括：

????????·????DOD：downstream-on-demand????下游按需方式

????????·????DU：downstream unsolicited 下游自主方式

????標簽控制模式包括：

????????·????有序方式（Ordered）

????????·????獨立方式（Independent）

????標簽保持模式包括：

????????·????保守模式（Conservative）

????????·????自由模式（Liberal）

15.5????MPLS轉(zhuǎn)發(fā)實現(xiàn)

15.6????MPLS應用與發(fā)展

第16章????BGP MPLS ×××基本原理

16.2????BGP MPLS ××× 技術(shù)背景

16.2.1????傳統(tǒng)×××缺陷

????×××技術(shù)能夠非常有效的節(jié)省用戶建立私有網(wǎng)絡(luò)的成本，成為用戶建立私有網(wǎng)絡(luò)的一個很好的選擇，因此各種各樣的×××技術(shù)也紛紛出爐，如GRE、IPSec、L2TP等等。這些×××技術(shù)被統(tǒng)稱為傳統(tǒng)×××技術(shù)。隨著網(wǎng)絡(luò)的發(fā)展，用戶私有網(wǎng)絡(luò)的規(guī)模也逐漸擴大，傳統(tǒng)×××技術(shù)的一些缺點被暴露出來，最主要的體現(xiàn)為以下兩點：

????·????靜態(tài)隧道的可擴展性不強。傳統(tǒng)×××技術(shù)的隧道需要靜態(tài)建立，隨著用戶網(wǎng)絡(luò)規(guī)模的擴大，×××隧道的數(shù)量成N平方增長，用戶的分支部門的增減都將涉及到大量的靜態(tài)隧道的配置或刪除。

????·????×××只能由用戶自行維護和管理。在公共的Internet網(wǎng)絡(luò)上承載著很多的×××用戶，而各個×××用戶的私網(wǎng)地址空間通常是重疊的，×××的維護和管理工作只能由用戶自行完成。負責維護和管理公共網(wǎng)絡(luò)的運營商因為不能區(qū)分開用戶，無法接管用戶的×××。

????這兩個缺點，使得用戶不可能選擇采用傳統(tǒng)的×××技術(shù)建立大規(guī)模的私有網(wǎng)絡(luò)。

16.2.2????BGP MPLS ×××的優(yōu)點

????BGP MPLS ×××技術(shù)是通過BGP和MPLS兩種技術(shù)配置實現(xiàn)的一種新型的×××技術(shù)，與傳統(tǒng)×××技術(shù)相比，它有如下三個優(yōu)點：

????·????實現(xiàn)隧道的動態(tài)建立。傳統(tǒng)×××技術(shù)用戶各個分部之間的×××隧道需要由維護人員手工靜態(tài)配置，而BGP MPLS ×××技術(shù)隧道是動態(tài)建立的。用戶的各個分部之間會自動建立隧道，且分部的增加或減少，不需要用戶再去添加或刪除隧道配置。

????·????解決了本地地址沖突問題。BGP MPLS ×××技術(shù)實現(xiàn)了一臺路由器可以同時處理多個不同的×××用戶數(shù)據(jù)的功能，最終使得多個地址沖突的用戶都可以將建立和維護×××的工作交給運營商，進一步降低×××用戶的負擔。

????·????×××私網(wǎng)路由易于控制。私網(wǎng)路由的交互是×××技術(shù)實現(xiàn)的關(guān)鍵，能夠動態(tài)的交互私網(wǎng)路由，用戶網(wǎng)絡(luò)才能自動發(fā)現(xiàn)各個分部網(wǎng)絡(luò)的所在位置。傳統(tǒng)的×××技術(shù)中可以支持私網(wǎng)路由的動態(tài)學習，然后BGP MPLS ×××技術(shù)在私網(wǎng)路由的動態(tài)交互的基礎(chǔ)上，加入了互通或隔離的控制，可以更加靈活的控制用戶各個分部，或者各個不同用戶之間的互訪關(guān)系。

16.3????MPLS隧道

16.3.1????隧道技術(shù)與MPLS

????×××的實現(xiàn)依賴于一個很重要的技術(shù)，那就是隧道。通過隧道，用戶私網(wǎng)在公網(wǎng)之間建立起一個邏輯通路，讓用戶的各個分部之間如有實際的物理線路相連。而隧道的實現(xiàn)是通過報文封裝的方法。如GRE隧道，就是采用公網(wǎng)IP頭部來封裝私網(wǎng)報文，公網(wǎng)上的路由器根據(jù)報文的外層IP頭進行轉(zhuǎn)發(fā)，直到報文抵達目的私有網(wǎng)絡(luò)，再去除外層的IP頭，解封出私網(wǎng)報文。

????MPLS技術(shù)產(chǎn)生本意是為了加快報文的轉(zhuǎn)發(fā)效率，但它其實也是一種隧道技術(shù)。從它的實現(xiàn)原理可以看出，它也是對報文進行封裝，在IP報文的前面加上了MPLS標簽，路由器直接根據(jù)標簽進行轉(zhuǎn)發(fā)，而無需檢查內(nèi)部的目的地址，這與GRE的封裝非常類似。所以MPLS技術(shù)是一種天然的隧道技術(shù)，而且與已有的×××所采用的隧道技術(shù)相比，它有著一個非常重要的優(yōu)勢，那就是動態(tài)性。

16.3.2????MPLS隧道應用

16.3.3????MPLS倒數(shù)第二跳彈出

16.4????多VRF技術(shù)

16.4.1????優(yōu)化×××組網(wǎng)結(jié)構(gòu)

????在×××的組網(wǎng)結(jié)構(gòu)中，我們將網(wǎng)絡(luò)分成公網(wǎng)和私網(wǎng)兩個部分。公網(wǎng)是指由服務商建設(shè)的公共網(wǎng)絡(luò)，而私網(wǎng)是指用戶自己建設(shè)的私有網(wǎng)絡(luò)。同時將網(wǎng)絡(luò)中的路由器按照在×××網(wǎng)絡(luò)中的位置區(qū)分成以下三種角色：

????·????CE（Custom Edge Router，用戶邊緣路由器）：直接與公網(wǎng)相連的用戶設(shè)備；

????·????PE（Provider Edge Router，服務商邊緣路由器）：指公網(wǎng)上的邊緣路由器，與CE相連；

????·????P（Provider Router，服務商路由器）：指公網(wǎng)上的核心路由器。

????傳統(tǒng)的×××隧道建立在用戶的CE設(shè)備之間，隧道的建立維護等工作完全需要由用戶自己來完成，每個×××用戶的維護工作繁瑣且分散，總體維護成本高昂。另一方面，作為專門提供網(wǎng)絡(luò)服務的網(wǎng)絡(luò)供應商，他們擁有充足的網(wǎng)絡(luò)維護資源，但卻完全無法感知用戶的×××應用，不能提供×××相關(guān)的服務，從而無法獲得響應的利潤。傳統(tǒng)×××的這種結(jié)構(gòu)限制了其大規(guī)模擴展，無論是用戶還是運營商都希望能夠?qū)ⅰ痢痢了淼赖慕⒕S護等工作轉(zhuǎn)移給運營商。

????另外一種×××方案是，隧道建立在PE設(shè)備之間，隧道的建立維護等工作由運營商來完成，如上圖所示。這樣，用戶能夠從繁瑣的×××維護工作中解脫出來，運營商也能夠從×××維護中獲利。

????然而，在以上方案中因為不同的私網(wǎng)用戶之間的地址空間可能完全重疊，所以運營商需要為每個×××用戶提供一臺接入設(shè)備，哪怕這兩個用戶離得再近也不能共用。這種方案稱之為專屬PE的方式。

????專屬PE方式需要運營商為每個×××用戶提供專門的設(shè)備，硬件成本過于高昂，用戶需要向運營商支付較高的費用，無法獲得廣泛認可。

????更優(yōu)的×××隧道方案是隧道建立在公網(wǎng)的PE之間，每一臺公網(wǎng)PE設(shè)備還可以同時接入多個×××用戶，多個×××用戶能夠共享一個隧道。這個方案無論從可維護性上，還是從成本上都滿足額用戶和運營商的需求。然而，由于不同的×××用戶可能選用了相同的地址空間，這樣會造成PE設(shè)備無法區(qū)分這些用戶的數(shù)據(jù)流。也就是說，此方案存在著同一臺設(shè)備上地址沖突的問題。多VRF（Virtual Routing and Forwarding，虛擬路由與轉(zhuǎn)發(fā)）技術(shù)可以解決這個問題。

16.4.2????多VRF技術(shù)實現(xiàn)原理

????多VRF技術(shù)的目的就是要解決在同一臺設(shè)備上的地址沖突問題。如上圖所示，該PE路由器的兩個不同接口，分別接入×××1和×××2用戶，而×××1用戶和×××2用戶都選用了10.0.0.1/24這個網(wǎng)段的地址。在沒有多VRF技術(shù)的情況下，這兩條路由將會在PE上發(fā)生沖突，在PE的路由表里面只能保留一條10.0.0.0/24路由。

????支持多VRF技術(shù)的路由器將一臺路由器劃分成多個VRF，每個VRF之間互相獨立，互不可見，各自擁有獨立的路由表項、端口、路由協(xié)議等等，每一個VRF就類似一臺虛擬的路由器。

????若上圖所示，PE1為了能同時接入×××1和×××2這兩個地址沖突的私網(wǎng)用戶，啟用兩個VRF，每個VRF與×××相對應，在VRF1里面只看到與×××1相連的接口，只學習×××1的路由；VRF2上也只看到與×××2相連的接口，只學習×××2的路由。這兩個VRF各自擁有自己的路由表，VRF1學習到的10.0.0.0/24路由，下一跳指向Eth0/1，這2條路由同時存在于PE1上，互不沖突，互不影響。

????有了支持多個技術(shù)的PE設(shè)備，就可以實現(xiàn)一臺PE接入多個×××用戶。

????為了加深理解多VRF技術(shù)的實現(xiàn)，在此進一步說明多VRF與設(shè)備端口的關(guān)系。在支持多VRF的PE設(shè)備上，需要將和某一個×××用戶相連的接口與對應的VRF相綁定。如上圖所示，PE1會將Eth0/0與VRF1綁定，而將Eth0/1與VRF2綁定。與VRF綁定后的接口，只會出現(xiàn)在該VRF對應的路由表里面；并且，當報文從該接口進入路由器時，只能查詢該VRF對應的路由表進行轉(zhuǎn)發(fā)。

????如上圖所示，從Eth0/0接口進入路由器的報文，只能查詢×××1的路由表進行轉(zhuǎn)發(fā)；從Eth0/0接口進入路由器的報文，也只能查詢×××2的路由表進行轉(zhuǎn)發(fā)。

????多VRF與設(shè)備端口的這種關(guān)系，確保了數(shù)據(jù)進入多VRF設(shè)備進行轉(zhuǎn)發(fā)時，不同×××用戶的數(shù)據(jù)之間不會發(fā)生沖突。

????在支持多VRF技術(shù)的路由器上，不同的VRF運行獨立的路由協(xié)議，這些路由協(xié)議不會交互協(xié)議報文，且學習到的路由也放在各自VRF的路由表中，互不影響。實現(xiàn)這種效果需要將各個VRF運行的路由協(xié)議與該VRF進行綁定。

????不同的VRF可以選擇采用同一種路由協(xié)議與×××用戶之間交互路由，例如均采用OSPF路由協(xié)議；當然也可以選擇不同的路由協(xié)議。在支持多VRF的路由器上需要運行多個路由協(xié)議進程，并將不同的進程與不同的VRF進行綁定，將路由協(xié)議的某個進程與某VRF進行綁定的做法稱之為路由協(xié)議的多實例。

????如上圖所示，PE路由器上運行兩個OSPF實例。OSPF instance 1和VRF 1進行綁定，與私網(wǎng)×××1用戶的路由器CE1建立OSPF鄰居；OSPF instance 2和VRF2進行綁定，與私網(wǎng)×××2用戶的路由器CE2建立OSPF鄰居。此時OSPF instance 1學習到的路由就會收錄到VRF1所對應的路由表中，而OSPF instance 2學習到的路由器就只會收錄到VRF2所對應的路由表中。

????多VRF和路由協(xié)議多實例之間的綁定關(guān)系，確保了即使使用不同的×××用戶選用相同的地址空間，并與PE設(shè)備之間通過路由協(xié)議交互路由時，也不會在PE上出現(xiàn)路由沖突。

????目前，絕大多數(shù)的路由器設(shè)備都能支持路由協(xié)議多實例功能，包括OSPF、IS-IS、BGP、RIP、靜態(tài)路由等。

16.5????MP-BGP技術(shù)

16.5.1????MP-BGP技術(shù)實現(xiàn)

????有了比傳統(tǒng)×××更加先進的隧道技術(shù)，也有了比傳統(tǒng)×××更加合理的×××組網(wǎng)結(jié)構(gòu)，最后只需要一種更加先進的路由協(xié)議，用于在PE設(shè)備之間交互私網(wǎng)路由信息。縱觀各種路由協(xié)議，最適合充當這個角色的路由協(xié)議是BGP路由協(xié)議，因為它有如下兩個非常關(guān)鍵的特質(zhì)，適合用于×××技術(shù)中。

????·????BGP路由協(xié)議是基于TCP連接建立路由鄰居的，可以實現(xiàn)跨越多臺路由器建立BGP鄰居，直接交互路由信息。在×××的組網(wǎng)中，就是需要兩臺PE設(shè)備直接交互私網(wǎng)路由，無需經(jīng)過中間的P設(shè)備轉(zhuǎn)達。因為作為隧道中間的P設(shè)備，它們無需了解×××的信息；另外，不同×××間地址空間會有重疊，如果這些×××路由都經(jīng)過P設(shè)備轉(zhuǎn)達，P設(shè)備上將無法區(qū)分。

????·????BGP路由協(xié)議的協(xié)議報文是基于TLV結(jié)構(gòu)的，具有擴展屬性位，便于攜帶更多的表明路由特征的信息。也就是說，BGP路由協(xié)議可以為×××組網(wǎng)定義一些擴展屬性，適應PE之間交互私網(wǎng)路由的需要。這一點對于×××非常重要，因為有了多VRF技術(shù)以后，每一臺PE設(shè)備需要接入多個×××用戶，一對PE設(shè)備之間交互的私網(wǎng)路由，需要設(shè)法攜帶上某種特征，才能夠通知對端PE這些路由信息屬于哪一個VRF。

????因為上述的兩個特質(zhì)，BGP路由協(xié)議被BGP MPLS ×××技術(shù)選用作于穿越公網(wǎng)傳遞私網(wǎng)路由的路由協(xié)議。為了適應×××技術(shù)的需要，BGP路由協(xié)議進行了一定的擴展，擴展后的BGP路由協(xié)議叫著MP-BGP（Multiprootocol BGP），即多協(xié)議BGP路由協(xié)議。

16.5.2????Route Target屬性

16.5.3????RD前綴

16.5.4????MPLS 私網(wǎng)Label

16.6????BGP MPLS ×××基本原理

16.6.1????公網(wǎng)隧道建立

????BGP MPLS ×××的實現(xiàn)分為以下四個步驟：

????????·????公網(wǎng)隧道的建立

????????·????本地×××的建立

????????·????私網(wǎng)路由的學習

????????·????私網(wǎng)數(shù)據(jù)的轉(zhuǎn)發(fā)

16.6.2????本地×××的建立

????只是將接口與×××進行綁定，并沒有最終完成本地×××的建立，還需要PE設(shè)備與本地的×××用戶完成私網(wǎng)路由的交互，這樣才能讓接入到PE上的×××用戶知道PE是通往其他分部的出口。

????

16.3.3????私網(wǎng)路由的學習

????完成了本地×××的建立，BGP MPLS ×××實現(xiàn)開始了最關(guān)鍵的一個步驟，也就是私網(wǎng)路由的學習過程，這個過程的主角是MP-BGP協(xié)議，它的目的是將PE設(shè)備在本地×××的建立過程中學習到的本地的私網(wǎng)路由信息通過MP-BGP協(xié)議傳遞給對端PE設(shè)備，并且根據(jù)用戶的×××互訪關(guān)系的設(shè)計，將這些信息存放在對端PE設(shè)備的正確的×××路由表中。

????私網(wǎng)路由的學習可以分為兩個部分來看，第一步是本地路由的封裝，也就是按照MP-BGP協(xié)議的原理，在本端PE上對即將傳遞給對端的私網(wǎng)路由進行一系列的準備工作，最終封裝成一個MP-BGP路由更新消息，發(fā)送給對端。

????

16.6.4????私網(wǎng)數(shù)據(jù)的傳遞

第17章????BGP MPLS ×××配置與故障排除

17.2????BGP MPLS ×××的配置思路

????BGP MPLS ×××的配置思路與BGP MPLS ×××的原理完全吻合，與BGP MPLS ×××的實現(xiàn)過程一樣，配置也分為以下三個步驟：

????1）配置公網(wǎng)隧道，首先在公網(wǎng)上使能MPLS，建立公網(wǎng)隧道；

????2）配置本地×××，其次就是要根據(jù)用戶×××的互訪關(guān)系，設(shè)計本地×××；

????3）配置MP-BGP，最后在PE之間建立其MP-BGP鄰居，傳遞私網(wǎng)路由。

17.3????BGP MPLS ×××配置命令

17.3.1????配置公網(wǎng)隧道

????在配置公網(wǎng)隧道時，有以下三個關(guān)鍵配置：

????1）配置該LSR設(shè)備的LSR ID：LSR ID的格式是一個IP地址，它將用來在MPLS網(wǎng)絡(luò)中標識這臺LSR設(shè)備。所以要求LSR設(shè)備的LSR ID在MPLS網(wǎng)絡(luò)中唯一，通常會選用LSR的loopback地址作為其LSR ID。配置方法非常簡單，如上圖所示，在系統(tǒng)模式下配置。

????2）使能LDP：這一步的配置是要講一臺普通的路由器，轉(zhuǎn)變?yōu)橐慌_可以處理MPLS報文，可以進行MPLS標簽分配的路由器。當然使能的標簽分配協(xié)議由用戶選用的標簽分配協(xié)議來決定，不一定是LDP協(xié)議，此處以LDP為例，給出配置案例，該部分配置內(nèi)容也在系統(tǒng)模式下。

????3）接口下使能MPLS和LDP：具體使能某一接口的MPLS報文處理能力和LDP標簽分配功能。系統(tǒng)模式下使能MPLS和LDP是接口使能對應功能的前提，只有具體接口使能了MPLS和LDP，該接口才能處理MPLS報文。

????完成上述配置后，如果網(wǎng)絡(luò)中已經(jīng)有對應的某一網(wǎng)段的路由，就能自動形成對應的標簽轉(zhuǎn)發(fā)表項，從而形成對應的隧道。

17.3.2????配置本地×××

????配置BGP MPLS ×××的第二步是要建立本地×××，這部分的配置包含兩個重要的部分，第一部分是根據(jù)用戶×××互訪關(guān)系的要求，給對應的×××設(shè)計RT、RD等參數(shù)，并在PE上配置該×××；第二部分是將用戶接入PE的接口與對應的×××進行綁定，并啟動路由協(xié)議多實例完成PE和CE之間的本地私網(wǎng)路由交互。

????所以這部分的關(guān)鍵配置如下幾步：

????1）創(chuàng)建一個×××：其中×××的名稱是一個任意字符串，可以根據(jù)用戶的特點進行命名，建立盡可能考慮能從名稱上識別是哪個用戶，以方便維護。

????2）配置RD和RT：這部分首先要根據(jù)用戶互訪需求進行限制，規(guī)劃完成后方可將規(guī)劃的RT和RD值配置在該×××視圖下。

????3）配置接口與×××綁定：將用戶接入的接口與對應的×××進行綁定，方法只需要在對應的接口下配置上圖所示的綁定命令。

????4）配置PE與CE之間的路由協(xié)議：其中在PE一側(cè)需要將對應的路由實例與對應的×××進行綁定，上圖是以O(shè)SPF在PE側(cè)的配置為例，將OSPF某一進程與某一×××進行綁定。

17.3.3????配置MP-BGP

17.4????BGP MPLS ×××配置示例

17.4.1????網(wǎng)絡(luò)環(huán)境和需求

17.4.2????配置BGP MPLS ×××公網(wǎng)隧道

????按照BGP MPLS ×××的配置思路，首先在公網(wǎng)上配置MPLS公網(wǎng)隧道，該部分配置包括兩個部分：

????1）首先在公網(wǎng)上使能某種IGP路由協(xié)議，使得公網(wǎng)設(shè)備之間IP互通；

????2）其次在公網(wǎng)上的P和PE設(shè)備上使能MPLS和MPLS LDP協(xié)議，完成PE設(shè)備之間的公網(wǎng)隧道建立。

17.4.3????配置BGP MPLS ×××本地×××

????配置BGP MPLS ×××的第二步是要配置本地×××，該部分配置通常分為以下三個步驟來完成；

????1）創(chuàng)建×××：按照用戶互訪需求創(chuàng)建×××并配置該×××的RD和RT值；

????2）配置私網(wǎng)接口與×××的綁定：即將PE上用戶接入的私網(wǎng)接口與對應的×××進行綁定；

????3）配置PE和CE之間的路由協(xié)議：實現(xiàn)PE與本地×××用戶之間的路由交互；

17.4.4????配置MP-BGP

17.5????BGP MPLS ×××排查故障

17.5.1????BGP MPLS ×××故障排查思路

17.5.2????BGP MPLS ×××故障排查步驟

17.5.3????排查本地×××故障的步驟

17.5.4????排查MP-BGP故障的步驟

第6篇????增強網(wǎng)絡(luò)安全性

第18章????增強網(wǎng)絡(luò)安全性

18.2????網(wǎng)絡(luò)安全概述

18.2.1????網(wǎng)絡(luò)安全威脅的來源

????實際上，真正使得企業(yè)遭受重大損失的安全事件，大部分都是來自于內(nèi)部。

18.2.2????網(wǎng)絡(luò)安全范圍

18.2.3????安全網(wǎng)絡(luò)構(gòu)成

18.3????業(yè)務隔離

18.3.1????局域網(wǎng)業(yè)務隔離

18.3.2????廣域網(wǎng)業(yè)務隔離

18.4????訪問控制

18.4.1????為什么要進行訪問控制

18.4.2????訪問控制的實現(xiàn)手段

18.4.3????防火墻技術(shù)

18.5.1????AAA體系結(jié)構(gòu)

????AAA是Authenticaiton，Authorizaiton and Accounting（認證、授權(quán)和計費）的簡稱，它提供了一個用來對認證、授權(quán)和計費這三種安全功能進行配置的一致性框架，實際上是網(wǎng)絡(luò)安全的一種管理機制。

????這里的網(wǎng)絡(luò)安全主要是指訪問控制，包括：

????·????哪些用戶可以訪問網(wǎng)絡(luò)服務器；

????·????具有訪問權(quán)的用戶可以得到哪些服務；

????·????如何對正在使用網(wǎng)絡(luò)資源的用戶進行計費。

????針對以上問題，AAA支持以下認證方式：

????·????不認證（none）：對用戶非常信任，不對其進行合法性檢查，一般情況下不采用這種方式。

????·????本地認證（local）：將用戶信息（包括本地用戶的用戶名、密碼和各種屬性）配置在設(shè)備上。本地認證的優(yōu)點是速度快，可以降低運營成本；缺點是存儲信息量受設(shè)備硬件條件限制。

????·????遠端認證：支持通過RADIUS協(xié)議或HWTACACS協(xié)議進行遠端認證，由設(shè)備（如交換機、路由器）作為Clinet端，與RADIUS服務器或TACACS服務器通信。對于RADIUS協(xié)議，可以采用標準或擴展的RADIUS協(xié)議，與CAMS等系統(tǒng)配合完成認證。

????·????授權(quán)功能。AAA支持以下授權(quán)方式：

????????·????直接授權(quán)（none）：對用戶非常信任，直接授權(quán)通過，此時用戶的權(quán)限為系統(tǒng)的默認權(quán)限。

????????·????本地授權(quán)（local）：根據(jù)設(shè)備上為本地用戶帳號配置的相關(guān)屬性進行授權(quán)。

????????·????HWTACACS授權(quán)：由TACACS服務器對用戶進行授權(quán)。

????????·????RADIUS授權(quán)：RADIUS授權(quán)是特殊的流程。只有在認證和授權(quán)的RADIUS方案相同的條件下，RADIUS授權(quán)才起作用，同時將RADIUS認證回應報文中攜帶的授權(quán)信息下發(fā)。

????·????計費功能。AAA支持以下計費方式：

????????·????不計費（none）：不對用戶計費。

????????·????本地計費（local）：本地計費是為了支持本地用戶的連接數(shù)限制管理，實現(xiàn)了對用戶接入數(shù)的統(tǒng)計功能；

????????·????遠端計費：支持通過RADIUS服務器或TACACS服務器進行遠端計費。

????AAA一般采用客戶機/服務器結(jié)構(gòu)。客戶端運行于被管理的資源側(cè)，服務器上集中存放用戶信息。因此，AAA框架具有良好的可擴展性，并且容易實現(xiàn)用戶信息的集中管理。AAA可以通過多種協(xié)議來實現(xiàn)，目前設(shè)備中的AAA是基于RADIUS協(xié)議或HWTACACS協(xié)議來實現(xiàn)的。

18.5.2????認證授權(quán)應用

18.6????傳輸安全

????在一個不安全的環(huán)境中傳輸重要數(shù)據(jù)時，首先應確保數(shù)據(jù)的機密性，即防止數(shù)據(jù)被未獲得授權(quán)的查看者理解，從而防止信息內(nèi)容泄漏，保證信息安全性。

????對于數(shù)據(jù)機密性的保障，需要對數(shù)據(jù)進行加密。加密算法根據(jù)其工作方式的不同，可以分為對稱加密算法和非對稱加密算法兩種。

????在對稱加密算法中，通信雙方共享一個秘密，作為加密/解密的密鑰。這個密鑰既可以直接獲得的，也可以是通過某種共享的方法推算出來的。由于任何具有這個共享密鑰的人都可以對密文進行解密，所以，對稱加密算法的安全性安全依賴于密鑰本身的安全性。因為對稱密鑰加密方法執(zhí)行效率一般比較高，對稱密鑰加密算法適用于能夠安全地交換密鑰且傳輸數(shù)據(jù)量較大的場合。目前有不少對稱密鑰加密算法的標準，包括DES、3DES、RC4、AES等。

????非對稱加密算法也稱為公開密鑰算法。此類算法為每個用戶分配一對密鑰：一個私有密鑰和一個公開密鑰。私有密鑰是保密的，由用戶自己保管。公開密鑰是公諸與眾的，其本身不構(gòu)成嚴格的秘密。這兩個密鑰的產(chǎn)生沒有相互關(guān)系，也就是說不能利用公開密鑰推斷出私有密鑰，安全性較高。非對稱加密算法的弱點在于其速度非常慢，吞吐量低。因此不適宜于大量數(shù)據(jù)的加密。非對稱密鑰的算法中最著名和最流行的是RSA和DH。

????在一個不安全的環(huán)境中傳輸數(shù)據(jù)時，還需要確保數(shù)據(jù)的完整性，即發(fā)覺數(shù)據(jù)是否被篡改。

????為了保證數(shù)據(jù)的完整性，通常使用摘要算法（HASH）。采用HASH函數(shù)對一段長度可變的數(shù)據(jù)進行hash計算，會得到一段固定長度的結(jié)果，該結(jié)果稱之為原數(shù)據(jù)的摘要，也稱之為消息驗證碼（Message Authentication Code，MAC）。摘要中包含了被保護數(shù)據(jù)的特征，如果該數(shù)據(jù)稍有變化，都會導致最后計算的摘要不同。另外HASH函數(shù)具有單向性。也就是說無法根據(jù)結(jié)果導出原始輸入，因而無法構(gòu)造一個與原報文有相同摘要的報文。

????數(shù)字簽名是指使用密碼算法對待發(fā)的數(shù)據(jù)進行加密處理，生成一段信息，附著在原文上一起發(fā)送，這段信息類似現(xiàn)實中的簽名或印章，接收方對其進行驗證，判斷原文幀偽。

????數(shù)字簽名技術(shù)是在網(wǎng)絡(luò)虛擬環(huán)境中確認身份的重要技術(shù)，完全可以大體現(xiàn)實過程中的“親筆簽名”，在技術(shù)和法律上有保證。

????數(shù)字簽名可以保證信息傳輸?shù)耐暾?#xff0c;確認發(fā)送者的真實身份并防止交易中的抵賴發(fā)生。

18.7????安全防御

18.7.1????使用NAT進行安全防御

????NAT（Network Address Translation，網(wǎng)絡(luò)地址轉(zhuǎn)換）是將IP數(shù)據(jù)報頭中的IP地址轉(zhuǎn)換為另一個IP地址的過程。網(wǎng)絡(luò)地址轉(zhuǎn)換是對Internet隱藏內(nèi)部地址，防止內(nèi)部地址公開。

????在內(nèi)部網(wǎng)絡(luò)與Intenret相連的位置使用NAT技術(shù)對于網(wǎng)絡(luò)安全來說有如下的好處：

????·????內(nèi)部用戶仍然能夠透明的訪問外部網(wǎng)絡(luò)，內(nèi)部用戶不會感受到地址轉(zhuǎn)換的存在，在部署了NAT技術(shù)后訪問外網(wǎng)業(yè)務的可用性不會受到影響。

????·????采用了NAT技術(shù)后，發(fā)出到外網(wǎng)的數(shù)據(jù)信息的源地址都經(jīng)過了轉(zhuǎn)換，內(nèi)網(wǎng)地址信息被屏蔽掉了，使外部人員無法獲致內(nèi)部網(wǎng)絡(luò)的信息，也就沒有了***的對象。

????·????采用NAT技術(shù)后，內(nèi)部網(wǎng)絡(luò)的IP地址在互聯(lián)網(wǎng)上永遠不會被路由，內(nèi)外網(wǎng)的路由被隔段，外網(wǎng)的主動***無法到達內(nèi)網(wǎng)。

????·????在兩個內(nèi)部網(wǎng)絡(luò)相互連接的時候，采用雙向NAT技術(shù)，可以避免兩個網(wǎng)絡(luò)的地址互相影響，避免由于地址沖突引發(fā)的網(wǎng)絡(luò)安全問題。

????總之，在與Internet（或其他網(wǎng)絡(luò)）相連的位置使用NAT（網(wǎng)絡(luò)地址轉(zhuǎn)換）技術(shù)是一種非常行之有效的安全防御手段。

18.7.2????網(wǎng)絡(luò)***與防御

18.7.3????設(shè)備安全加固

????整個網(wǎng)絡(luò)是由網(wǎng)絡(luò)設(shè)備和相關(guān)線路組成，網(wǎng)絡(luò)設(shè)備的安全是整個網(wǎng)絡(luò)穩(wěn)定運行的前提條件。如果網(wǎng)絡(luò)設(shè)備的安全都得不到保證，整個網(wǎng)絡(luò)的安全也就無從談起。

????在網(wǎng)絡(luò)上，對于網(wǎng)絡(luò)設(shè)備的安全威脅主要有以下幾個方面：

????·????對于設(shè)備登錄安全的威脅。非法用戶通過各種方式（比如TELNET、SSH、SNMP等方式）遠程登錄到設(shè)備上，獲取對設(shè)備部分或全部的控制權(quán)，對設(shè)備的穩(wěn)定運行造成威脅，從而威脅到整個網(wǎng)絡(luò)的穩(wěn)定運行。

????·????對于設(shè)備管理權(quán)限的安全威脅。合法的用戶獲取到非法的權(quán)限，獲得對設(shè)備更大的操作權(quán)限，對設(shè)備的穩(wěn)定運行造成威脅，從而威脅到整個網(wǎng)絡(luò)的穩(wěn)定運行。

????·????對于設(shè)備本身的***。利用設(shè)備開啟的各類服務，比如FTP服務，IP重定向服務等服務，對設(shè)備的CPU進行***，使設(shè)備無法正常工作，從而威脅到整個網(wǎng)絡(luò)的穩(wěn)定運行。

????·????對于設(shè)備資源的安全威脅。非法用戶通過大規(guī)模消耗設(shè)備的相應資源（比如APP表項，MAC表項），導致正常用戶享受的服務。

第7篇????服務質(zhì)量

第19章????QoS概述

????傳統(tǒng)的IP網(wǎng)絡(luò)僅提供“盡力而為”（Best-Effort）的傳輸服務。網(wǎng)絡(luò)有可用資源時就轉(zhuǎn)發(fā)數(shù)據(jù)包，網(wǎng)絡(luò)可用資源不足時就丟棄數(shù)據(jù)包。網(wǎng)絡(luò)設(shè)備采用先進先出（First In First Out），不區(qū)分業(yè)務，也無法對業(yè)務傳遞提供任何可預期和有保障的服務質(zhì)量。

????新一代互聯(lián)網(wǎng)承載了語音、視頻等實時互動信息，而這些業(yè)務對網(wǎng)絡(luò)的延遲、抖動等情況都非常敏感，因此要求網(wǎng)絡(luò)在傳統(tǒng)服務之外能進一步提供有保證和可預期的服務質(zhì)量。

????QoS（Quality of Service，服務質(zhì)量）通過合理的管理和分配網(wǎng)絡(luò)資源，允許用戶的緊急和延遲敏感型業(yè)務能獲得相對優(yōu)先的服務，從而在丟包、延遲、抖動和帶寬等方面獲得可預期的服務水平。

19.2????新一代網(wǎng)絡(luò)面臨的服務質(zhì)量問題

19.2.1????常見的語音視頻質(zhì)量問題

19.3????服務質(zhì)量的衡量標準

19.3.1????帶寬

????帶寬（Bandwidth）和吞吐量（Throughput）是用于衡量網(wǎng)絡(luò)傳輸容量的關(guān)鍵指標。帶寬就是單位時間內(nèi)許可的最×××量，其單位為bps（bit per second）。吞吐量是每秒通過的數(shù)據(jù)包的個數(shù)，其單位為pps（packet per second）。

????對于一條端到端的路徑而言，其最大可用帶寬等于端到端路徑上帶寬最低的鏈路的帶寬。

????當然，在每一鏈路上可能同時傳送多個數(shù)據(jù)流，這些數(shù)據(jù)流將共同分享鏈路帶寬。因此每個數(shù)據(jù)流實際可以占用的帶寬將小于最大可用帶寬。

????對于所有應用而言，帶寬總是首要條件。為了使應用能夠正常工作，首先必須獲得足夠的可用帶寬。帶寬不足將導致網(wǎng)絡(luò)擁塞，引起丟包、延遲、抖動等一系列問題。

19.3.2????延遲

????延遲（Delay）有稱為時延，是衡量數(shù)據(jù)包穿越網(wǎng)絡(luò)所用時間的指標，通常以毫秒（ms）為單位。延遲是一個綜合性的指標，主要由處理延遲和傳播延遲組成。

????處理延遲指網(wǎng)絡(luò)設(shè)備從接收到報文到將其提交到出接口準備發(fā)出所消耗的時間。其主要包括兩部分：

????·????交換延遲：指報文從接口被交換到出接口所用的時間，這部分延遲主要取決于設(shè)備內(nèi)部處理能力，例如總線帶寬和交換板容量等，在設(shè)備既定的條件下可以被認為是固定值。

????·????排隊延遲：是指報文在出接口隊列中等待和被調(diào)度的時間，這部分延遲受網(wǎng)絡(luò)擁塞情況，調(diào)度算法和CPU負載的影響，是一個不確定的值。當網(wǎng)絡(luò)負載較輕時排隊延遲可能很小；但當網(wǎng)絡(luò)負載較重時，大部分報文都要在隊列中排隊等候，排隊延遲會很大。

????·????串行化延遲：指報文被發(fā)送到鏈路上時轉(zhuǎn)為串行信號所用的時間。其主要取決于物理接口的速率，速率越大則串行化所用時間越少。

????·????傳輸延遲：指物理信號在介質(zhì)上傳輸所用的時間。其主要取決于鏈路的長度和物理性質(zhì)。比如衛(wèi)星通信通常就具有很大的傳輸延遲，而局域網(wǎng)內(nèi)的傳輸延遲基本可以忽略不計。

????????各種延遲發(fā)生作用的位置如圖所示。

19.3.3????抖動

????抖動（Jitter）是描述延遲變化的物理量，是衡量網(wǎng)絡(luò)延遲穩(wěn)定性的指標。抖動通常以毫秒（ms）為單位。抖動的數(shù)值等于延遲變化量的絕對值。

????抖動產(chǎn)生的原因主要是延遲的隨機性。在IP網(wǎng)絡(luò)環(huán)境中，由于分組轉(zhuǎn)發(fā)的緣故，同一數(shù)據(jù)流中相接的兩個包可能通過不同的路徑到達對端，因而其延遲有可能有相差較大。即使通過相同的路徑，網(wǎng)絡(luò)設(shè)備和鏈路資源的情況也是一個不斷變化的因素，這就可能造成延遲的變化性和不可預知性，從而引起較大的抖動。

19.3.4????丟包率

????丟包的產(chǎn)生可能來源于傳輸錯誤、流量限制、網(wǎng)絡(luò)擁塞等多種情況。由于傳輸介質(zhì)的改進，傳輸錯誤造成的丟包已經(jīng)很少發(fā)生了。在因而目前的丟包大部分來自網(wǎng)絡(luò)擁塞和流量限制。前者是由于帶寬資源不足，當隊列滿之后，設(shè)備不得以而對非重要類型數(shù)據(jù)進行丟棄而發(fā)生的；后者由于數(shù)據(jù)流量超出許可的范圍，導致設(shè)備對其進行丟棄而發(fā)生的。

????丟包的程度通過丟包率來衡量。一段時間內(nèi)的丟包率等于該段時間內(nèi)丟棄的報文數(shù)量除以該段時間內(nèi)的全部報文數(shù)量。

????丟包率是衡量網(wǎng)絡(luò)性能狀況的另一個重要參數(shù)，主要表征報文在網(wǎng)絡(luò)傳輸過程的可靠性。對于大多數(shù)應用而言，丟包是最為嚴重的網(wǎng)絡(luò)問題。因為丟包意味著信息的不完整，甚至會影響整個數(shù)據(jù)流。對于TCP應用，由于其本身提供了重傳確認的機制，發(fā)生少量的丟包時可以通過重傳進行彌補，但是嚴重的丟包會導致TCP傳輸速率的緩慢，甚至完全中斷。對于UDP應用，由于UDP本身沒有任何確認機制，它不能確定是否丟包，極有可能造成信息的永久缺失。對語音、視頻等應用，如果網(wǎng)絡(luò)出現(xiàn)丟包，它們會寧愿舍棄這些數(shù)據(jù)包，因為遲到的數(shù)據(jù)包對這些應用是沒有價值的，因此丟包會使這些應用在使用效果上大打折扣。

19.3.5????常規(guī)應用對網(wǎng)絡(luò)服務質(zhì)量的要求

19.4????QoS的功能

19.4.1????提高服務質(zhì)量的方法

????提高服務質(zhì)量的主要方法包括：

????·????提高物理帶寬：增加物理帶寬是緩解帶寬不足的最簡單方法，比如百兆以太網(wǎng)升級到千兆，OC-48升級到OC-192。但由于涉及硬件升級，這種方法受技術(shù)和成本的限制。應用對帶寬的需求是無限的，由于計算機網(wǎng)絡(luò)具有分組交換資源重復的基本特點，不論物理帶寬有多高，都仍然可能發(fā)生至少是暫時性的擁塞。

????·????增加緩沖：發(fā)送方可以增加緩沖區(qū)，在擁塞發(fā)生時將來不及發(fā)送的報文緩存起來，等資源有富余時再發(fā)送；接收方可以增加緩沖區(qū)，在抖動較大時等待足夠的報文到達后再平滑處理。這種方法可以在一定程度上緩解突發(fā)性的擁塞和高抖動，但增加了被緩沖報文的延遲。另一方面，緩沖區(qū)總是有限的，當緩沖區(qū)滿時報文仍然會被丟棄。

????·????對報文進行壓縮：壓縮技術(shù)減少了數(shù)據(jù)傳輸量，效果相當于增加了帶寬，同時降低了串行化延遲。但壓縮和解壓縮操作會加重設(shè)備處理負擔，引入新的處理延遲。同時壓縮的比率無法預先確定，因此不能預期其實施效果。

????·????優(yōu)先轉(zhuǎn)發(fā)某些數(shù)據(jù)流的報文：在資源不足時，優(yōu)先為重要、敏感的應用報文提供服務，而丟棄不重要的應用報文；在重要性相同的情況下，根據(jù)需求對各應用按一定比例提供服務。這樣既可以照顧敏感應用對延遲和抖動的要求，又可以照顧各類應用對帶寬和吞吐量的要求。在物理資源既定的情況下，這是一種合理的解決方案。

????·????分片和交錯發(fā)送：在低速鏈路上，為了避免大尺寸報文的傳輸長時間占用鏈路而造成其他報文的延遲，可以將其拆分成若干片段。這種方法可以降低低速鏈路上重要應用的延遲，降低敏感應用的抖動。

19.4.2????QoS的功能

????QoS旨在對網(wǎng)絡(luò)資源提供更好的管理，以在統(tǒng)計層面上對各種業(yè)務提供合理而公平的網(wǎng)絡(luò)服務。其具體的作用包括以下幾個方面：

????·盡量避免網(wǎng)絡(luò)擁塞。

????·在不能避免擁塞時對帶寬進行有效管理。

????·降低IP網(wǎng)絡(luò)流量。

????·為特定用戶或特定業(yè)務提供專用帶寬

????·支撐網(wǎng)絡(luò)上的實時業(yè)務。

????????QoS只能使資源的分配更合理，使網(wǎng)絡(luò)傳輸變得更有效，而不能創(chuàng)造網(wǎng)絡(luò)資源。

19.5????Best-Effort模型

19.5.1????Best-Effort模型介紹

????Best Effort是最簡單的服務模型。報文的轉(zhuǎn)發(fā)無需預約資源，網(wǎng)絡(luò)盡最大可能來發(fā)送報文，有資源就發(fā)送，沒資源就丟棄。網(wǎng)絡(luò)不區(qū)分報文所屬的業(yè)務類型，對各種業(yè)務都不提供任何的延遲和丟包保證。

????Best Effort模型是互聯(lián)網(wǎng)缺省的服務模型，其通過FIFO（First Input First Output，先入先出）隊列來實現(xiàn)，實現(xiàn)最為簡單。

19.5.2????FIFO隊列

19.5.3????Best-Effort模型的特點

19.6????DiffServ模型

19.6.1????DiffServ模型介紹

19.6.2????Diffserv模型體系結(jié)構(gòu)

????Diffserv模型的體系結(jié)構(gòu)如圖所示，其主要由下列組件構(gòu)成：

????·DS域（Differentiated Services Domain）：DS域是一組相鄰的DS節(jié)點的集合，這些DS節(jié)點配置了一致的服務提供策略。DS域的邊界由位于邊界處的所有DS邊界節(jié)點構(gòu)成。

????·DS邊界節(jié)（DS Boundary Nodes）：DS邊界節(jié)點負責對進入本DS域的數(shù)據(jù)進行分類及可能的調(diào)節(jié)，以保證穿過此DS域的數(shù)據(jù)流符合約定的速率，其報文的DS代碼點被適當標記。

????·DS內(nèi)部節(jié)點（DS Interior Nodes）：位于DS域內(nèi)的DS內(nèi)部節(jié)點根據(jù)報文攜帶的DS代碼點為數(shù)據(jù)包提供適當?shù)霓D(zhuǎn)發(fā)行為。

????·邊界鏈路和內(nèi)部鏈路：DS域的邊界節(jié)點通過邊界鏈路與其他DS域或非DS域相連；一個DS域內(nèi)部的邊界節(jié)點和內(nèi)部節(jié)點之間通過內(nèi)部鏈路互相連接。

????·非DS域：指不支持DS服務的網(wǎng)絡(luò)或節(jié)點。

????·DS區(qū)（Differentialted Services Region）：DS區(qū)由一個或多個相鄰的DS域構(gòu)成，可以沿一系列DS域構(gòu)成的路徑上提供區(qū)分服務。DS區(qū)中的DS域可能配置了不同的服務提供策略，以及不同的代碼點到PHB的映射規(guī)則。為了在DS區(qū)內(nèi)的整個路徑上提供區(qū)分服務，各DS域之間必須建立定義了TCA（Traffic Conditoning Agreement，流量調(diào)節(jié)協(xié)議）的SLA（Service Level Agreement，服務水平協(xié)議），以明確如果在DS域邊界處對由一個DS域傳給另一個DS域的數(shù)據(jù)進行調(diào)節(jié)。

19.6.3????邊界行為

19.6.4????無突發(fā)令牌桶算法

19.6.5????帶突發(fā)的雙令牌桶算法

19.6.6????主要標記方法

19.6.7????IP Precedence

19.6.8????DSCP

19.6.9????802.1p CoS

19.6.10 MPLS EXP

19.6.11????×××和丟棄

????×××（Shaping）的目的是使輸出的流量更加平滑，并保證其符合SLA。×××可以減少網(wǎng)絡(luò)流量的突發(fā)和振蕩，同時也降低丟棄的概率。×××器將超出承諾速率的報文放入一個緩沖區(qū)（buffer）中，當資源許可時再發(fā)送。緩沖區(qū)的存在減少了流量高峰期的丟包，但也會因此引入額外的延遲。緩沖區(qū)的空間通常是有限的，如果緩沖區(qū)空間不足，則被延遲發(fā)送的報文會被丟棄。

????丟棄（Dropping）的目的是限制流量的突發(fā)性，并保證其符合SLA。丟棄器對于超出承諾速率的報文直接丟棄。這雖然不利于平滑網(wǎng)絡(luò)流量，但避免了額外引入的延遲，降低了資源的消耗。這種操作也稱為流量監(jiān)管（Traffic Policing）。

19.6.12????PHB

????PHB（Per-hop Behavior，逐跳行為）指DS節(jié)點對行為聚合應用的可由外部觀測到的轉(zhuǎn)發(fā)行為。PHB是DS節(jié)點對行為聚合分配資源的方法。

????PHB可以通過占用帶寬、緩沖等資源的優(yōu)先級來定義，也可以通過延遲、抖動等可觀測的特性來定義。一個典型的PHB例子是為某兩地之間的數(shù)據(jù)流保留5%的鏈路帶寬。

????PHB具有單跳性和獨立性的特點，它規(guī)定了行為聚合在DS節(jié)點處獲得怎樣的服務。每個節(jié)點具有獨立的PHB策略，各節(jié)點、各域之間互相沒有影響。這也是Diffserv模型具有良好擴展性的原因之一。

????在DS節(jié)點上，PHB是通過一定的緩沖區(qū)管理和分組調(diào)度策略實現(xiàn)的。DS節(jié)點根據(jù)入站報文攜帶的標記為其提供適當?shù)腜HB。一個DS節(jié)點可以實現(xiàn)多種PHB。代碼點到PHB的映射關(guān)系可以是一對一的，也可以是多對一的。

19.7????IntServ模型

19.7.1????IntServ模型介紹

????IntServ（Integrated Service，綜合服務）模型由RFC 1633所定義，它可以滿足多種QoS需求。在這種模型中，節(jié)點在發(fā)送報文前，需要向網(wǎng)絡(luò)申請所需資源。這個請求是通過RSVP（Resource Reservation Protocol，資源預留協(xié)議）信令來完成。

????IntServ可以提供以下兩種服務：

????·保證服務：它提供保證的帶寬和延遲來滿足應用程序的要求。

????·負載控制服務：它保證即使在網(wǎng)絡(luò)過載的情況下，也能對報文提供與網(wǎng)絡(luò)未過載時類似的服務。即在網(wǎng)絡(luò)擁塞的情況下，也可以保證某些應用程序報文的低延遲和優(yōu)先通過。

19.7.2????IntServ體系結(jié)構(gòu)

????IntServ模型的范圍既涵蓋了網(wǎng)絡(luò)設(shè)備也涵蓋了主機，因而是一種端到端的服務。該模型要求數(shù)據(jù)流向上的每一跳設(shè)備都為每一個流單獨預留資源，同時在每一個流進行資源申請時進行準入控制。

????在發(fā)送數(shù)據(jù)之前，終端節(jié)點應用程序首先將其流量參數(shù)和需要的特定服務質(zhì)量以信令向網(wǎng)絡(luò)發(fā)起請求，這些參數(shù)包括帶寬、延遲等。網(wǎng)絡(luò)在收到應用程序的資源請求后，執(zhí)行資源分配檢查，即基于應用程序的資源申請和網(wǎng)絡(luò)現(xiàn)有的資源情況，判斷是否為應用程序分配資源。一旦網(wǎng)絡(luò)確認認為應用程序的資源申請和網(wǎng)絡(luò)現(xiàn)有的資源情況，判斷是否為應用程序分配資源。一旦網(wǎng)絡(luò)確認為應用程序分配資源，則網(wǎng)絡(luò)將為這個流（Flow，由兩端節(jié)點的IP地址、端口號、協(xié)議號確定）維護一個狀態(tài)，并基于這個狀態(tài)執(zhí)行報文的分類、流量監(jiān)管、排隊及其調(diào)度。收到網(wǎng)絡(luò)確認已預留資源的消息后，終端節(jié)點應用程序才開始發(fā)送報文。只要該數(shù)據(jù)流的流量在流量參數(shù)描述的范圍內(nèi)，網(wǎng)絡(luò)就會承諾滿足應用程序的QoS需求。

19.7.3????RSVP介紹

????RSVP（Resource Reservation Protocol，資源預留協(xié)議）是為IntServ模型設(shè)計的信令協(xié)議，用于在一條路徑的各節(jié)點上進行資源預留。RSVP工作在傳輸層，但只用于信息的傳遞，而不參與應用數(shù)據(jù)的傳送，是一種Internet上的控制協(xié)議。

????簡單來說，RSVP具有以下主要特點：

????·資源的申請具有單向性，即一對通信節(jié)點間可以在單方向申請資源，雙向的資源申請需獨立進行。

????·由接收者發(fā)起對資源預留的請求，并維護資源預留信息；

????·使用“軟狀態(tài)”（soft state）機制維護資源預留信息。

????????路由器在為每一條流進行資源預留時會沿著數(shù)據(jù)傳輸方向逐跳發(fā)送資源請求報文（Path消息），其中包含了自身對于帶寬、延遲等參數(shù)的需求信息。收到請求的路由器在進行記錄后再將Path消息發(fā)向下一跳。當報文到達目的地后，由接收端反向逐條發(fā)送資源預留報文（Resv消息）給沿途的路由器進行資源預留。

19.7.4????IntServ模型的特點

19.7.5????IntServ模型的主要應用

第20章????配置QoS邊界行為

????DS域（DS Domain）內(nèi)的節(jié)點可分為邊界節(jié)點和內(nèi)部節(jié)點。DS邊界節(jié)點負責區(qū)分和標記用戶數(shù)據(jù)，并根據(jù)SLA/TCA對數(shù)據(jù)進行一定的調(diào)節(jié)。內(nèi)部節(jié)點依據(jù)標記按照特定的PHB進行轉(zhuǎn)發(fā)。

20.2????分類

20.2.1????分類的實現(xiàn)

????在DS模型中，一個行為聚合（Behavior Aggregate,BA）中的流在轉(zhuǎn)發(fā)時將應用同一個PHB（Per-hop Behavior，逐跳行為），因此將獲得相同的QoS服務。分類的目的就是將符合條件的數(shù)據(jù)流劃分到相應的BA中，以便于后續(xù)的QoS機制做進一步處理。

????H3C路由器和交換機支持兩類分類機制，允許依據(jù)豐富的條件對報文進行分類：

????·自動分類：在接口上可以配置信任端口優(yōu)先級或信任報文優(yōu)先級。信任端口優(yōu)先級時將從本端口進入的所有報文歸為一類。信任報文優(yōu)先級時可以配置為依據(jù)報文攜帶的CoS、IP Precedence、DSCP或MPLS EXP等優(yōu)先級標記對其劃分類別。

????·手動分類：通用引用ACL等手段匹配報文的不同字段，以便依據(jù)報文的2-7層信息進行分類，這些信息包括MAC地址、VLAN號、IP地址、協(xié)議類型、傳輸層端口號、COS、IP Precedence、DSCP或MPLS EXP等。

20.3????流量監(jiān)管

20.3.1????流量監(jiān)管的實現(xiàn)

20.3.2????CAR的位置

20.3.3????CAR的原理

20.3.4????配置CAR實現(xiàn)流量監(jiān)管

20.4????標記

20.4.1????標記的實現(xiàn)

20.4.2????映射表標記的原理

20.4.3????CAR標記的原理

20.4.4????標記的配置

20.5????流量×××

20.5.1????流量×××的實現(xiàn)

20.5.2????GTS的位置

20.5.3???? GTS的原理

20.5.4????配置GTS實現(xiàn)流量×××

20.6????接口限速

20.6.1????接口限速介紹

20.6.2????接口限速的原理

20.6.3????接口限速的配置

20.7????流量監(jiān)管/×××配置示例

第21章????基本擁塞管理

????所謂擁塞，是指當前供給資源相對于正常轉(zhuǎn)發(fā)處理需要資源的不足，從而導致服務質(zhì)量下降的一種現(xiàn)象。擁塞有可能會引發(fā)一系列的負面影響。

????在擁塞發(fā)生時保證重要數(shù)據(jù)的正常傳送，是QoS的主要功能之一，也是一類最重要的PHB，相關(guān)的技術(shù)成為擁塞管理技術(shù)。

21.2????擁塞管理概述

21.2.1????擁塞與擁塞管理

????網(wǎng)絡(luò)的設(shè)備在某個時間內(nèi)接收到的數(shù)據(jù)總量可能會超過設(shè)備轉(zhuǎn)發(fā)接口的轉(zhuǎn)發(fā)能力，從而導致?lián)砣陌l(fā)生。比如，若路由器的告訴以太網(wǎng)連接到一個局域網(wǎng)，通過低速的WAN鏈路連接Internet，當局域網(wǎng)內(nèi)有大量用戶訪問Internet時，路由器的WAN鏈路的出方向?qū)l(fā)生擁塞。交換機設(shè)備也可能存在上行帶寬不夠而發(fā)生擁塞問題，比如若接口1和接口2接入的用戶都需要通過接口3上行訪問部門服務器，接口3與接口1和2速率相同，這樣當大量用戶同時訪問服務器時可能導致接口3發(fā)生擁塞。

????擁塞有可能會引發(fā)一系列的負面影響：

????·????擁塞增加了報文傳輸?shù)难舆t和抖動，可能會引起報文重傳，從而導致更多的擁塞產(chǎn)生；

????·????擁塞使網(wǎng)絡(luò)的有效吞吐率降低，造成網(wǎng)絡(luò)資源的利用率降低。

????·????擁塞加劇會耗費大量的網(wǎng)絡(luò)資源（特別是存儲資源），不合理的資源分配甚至可能導致系統(tǒng)陷入資源死鎖而崩潰。

????擁塞管理是指在網(wǎng)絡(luò)發(fā)生擁塞時，進行管理和控制，合理分配資源。處理的方法是使用隊列技術(shù)，將報文一定的策略緩存在隊列中，然后按一定調(diào)度策略把報文從隊列中取出，在接口上發(fā)送出去。不同的隊列調(diào)度算法解決不同的問題，并產(chǎn)生不同的效用。

21.2.2????路由器擁塞管理

????對于路由器設(shè)備，路由器的每個網(wǎng)絡(luò)接口都有一個物理的發(fā)送隊列，在被發(fā)送出接口之前，報文在發(fā)送隊列緩存。網(wǎng)絡(luò)接口接收的數(shù)據(jù)流量經(jīng)過轉(zhuǎn)發(fā)進程處理后被送到轉(zhuǎn)發(fā)出接口。如果該接口發(fā)送隊列不滿（不擁塞），則該報文直接轉(zhuǎn)入發(fā)送隊列轉(zhuǎn)發(fā)。否則進入軟件隊列緩存，軟件隊列包括系統(tǒng)隊列和用戶隊列，軟件隊列的調(diào)度策略決定哪些報文可以進入發(fā)送隊列進行轉(zhuǎn)發(fā)。

????系統(tǒng)隊列包括緊急和協(xié)議隊列，在擁塞時分別用來發(fā)送鏈路控制和路由協(xié)議報文。系統(tǒng)隊列的優(yōu)先級高于一般用戶隊列。需發(fā)送鏈路控制和路由協(xié)議報文時，可能正好遇到發(fā)送隊列滿而導致發(fā)送失敗，此時報文入緊急隊列或協(xié)議隊列緩存，等待后續(xù)發(fā)送。

????用戶隊列是指提供給用戶使用的，對各種業(yè)務流量進行擁塞管理的隊列技術(shù)。路由器常用的用戶隊列有FIFO、PQ、RTPQ、WFQ、CBQ等隊列，默認使用FIFO隊列，用戶可以通過命令配置自己需要的用戶隊列。交換機的SP、WRR等隊列也可以理解為用戶隊列。

注意：

????在Tunnel接口、子接口，或者封裝了PPPoE、PPPoA、PPPoEoA、PPPoFR協(xié)議的VT、Dialer接口上，要使隊列生效，需使能LR功能。

21.2.3????交換機擁塞管理

????相對于路由器產(chǎn)品，交換機處理的業(yè)務具有流量大、帶寬高的特點。因此交換機QoS要求告訴硬件處理，通常采用芯片實現(xiàn)QoS隊列。芯片中的隊列不能像軟件一樣靈活擴展，通常是固定數(shù)目的。交換機通常通過二層頭識別數(shù)據(jù)類，因此主要參照802.1p標記，三層交換機也可以識別DSCP等三層標記。

????交換機設(shè)備收到數(shù)據(jù)報文，先經(jīng)過轉(zhuǎn)發(fā)進程處理，然后根據(jù)優(yōu)先級的信任規(guī)則，查找QoS映射表，將報文映射到本地隊列。比如信任報文的DSCP優(yōu)先級，就根據(jù)報文的DSCP優(yōu)先級標記，查找DSCP到本地優(yōu)先級的映射表，根據(jù)映射結(jié)果對報文進行本地優(yōu)先級標記。報文的本優(yōu)先級和本地隊列是一一對應的關(guān)系。

????交換機的擁塞管理過程由芯片硬件實現(xiàn)，因此處理效率高，可以實現(xiàn)報文的線速轉(zhuǎn)發(fā)，但其支持的隊列類型卻沒有路由器那么豐富。交換機上常用的隊列有SP、WRR、HWFQ等。默認使用的隊列類型依產(chǎn)品型號的不同有所區(qū)別，比如有的產(chǎn)品默認使用SP隊列，有的默認使用WRR隊列。

注意：

????交換機的本地隊列數(shù)與硬件有關(guān)，不同設(shè)備、不同芯片支持的隊列數(shù)可能不同。

21.3????路由器擁塞管理

21.3.1????FIFO隊列原理

????FIFO（First In First Out Queuing，先入先出隊列）僅提供一個隊列，所有報文按到達轉(zhuǎn)發(fā)接口的時間先后順序入隊列，隊列長度達到最大值后，后續(xù)報文被丟棄。

????隊列調(diào)度時，首先看系統(tǒng)隊列是否為空，如果不空，則先發(fā)送系統(tǒng)隊列報文；如果系統(tǒng)隊列空，則按報文入隊列的時間順序，先入先出地發(fā)送FIFO隊列報文。

????FIFO隊列具有處理簡單，開銷小等優(yōu)點。但FIFO不區(qū)分報文類型盡力而為的轉(zhuǎn)發(fā)模式，使對時間敏感的實時應用（如VoIP）的延遲得不到保證，關(guān)鍵業(yè)務的帶寬也不能得到保證。

21.3.2????FIFO隊列配置

21.3.3????FIFO隊列顯示

21.3.4????PQ隊列原理

????PQ（Priority Queuing，優(yōu)先隊列）是針對關(guān)鍵業(yè)務設(shè)計的。關(guān)鍵業(yè)務有一個重要的特點，即在擁塞發(fā)生時要求優(yōu)先獲得服務以降低延遲、抖動和丟包率。

????PQ隊列提供4個隊列，分別為top（高優(yōu)先級隊列）、middle（中優(yōu)先隊列）、normal（正常優(yōu)先隊列）和bootom（低優(yōu)先隊列），它們的優(yōu)先級依次降低。在隊列調(diào)度時，PQ嚴格按照優(yōu)先級從高到低的次序，優(yōu)先發(fā)送較高優(yōu)先級隊列中的報文，保證較高優(yōu)先級報文的利益。

????PQ允許根據(jù)報文的協(xié)議類型、數(shù)據(jù)流入接口、長度、源地址/目的地址等靈活地指定其優(yōu)先次序。PQ數(shù)據(jù)包與定義的優(yōu)先級次序規(guī)則進行匹配，根據(jù)匹配結(jié)果將其送入對應的隊列；如果所有規(guī)則都不匹配，則將其送入缺省隊列。默認情況下，缺省隊列是正常優(yōu)先隊列。

????PQ對其4個隊列均使用尾丟棄策略。即隊列滿后，后續(xù)報文做丟棄處理。

21.3.5????PQ隊列調(diào)度

21.3.6????PQ隊列配置

????PQ隊列的配置過程主要分兩部分：

????·????配置PQL（Priority Queue List，優(yōu)先隊列列表）：系統(tǒng)預定義了16個PQL，用戶可以選擇其中的一個來配置自己需要的優(yōu)先隊列。配置內(nèi)容包括：

????·????PQ各隊列的匹配規(guī)則。

????·????各隊列的長度

????·????缺省隊列。

????·????PQ隊列應用到接口：引用配置好的PQL，在接口應用PQ隊列。系統(tǒng)預定義的PQL中沒有分類規(guī)則，將其應用到接口后，所有報文都入缺省隊列。

21.3.7????PQ隊列信息顯示

21.3.8????PQ隊列配置示例

21.3.9????CQ隊列原理

21.3.10????CQ隊列調(diào)度

21.3.11????CQ隊列配置任務

21.3.12 CQ隊列配置

21.3.13????CQ隊列信息顯示

21.3.14????CQ隊列配置示例

21.3.15????WFQ隊列原理

21.3.16????WFQ入隊機制

21.3.17????WFQ隊列調(diào)度

21.3.18????WFQ隊列特點

21.3.19????WFQ隊列配置與顯示

21.3.20????RTPQ隊列原理

21.3.21????RTPQ隊列調(diào)度

21.3.22????RTPQ隊列的配置與顯示

21.3.23????RTPQ配置示例

21.4????交換機擁塞管理

21.4.1????優(yōu)先級映射

21.4.2????SP隊列調(diào)度

21.4.3????WRR隊列調(diào)度

21.4.4????SP和WRR隊列混合調(diào)度

21.4.5????交換機隊列的配置和顯示命令介紹

21.4.6????交換機隊列配置示例

第22章????配置擁塞避免機制

????當擁塞發(fā)生時，利用隊列技術(shù)實現(xiàn)的擁塞管理機制可以對報文進行區(qū)分，并根據(jù)定義的規(guī)則提供服務。然而這種機制發(fā)揮作用的前提是所有的報文都能夠被恰當?shù)乃腿胩囟ǖ年犃小６旉犃斜惶顫M時，所有后續(xù)到達的報文都會被無差別的丟棄，此時隊列機制完全失效。同時這種從隊列尾部開始的截斷性丟棄還會導致一系列嚴重的問題。

????擁塞避免機制可以在相當程度上緩解或避免這種情況的發(fā)生。

22.2????尾丟棄及其導致的問題

????22.2.1????尾丟棄及其導致的問題

????當隊列被填滿時，所有后續(xù)到來的報文都會因無法入隊而丟棄，這種從隊尾開始的丟棄方式被稱為“尾丟棄”（Tail-drop）。尾丟棄是一種截斷性的丟棄方式，不對報文進行任何方式的區(qū)分。

????尾丟棄帶來的結(jié)果是高延遲、高抖動、喪失服務保證、TCP全局同步和TCP餓死等一系列問題。從而導致應用超時、數(shù)據(jù)重傳和業(yè)務不可用等種種后果。數(shù)據(jù)超時重傳的結(jié)果是進一步地加劇網(wǎng)絡(luò)擁塞。

22.2.2????TCP全局同步

????尾丟棄帶來的最重要的問題就是TCP全局同步。

????隊列滿時，所有報文在隊尾被全部丟棄。這種沒有差別的丟棄會造成所有TCP流的報文幾乎在同一時刻丟失，TCP又幾乎在同一時刻重傳。

????TCP在丟失報文時會自動縮小窗口尺寸。因而所有TCP連接的窗口會在幾乎同一時刻縮小。這樣鏈路帶寬會突然變得充足，因而TCP連接也會逐漸增大其窗口，這也幾乎是同時發(fā)生的。窗口增大后，流量會急劇增加，從而再次造成擁塞。這樣將造成所有TCP連接的流量以相同的“頻率”持續(xù)振蕩。這種現(xiàn)象稱為TCP全局同步。

????TCP全局同步的結(jié)果是TCP傳輸效率急劇下降，并且?guī)挼钠骄寐蚀蟠蠼档汀?/p>

22.2.3????解決尾丟棄的方法

????增加隊列的長度可以緩存更多的報文，因而降低了流量的突發(fā)性，減少尾丟棄的概率。但單純增加隊列長度并不能從根本上解決TCP同步的問題：

????隊列長度的增加是有限的，因而只能在有限范圍內(nèi)發(fā)揮作用，當流量比較大時這種方法幾乎無效。

????增加隊列長度的同時也加大了報文的平均延遲和抖動，這對某些應用是有害的。對實時業(yè)務而言，過大的延遲與丟包是等效的。

????TCP全局同步的根本原因是所有報文在同一時刻被無差別的丟棄。因此如果在尾丟棄發(fā)生前，使不同TCP連接的報文在不同時刻被丟棄，則各個TCP連接的流量振蕩就不會同步。

22.3????RED原理

????22.3.1????RED介紹

????

????RED（Random Early Detection，隨機早期檢測）技術(shù)的出現(xiàn)較好地解決了TCP全局同步的問題。它的做法是在隊列被填滿前就開始丟棄報文，并且隨著隊列長度的增加（擁塞發(fā)生的可能性增加）報文被丟棄的概率會越來越大，當超過一個最大丟棄概率時再全部丟棄到來的報文。

????RED的特點在于“早期”和“隨機”。早期表示丟失是在擁塞發(fā)生之前就開始進行的，這就意味著報文不必全部丟棄而可以有所“選擇”。而隨機則表明了這種丟棄行為是報文而不是以流為單位“無規(guī)律”進行的。隨機和早期的特點決定了所有TCP流的報文為單位，對于那些占據(jù)大量帶寬的非TCP的“野蠻”流來講，被丟棄的概率會更大，因而大大降低了TCP餓死的概率。

22.3.2????RED的參數(shù)和行為

22.3.3????RED的效果

22.4????WRED的原理

22.4.1????WRED介紹

????雖然RED很好的解決了TCP全局同步和餓死等問題，但由于其不能感知業(yè)務類型，對報文的丟棄不分輕重緩急，因此并沒有解決重要和緊急報文被丟棄的問題。

????WRED（Weighted RED，加權(quán)隨機早期檢測）技術(shù)較好的解決了上述問題。它允許為不同優(yōu)先級的報文配置不同的RED參數(shù)，從而保證了不同重要程度的報文獲得不同的服務。目前WRED可以利用DSCP和IP Precedence來區(qū)分數(shù)據(jù)。

22.4.2????基于IP Precedence的WRED參數(shù)和行為

22.4.3????基于DSCP的WRED參數(shù)和行為

22.4.4????WRED的效果

22.5????配置WRED

????22.5.1????基于接口的WRED配置命令

22.5.2????基于隊列的WRED表配置命令

22.5.3????WRED參數(shù)的意義

22.5.4????WRED顯示和維護命令

22.5.5????WRED配置示例

第23章????高級QoS管理工具

????CAR、GTS、PQ、CQ、WFQ、WRED等傳統(tǒng)的QoS工具能夠?qū)崿F(xiàn)標記、流量監(jiān)管、流量×××、擁塞管理、擁塞避免等各種QoS功能。但這些工具的配置互相獨立，各有不同，不便于記憶和使用。

????作為一種高級的QoS管理工具，QoS policy通過使用MQC（Modular QoS Configuration，模塊化QoS配置），將數(shù)據(jù)類型的定義與QoS動作的定義相分離，提高了配置的標準化和靈活性。其不僅可以作為任意類型的數(shù)據(jù)提供任意類型的QoS服務，而且允許復用類和動作的配置。

23.2????QoS Policy概述

23.2.1????QoS Policy介紹

????QoS policy包含三個要素：類（classifier）、行為（behavior）、策略（policy）。用戶可以通過QoS策略將指定的類和行為綁定起來，方便地進行QoS配置。

????類是用戶定義的一系列規(guī)則的集合，系統(tǒng)通過將報文與類中的規(guī)則進行匹配，根據(jù)匹配結(jié)果對報文進行分類。

????行為定義了針對報文所做的QoS動作。策略則用來將指定的類和行為綁定起來，并對分類后的報文執(zhí)行行為中定義的動作。

????用戶可以在一個策略中定義多個類與行為的綁定關(guān)系。這樣，系統(tǒng)就可以根據(jù)QoS policy對從屬于其中某一類的數(shù)據(jù)施加相應的行為。

????使用QoS policy可以實現(xiàn)分類、標記、×××、監(jiān)管、擁塞管理、擁塞避免、統(tǒng)計、鏡像、訪問控制、深度應用識別等多種QoS功能。

????每個QoS policy包含若干條目。每個條目為一個C-B（Class-Behavior）對，包含一個類和一個對應的行為。

????QoS policy被應用后，報文按條目的先后順序嘗試匹配其分類規(guī)則。匹配某類后則執(zhí)行對應的行為。一個行為可以包含多個動作，依次將其執(zhí)行完畢后，將結(jié)束QoS policy對此報文的處理，不再繼續(xù)匹配其他條目。若不匹配某類，則繼續(xù)嘗試匹配其他類。對于路由器產(chǎn)品，若不匹配任何類，則被認為屬于缺省類，系統(tǒng)將對其實施缺省行為。

23.2.2????QoS Policy配置任務

????使用QoS policy配置QoS的過程如上圖所示：

????·????首先需要定義類，在類中配置需要的分類規(guī)則；

????·????然后定義行為，在行為中定義需要的QoS動作。可以根據(jù)需要定義多個類及其對應的行為。

????·????隨后定義為QoS policy，在QoS policy中添加條目，引用定義的類與行為，完成類與行為的綁定。

????·????QoS policy定義完成后，可以根據(jù)需要在適當?shù)奈恢脩弥?/p>

????QoS policy常見的應用位置有：

????·????基于接口（或PVC）進行應用QoS policy：對通過接口（或PCV）接收/發(fā)送的流量生效。

????·????基于上線用戶應用QoS policy：對通過上線用戶接收/發(fā)送的流量生效。

????·????基于VLAN應用QoS policy：對通過同一個VLAN內(nèi)所有接口接收/發(fā)送的流量生效。

????·????基于全局應用QoS policy：對所有數(shù)據(jù)流量生效。

????·????基于控制平面應用QoS policy：對通過控制平面接收/發(fā)送的流量生效。

????注意：如果QoS policy應用在出方向，則QoS policy對本地協(xié)議報文不起作用。本地協(xié)議報文是設(shè)備內(nèi)部發(fā)起的。常見的本地協(xié)議報文有鏈路維護報文、IS-IS、OSPF、BGP、LDP、RSVP、SSH報文等。為了確保這些報文能夠被不受影響的發(fā)送出去，即便在出方向應用了QoS policy，其也不會受到QoS policy的限制，從而降低了因QoS誤配置而將這些報文丟棄或?qū)ζ涮峁┑偷燃壏盏娘L險。

23.2.3????類的定義

????類分為系統(tǒng)定義類和用戶定義類兩種。

????系統(tǒng)定義類是系統(tǒng)預先定義好的類，系統(tǒng)為這些類定義了通用的規(guī)則。定義QoS policy時可直接引用這些類。這些類包括：

????·缺省類：類名為default-class，不匹配QoS policy中其它任何分類的報文將被歸入缺省類；

????·基于DSCP的預定義類：包括ef、af1、af2、af3、af4，分別匹配IP DSCP值ef、af1、af2、af3、af4。

????·基于IP Precedence的預定義類：包括ip-prec0、ip-prec1、…Ip-prec7，分配匹配IP Precedence0、1、…7。

????·基于MPLS EXP的預定義類：包括mpls-exp0、mpls-exp1、…mpls-exp7，分別匹配MPLS EXP值0、1、7

????用戶不能修改或刪除系統(tǒng)定義的類。

????用戶定義類由用戶創(chuàng)建并維護。用戶可以根據(jù)下列標準定義用戶類：

????·????根據(jù)ACL分類；

????·????匹配所有的數(shù)據(jù)報文

????·????根據(jù)協(xié)議類型分類

????·????根據(jù)報文二層信息分類

????·????根據(jù)報文三層信息分類

????·????根據(jù)各類優(yōu)先級、標志位分類

????·????根據(jù)報文接收接口分類

????·????根據(jù)MPLS標簽分類

23.2.4????行為的定義

????在QoS policy中，一個行為可以包含多個QoS動作。這些動作依據(jù)特定的順序被執(zhí)行。

????路由器軟件的QoS動作順序依次為：流過濾、重標記、流量監(jiān)管、流量×××、擁塞管理。硬件QoS動作的支持情況以及執(zhí)行順序與具體的產(chǎn)品相關(guān)。

????

23.2.5????QoS policy

23.2.6????QoS Policy配置示例

23.2.7????基于VLAN的QoS Policy

????QoS policy應于VLAN后，會對VLAN內(nèi)所有端口上匹配規(guī)則的流量生效。

23.3????CBQ介紹

23.3.1????CBQ概述

????CBQ（Class Based Queuing，基于類的隊列）是一種基于QoS policy實現(xiàn)的擁塞管理技術(shù)。在網(wǎng)絡(luò)擁塞時，CBQ對報文根據(jù)用戶定義的類規(guī)則進行匹配，并使其進入相應的隊列。

????CBQ中包含一個LLQ（Low Latency Queuing，低延遲隊列），用來支撐EF（Expedited Forwarding，確保轉(zhuǎn)發(fā)）類業(yè)務，保證每一個隊列的帶寬及可控的延遲。

????CBQ中還包含一個缺省隊列，對應缺省分類，用于為缺省的BE（Best Effort，盡力傳送）類業(yè)務提供服務。其使用WFQ隊列調(diào)度，利用接口剩余帶寬進行發(fā)送。

23.3.2????CBQ入隊列處理

23.3.3????CBQ隊列調(diào)度

23.3.4????QoS預留帶寬

23.3.5????CBQ的配置過程

23.3.6????系統(tǒng)定義的CBQ

23.3.7????CBQ隊列配置

23.3.8????CBQ信息顯示

23.4????基于QoS policy的其它QoS功能介紹

????QoS policy不僅可以實現(xiàn)CBQ，依托其豐富的分類規(guī)則和QoS動作，以及靈活的配置方式，還可以實現(xiàn)包括CBPolicing（基于類的流量監(jiān)管）、CBShaping（基于類的×××）、CBMarking（基于類的標記）等在內(nèi)的諸多QoS功能。

23.4.1????基于QoS policy的監(jiān)管與×××配置示例

23.4.2????基于QoS policy的MPLS QoS配置示例

第24章????鏈路有效增強機制

????QoS的實質(zhì)是一種帶寬管理技術(shù)，它本身并不能創(chuàng)造帶寬，而只是更加合理的利用帶寬。在一些低速鏈路上，由于傳輸速率與數(shù)據(jù)流量的差距過大，盡管采用了一些帶寬管理技術(shù)，仍有可能無法滿足業(yè)務的需求。此時，一方面可以通過升級硬件來提高鏈路的數(shù)據(jù)傳輸能力，另一方面可以利用壓縮技術(shù)來降低數(shù)據(jù)傳輸量，從而達到提升吞吐量的目的。

????低速鏈路的另一個問題就是串行化延遲過長帶來的阻塞。當一個大報文被串行化到鏈路上時，其后續(xù)的小報文會較長時間的處于等待狀態(tài)，當這個等待時間足夠長時就會導致小包業(yè)務的超時或可用性下降。解決的辦法就是利用LFI（Link Fragmentaion & Interieaving，鏈路分片與交錯）技術(shù)，將一個大報文分成若干個小片并與其他的小報文交錯在一起發(fā)送，從而減少其他業(yè)務的等待時間。

24.2????壓縮的必要性

24.2.1????為什么需要壓縮

????數(shù)據(jù)通信本身的特點決定了線路上傳輸?shù)臄?shù)據(jù)不可能全部都是有效載荷。報文的頭（和尾）對網(wǎng)絡(luò)傳輸有用而對用戶應用而言是無用的信息。

????對某些小報文應用來說，報文頭作為非有效載荷占據(jù)了很大一部分帶寬。以VoIP報文為例，為了保持實時性，必須間隔很短的時間就發(fā)送一個報文，每個報文的語言載荷都較小，典型的載荷長度為20byte-160byte。一個20byte的語音報文被封裝了46byte的報文頭，包括IP頭、UPD頭、RTP頭。此外，對一個特定的數(shù)據(jù)流而言，其報文頭的信息變化較少。在這種情況下，有效載荷實際上只占到23%，絕大部分的帶寬被冗余信息所占據(jù)。這不僅造成帶寬的大量浪費，也導致語音報文的延遲顯著加大。

????此外，即使在作為凈載荷的用戶數(shù)據(jù)中也存在大量相同的字符串。這些對于帶寬緊張的低速鏈路來講也是某種程度的“浪費”。為了減少網(wǎng)絡(luò)流量和延遲，也應當盡可能的對載荷數(shù)據(jù)進行壓縮。

????對報文頭和載荷的壓縮減少了需要傳遞的數(shù)據(jù)量，從而間接增大了鏈路吞吐量。

24.2.2????壓縮的可行性

????依據(jù)其在傳輸中的變化情況，報文頭中的信息可以分為以下幾類：

????不變部分包括報文的源/目的IP地址、源/目的端口號、協(xié)議號、版本信息等。這些內(nèi)容在傳遞過程中保持不變，因此在會話初始時傳遞一次即可。

????·規(guī)律變化部分包括Packet ID、Sequence Number等內(nèi)容。這些內(nèi)容在傳遞過程中以簡單規(guī)律變化（如單調(diào)遞增），因此只需要在會話之初傳遞一次，之后每次傳遞一個變化量即可。

????·運算可獲得部分包括IP包長、校驗和等。IP包長可以依據(jù)報文頭尾計算獲得，而三層校驗和可以不同傳遞，依靠二層校驗和來保證正確性。

????·不規(guī)律變化部分是指報文頭中隨機變化的字段，這些字段沒有變化規(guī)律，因此需要完整傳遞。

????????載荷中的大量重復字符串也可以進行壓縮，方法是對重復出現(xiàn)字符串的位置用第一個字符串的偏移量和字符長度來代替。

24.3????IP頭壓縮

24.3.1????頭壓縮算法

24.3.2????頭壓縮的實現(xiàn)

24.3.3????頭壓縮的效果

24.3.4????IPHC頭壓縮配置命令

24.4????分片和交錯

24.4.1????低速鏈路的延遲和抖動問題

24.4.2????LFI原理

24.4.3????配置LFI

24.4.4????配置示例

第9篇????開放應用體系架構(gòu)

第25章????開放應用體系架構(gòu)

????隨著各種業(yè)務不斷地融入傳統(tǒng)數(shù)據(jù)通訊網(wǎng)絡(luò)，以及對網(wǎng)絡(luò)安全性、可管理性要求的不斷提高，用戶需要網(wǎng)絡(luò)設(shè)備在轉(zhuǎn)發(fā)數(shù)據(jù)包之外提供更多、更復雜、更靈活的服務。例如，用戶需要網(wǎng)絡(luò)設(shè)備能夠接入電話和傳真、統(tǒng)計和計費，防范網(wǎng)絡(luò)***、防病毒、流量監(jiān)管和調(diào)整等。這一切都對網(wǎng)絡(luò)設(shè)備提出了更高的要求。

????在傳統(tǒng)網(wǎng)絡(luò)中，上述功能由專用設(shè)備來獨立完成。但出于降低網(wǎng)絡(luò)建設(shè)、管理、維護成本的考慮，用戶往往希望能夠在一臺設(shè)備上完成多種功能。另外，還有很多用戶對網(wǎng)絡(luò)服務有個性化的需求，而往往一家獨大的技術(shù)廠商很難同時提供客戶所要求的所有需求和服務。

????面對這樣的情況，H3C提出了一個開放的軟硬件體系結(jié)構(gòu)——OAA（Open Application Architecture，開放應用體系架構(gòu)）。OAA允許對傳統(tǒng)的路由交換設(shè)備進行二次開發(fā)，滿足客戶的多樣化需求；允許眾多廠商生產(chǎn)的設(shè)備和軟件無縫集成在一起，像一臺設(shè)備那樣工作。

25.2????OAA概述

25.2.1????OAA架構(gòu)簡介

????傳統(tǒng)網(wǎng)絡(luò)模式最大的特點就是分工合作，客戶根據(jù)需求選擇不同的網(wǎng)絡(luò)設(shè)備，然后將它們通過IP網(wǎng)絡(luò)連接而成。比如選擇路由器完成基本路由、連接異構(gòu)網(wǎng)絡(luò)功能；交換機可以提供高密度、告訴主機接入；語音服務器、AAA服務器提供語音管理、認證計費等功能；防火墻提供基本安全功能；網(wǎng)管系統(tǒng)提供集中化設(shè)備監(jiān)控、管理功能。

????如果客戶有新的需求，比如在連接廣域網(wǎng)的路由器上實現(xiàn)應用加速，在網(wǎng)管平臺集成網(wǎng)絡(luò)流量分析，在防火墻上新增網(wǎng)絡(luò)殺毒應用，往往很難實現(xiàn)。一方面因為部分網(wǎng)絡(luò)設(shè)備是為1-3層功能、性能而設(shè)計的,而應用加速、網(wǎng)絡(luò)流量分析、網(wǎng)絡(luò)殺毒則要求網(wǎng)絡(luò)設(shè)備具備深度4-7層分析處理能力，而即使原有網(wǎng)絡(luò)設(shè)備實現(xiàn)了這些4-7層功能，也會占用網(wǎng)絡(luò)設(shè)備過多資源，從而影響網(wǎng)絡(luò)設(shè)備的1-3層功能和性能；另一方面因為這些網(wǎng)絡(luò)設(shè)備往往架構(gòu)封閉，新增功能只能由廠商開發(fā)、編譯、加載、客戶要求的新功能也不是廠商的專長，開發(fā)的新功能往往不能完全符合客戶業(yè)務需求。

????針對這種情況，H3C及時地提出OAA開放應用體系架構(gòu)，該架構(gòu)的特點在于不影響網(wǎng)絡(luò)設(shè)備固有1-3層功能、性能的同時，提供開放接口實現(xiàn)深度4-7層擴展。

????OAA架構(gòu)主要分為3個組成部分：

????·路由交換組件：路由交換組件是網(wǎng)絡(luò)設(shè)備主體部分，這部分有完整的路由器或交換機的功能，也是用戶管理控制的核心。????

????·獨立業(yè)務組件：獨立業(yè)務組件是OAA架構(gòu)的核心部分，是可以開放給第三方合作開發(fā)的主體，主要用來提供各種獨特的業(yè)務服務功能。

????·接口連接組件：接口連接組件是網(wǎng)絡(luò)設(shè)備和獨立業(yè)務組件的連接器件，它使各組件形成一個統(tǒng)一的產(chǎn)品。

????獨立業(yè)務組件可以分為硬件平臺、軟件平臺和特色業(yè)務3個平面，每個層面都是開放、標準的規(guī)范接口，可以進行靈活的二次開發(fā)。比如擅長硬件開發(fā)的第三方可以根據(jù)OAA規(guī)范開發(fā)獨立業(yè)務組件的硬件平臺部分，擅長軟件平臺開發(fā)的第三方可以在標準OAA硬件平臺上開發(fā)軟件平臺，擅長業(yè)務集成開發(fā)的第三方以在OAA標準軟件平臺上開發(fā)特色業(yè)務。

????OAA架構(gòu)優(yōu)勢在于全面的1-7層解決方案定制能力，使得網(wǎng)絡(luò)設(shè)備的擴展能力大增。

????傳統(tǒng)網(wǎng)絡(luò)的優(yōu)勢在于豐富的1-3層特性，附帶一定的4層特性和簡單的應用，但是4層以上特性擴展能力相對較弱。基于OAA架構(gòu)的網(wǎng)絡(luò)設(shè)備在1-3層功能特性和性能上與傳統(tǒng)網(wǎng)絡(luò)設(shè)備相當，同時通過開放的獨立業(yè)務組件而實現(xiàn)深度4-7層擴展。這種開放式的架構(gòu)不但使網(wǎng)絡(luò)設(shè)備廠商可以更加方便的集成更多高層特性，也有利于和第三方深度合作，共同開發(fā)符合市場需求的特性；甚至用戶也可以根據(jù)自身需要而在OAA平臺上進行靈活的二次開發(fā)。

25.2.2????開放業(yè)務平臺（OAP）

????開放應用平臺OAP（Open Application Platform）是H3C根據(jù)OAA架構(gòu)規(guī)范而實現(xiàn)的具體產(chǎn)品平臺。OAP實現(xiàn)了OAA架構(gòu)中的獨立業(yè)務組件功能，包括硬件平臺、軟件平臺和特色業(yè)務。OAP平臺具有開放的軟硬件接口、強大的數(shù)據(jù)處理能力以及靈活的工作模式等特點。

????通過OAP這個開放業(yè)務平臺，H3C可以向客戶提供特定的業(yè)務功能；也可以和第三方合作進行開發(fā)共同對客戶提供完整的業(yè)務；當然，用戶也可以根據(jù)需要在軟件平臺上進行二次業(yè)務開發(fā)。所有的一切都不影響傳統(tǒng)路由交換組件的自身功能。

25.3????OAA工作模式

25.3.1????主機模式

????OAP可以被二次開發(fā)為各種不同的業(yè)務系統(tǒng)，可以滿足各種業(yè)務特性需求。根據(jù)路由交換組件和業(yè)務組件之間的數(shù)據(jù)交互方式的不同，OAP提供了4種工作模式：主機模式、鏡像模式、重定向模式和透明模式（也稱為橋接模式）

????在主機模式下，獨立業(yè)務系統(tǒng)像網(wǎng)絡(luò)上的一臺主機一樣工作，擁有自己的IP地址，作為網(wǎng)絡(luò)末梢存在。IP報文是通過路由交換組件連接獨立業(yè)務組件的高速數(shù)據(jù)通道轉(zhuǎn)發(fā)，路由交換部件相當于獨立業(yè)務系統(tǒng)的網(wǎng)關(guān)。路由交換部件收到數(shù)據(jù)報文后，如果判斷出數(shù)據(jù)需要送給OAP模塊處理（目的IP地址為OAP模塊地址），則將此數(shù)據(jù)轉(zhuǎn)發(fā)給OAP模塊，OAP模塊處理完成后，將回應的報文返回路由交換組件，由路由交換部件將報文發(fā)送給相應的目的地。這種工作模式下，路由交換部件和獨立業(yè)務組件間的藕合是最松的。

????主機模式適合語音服務器、AAA服務器等應用。例如，當OAP模塊上集成了AAA服務器應用，則當認證請求報文到達網(wǎng)絡(luò)設(shè)備后，網(wǎng)絡(luò)設(shè)備根據(jù)路由信息將認證請求報文轉(zhuǎn)發(fā)給OAP模塊；OAP模塊上的AAA服務器根據(jù)認證請求報文中攜帶的用戶信息判斷認證是否通過，通過則返回正確授權(quán)報文，不通過則返回認證拒絕報文。不管是授權(quán)報文還是拒絕報文都轉(zhuǎn)交給網(wǎng)絡(luò)設(shè)備，網(wǎng)絡(luò)設(shè)備收到報文后根據(jù)路由/轉(zhuǎn)發(fā)信息選擇正確的出接口轉(zhuǎn)發(fā)報文。

25.3.2????鏡像模式

????鏡像模式下，路由交換部件根據(jù)要求，把特定的報文復制一份給獨立業(yè)務組件，原始報文繼續(xù)完成正常的轉(zhuǎn)發(fā)。而獨立業(yè)務組件收到這個報文以后進行分析和處理，然后將報文丟棄。當然路由交換組件和獨立業(yè)務組件也可以進行聯(lián)動，獨立業(yè)務組件分析完鏡像報文后可以下發(fā)聯(lián)動規(guī)則要求路由交換對相應業(yè)務流進行限速、阻斷等特殊處理。這種模式下，鏡像報文也是通過路由交換組件連接獨立業(yè)務組件的高速數(shù)據(jù)通道轉(zhuǎn)發(fā)。

????鏡像模式適用于網(wǎng)絡(luò)流量分析、***檢測IDS等應用。比如，網(wǎng)絡(luò)流量分析應用中，數(shù)據(jù)包進入網(wǎng)絡(luò)設(shè)備接口處理后被鏡像到OAP模塊，同時原報文被正常轉(zhuǎn)發(fā)。OAP中的網(wǎng)絡(luò)流量分析功能對鏡像報文進行分析，如果發(fā)現(xiàn)報文中占用大量帶寬的BT應用數(shù)據(jù)流，那么網(wǎng)絡(luò)分析應用程序會針對該鏡像報文所代表的數(shù)據(jù)流生成限速聯(lián)動規(guī)則，并下發(fā)給網(wǎng)絡(luò)設(shè)備，網(wǎng)絡(luò)設(shè)備應用該聯(lián)動規(guī)則就可以對BT流進行限速。

25.3.3????重定向模式

????在重定向工作模式下，數(shù)據(jù)包到達網(wǎng)絡(luò)設(shè)備接口后根據(jù)規(guī)則判斷是否被重定向，如果符合重定向規(guī)則那么將該報文重定向OAP模塊中。OAP模塊中的業(yè)務系統(tǒng)對重定向報文進行分析處理，然后根據(jù)處理結(jié)果判斷是否生成聯(lián)動規(guī)則并發(fā)送給網(wǎng)絡(luò)設(shè)備。根據(jù)不同業(yè)務的需求，重定向報文也有可能被返回給網(wǎng)絡(luò)設(shè)備，網(wǎng)絡(luò)設(shè)備對返回報文進行正常轉(zhuǎn)發(fā)。

????重定向模式所適用的業(yè)務比較廣泛，如***檢測、應用加速、網(wǎng)絡(luò)殺毒等。比如在網(wǎng)絡(luò)殺毒應用中，攜帶病毒的HTTP報文到達網(wǎng)絡(luò)設(shè)備后，根據(jù)配置的規(guī)則判斷應被重定向到OAP模塊中，模塊中的殺毒應用程序發(fā)現(xiàn)病毒并將病毒查殺，再下發(fā)聯(lián)動規(guī)則要求網(wǎng)絡(luò)設(shè)備過濾該HTTP站點。同時，OAP模塊上殺毒應用程序生成一個HTTP頁面返回給網(wǎng)絡(luò)設(shè)備，表示用戶訪問的網(wǎng)頁有病毒。網(wǎng)絡(luò)設(shè)備再將此HTTP頁面發(fā)送給訪問用戶，以通知用戶。

25.3.4????透明模式

????透明模式下，獨立業(yè)務組件像二層網(wǎng)橋設(shè)備一樣工作，不需要配置IP地址。外來的數(shù)據(jù)流從OAP模塊上的外部以太網(wǎng)接口流入，穿過獨立業(yè)務組件，經(jīng)過內(nèi)部高速數(shù)據(jù)通道到達路由交換組件。在路由交換組件看來，外部數(shù)據(jù)直接到達了連接部件上的高速以太網(wǎng)口，內(nèi)嵌的獨立業(yè)務系統(tǒng)似乎根本不存在一樣。實際上，當數(shù)據(jù)通過獨立業(yè)務系統(tǒng)的時候，獨立業(yè)務系統(tǒng)會做相關(guān)的記錄分析，必要的時候，業(yè)務系統(tǒng)還會對報文會做一定的修改以完成相關(guān)的功能。

????這種模式下，路由交換組件和獨立業(yè)務之間的耦合也是比較松的。

????這種工作模式適用于IPS/IDS、流量分析、應用加速等。

????在IPS/IDS應用中，報文抵達OAP外部接口后，IPS/IDS應用程序?qū)υ搱笪倪M行分析處理，如果檢測出來是***報文，則將該報文丟棄，并生成對應防火墻規(guī)則過濾該數(shù)據(jù)流；如果是正常報文則允許其通過。

25.4????聯(lián)動及管理

25.4.1????聯(lián)動

????OAA體系結(jié)構(gòu)中，路由交換組件與獨立業(yè)務組件是兩個獨立的主體，這兩個主體協(xié)作完成具體業(yè)務。為達到這種目的，兩者之間有時需要互通一些信息，這種信息交互就是聯(lián)動。簡單而言，就是指獨立業(yè)務組件可以向路由交換組件發(fā)指令，改變路由交換組件的動作。

????聯(lián)動功能主要是通過ACFP（Application Control Forwarding Protocol，應用控制轉(zhuǎn)發(fā)協(xié)議）來實現(xiàn)的。ACFP及基于SNMP協(xié)議而開發(fā)的管理協(xié)議。ACFP協(xié)議的運行過程與網(wǎng)管軟件運行有些類似。獨立業(yè)務組件就像網(wǎng)管系統(tǒng)一樣，向路由交換組件發(fā)送各種SNMP命令；而路由交換組件上支持SNMP Agent功能，可以執(zhí)行下發(fā)的這些命令。

????為了支持聯(lián)動功能，要求路由交換組件支持相關(guān)MIB。

25.4.2????管理

????除了聯(lián)動外，路由交換組件和獨立業(yè)務組件間還需要互相監(jiān)控、互相感知，有時還需要路由交換組件向獨立業(yè)務組件發(fā)送一些指令，指示獨立業(yè)務組件進行相應操作。這種路由交換組件ji監(jiān)控、指揮獨立業(yè)務組件的行為就是管理。

????路由交換組件對獨立業(yè)務組件的管理是通過ACSEI協(xié)議來完成的。通過ACSEI協(xié)議，路由交換部件可以區(qū)分不同插槽上的多個OAP模塊，監(jiān)控、記錄各個OAP模塊的運行狀態(tài)。路由交換組件與OAP模塊間還通過ACSIE協(xié)議來完成互相監(jiān)測、信息交互、時鐘同步等功能；路由交換組件還可以對OAP模塊下發(fā)如業(yè)務系統(tǒng)關(guān)閉、重新啟動等命令。

????通過路由交換組件和獨立業(yè)務組件之間的管理通道，已經(jīng)登錄到路由交換組件上的用戶，可以向獨立業(yè)務組件發(fā)起連接，登錄到獨立業(yè)務組件的控制臺上。

25.5????OAA典型應用

25.6????OAA的未來

轉(zhuǎn)載于:https://blog.51cto.com/rainy0426/2381385

總結(jié)

以上是生活随笔為你收集整理的H3C SE 教程笔记——构建安全优化的广域网（下）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。