基于IOS的IP服務(wù)水平協(xié)議SLA配置培訓(xùn)課件

83/84基于IOS的IP服務(wù)水平協(xié)議配置CiscoIOSSLA(以下簡稱IPSLA)基于CiscoSAA技術(shù)進(jìn)展而來，并在其基礎(chǔ)上進(jìn)行了增強(qiáng)，該特性讓用戶能夠監(jiān)測路兩臺Cisco路由器之間或Cisco路由器與一個遠(yuǎn)程的IP設(shè)備之間的網(wǎng)絡(luò)性能。本文集中討論了新的SLA（又稱作SAA）信息，包括使用與配置原則，如何從IPSLA中抽取數(shù)據(jù)，如何使用命令行(CLI)和SNMP來配置IPSLA等內(nèi)容。SNMP的MIB細(xì)節(jié)能夠參考Cisco-RTTMON-MIB。IPSLA概述IPSLA用途IPSLA能夠用于以下用途SLA監(jiān)測網(wǎng)絡(luò)性能監(jiān)測網(wǎng)絡(luò)服務(wù)評估端到端的可用性監(jiān)測網(wǎng)絡(luò)故障診斷MPLS網(wǎng)絡(luò)監(jiān)測VOIP網(wǎng)絡(luò)監(jiān)測IPSLA優(yōu)點(diǎn)增強(qiáng)布署新應(yīng)用的信心監(jiān)測與確認(rèn)服務(wù)質(zhì)量，實(shí)現(xiàn)差不服務(wù)增加用戶信心與用戶中意度通過SLA的度量，用戶能夠確認(rèn)他的網(wǎng)絡(luò)應(yīng)用照他們需要的那樣運(yùn)行網(wǎng)絡(luò)有問題時能夠預(yù)告提醒用戶能夠連續(xù)的、可靠的周期性度量網(wǎng)絡(luò)的性能IPSLA特性概述測量能力：能夠測量UDP響應(yīng)時刻、單向延時、抖動、掉包情況和連通性；ICMP響應(yīng)時刻與連通性、每一跳的ICMP響應(yīng)時刻與抖動；DNS查詢、TCP連接、HTTP處理時刻等的性能度量；丟包統(tǒng)計(jì)；DHCP響應(yīng)時刻測試；從網(wǎng)絡(luò)設(shè)備到服務(wù)器的響應(yīng)時刻；模擬Voip的codec’s測試出語音質(zhì)量的MOS/ICPIF得分；DLSw+通道性能；IPSLA能夠通過命令行或SNMP(Cisco-RTTMON-MIB)來實(shí)現(xiàn)前期告警，能夠定義SLA的監(jiān)測閾值，當(dāng)一個SLA達(dá)到閾值時能產(chǎn)生一個SNMPTRAP，同時能觸發(fā)相關(guān)的作業(yè)以實(shí)現(xiàn)更詳細(xì)的分析；IPSLA能夠?qū)崿F(xiàn)靈活的調(diào)度，能夠在任何給定的時刻或以任意的時刻間隔周期性運(yùn)行。圖1

CiscoIOSIPSLA使用IPSLA來度量網(wǎng)絡(luò)IPSLA是一個網(wǎng)絡(luò)性能度量與診斷工具，它通過主動在多個站點(diǎn)之間或多條路徑之間發(fā)送數(shù)量來實(shí)現(xiàn)對網(wǎng)絡(luò)性能的度量。IPSLA使用時標(biāo)來計(jì)算如抖動、延時、響應(yīng)時刻這、丟包率、語音MOS值等網(wǎng)絡(luò)性能參數(shù)。用戶通過命令行或RTTMONMIB能夠定義一個IPSLA動作（探針），定義IPSLA動作時能夠明確那個動作所產(chǎn)生的流量的包尺寸、發(fā)包間隔、協(xié)議類型、DSCP標(biāo)記以及其它一些參數(shù)；然后讓那個動作在適當(dāng)?shù)臅r候運(yùn)行并返回度量性能所需要的參數(shù)。例如，我們能夠定義一個用來度量UDP的抖動的動作，那個動作每分鐘每隔20ms發(fā)出10個64Bytes的包。由IPSLA探針?biāo)祷氐臄?shù)據(jù)存儲在RTTMONMIB中，能夠通過命令行或網(wǎng)絡(luò)治理應(yīng)用來提取其中的網(wǎng)絡(luò)性能統(tǒng)計(jì)數(shù)據(jù)。能夠讓IPSLA探針在任意時刻點(diǎn)或以任意的時刻間隔連運(yùn)行，通過設(shè)置不同的DSCP值，IPSLA能夠測試同一鏈路上不同類型的流量的性能。運(yùn)行CiscoIOS的目標(biāo)路由器能夠需要配置成IPSLAResponder(響應(yīng)器)，用于處理測試包并提供更詳細(xì)的時標(biāo)信息。響應(yīng)器能夠?qū)⒛繕?biāo)路由器的處理延時等信息發(fā)送回源路由器，如此在后期計(jì)算時那個處理延時就能夠去掉以提高測試的精確性。使用IPSLA時單向測量機(jī)制也是可行的。IPSLA利用SNMPtrap提供了預(yù)告警告機(jī)制，每個測試探針能夠預(yù)告配置一個性能閾值；當(dāng)結(jié)果超出閾值時，IPSLA將產(chǎn)生一個SNMPTRAP并發(fā)送到網(wǎng)管應(yīng)用上，可用的SNMPTrap包括：循環(huán)時刻、平均抖動、單向延時、抖動、丟包率、MOS值、連通性測試等，同時治理員也能夠定義IPSLA去執(zhí)行一個新的探針，例如當(dāng)延時超出閾值時能夠觸發(fā)第二個作業(yè)――測試每一跳的延時來將問題區(qū)域隔離出來。SLA監(jiān)測介紹概述企業(yè)IT部門向內(nèi)部客戶或其它部門提供SLA的壓力在不斷的增長，如何去度量外部提供的SLA也是一個大問題；服務(wù)供應(yīng)商為了提高客戶中意度也有提供SLA的動機(jī)；治理上需要確保網(wǎng)絡(luò)能滿足生產(chǎn)經(jīng)營活動的需要；終端用戶需要保證在他需要時，關(guān)鍵應(yīng)用與服務(wù)總是可用的；一個組織在布署一個新的技術(shù)、新的關(guān)鍵應(yīng)用或IP服務(wù)（如voip），通常需要一個SLA或服務(wù)水平的驗(yàn)證。交付SLA的復(fù)雜度日益增加，專門難決定要去監(jiān)測些什么，如何去度量，以什么樣的頻率去搜集數(shù)據(jù)。在一個復(fù)雜的多服務(wù)網(wǎng)絡(luò)中，要實(shí)現(xiàn)端到端的服務(wù)監(jiān)測也是相當(dāng)困難的。服務(wù)水平治理，包括SLA，是解決那個問題的一個關(guān)鍵組件，同時能夠增加網(wǎng)絡(luò)可用性。定義SLA需求在定義SLAs時，最為關(guān)鍵的是客戶所關(guān)注的事務(wù)處理目標(biāo)，只有在明確客戶關(guān)注什么的情況下，才能制定出切實(shí)可行的服務(wù)水平參數(shù)來。太多的、太復(fù)雜的不可行的參數(shù)往往會達(dá)不到治理服務(wù)水平的目標(biāo)，并受到客戶的責(zé)備。一份SLA越通用，SLA的需求也就越簡單，服務(wù)供應(yīng)商的SLA必須同時考慮連接性與主機(jī)應(yīng)用：SLA的度量是需要的能夠以合適的粒度去界定SLA問題出現(xiàn)SLA違背時能施以財(cái)務(wù)懲處可通過WEB訪問的商務(wù)報(bào)告和技術(shù)細(xì)節(jié)報(bào)告。在布署新的應(yīng)用時確定關(guān)鍵的業(yè)務(wù)目標(biāo)已達(dá)到服務(wù)水平合同與SLAsSLA是服務(wù)水平合同(SLC)中的關(guān)鍵組成部分，SLC定義了服務(wù)提供者向終端用戶提供的連接性與性能協(xié)議，服務(wù)提供者能夠在企業(yè)內(nèi)部(如企業(yè)內(nèi)的IT部門確實(shí)是其它部門的服務(wù)提供者)，也能夠是一家外部公司(如提供廣域連接、主機(jī)服務(wù)的的ISP)。一個SLC通常包括多個SLA，因此一個特定的SLA的違反會引起整個SLC的違反。服務(wù)水平治理解決方案需要提供一個能治理一個SLC內(nèi)所有SLA的解決方法。應(yīng)當(dāng)能獨(dú)立的監(jiān)測多個SLC及其相關(guān)的SLA，這通常包括了預(yù)期的服務(wù)水平和最小服務(wù)水平兩個參數(shù)，例如，一個為分支機(jī)構(gòu)和總部提供連接的SLC定義了一條64kbps的鏈路，要求在一個月的計(jì)算期內(nèi)，鏈路的平均延時在100ms以面，那個平均延時確實(shí)是預(yù)期的服務(wù)水平，這時的最小服務(wù)水平能夠是一天的計(jì)算期內(nèi)，平均延時在300ms以內(nèi)。端到端的SLC常用于性能監(jiān)測也失效治理，IPSLA提供了每一個SLA的細(xì)節(jié)信息。使用IPSLA監(jiān)測網(wǎng)絡(luò)用戶必須決定何時去監(jiān)測服務(wù)水平的參數(shù)值，那個過程中的一個重要阻礙因素是所考慮的SLA的類型，在決定何時監(jiān)測服務(wù)水平之間需要解決以下幾個問題。首先，用戶必須明白服務(wù)水平合同什么時候真正開始生效？度量的要緊目標(biāo)是什么？什么參數(shù)是需要監(jiān)測的重要參數(shù)？第二步要做的確實(shí)是對網(wǎng)絡(luò)中的流量模式進(jìn)行評估，度量采樣做得越多，所取得的流量模式就越準(zhǔn)確。更多的點(diǎn)意味著信息更精確，相反，更多的度量采樣潛在的引起治理流量的上午，讓可用帶寬變小?；顒拥亩攘繉⒛M網(wǎng)絡(luò)中的流量型號，例如正確的包尺寸，間隔等。例1：測量從分支機(jī)構(gòu)到中心辦公室的數(shù)據(jù)流量性能圖2

例1的網(wǎng)絡(luò)拓樸一個企業(yè)客戶有一個總部，和兩個分支機(jī)構(gòu)辦公室；其中一個分支機(jī)構(gòu)使用單獨(dú)的幀中繼電路(256Kbps)，另一個通過InternetVPN的方式訪問中心辦公室。兩個分支辦公室的用戶都需要訪問位于總部的web服務(wù)。例如，公司要求提供99.95%的可用性，響應(yīng)時刻要求小于50ms，關(guān)于通過InternetVPN訪問總部的分支機(jī)構(gòu)，提供了一個延時低于100ms的SLA?；谶@些數(shù)據(jù)，該企業(yè)必須考慮如何度量與驗(yàn)證兩個分支辦公室都能取開中意的服務(wù)水平，假如不能達(dá)到那個服務(wù)水平，就需要確認(rèn)是網(wǎng)絡(luò)中哪個/哪些部件(如廣域鏈路、客戶端應(yīng)用、Web服務(wù)器)導(dǎo)致了問題的產(chǎn)生。選擇適當(dāng)?shù)淖鳂I(yè)在SLA布署中的第一步確實(shí)是分析需要監(jiān)測哪些參數(shù)，在前面介紹過IPSLA所能提供的作業(yè)類型，下面對這些作業(yè)再作詳細(xì)的講明：

UDPEcho作業(yè)UDPECHO作業(yè)能夠測試從路由器到IP設(shè)備之間的端到端的響應(yīng)時刻或連通性，UDP是一個能夠報(bào)告錯誤并提供與IP包處理相關(guān)的其它信息的網(wǎng)絡(luò)層(第三層)協(xié)議，響應(yīng)時刻是通過計(jì)算發(fā)出UDPECHO消息和收到UDPecho響應(yīng)之間的時刻差來實(shí)現(xiàn)的。在目標(biāo)路由器上啟用IPSLAResponder能夠提高UDPecho的精度。在本文后面將詳細(xì)討論IPSLAResponder。

DNSDNS響應(yīng)時刻是通過計(jì)算發(fā)出DNS請求和接收到響應(yīng)之間的時刻差來實(shí)現(xiàn)的，那個作業(yè)可通過用戶提供的主機(jī)名查詢IP，也可通過用戶提供的IP地址查詢相應(yīng)的主機(jī)名。

DHCP，動態(tài)主機(jī)配置協(xié)議動態(tài)主機(jī)配置協(xié)議（DHCP）響應(yīng)時刻是計(jì)算從發(fā)出請求到收到響應(yīng)之間的差值實(shí)現(xiàn)的，當(dāng)取得IP地址后，源路由器會將那個IP釋放回地址池，從而幸免出現(xiàn)消耗大量IP地址的情況出現(xiàn)。HTTPHTTP作業(yè)能夠度量連接或從HTTP服務(wù)器訪問數(shù)據(jù)的往返時刻(RTT)，臺要通過一個URL來定義，HTTP服務(wù)器響應(yīng)時刻度量由以下三部分組成：DNS查詢—域名查詢的往返時刻RTTtakentoperformdomainnamelookupTCP連接—TCP連接處理的往返時刻HTTP處理時刻發(fā)出請求到從服務(wù)器收到響應(yīng)的往返時刻選擇適當(dāng)?shù)臏y試組合在定義一個SLA的過程中，最困難的確實(shí)是選擇適當(dāng)?shù)臏y試組合，在做這一步之前，必須先滿足以下條件：源設(shè)備必須是Cisco設(shè)備，同時能運(yùn)行IPSLA――IOS版本為12.0(5)T或更新；當(dāng)做IPSLA作業(yè)時，目的設(shè)備能夠是一個IP設(shè)備，使用Cisco路由器中的IPSLAResponder能夠提高測量精度當(dāng)這些條件滿足時，就能夠集中精力選擇設(shè)備組合了。一般情況下，源設(shè)備是邊緣的路由器或企業(yè)網(wǎng)絡(luò)與供應(yīng)商網(wǎng)絡(luò)的邊緣路由器。表1：本例中所選擇的測試組合：源目的作業(yè)講明CDUDP

ABUDP

BWeb服務(wù)器HTTP

DWeb服務(wù)器HTTP

AWeb服務(wù)器HTTP可選CWeb服務(wù)器HTTP可選以上就提供了廣域連接相關(guān)的細(xì)節(jié)，如DNS查詢時刻、TCP連接及最終的HTTP作業(yè)等。選擇適當(dāng)?shù)暮奢d荷載是包所承載內(nèi)容的實(shí)際尺寸，那個值與包本身的大小不一樣；依照協(xié)議類型的不同，包頭的長度也不同。在選擇荷載值時，必須考慮操縱包分片的最大傳輸單元(MTU)的阻礙，通過操縱與MTU相關(guān)的荷載尺寸，就能夠操縱每個采樣所發(fā)出的包的個數(shù)。那個值最好能和網(wǎng)絡(luò)中實(shí)際包的值相一致。Internet中平均包大小為260Bytes，那個客戶也使用那個包尺寸。

選擇適當(dāng)?shù)腡OS位本用戶未實(shí)施QOS，在那個例子中不涉及到TOS位選擇適當(dāng)?shù)牟蓸娱g隔IPSLA發(fā)送監(jiān)控流量采樣的頻率取決于需要和監(jiān)控流量本身對網(wǎng)絡(luò)帶寬的需求。采樣發(fā)生的頻率能夠基于取得最精確的網(wǎng)絡(luò)服務(wù)水平結(jié)論如此一個前提來考慮，但專門不幸，一般這是不現(xiàn)實(shí)的，在一個昂貴的廣域鏈路上，用戶可不能同意測試的流量占用太多帶寬的。在使用低端路由器時或有大量流量通過路由器時，還得考慮產(chǎn)生SLA流量對設(shè)備本身性能的阻礙。在這種情況下，需要降低采樣的頻率或使用一個單獨(dú)的路由器來做IPSLA作業(yè)。更細(xì)節(jié)的性能討論，請參見本文的后續(xù)章節(jié)。在那個例子中，我們選擇了如下的采樣間隔：UDP:60秒HTT：300秒選擇適當(dāng)?shù)挠蛑狄话闱闆r下，服務(wù)提供商在SLC中都會提供一個預(yù)先定義好的性能域值，ISP提供的SLA中可能包括總延時和可用性的百分比等參數(shù)。在這種情況下，選擇什么域值是專門清晰的。假如這些值都不明確，則需要網(wǎng)絡(luò)治理員來決定應(yīng)當(dāng)選擇什么樣的域值。目前域值能夠有響應(yīng)時刻和抖動計(jì)算，不適用于丟包率?，F(xiàn)實(shí)的域值案例:?單向延時:–西歐-美國西部:90ms–美國西部-美國東部:30ms–歐洲:40ms–西歐-非洲:150ms–西歐-北亞:100ms這些數(shù)據(jù)僅考慮了運(yùn)營商的骨干鏈路部分，接入層網(wǎng)絡(luò)增加的延時還必須增加進(jìn)來表2：本例中配置了如下閾值源目的度量域值A(chǔ)B往返延時<150ms>150ms或<100msCD往返延時<200ms>200ms或<150msA,B,C,DDNSDNS超時10sec>5s或<3sA,B,C,DWeb服務(wù)器TCP連接<500ms>500ms或＜200msA,B,C,DWeb服務(wù)器HTTP超時或5sec>2s或<1s例2:總部到分支機(jī)構(gòu)的電話會議圖3：例2網(wǎng)絡(luò)拓樸圖選擇適當(dāng)?shù)淖鳂I(yè)在例2中，業(yè)務(wù)經(jīng)理需要在總部和分支機(jī)構(gòu)之間召開電話會議，客戶差不多通過三個不同的類在鏈路上布署了QOS。在這種情況下，音頻和視頻在網(wǎng)絡(luò)中極度依靠于包的延時和丟包率。為VOIP選擇一個抖動作業(yè)，再為業(yè)務(wù)數(shù)據(jù)流量選擇一個UDP作業(yè)。未對盡力投遞類數(shù)據(jù)定義作業(yè)。抖動/VOIPVOIP作業(yè)，通過稱為抖動，度量了兩個方向上面包與包之間延時的變化（源到目的/目的到源），IPSLA以一個特定的間隔發(fā)出一系列的包，包的序號與時標(biāo)及響應(yīng)這些包的相關(guān)參數(shù)被搜集起來計(jì)算中間延時的變化。該測量方式在驗(yàn)證VOIP服務(wù)中相當(dāng)有用，使用抖動作業(yè)時需要在目標(biāo)設(shè)備上啟用IPSLAResponder。抖動作業(yè)與其它作業(yè)相比，提供了如下的些信息：抖動：源目的，目的源丟包情況：源目的，目的源往返時刻假如SLA與Responder的時鐘是同步的，能夠測試出單向延時最精確的作業(yè)包有序列號12.3(4)T開始提供MOS度量與Codec模擬12.3(7)T開始提供單向延時、抖動、丟包及MOS的Trap選擇適當(dāng)?shù)臏y試組合相關(guān)路由器:W,X,Y分支路由器:Z作業(yè):X到Z;Y到Z;W到Z選擇適當(dāng)?shù)暮奢d大小使用200Bytes的包尺寸選擇適當(dāng)?shù)腡OS字段從某種意義上來講，不同類型的流量在通過網(wǎng)絡(luò)時具有不同的優(yōu)先級。如某公司堅(jiān)信Email比WEB流量更為重要，它就可能為Email流量設(shè)置一個比Web流量更沒的優(yōu)先級。IPSLA能夠在IP頭中配置TOS位。假如在QOS策略中是使用的DSCP位，DSCP位需要轉(zhuǎn)化為TOS位輸入到IPSLA選項(xiàng)中去，因?yàn)槟壳暗腎PSLA特性不直接支持DSCP值。表三：定義三個不同的QOS類類IP優(yōu)先級DSCPTOSVoIP10140160業(yè)務(wù)數(shù)據(jù)10032128盡力投遞00000000表四：定義5個不同的QOS類類IP優(yōu)先級DSCPTOSVoIP10140160視頻10032128語音操縱流量01124096業(yè)務(wù)數(shù)據(jù)00108032盡力投遞00000000選擇適當(dāng)?shù)牟蓸娱g隔抖動使用10個間隔20ms的64bytes包作為一組，頻率如下：X-Z:60secY-Z:60secW-Z:180sec選擇適當(dāng)?shù)拈撝翟谀莻€SLA中沒有特定的閾值，治理員必須進(jìn)行獨(dú)立的測試，那個地點(diǎn)選擇了如下表所示的閾值。表五：本例中所用到的域值源目的度量閾值X—實(shí)時應(yīng)用Z雙向延時<100ms抖動<20ms>100ms或<50ms抖動>20msX—關(guān)鍵應(yīng)用Z雙向延時<500ms>500ms或<300ms,超時5secW—實(shí)時應(yīng)用Z雙向延時<100ms抖動<20ms>100ms或<50ms抖動>20msW—關(guān)鍵應(yīng)用Z雙向延時<500ms>500ms或<300ms,超時5secY—實(shí)時應(yīng)用Z雙向延時<100ms抖動<20ms>100ms或<50ms抖動>20msY—關(guān)鍵應(yīng)用Z雙向延時<500ms>500ms或<300ms,超時5secG.114標(biāo)準(zhǔn)建議單向延時(電話到電話)低于150ms是可同意的，我們建議延時不要過超過20-40msIPSLA配置與作業(yè)細(xì)節(jié)路由器處理延時因?yàn)檫€存在其它高優(yōu)先級應(yīng)用的緣故，路由器需要花約10個ms來處理進(jìn)入路由器的包。那個延時會阻礙到通過Ping技術(shù)計(jì)算出來的響應(yīng)時刻，因?yàn)轫憫?yīng)包中包括到在隊(duì)列中等待處理的時刻，如此，測試出來的響應(yīng)時刻就不是真正的網(wǎng)絡(luò)延時。IPSLA通過使用Responder，能夠?qū)⒙酚善鞯奶幚硌訒r從最終的計(jì)算結(jié)果中去掉從而保證測出來的是真正的往返延時。Responder與IPSLA操縱協(xié)議IPSLAResponder是內(nèi)置在Cisco路由器中的一個組件，用于響應(yīng)IPSLA的請求包。Responder在回顯包上打上時標(biāo)，從而能夠計(jì)算出單向丟包、延時及抖動參數(shù)。通過使用Responder，測試的精度也能夠達(dá)到令人中意的效果。IPSLA的精度大大好于ICMPping的精度，能夠參見如下文檔：/warp/public/cc/pd/iosw/prodlit/sanpo_wp.htm通過使用IPSLAResponder，能夠在源和目的設(shè)備之間使用一個專用的操縱協(xié)議，僅僅運(yùn)行CiscoIOS的設(shè)備才能成為IPSLA的源和IPSLAResponder的目的設(shè)備。IPSLAResponder能夠用于UDP抖動作業(yè)(必須)、UDPecho和TCP連接作業(yè)。當(dāng)目的路由器是Cisco路由器時，我們建議配置UDPecho和tcp連接時均使用Responder。而且不使用目的路由器上的Small-server.IPSLA能夠定義Responder所監(jiān)聽的端口，Responder在一個特定的端口上監(jiān)聽IPSLA作業(yè)的操縱信息。操縱信息攜帶了如協(xié)議、端口號、持續(xù)時刻等信息，一旦收到操縱信息，Responder將在特定的時刻內(nèi)開啟特定的UDP/TCP端口。然后Responder就在該端口上接收并響應(yīng)包，響應(yīng)完成或超過一個可能的時刻，就關(guān)閉剛才所開啟的端口。為了增加SLA操縱信息的安全性，用戶能夠使用MD5認(rèn)證。當(dāng)IPSLA作業(yè)需要目標(biāo)路由器上有Responder存在時會發(fā)生以下情況用戶初始化一個定義了目的路由器、協(xié)議及端口號的作業(yè)IPSLA向目標(biāo)路由器發(fā)送操縱信息假如啟用了MD5驗(yàn)證，MD5checksum和操縱信息一起發(fā)送假如消息中的驗(yàn)證字段是啟用的，Responder檢驗(yàn)驗(yàn)證字段假如SLA探針沒收到響應(yīng)，再將發(fā)送操縱信息直到超時假如Responder不能處理操縱信息，將返回錯誤，假如Responder處理了操縱信息，它將返回一條OK消息到源路由器，并在消息中所定義的端口上監(jiān)聽。當(dāng)返回碼是OK是，源路由器開始向Responder發(fā)送真正的測試包。圖4：源與Responder之間的度量時標(biāo)使用命令行啟動SLAResponder(config#)rtrresponder使用SNMP啟動SLAResponderrttMonApplResponder.0-Integer1使用命令行配置操縱協(xié)議的MD5驗(yàn)證需要在源路由器和目標(biāo)路由器上同時配置密鑰對，命令如下：(config#)keychain<name>(config-keychain#)key<number-1>(config-keychain-key#)key-string<authenticationstring>(config-keychain-key#)exit(config-keychain#)key<number-2>(config-keychain-key#)key-string<authenticationstring>(config-keychain-key#)exit(config#)rtrkey-chain<name>使用SNMP配置MD5驗(yàn)證當(dāng)前只能創(chuàng)建一個認(rèn)證表。rttMonApplAuthStatus.<index>-Integer4\rttMonApplAuthKeyChain.<index>-DisplayString"text"\rttMonApplAuthKeyString1.<index>-DisplayString"string"\rttMonApplAuthKeyString2.<index>-DisplayString"string"一量那個表創(chuàng)建好，就key-chain和key-strings就不能刪除，要刪除只能刪除個表格?？缮炜s的IPSLA布署通常情況下，IPSLA作業(yè)能夠單獨(dú)調(diào)度，每個目標(biāo)的測試都需要使用rtrschedule命令來進(jìn)行調(diào)度，順序執(zhí)行大量的SLA作業(yè)是IPSLA取得良好性能的關(guān)鍵之一?？紤]一個有100個作業(yè)的源，要將這100個作業(yè)調(diào)度到不同時刻去執(zhí)行顯然并不是一件專門容易的事。從IOS12.3(8)T開始，提供了多作業(yè)調(diào)度特性。具體的命令能夠參見相關(guān)的文檔。UDP作業(yè)UDP作業(yè)計(jì)算Cisco路由器和一個IP設(shè)備之間的UDP響應(yīng)時刻，響應(yīng)時刻通過計(jì)算發(fā)送一個數(shù)據(jù)報(bào)到目標(biāo)設(shè)備和從目標(biāo)設(shè)備收到響應(yīng)之間的間隔來實(shí)現(xiàn)。假如目標(biāo)設(shè)備是Cisco路由器，缺省情況下UDPsmall-server是關(guān)閉的，用戶能夠選擇通過serviceudp-small-server命令啟用系統(tǒng)IOS自帶的小的udp服務(wù)器。也能夠選擇啟動IPSLAResponder以提高測試精度。UDP作業(yè)在使用缺省的UDPechoport(UDPport7)，在使用IPSLAResponder的情況下，能夠自定義端口。響應(yīng)時刻計(jì)算如圖5所示，用戶在計(jì)算時能夠最小化處理延時，并將它從總的時延中減去。圖5

響應(yīng)時刻計(jì)算配置UDPEchoOperation(config)#rtr1(config-rtr)#typeudpechodest-ipaddrdest-port5000(config)#rtrsch1start-timenow檢查UDPEcho的統(tǒng)計(jì)信息R1#showrtropEntrynumber:1Modificationtime:*13:26:52.947PSTWedJun22004Numberofoperationsattempted:7Numberofoperationsskipped:0CurrentsecondsleftinLife:3227Operationalstateofentry:ActiveLasttimethisentrywasreset:NeverConnectionlossoccurred:FALSETimeoutoccurred:FALSEOverthresholdsoccurred:FALSELatestRTT(milliseconds):104Latestoperationstarttime:*13:32:52.955PSTWedJun22004Latestoperationreturncode:OK表六：UDPecho統(tǒng)計(jì)信息講明字段描述EntrynumberIPSLA作業(yè)號Modificationtime本作業(yè)的創(chuàng)建時刻N(yùn)umberofoperationsattempted已發(fā)送的作業(yè)數(shù)量Numberofoperationsskipped躍過的作業(yè)數(shù)量Currentsecondsleftinlife本作業(yè)在停止前還能運(yùn)行的時刻，這是一個可配置的參數(shù)Operationalstateofentry作業(yè)是否是活動的，并在測試網(wǎng)絡(luò)Lasttimethisentrywasreset作業(yè)被復(fù)位的最新時刻，復(fù)位能夠清空所有的的統(tǒng)計(jì)值Connectionlossoccurred是否發(fā)生過連接丟失Timeoutoccurred是否發(fā)生過超時Overthresholdsoccurred設(shè)置了閾值，并出現(xiàn)了超時現(xiàn)象LatestRTT(milliseconds)最后一次測試的往返時刻Latestoperationstarttime最后一次測試開始時刻Latestoperationreturncode作業(yè)狀態(tài)UDP抖動作業(yè)在網(wǎng)絡(luò)中有實(shí)時流量存在的情況下，度量網(wǎng)絡(luò)性能就不僅僅只考慮可用性了，更多的會關(guān)注網(wǎng)絡(luò)中的延時等參數(shù)，實(shí)時應(yīng)用與延時是緊密相關(guān)的。關(guān)于語音數(shù)據(jù)，丟包是比較容易處理的，但頻繁的丟包會引起通話質(zhì)量的下降。UDP抖動作業(yè)能在一個作業(yè)中提供丟包情況、抖動和延時參數(shù)，同時也能夠?qū)ｉT好的測試單向的參數(shù)。抖動作業(yè)被設(shè)計(jì)為通過產(chǎn)生活動的UDP流量來測試網(wǎng)絡(luò)中的延時、延時變化（抖動）丟包率等參數(shù)。它每次從源路由器發(fā)送N個大小為Sbyte的包到目的路由器，包之間的間隔為Tms，所有的這些參數(shù)差不多上用戶能夠配置的。基于抖動作業(yè)發(fā)出的包/接收到的包中所攜帶的時標(biāo)及序號信息，就能夠測量如每個方向的延時變化(抖動)，每個方向的丟包率，平均的往返時刻，單向延時[需要12.2(2)T或更新的IOS]等參數(shù)值。抖動計(jì)算源以10ms的間隔連續(xù)的向目的發(fā)出測試包，假如網(wǎng)絡(luò)運(yùn)行處于理想狀態(tài)，目的應(yīng)該以10ms的間隔收到這一系列的包。隊(duì)列、使用備用路由等因素所導(dǎo)致的延時會讓包到達(dá)目的路由器的間隔大于或小于10ms。正的抖動意味著兩個包到達(dá)的間隔大于10ms，如間隔12ms，這時正抖動確實(shí)是2ms，同理負(fù)抖動是指到達(dá)間隔小于原始間隔。在語音網(wǎng)絡(luò)中不希望有太大的抖動值，在一個對延時敏感的網(wǎng)絡(luò)中，最理想的情況是抖動為0。單向延時計(jì)算理論上，包從主機(jī)A到主機(jī)B所花的時刻在兩個方向上應(yīng)該完全一致，但在實(shí)際環(huán)境中，兩個方向上的延時可能有專門大的區(qū)不，有可能一個方向遠(yuǎn)遠(yuǎn)大于不一個方向?？紤]一條繁忙的高速公路，完全有可能在某一個方向上發(fā)生堵車的現(xiàn)象，在網(wǎng)絡(luò)中也存在同樣的現(xiàn)象。在源和目的之間也可能存在非對稱的路徑。單向延時計(jì)算為用戶提供了網(wǎng)絡(luò)中更詳細(xì)的性能。用戶能夠更方便的理解網(wǎng)絡(luò)中的瓶頸究竟在哪里。UPD抖動作業(yè)提供了單向延時的測試能力。然而，單向延時的測試需要源和目的路由器上的時鐘要相當(dāng)同步才行。這時需要使用基于GPS的NTP服務(wù)器，當(dāng)源與目的路由器的時鐘不同步時，IPSLA會忽略單向延時的計(jì)算，并填上0。單向抖動和丟包率不需要時鐘同步。通過命令行配置抖動作業(yè)(Config)#rtr200(config-rtr)#typejitterdest-ip00dest-port99num-packets20interval20針對抖動作業(yè)使用show命令R1#showrtrcollection-statisticsEntryNumber:1TargetAddress:00,PortNumber:31337StartTime:*14:14:14.000ESTThuApr62000RTTValues:NumOfRTT:2800RTTSum:4792RTTSum2:8830PacketLossValues:PacketLossSD:0PacketLossDS:0PacketOutOfSequence:0PacketMIA:0PacketLateArrival:0InternalError:0Busies:0JitterValues:MinOfPositivesSD:1MaxOfPositivesSD:1NumOfPositivesSD:249SumOfPositivesSD:249Sum2PositivesSD:249MinOfNegativesSD:1MaxOfNegativesSD:2NumOfNegativesSD:238SumOfNegativesSD:239Sum2NegativesSD:241MinOfPositivesDS:1MaxOfPositivesDS:1NumOfPositivesDS:97SumOfPositivesDS:97Sum2PositivesDS:97MinOfNegativesDS:1MaxOfNegativesDS:1NumOfNegativesDS:92SumOfNegativesDS:92Sum2NegativesDS:92Interarrivaljitterout:0Interarrivaljitterin:0OneWayValues:NumOfOW:0OWMinSD:0OWMaxSD:0OWSumSD:0OWSum2SD:0OWMinDS:0OWMaxDS:0OWSumDS:0OWSum2DS:0表7：showrtrcollection-statistics的各域的講明字段講明NumOfRTT成功的往返次數(shù)RTTSum全程時刻總和RTTSum2全程時刻平方和PacketLossSD源到目的丟失的包PacketLossDS目的到源丟失的包PacketOutOfSequence返回包序列號不正確的數(shù)量PacketMIA出現(xiàn)丟包，但方向不能確定，這通訊是一個測試流的最后一個包丟了。PacketLateArrival在超時之后到達(dá)的包的數(shù)量InternalError由于其它內(nèi)部錯誤導(dǎo)致作業(yè)不能正常運(yùn)行的次數(shù)Busies由于上次運(yùn)行未完成而導(dǎo)致本次不能運(yùn)行的次數(shù)＝MinOfPositivesSD

MaxOfPositivesSD源到目的的最小和最大正抖動（單位為MS）NumOfPositivesSD源到目的正抖動數(shù)量SumOfPositivesSD源到目的總的抖動值Sum2PositivesSD源到目的正抖動的平方和MinOfNegativesSD

MaxOfNegativesSD目的到源的最小和最大正抖動（單位為MS）NumOfNegativesSD目的到源正抖動數(shù)量SumOfNegativesSD目的到源總的抖動值Sum2NegativesSD目的到源正抖動的平方和應(yīng)用于VoIP的UDP抖動作業(yè)這一類UDP抖動作業(yè)是在當(dāng)前的UDP抖動作業(yè)基礎(chǔ)上的一個增強(qiáng)與擴(kuò)展，通過增強(qiáng)與擴(kuò)展之后，經(jīng)命令行或MIB配置，能夠通過模擬codec來實(shí)現(xiàn)對語音質(zhì)量的測試并直接得出語音質(zhì)量評分，目前12.3(4)T能夠支持如下幾種codec:711ALawG.711uLawG.729A命令如下：(config)#Rtr1(config-rtr)#typejitterdest-ipaddr<ipaddress>dest-port<portno>codec<codectype>codec-interval<value>codec-size<value>codec-numpacket<value>新的參數(shù)的選項(xiàng)如下表所示：Codectypecodec-sizecodec-intervalcodec-numpacketsG711ulaw17220ms1000G711alaw17220ms1000G729a3220ms1000VoIP作業(yè)使用ICPIF語音質(zhì)量評價系統(tǒng)事測試MOS值，能夠通過命令行和MIB存取活動的測試結(jié)果中的MOS值。那個測試能夠從應(yīng)用的角度看出來網(wǎng)絡(luò)性能參數(shù)對VoIP的支持程度。盡管ICPIF/MOS參數(shù)在評價語音質(zhì)量時是特不有用的，但它并沒有包括能夠阻礙到語音質(zhì)量的所有參數(shù)。更詳細(xì)的信息能夠參見如下的文檔：/univercd/cc/td/doc/product/software/ios123/123newft/123t/123t_4/gtsaamos.htm#1043332IOS12.3(7)T提供了基于單向抖動、丟包情況、延時及MOS/ICPIF語音得分參數(shù)設(shè)置反應(yīng)閾值或發(fā)出SNMPtrap的能力，詳細(xì)情況能夠參見如下鏈接：/en/US/products/sw/iosswrel/ps5207/products_feature_guide09186a008020a3c9.html以下命令行在12.3(7)T下測試通過：loggingon rtr10 typejitterdest-ipaddr25dest-port16384codecg711alawadvantage-factor2 owneradmin tagjitter-with-voice-scores rtrschedule10start-timenow rtrreaction-configuration10reactmosthreshold-typeimmediate\threshold-value490250action-typetrapOnly rtrloggingtraps snmp-serverhost0version2cpublic snmp-serverenabletrapssyslog12.3(7)T中的trap的實(shí)質(zhì)是syslog到traps的轉(zhuǎn)換，因此需要在命令行配置logging，在以后的版本中將提供純粹的SNMPtrap.下面是相關(guān)Show的結(jié)果Router#showrtroperational-state10Entrynumber:10Modificationtime:12:57:45.690UTCSunOct262003Numberofoperationsattempted:1Numberofoperationsskipped:0CurrentsecondsleftinLife:ForeverOperationalstateofentry:ActiveLasttimethisentrywasreset:NeverConnectionlossoccurred:FALSETimeoutoccurred:FALSEOverthresholdsoccurred:FALSELatestRTT(milliseconds):19Latestoperationstarttime:12:57:45.723SunOct262003Latestoperationreturncode:OK!VoiceScores:ICPIF:20MOSScore:3!RTTValues:NumOfRTT:10RTTAvg:19RTTMin:19RTTMax:20RTTSum:191RTTSum2:3649PacketLossValues:PacketLossSD:0PacketLossDS:0PacketOutOfSequence:0PacketMIA:0PacketLateArrival:0InternalError:0Busies:0JitterValues:NumOfJitterSamples:9MinOfPositivesSD:0MaxOfPositivesSD:0NumOfPositivesSD:0SumOfPositivesSD:0Sum2PositivesSD:0MinOfNegativesSD:0MaxOfNegativesSD:0NumOfNegativesSD:0SumOfNegativesSD:0Sum2NegativesSD:0MinOfPositivesDS:1MaxOfPositivesDS:1NumOfPositivesDS:1SumOfPositivesDS:1Sum2PositivesDS:1MinOfNegativesDS:1MaxOfNegativesDS:1NumOfNegativesDS:1SumOfNegativesDS:1Sum2NegativesDS:1Interarrivaljitterout:0Interarrivaljitterin:0OneWayValues:NumOfOW:0OWMinSD:0OWMaxSD:0OWSumSD:0OWSum2SD:0OWMinDS:0OWMaxDS:0OWSumDS:0OWSum2DS:0Router#showrtrcollection-statistics10Entrynumber:10StartTimeIndex:12:57:45.931UTCSunOct262003Numberofsuccessfuloperations:60Numberofoperationsoverthreshold:0NumberoffailedoperationsduetoaDisconnect:0NumberoffailedoperationsduetoaTimeout:0NumberoffailedoperationsduetoaBusy:0NumberoffailedoperationsduetoaNoConnection:0NumberoffailedoperationsduetoanInternalError:0NumberoffailedoperationsduetoaSequenceError:0NumberoffailedoperationsduetoaVerifyError:0VoiceScores:MinOfICPIF:2MaxOfICPIF:20MinOfMos:3MaxOfMos:5RTTValues:NumOfRTT:600RTTAvg:20RTTMin:19RTTMax:22RTTSum:12100RTTSum2:244292PacketLossValues:PacketLossSD:0PacketLossDS:0PacketOutOfSequence:0PacketMIA:0PacketLateArrival:0InternalError:0Busies:0JitterValues:NumOfJitterSamples:540MinOfPositivesSD:1MaxOfPositivesSD:1NumOfPositivesSD:26SumOfPositivesSD:26Sum2PositivesSD:26MinOfNegativesSD:1MaxOfNegativesSD:1NumOfNegativesSD:19SumOfNegativesSD:19Sum2NegativesSD:19MinOfPositivesDS:1MaxOfPositivesDS:1NumOfPositivesDS:43SumOfPositivesDS:43Sum2PositivesDS:43MinOfNegativesDS:1MaxOfNegativesDS:2NumOfNegativesDS:43SumOfNegativesDS:44Sum2NegativesDS:46Interarrivaljitterout:0Interarrivaljitterin:0OneWayValues:NumOfOW:0OWMinSD:0OWMaxSD:0OWSumSD:0OWSum2SD:0OWMinDS:0OWMaxDS:0OWSumDS:0OWSum2DS:0.ICMPEcho作業(yè)ICMPEcho作業(yè)能夠測試Cisco路由器和IP設(shè)備之間的端到端的響應(yīng)時刻，響應(yīng)時刻是通過計(jì)算ICMPecho請求與響應(yīng)消息的時刻差也教育處的。IPSLA通過在IP包中設(shè)置DSCP位，也同意用戶測量QOS的實(shí)施情況。響應(yīng)時刻計(jì)算如往常討論的一樣，在計(jì)算時，處理延時被最小化并在最終結(jié)果中減去。圖6：ICMPecho作業(yè)的響應(yīng)時刻計(jì)算ICMP荷載通過設(shè)置”requestsize”用戶能夠配置ICMPECHO作業(yè)的有效荷載尺寸，路由器將在定義的數(shù)值之上加上36Bytes，如定義的request-size是28Bytes，則實(shí)際的ICMP包的大小是64Bytes。配置ICMPecho作業(yè)(config)#rtr2(config-rtr)#typeechoprotocolipicmpecho(config-rtr-echo)#request-data-size400(config-rtr-echo)#tos160(config)#rtrsch2startnowICMPecho作業(yè)的show結(jié)果R1#showrtroperation2Entrynumber:2Modificationtime:*13:51:09.195PSTWedJun22004Numberofoperationsattempted:1Numberofoperationsskipped:0CurrentsecondsleftinLife:3545Operationalstateofentry:ActiveLasttimethisentrywasreset:NeverConnectionlossoccurred:FALSETimeoutoccurred:FALSEOverthresholdsoccurred:FALSELatestRTT(milliseconds):0Latestoperationstarttime:*13:51:09.203PSTWedJun22004Latestoperationreturncode:OKRTTValues:RTTAvg:0RTTMin:0RTTMax:0NumOfRTT:1RTTSum:0RTTSum2:0表8：ICMPecho作業(yè)的showrtroperation域描述：字段描述LatestRTT最后一次的往返時刻(ms)RTTAvg平均往返時刻(ms)RTTMin最小往返時刻(ms)RTTMax最大往返時刻(ms)NumofRTT已測試的往返個數(shù)RTTSum往返時刻之和RTTSum2往返時刻的平方和

ICMPPATHecho作業(yè)ICMPpathecho作業(yè)能夠測試出Cisco路由器到任IP設(shè)備之間的每一跳的響應(yīng)時刻，它使用traceroute命令來發(fā)覺到目的的路徑，然后測試源到路徑上每一個中間跳的響應(yīng)時刻。假如到目的地有多條等價路徑，通過在中間路由器上設(shè)置LSR參數(shù)，SLA能夠選擇一條特定的路徑進(jìn)行測試。差不多的配置命令如下：Router#rtr3 typepathEchoprotocolipIcmpEcho<ip_address> frequency10 lives-of-history-kept5 buckets-of-history-kept3 filter-for-historyallrtrschedule3life25start-timenowTCP連接作業(yè)TCP連接作業(yè)能夠測量出從Cisco路由器到任意IP設(shè)備之間進(jìn)行TCP連接所需要的時刻，如目標(biāo)設(shè)備是Cisco路由器，用戶能夠在目標(biāo)路由器上啟動IPSLAResponder。假如目標(biāo)設(shè)備不是Cisco路由器，用戶必須指定一個周知端口，如21、23、80等。圖7：TCP連接響應(yīng)時刻使用命令行配置TCP連接作業(yè)創(chuàng)建一個tcp連接作業(yè)，不需要IPSLAResponder，目的端口為80，命令如下，controldisable意味著不需要Responder(config)#rtr1(config-rtr)#typetcpConnectdest-ipaddrdest-port80controldisable(config)#rtrschedule1start-timenow創(chuàng)建一個需要Responder的tcp連接作業(yè)，命令如下：(config)#rtr1(config-rtr)#typetcpConnectdest-ipaddrdest-port8008(config-rtr)#tos4(config)#rtrschedule1start-timenowTCP連接作業(yè)的show輸出Router#shrtrop1 CurrentOperationalStateEntryNumber:1ModificationTime:14:17:10.000CETThuAug222002DiagnosticsText:LastTimethisEntrywasReset:NeverNumberofOctetsinusebythisEntry:1490ConnectionLossOccurred:FALSETimeoutOccurred:FALSEOverThresholdsOccurred:FALSENumberofOperationsAttempted:17CurrentSecondsLeftinLife:2603OperationalStateofEntry:activeLatestCompletionTime(milliseconds):6LatestOperationStartTime:14:33:10.000CETThuAug222002LatestOperationReturnCode:okLatest8DNS作業(yè)DNS作業(yè)用于測試DNS的響應(yīng)時刻，IPSLADNS作業(yè)既能夠測試從主機(jī)名到IP地址的查詢時刻，也能夠測試從不IP地址到主機(jī)名的查詢。配置命令如下：(config)#rtr1(config-rtr)#typednstarget-addrname-server0(config)#rtrschedule1start-timenowHTTP作業(yè)HTTP作業(yè)能夠度量從一個HTTP服務(wù)器訪問數(shù)據(jù)所需要的時刻，HTTP服務(wù)器響應(yīng)時刻分為如下幾個部分：域名查詢、TCP連接、發(fā)覺HTTP請求到收到HTTP響應(yīng)如此三個時刻。IPSLA支持三種類型的HTTP作業(yè)，分不描述如下：GET請求：基于定義的URL進(jìn)行格式化RAW模式：能夠?qū)ｉT靈活的的RAW數(shù)據(jù)的方式定義HTTP請求。能夠定義認(rèn)證信息等參數(shù)。針對特定的URL，取得第一個響應(yīng)字節(jié)所需要的時刻。圖8：HTTP響應(yīng)時刻定義

使用命令行定義HTTPget作業(yè)(config)#rtr1(config-rtr)#typehttpoperationgeturl/foo/(config)#rtrschedule1start-timenowShow的輸出如下：Router#shrtrop1Entrynumber:1Modificationtime:*22:01:31.895METSunApr111993Numberofoperationsattempted:1Numberofoperationsskipped:0CurrentsecondsleftinLife:3592Operationalstateofentry:ActiveLasttimethisentrywasreset:NeverConnectionlossoccurred:FALSETimeoutoccurred:FALSEOverthresholdsoccurred:FALSELatestRTT(milliseconds):193Latestoperationstarttime:*22:01:31.902METSunApr111993Latestoperationreturncode:OKLatestDNSRTT:4LatestTCPConnectionRTT:8LatestHTTPTransactionRTT:181LatestHTTPStatus:200LatestHTTPMessageSize:2842LatestHTTPEntity-Bodysize:2677相關(guān)字段意義描述：字段描述LatestRTTDNS、TCP連接、HTTP處理的響應(yīng)時刻之和LatestDNSRTTDNS查詢所響應(yīng)時刻LatestTCPConnectionRTTTCPSYN到ACK的響應(yīng)時刻LatestHTTPTransactionRTT:181取得文件第一字節(jié)所花的HTTP處理時刻LatestHTTPStatus:200HTTP完成所需要的時刻

使用命令行定義HTTP的RAW作業(yè)(config)#rtr6(config-rtr)#typehttpoperationrawurl(config-rtr)#http-raw-request(config-rtr-http)#GET/index.htmlHTTP/1.0\r\n(config-rtr-http)#\r\n(config-rtr-http)#exit使用命令行定義一個通過代理服務(wù)器的RAW作業(yè)本例中，是代理服務(wù)器，是實(shí)際需要訪問的服務(wù)器。(config)#rtr6(config-rtr)#typehttpoperationrawurlhttp://1.1.1(config-rtr)#http-raw-request(config-rtr-http)#GEThttp://2.2.(config-rtr-http)#\r\n(config-rtr-http)#exit(config)#rtrschedule6start-timenow使用命令行配置一個需要認(rèn)證的HTTPRAW作業(yè)(config)#rtr1(config-rtr)#typehttpoperationrawurl(config-rtr)#http-raw-request(config-rtr-http)#GET/lab/index.htmlHTTP/1.0\r\n(config-rtr-http)#Authorization:BasicbtNpdGT4biNvoZe=\r\n(config-rtr-http)#\r\n(config-rtr-http)#exit(config)#rtrschedule1start-timenowDHCP作業(yè)DHCP作業(yè)能夠測試出從了現(xiàn)一個DHCP服務(wù)器到從該DHCP服務(wù)器獲得一個地址所需要的時刻，在完成作業(yè)后，IPSLA將釋放租用到的地址。配置DHCP作業(yè)時，有兩種模式能夠選擇，缺省情況下從路由器的所有接口發(fā)出DHCP的discovery包，當(dāng)配置了ipdhcpserver命令時，discovery包只發(fā)到所定義的DHCP服務(wù)器。DLSW作業(yè)DLSW+是Cisco在RFC1795基礎(chǔ)上的一個增強(qiáng)，該協(xié)議使用TCP在IP骨干網(wǎng)上傳送SNA數(shù)據(jù)。路由器這這中間充當(dāng)DLSwpeer的角色。IPSLA中的DLSw+作業(yè)能夠測試在一對DLSwpeer之間的網(wǎng)絡(luò)響應(yīng)時刻，DLSwpeer一般使用2065的TCP端口。DLSw+作業(yè)只需要對端支持RFC1795，不需要對端是Cisco的路由器。FTP作業(yè)(12.1(1)T以后的IOS支持)FTP往往會攜帶大帶的流量，那個作業(yè)能夠測試出從主機(jī)到路由器的FTP吞吐量和響應(yīng)時刻，能夠?qū)ｉT好的刻畫出網(wǎng)絡(luò)的能力來。使用命令行定義一個FTP作業(yè)(config)#rtr1(config-rtr)#typeftpoperationget\urlftp://user:pwd@/test.cap(config)#rtrschedule1start-timenowFTP作業(yè)的show結(jié)果RT#shrtrop1Entrynumber:1Modificationtime:*04:02:36.295METMonApr121993Numberofoperationsattempted:6Numberofoperationsskipped:0CurrentsecondsleftinLife:3287Operationalstateofentry:ActiveLasttimethisentrywasreset:NeverConnectionlossoccurred:FALSETimeoutoccurred:FALSEOverthresholdsoccurred:FALSELatestRTT(milliseconds):4193Latestoperationstarttime:*04:07:36.299METMonApr121993Latestoperationreturncode:OKBytesread:2048000相關(guān)字段定義：字段描述LatestRTT取得文件所花的響應(yīng)時刻Bytesread讀取文件大小通過表中的兩個參數(shù)能夠計(jì)算出下載的帶寬來：2048000bytes/4.193s=488.4KB/s路徑抖動作業(yè)(自12.2T開始支持)IOS12.2T開始提供的路徑抖動作業(yè)能夠測試出網(wǎng)絡(luò)中每一跳的抖動、丟包率和延時參數(shù)，那個作業(yè)先通過traceroute發(fā)覺從源到目的的路徑，然后使用ICMPecho來測試出每一跳響應(yīng)時刻、丟包率及大約的抖動參數(shù)(基于RFC1889)。由于ICMP只包括一個往返時刻，因此那個作業(yè)的測試結(jié)果的精確度不高。該作業(yè)不能使用RTTMONMIB來進(jìn)行配置與讀取數(shù)據(jù)，因此只能通過命令行來進(jìn)行配置和查看結(jié)果。路徑抖動的配置命令(config)#rtr3(config-rtr)#typeicmpPathJitterdest-ipaddr<dest-ip>source-ipaddr<src_ip>num-packets<n>interval<t>在未定義num-packets及interval值時，缺省為情況下包數(shù)量為10個，間隔為20ms路徑抖動的show結(jié)果PathJitterStatisticsSourceIP -DestinationIP -0NumberofEchos -10IntervalbetweenEchos -20msTargetOnly -Disabled(default)HopIP:RTT:1 PacketLoss:0 Jitter:0MinRTT:1 MaxRTT:2 SumRTT:19 Sum2RTT:37MinPosJitter:1 MaxPosJitter:1 SumPos:1 Sum2Pos:1MinNegJitter:0 MaxNegJitter:0 SumNeg:0 Sum2Neg:0OutOfSequence:0 DiscardedSamples:0HopIP0:RTT:1 PacketLoss:0 Jitter:0MinRTT:1 MaxRTT:3 SumRTT:14 Sum2RTT:24MinPosJitter:2 MaxPosJitter:2 SumPos:2 Sum2Pos:4MinNegJitter:1 MaxNegJitter:1 SumNeg:2 Sum2Neg:2OutOfSequence:0 DiscardedSamples:0使用命令查看作業(yè)狀態(tài)使用如下命令查看SLA是否正確配置：showrtrapplicationshowrtrconfiguration使用如下命令查看作業(yè)運(yùn)行的結(jié)果showrtroperational-stateshowrtrdistributions-statisticsshowrtrcollection-statisticsshowrtrtotals-statisticsIPSLA的硬件及軟件需求IPSLA與IOS版本之間的關(guān)系各版本的IOS所支持的IPSLA作業(yè)特性特性/版本11.212.0(3)T12.0(5)T12.0(8)S12.1E12.1(1)T12.212.2(2)T12.2(11)T(Infra2)12.2(14)S12.2(25)SICMPEchoXXXXXXXXXICMPEchoPathXXXXXXXXXSSCP(SNA)XXXXXXtX

UDPEcho

XXXXXXXXTCPConnect

XXXXXXXXUDPJitter

XXXXXXXHTTP

XXXXXXXDNS

XXXXXXXDHCP

XXXXXXXDLSw+

XXXXXXXSNMPSupport

XXXXXXXUDPJitterOneWayLatency

XXXFTPGet

XXXXXMPLS/VPNAware

XX

XFrame-Relay(CLI)

XX

XICMPPathJitter

XX

XAPM

XX

XIPSLA的硬件支持情況IPSLA在除IPLite外的所有IOS軟件特性集中支持。IOS12.3版本使用了package來劃分特性集，除IPBASE以外，其它的package均支持IPSLA。將在12.4T的IPBASE中集成進(jìn)SLAResponder和ICMP作業(yè)的支持。除4500系列交換機(jī)外，所有支持IOS軟件的Cisco硬件均支持IPSLA。Linksys的設(shè)備將在以后提供Responder的支持。IPSLA的軟件架構(gòu)變遷從12.2(15)T2、12.3(3)、12.2S(25)、12.0(34)S開始，整個IPSLA的軟件架構(gòu)將進(jìn)行重寫，新的架構(gòu)稱為InfrastructureII，新的架構(gòu)增強(qiáng)了性能，降低了IPSLA的內(nèi)存占用。其它的增加還包括提高了精確度，提供基于NTP的時標(biāo)等。InfrastructureII還包括如下增強(qiáng)：自12.3(3)開始，IPSLA作業(yè)的數(shù)量僅受CPU能力和內(nèi)存的限制。在往常的版本中，12.2(11)T往常只能配置500個作業(yè)，12.2(11)T以后也只能配置2000個作業(yè)。SLA對內(nèi)存的占用降低了50%新的架構(gòu)所有的作業(yè)使用同一進(jìn)程，在往常，每個作業(yè)一個進(jìn)程。IPSLARTTMonMIB截止2004年9月，Cisco-RTTMON-MIB.my，只有FR、PathJitter、ATM三種作業(yè)不能支持。使用RTTMONMIB創(chuàng)建作業(yè)通過SNMP創(chuàng)建IPSLA作業(yè)能夠使用兩個命令：createAndGo和createAndWait。每個令在執(zhí)行前均需要定義如下一些變量：setrttMonCtrlAdminStatussetrttMonCtrlAdminRttTypesetrttMonEchoAdminProtocol關(guān)于每個作業(yè)，在它被提交前，還有一些作業(yè)相關(guān)的參數(shù)需要設(shè)置，如下所示：作業(yè)參數(shù)echo,pathEcho及dlswrttMonEchoAdminTargetAddressudpEcho、tcpConnect和jitterrttMonEchoAdminTargetAddressrttMonEchoAdminTargetPortHTTPrttMonEchoAdminURLDNSrttMonEchoAdminTargetAddressStringrttMonEchoAdminNameServerECHO作業(yè)示例rttMonCtrlAdminStatus.<index>-Integer4\rttMonCtrlAdminRttType.<index>-Integer1\rttMonEchoAdminProtocol.<index>-Integer2\rttMonEchoAdminTargetAddress.<index>-OctetString"04000001"\rttMonEchoAdminSourceAddress.<index>-OctetString"01000001"\rttMonEchoPathAdminHopAddress.<index>.1-OctetString"02000001"\rttMonEchoPathAdminHopAddress.<index>.2-OctetString"03000001"\rttMonScheduleAdminRttStartTime.<index>-TimeTicks1\rttMonScheduleAdminRttLife.<index>-Integer2147483647

PathEcho作業(yè)rttMonCtrlAdminStatus.<index>-Integer4\rttMonCtrlAdminRttType.<index>-Integer2\rttMonEchoAdminProtocol.<index>-Integer2\rttMonEchoAdminTargetAddress.<index>-OctetString"05000002"\rttMonScheduleAdminRttStartTime.<index>-TimeTicks1\rttMonScheduleAdminConceptRowAgeout.<index>-Integer0UDP作業(yè)rttMonCtrlAdminStatus.<index>-Integer4\rttMonCtrlAdminRttType.<index>-Integer5\rttMonEchoAdminProtocol.<index>-Integer3\rttMonEchoAdminTargetAddress.<index>-OctetString"05000002"\rttMonEchoAdminTargetPort.<index>-Integer4444\rttMonEchoAdminTOS.<index>-Integer5\rttMonScheduleAdminRttStartTime.<index>-TimeTicks1TCP作業(yè)rttMonCtrlAdminStatus.<index>-Integer4\rttMonCtrlAdminRttType.<index>-Integer6\rttMonEchoAdminProtocol.<index>-Integer24\rttMonEchoAdminTargetAddress.<index>-OctetString"05000002"\r