《为使用SNMP定义Trap的惯例》由会员分享，可在线阅读，更多相关《为使用SNMP定义Trap的惯例（3页珍藏版）》请在金锄头文库上搜索。
1、为使用SNMP定义Trap的惯例1历史前景就如RFC1025中所报告的，为Internet网络管理标准1发展做的IAB推荐，一个基于TCP/IP的网管的双重策略被采纳。在短期内，在RFC中定义的简单网管协议，被用来管理Internet社区的节点。在长期内，OSI网络管理框架的使用将会通过检验。产生了两份文档来定义管理信息：RFC1065，它定义了管理信息结构(SMI)，以及RFC1066。定义了管理信息基础。设计这两份文档以便于与SNMP和OSI网管框架相协调。这个策略在短期内非常成功：在几个月内，通过研究和商业社区，形成了基于Internet的网管技术。由此而产生的结果是：一时间Intern
2、et部分社区变为可管理的网络。在RFC1109中报告的，第二AdHoc网管审查组2的报告，SNMP和OSI网管框架比预期的有很大不同。由此，在SMI和MIB之间以及二者共同的和谐性的需求被暂停了。这个行动允许了基于SNMP的可操作的网管框架在Internet社区通过MIB-II产生来响应新的操作请求。1990年5月，核心文档以被建议的身份被提升为标准协议。由此，Internet标准网管框架包含：基于TCP/IPinternet管理信息的结构和认证，即RFC11553，它描述了包含在MIB中被管理的对象是如何被定义的；基于TCP/IPinternet网管的管理信息基础，即RFC11564，它描述
3、了包含在MIB中的被管理的对象；简单网管协议，即RFC11575，定义了用于管理这些对象的协议。2.定义陷阱由于Internet标准SMI起初独立于协议的要求，它并没有提供定义陷阱的方法。取而代之的是，SNMP定义了一些标准化的陷阱，为企业的管理传送企业专用陷阱提供了一种方法。然而，随着实验性MIBs的出现，其中有些需要定义实验专用的陷阱，急需一种定义陷阱的方便的方法。为此建议使用陷阱类型宏。IMPORTSObjectNameFROMRFC1155-SMI;TRAP-TYPEMACRO:=BEGINTYPENOTATION:=ENTERPRISEvalue(enterpriseOBJECTID
4、ENTIFIER)VarPartDescrPartReferPartVALUENOTATION:=value(VALUEINTEGER)VarPart:=VARIABLESVarTypes|emptyVarTypes:=VarType|VarTypes,VarTypeVarType:=value(vartypeObjectName)DescrPart:=DESCRIPTIONvalue(descriptionDisplayString)|emptyReferPart:=REFERENCEvalue(referenceDisplayString)|emptyEND然而必须强调在Internet标
5、准网管框架中，使用陷阱是非常令人失望的。陷阱类型宏是用来认可现存的简明的定义，而不是促使定义新的陷阱。2.1. 制定陷阱宏种类应该注意的是陷阱类型宏的扩张概念上是发生在完成时而不是在运行期间。制定企业条款企业条款，必须是现有的，定义了企业管理，在其下的注册权限，这个陷阱是定义了的。（关于注册权限的授权的讨论，见SMI3）。评估被放在SNMP陷阱协议数据单元的企业项内。根据惯例，如果企业条款的评估是简单网管协议中的对象标志符:=mib-211就象在MIB-II7中定义的，sysObjectID的评估被放在SNMP陷阱协议数据单元的企业项内，而不使用此项评估。这提供了一种使用陷阱类型宏来代表现存的
6、SNMP标准陷阱的方法；它并没有用来提供定义另外的SNMP标准陷阱的方法。2.1.1. 制定变量条款变量条款，不必是现有的，定义了MIB对象的有序的序列，这些对象包含在每个陷阱类型的实例中。每个变量按顺序被放置在SNMP陷阱协议数据单元的变量绑定域内。注意到在代理的选项中，附加的变量可能在变量绑定域内出现。然而，如果企业条款的评估是简单网管协议中的对象标志符:=mib-211SNMP消息超过484就象在MIB-II7中定义的，那么附加变量的出现不会导致连续的字节。2.1.2. 制定描述条款描述条款，不必是现有的，包含一个陷阱类型的原文的定义。注意到为了符合ASN.1的语法，这个条款的全部评估必
7、须包含在双引号内，尽管这些评估是多线程的。更要注意如果MIB模块其他地方没有包含陷阱的原文描述，描述条款必须是现有的。2.1.3. 制定参考条款参考条款，不需要是现有的，包含有在其他MIB模块中定义的一个陷阱的原文的相互参照，事件，或是警告。当其他一些组织产生出MIB时，这是非常有用的。制定陷阱类型评估陷阱类型祷文的评估是整数。企业条款指示的注册权限为陷阱唯一指定这些整数。这项评估被放在SNMP陷阱协议数据单元的专用陷阱域内，普通陷阱域被放在“企业专用(6)”根据惯例，如果企业条款的评估是简单网管协议中的对象标志符:=mib-211就象在MIB-II7中定义的，那么陷阱类型宏祷文的评估放在SN
8、MP陷阱协议数据单元的普通陷阱域内，专用陷阱域放在0.它提供了使用陷阱宏来代表已存的SNMP陷阱的方法；他并没有用来提供定义附加标准SNMP陷阱的方法。2.2.使用举例2.2.1.专用企业陷阱考虑这样一个简单例子：当一个通信连接失败时，发送一个企业专用陷阱myEnterpriseOBJECTIDENTIFIER:=enterprises9999myLinkDownTRAP-TYPEENTERPRISEmyEnterpriseVARIABLESifIndexDESCRIPTION一个myLinkDown陷阱表示发送的SNMP请求实体确认了表现在代理配置通信里的一次失败连接。:=22.2.2.为使
9、用SNMP的普通陷阱考虑标准SNMP陷阱可能会这样定义：coldStartTRAP-TYPEENTERPRISEsnmpDESCRIPTION一个coldStart陷阱表示发送的协议实体在重新初始化自己这样可能会改变代理配置或协议实体。:=0warmStartTRAP-TYPEENTERPRISEsnmpDESCRIPTION一个warmStart陷阱表示发送的协议实体在重新初始化自己这样代理配置和协议实体都会改变.:=1linkDownTRAP-TYPEENTERPRISEsnmpVARIABLESifIndexDESCRIPTION一个linkDown陷阱表示了发送的协议实体确认了表现在代
10、理配置中通信连接的一次失败.:=2linkUpTRAP-TYPEENTERPRISEsnmpVARIABLESifIndexDESCRIPTION一个linkUp陷阱表示了发送的协议实体认了在代理配置出现时的一个通信连接.:=3authenticationFailureTRAP-TYPEENTERPRISEsnmpDESCRIPTION一个authenticationFailure陷阱表示了发送的协议实体是不恰当鉴别协议消息中的地址。当SNMP的补充协议必须能够产生这个陷阱，它同样必须能够压缩这些陷阱的发送通过一个特殊执行机制.:=4egpNeighborLossTRAP-TYPEENTERP
11、RISEsnmpVARIABLESegpNeighAddrDESCRIPTION一个egpNeighborLoss陷阱表示了从发送协议实体的一相邻EGP是一个已经被标记的等同EGP，现在这个等同的关系是不包含在内的:=53.致谢本文档由SNMP网络工作组产生：AnneAmbler,SpiderKarlAuerbach,SunFredBaker,ACCKenBrinkerhoffRonBroersma,NOSCJackBrown,USArmyTheodoreBrunner,BellcoreJeffreyBuffum,HPJohnBurress,WellfleetJeffreyD.Case,Uni
12、versityofTennesseeatKnoxvilleChrisChiptasso,SpartacusPaulCiarfella,DECBobColletJohnCook,ChipcomTracyCox,BellcoreJamesR.Davin,MIT-LCSEricDecker,ciscoKurtDobbins,CabletronNadyaEl-Afandi,NetworkSystemsGaryEllis,HPFredEngleMikeErlingerMarkS.Fedor,PSIRichardFox,SynopticsKarenFrisa,CMUChrisGunner,DECFredH
13、arris,UniversityofTennesseeatKnoxvilleKenHibbard,XylogicsOleJacobsen,InteropKenJonesSatishJoshi,SynopticsFrankKastenholz,Racal-InterlanShimshonKaufman,SpartacusKenKey,UniversityofTennesseeatKnoxvilleJimKinder,FibercomAlexKoifman,BBNChristopherKolb,PSICherylKrupczak,NCRPaulLangille,DECPeterLin,Vitali
14、nkJohnLunny,TWGCarlMalamudRandyMayhew,UniversityofTennesseeatKnoxvilleKeithMcCloghrie,HughesLANSystemsDonnaMcMaster,DavidSystemsLynnMonsanto,SunDavePerkins,3COMJimReinstedler,UngermanBassAnilRijsinghani,DECKathyRinehart,ArnoldAFBKaryRobertsonMarshallT.Rose,PSI(chair)L.MichaelSabo,NCSCJonSaperia,DECG
15、regSatz,ciscoMartinSchoffstall,PSIJohnSeligsonSteveSherry,XyplexFeiShu,NECSamSjogren,TGVMarkSleeper,SpartaLanceSprungMikeSt.JohnsBobStewart,XyplexEmilSturnioldKajTesink,BellcoreDeanThroop,DataGeneralBillTownsend,XylogicsMauriceTurcotte,Racal-MilgoKannanVaradhouSudhanshuVerma,HPBillVersteeg,NetworkRe
16、searchCorporationWarrenVik,InteractiveSystemsDavidWaitzman,BBNSteveWaldbusser,CMUDanWintringhanDavidWoodWengyikYeong,PSIJeffYoung,CrayResearch4.参考Cerf,V.,IABRecommendationsfortheDevelopmentofInternetNetworkManagementStandards,RFC1052,NRI,April1988.1 Cerf,V.,ReportoftheSecondAdHocNetworkManagementReviewGroup,RFC1109,NRI,August1989.RoseM.,andK.McCloghrie,StructureandIden
