SNMP網(wǎng)絡(luò)管理體系結(jié)構(gòu)

第4章SNMP網(wǎng)絡(luò)管理體系結(jié)構(gòu)CMIP網(wǎng)絡(luò)管理體系結(jié)構(gòu)對系統(tǒng)模型、信息模型和通信協(xié)議幾個方面都提出了比較完備和理想的解決方案，為其他網(wǎng)絡(luò)管理體系結(jié)構(gòu)建立了理想?yún)⒖紭?biāo)準(zhǔn)。SNMP網(wǎng)絡(luò)管理體系結(jié)構(gòu)是為了管理基于TCP/IP協(xié)議的網(wǎng)絡(luò)而提出的，與TCP/IP協(xié)議與OSI協(xié)議的關(guān)系類似，SNMP與CMIP相比，突出的特點是簡單。這一特點使SNMP得到了廣泛的支持和應(yīng)用，特別是在Internet上的成功應(yīng)用，使得它的重要性越來越突出，目前已經(jīng)成為CMIP之外的最重要的網(wǎng)絡(luò)管理體系結(jié)構(gòu)。SNMP體系結(jié)構(gòu)4.1?1TCP/IP網(wǎng)絡(luò)管理的發(fā)展在TCP/IP的早期開發(fā)中，網(wǎng)絡(luò)管理問題并未得到太大的重視。直到70年代，還一直沒有網(wǎng)絡(luò)管理協(xié)議，只有互聯(lián)網(wǎng)絡(luò)控制信息協(xié)議(ICMP)可以作為網(wǎng)絡(luò)管理的工具。ICMP提供了從路由器或其它主機向主機傳送控制信息的方法，可用于所有支持IP的設(shè)備。從網(wǎng)絡(luò)管理的觀點來看，ICMP最有用的特性是回聲(echo)和回聲應(yīng)答(echoreply)消息對。這個消息對為測試實體間能否通信提供了一個機制。echo消息要求其接收者在echoreply消息中返回接收到的內(nèi)容。另一個有用的消息對是時間戳(timestamp)和時間戳應(yīng)答(timestampreply)，這個消息對為測試網(wǎng)絡(luò)延遲特性提供了機制。與各種IP頭選項結(jié)合，這些ICMP消息可用來開發(fā)一些簡單有效的管理工具。典型的例子是廣泛應(yīng)用的分組互聯(lián)網(wǎng)絡(luò)探索(PING)程序。利用ICMP加上另外的選項如請求間隔和一個請求的發(fā)送次數(shù)，PING能夠完成多種功能。包括確定一個物理網(wǎng)絡(luò)設(shè)備能否尋址，驗證一個網(wǎng)絡(luò)能夠?qū)ぶ?，和驗證一個主機上的服務(wù)器操作。PING在一些工具的配合下滿足了TCP/IP網(wǎng)絡(luò)初期的管理要求。但是到了80年代后期，當(dāng)互聯(lián)網(wǎng)絡(luò)的發(fā)展呈指數(shù)增加時，人們感到需要開發(fā)比PING功能更強并易于普通網(wǎng)絡(luò)管理人員學(xué)習(xí)和使用的標(biāo)準(zhǔn)協(xié)議。因為當(dāng)網(wǎng)絡(luò)中的主機數(shù)量上百萬，獨立網(wǎng)絡(luò)數(shù)量上千的時候，已不能只依靠少數(shù)網(wǎng)絡(luò)專家解決管理問題了。1987年11月發(fā)布了簡單網(wǎng)關(guān)監(jiān)控協(xié)議(SGMP),成為提供專用網(wǎng)絡(luò)管理工具的起點。SGMP提供了一個直接監(jiān)控網(wǎng)關(guān)的方法。隨著對通用網(wǎng)絡(luò)管理工具需求的增長，出現(xiàn)了3個有影響的方法。1?高層實體管理系統(tǒng)(HEMS):主機監(jiān)控協(xié)議(HMP)的一般化。簡單網(wǎng)絡(luò)管理協(xié)議(SNMP)：SGMP的升級版。TCP/IP上的CMIP(CMOT):最大限度地與OSI標(biāo)準(zhǔn)的CMIP、服務(wù)以及數(shù)據(jù)庫結(jié)構(gòu)保持一致。1988年，互聯(lián)網(wǎng)絡(luò)活動會議(IAB)確定了將SNMP作為近期解決方案進一步開發(fā)，而把CMOT作為遠期解決方案的策略。當(dāng)時普遍認為：TCP/IP不久將會過渡到OSI，因而不應(yīng)在TCP/IP的應(yīng)用層協(xié)議和服務(wù)上花費太多的精力。SNMP開發(fā)速度快，并能為網(wǎng)絡(luò)管理經(jīng)驗庫的開發(fā)提供一些基本的工具，可用來滿足眼前的需要。為了強化這一策略，IAB要求SNMP和CMOT使用相同的被管對象數(shù)據(jù)庫。即在任何主機、路由器、網(wǎng)橋以及其它管理設(shè)備中，兩個協(xié)議都以相同的格式使用相同的監(jiān)控變量。因此，兩個協(xié)議有一個公共的管理信息結(jié)構(gòu)(SMI),和一個管理信息庫MIB。但是，人們很快發(fā)現(xiàn)這兩個協(xié)議在對象級的兼容是不現(xiàn)實的。在OSI的網(wǎng)絡(luò)管理中，被管對象是很成熟的，它具有屬性、相關(guān)的過程、通報以及其它一些與面向?qū)ο笥嘘P(guān)的復(fù)雜的特性。而SNMP為了保持簡單性，沒有這樣復(fù)雜的概念。實際上，SNMP的對象在面向?qū)ο蟮母拍钕赂揪筒荒芊Q為對象，它們只是帶有一些如數(shù)據(jù)類型、讀寫特性等基本特性的變量。因此IAB最終放松了公共SMI/MIB的條件，并允許SNMP獨立于CMOT發(fā)展。從對OSI的兼容性的束縛中解脫后，SNMP取得了迅速的發(fā)展，很快被眾多的廠商設(shè)備所支持，并在互聯(lián)網(wǎng)絡(luò)中活躍起來。而且，普通用戶也選擇了SNMP作為標(biāo)準(zhǔn)的管理協(xié)議。SNMP最重要的進展是遠程監(jiān)控(RMON)能力的開發(fā)。RMON為網(wǎng)絡(luò)管理者提供了監(jiān)控整個子網(wǎng)而不是各個單獨設(shè)備的能力。除了RMON，還對基本SNMPMIB進行了擴充。有些擴充采用標(biāo)準(zhǔn)的網(wǎng)絡(luò)接口，例如令牌環(huán)(tokenring)和光纖分布數(shù)據(jù)接口(FDDI),這種擴充是獨立于廠商的。但是，單靠定義新的或更細致的MIB擴充SNMP是有限的。當(dāng)SNMP被用于大型或復(fù)雜網(wǎng)絡(luò)時，它在安全和功能方面的不足就變得明顯了。為了彌補這些不足，1992年7月發(fā)表了3個增強SNMP安全性的文件作為建議標(biāo)準(zhǔn)。增強版與原來的SNMP是不兼容的，它需要改變外部消息句柄及一些消息處理過程。但實際定義協(xié)議操作并包含SNMP消息的協(xié)議數(shù)據(jù)單元(PDU)保持不變，并且沒有增加新的PDU。目的是盡量實現(xiàn)向SNMP的安全版本的平滑過渡。但是這個增強版受到了另一個方案的沖擊。同樣是在1992年7月，四名SNMP的關(guān)鍵人物提出一個稱為SMP的SNMP新版本。并實現(xiàn)了四個可互操作的方案。兩個是商業(yè)產(chǎn)品，兩個是公開軟件。SMP在功能和安全性兩方面提高了SNMP，特別是SMP增加了一些PDU。所有的消息頭和安全功能都與提議的安全性增強標(biāo)準(zhǔn)相似。最終SMP被接受為定義第二代SNMP即SNMPv2的基礎(chǔ)。1993年安全版SNMPv2發(fā)布。經(jīng)過幾年試用以后，IETF(InternetEngineeringTaskForce)決定對SNMPv2進行修訂。1996年發(fā)布了一組新的RFC(RequestForComments)，在這組新的文檔中，SNMPv2的安全特性被取消了，消息格式也重新采用SNMPvl的基于“共同體(community)”概念的格式。刪除SNMPv2中的安全特性是SNMPv2發(fā)展過程中最大的失敗。主要原因是廠商和用戶對1993版的SNMPv2的安全機制不感興趣，同時IETF要求的修訂時間也非常緊迫，設(shè)計者們來不及對安全機制進行改善，甚至來不及對存在的嚴重缺陷進行修改。因此不得不在1996年版的SNMPv2中放棄了安全特性。1999年4月IETFSNMPv3工作組提出了RFC2571?RFC2576，形成了SNMPv3的建議。目前，這些建議正在進行標(biāo)準(zhǔn)化。SNMPv3提出了SNMP管理框架的一個統(tǒng)一的體系結(jié)構(gòu)。在這個體系結(jié)構(gòu)中，采用User-based安全模型和View-based訪問控制模型提供SNMP網(wǎng)絡(luò)管理的安全性。安全機制是SNMPv3的最具特色的內(nèi)容。4.1.2SNMP基本框架網(wǎng)絡(luò)管理體系結(jié)構(gòu)SNMP的網(wǎng)絡(luò)管理模型包括以下關(guān)鍵元素：管理站、代理者、管理信息庫、網(wǎng)絡(luò)管理協(xié)議。管理站一般是一個分立的設(shè)備，也可以利用共享系統(tǒng)實現(xiàn)。管理站被作為網(wǎng)絡(luò)管理員與網(wǎng)絡(luò)管理系統(tǒng)的接口。它的基本構(gòu)成為：?一組具有分析數(shù)據(jù)、發(fā)現(xiàn)故障等功能的管理程序；?一個用于網(wǎng)絡(luò)管理員監(jiān)控網(wǎng)絡(luò)的接口；?將網(wǎng)絡(luò)管理員的要求轉(zhuǎn)變?yōu)閷h程網(wǎng)絡(luò)元素的實際監(jiān)控的能力；?一個從所有被管網(wǎng)絡(luò)實體的MIB中抽取信息的數(shù)據(jù)庫。網(wǎng)絡(luò)管理系統(tǒng)中另一個重要元素是代理者。裝備了SNMP的平臺，如主機、網(wǎng)橋、路由器及集線器均可作為代理者工作。代理者對來自管理站的信息請求和動作請求進行應(yīng)答，并隨機地為管理站報告一些重要的意外事件。與CMIP體系相同，網(wǎng)絡(luò)資源也被抽象為對象進行管理。但SNMP中的對象是表示被管資源某一方面的數(shù)據(jù)變量。對象被標(biāo)準(zhǔn)化為跨系統(tǒng)的類，對象的集合被組織為管理信息庫(MIB)OMIB作為設(shè)在代理者處的管理站訪問點的集合，管理站通過讀取MIB中對象的值來進行網(wǎng)絡(luò)監(jiān)控。管理站可以在代理者處產(chǎn)生動作，也可以通過修改變量值改變代理者處的配置。管理站和代理者之間通過網(wǎng)絡(luò)管理協(xié)議通信，SNMP通信協(xié)議主要包括以下能力：Get:管理站讀取代理者處對象的值；Set:管理站設(shè)置代理者處對象的值；Trap:代理者向管理站通報重要事件。在標(biāo)準(zhǔn)中，沒有特別指出管理站的數(shù)量及管理站與代理者的比例。一般地，應(yīng)至少要有兩個系統(tǒng)能夠完成管理站功能，以提供冗余度，防止故障。另一個實際問題是一個管理站能帶動多少代理者。只要SNMP保持它的簡單性，這個數(shù)量可以高達幾百。網(wǎng)絡(luò)管理協(xié)議體系結(jié)構(gòu)SNMP為應(yīng)用層協(xié)議，是TCP/IP協(xié)議族的一部分。它通過用戶數(shù)據(jù)報協(xié)議(UDP)來操作。在分立的管理站中，管理者進程對位于管理站中心的MIB的訪問進行控制，并提供網(wǎng)絡(luò)管理員接口。管理者進程通過SNMP完成網(wǎng)絡(luò)管理。SNMP在UDP、IP及有關(guān)的特殊網(wǎng)絡(luò)協(xié)議(如，Ethernet,FDDI,X.25)之上實現(xiàn)。每個代理者也必須實現(xiàn)SNMP、UDP和IP。另外，有一個解釋SNMP的消息和控制代理者MIB的代理者進程。SNM管理站SNM管理站SNMP弋理者圖4.1SNMP的協(xié)議環(huán)境圖4.1描述了SNMP的協(xié)議環(huán)境。從管理站發(fā)出3類與管理應(yīng)用有關(guān)的SNMP的消息GetRequest、GetNextRequest、SetRequest。3類消息都由代理者用GetResponse消息應(yīng)答，該消息被上交給管理應(yīng)用。另外，代理者可以發(fā)出Trap消息，向管理者報告有關(guān)MIB及管理資源的事件。由于SNMP依賴UDP,而UDP是無連接型協(xié)議，所以SNMP也是無連接型協(xié)議。在管理站和代理者之間沒有在線的連接需要維護。每次交換都是管理站和代理者之間的一個獨立的傳送。3） 陷阱引導(dǎo)輪詢（Trap-directedpolling）如果管理站負責(zé)大量的代理者，而每個代理者又維護大量的對象，則靠管理站及時地輪詢所有代理者維護的所有可讀數(shù)據(jù)是不現(xiàn)實的。因此管理站采取陷阱引導(dǎo)輪詢技術(shù)對MIB進行控制和管理。所謂陷阱引導(dǎo)輪詢技術(shù)是：在初始化時，管理站輪詢所有知道關(guān)鍵信息（如接口特性、作為基準(zhǔn)的一些性能統(tǒng)計值，如發(fā)送和接收的分組的平均數(shù)）的代理者。一旦建立了基準(zhǔn)，管理站將降低輪詢頻度。相反地由每個代理者負責(zé)向管理站報告異常事件。例如，代理者崩潰和重啟動、連接失敗、過載等。這些事件用SNMP的trap消息報告。管理站一旦發(fā)現(xiàn)異常情況，可以直接輪詢報告事件的代理者或它的相鄰代理者，對事件進行診斷或獲取關(guān)于異常情況的更多的信息。陷阱引導(dǎo)輪詢可以有效地節(jié)約網(wǎng)絡(luò)容量和代理者的處理時間。網(wǎng)絡(luò)基本上不傳送管理站不需要的管理信息，代理者也不會無意義地頻繁應(yīng)答信息請求。4） 代管（Proxies）利用SNMP需要管理站及其所有代理者支持UDP和IP。這限制了在不支持TCP/IP協(xié)議的設(shè)備（如網(wǎng)橋、調(diào)制解調(diào)器）上的應(yīng)用。并且，大量的小系統(tǒng)（PC、工作站、可編程控制器）雖然支持TCP/IP協(xié)議，但不希望承擔(dān)維護SNMP、代理者軟件和MIB的負擔(dān)。為了容納沒有裝載SNMP的設(shè)備，SNMP提出了代管的概念。在這個模式下，一個SNMP的代理者作為一個或多個其他設(shè)備的代管人。即，SNMP代理者為托管設(shè)備（proxieddevices）服務(wù)。圖4.2顯示了常見的一類協(xié)議體系結(jié)構(gòu)。管理站向代管代理者發(fā)出對某個設(shè)備的查詢。代管代理者將查詢轉(zhuǎn)變?yōu)樵撛O(shè)備使用的管理協(xié)議。當(dāng)代理者收到對一個查詢的應(yīng)答時，將這個應(yīng)答轉(zhuǎn)發(fā)給管理站。類似地如果一個來自托管設(shè)備的事件通報傳到代理者，代理者以陷阱消息的形式將它發(fā)給管理站。SNMP管理站映射功能管理者進程托管設(shè)備使用的協(xié)議體系SNMPUDPIPSNMP管理站映射功能管理者進程托管設(shè)備使用的協(xié)議體系SNMPUDPIP依賴網(wǎng)絡(luò)的協(xié)議依賴網(wǎng)絡(luò)的協(xié)議代管代理者托管設(shè)備管理

進程托管設(shè)備

使用的協(xié)議體系依賴

網(wǎng)絡(luò)的協(xié)議圖4.2SNMP協(xié)議體系結(jié)構(gòu)SNMP管理信息與CMIP體系相同，SNMP的基礎(chǔ)是包含被管元素信息的被稱為MIB的數(shù)據(jù)庫。每個被管資源由對象來表示，MIB是這些對象的有結(jié)構(gòu)的集合。在SNMP中，MIB本質(zhì)上是一個樹型的數(shù)據(jù)庫結(jié)構(gòu)。網(wǎng)絡(luò)中每個的系統(tǒng)都(工作站、服務(wù)器、路由器、網(wǎng)橋等)擁有一個反映系統(tǒng)中被管資源狀態(tài)的MIB。網(wǎng)絡(luò)管理實體可以通過提取MIB中的對象值監(jiān)測系統(tǒng)中的資源，也可以通過修改這些對象值來控制資源。4.2.1管理信息結(jié)構(gòu)SNMP的規(guī)范SMI(structureofmanagementinformation)為定義和構(gòu)造MIB提供了一個通用的框架。同時也規(guī)定了可以在MIB中使用的數(shù)據(jù)類型，說明了資源在MIB中怎樣表示和命名。SMI的基本指導(dǎo)思想是追求MIB的簡單性和可擴充性。因此，MIB只能存儲簡單的數(shù)據(jù)類型：標(biāo)量和標(biāo)量的二維矩陣。我們將看到SNMP只能提取標(biāo)量，包括表中的單獨的條目。SMI避開復(fù)雜的數(shù)據(jù)類型是為了降低實現(xiàn)的難度和提高互操作性。但在MIB中不可避免地包含廠家建立的數(shù)據(jù)類型，如果對這樣的數(shù)據(jù)類型的定義沒有嚴格的限制，互操作性也會受到影響。為了提供一個標(biāo)準(zhǔn)的方法來表示管理信息，SMI必須：提供一個標(biāo)準(zhǔn)的技術(shù)定義MIB的具體結(jié)構(gòu)；提供一個標(biāo)準(zhǔn)的技術(shù)定義各個對象，包括句法和對象值；提供一個標(biāo)準(zhǔn)的技術(shù)對對象值進行編碼。1)MIB結(jié)構(gòu)SNMP中的所有的被管對象都被排列在一個樹型結(jié)構(gòu)之中。處于葉子位置上的對象是實際的被管對象，每個實際的被管對象表示某些被管資源、活動或相關(guān)信息。樹型結(jié)構(gòu)本身定義一個將對象組織到邏輯上相關(guān)的集合之中的方法。MIB中的每個對象類型都被賦予一個對象標(biāo)識符(OBJECTIDENTIFIER)，以此來命名對象。另外，由于對象標(biāo)識符的值是層次結(jié)構(gòu)的，因此命名方法本身也能用于確認對象類型的結(jié)構(gòu)。對象標(biāo)識符是能夠唯一標(biāo)識某個對象類的符號。它的值由一個整數(shù)序列構(gòu)成。被定義的對象的集合具有樹型結(jié)構(gòu)，樹根是引用ASN.1標(biāo)準(zhǔn)的對象。從對象標(biāo)識符樹的樹根開始，每個對象標(biāo)識符成分的值指定樹中的一個弧。從樹根開始，第一級有3個節(jié)點:iso、ccitt、joint-iso-ccitt。在iso節(jié)點下面有一個為“其他組織”使用的子樹，其中有一個美國國防部的子樹(dod)。SNMP在dod之下設(shè)置一個子樹用于Internet的管理。如下所示:internetOBJECTIDENTIFIER::={iso(1)org(3)dod(6)1}因此，internet節(jié)點的對象標(biāo)識符的值是1.3.6.1。這個值作為internet子樹的下級節(jié)點標(biāo)識符的前綴。SMI在internet節(jié)點之下定義了4個節(jié)點：directory為與OSI的directory相關(guān)的將來的應(yīng)用保留的節(jié)點mgmt用于在IAB批準(zhǔn)的文檔中定義的對象experimental用于標(biāo)識在Internet實驗中應(yīng)用的對象private用于標(biāo)識單方面定義的對象mgmt子樹包含IAB已經(jīng)批準(zhǔn)的管理信息庫的定義?，F(xiàn)在已經(jīng)開發(fā)了兩個版本的MIB，mib-1和和它的擴充版mib-2。二者子樹中的對象標(biāo)識符是相同的，因為在任何配置中，只有一個MIB。MIB中的mib-1或mib-2以外的對象可以用以下方法定義：由一個全新的修訂版(如mib-3)來擴充或取代mib-2?？梢詾樘囟ǖ膽?yīng)用構(gòu)造一個實驗MIB。這樣的對象隨后會被移到mgmt子樹之下。例如定義包含各種傳輸媒體的MIB(例如為令牌環(huán)局域網(wǎng)定義的MIB)。專用的擴充可以加在private子樹之下。private子樹目前只定義了一個子節(jié)點enterprises，用于廠商加強對自己設(shè)備的管理，與用戶及其他廠商共享信息。在enterprises子樹下面，每個注冊了enterprise對象標(biāo)識符的廠商有一個分支。internet節(jié)點之下分為4個子樹的做法為MIB的進化提供了很好的基礎(chǔ)。通過對新對象的實驗，廠商能夠在其被接受為mgmt的標(biāo)準(zhǔn)之前有效地獲得大量的實際知識。因此這樣的MIB既是對管理符合標(biāo)準(zhǔn)的對象直接有效的，對適應(yīng)技術(shù)和產(chǎn)品的變化也是靈活的。這一點也反映了TCP/IP協(xié)議的如下特性：協(xié)議在成為標(biāo)準(zhǔn)之前進行大量的實驗性的使用和調(diào)測。圖4.3對象標(biāo)識符樹型結(jié)構(gòu)2)對象句法SNMPMIB中的每個對象都由一個形式化的方法定義，說明對象的數(shù)據(jù)類型、取值范圍以及與MIB中的其他對象的關(guān)系。各個對象以及MIB的整體結(jié)構(gòu)都由ASN.1描述法定義。為了保持簡單，只利用了ASN.1的元素和特征的一個有限的子集。UNIVERSAL類型:ASN.1的UNIVERSAL類由獨立于應(yīng)用的通用數(shù)據(jù)類型組成。其中只有以下數(shù)據(jù)類型被允許用于定義MIB對象：integer(UNIVERSAL2)octetstring(UNIVERSAL4)null(UNIVERSAL5)objectidentifier(UNIVERSAL6)sequence,sequence-of(UNIVERSAL16)前3個是構(gòu)成其他對象類型的基本類型。objectidentifier唯一標(biāo)識對象的符號，由一個integer序列組成，序列中的integer被稱為子標(biāo)識符。對象標(biāo)識符的integer序列從左到右，定義了對象在MIB樹型結(jié)構(gòu)中的位置。sequence和sequence-of用于構(gòu)成表。APPLICATION-WIDE類型:ASN.1的APPLICATION類由與特定的應(yīng)用相關(guān)的數(shù)據(jù)類型組成。每個應(yīng)用，包括SNMP，負責(zé)定義自己的APPLICATION數(shù)據(jù)類型。在SNMP中已經(jīng)定義了以下數(shù)據(jù)類型：networkaddress:該類型用CHOICE結(jié)構(gòu)定義，允許從多個協(xié)議族的地址格式中進行選擇。目前，只定義了IpAddress一種地址格式。ipaddress:IP格式的32位地址。counter:只能做增值不能做減值運算的非負整數(shù)。最大值被設(shè)為232-1，當(dāng)達到最大值時，再次從0開始增加。gauge:可做增值也可做減值運算的非負整數(shù)。最大值被設(shè)為232-1，當(dāng)達到最大值時被鎖定，直至被復(fù)位(reset)。?timeticks:從某一參照時間開始以百分之一秒為單位計算經(jīng)歷的時間的非負整數(shù)。當(dāng)MIB中定義的某個對象類用到這個數(shù)據(jù)類型時，參照時間在該對象類的定義中指出。opaque:該數(shù)據(jù)類型提供一個傳遞任意數(shù)據(jù)的能力。數(shù)據(jù)在傳輸時被作為OCTETSTRING編碼。被傳遞的數(shù)據(jù)本身可以是由ASN.1或其他句法定義的任意的格式。3） 定義對象管理信息庫由一個對象的集合構(gòu)成，每個對象都有一個型和一個值。型是對被管對象種類的定義，因此型的定義是一個句法描述。對象的實例是某類對象的一個具體實現(xiàn)，具有一個確定的值。怎樣定義MIB中的對象呢？ASN.1是將被使用的描述法。ASN.1中包含一些預(yù)定義的通用類型，也規(guī)定了通過現(xiàn)有類型定義新類型的語法。定義被管對象的一個可選方法是定義一個被稱為Object的新類型。這樣，MIB中所有的對象都將是這種類型的。這個方法在技術(shù)上是可行的，但會產(chǎn)生定義不便于應(yīng)用的問題。我們需要多種值的類型，包括counter、gauge等等。另外，MIB支持二維表格或矩陣的定義。因此，一個通用的對象類型必須包含參數(shù)來對應(yīng)所有這些可能性和選擇性。另一個更有吸引力的方法，并且也是被SNMP所實際采用的方法是利用宏（macro）對在被管對象定義中相互關(guān)聯(lián)的類型進行集合定義。一個宏的定義給出相關(guān)類型集合的句法，而宏的實例定義一個特定的類型。因此定義被分為以下等級：宏：定義合法的宏實例，即說明相關(guān)集合類型的句法宏實例：通過為宏定義提供實際參數(shù)生成實例，即說明一個特定的類型宏實例值：用一個特定的值來表示一個特定的實體圖4.4是OBJECT-TYPE宏的定義（引自RFC1212）。圖4.4被管對象宏其中的主要項目是:SYNTAX:對象類的抽象句法，該句法必須從SMI的對象句法類型中確定一種類型。ACCESS:定義通過SNMP或其他協(xié)議訪問對象實例的方法。Access子句定義該對象類型支持的最低等級。可選的等級有:read-only、read-write、write-only和not-accessible。STATUS:指出該對象在實現(xiàn)上的要求。要求可以是:mandatory（必須）、optional（可選）、deprecated（懇求一必須實現(xiàn)的對象，但很可能在新版MIB中被刪除）和obsolete（廢除一不再需要被管系統(tǒng)實現(xiàn)的對象）。DescrPart:對象類型語義的文本描述。該子句是可選的。ReferPart:對定義在在其他MIB模塊中的某個對象的文本型交叉引用。該子句是可選的。IndexPart:用于定義表。該子句只是在對象類型對應(yīng)表中的”行”時才出現(xiàn)。DefValPart:定義一個默認值，用于建立對象實例。該子句是可選的。VALUENOTATION:指出通過SNMP訪問該對象時使用的名字。由于應(yīng)用OBJECT-TYPE宏的MIB的完整的定義包含在MIB的冗長的文檔中，因此，人們并不常使用它們。比較常用的是更簡捷的方法—基于樹型結(jié)構(gòu)和對象特性的表格表示的方法。4） 定義表格SMI只支持一種數(shù)據(jù)結(jié)構(gòu)化方法:標(biāo)量值條目的二維表格。表格的定義用到ASN.1的sequence和sequenceof兩個類型和OBJECT-TYPE宏中的IndexPart。表格定義方法可以通過實例進行說明?？紤]對象類型tcpConnTable,這個對象包含由相應(yīng)的被管實體維護的TCPconnections的信息。對于每個這樣的connection，以下信息在表中存儲：state:TCPconnection的狀態(tài)localaddress:該connection的本端的IP地址localport:該connection的本端的TCP端口remoteaddress:該connection的另一端的IP地址remoteport:該connection的另一端的TCP端口需要注意的是，tcpConnTable是存放在某個被管系統(tǒng)維護的MIB中。因此，tcpConnTable中的一個條目對應(yīng)被管系統(tǒng)中的一個connection的狀態(tài)信息。TCPconnection的狀態(tài)信息有22個項目，按照tcpConnTable的定義，只有上述5個項目對網(wǎng)絡(luò)管理者來說是可見的。這也體現(xiàn)了SNMP強調(diào)保持網(wǎng)絡(luò)管理簡單性的特點。即，在被管對象中，只包含相對應(yīng)的被管實體的有限的和有用的信息。圖4.5給出了tcpConnTable的定義（引自RFC1213）。圖4.5TCPconnectionTable在圖4.5中，可以看到sequence和sequenceof在定義表格時的應(yīng)用:整個表由一個SEQUENCEOFTcpConnEntry構(gòu)成。ASN.1的結(jié)構(gòu)SEQUENCEOF由一個或多個相同的元素構(gòu)成，在本例中（在所有的SNMPSMI的情況下）每個元素是表中的一行。每一行由一個指定了5個標(biāo)量元素的SEQUENCE構(gòu)成。ASN.1的結(jié)構(gòu)SEQUCECE由固定數(shù)目的元素組成，元素的類型可以是多種。盡管ASN.1允許這些元素是可選的，但SMI限制這個結(jié)構(gòu)只能使用“mandatory”元素。在本例中，每一行所包含的元素的類型是INTEGER,IpAddress,INTEGER,IpAddress,INTERGE。tcpConnEntry定義中的INDEX成分確定哪個對象值將被用于區(qū)分表中的各行。在TCP中,一個socket（IP地址，TCP端口）可以支持多個connection，而任意一對sockets之間同時只能有一個connectiono因此為了明確地區(qū)分各行，每行中的后4個元素是必要的，也是充分的。MIB-II在TCP/IP網(wǎng)絡(luò)管理的建議標(biāo)準(zhǔn)中，提出了多個相互獨立的MIB，其中包含為Internet的網(wǎng)絡(luò)管理而開發(fā)的MIB-II。鑒于它在說明標(biāo)準(zhǔn)MIB的結(jié)構(gòu)、作用和定義方法等方面的重要性和代表性，有必要對其進行比較深入的討論。MIB-II是在MIB-I的基礎(chǔ)之上開發(fā)的，是MIB-I的一個超集。mib-2組被分為以下分組：system:關(guān)于系統(tǒng)的總體信息；interface:系統(tǒng)到子網(wǎng)接口的信息；at（addresstranslation）:描述internet到subnet的地址映射；ip：關(guān)于系統(tǒng)中IP的實現(xiàn)和運行信息；icmp:關(guān)于系統(tǒng)中ICMP的實現(xiàn)和運行信息；tcp:關(guān)于系統(tǒng)中TCP的實現(xiàn)和運行信息；udp:關(guān)于系統(tǒng)中UDP的實現(xiàn)和運行信息；egp:關(guān)于系統(tǒng)中EGP的實現(xiàn)和運行信息；dot3（transmission）:有關(guān)每個系統(tǒng)接口的傳輸模式和訪問協(xié)議的信息。snmp:關(guān)于系統(tǒng)中SNMP的實現(xiàn)和運行信息。1）system組system組提供有關(guān)被管系統(tǒng)的總體信息。表4.1列出了該組中各個對象的名稱、句法、訪問權(quán)限和對象描述。表4.1system組中的對象ObjectSyntaxAccessDescriptionsysDescrDisplayString(SIZE(0...255))RO對實體的描述，如硬件、操作系統(tǒng)等sysObjectIDOBJECTIDENTIFIERRO實體中包含的網(wǎng)絡(luò)管理子系統(tǒng)的廠商標(biāo)識sysUpTimeTimeTicksRO系統(tǒng)的網(wǎng)絡(luò)管理部分本次啟動以來的時間sysContectDisplayString(SIZE(0...255))RW該被管節(jié)點負責(zé)人的標(biāo)識和聯(lián)系信息sysNameDisplayString(SIZE(0...255))RW該被管節(jié)點被賦予的名稱sysLocationDisplayStringRW該節(jié)點的物理地點

(SIZE(0...255))sysServiceINERGER(0...127)RO指出該節(jié)點所提供的服務(wù)的集合，7個bit對應(yīng)7層服務(wù)2)interfaces組interfaces組包含實體物理接口的一般信息，包括配置信息和各接口中所發(fā)生的事件的統(tǒng)計信息。表4.2列出了該組中各個對象的名稱、句法、訪問權(quán)限和對象描述。表4.2interfaces組中的對象ObjectSyntaxAccessDescriptionifNumberINTEGERRO網(wǎng)絡(luò)接口的數(shù)目ifTableSEQUENCEOFifEntryNA接口條目清單ifEntrySEQUENCENA包含子網(wǎng)及其以下層對象的接口條目ifIndexINTEGERRO對應(yīng)各個接口的唯一值ifDescrDisplayString(SIZE(0...255))RO有關(guān)接口的信息，包括廠商、產(chǎn)品名稱、硬件接口版本ifTypeINTEGERRO接口類型，根據(jù)物理或鏈路層協(xié)議區(qū)分ifMtuINERGERRO接口可接收或發(fā)送的最大協(xié)議數(shù)據(jù)單元的尺寸ifSpeedGaugeRO接口當(dāng)前數(shù)據(jù)速率的估計值ifPhysAddressPhysAddressRO網(wǎng)絡(luò)層之下協(xié)議層的接口地址ifAdminStatusINTEGERRW期望的接口狀態(tài)(up(l),down(2),testing(3))ifOperStatusINTEGERRO當(dāng)前的操作接口狀態(tài)(up(1),down(2),testing(3))ifLastChangeTimeTicksRO接口進入當(dāng)前操作狀態(tài)的時間ifInOctetsCounterRO接口收到的8元組的總數(shù)ifInUcastPktsCounterRO遞交到高層協(xié)議的子網(wǎng)單播的分組數(shù)ifInNUcastPktsCounterRO遞父到咼層協(xié)議的非單播的分組數(shù)ifInDiscardsCounterRO被丟棄的進站分組數(shù)ifInErrorsCounterRO有錯的進站分組數(shù)ifInUnkownProtosCounterRO由于協(xié)議未知而被丟棄的分組數(shù)ifOutOctetsCounterRO接口發(fā)送的8元組的總數(shù)ifOutUcastPktsCounterRO發(fā)送到子網(wǎng)單播地址的分組總數(shù)ifOutNUcastPktsCounterRO發(fā)送到非子網(wǎng)單播地址的分組總數(shù)ifOutDiscardsCounterRO被丟棄的出站分組數(shù)ifOutErrorsCounterRO不能被發(fā)送的有錯的分組數(shù)ifOutQLenGaugeRO輸出分組隊列長度ifSpecificOBJECTIDENTIFIERRO參考MIB對實現(xiàn)接口的媒體的定義3)addresstranslation組addresstranslation組由一個表構(gòu)成，表中的每一行對應(yīng)系統(tǒng)中的一個物理接口，提供網(wǎng)絡(luò)地址向物理地址的映射。一般情況下，網(wǎng)絡(luò)地址是指系統(tǒng)在該接口上的IP地址，而物理地址決定于實際采用的子網(wǎng)情況。例如，如果接口對應(yīng)的是LAN,則物理地址是接口的MAC地址，如果對應(yīng)X.25分組交換網(wǎng)，則物理地址

可能是一個X.121地址。表4.3列出了該組中各個對象的名稱、句法、訪問權(quán)限和對象描述。表4.3addresstranslation組中的對象ObjectSyntaxAccessDescriptionatTableSEQUENCEOFAtEntrvNA包含網(wǎng)絡(luò)地址對物理地址的映射atEntrySEQUENCENA包含一個網(wǎng)絡(luò)地址、物理地址對atIfIndexINTEGERRW表格條目的索引atPhysAddressPhysAddressRW依賴媒體的物理地址atNetAddressNetworkAddressRW對應(yīng)物理地址的網(wǎng)絡(luò)地址實際上，addresstranslation組包含在MIB-II中只是為了與MIB-I兼容，MIB-II的地址轉(zhuǎn)換信息在各個網(wǎng)絡(luò)協(xié)議組中提供。4）ip組ip組包含有關(guān)節(jié)點上IP實現(xiàn)和操作的信息，如有關(guān)IP層流量的一些計數(shù)器。ip組中包含3個表，ipAddrTable、ipRouteTalbe和ipNetToMediaTable。ipAddrTable包含分配給該實體的IP地址的信息，每個地址被唯一地分配給一個物理地址。ipRouteTable包含用于互聯(lián)網(wǎng)路由選擇的信息。該路由表中信息是比較原本地從一些協(xié)議的路由表中抽取而來的。實體當(dāng)前所知的每條路由都有一個條目，表格由ipRouteDest索引。ipRouteTable中的信息可用于配置的監(jiān)測，并且由于表中的對象是read-write的，因此也可被用于路由控制。ipNetToMediaTable是一個提供IP地址和物理地址之間對應(yīng)關(guān)系的地址轉(zhuǎn)換表。除了增加一個指示映射類型的對象ipNetToMediaType之外，表中所包含的信息與addresstranslation組相同。此外，ip組中還包含一些用于性能和故障監(jiān)測的標(biāo)量對象。表4.4列出了該組中各個對象的名稱、句法、訪問權(quán)限和對象描述。表4.4ip組中的對象ObjectSyntaxAccessDescriptionipForwardingINTEGERRW是否作為IP網(wǎng)關(guān)（1/0）ipDefaultTTLINTEGERRW插入到該實體生成的數(shù)據(jù)報的IP頭中Time-To-Live字段中的默認值ipInReceivesCounterRO接口收到的輸入數(shù)據(jù)報的總數(shù)ipInHdrErrorsCounterRO由于IP頭錯被丟棄的輸入數(shù)據(jù)報總數(shù)ipInAddrErrorsCounterRO由于IP地址錯被丟棄的輸入數(shù)據(jù)報總數(shù)ipForwDatagramsCounterRO轉(zhuǎn)發(fā)的輸入數(shù)據(jù)報數(shù)ipInUnknownProtosCounterRO由于協(xié)議未知被丟棄的輸入數(shù)據(jù)報數(shù)ipInDiscardsCounterRO無適當(dāng)理由而被丟棄的輸入數(shù)據(jù)報數(shù)ipInDeliversCounterRO成功地遞交給IP用戶協(xié)議的輸入數(shù)據(jù)報數(shù)ipOutRequestsCounterRO本地IP用戶協(xié)議要求傳輸?shù)腎P數(shù)據(jù)報總數(shù)ipOutNoRoutesCounterRO由于未找到路由而被丟棄的IP數(shù)據(jù)報數(shù)ipReasmTimeOutINTEGERRO重組接收到的碎片可等待的最大秒數(shù)ipReasmReqdsCounterRO接收到的需要重組的IP碎片數(shù)ipReasmOKsCounterRO成功重組的IP數(shù)據(jù)報數(shù)ipRaesmFailsCounterRO由IP重組算法檢測到的重組失敗的數(shù)目ipFragsOkCounterRO成功拆分的IP數(shù)據(jù)報數(shù)ipFragsFailsCounterRO不能成功拆分而被丟棄的IP數(shù)據(jù)報數(shù)ipFragsCreatesCounterRO本實體產(chǎn)生的IP數(shù)據(jù)報碎片數(shù)ipAddrTableSEQUENCEOFNA本實體的IP地址信息（表內(nèi)對象略）ipRouteTableSEQUENCEOFNAIP路由表

(表內(nèi)對象略)ipNetToMediaTable|JU I“IILJ、SEQUENCEOFIpNetToMedisNA用于將IP映射到物理地址的地址轉(zhuǎn)換表(表內(nèi)對象略)IpRoutingDiscardsCounterRO被丟棄的路由選擇條目5)icmp組ICMP(InternetControlMessageProtocol)是TCP/IP協(xié)議族中的一部分，所有實現(xiàn)IP協(xié)議的系統(tǒng)都提供ICMP。ICMP提供從路由器或其他主機向主機傳遞消息的手段，它的基本作用是反饋通信環(huán)境中存在的問題,例如:數(shù)據(jù)報不能到達目的地，路由器沒有緩沖區(qū)容量來轉(zhuǎn)發(fā)數(shù)據(jù)報。icmp組包含有關(guān)一個節(jié)點的ICMP的實現(xiàn)和操作的信息，具體地講，icmp組由節(jié)點接收和發(fā)送的各種ICMP消息的計數(shù)器所構(gòu)成由一個表構(gòu)成。表4.5列出了該組中各個對象的名稱、句法、訪問權(quán)限和對象描述。表4.5icmp組中的對象ObjectSyntaxAccessDescriptionicmpInMsgsCounterRO收到的ICMP消息的總數(shù)icmpInErrorsCounterRO收到的有錯的ICMP的消息數(shù)icmpInDestUnreachsCounterRO收到的目的地不可到達的消息數(shù)icmpInTimeExcdsCounterRO收到的超時的消息數(shù)icmpInParmProbsCounterRO收到的有參數(shù)問題的消息數(shù)icmpInSrcQuenchsCounterRO收到的源有問題的消息數(shù)icmpInRedirectsCounterRO收到的重定向的消息數(shù)icmpInEchosCounterRO收到的要求echo的消息數(shù)icmpInEchoRepsCounterRO收到的應(yīng)答echo的消息數(shù)icmpInTimestampsCounterRO收到的要求Timestamp的消息數(shù)icmpInTimestampRepsCounterRO收到的應(yīng)答Timestamp的消息數(shù)icmpInAddrMasksCounterRO收到的要求AddressMask的消息數(shù)icmpInAddrMaskRepsCounterRO收到的應(yīng)答AddressMask的消息數(shù)icmpOutMsgsCounterRO發(fā)出的ICMP消息的總數(shù)icmpOutErrorsCounterRO發(fā)出的有錯的ICMP的消息數(shù)icmpOutDestUnreachsCounterRO發(fā)出的目的地不可到達的消息數(shù)icmpOutTimeExcdsCounterRO發(fā)出的超時的消息數(shù)icmpOutParmProbsCounterRO發(fā)出的有參數(shù)問題的消息數(shù)icmpOutSrcQuenchsCounterRO發(fā)出的源有問題的消息數(shù)icmpOutRedirectsCounterRO發(fā)出的重定向的消息數(shù)icmpOutEchosCounterRO發(fā)出的要求echo的消息數(shù)icmpOutEchoRepsCounterRO發(fā)出的應(yīng)答echo的消息數(shù)icmpOutTimestampsCounterRO發(fā)出的要求Timestamp的消息數(shù)icmpOutTimestampRepsCounterRO發(fā)出的應(yīng)答Timestamp的消息數(shù)icmpOutAddrMasksCounterRO發(fā)出的要求AddressMask的消息數(shù)icmpOutAddrMaskRepsCounterRO發(fā)出的應(yīng)答AddressMask的消息數(shù)6)tcp組tcp組包含有關(guān)一個節(jié)點的TCP的實現(xiàn)和操作的信息，圖4.5定義的tcpConnTable包含在這個組中。表4.6列出了該組中各個對象的名稱、句法、訪問權(quán)限和對象描述。

表4.6tcp組中的對象ObjectSyntaxAccessDescriptiontcpRtoAlgorithmINTEGERRO重傳時間tcpRtoMinINTEGERRO重傳時間的最小值tcpRtoMaxINTEGERRO重傳時間的最大值tcpMaxConnINTEGERRO實體支持的TCP連接數(shù)的上限tcpActiveOpensCounterRO實體已經(jīng)支持的主動打開的數(shù)量tcpPassiveOpensCounterRO實體已經(jīng)支持的被動打開的數(shù)量tcpAttemptFailsCounterRO已經(jīng)發(fā)生的試連失敗的次數(shù)tcpEstabResetsCounterRO已經(jīng)發(fā)生的復(fù)位的次數(shù)tcpCurrEstabGaugeRO當(dāng)前狀態(tài)為established的TCP連接數(shù)tcpInSegsCounterRO收到的segments總數(shù)tcpOutSegsCounterRO發(fā)出的segments總數(shù)tcpRetranSegsCounterRO重傳的segments總數(shù)tcpConnTableSEQUENCEOFTcpConnTntrvNA包含TCP各個連接的信息(表內(nèi)對象略，參考圖4.5)tcpInErrorsCounterRO收到的有錯的segments的總數(shù)tcpOutRstsCounterRO發(fā)出的含有RST標(biāo)志的segments數(shù)7)udp組udp組包含有關(guān)一個節(jié)點的UDP的實現(xiàn)和操作的信息。除了有關(guān)發(fā)送和接收的數(shù)據(jù)報的信息之外，這個組中還包含一個udpTable表，該表中包含UDP端點的管理信息。所謂UDP端點是指正在支持本地應(yīng)用接收數(shù)據(jù)報的UDP進程。udpTable表中包含每個UDP端點用戶的IP地址和UDP端口。表4.7列出了該組中各個對象的名稱、句法、訪問權(quán)限和對象描述。表4.7udp組中的對象ObjectSyntaxAccessDescriptionudpInDatagramsCounterRO遞交該UDP用戶的數(shù)據(jù)報的總數(shù)udpNoPortsCounterRO收到的目的端口上沒有應(yīng)用的數(shù)據(jù)報總數(shù)udpInErrorsCounterRO收到的無法遞交的數(shù)據(jù)報數(shù)udpOutDatagramsCounterRO該實體發(fā)出的UDP數(shù)據(jù)報總數(shù)udpTableSEQUENCEOFUdpEntrvNA包含UDP的用戶信息udpTableSEQUENCENA某個當(dāng)前UDP用戶的信息udpLocalAddressIpAddressROUDP用戶的本地IP地址udpLocalPortINTEGERROUDP用戶的本地端口號8)egp組egp組包含有關(guān)一個節(jié)點的EGP(ExternalGatewayProtocol)的實現(xiàn)和操作的信息。除了有關(guān)發(fā)送和接收的EGP消息的信息之外，這個組中還包含一個egpNeighTable表，該表中包含有關(guān)相鄰網(wǎng)關(guān)的信息。表4.8列出了該組中各個對象的名稱、句法、訪問權(quán)限和對象描述。表4.8egp組中的對象ObjectSyntaxAccessDescriptionegpInMsgsCounterRO收到的無錯的EGP消息數(shù)egpInErrorsCounterRO收到的有錯的EGP消息數(shù)egpOutMsgsCounterRO本地產(chǎn)生的EGP消息總數(shù)egpOutErrorsCounterRO由于資源限制沒有發(fā)出的本地產(chǎn)生的EGP消息數(shù)egpNeighTableSEQUENCEOFEgpNeighEntryNA相鄰網(wǎng)關(guān)的EGP表(表內(nèi)的對象略)egpAsINTEGERRO本EGP實體的自治系統(tǒng)數(shù)4.3簡單網(wǎng)絡(luò)管理協(xié)議(SNMP)4.3.1SNMP支持的操作SNMP只支持對變量的檢查和修改的操作，具體地，可以對標(biāo)量對象進行以下三種操作：Get:管理站從被管理站提取標(biāo)量對象值。Set:管理站更新被管理站中的標(biāo)量對象值。Trap:被管理站向管理站主動地發(fā)送一個標(biāo)量對象值。MIB的結(jié)構(gòu)不能通過增加或減少對象實例被改變，并且，訪問只能對對象標(biāo)識樹中的葉子對象進行。這些限制大大簡化了SNMP的實現(xiàn)，但同時也限制了網(wǎng)絡(luò)管理系統(tǒng)的能力。4.3.2共同體和安全控制網(wǎng)絡(luò)管理是一種分布式的應(yīng)用。與其他分布式的應(yīng)用相同，網(wǎng)絡(luò)管理中包含由一個應(yīng)用協(xié)議支持的多個應(yīng)用實體的相互作用。在SNMP網(wǎng)絡(luò)管理中，這些應(yīng)用實體就是采用SNMP的管理站應(yīng)用實體和被管理站的應(yīng)用實體。SNMP網(wǎng)絡(luò)管理具有一些不同于其他分布式應(yīng)用的特性，它包含一個管理站和多個被管理站之間一對多的關(guān)系。即，管理站能夠獲取和設(shè)置各管理站的對象，能夠從各被管理站中接收陷阱信息。因此，從操作或控制的角度來看，管理站管理著多個被管理站。同時，系統(tǒng)中也可能有多個管理站，每個管理站都管理所有的或一部分被管理站。反過來，我們也要看到SNMP網(wǎng)絡(luò)管理中還包含另外一種一對多的關(guān)系—一個被管理站和多個管理站之間的關(guān)系。每個被管理站控制著自己的本地MIB，同時必須能夠控制多個管理站對這個本地MIB的訪問。這里所說的控制有以下三個方面:認證服務(wù):將對MIB的訪問限定在授權(quán)的管理站的范圍內(nèi);訪問策略:對不同的管理站給予不同的訪問權(quán)限;代管服務(wù):一個被管理站可以作為其他一些被管理站(托管站)的代管，這就要求在這個代管系統(tǒng)中實現(xiàn)為托管站服務(wù)的認證服務(wù)和訪問權(quán)限。以上這些控制都是為了保證網(wǎng)絡(luò)管理信息的安全，即被管系統(tǒng)需要保護它們的MIB不被非法地訪問。SNMP通過共同體(community)的概念提供了初步的和有限的安全能力。SNMP用共同體來定義一個代理者和一組管理者之間的認證、訪問控制和代管的關(guān)系。共同體是一個在被管系統(tǒng)中定義的本地的概念。被管系統(tǒng)為每組可選的認證、訪問控制和代管特性建立一個共同體。每個共同體被賦予一個在被管系統(tǒng)內(nèi)部唯一的共同體名，該共同體名要提供給共同體內(nèi)的所有的管理站，以便它們在get和set操作中應(yīng)用。代理者可以與多個管理站建立多個共同體，同一個管理站可以出現(xiàn)在不同的共同體中。由于共同體是在代理者處本地定義的，因此不同的代理者處可能會定義相同的共同體名。共同體名相同并不意味者共同體有什么相似之處，因此，管理站必須將共同體名與代理者聯(lián)系起來加以應(yīng)用。認證服務(wù)認證服務(wù)是為了保證通信是可信的。在SNMP消息的情況下，認證服務(wù)的功能是保證收到的消息是來自它所聲稱的消息源。SNMP只提供一種簡單的認證模式:所有由管理站發(fā)向代理者的消息都包含一個共同體名，這個名字發(fā)揮口令的作用。如果發(fā)送者知道這個口令，則認為消息是可信的。通過這種有限的認證形式，網(wǎng)絡(luò)管理者可以對網(wǎng)絡(luò)監(jiān)控(set、trap)特別是網(wǎng)絡(luò)控制(set)操作進行限制。共同體名被用于引發(fā)一個認證過程，而認證過程可以包含加密和解密以實現(xiàn)更安全的認證。訪問策略通過定義共同體，代理者將對它的MIB的訪問限定在了一組被選擇的管理站中。通過使用多個共同體，代理者可以為不同的管理站提供不同的MIB訪問控制。訪問控制包含兩個方面：SNMPMIB視圖:MIB中對象的一個子集?？梢詾槊總€共同體定義不同的MIB視圖。視圖中的對象子集可以不在MIB的一個子樹之內(nèi)。SNMP訪問模式:READ-ONLY或READ-WRITE。為每個共同體定義一個訪問模式。MIB視圖和訪問模式的結(jié)合被稱為SNMP共同體輪廓(profile)。即，一個共同體輪廓由代理者處MIB的一個子集加上一個訪問模式構(gòu)成。SNMP訪問模式統(tǒng)一地被用于MIB視圖中的所有對象。因此，如果選擇了READ-ONLY訪問模式，則管理站對視圖中的所有對象都只能進行read-only操作。事實上，在一個共同體輪廓之內(nèi)，存在兩個獨立的訪問限制一MIB對象定義中的訪問限制和SNMP訪問模式。這兩個訪問限制在實際應(yīng)用中必須得到協(xié)調(diào)。表4.9給出了這兩個訪問限制的協(xié)調(diào)規(guī)則。注意，對象被定義為write-only，SNMP也可以對其進行/r/