rfc2232.Definitions of Managed Objects for DLUR using SMIv2

合集下载

1+x云运维考试试题及答案

1+x云运维考试试题及答案

1+x云运维考试试题及答案1.HAProxy配置中, 那部分配置用于配置后端服务器参数?A.globalB.defaultsC.f rontendD.backend答案: D2、下列哪一项是问题管理流程中最后的活动?A.将任何与变更请求相关的提交给变更管理。

B.记录问题C、完成所有问题管理活动, 结束问题记录D.开始回顾问题及其影响答案: C3、解诀网络问题的过程中哪个步骤需要询问用户, 以便了解解决问题所需的信息?A.收集信息B.界定故障现象C.列举可能导致故障的原因D.排查原因答案: C4.jobs命令是什么命令A.查看处理后台的任务列表B.查看定时任务C.查看运行的进程D.执行任务答案: A5.Linux操作系统中添加用户的命令eraddB.adduser addD.addus6、下列哪一项是问题管理流程中最后的活动?A.将任何与变更请求相关的提交给变更管理。

B.记录问题C、完成所有问题管理活动, 结束问题记录D.开始回顾问题及其影响答案: C7、主要作用是使uid为“0”的用户即root用户能够直接通过认证而不用输入密码, 是哪个模块A.pam_userdb.soB.pam_limits.soC.pam_rootok.soD.pam_pwhistroy.so答案: C8、system_u:object_r:admin_home_t:s0 中system_u 表示为A.角色B.SELinux中最重要的信息C.类型D.用户答案: D9、Memcached中gets命令的作用是什么A.获取 valueB.获取带有CAS令牌存的value。

、追加valueD.在前面追加value答案: B10、下面哪一项是主动问题管理的范围?A.处理变更请求B.履行趋势分析并识别潜在的事故和问题C.跟踪调查所有的事故和中断D.最小化因变更IT环境导致的服务中断答案: B11.Nginx的Web站点服务器默认路径是下列中哪个选项A.HTMLC.SBIND.BIN答案: A12、下面关于ARP工作原理的描述, 不正确的是A.是通过IP地址查询对应的MAC地址B.ARP缓存中的数据是动态更新的C.ARP请求报文可以跨网段传输D.ARPA是通过AMC查询对应的IP地址答案: C13.下列选项中对响应策略描述正确的是A.响应策略是指当用户请求来的时候, 负载均衡器会优先将请求转发给当前时刻响应最快的后端服务器B.响应策略是指当负载均衡器往后端转发流量的时候, 会先去评估后端每台服务器的负载压力情况, 对于压力比较大的后端服务器转发的请求就少一些, 对于压力比较小的后端服务器可以多转发一些请求给它。

网络拓扑论述(snmp版本)

网络拓扑论述(snmp版本)

网络拓扑发现snmp摘要随着计算机网络技术的发展和lnternet在全世界范围内的普及,计算机网络作为信息社会的基础设施已应用到政府部门、商业、军事、教育等社会各领域。

当前计算机网络的发展特点是:网络规模不断扩大,复杂性不断增加,网络的异构性也越来越高。

在现有的技术条件下,人们希望有一个更加稳定可靠的网络环境,计算机网络管理系统就是应这样的需求而产生的。

它对网络上的各种设备进行管理,通过监视和控制这些设备,及时地向管理人员报告网络状态,并且简化网络故障的处理,减少故障造成的损失,提高网络的服务质量和效率[1]。

一个好的网络管理系统首先需要掌握整个被管网络的拓扑结构。

网络的配置管理是发现和配置网络中对网络管理有意义的设备的过程,而网络的自动拓扑发现规则是配置管理的核心,是故障和性能管理的基础,同时它也是衡量一个商业网管系统成败的重要尺度。

因此,拓扑发现算法的设计在整个网管系统的开发中有着举足轻重的地位。

网络拓扑发现技术是利用网管协议或网络提供的可用工具,通过拓扑算法,发现网络中路由器、交换机及主机之间的连接关系,并且以图形的方式直观地显示出来,同时还要尽量减小发现网络设备和显示设备拓扑图的运行代价[2]。

为了发现更加详细的网络拓扑结构,网络的多层自动拓扑发现是必不可少的,业界通常把网络自动拓扑发现分为两部分,即IP管理域内网络层拓扑发现和数据链路层拓扑发现,本文将详细地介绍网络拓扑自动发现算法。

1.拓扑发现算法的相关协议简介1.1 SNMP(Simple Network ManagementProtocol,简单网络管理协议)由于SNMP的简单和易于实现的特点,该管理协议已经成为目前应用最为广泛和最为流行的网络管理协议,也成为了事实上的标准[3]。

它的设计目的是使网络管理站能够有效而简单地监视和控制网络设备,它由管理者、管理信息库(MIB)、代理(Agent)以及被管对象4部分组成,SNMP的体系结构见图1。

rfc3312读书笔记

rfc3312读书笔记

本端(B) 状态表
方向 当前状态 期望强度 _______ _______ _______ _______ _______ ___
local send no noneman datory
local recv no mandato ry
表三
更新
remote send no none
remote recv no none
local recv no optiona l
remote send no none
remote recv no none
a=curr: qos remote nao=ndees:q os none local sendrec va=des:q os optiona l remote sae=nddes:q os mandato ry remote recv …
Offer
例:移动 接入网
send A
recv
recv send
专用线路
S
(带宽有 保证)
Offer
本端(A) 状态表
复制
事务状态 表
编码 SDP
方向 当前状态 期望强度 _______ _______ _______ _______ _______ ___
local send no none
local recv no none remote send no optiona l
remote
recv
no 表一并更 mandato
对比 新它
ry
本端(A) 状态表
方向 当前状态 期望强度 _______ _______ _______ _______ _______ ___
local send no none

snmp-rfc

snmp-rfc

1284 Definitions of Managed Objects for the Ethernet-like Interface
Types. J. Cook. December 1991. (Format: TXT=43225 bytes) (Obsoleted
by RFC1398) (Status: PROPOSED STANDARD)
TCP/IP-based internets. M.T. Rose, K. McCloghrie. May-01-1990.
(Format: TXT=40927 bytes) (Obsoletes RFC1065) (Also STD0016) (Status:
STANDARD)
M.L. Schoffstall, C. Davin. Apr-01-1989. (Format: TXT=71563 bytes)
(Obsoletes RFC1067) (Obsoleted by RFC1157) (Status: UNKNOWN)
1155 Structure and identification of management information for
1089 SNMP over Ethernet. M.L. Schoffstall, C. Davin, M. Fedor, J.D.
Case. Feb-01-1989. (Format: TXT=4458 bytes) (Status: UNKNOWN)
1098 Simple Network Management Protocol (SNMP). J.D. Case, M. Fedor,
Version 3. S. Willis, J.W. Burruss. Oct-01-1991. (Format: TXT=25717

WLAN室外基站型AP招标技术规范书

WLAN室外基站型AP招标技术规范书

WLAN室外基站型AP 招标技术规范目录一、总则 ................................................................................. 错误!未定义书签。

1.1概述................................................................................... 错误!未定义书签。

1.2技术规范和技术标准....................................................... 错误!未定义书签。

1.3本规范书的补充规定....................................................... 错误!未定义书签。

二、WLAN室外基站型AP产品性能规定......................... 错误!未定义书签。

1、接口规定........................................................................... 错误!未定义书签。

2、功能规定........................................................................... 错误!未定义书签。

3、性能规定........................................................................... 错误!未定义书签。

4、天线规定........................................................................... 错误!未定义书签。

5、运营环境规定................................................................... 错误!未定义书签。

宁德市有线电视分配接入网双向改造方案与实施

宁德市有线电视分配接入网双向改造方案与实施

宁德市有线电视分配接入网双向改造方案与实施随着有线数字电视整体转换工作的加快推进,网络的改造建设再次成为有线电视行业的热点。

由于现有的HFC网在很多地方还没有完成双向改造,这样的网络只能满足基本广播电视节目的传送,而不能承载多媒体交互业务和增值业务,也不能有效实现网络、业务和用户管理。

因此,在目前的形势下,我们将如何选择一种较为合理的方案,进行网络双向建设改造,这已成为有线电视网络技术人员面临的重要课题。

本文在对比目前有线电视双向网络建设改造主流方案的基础上,结合宁德市城区的实际情况,提出宁德市有线电视分配接入网双向改造方案与实施。

1 接入网双向改造方案比较对目前有线电视网络的双向建设改造,主要分为城域干线网和用户分配网,其重点是用户分配接入网的双向改造。

有线电视分配接入网双向改造的应用技术方案较多,本文着重比较、介绍以下4种主流方案:CMTS+ CM(即CM方案)、EPON+LAN、EPON+EOC和FTTH方案。

1.1 基于HFC网络的CMTS+ CM方案(CM方案)CMTS(电缆调制解调器端接系统)+CM(电缆调制解调器)组网方案,它在分配接入网双向化改造中采用的C M技术;在光传输部分,下行数据信号和CATV的下行信号采用频分(FDM)方式共纤传输,上下行数据信号采用空分(SDM)方式共缆不同纤传输;在电缆部分,上下行信号按FDM方式同缆传输。

这一方案可利用已有HFC(混合光纤同轴网络)网络中预留的光纤和无源同轴分配入户的电缆,并组成双向传输系统,不需要重新铺线,只需在前端和用户端分别加装CMTS和CM 即可实现双向传输,前期投入少,改造工程量小,适合已建HFC网络改造。

但存在反向噪声汇聚,网络反向设计和工艺控制要求较高等问题,由于受CMTS的带宽限制,可承载业务有限,无法满足大带宽业务的需求,因此日后网络扩容投资相对较大。

1.2 EPON改造方案PON(无源光网)是为了支持点到多点应用发展起来的光接入系统。

STM32固件库使用手册的中文翻译版

STM32固件库使用手册的中文翻译版
该固态函数库通过校验所有库函数的输入值来实现实时错误检测。该动态校验提高了软件的鲁棒性。实时 检测适合于用户应用程序的开发和调试。但这会增加了成本,可以在最终应用程序代码中移去,以。
因为该固件库是通用的,并且包括了所有外设的功能,所以应用程序代码的大小和执行速度可能不是最优 的。对大多数应用程序来说,用户可以直接使用之,对于那些在代码大小和执行速度方面有严格要求的应 用程序,该固件库驱动程序可以作为如何设置外设的一份参考资料,根据实际需求对其进行调整。
1.3.1 变量 ................................................................................................................................................ 28 1.3.2 布尔型 ............................................................................................................................................ 28 1.3.3 标志位状态类型 ........................................................................................................................... 29 1.3.4 功能状态类型 .............................................................................................................

FortiSwitch Data Center系列产品介绍说明书

FortiSwitch Data Center系列产品介绍说明书

DATA SHEETFortiSwitch ™ Data Center SeriesFortiSwitch Data Center switches deliver a Secure, Simple, Scalable Ethernet solution with outstanding throughput, resiliency, and scalability. Virtualization and cloud computing have created dense high-bandwidth Ethernet networking requirements. FortiSwitch Data Center switches meet these challenges by providing a high performance 10 GE, 40 GE, or 100 GE capable switching platform, with a low Total Cost of Ownership. Ideal for Top of Rack server or firewall aggregation applications, as well as SD-Branch network coredeployments, these switches are purpose-built to meetthe needs of today’s bandwidth intensive environments.Highlights§High throughput Ethernet switch suitable for Top of Rack or largeSD-Branch network deployments§ 1 GE, 10 GE, or 100 GE access ports, in a compact 1 RU form factor with 40 or 100 GE capable uplinks which includes breakout support for 2x50G, 4x25G, 4x10G, and 4x1G §FortiGate management through FortiLink, enabling the Security Fabric§Stackable up to 300 switches per FortiGate depending on model§Dual hot swappable power supplies for redundancy§Supports Wire-speed switching with both Store and Forward and Cut Through forwarding modesProduct OfferingsFortiSwitch 1024D, 1048E, 3032D, and 3032ESecurity Fabric Integration through FortiLinkThe FortiSwitch Data Center Series supports FortiGate managementthrough FortiLink, extending the Fortinet Security Fabric to the Ethernet port level. This link allows the same policies configured and applied to FortiGate interfaces to be applied to theFortiSwitch Ethernet ports, reducing complexity and decreasing management cost. With network security and access layer functions enabled and managed through a single console, centralized policy management, including role-based access and control, are easy to implement and manage. Users or devices can be authenticated against the same database and have the same security policy applied regardless of how or where they connect to the network.DATA SHEET | FortiSwitch™ Data Center SeriesDeploymentStandalone ModeThe FortiSwitch has a native GUI and CLI interface. All configuration and switch administration can be accomplished through either of theseinterfaces. Available ReSTful API’s offer additional configuration and management options.FortiLink ModeFortiLink is an innovative proprietary management protocol that allows our FortiGate Security Appliance to seamlessly manage any FortiSwitch. FortiLink enables the FortiSwitch to become a logical extension of the FortiGate integrating it directly into the Fortinet Security Fabric. This management option reduces complexity and decreases management cost as network security and access layer functions are enabled and managed through a single console.DATA SHEET | FortiSwitch ™ Data Center Series3HardwareFortiSwitch 3032D — frontFortiSwitch 3032D — backFortiSwitch 1048E — frontFortiSwitch 1048E — backFortiSwitch 1024D — backFortiSwitch 3032E — frontFortiSwitch 3032E — backFortiSwitch 1024D — frontDATA SHEET | FortiSwitch™ Data Center SeriesFeaturesLAG support for FortiLink Connection YesActive-Active Split LAG from FortiGate to FortiSwitches for Advanced Redundancy YesFORTISWITCH 1024D FORTISWITCH 1048E FORTISWITCH 3032D FORTISWITCH 3032E Layer 2Jumbo Frames Yes Yes Yes YesAuto-negotiation for port speed and duplex Yes Yes Yes YesIEEE 802.1D MAC Bridging/STP Yes Yes Yes YesIEEE 802.1w Rapid Spanning Tree Protocol (RSTP)Yes Yes Yes YesIEEE 802.1s Multiple Spanning Tree Protocol (MSTP)Yes Yes Yes YesSTP Root Guard Yes Yes Yes YesEdge Port / Port Fast Yes Yes Yes YesIEEE 802.1Q VLAN Tagging Yes Yes Yes YesPrivate VLAN Yes Yes Yes YesIEEE 802.3ad Link Aggregation with LACP Yes Yes Yes YesUnicast/Multicast traffic balance over trunking port(dst-ip, dst-mac, src-dst-ip, src-dst-mac, src-ip, src-mac)Yes Yes Yes YesIEEE 802.1AX Link Aggregation Yes Yes Yes YesSpanning Tree Instances (MSTP/CST)32/132/132/132/1IEEE 802.3x Flow Control and Back-pressure Yes Yes Yes YesIEEE 802.1Qbb Priority-based Flow Control Yes Yes Yes YesIEEE 802.3u 100Base-TX Yes No No YesIEEE 802.3z 1000Base-SX/LX Yes Yes Yes YesIEEE 802.3ab 1000Base-T Yes Yes No YesDATA SHEET | FortiSwitch™ Data Center Series Features* Requires ‘Advanced Features’ License5DATA SHEET | FortiSwitch™ Data Center Series RFC ComplianceRFC and MIB Support*BFDRFC 5880: Bidirectional Forwarding Detection (BFD)RFC 5881: Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)RFC 5882: Generic Application of Bidirectional Forwarding Detection (BFD)BGPRFC 1771: A Border Gateway Protocol 4 (BGP-4)RFC 1965: Autonomous System Confederations for BGPRFC 1997: BGP Communities AttributeRFC 2545: Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain RoutingRFC 2796: BGP Route Reflection - An Alternative to Full Mesh IBGPRFC 2842: Capabilities Advertisement with BGP-4RFC 2858: Multiprotocol Extensions for BGP-4RFC 4271: BGP-4RFC 6286: Autonomous-System-Wide Unique BGP Identifier for BGP-4RFC 6608: Subcodes for BGP Finite State Machine ErrorRFC 6793: BGP Support for Four-Octet Autonomous System (AS) Number SpaceRFC 7606: Revised Error Handling for BGP UPDATE MessagesRFC 7607: Codification of AS 0 ProcessingRFC 7705: Autonomous System Migration Mechanisms and Their Effects on the BGP AS_PATH Attribute RFC 8212: Default External BGP (EBGP) Route Propagation Behavior without PoliciesRFC 8654: Extended Message Support for BGPDHCPRFC 2131: Dynamic Host Configuration ProtocolRFC 3046: DHCP Relay Agent Information OptionRFC 7513: Source Address Validation Improvement (SAVI) Solution for DHCPIP/IPv4RFC 3168: The Addition of Explicit Congestion Notification (ECN) to IPRFC 5227: IPv4 Address Conflict DetectionRFC 5517: Cisco Systems' Private VLANs: Scalable Security in a Multi-Client EnvironmentRFC 7039: Source Address Validation Improvement (SAVI) FrameworkIP MulticastRFC 2362: Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol SpecificationRFC 2710: Multicast Listener Discovery (MLD) for IPv6 (MLDv1)RFC 4541: Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping SwitchesRFC 4605: Internet Group Management Protocol (IGMP)/Multicast Listener Discovery (MLD)-Based Multicast Forwarding (“IGMP/MLD Proxying”)RFC 4607: Source-Specific Multicast for IPIPv6RFC 2464: Transmission of IPv6 Packets over Ethernet Networks: Transmission of IPv6 Packets over Ethernet NetworksRFC 2474: Definition of the Differentiated Services Field (DS Field) in the and IPv6 Headers (DSCP) RFC 2893: Transition Mechanisms for IPv6 Hosts and RoutersRFC 4213: Basic Transition Mechanisms for IPv6 Hosts and RouterRFC 4291: IP Version 6 Addressing ArchitectureRFC 4443: Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification RFC 4861: Neighbor Discovery for IP version 6 (IPv6)RFC 4862: IPv6 Stateless Address Auto configurationRFC 5095: Deprecation of Type 0 Routing Headers in IPv6RFC 6724: Default Address Selection for Internet Protocol version 6 (IPv6)RFC 7113: IPv6 RA GuardRFC 8200: Internet Protocol, Version 6 (IPv6) SpecificationRFC 8201: Path MTU Discovery for IP version 6IS-ISRFC 1195: Use of OSI IS-IS for Routing in TCP/IP and Dual EnvironmentsRFC 5308: Routing IPv6 with IS-ISMIBMIBRFC 1724: RIPv2-MIBRFC 1850: OSPF Version 2 Management Information BaseRFC 2233: The Interfaces Group MIB using SMIv2RFC 2618: Radius-Auth-Client-MIBRFC 2620: Radius-Acc-Client-MIBRFC 2674: Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering and Virtual LAN extensionsRFC 2787: Definitions of Managed Objects for the Virtual Router Redundancy ProtocolRFC 2819: Remote Network Monitoring Management Information BaseRFC 2932: IPv4 Multicast Routing MIBRFC 2934: Protocol Independent Multicast MIB for IPv4RFC 3289: Management Information Base for the Differentiated Services ArchitectureRFC 3433: Entity Sensor Management Information BaseRFC 3621: Power Ethernet MIBRFC 6933: Entity MIB (Version 4)OSPFRFC 1583: OSPF version 2RFC 1765: OSPF Database OverflowRFC 2328: OSPF version 2RFC 2370: The OSPF Opaque LSA OptionRFC 2740: OSPF for IPv6RFC 3101: The OSPF Not-So-Stubby Area (NSSA) OptionRFC 3137: OSPF Stub Router AdvertisementRFC 3623: OSPF Graceful RestartRFC 5340: OSPF for IPv6 (OSPFv3)RFC 5709: OSPFv2 HMAC-SHA Cryptographic AuthenticationRFC 6549: OSPFv2 Multi-Instance ExtensionsRFC 6845: OSPF Hybrid Broadcast and Point-to-Multipoint Interface TypeRFC 6860: Hiding Transit-Only Networks in OSPFRFC 7474: Security Extension for OSPFv2 When Using Manual Key ManagementRFC 7503: OSPF for IPv6RFC 8042: CCITT Draft Recommendation T.4RFC 8362: OSPFv3 Link State Advertisement (LSA) ExtensibilityOTHERRFC 2030: SNTPRFC 3176: InMon Corporation's sFlow: A Method for Monitoring Traffic in Switched and Routed NetworksRFC 3768: VRRPRFC 3954: Cisco Systems NetFlow Services Export Version 9RFC 5101: Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow InformationRFC 5798: VRRPv3 (IPv4 and IPv6)RADIUSRFC 2865: Admin Authentication Using RADIUSRFC 2866: RADIUS AccountingRFC 5176: Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)RIPRFC 1058: Routing Information ProtocolRFC 2080: RIPng for IPv6RFC 2082: RIP-2 MD5 AuthenticationRFC 2453: RIPv2RFC 4822: RIPv2 Cryptographic AuthenticationSNMPRFC 1157: SNMPv1/v2cRFC 2571: Architecture for Describing SNMPDATA SHEET | FortiSwitch ™ Data Center Series7Specifications* Full line rate with minimum packet size of 427bytes on FS-1048E** Fortinet Warranty Policy:/doc/legal/EULA.pdfDATA SHEET | FortiSwitch ™ Data Center Series8Specifications* Full line rate with minimum packet size of 250bytes on FS-3032E, 194bytes on FS-3032D ** Fortinet Warranty Policy:/doc/legal/EULA.pdfDATA SHEET | FortiSwitch™ Data Center Series Order InformationFS-SW-LIC-3000SW License for FS-3000 Series Switches to activate Advanced Features.AC Power Supply FS-PSU-460Spare AC power supply for FS-1048E/1024DFS-PSU-800Spare AC power supply for FS-3032E* When managing a FortiSwitch with a FortiGate via FortiGate Cloud, no additional license is necessary.For details of Transceiver modules, see the Fortinet Transceivers datasheet. Copyright © 2020 Fortinet, Inc. All rights reserved. Fortinet®, FortiGate®, FortiCare® and FortiGuard®, and certain other marks are registered trademarks of Fortinet, Inc., and other Fortinet names herein may also be registered and/or common law trademarks of Fortinet. All other product or company names may be trademarks of their respective owners. Performance and other metrics contained herein were attained in internal lab tests under ideal conditions, and actual performance and other results may vary. Network variables, different network environments and other conditions may affect performance results. Nothing herein represents any binding commitment by Fortinet, and Fortinet disclaims all warranties, whether express or implied, except to the extent Fortinet enters a binding written contract, signed by Fortinet’s General Counsel, with a purchaser that expressly warrants that the identified product will perform according to certain expressly-identified performance metrics and, in such event, only the specific performance metrics expressly identified in such binding written contract shall be binding on Fortinet. For absolute clarity, any such warranty will be limited to performance in the same ideal conditions as in Fortinet’s internal lab tests. Fortinet disclaims in full any covenants, representations, and guarantees pursuant hereto, whether express or implied. Fortinet reserves the right to change, modify, transfer, or otherwise revise this publication without notice, and the most current version of the publication shall be applicable. Fortinet disclaims in full any covenants, representations, and guarantees pursuant hereto, whether express or implied. Fortinet reserves the right to change, modify, transfer, or otherwise revise this publication without notice, and the most current version of the publication shall be applicable.FST-PROD-DS-SW4FS-DC-DAT-R23-202011。

维护上岗证考题(含答案).

维护上岗证考题(含答案).

CS-SD考试参考c 1. (单选)为了解决技术问题而引发的软件补丁实施操作,应该选择以下哪类SR TypeA. RFC-Software UpdateB. RFC-Software UpgradeC. RFC-Solution ImplementationD. CS- Technical Requestabcd 2. (多选)技术审批环节,审批人员需从技术角度对实施方案进行评审,重点关注:()A. 方案与客户网络是否匹配B. 实施步骤是否合理C. 倒回措施是否完备D. 操作时间是否合理及操作风险abcd 3. (多选)以下场景建议不进行网络变更操作:()A. 同一局点、同一时间已计划了其他网络变更操作B. 近期发生重大事故C. 客户网络所在地有重大政治/国际会议召开D. 市场部有重大合同签订abcdeg 4. (多选)对于软件更新实施SR,在创建SR时,以下哪些信息是必填的A. 客户组织B. ProductC. RevisionD. RFC Target RevisionE. SR OwnerF. SR GroupG. RFC Plan End Datec 5. (单选)从哪里可以下载流程文件和指导书?A. Support网站B. 3MS-DocumentC. W3-PDMCD. iLearningf 6. (判断)软件更新实施流程范围包含了为解决现网问题而进行的补丁安装操作对错abd 7. (多选)值守方案需至少包含以下几个关键内容:()A. XX产品值守checklistB. 网络应急预案C. 客户责任人值班表D. 值守管理要求a 8. (单选)对于RFC-Application任务,任务Owner应该将任务分派给A. 运营经理/CS经理B. TDC. NSED. PSEb 9. (单选)系统自动创建的RFC Task默认的Owner为A. RFC SR OwnerB. RFC SR创建人C. TLD. ODd 10. (单选)对于整改,责任人需要根据整改实施计划,统计整改所需的人力及物料并通过()进行整改物料的申请。

rfc相关设置及使用

rfc相关设置及使用

rfc相关设置及使用RFC(Request for Comments)是一种用于定义互联网协议、标准和相关问题的文档。

RFC的格式由互联网工程任务组(IETF)统一规定,它们记录了网络技术的发展和演进过程。

在本文中,我们将介绍RFC相关的设置和使用。

1. 了解RFC的作用和历史:RFC是由IETF组织制定的一种标准化文档,它记录了互联网协议的设计、开发和演化过程。

RFC起源于20世纪60年代的ARPANET,是一种社区驱动的文档,通过共享和讨论来推动互联网技术的发展。

RFC文档旨在提供指南、建议和最佳实践,帮助网络技术人员解决问题。

2. 寻找和阅读RFC文档:RFC文档可以在互联网上免费获取,IETF的官方网站和其他资源库都有存档。

这些文档按照顺序编号,并且以RFC开头,比如RFC 791定义了IPv4协议。

通过搜索引擎或在IETF网站上使用关键词搜索,可以找到特定主题的RFC文档。

阅读RFC文档时,应该注意文档的状态,有一些可能已经被更新或废弃。

3. 使用RFC文档:RFC文档在网络技术的发展过程中起着重要的指导作用。

它们提供了协议规范、算法实现、安全性和隐私等方面的建议。

网络管理员、网络工程师和开发人员可以使用RFC文档来了解和理解特定协议或标准的设计原理和要求。

此外,RFC文档还常用于进行互联网协议的实现、编程和配置。

4. 参与RFC的制定过程:RFC并不是静止的文件,而是一个持续演进的过程。

任何人都可以参与到RFC的制定过程中。

要参与RFC的制定,可以加入IETF并参与相关的工作组或邮件列表。

通过这种方式,个人可以提出改进建议,参与讨论和标准化的制定。

5. 遵循RFC的指导原则:在网络技术领域,遵循RFC的指导原则是至关重要的。

这些指导原则包括设计原则、协议分层、安全性和互操作性等要求。

遵循RFC的指导原则可以确保网络协议的正确性、稳定性和可靠性,同时也可以促进网络技术的发展和创新。

总结起来,RFC在互联网技术领域起着重要的作用,它们记录了互联网协议的发展历程和指导原则。

MIB结构和语法

MIB结构和语法

1? MIB基础知识MIB(Management Information Base,管理信息库)是MO(Managed Object管理对象)定义的集合。

MIB文件是按照ASN.1定义的文本文件。

?每个管理对象都对应一个节点,并且用OID(Object Identifier)来标识;数据管理对象对应叶子节点;所有的管理对象形成了一棵管理树。

1.1 基本概念对象标识:对象标识是一种数据类型,它指明一种授权命名的对象。

表示为一个整数序列,以?(1)标准MIB:rfc1213, rfc1471 , rfc1724, rfc2618等等?? 注:通用性MIB rfc1213习惯称为MIB-II(2)自定义MIB:当标准MIB信息不足以描述厂商设备,需要自定义MIB,但首先要向IANA 组织申请编号。

1.3 MIB管理对象的基本属性管理对象的四个基本属性如下:(1)对象类型(Object Type):定义了一个特定对象的名字,例如sysUpTime。

这个名字只是一个标示符。

MIB对象既可以用这个标示符来表示,也可以用相应的MIB号码来表示。

例如定义internet OBJECT IDENTIFIER ::= { iso org(3) dod(6) 1 }(2)语法(Syntax) :指定了数据类型,例如整数、8位组串数字(字符串;范围为0至255)、对象标识符(预先定义的数据类型别名)或NULL。

NULL是留待的后使用的空位。

(3)访问(Access):表明了这个特定对象的访问级别。

合法的值有:只读、读写、只写和不可存取。

(4)状态(Status):定义了这个对象的实现需要:必备的(被管理节点必须实现该对象);可选的((1(22????第1第第第第第2.1?v1中的(1)简单类型:Integer、Octet String、Object Identifier、Null(2)应用类型:IpAddress、Counter、Gauge、TimeTicks、Opaquev2中的(1)简单类型:Integer32、OctetString、Object Identifier、Null(2)应用类型:IpAddress、Counter32、Counter64、Gauge32、Unsigned32、TimeTicks、Opaque、BIT STRING2.2? 自定义MIB基本原则(1)优先采用标准MIB:如果确实无法满足要求才考虑自定义MIB(2)采用最新的SNMPV2-SMI来定义MIB:使用最新的SNMPv2定义MIB可以使得对MIB的描述更详尽,可用的类型也更丰富。

网络协议RFC文档版本号

网络协议RFC文档版本号

1.表格表1 协议列表说明:●Vxworks中网络协议基本与4.4BSD网络兼容,但增强了实时性和某些特性。

●Vxworks支持的网络协议如下,但并没有指明版本号:应用层:NFS FTP TFTP DHCP SNTP TELNET MIB-II HTTP;传输层:TCP UDP;网络层:IP IP多播CIDR RIP OSPF ICMP ARP IGMP;链路层:Ethernet PPP SLIP CSLIP。

各个版本之间差别不是很大,基本的功能都是相同的。

2.各个网络协议的部分RFC标准RFC1122, 标准RFC3168, RFC6093, RFC6528均为建议标准RFC2228, RFC2640, 建议标准RFC2773, 实验性EXPERIMENTALRFC3659, RFC5797建议标准RFC1782, RFC1783, RFC1784, 建议标准RFC1785, INFORMATIONALRFC2347, RFC2348, RFC2349DRAFT STANDARDRFC1349建议标准RFC950, 标准协议RFC4884建议标准RFC5227, RFC5494建议标准RFC1957, international RFC2449, RFC6186建议标准RFC5506, RFC5761, RFC6051, RFC6222建议标准(14)RSTPRFC3265, RFC3853, RFC4320, RFC4916,RFC5393, RFC5621, RFC5626, RFC5630 , RFC5922, RFC5954, RFC6026, RFC6141建议标准RFC4822HTTPS不应与在RFC 2660中定义的安全超文本传输协议(S-HTTP)相混RFC5785建议标准。

RFC逻辑定律

RFC逻辑定律

RFC逻辑定律SAP 高级应用开发 - RFCRFC Remote function Call 远程功能调用, 是SAP系统之间以及非SAP系统之间程序通信的基本接口技术. 例如BAPI , ALE都是基于RFC实现的RFC连接类型:1.类型2: R/2连接2.类型3: ABAP连接或R/3连接,指定主机名和通信服务3.类型I:内部连接,与当前系统连接到同一ABAP系统中,预定义无法修改,与SM51中所显示的应用服务器名相同4.类型L:逻辑目标,通常工作流系统指定过程中配置的RFC目标即为该类型的逻辑目标5.类型X:指定安装了特殊的ABAP设备驱动程序的系统,必须制定ABAP设备驱动程序名6.类型S:通过SNA或APPC启动的外部程序连接7.类型M:通过CMC到ABAP系统的异步RFC连接8.类型T:通过TCP/IP并使用RFC库或SAP连接器的外部程序连接;分为启动(指定主机名、程序路径名)和注册(RFC服务器程序)两种连接模式。

9.类型G:定义外部系统到本地HTTP连接10.类型H:定义ABAP系统到本地的HTTP连接远程调用RFM:1.远程目标可以是文字或变量,其值为SAP系统中一直的远程目标系统。

2.若远程系统是当前系统中的SAP应用服务器,也可以直接指定应用服务器名称,则SM59中的I类型目标3.SM59定义的RFC目标是区分大小写的。

DESTINATION附加项中目标变量的值必须与其完全一致通过CALL FUNCTION语句进行远程功能调用时,可形成不同的调用模式:1. CALL FUNCTION DESTINATION 以同步RFC方式实现RFM 调用,若后面无其他附加项,则形成同步RFC调用,调用程序等待远程调用结果以继续执行2. CALL FUNCTION STARTING NEW TASK 以异步RFC方式实现RFM调用,调用程序不等待远程调用结果继续执行,结果将在回调子程序(callback subroutine)中接收3. CALL FUNCTION IN BACKROUND TASK 以事务性RFC方式实现RFM调用,远程功能暂不开始执行,等待COMMIT WORK 语句出现时,一次性执行一个或多个远程功能远程功能调用时,仅允许通过值传递参数,不能进行引用传递,因为在RFC过程中,可以传递参数,并返回结果,但不能改变调用程序的上下文对表类型参数,在本地普通功能调用中默认为引用传递,不需要创建内表的本地副本,但RFC不支持引用传递机制,将进行隐式的值传递调用,必须在RFC客户和RFC服务器之间交换整个表,只传输实际表格,如果没有指定表参数,则在被调用功能中使用空表RFC 创建连接类型时:1.LOAD BALANCING选择NO:指定TARGET HOST,SYSTEM NUMBER2. LOAD BALANCING选择YES,要指定TARGET SYSTEM (SM51),MESSAGE SERVER(RZ03),GROUP(SMLG)除去SM59定义的远程目标之外,SAP提供两个预定义目标,可以再CALL FUNCTION 语句的DESTINATION附加附件中使用:l目标NONE,将运行当前程序的应用服务器作为目标系统,调用过程将通过RFC接口实现,并拥有RFC上下文,应用于任意调用类型l目标BACK,用于被远程调用的RFM内部的CALL FUNCTION 语句中的目标制定,通过已建立的RFC连接反过来调用该模块的调用者或已载入的其他功能模块SAP ABAP 系统间的RFC实现(通过RFM实现)远程调用RFM:1.远程目标可以是文字或变量,其值为SAP系统中一直的远程目标系统。

rfc2674.Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering and Vir

rfc2674.Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering and Vir

Network Working Group E. Bell Request for Comments: 2674 3Com Corp. Category: Standards Track A. Smith Extreme Networks P. Langille Newbridge Networks A. Rijhsinghani Cabletron Systems K. McCloghrie cisco Systems August 1999 Definitions of Managed Objects for Bridges with TrafficClasses, Multicast Filtering and Virtual LAN ExtensionsStatus of this MemoThis document specifies an Internet standards track protocol for theInternet community, and requests discussion and suggestions forimprovements. Please refer to the current edition of the "InternetOfficial Protocol Standards" (STD 1) for the standardization stateand status of this protocol. Distribution of this memo is unlimited. Copyright NoticeCopyright (C) The Internet Society (1999). All Rights Reserved. AbstractThis memo defines a portion of the Management Information Base (MIB)for use with network management protocols in TCP/IP based internets.In particular, it defines two MIB modules for managing the newcapabilities of MAC bridges defined by the IEEE 802.1D-1998 MACBridges and the IEEE 802.1Q-1998 Virtual LAN (VLAN) standards forbridging between Local Area Network (LAN) segments. One MIB moduledefines objects for managing the ’Traffic Classes’ and ’EnhancedMulticast Filtering’ components of IEEE 802.1D-1998. The other MIBmodule defines objects for managing IEEE 802.1Q VLANs.Provisions are made for support of transparent bridging. Provisionsare also made so that these objects apply to bridges connected bysubnetworks other than LAN segments. This memo also includes several MIB modules in a manner that is compliant to the SMIv2 [V2SMI].This memo supplements RFC 1493 [BRIDGEMIB] and (to a lesser extent)RFC 1525 [SBRIDGEMIB].Bell, et al. Standards Track [Page 1]Table of Contents1 The SNMP Management Framework (3)2 Overview (4)2.1 Scope (4)3 Structure of MIBs (5)3.1 Structure of Extended Bridge MIB module (5)3.1.1 Relationship to IEEE 802.1D-1998 Manageable Objects (6)3.1.2 Relationship to IEEE 802.1Q Manageable Objects (8)3.1.3 The dot1dExtBase Group (8)3.1.4 The dot1dPriority Group (9)3.1.5 The dot1dGarp Group (9)3.1.6 The dot1dGmrp Group (9)3.1.7 The dot1dTpHCPortTable (9)3.1.8 The dot1dTpPortOverflowTable (9)3.2 Structure of Virtual Bridge MIB module (9)3.2.1 Relationship to IEEE 802.1Q Manageable Objects (9)3.2.2 The dot1qBase Group (13)3.2.3 The dot1qTp Group (13)3.2.4 The dot1qStatic Group (13)3.2.5 The dot1qVlan Group (13)3.3 Textual Conventions (13)3.4 Relationship to Other MIBs (14)3.4.1 Relationship to the ’system’ group (14)3.4.2 Relation to Interfaces MIB (14)3.4.2.1 Layering Model (15)3.4.2.2 ifStackTable (16)3.4.2.3 ifRcvAddressTable (16)3.4.3 Relation to Original Bridge MIB (16)3.4.3.1 The dot1dBase Group (16)3.4.3.2 The dot1dStp Group (17)3.4.3.3 The dot1dTp Group (17)3.4.3.4 The dot1dStatic Group (17)3.4.3.5 Additions to the Original Bridge MIB (18)4 Definitions for Extended Bridge MIB (18)5 Definitions for Virtual Bridge MIB (39)6 Acknowledgments (80)7 Security Considerations (80)8 References (81)9 Authors’ Addresses (84)10 Intellectual Property (85)11 Full Copyright Statement (86)Bell, et al. Standards Track [Page 2]1. The SNMP Management FrameworkThe SNMP Management Framework presently consists of five majorcomponents:o An overall architecture, described in an Architecture forDescribing SNMP Management Frameworks [ARCH].o Mechanisms for describing and naming objects and events for thepurpose of management. The first version of this Structure ofManagement Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [V1SMI], STD 16, RFC 1212 [V1CONCISE] and RFC 1215[V1TRAPS]. The second version, called SMIv2, is described in STD 58, RFC 2578 [V2SMI], STD 58, RFC 2579 [V2TC] and STD 58, RFC2580 [V2CONFORM].o Message protocols for transferring management information. Thefirst version of the SNMP message protocol is called SNMPv1 anddescribed in STD 15, RFC 1157 [V1PROTO]. A second version of the SNMP message protocol, which is not an Internet standards trackprotocol, is called SNMPv2c and described in RFC 1901[V2COMMUNITY] and RFC 1906 [V2TRANS]. The third version of themessage protocol is called SNMPv3 and described in RFC 1906[V2TRANS], Message Processing and Dispatching [V3MPC] and User-based Security Model [V3USM].o Protocol operations for accessing management information. Thefirst set of protocol operations and associated PDU formats isdescribed in STD 15, RFC 1157 [V1PROTO]. A second set ofprotocol operations and associated PDU formats is described inRFC 1905 [V2PROTO].o A set of fundamental applications described in SNMPv3Applications [V3APPS] and the view-based access control mechanism described in View-based Access Control Model [V3VACM].Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB aredefined using the mechanisms defined in the SMI.This memo specifies a MIB module that is compliant to the SMIv2. AMIB conforming to the SMIv1 can be produced through the appropriatetranslations. The resulting translated MIB must be semanticallyequivalent, except where objects or events are omitted because notranslation is possible (use of Counter64). Some machine readableinformation in SMIv2 will be converted into textual descriptions in Bell, et al. Standards Track [Page 3]SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB.2. OverviewA common device present in many networks is the Bridge. This device is used to connect Local Area Network segments below the networklayer. These devices are often known as ’layer 2 switches’.There are two major modes defined for this bridging: Source-Route and transparent. Source-Route bridging is described by IEEE 802.5[802.5]. and is not discussed further in this document.The transparent method of bridging is defined by IEEE 802.1D-1998[802.1D] which is an update to the original IEEE 802.1D specification [802.1D-ORIG]. Managed objects for that original specification oftransparent bridging were defined in RFC 1493 [BRIDGEMIB].The original IEEE 802.1D is augmented by IEEE 802.1Q-1998 [802.1Q] to provide support for ’virtual bridged LANs’ where a single bridgedphysical LAN network may be used to support multiple logical bridged LANs, each of which offers a service approximately the same as thatdefined by IEEE 802.1D. Such virtual LANs (VLANs) are an integralfeature of switched LAN networks. A VLAN can be viewed as a group of end-stations on multiple LAN segments and can communicate as if they were on a single LAN. IEEE 802.1Q defines port-based Virtual LANswhere membership is determined by the bridge port on which dataframes are received. This memo defines the objects needed for themanagement of port-based VLANs in bridge entities.This memo defines those objects needed for the management of abridging entity operating in the transparent mode, as well as someobjects applicable to all types of bridges. Managed objects forSource-Route bridging are defined in RFC 1525 [SRBRIDGEMIB].2.1. ScopeThis MIB includes a comprehensive set of managed objects whichattempts to match the set defined in IEEE 802.1D and IEEE 802.1Q.However, to be consistent with the spirit of the SNMP Framework, asubjective judgement was made to omit the objects from thosestandards most ’costly’ to implement in an agent and least’essential’ for fault and configuration management. The omissionsare described in section 3 below.Bell, et al. Standards Track [Page 4]Historical note:The original bridge MIB [BRIDGEMIB] used the following principles for determining inclusion of an object in the BRIDGE-MIB module:(1) Start with a small set of essential objects and add only asfurther objects are needed.(2) Require objects be essential for either fault or configuration management.(3) Consider evidence of current use and/or utility.(4) Limit the total of objects.(5) Exclude objects which are simply derivable from others inthis or other MIBs.(6) Avoid causing critical sections to be heavily instrumented.The guideline that was followed is one counter per criticalsection per layer.3. Structure of MIBsThis document defines additional objects, on top of those existing in the original BRIDGE-MIB module defined in [BRIDGEMIB]: that MIBmodule is to be maintained unchanged for backwards compatibility.Section 3.4.3 of the present document contains some recommendationsregarding usage of objects in the original bridge MIB by devicesimplementing the enhancements defined here.Two MIB modules are defined here:(1) Managed objects for an extended bridge MIB module P-BRIDGE-MIB for the traffic class and multicast filtering enhancementsdefined by IEEE 802.1D-1998 [802.1D].(2) Managed objects for a virtual bridge MIB module Q-BRIDGE-MIBfor the Virtual LAN bridging enhancements defined by IEEE802.1Q-1998 [802.1Q].3.1. Structure of Extended Bridge MIB moduleObjects in this MIB are arranged into groups. Each group isorganized as a set of related objects. The overall structure andassignment of objects to their groups is shown below.Bell, et al. Standards Track [Page 5]3.1.1. Relationship to IEEE 802.1D-1998 Manageable ObjectsThis section contains a cross-reference to the objects defined inIEEE 802.1D-1998 [802.1D]. It also details those objects that arenot considered necessary in this MIB module.Some objects defined by IEEE 802.1D-1998 have been included in thevirtual bridge MIB module rather than this one: entries indot1qTpGroupTable, dot1qForwardAllTable anddot1qForwardUnregisteredTable are required for virtual bridged LANswith additional indexing (e.g. per-VLAN, per-FDB) and so are notdefined here. Instead, devices which do not implement virtualbridged LANs but do implement the Extended Forwarding Servicesdefined by IEEE 802.1D (i.e. dynamic learning of multicast groupaddresses and group service requirements in the filtering database)should implement these tables with a fixed value for dot1qFdbId (the value 1 is recommended) or dot1qVlanIndex (the value 1 isrecommended). Devices which support Extended Filtering Servicesshould support dot1qTpGroupTable, dot1qForwardAllTable anddot1qForwardUnregisteredTable.Bell, et al. Standards Track [Page 6]Extended Bridge MIB Name IEEE 802.1D-1998 Namedot1dExtBase Bridgedot1dDeviceCapabilitiesdot1dExtendedFilteringServicesdot1dTrafficClassesdot1dTrafficClassesEnableddot1dGmrpStatus .ApplicantAdministrativeControl dot1dPrioritydot1dPortPriorityTabledot1dPortDefaultUserPriority .UserPrioritydot1dPortNumTrafficClassesdot1dUserPriorityRegenTable .UserPriorityRegenerationTabledot1dUserPrioritydot1dRegenUserPrioritydot1dTrafficClassTable .TrafficClassTabledot1dTrafficClassPrioritydot1dTrafficClassdot1dPortOutboundAccessPriorityTable.OutboundAccessPriorityTabledot1dPortOutboundAccessPrioritydot1dGarpdot1dPortGarpTabledot1dPortGarpJoinTime .JoinTimedot1dPortGarpLeaveTime .LeaveTimedot1dPortGarpLeaveAllTime .LeaveAllTimedot1dGmrpdot1dPortGmrpTabledot1dPortGmrpStatus .ApplicantAdministrativeControldot1dPortGmrpFailedRegistrations .FailedRegistrationsdot1dPortGmrpLastPduOrigin .OriginatorOfLastPDUdot1dTpdot1dTpHCPortTabledot1dTpHCPortInFrames .BridgePort.FramesReceiveddot1dTpHCPortOutFrames .ForwardOutBounddot1dTpHCPortInDiscards .DiscardInbounddot1dTpPortOverflowTabledot1dTpPortInOverflowFrames .BridgePort.FramesReceiveddot1dTpPortOutOverflowFrames .ForwardOutBounddot1dTpPortInOverflowDiscards .DiscardInboundBell, et al. Standards Track [Page 7]The following IEEE 802.1D-1998 management objects have not beenincluded in the Bridge MIB for the indicated reasons.IEEE 802.1D-1998 Object DispositionBridge.StateValue not considered usefulBridge.ApplicantAdministrativeControlnot provided per-attribute(e.g. per-VLAN, per-Group).Only per-{device,port,application} control is provided in this MIB.3.1.2. Relationship to IEEE 802.1Q Manageable ObjectsThis section contains section number cross-references to manageableobjects defined in IEEE 802.1Q-1998 [802.1Q]. These objects havebeen included in this MIB as they provide a natural fit with the IEEE 802.1D objects with which they are co-located.Extended Bridge MIB Name IEEE 802.1Q-1998 Section and Name dot1dExtBase Bridgedot1dDeviceCapabilitiesdot1qStaticEntryIndividualPort 5.2 implementation optionsdot1qIVLCapabledot1qSVLCapabledot1qHybridCapabledot1qConfigurablePvidTagging 12.10.1.1 read bridge vlanconfigdot1dLocalVlanCapabledot1dPortCapabilitiesTabledot1dPortCapabilitiesdot1qDot1qTagging 5.2 implementation optionsdot1qConfigurableAcceptableFrameTypes5.2 implementation optionsdot1qIngressFiltering 5.2 implementation options3.1.3. The dot1dExtBase GroupThis group contains the objects which are applicable to all bridgesimplementing the traffic class and multicast filtering features ofIEEE 802.1D-1998 [802.1D]. It includes per-device configuration ofGARP and GMRP protocols. This group will be implemented by alldevices which implement the extensions defined in 802.1D-1998.Bell, et al. Standards Track [Page 8]3.1.4. The dot1dPriority GroupThis group contains the objects for configuring and reporting status of priority-based queuing mechanisms in a bridge. This includes per- port user_priority treatment, mapping of user_priority in frames into internal traffic classes and outbound user_priority andaccess_priority.3.1.5. The dot1dGarp GroupThis group contains the objects for configuring and reporting onoperation of the Generic Attribute Registration Protocol (GARP).3.1.6. The dot1dGmrp GroupThis group contains the objects for configuring and reporting onoperation of the GARP Multicast Registration Protocol (GMRP).3.1.7. The dot1dTpHCPortTableThis table extends the dot1dTp group from the original bridge MIB[BRIDGEMIB] and contains the objects for reporting port bridgingstatistics for high capacity network interfaces.3.1.8. The dot1dTpPortOverflowTableThis table extends the dot1dTp group from the original bridge MIB[BRIDGEMIB] and contains the objects for reporting the upper bits of port bridging statistics for high capacity network interfaces forwhen 32-bit counters are inadequate.3.2. Structure of Virtual Bridge MIB moduleObjects in this MIB are arranged into groups. Each group isorganized as a set of related objects. The overall structure andassignment of objects to their groups is shown below. Somemanageable objects defined in the original bridge MIB [BRIDGEMIB]need to be indexed differently when they are used in a VLAN bridging environment: these objects are, therefore, effectively duplicated by new objects with different indexing which are defined in the Virtual Bridge MIB.3.2.1. Relationship to IEEE 802.1Q Manageable ObjectsThis section contains section-number cross-references to manageableobjects defined in clause 12 of IEEE 802.1Q-1998 [802.1Q]. It alsodetails those objects that are not considered necessary in this MIBmodule.Bell, et al. Standards Track [Page 9]Note: unlike IEEE 802.1D-1998, IEEE 802.1Q-1998 [802.1Q] did notdefine exact syntax for a set of managed objects: the followingcross-references indicate the section numbering of the descriptionsof management operations from clause 12 in the latter document.Virtual Bridge MIB object IEEE 802.1Q-1998 Referencedot1qBasedot1qVlanVersionNumber 12.10.1.1 read bridge vlan config dot1qMaxVlanId 12.10.1.1 read bridge vlan config dot1qMaxSupportedVlans 12.10.1.1 read bridge vlan config dot1qNumVlansdot1qGvrpStatus 12.9.2.1/2 read/set garpapplicant controlsdot1qTpdot1qFdbTabledot1qFdbIddot1qFdbDynamicCount 12.7.1.1.3 read filtering d/basedot1qTpFdbTabledot1qTpFdbAddressdot1qTpFdbPortdot1qTpFdbStatusdot1qTpGroupTable 12.7.7.1 read filtering entrydot1qTpGroupAddressdot1qTpGroupEgressPortsdot1qTpGroupLearntdot1qForwardAllTable 12.7.7.1 read filtering entrydot1qForwardAllPortsdot1qForwardAllStaticPortsdot1qForwardAllForbiddenPortsdot1qForwardUnregisteredTable 12.7.7.1 read filtering entrydot1qForwardUnregisteredPortsdot1qForwardUnregisteredStaticPortsdot1qForwardUnregisteredForbiddenPortsdot1qStaticdot1qStaticUnicastTable 12.7.7.1 create/delete/readfiltering entry12.7.6.1 read permanent databasedot1qStaticUnicastAddressdot1qStaticUnicastReceivePortdot1qStaticUnicastAllowedToGoTodot1qStaticUnicastStatusdot1qStaticMulticastTable 12.7.7.1 create/delete/readfiltering entry12.7.6.1 read permanent databasedot1qStaticMulticastAddressdot1qStaticMulticastReceivePortdot1qStaticMulticastStaticEgressPortsBell, et al. Standards Track [Page 10]dot1qStaticMulticastForbiddenEgressPortsdot1qStaticMulticastStatusdot1qVlandot1qVlanNumDeletesdot1qVlanCurrentTable 12.10.2.1 read vlan configuration 12.10.3.5 read VID to FIDallocations12.10.3.6 read FID allocated toVID12.10.3.7 read VIDs allocated toFIDdot1qVlanTimeMarkdot1qVlanIndexdot1qVlanFdbIddot1qVlanCurrentEgressPortsdot1qVlanCurrentUntaggedPortsdot1qVlanStatusdot1qVlanCreationTimedot1qVlanStaticTable 12.7.7.1/2/3 create/delete/readfiltering entry12.7.6.1 read permanent database12.10.2.2 create vlan config12.10.2.3 delete vlan configdot1qVlanStaticName 12.4.1.3 set bridge namedot1qVlanStaticEgressPortsdot1qVlanForbiddenEgressPortsdot1qVlanStaticUntaggedPortsdot1qVlanStaticRowStatusdot1qNextFreeLocalVlanIndexdot1qPortVlanTable 12.10.1.1 read bridge vlanconfigurationdot1qPvid 12.10.1.2 configure PVID valuesdot1qPortAcceptableFrameTypes 12.10.1.3 configure acceptableframe types parameterdot1qPortIngressFiltering 12.10.1.4 configure ingressfiltering parametersdot1qPortGvrpStatus 12.9.2.2 read/set garp applicantcontrolsdot1qPortGvrpFailedRegistrationsdot1qPortGvrpLastPduOrigindot1qPortVlanStatisticsTable 12.6.1.1 read forwarding portcountersdot1qTpVlanPortInFramesdot1qTpVlanPortOutFramesdot1qTpVlanPortInDiscardsdot1qTpVlanPortInOverflowFramesdot1qTpVlanPortOutOverflowFramesdot1qTpVlanPortInOverflowDiscardsBell, et al. Standards Track [Page 11]dot1qPortVlanHCStatisticsTable 12.6.1.1 read forwarding portcountersdot1qTpVlanPortHCInFramesdot1qTpVlanPortHCOutFramesdot1qTpVlanPortHCInDiscardsdot1qLearningConstraintsTable 12.10.3.1/3/4 read/set/deletevlan learning constraints 12.10.3.2 read vlan learningconstraints for VIDdot1qConstraintVlandot1qConstraintSetdot1qConstraintTypedot1qConstraintStatusdot1qConstraintSetDefaultdot1qConstraintTypeDefaultThe following IEEE 802.1Q management objects have not been includedin the Bridge MIB for the indicated reasons.IEEE 802.1Q-1998 Operation Dispositionreset bridge (12.4.1.4) not considered usefulreset vlan bridge (12.10.1.5) not considered usefulread forwarding port counters (12.6.1.1)discard on error details not considered usefulread permanent database (12.7.6.1)permanent database size not considered usefulnumber of static filtering count rows inentries dot1qStaticUnicastTable +dot1qStaticMulticastTablenumber of static VLAN count rows inregistration entries dot1qVlanStaticTableread filtering entry range use GetNext operation.(12.7.7.4)read filtering database (12.7.1.1)filtering database size not considered usefulnumber of dynamic group address count rows applicable to each entries (12.7.1.3) FDB in dot1dTpGroupTableBell, et al. Standards Track [Page 12]read garp state (12.9.3.1) not considered usefulnotify vlan registration failure not considered useful(12.10.1.6)notify learning constraint violation(12.10.3.10) not considered useful3.2.2. The dot1qBase GroupThis mandatory group contains the objects which are applicable to all bridges implementing IEEE 802.1Q virtual LANs.3.2.3. The dot1qTp GroupThis group contains objects that control the operation and report the status of transparent bridging. This includes management of thedynamic Filtering Databases for both unicast and multicastforwarding. This group will be implemented by all bridges thatperform destination-address filtering.3.2.4. The dot1qStatic GroupThis group contains objects that control static configurationinformation for transparent bridging. This includes management ofthe static entries in the Filtering Databases for both unicast andmulticast forwarding.3.2.5. The dot1qVlan GroupThis group contains objects that control configuration and reportstatus of the Virtual LANs known to a bridge. This includesmanagement of the statically configured VLANs as well as reportingVLANs discovered by other means e.g. GVRP. It also controlsconfiguration and reports status of per-port objects relating toVLANs and reports traffic statistics. It also provides formanagement of the VLAN Learning Constraints.3.3. Textual ConventionsThe datatypes MacAddress, BridgeId, Timeout, EnabledStatus, PortList, VlanIndex and VlanId are used as textual conventions in thisdocument. These textual conventions have NO effect on either thesyntax nor the semantics of any managed object. Objects definedusing these conventions are always encoded by means of the rules that define their primitive type. Hence, no changes to the SMI or theSNMP are necessary to accommodate these textual conventions which are adopted merely for the convenience of readers.Bell, et al. Standards Track [Page 13]3.4. Relationship to Other MIBsAs described above, some IEEE 802.1D management objects have not been included in this MIB because they overlap with objects in other MIBs applicable to a bridge implementing this MIB. In particular, it isassumed that a bridge implementing this MIB will also implement (atleast) the ’system’ group defined in MIB-II [MIB2], the ’interfaces’ group defined in [INTERFACEMIB] and the original bridge MIB[BRIDGEMIB].3.4.1. Relationship to the ’system’ groupIn MIB-II, the ’system’ group is defined as being mandatory for allsystems such that each managed entity contains one instance of eachobject in the ’system’ group. Thus, those objects apply to theentity as a whole irrespective of whether the entity’s solefunctionality is bridging, or whether bridging is only a subset ofthe entity’s functionality.3.4.2. Relation to Interfaces MIBThe Interfaces Group MIB [INTERFACEMIB], requires that any MIB which is an adjunct of the Interfaces Group MIB, clarify specific areaswithin the Interfaces Group MIB. These areas were intentionally left vague in the Interfaces Group MIB to avoid over-constraining the MIB, thereby precluding management of certain media-types.The Interfaces Group MIB enumerates several areas which a media-specific MIB must clarify. Each of these areas is addressed in afollowing subsection. The implementor is referred to the Interfaces Group MIB in order to understand the general intent of these areas.In the Interfaces Group MIB, the ’interfaces’ group is defined asbeing mandatory for all systems and contains information on anentity’s interfaces, where each interface is thought of as beingattached to a ‘subnetwork’. (Note that this term is not to beconfused with ‘subnet’ which refers to an addressing partitioningscheme used in the Internet suite of protocols.) The term ’segment’ is used in this memo to refer to such a subnetwork, whether it be an Ethernet segment, a ’ring’, a WAN link, or even an X.25 virtualcircuit.Implicit in this Extended Bridge MIB is the notion of ports on abridge. Each of these ports is associated with one interface of the ’interfaces’ group (one row in ifTable) and, in most situations, each port is associated with a different interface. However, there aresituations in which multiple ports are associated with the sameBell, et al. Standards Track [Page 14]interface. An example of such a situation would be several portseach corresponding one-to-one with several X.25 virtual circuits but all on the same interface.Each port is uniquely identified by a port number. A port number has no mandatory relationship to an interface number, but in the simplecase a port number will have the same value as the correspondinginterface’s interface number. Port numbers are in the range(1..dot1dBaseNumPorts).Some entities perform other functionality as well as bridging through the sending and receiving of data on their interfaces. In suchsituations, only a subset of the data sent/received on an interfaceis within the domain of the entity’s bridging functionality. Thissubset is considered to be delineated according to a set ofprotocols, with some protocols being bridged, and other protocols not being bridged. For example, in an entity which exclusively performed bridging, all protocols would be considered as being bridged, whereas in an entity which performed IP routing on IP datagrams and onlybridged other protocols, only the non-IP data would be considered as being bridged. Thus, this Extended Bridge MIB (and in particular,its counters) is applicable only to that subset of the data on anentity’s interfaces which is sent/received for a protocol beingbridged. All such data is sent/received via the ports of the bridge.3.4.2.1. Layering ModelThis memo assumes the interpretation of the Interfaces Group to be in accordance with the Interfaces Group MIB [INTERFACEMIB] which states that the interfaces table (ifTable) contains information on themanaged resource’s interfaces and that each sub-layer below theinternetwork layer of a network interface is considered an interface. This document recommends that, within an entity, VLANs which areinstantiated as an entry in dot1qVlanCurrentTable by eithermanagement configuration through dot1qVlanStaticTable or by dynamicmeans (e.g. through GVRP), are NOT also represented by an entry inifTable.Where an entity contains higher-layer protocol entities e.g. IP-layer interfaces that transmit and receive traffic to/from a VLAN, theseshould be represented in the ifTable as interfaces of typepropVirtual(53). Protocol-specific types such as l3ipxvlan(137)should not be used here since there is no implication that the bridge will perform any protocol filtering before delivering up to thesevirtual interfaces.Bell, et al. Standards Track [Page 15]3.4.2.2. ifStackTableIn addition, the Interfaces Group MIB [INTERFACEMIB] defines a table ’ifStackTable’ for describing the relationship between logicalinterfaces within an entity. It is anticipated that implementorswill use this table to describe the binding of e.g. IP interfaces to physical ports, although the presence of VLANs makes therepresentation less than perfect for showing connectivity: theifStackTable cannot represent the full capability of the IEEE 802.1Q VLAN bridging standard since that makes a distinction between VLANbindings on ’ingress’ to and ’egress’ from a port: theserelationships may or may not be symmetrical whereas Interface MIBEvolution assumes a symmetrical binding for transmit and receive.This makes it necessary to define other manageable objects forconfiguring which ports are members of which VLANs.3.4.2.3. ifRcvAddressTableThis table contains all MAC addresses, unicast, multicast, andbroadcast, for which an interface will receive packets and forwardthem up to a higher layer entity for local consumption. Note thatthis does not include addresses for data-link layer control protocols such as Spanning-Tree, GMRP or GVRP. The format of the address,contained in ifRcvAddressAddress, is the same as for ifPhysAddress.This table does not include unicast or multicast addresses which are accepted for possible forwarding out some other port. This table is explicitly not intended to provide a bridge address filteringmechanism.3.4.3. Relation to Original Bridge MIBThis section defines how objects in the original bridge MIB module[BRIDGEMIB] should be represented for devices which implement theextensions: some of the old objects are less useful in such devicesbut must still be implemented for reasons of backwards compatibility. Note that formal conformance statements for that MIB module do notexist since it is defined in SMIv1.3.4.3.1. The dot1dBase GroupThis mandatory group contains the objects which are applicable to all types of bridges. Interpretation of this group is unchanged.Bell, et al. Standards Track [Page 16]。

Network MIB Agent Network Management

Network MIB Agent Network Management

The Ohio State University
Raj Jain 30-6
Global Naming Hierarchy
ccitt(0) standard (0) iso9314 (9314) fddiMIB (1) directory (1) iso (1) joint-iso-ccitt (2) org (3) dod (6) internet (1) mgmt(2) mib (1) system (1) interfaces (2)
The Ohio State University
Raj Jain 30-13
OSI Network Management Standards
q q q q q
Common Management Information Protocol (CMIP) Common Management Information Service (CMIS) CMIP is the management (application layer) protocol CMIS is the service interface to CMIP M-GET (read attribute), M-SET (write attribute), MEVENT-REPORT (report an event), M-ACTION (perform an action), M-CREATE (create an instance), M-DELETE (delete an instance)
The Ohio State University
Raj Jain 30-14
Summary
q q q q
Management = Initialization, Monitoring, and Control SNMP = Only 5 commands Standard MIBs defined for each object Uses ASN.1 encoding

MIB结构和语法

MIB结构和语法

1 MIB基础知识MIB(Management Information Base,管理信息库)是MO(Managed Object 管理对象)定义的集合。

MIB文件是按照ASN.1定义的文本文件。

每个管理对象都对应一个节点,并且用OID(Object Identifier)来标识;数据管理对象对应叶子节点;所有的管理对象形成了一棵管理树。

1.1 基本概念对象标识:对象标识是一种数据类型,它指明一种授权命名的对象。

表示为一个整数序列,以点分隔。

MIB树:表示对象标识的整数构成一个树型结构,类似于DNS和文件系统。

对象标识从顶部开始,顶部没有标识,以root表示。

所有的MIB变量都从1.3.6.1.2.1这个标识开始。

树上的每个节点还有文字名,例如:1.3.6.1.2.1就和.dod.internet.memt.mib对应。

图1 管理信息库的对象命名举例1.2 MIB分类MIB依据数据的通用性可以分为:(1)标准MIB:rfc1213, rfc1471 , rfc1724, rfc2618等等注:通用性MIB rfc1213习惯称为MIB-II(2)自定义MIB:当标准MIB信息不足以描述厂商设备,需要自定义MIB,但首先要向IANA组织申请编号。

1.3 MIB管理对象的基本属性管理对象的四个基本属性如下:(1)对象类型(Object Type):定义了一个特定对象的名字,例如sysUpTime。

这个名字只是一个标示符。

MIB对象既可以用这个标示符来表示,也可以用相应的MIB号码来表示。

例如定义internet OBJECT IDENTIFIER ::= { iso org(3) dod(6) 1 } 那么既可以用internet也可以用字串.1.3.6.1来表示这个对象。

(2)语法(Syntax) :指定了数据类型,例如整数、8位组串数字(字符串;范围为0至255)、对象标识符(预先定义的数据类型别名)或NULL。

金仓数据库认证工程师(KCE)考试试题_含答案_

金仓数据库认证工程师(KCE)考试试题_含答案_

金仓数据库认证工程师(KCE)考试试题姓名:学号:特别说明:考试时间为90分钟,考试形式为闭卷考试。

一、多项选择题(每题5分,共25分)1.启动KingbaseES 数据库查询分析器的方法有(ABC)A.通过开始菜单,选择KingbaseES安装程序组中的查询分析器启动B.通过JManager工具启动C.在命令行输入如下命令:"java -jar JSQL.jar"启动D.在控制管理器中点击启动按钮启动2.三权分立包括(ABD)A.系统管理员B.安全管理员C.系统分析员D.审计管理员3.数据更新语句有以下几类(ACD)A.插入语句B.查询语句C.修改语句D.删除语句4. KingbaseES支持下列哪些字符集?(ABCD )A.GBK B.ASCII C.UNICODE D.GB180305.下列属于KingbaseES命令行工具的有?(BCD )A.Isqlplus B.Iagent C.Ikill D.Isql1二、判断题(每题3分,共15分)1.如果在本机上安装了一个KingbaseES数据库,数据库名为AAA,数据库用户名为:BBB,密码为:CCC。

端口号为54321。

那么,isql系统工具的登录可以使用下面的命令实现:在命令行中bin目录下输入“isql -h localhost -p 54321 -U BBB -W CCC -d AAA”回车即可。

(Y)2. 在KingbaseES数据库SCOTT模式下的EMP表中,查询与SMITH这个员工职位相同的所有员工的员工编号,姓名,薪水和职位。

可以用以下子查询语句实现:(F)SELECT Empno, Ename, Sal, JobFROM EMPWHERE Job=(SELECT JobFROM EMPWHERE Ename='SMITH');3. 在进行数据库删除时,被删除的数据库有用户连接时,不影响数据库的正常删除。

rfc1212

rfc1212

Network Working Group M. Rose Request for Comments: 1212 Performance Systems International K. McCloghrie Hughes LAN Systems Editors March 1991 Concise MIB DefinitionsStatus of this MemoThis memo defines a format for producing MIB modules. This RFCspecifies an IAB standards track document for the Internet community, and requests discussion and suggestions for improvements. Pleaserefer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol.Distribution of this memo is unlimited.Table of Contents1. Abstract (2)2. Historical Perspective (2)3. Columnar Objects (3)3.1 Row Deletion (4)3.2 Row Addition (4)4. Defining Objects (5)4.1 Mapping of the OBJECT-TYPE macro (7)4.1.1 Mapping of the SYNTAX clause (7)4.1.2 Mapping of the ACCESS clause (8)4.1.3 Mapping of the STATUS clause (8)4.1.4 Mapping of the DESCRIPTION clause (8)4.1.5 Mapping of the REFERENCE clause (8)4.1.6 Mapping of the INDEX clause (8)4.1.7 Mapping of the DEFVAL clause (10)4.1.8 Mapping of the OBJECT-TYPE value (11)4.2 Usage Example (11)5. Appendix: DE-osifying MIBs (13)5.1 Managed Object Mapping (14)5.1.1 Mapping to the SYNTAX clause (15)5.1.2 Mapping to the ACCESS clause (15)5.1.3 Mapping to the STATUS clause (15)5.1.4 Mapping to the DESCRIPTION clause (15)5.1.5 Mapping to the REFERENCE clause (16)5.1.6 Mapping to the INDEX clause (16)5.1.7 Mapping to the DEFVAL clause (16)5.2 Action Mapping (16)5.2.1 Mapping to the SYNTAX clause (16)5.2.2 Mapping to the ACCESS clause (16)SNMP Working Group [Page 1]5.2.3 Mapping to the STATUS clause (16)5.2.4 Mapping to the DESCRIPTION clause (16)5.2.5 Mapping to the REFERENCE clause (16)6. Acknowledgements (17)7. References (18)8. Security Considerations (19)9. Authors’ Addresses (19)1. AbstractThis memo describes a straight-forward approach toward producingconcise, yet descriptive, MIB modules. It is intended that allfuture MIB modules be written in this format.2. Historical PerspectiveAs reported in RFC 1052, IAB Recommendations for the Development ofInternet Network Management Standards [1], a two-prong strategy fornetwork management of TCP/IP-based internets was undertaken. In the short-term, the Simple Network Management Protocol (SNMP), defined in RFC 1067, was to be used to manage nodes in the Internet community.In the long-term, the use of the OSI network management framework was to be examined. Two documents were produced to define the management information: RFC 1065, which defined the Structure of ManagementInformation (SMI), and RFC 1066, which defined the ManagementInformation Base (MIB). Both of these documents were designed so as to be compatible with both the SNMP and the OSI network managementframework.This strategy was quite successful in the short-term: Internet-based network management technology was fielded, by both the research andcommercial communities, within a few months. As a result of this,portions of the Internet community became network manageable in atimely fashion.As reported in RFC 1109, Report of the Second Ad Hoc NetworkManagement Review Group [2], the requirements of the SNMP and the OSI network management frameworks were more different than anticipated.As such, the requirement for compatibility between the SMI/MIB andboth frameworks was suspended. This action permitted the operational network management framework, based on the SNMP, to respond to newoperational needs in the Internet community by producing MIB-II.In May of 1990, the core documents were elevated to "StandardProtocols" with "Recommended" status. As such, the Internet-standard network management framework consists of: Structure andIdentification of Management Information for TCP/IP-based internets, RFC 1155 [3], which describes how managed objects contained in the SNMP Working Group [Page 2]MIB are defined; Management Information Base for Network Managementof TCP/IP-based internets, which describes the managed objectscontained in the MIB, RFC 1156 [4]; and, the Simple NetworkManagement Protocol, RFC 1157 [5], which defines the protocol used to manage these objects. Consistent with the IAB directive to producesimple, workable systems in the short-term, the list of managedobjects defined in the Internet-standard MIB was derived by takingonly those elements which are considered essential. However, the SMI defined three extensibility mechanisms: one, the addition of newstandard objects through the definitions of new versions of the MIB; two, the addition of widely-available but non-standard objectsthrough the experimental subtree; and three, the addition of private objects through the enterprises subtree. Such additional objects can not only be used for vendor-specific elements, but also forexperimentation as required to further the knowledge of which otherobjects are essential.As more objects are defined using the second method, experience hasshown that the resulting MIB descriptions contain redundantinformation. In order to provide for MIB descriptions which are more concise, and yet as informative, an enhancement is suggested. Thisenhancement allows the author of a MIB to remove the redundantinformation, while retaining the important descriptive text.Before presenting the approach, a brief presentation of columnarobject handling by the SNMP is necessary. This explains and further motivates the value of the enhancement.3. Columnar ObjectsThe SNMP supports operations on MIB objects whose syntax isObjectSyntax as defined in the SMI. Informally stated, SNMPoperations apply exclusively to scalar objects. However, it isconvenient for developers of management applications to imposeimaginary, tabular structures on the ordered collection of objectsthat constitute the MIB. Each such conceptual table contains zero or more rows, and each row may contain one or more scalar objects,termed columnar objects. Historically, this conceptualization hasbeen formalized by using the OBJECT-TYPE macro to define both anobject which corresponds to a table and an object which correspondsto a row in that table. (The ACCESS clause for such objects is"not-accessible", of course.) However, it must be emphasized that, at the protocol level, relationships among columnar objects in the same row is a matter of convention, not of protocol.Note that there are good reasons why the tabular structure is not amatter of protocol. Consider the operation of the SNMP Get-Next-PDU acting on the last columnar object of an instance of a conceptual SNMP Working Group [Page 3]row; it returns the next column of the first conceptual row or thefirst object instance occurring after the table. In contrast, if the rows were a matter of protocol, then it would instead return anerror. By not returning an error, a single PDU exchange informs the manager that not only has the end of the conceptual row/table beenreached, but also provides information on the next object instance,thereby increasing the information density of the PDU exchange.3.1. Row DeletionNonetheless, it is highly useful to provide a means whereby aconceptual row may be removed from a table. In MIB-II, this wasachieved by defining, for each conceptual row, an integer-valuedcolumnar object. If a management station sets the value of thisobject to some value, usually termed "invalid", then the effect isone of invalidating the corresponding row in the table. However, it is an implementation-specific matter as to whether an agent removesan invalidated entry from the table. Accordingly, managementstations must be prepared to receive tabular information from agents that corresponds to entries not currently in use. Properinterpretation of such entries requires examination of the columnarobject indicating the in-use status.3.2. Row AdditionIt is also highly useful to have a clear understanding of how aconceptual row may be added to a table. In the SNMP, at the protocol level, a management station issues an SNMP set operation containingan arbitrary set of variable bindings. In the case that an agentdetects that one or more of those variable bindings refers to anobject instance not currently available in that agent, it may,according to the rules of the SNMP, behave according to any of thefollowing paradigms:(1) It may reject the SNMP set operation as referring tonon-existent object instances by returning a responsewith the error-status field set to "noSuchName" and theerror-index field set to refer to the first vacuousreference.(2) It may accept the SNMP set operation as requesting thecreation of new object instances corresponding to eachof the object instances named in the variable bindings.The value of each (potentially) newly created objectinstance is specified by the "value" component of therelevant variable binding. In this case, if the request specifies a value for a newly (or previously) createdobject that it deems inappropriate by reason of value or SNMP Working Group [Page 4]syntax, then it rejects the SNMP set operation byresponding with the error-status field set to badValueand the error-index field set to refer to the firstoffending variable binding.(3) It may accept the SNMP set operation and create newobject instances as described in (2) above and, inaddition, at its discretion, create supplemental objectinstances to complete a row in a conceptual table ofwhich the new object instances specified in the requestmay be a part.It should be emphasized that all three of the above behaviors arefully conformant to the SNMP specification and are fully acceptable, subject to any restrictions which may be imposed by access controland/or the definitions of the MIB objects themselves.4. Defining ObjectsThe Internet-standard SMI employs a two-level approach towards object definition. A MIB definition consists of two parts: a textual part, in which objects are placed into groups, and a MIB module, in whichobjects are described solely in terms of the ASN.1 macro OBJECT-TYPE, which is defined by the SMI.An example of the former definition might be:OBJECT:-------sysLocation { system 6 }Syntax:DisplayString (SIZE (0..255))Definition:The physical location of this node (e.g., "telephonecloset, 3rd floor").Access:read-only.Status:mandatory.An example of the latter definition might be:sysLocation OBJECT-TYPESYNTAX DisplayString (SIZE (0..255))SNMP Working Group [Page 5]STATUS mandatory::= { system 6 }In the interests of brevity and to reduce the chance ofediting errors, it would seem useful to combine the twodefinitions. This can be accomplished by defining anextension to the OBJECT-TYPE macro:IMPORTSObjectNameFROM RFC1155-SMIDisplayStringFROM RFC1158-MIB;OBJECT-TYPE MACRO ::=BEGINTYPE NOTATION ::=-- must conform to-- RFC1155’s ObjectSyntax"SYNTAX" type(ObjectSyntax)"ACCESS" Access"STATUS" StatusDescrPartReferPartIndexPartDefValPartVALUE NOTATION ::= value (VALUE ObjectName)Access ::= "read-only"| "read-write"| "write-only"| "not-accessible"Status ::= "mandatory"| "optional"| "obsolete"| "deprecated"DescrPart ::="DESCRIPTION" value (description DisplayString) | emptyReferPart ::="REFERENCE" value (reference DisplayString)| emptyIndexPart ::="INDEX" "{" IndexTypes "}"SNMP Working Group [Page 6]IndexTypes ::=IndexType | IndexTypes "," IndexTypeIndexType ::=-- if indexobject, use the SYNTAX-- value of the correspondent-- OBJECT-TYPE invocationvalue (indexobject ObjectName)-- otherwise use named SMI type-- must conform to IndexSyntax below| type (indextype)DefValPart ::="DEFVAL" "{" value (defvalue ObjectSyntax) "}" | emptyENDIndexSyntax ::=CHOICE {numberINTEGER (0..MAX),stringOCTET STRING,objectOBJECT IDENTIFIER,addressNetworkAddress,ipAddressIpAddress}4.1. Mapping of the OBJECT-TYPE macroIt should be noted that the expansion of the OBJECT-TYPE macro issomething which conceptually happens during implementation and notduring run-time.4.1.1. Mapping of the SYNTAX clauseThe SYNTAX clause, which must be present, defines the abstract datastructure corresponding to that object type. The ASN.1 language [6] is used for this purpose. However, the SMI purposely restricts theASN.1 constructs which may be used. These restrictions are madeexpressly for simplicity.SNMP Working Group [Page 7]4.1.2. Mapping of the ACCESS clauseThe ACCESS clause, which must be present, defines the minimum levelof support required for that object type. As a local matter,implementations may support other access types (e.g., animplementation may elect to permitting writing a variable marked asread-only). Further, protocol-specific "views" (e.g., thoseindirectly implied by an SNMP community) may make furtherrestrictions on access to a variable.4.1.3. Mapping of the STATUS clauseThe STATUS clause, which must be present, defines the implementation support required for that object type.4.1.4. Mapping of the DESCRIPTION clauseThe DESCRIPTION clause, which need not be present, contains a textual definition of that object type which provides all semanticdefinitions necessary for implementation, and should embody anyinformation which would otherwise be communicated in any ASN.1commentary annotations associated with the object. Note that, inorder to conform to the ASN.1 syntax, the entire value of this clause must be enclosed in double quotation marks, although the value may be multi-line.Further, note that if the MIB module does not contain a textualdescription of the object type elsewhere then the DESCRIPTION clause must be present.4.1.5. Mapping of the REFERENCE clauseThe REFERENCE clause, which need not be present, contains a textualcross-reference to an object defined in some other MIB module. This is useful when de-osifying a MIB produced by some other organization.4.1.6. Mapping of the INDEX clauseThe INDEX clause, which may be present only if that object typecorresponds to a conceptual row, defines instance identificationinformation for that object type. (Historically, each MIB definition contained a section entitled "Identification of OBJECT instances for use with the SNMP". By using the INDEX clause, this section need no longer occur as this clause concisely captures the precise semantics needed for instance identification.)If the INDEX clause is not present, and the object type correspondsto a non-columnar object, then instances of the object are identified SNMP Working Group [Page 8]by appending a sub-identifier of zero to the name of that object.Further, note that if the MIB module does not contain a textualdescription of how instance identification information is derived for columnar objects, then the INDEX clause must be present.To define the instance identification information, determine whichobject value(s) will unambiguously distinguish a conceptual row. The syntax of those objects indicate how to form the instance-identifier: (1) integer-valued: a single sub-identifier taking theinteger value (this works only for non-negativeintegers);(2) string-valued, fixed-length strings: ‘n’ sub-identifiers, where ‘n’ is the length of the string (each octet of the string is encoded in a separate sub-identifier);(3) string-valued, variable-length strings: ‘n+1’ sub-identifiers, where ‘n’ is the length of the string (thefirst sub-identifier is ‘n’ itself, following this, each octet of the string is encoded in a separate sub-identifier);(4) object identifier-valued: ‘n+1’ sub-identifiers, where‘n’ is the number of sub-identifiers in the value (thefirst sub-identifier is ‘n’ itself, following this, each sub-identifier in the value is copied);(5) NetworkAddress-valued: ‘n+1’ sub-identifiers, where ‘n’depends on the kind of address being encoded (the firstsub-identifier indicates the kind of address, value 1indicates an IpAddress); or,(6) IpAddress-valued: 4 sub-identifiers, in the familiara.b.c.d notation.Note that if an "indextype" value is present (e.g., INTEGER ratherthan ifIndex), then a DESCRIPTION clause must be present; the textcontained therein indicates the semantics of the "indextype" value. SNMP Working Group [Page 9]By way of example, in the context of MIB-II [7], the following INDEX clauses might be present:objects under INDEX clause----------------- ------------ifEntry { ifIndex }atEntry { atNetIfIndex,atNetAddress }ipAddrEntry { ipAdEntAddr }ipRouteEntry { ipRouteDest }ipNetToMediaEntry { ipNetToMediaIfIndex,ipNetToMediaNetAddress }tcpConnEntry { tcpConnLocalAddress,tcpConnLocalPort,tcpConnRemoteAddress,tcpConnRemotePort }udpEntry { udpLocalAddress,udpLocalPort }egpNeighEntry { egpNeighAddr }4.1.7. Mapping of the DEFVAL clauseThe DEFVAL clause, which need not be present, defines an acceptabledefault value which may be used when an object instance is created at the discretion of the agent acting in conformance with the thirdparadigm described in Section 4.2 above.During conceptual row creation, if an instance of a columnar objectis not present as one of the operands in the correspondent SNMP setoperation, then the value of the DEFVAL clause, if present, indicates an acceptable default value that the agent might use.The value of the DEFVAL clause must, of course, correspond to theSYNTAX clause for the object. Note that if an operand to the SNMPset operation is an instance of a read-only object, then the errornoSuchName will be returned. As such, the DEFVAL clause can be used to provide an acceptable default value that the agent might use.It is possible that no acceptable default value may exist for any of the columnar objects in a conceptual row for which the creation ofnew object instances is allowed. In this case, the objects specified in the INDEX clause must have a corresponding ACCESS clause value of read-write.SNMP Working Group [Page 10]By way of example, consider the following possible DEFVAL clauses:ObjectSyntax DEFVAL clause----------------- ------------INTEGER 1 -- same for Counter, Gauge, TimeTicksOCTET STRING ’ffffffffffff’hDisplayString "any NVT ASCII string"OBJECT IDENTIFIER sysDescrOBJECT IDENTIFIER { system 2 }NULL NULLNetworkAddress { internet ’c0210415’h }IpAddress ’c0210415’h -- 192.33.4.214.1.8. Mapping of the OBJECT-TYPE valueThe value of an invocation of the OBJECT-TYPE macro is the name ofthe object, which is an object identifier.4.2. Usage ExampleConsider how the ipNetToMediaTable from MIB-II might be fullydescribed:-- the IP Address Translation tables-- The Address Translation tables contain IpAddress to-- "physical" address equivalences. Some interfaces do not-- use translation tables for determining address equivalences -- (e.g., DDN-X.25 has an algorithmic method); if all-- interfaces are of this type, then the Address Translation-- table is empty, i.e., has zero entries.ipNetToMediaTable OBJECT-TYPESYNTAX SEQUENCE OF IpNetToMediaEntryACCESS not-accessibleSTATUS mandatoryDESCRIPTION"The IP Address Translation table used for mapping from IP addresses to physical addresses."::= { ip 22 }ipNetToMediaEntry OBJECT-TYPESYNTAX IpNetToMediaEntryACCESS not-accessibleSTATUS mandatoryDESCRIPTION"Each entry contains one IpAddress to ’physical’SNMP Working Group [Page 11]address equivalence."INDEX { ipNetToMediaIfIndex,ipNetToMediaNetAddress }::= { ipNetToMediaTable 1 }IpNetToMediaEntry ::=SEQUENCE {ipNetToMediaIfIndexINTEGER,ipNetToMediaPhysAddressOCTET STRING,ipNetToMediaNetAddressIpAddress,ipNetoToMediaTypeINTEGER}ipNetToMediaIfIndex OBJECT-TYPESYNTAX INTEGERACCESS read-writeSTATUS mandatoryDESCRIPTION"The interface on which this entry’s equivalenceis effective. The interface identified by aparticular value of this index is the sameinterface as identified by the same value ofifIndex."::= { ipNetToMediaEntry 1 }ipNetToMediaPhysAddress OBJECT-TYPESYNTAX OCTET STRINGACCESS read-writeSTATUS mandatoryDESCRIPTION"The media-dependent ’physical’ address."::= { ipNetToMediaEntry 2 }ipNetToMediaNetAddress OBJECT-TYPESYNTAX IpAddressACCESS read-writeSTATUS mandatoryDESCRIPTION"The IpAddress corresponding to the media-dependent ’physical’ address."::= { ipNetToMediaEntry 3 }ipNetToMediaType OBJECT-TYPESYNTAX INTEGER {SNMP Working Group [Page 12]other(1), -- none of the followinginvalid(2), -- an invalidated mappingdynamic(3),static(4)}ACCESS read-writeSTATUS mandatoryDESCRIPTION"The type of mapping.Setting this object to the value invalid(2) hasthe effect of invalidating the corresponding entry in the ipNetToMediaTable. That is, it effectively disassociates the interface identified with saidentry from the mapping identified with said entry. It is an implementation-specific matter as towhether the agent removes an invalidated entryfrom the table. Accordingly, management stations must be prepared to receive tabular informationfrom agents that corresponds to entries notcurrently in use. Proper interpretation of suchentries requires examination of the relevantipNetToMediaType object."::= { ipNetToMediaEntry 4 }5. Appendix: DE-osifying MIBsThere has been an increasing amount of work recently on taking MIBsdefined by other organizations (e.g., the IEEE) and de-osifying them for use with the Internet-standard network management framework. The steps to achieve this are straight-forward, though tedious. Ofcourse, it is helpful to already be experienced in writing MIBmodules for use with the Internet-standard network managementframework.The first step is to construct a skeletal MIB module, e.g.,RFC1213-MIB DEFINITIONS ::= BEGINIMPORTSexperimental, OBJECT-TYPE, CounterFROM RFC1155-SMI;-- contact IANA for actual numberroot OBJECT IDENTIFIER ::= { experimental xx }ENDSNMP Working Group [Page 13]The next step is to categorize the objects into groups. Forexperimental MIBs, optional objects are permitted. However, when aMIB module is placed in the Internet-standard space, these optionalobjects are either removed, or placed in a optional group, which, if implemented, all objects in the group must be implemented. For thefirst pass, it is wisest to simply ignore any optional objects in the original MIB: experience shows it is better to define a core MIBmodule first, containing only essential objects; later, if experience demands, other objects can be added.It must be emphasized that groups are "units of conformance" within a MIB: everything in a group is "mandatory" and implementations doeither whole groups or none.5.1. Managed Object MappingNext for each managed object class, determine whether there can exist multiple instances of that managed object class. If not, then foreach of its attributes, use the OBJECT-TYPE macro to make anequivalent definition.Otherwise, if multiple instances of the managed object class canexist, then define a conceptual table having conceptual rows eachcontaining a columnar object for each of the managed object class’sattributes. If the managed object class is contained within thecontainment tree of another managed object class, then the assignment of an object type is normally required for each of the "distinguished attributes" of the containing managed object class. If they do notalready exist within the MIB module, then they can be added via thedefinition of additional columnar objects in the conceptual rowcorresponding to the contained managed object class.In defining a conceptual row, it is useful to consider theoptimization of network management operations which will act upon its columnar objects. In particular, it is wisest to avoid defining more columnar objects within a conceptual row, than can fit in a singlePDU. As a rule of thumb, a conceptual row should contain no morethan approximately 20 objects. Similarly, or as a way to abide bythe "20 object guideline", columnar objects should be grouped intotables according to the expected grouping of network managementoperations upon them. As such, the content of conceptual rows should reflect typical access scenarios, e.g., they should be organizedalong functional lines such as one row for statistics and another row for parameters, or along usage lines such as commonly-needed objects versus rarely-needed objects.On the other hand, the definition of conceptual rows where the number of columnar objects used as indexes outnumbers the number used to SNMP Working Group [Page 14]hold information, should also be avoided. In particular, thesplitting of a managed object class’s attributes into many conceptual tables should not be used as a way to obtain the same degree offlexibility/complexity as is often found in MIB’s with a myriad ofoptionals.5.1.1. Mapping to the SYNTAX clauseWhen mapping to the SYNTAX clause of the OBJECT-type macro:(1) An object with BOOLEAN syntax becomes an INTEGER takingeither of values true(1) or false(2).(2) An object with ENUMERATED syntax becomes an INTEGER,taking any of the values given.(3) An object with BIT STRING syntax containing no more than 32 bits becomes an INTEGER defined as a sum; otherwise if more than 32 bits are present, the object becomes anOCTET STRING, with the bits numbered from left-to-right, in which the least significant bits of the last octet may be "reserved for future use".(4) An object with a character string syntax becomes eitheran OCTET STRING or a DisplayString, depending on therepertoire of the character string.(5) An non-tabular object with a complex syntax, such as REAL or EXTERNAL, must be decomposed, usually into an OCTETSTRING (if sensible). As a rule, any object with acomplicated syntax should be avoided.(6) Tabular objects must be decomposed into rows of columnar objects.5.1.2. Mapping to the ACCESS clauseThis is straight-forward.5.1.3. Mapping to the STATUS clauseThis is usually straight-forward; however, some osified-MIBs use the term "recommended". In this case, a choice must be made between"mandatory" and "optional".5.1.4. Mapping to the DESCRIPTION clauseThis is straight-forward: simply copy the text, making sure that any SNMP Working Group [Page 15]。

rfc2578 SMIv2

rfc2578 SMIv2
6.4 Mapping of the OBJECT-IDENTITY value ......................20
6.5 Usage Example .............................................20
7 Mapping of the OBJECT-TYPE macro ............................20
2.6 Administrative Identifiers ................................11
3 Information Modules .........................................11
3.1 Macro Invocation ..........................................12
2.2 Object Names and Syntaxes ..................................5
2.3 The OBJECT-TYPE macro ......................................8
2.5 The NOTIFICATION-TYPE macro ...............................10
International Network Services
April 1999
Structure of Management Information Version 2 (SMIv2)
5.4 Mapping of the DESCRIPTION clause .........................18

sap rfc的类型

sap rfc的类型

sap rfc的类型
1.SynchronousRFC:同步RFC是指在调用RFC时,等待RFC函数执行完成并返回结果后,才能继续执行后续代码。

2. Asynchronous RFC:异步RFC是指在调用RFC时,不等待RFC 函数执行完成,而是立即返回,RFC函数的执行结果将在以后的时间点返回。

3. Transactional RFC:事务RFC是指一组RFC函数的执行过程中,如果其中任何一个RFC函数执行失败,那么整个事务将被回滚,所有RFC函数的执行结果都将被取消。

4. Queued RFC:队列RFC是指将RFC请求放入一个队列中等待执行,直到队列中的RFC请求被处理完毕后,才开始执行下一个RFC 请求。

5. Trusted RFC:信任RFC是指在SAP系统之间进行RFC通信时,通过信任配置,保证通信的安全性和可靠性。

- 1 -。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

Network Working Group B. Clouston, Editor Request for Comments: 2232 Cisco Systems Category: Standards Track B. Moore, Editor IBM Corporation November 1997 Definitions of Managed Objectsfor DLUR using SMIv2Status of this MemoThis document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions forimprovements. Please refer to the current edition of the "InternetOfficial Protocol Standards" (STD 1) for the standardization stateand status of this protocol. Distribution of this memo is unlimited. Copyright NoticeCopyright (C) The Internet Society (1997). All Rights Reserved.Table of Contents1. Status of this Memo (1)2. Introduction (1)3. The SNMP Network Management Framework (2)4. Overview (2)4.1 DLUR MIB structure (3)5. Definitions (5)6. Acknowledgments (18)7. References (19)8. Security Considerations (19)9. Authors’ Addresses (20)10. Full Copyright Statement (21)2. IntroductionThis memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for monitoring and controllingnetwork devices with DLUR (Dependent LU Requester) capabilities.This memo identifies managed objects for the DLUR protocol.Clouston & Moore Standards Track [Page 1]3. The SNMP Network Management FrameworkThe SNMP Network Management Framework consists of several components. For the purpose of this specification, the applicable components ofthe Framework are the SMI and related documents [1, 2, 3], whichdefine the mechanisms used for describing and naming objects for the purpose of management.The Framework permits new objects to be defined for the purpose ofexperimentation and evaluation.4. OverviewThis document identifies objects for monitoring the configuration and active characteristics of devices with DLUR capabilities. Dependent LU requester/server (DLUR/S) is an extension to the Advanced Peer-to-Peer Networking (APPN) architecture that provides dependent LUservices in APPN networks. See the SNANAU APPN MIB [4] formanagement of APPN networks.The base APPN architecture only provided for transport of databetween independent logical units (LUs). However, customers have an enormous investment in applications based on dependent LU types.DLUR/S provides for support of dependent LU sessions in an APPNnetwork.A dependent LU server (DLUS) is an APPN node that provides SystemServices Control Point (SSCP) services over an APPN network to remote secondary dependent LUs by using SSCP-PU (physical unit) and SSCP-LU sessions whose flows are encapsulated on LU 6.2 session flows between the DLUS node and the appropriate dependent LU requester (DLUR) node. The secondary dependent LUs may be local to the DLUR node, or inadjacent type 2.0 or 2.1 nodes.The LU 6.2 control sessions between a DLUS node and a DLUR node arereferred to as a CPSVRMGR pipe. CPSVRMGR refers to the mode used for the sessions.In this document, we describe DLUR managed objects.The DLUR terms and overall architecture are described in [5].Highlights of the management functions supported by the DLUR MIBmodule include the following:Clouston & Moore Standards Track [Page 2]o Identifying the node’s DLUR capabilitieso Displaying the physical units (PUs) this node is supportingo Identification of Dependent LU Serverso Displaying the state of control sessions to Dependent LUServers.This MIB module does not support:o Management of dependent LU serverso Configuration of DLUR nodes.o Changing the state of control session to the DLUSo Displaying the dependent LUs this node is supportingo Traps. The APPN MIB contains a trap for Alert conditions thatmay affect DLUR resources. The value for the affectedObjectobject contained in the alertTrap is determined by theimplementation. It may contain a VariablePointer from the DLUR MIB. The APPN/DLUR Alerts are defined in [6].4.1. DLUR MIB StructureAlthough DLUR is an extension to APPN, the DLUR MIB relies verylittle upon the APPN MIB. The dlurNodeCpName object in this MIB has the same value as the appnNodeCpName object in the APPN MIB. If the dlurPuLsName object in the MIB has the same value as the appnLsNameobject in the APPN MIB, then the two objects are referring to thesame link station.The DLUR MIB module contains the following collections of objects:o dlurNodeInfo--objects representing the capabilities andarchitecture options supported by the DLUR implementation, aswell as default primary and backup DLUSs.o dlurPuInfo--objects describing the PUs that this APPN node issupporting with DLUR.o dlurDlusInfo--objects describing the control sessions withDLUSs.These are described below in more detail.Clouston & Moore Standards Track [Page 3]4.1.1. dlurNodeInfo groupThe dlurNodeInfo group consists of the following objects and table:1) dlurNodeCapabilities groupThese objects represent the capabilities and options of the DLURimplementation, such as the release level of the implementation2) dlurDefaultDefBackupDlusTableThis table identifies the list of defined backup DLUSs for all PUsserved by this DLUR, if there is no specific DLUS backup list for the PU. The list is in descending order of preference as a backup DLUS.4.1.2. dlurPuInfo groupThe dlurPuInfo group consists of the following tables:1) dlurPuTableThis table has an entry for each PU this node is supporting via DLUR, including the locally known name, the SSCP supplied name (if known), and the PU status.2) dlurPuDefBackupDlusTableThis table contains the backup DLUS list defined on a PU basis. The table has an entry for each specifically defined backup DLUS on each PU. The first index to the entry is the PU name, which organizes the table by PU name. The second index is a ranking which further sortsthe table in descending order of preference as a backup DLUS for the PU.If a PU name is not found in this table, thedlurDefaultDefBackupDlusNameTable is used as a backup list for thatPU.4.1.3. dlurDlusInfo groupThis group consists of the following table:1) dlurDlusTableThis table contains information about the control sessions (CPSVRMGR pipes) with the DLUS, including the control point (CP) name of theDLUS and the status of the control session.Clouston & Moore Standards Track [Page 4]5. DefinitionsAPPN-DLUR-MIB DEFINITIONS ::= BEGINIMPORTSDisplayString, TruthValueFROM SNMPv2-TCOBJECT-TYPE, MODULE-IDENTITY, Unsigned32FROM SNMPv2-SMIMODULE-COMPLIANCE, OBJECT-GROUPFROM SNMPv2-CONFsnanauMIBFROM SNA-NAU-MIBSnaControlPointNameFROM APPN-MIB;dlurMIB MODULE-IDENTITYLAST-UPDATED "9705101500Z"ORGANIZATION "IETF SNA NAU MIB WG / AIW APPN/HPR MIBs SIG"CONTACT-INFO"Bob CloustonCisco Systems7025 Kit Creek RoadP.O. Box 14987Research Triangle Park, NC 27709, USATel: 1 919 472 2333E-mail: clouston@Bob MooreIBM Corporation800 Park Offices DriveRHJA/664P.O. Box 12195Research Triangle Park, NC 27709, USATel: 1 919 254 4436E-mail: remoore@"DESCRIPTION"This is the MIB module for objects used to managenetwork devices with DLUR capabilities. This MIBcontains information that is useful for managing an APPN product that implements a DLUR (Dependent Logical Unit Clouston & Moore Standards Track [Page 5]Requester). The DLUR product has a client/serverrelationship with an APPN product that implements a DLUS (Dependent Logical Unit Server)."::= { snanauMIB 5 }-- snanauMIB ::= { mib-2 34 }-- ********************************************************************* -- Textual Convention-- ********************************************************************* -- SnaControlPointName is imported from the APPN MIB-- ********************************************************************* dlurObjects OBJECT IDENTIFIER ::= { dlurMIB 1 }-- ********************************************************************* dlurNodeInfo OBJECT IDENTIFIER ::= { dlurObjects 1 }-- ********************************************************************* -- DLUR Capabilities of the node---- This group represents the capabilities and options of the DLUR-- implementation.-- ********************************************************************* dlurNodeCapabilities OBJECT IDENTIFIER ::= { dlurNodeInfo 1 } dlurNodeCpName OBJECT-TYPESYNTAX SnaControlPointNameMAX-ACCESS read-onlySTATUS currentDESCRIPTION"Administratively assigned network name for the APPN node where this DLUR implementation resides. If this object has the same value as the appnNodeCpName object in the APPN MIB, then thetwo objects are referring to the same APPN node."::= { dlurNodeCapabilities 1 }dlurReleaseLevel OBJECT-TYPESYNTAX DisplayString (SIZE (2))MAX-ACCESS read-onlySTATUS currentDESCRIPTION"The DLUR release level of this implementation. This is thevalue that is encoded in the DLUR/DLUS Capabilites (CV 51).To insure consistent display, this one-byte value is encodedhere as two displayable characters that are equivalent to ahexadecimal display. For example, if the one-byte value as Clouston & Moore Standards Track [Page 6]encoded in CV51 is X’01’, this object will contain thedisplayable string ’01’."::= { dlurNodeCapabilities 2 }dlurAnsSupport OBJECT-TYPESYNTAX INTEGER {continueOrStop(1),stopOnly(2)}MAX-ACCESS read-onlySTATUS currentDESCRIPTION"Automatic Network Shutdown (ANS) capability of this node.- ’continueOrStop’ indicates that the DLUR implementation supports either ANS value (continue or stop) asspecified by the DLUS on ACTPU for each PU.- ’stopOnly’ indicates that the DLUR implementation only supports the ANS value of stop.ANS = continue means that the DLUR node will keep LU-LUsessions active even if SSCP-PU and SSCP-LU control sessions are interrupted.ANS = stop means that LU-LU sessions will be interrupted when the SSCP-PU and SSCP-LU sessions are interrupted."::= { dlurNodeCapabilities 3 }dlurMultiSubnetSupport OBJECT-TYPESYNTAX TruthValueMAX-ACCESS read-onlySTATUS currentDESCRIPTION"Indication of whether this DLUR implementation can supportCPSVRMGR sessions that cross NetId boundaries."::= { dlurNodeCapabilities 4 }dlurDefaultDefPrimDlusName OBJECT-TYPESYNTAX SnaControlPointNameMAX-ACCESS read-onlySTATUS currentDESCRIPTION"The SNA name of the defined default primary DLUS for all ofthe PUs served by this DLUR. This can be overridden for a Clouston & Moore Standards Track [Page 7]particular PU by a defined primary DLUS for that PU,represented by the dlurPuDefPrimDlusName object."::= { dlurNodeCapabilities 5 }dlurNetworkNameForwardingSupport OBJECT-TYPESYNTAX TruthValueMAX-ACCESS read-onlySTATUS currentDESCRIPTION"Indication of whether this DLUR implementation supportsforwarding of Network Name control vectors on ACTPUs andACTLUs to DLUR-served PUs and their associated LUs.This object corresponds to byte 9. bit 3 of cv51."::= { dlurNodeCapabilities 6 }dlurNondisDlusDlurSessDeactSup OBJECT-TYPESYNTAX TruthValueMAX-ACCESS read-onlySTATUS currentDESCRIPTION"Indication of whether this DLUR implementation supportsnondisruptive deactivation of its DLUR-DLUS sessions.Upon receiving from a DLUS an UNBIND for the CPSVRMGR pipewith sense data X’08A0 000B’, a DLUR that supports thisoption immediately begins attempting to activate a CPSVRMGRpipe with a DLUS other than the one that sent the UNBIND.This object corresponds to byte 9. bit 4 of cv51."::= { dlurNodeCapabilities 7 }-- ********************************************************************* -- DLUR default defined backup DLUS table-- ********************************************************************* dlurDefaultDefBackupDlusTable OBJECT-TYPESYNTAX SEQUENCE OF DlurDefaultDefBackupDlusEntryMAX-ACCESS not-accessibleSTATUS currentDESCRIPTION"This table contains an ordered list of defined backup DLUSsfor all of the PUs served by this DLUR. These can beoverridden for a particular PU by a list of defined backupDLUSs for that PU, represented by thedlurPuDefBackupDlusNameTable. Entries in this table are Clouston & Moore Standards Track [Page 8]ordered from most preferred default backup DLUS to leastpreferred."::= { dlurNodeInfo 2 }dlurDefaultDefBackupDlusEntry OBJECT-TYPESYNTAX DlurDefaultDefBackupDlusEntryMAX-ACCESS not-accessibleSTATUS currentDESCRIPTION"This table is indexed by an integer-valued index, whichorders the entries from most preferred default backup DLUSto least preferred."INDEX { dlurDefaultDefBackupDlusIndex }::= { dlurDefaultDefBackupDlusTable 1 }DlurDefaultDefBackupDlusEntry ::= SEQUENCE {dlurDefaultDefBackupDlusIndex Unsigned32,dlurDefaultDefBackupDlusName SnaControlPointName}dlurDefaultDefBackupDlusIndex OBJECT-TYPESYNTAX Unsigned32 (1..4294967295)MAX-ACCESS not-accessibleSTATUS currentDESCRIPTION"Index for this table. The index values start at 1,which identifies the most preferred default backup DLUS."::= { dlurDefaultDefBackupDlusEntry 1 } dlurDefaultDefBackupDlusName OBJECT-TYPESYNTAX SnaControlPointNameMAX-ACCESS read-onlySTATUS currentDESCRIPTION"Fully qualified name of a default backup DLUS for PUs served by this DLUR."::= { dlurDefaultDefBackupDlusEntry 2 }-- ********************************************************************* -- PU Information---- The following table carries information about the PUs that this APPN -- node is supporting via DLUR.Clouston & Moore Standards Track [Page 9]-- ********************************************************************* dlurPuInfo OBJECT IDENTIFIER ::= { dlurObjects 2 }dlurPuTable OBJECT-TYPESYNTAX SEQUENCE OF DlurPuEntryMAX-ACCESS not-accessibleSTATUS currentDESCRIPTION"Information about the PUs supported by this DLUR."::= { dlurPuInfo 1 }dlurPuEntry OBJECT-TYPESYNTAX DlurPuEntryMAX-ACCESS not-accessibleSTATUS currentDESCRIPTION"Entry in a table of PU information, indexed by PU name."INDEX { dlurPuName }::= { dlurPuTable 1 }DlurPuEntry ::= SEQUENCE {dlurPuName DisplayString,dlurPuSscpSuppliedName DisplayString,dlurPuStatus INTEGER,dlurPuAnsSupport INTEGER,dlurPuLocation INTEGER,dlurPuLsName DisplayString,dlurPuDlusSessnStatus INTEGER,dlurPuActiveDlusName DisplayString,dlurPuDefPrimDlusName DisplayString}dlurPuName OBJECT-TYPESYNTAX DisplayString (SIZE (1..17))MAX-ACCESS not-accessibleSTATUS currentDESCRIPTION"Locally administered name of the PU."::= { dlurPuEntry 1 }dlurPuSscpSuppliedName OBJECT-TYPESYNTAX DisplayString (SIZE (0..17))MAX-ACCESS read-onlyClouston & Moore Standards Track [Page 10]STATUS currentDESCRIPTION"The SNA name of the PU. This value is supplied to a PU by the SSCP that activated it. If a value has not been supplied, azero-length string is returned."::= { dlurPuEntry 2 }dlurPuStatus OBJECT-TYPESYNTAX INTEGER {reset(1),pendReqActpuRsp(2),pendActpu(3),pendActpuRsp(4),active(5),pendLinkact(6),pendDactpuRsp(7),pendInop(8),pendInopActpu(9)}MAX-ACCESS read-onlySTATUS currentDESCRIPTION"Status of the DLUR-supported PU. The following values aredefined:reset(1) - resetpendReqActpuRsp(2) - pending a response from the DLUSto a Request ACTPUpendActpu(3) - pending an ACTPU from the DLUSpendActpuRsp(4) - pending an ACTPU response from the PU active(5) - activependLinkact(6) - pending activation of the link to adownstream PUpendDactpuRsp(7) - pending a DACTPU response from the PU pendInop(8) - the CPSVRMGR pipe became inoperativewhile the DLUR was pending an ACTPUresponse from the PUpendInopActpu(9) - when the DLUR was in the pendInopstate, a CPSVRMGR pipe became activeand a new ACTPU was received over it, before a response to the previousACTPU was received from the PU."::= { dlurPuEntry 3 }dlurPuAnsSupport OBJECT-TYPESYNTAX INTEGER {Clouston & Moore Standards Track [Page 11]stop(2)}MAX-ACCESS read-onlySTATUS currentDESCRIPTION"The Automatic Network Shutdown (ANS) support configured forthis PU. This value (as configured by the networkadministrator) is sent by DLUS with ACTPU for each PU.- ’continue’ means that the DLUR node will attempt to keep LU-LU sessions active even if SSCP-PU and SSCP-LUcontrol sessions are interrupted.- ’stop’ means that LU-LU sessions will be interruptedwhen the SSCP-PU and SSCP-LU sessions are interrupted." ::= { dlurPuEntry 4 }dlurPuLocation OBJECT-TYPESYNTAX INTEGER {internal(1),downstream(2) }MAX-ACCESS read-onlySTATUS currentDESCRIPTION"Location of the DLUR-support PU:internal(1) - internal to the APPN node itself (no link) downstream(2) - downstream of the APPN node (connected via a link)."::= { dlurPuEntry 5 }dlurPuLsName OBJECT-TYPESYNTAX DisplayString (SIZE (0..10))MAX-ACCESS read-onlySTATUS currentDESCRIPTION"Administratively assigned name of the link station throughwhich a downstream PU is connected to this DLUR. A zero-length string is returned for internal PUs. If this object has thesame value as the appnLsName object in the APPN MIB, then thetwo are identifying the same link station."::= { dlurPuEntry 6 }dlurPuDlusSessnStatus OBJECT-TYPESYNTAX INTEGER {Clouston & Moore Standards Track [Page 12]pendingActive(2),active(3),pendingInactive(4)}MAX-ACCESS read-onlySTATUS currentDESCRIPTION"Status of the control session to the DLUS identified indlurPuActiveDlusName. This is a combination of the separatestates for the contention-winner and contention-loser sessions: reset(1) - none of the cases belowpendingActive(2) - either contention-winner session orcontention-loser session is pending active active(3) - contention-winner and contention-losersessions are both activependingInactive(4) - either contention-winner session orcontention-loser session is pendinginactive - this test is made AFTER the’pendingActive’ test.The following matrix provides a different representation ofhow the values of this object are related to the individualstates of the contention-winner and contention-loser sessions: Conwinner| pA | pI | A | X = !(pA | pI | A)C ++++++++++++++++++++++++++++++++++o pA | 2 | 2 | 2 | 2n ++++++++++++++++++++++++++++++++++l pI | 2 | 4 | 4 | 4o ++++++++++++++++++++++++++++++++++s A | 2 | 4 | 3 | 1e ++++++++++++++++++++++++++++++++++r X | 2 | 4 | 1 | 1++++++++++++++++++++++++++++++++++"::= { dlurPuEntry 7 }dlurPuActiveDlusName OBJECT-TYPESYNTAX DisplayString (SIZE (0..17))MAX-ACCESS read-onlySTATUS currentDESCRIPTION"The SNA name of the active DLUS for this PU. If its lengthis not zero, this name follows the SnaControlPointName textual Clouston & Moore Standards Track [Page 13]convention. A zero-length string indicates that the PU doesnot currently have an active DLUS."::= { dlurPuEntry 8 }dlurPuDefPrimDlusName OBJECT-TYPESYNTAX DisplayString (SIZE (0..17))MAX-ACCESS read-onlySTATUS currentDESCRIPTION"The SNA name of the defined primary DLUS for this PU, if onehas been defined. If present, this name follows theSnaControlPointName textual convention. A zero-length stringindicates that no primary DLUS has been defined for this PU, in which case the global default represented by thedlurDefaultDefPrimDlusName object is used."::= { dlurPuEntry 9 }-- *****************************************-- Defined backup DLUS table for a PU-- *****************************************dlurPuDefBackupDlusTable OBJECT-TYPESYNTAX SEQUENCE OF DlurPuDefBackupDlusEntryMAX-ACCESS not-accessibleSTATUS currentDESCRIPTION"This table contains an ordered list of defined backup DLUSsfor those PUs served by this DLUR that have their own definedbackup DLUSs. PUs that have no entries in this table use theglobal default backup DLUSs for the DLUR, represented by thedlurDefaultDefBackupDlusNameTable. Entries in this table areordered from most preferred backup DLUS to least preferred for each PU."::= { dlurPuInfo 2 }dlurPuDefBackupDlusEntry OBJECT-TYPESYNTAX DlurPuDefBackupDlusEntryMAX-ACCESS not-accessibleSTATUS currentDESCRIPTION"This table is indexed by PU name and by an integer-valuedindex, which orders the entries from most preferred backup DLUS for the PU to least preferred."INDEX { dlurPuDefBackupDlusPuName,Clouston & Moore Standards Track [Page 14]dlurPuDefBackupDlusIndex }::= { dlurPuDefBackupDlusTable 1 }DlurPuDefBackupDlusEntry ::= SEQUENCE {dlurPuDefBackupDlusPuName DisplayString,dlurPuDefBackupDlusIndex Unsigned32,dlurPuDefBackupDlusName SnaControlPointName}dlurPuDefBackupDlusPuName OBJECT-TYPESYNTAX DisplayString (SIZE (1..17))MAX-ACCESS not-accessibleSTATUS currentDESCRIPTION"Locally administered name of the PU. If this object has thesame value as the dlurPuName object, then the two areidentifying the same PU."::= { dlurPuDefBackupDlusEntry 1 }dlurPuDefBackupDlusIndex OBJECT-TYPESYNTAX Unsigned32 (1..4294967295)MAX-ACCESS not-accessibleSTATUS currentDESCRIPTION"Secondary index for this table. The index values start at 1, which identifies the most preferred backup DLUS for the PU."::= { dlurPuDefBackupDlusEntry 2 }dlurPuDefBackupDlusName OBJECT-TYPESYNTAX SnaControlPointNameMAX-ACCESS read-onlySTATUS currentDESCRIPTION"Fully qualified name of a backup DLUS for this PU."::= { dlurPuDefBackupDlusEntry 3 }-- ********************************************************************* -- DLUS Control Sessions (CPSVRMGR Pipes)---- This table contains information about DLUS control sessions, also-- known as CPSVRMGR pipes. Although DLUR uses a pair of CPSVRMGR-- sessions for communication, for the purpose of status, information-- about these two sessions is combined to yield a single status for the -- requester/server connection.Clouston & Moore Standards Track [Page 15]-- ********************************************************************* dlurDlusInfo OBJECT IDENTIFIER ::= { dlurObjects 3 }dlurDlusTable OBJECT-TYPESYNTAX SEQUENCE OF DlurDlusEntryMAX-ACCESS not-accessibleSTATUS currentDESCRIPTION"Information about DLUS control sessions."::= { dlurDlusInfo 1}dlurDlusEntry OBJECT-TYPESYNTAX DlurDlusEntryMAX-ACCESS not-accessibleSTATUS currentDESCRIPTION"This entry is indexed by the name of the DLUS."INDEX { dlurDlusName }::= { dlurDlusTable 1 }DlurDlusEntry ::= SEQUENCE {dlurDlusName SnaControlPointName,dlurDlusSessnStatus INTEGER}dlurDlusName OBJECT-TYPESYNTAX SnaControlPointNameMAX-ACCESS not-accessibleSTATUS currentDESCRIPTION"The SNA name of a DLUS with which this DLUR currently has aCPSVRMGR pipe established."::= { dlurDlusEntry 1 }dlurDlusSessnStatus OBJECT-TYPESYNTAX INTEGER {reset(1),pendingActive(2),active(3),pendingInactive(4)}MAX-ACCESS read-onlySTATUS currentClouston & Moore Standards Track [Page 16]DESCRIPTION"Status of the CPSVRMGR pipe between the DLUR and this DLUS.This is a combination of the separate states for thecontention-winner and contention-loser sessions:reset(1) - none of the cases belowpendingActive(2) - either contention-winner session orcontention-loser session is pending active active(3) - contention-winner and contention-losersessions are both activependingInactive(4) - either contention-winner session orcontention-loser session is pendinginactive - this test is made AFTER the’pendingActive’ test.The following matrix provides a different representation ofhow the values of this object are related to the individualstates of the contention-winner and contention-loser sessions: Conwinner| pA | pI | A | X = !(pA | pI | A)C ++++++++++++++++++++++++++++++++++o pA | 2 | 2 | 2 | 2n ++++++++++++++++++++++++++++++++++l pI | 2 | 4 | 4 | 4o ++++++++++++++++++++++++++++++++++s A | 2 | 4 | 3 | 1e ++++++++++++++++++++++++++++++++++r X | 2 | 4 | 1 | 1++++++++++++++++++++++++++++++++++"::= { dlurDlusEntry 2 }-- ***************************************************************-- Conformance information-- *************************************************************** dlurConformance OBJECT IDENTIFIER ::= { dlurMIB 2 }dlurCompliances OBJECT IDENTIFIER ::= { dlurConformance 1 } dlurGroups OBJECT IDENTIFIER ::= { dlurConformance 2 }-- Compliance statementsdlurCompliance MODULE-COMPLIANCESTATUS currentDESCRIPTIONClouston & Moore Standards Track [Page 17]"The compliance statement for the SNMPv2 entities whichimplement the DLUR MIB."MODULE -- this module-- Unconditionally mandatory groupsMANDATORY-GROUPS { dlurConfGroup }::= { dlurCompliances 1 }-- Units of conformancedlurConfGroup OBJECT-GROUPOBJECTS {dlurNodeCpName,dlurReleaseLevel,dlurAnsSupport,dlurMultiSubnetSupport,dlurNetworkNameForwardingSupport,dlurNondisDlusDlurSessDeactSup,dlurDefaultDefPrimDlusName,dlurDefaultDefBackupDlusName,dlurPuSscpSuppliedName,dlurPuStatus,dlurPuAnsSupport,dlurPuLocation,dlurPuLsName,dlurPuDlusSessnStatus,dlurPuActiveDlusName,dlurPuDefPrimDlusName,dlurPuDefBackupDlusName,dlurDlusSessnStatus}STATUS currentDESCRIPTION"A collection of objects providing information on animplementation of APPN DLUR."::= { dlurGroups 1 }-- end of conformance statementEND6. AcknowledgmentsThis MIB module is the product of the IETF SNA NAU MIB WG and the AIW APPN/HPR MIBs SIG.Clouston & Moore Standards Track [Page 18]7. References[1] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,"Structure of Management Information for version 2 ofthe Simple Network Management Protocol (SNMPv2)", RFC 1902,January 1996.[2] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,"Textual Conventions for Version 2 of the SimpleNetwork Management Protocol (SNMPv2)", RFC 1903, January 1996.[3] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,"Conformance Statements for Version 2 of the SimpleNetwork Management Protocol (SNMPv2)", RFC 1904, January 1996.[4] Clouston, B., and B. Moore, "Definition of Managed Objects forAPPN", RFC 2155, June 1997.[5] IBM, Systems Network Architecture Advanced Peer-to-PeerNetworking Dependent LU Requester Architecture Reference,Version 1.2, SV40-1010-01, December 1995.[6] IBM, SNA/MS Formats, GC31-8302-00.8. Security ConsiderationsIn most cases, MIBs are not themselves security risks; if SNMPsecurity is operating as intended, the use of a MIB to viewinformation about a system, or to change some parameter at thesystem, is a tool, not a threat.None of the read-only objects in the DLUR MIB reports a password,user data, or anything else that is particularly sensitive. Someenterprises view their network configuration itself, as well asinformation about network usage and performance, as corporate assets; such enterprises may wish to restrict SNMP access to most of theobjects in the MIB.There are no read-write objects in the DLUR MIB.Clouston & Moore Standards Track [Page 19]。

相关文档
最新文档