随着网络技术的发展，网络数量越来越多，网络中的设备来自不同厂家，如何管理这些设备变得十分重要。
基于TCP/IP的网络管理包含两个部分：网络管理站（也叫管理进程，manager）和被管理的网络单元（也叫被管设备，包括路由器、X终端、终端服务器、打印机等运行TCP/IP协议的设备）。
被管理设备端中与管理相关的软件叫做代理程序或代理进程。管理站一般是带有彩色监视器的工作站，可以显示所有被管理设备的状态（如是否掉线、各种连接上的流量状况等）。
管理进程和代理进程间通信方式有两种：一是管理进程向代理进程发出请求，询问一个具体的参数值或要求改变代理进程的某参数值；二是代理进程主动向管理进程报告有某些重要的事件发生。
基于TCP/IP的网络管理包含三个部分：
1.一个管理信息库（MIB，Management Information Base），其中包含所有代理进程的所有可被查询和修改的参数。RFC 1213定义了第二版的MIB，叫做MIB-Ⅱ。
2.关于MIB的一套公用的结构和表示符号，称其为管理信息结构（SMI，Structure of Management Information）。如SMI定义计数器是一个非负整数，范围是0~4294967295，当达到最大值时，又从0开始计数。
3.管理进程和代理进程之间的通信协议，叫做简单网络管理协议（SNMP，Simple Network Management Protocol）。尽管运输层可以使用很多协议，但用得最多的还是UDP，所以可能发生数据报丢失的情况，需要超时和重传机制。
SNMP定义了5种报文：
1.get-request操作：从代理进程处提取一个或多个参数值。
2.get-next-request操作：从代理进程处提取一个或多个参数的下一个参数值。
3.set-request操作：设置代理进程的一个或多个参数值。
4.get-response操作：返回一个或多个参数值，由代理进程发出，是前三个操作的响应操作。
5.trap操作：代理进程主动发出，通知管理进程某些事件的发生。
代理进程和管理进程的熟知端口号不同，因此一个系统可以同时为管理进程和代理进程。
上图中只标注了UDP和IP首部长度，这是由于SNMP报文编码采用了ASN.1和BER，使得SNMP的长度取决于变量的类型和值。
版本字段为0，该字段的值是通过SNMP版本号减去1得到的，0代表SNMP v1。
共同体字段是一个字符串，是管理进程和代理进程之间的口令，是明文格式，默认值为public。
PDU（协议数据单元，Protocol Data Unit）类型字段取值：
对于get-request、get-next-request、set-request操作，请求标识字段由管理进程设置，然后由代理进程在get-response中返回，用于管理进程将查询和响应进行匹配。类似的字段在其他UDP应用中也有，（如DNS的标识字段）。这个字段允许管理进程对一个或多个代理进程发出多个请求，并从返回的众多应答中进行分类。
差错状态字段由代理进程标注，指明有差错发生，它的取值如下：
差错索引字段是一个整数偏移量，代理进程用它指明差错发生在哪个参数，只有在发生noSuchName、readOnly、badValue差错时才进行标注。
在get-request、get-next-request、set-request的请求数据报中，包含变量名称和变量值的一张表，对于get-request和get-next-request操作，变量值部分不需填写。
SNMP中的数据类型：
1.INTEGER：一个变量虽然定义为整型，但也有多种形式，有些整型变量没有范围限制，有些整型变量定义为特定的数值（如IP的转发标志就只有允许转发的1和不允许转发的2两种），有些整型变量定义为一个特定的范围（如UDP和TCP的端口号从0~65535）。
2.OCTER STRING：0或多个8bit字节，每个字节值在0~255之间。不以NULL结尾。BER编码的这种数据类型和DisplayString数据类型中，字符串的字节数被放置在字符串之前。
3.DisplayString：0或多个8bit字节，每个字节必须是ASCII码。MIB-Ⅱ中，该类型的变量的长度不能超过255个字符。
4.OBJECT IDENTIFIER。
5.NULL：表示相关变量没有值，如在get-request或get-next-request数据报中，要获取的变量的值会填为NULL。
6.IpAddress：4字节长度的OCTER STRING，以网络序表示的IP地址，每个字节代表IP地址的一个字段。
7.PhyAddress：OCTER STRING类型，代表物理地址（如以太网物理地址为6字节长度）。
8.Counter：非负整数，可从0递增到232-1（4294976295），达到最大值后归零。
9.Gauge：非负整数，取值范围为0~4294976295，可增可减，达到最大值后变量被锁定，直到被复位。如MIB中的tcpCurrEstab变量就是这种类型，它表示目前在ESTABLISHED或CLOSE_WAIT状态的TCP连接数。
10.TimeTicks：时间计数器，以0.01秒为单位递增，不同变量可以有不同的递增幅度，所以在定义这种变量的时候要指定递增幅度。如MIB中的sysUpTime变量就是这种类型，它表示代理进程从启动开始到现在的时间长度，以多少个0.01秒的数目来表示。
11.SEQUENCE：与C语言中的struct类似，一个SEQUENCE中包含0个或多个元素。如MIB中的UdpEntry变量就是这种类型，它表示代理进程目前在使用的UDP数量，此变量中包含两个元素：一是IpAddress类型变量udpLocalAddress，表示IP地址；二是INTEGER类型的变量udpLocalPort，范围是0~65535，表示端口号。
12.SEQUENCE OF：这是向量的定义。类似SEQUENCE，但其中所有元素的类型是相同的。如果元素类型是类似整数类型的简单数据类型，那么它就是一个一维向量；如果其中的元素类型是SEQUENCE，可将它看作一个二维数组或表。
对象标识是一种数据类型，它表示一种授权的命名对象，授权的含义为这些标识不是随便分配的，而是由权威机构进行管理和分配的。
对象标识是一个整数序列，以点·分隔，这些整数构成一个树型结构。对象标识从树的顶部开始，顶部没有标识，以root表示：
如上图，树上的每个结点同时还有一个文字名，如表示1.3.6.1.2.1就对应于iso.org.dod.internet.memt.mib，文字名的目的是为了让人们阅读更方便。实际应用中，管理进程和代理进程进行数据报交互时，其中的MIB变量名都是数字形式的对象标识，这些变量名都以1.3.6.1.2.1开始。
上图中的标识1.3.6.1.4.1是为厂家自定义而预留的，在Assigned Number RFC中列出了此结点下大约400个标识。
信息管理库MIB就是所有代理进程包含的，能够被管理进程进行查询和设置的信息的集合。
如上图所示，MIB被划分为若干组，如system、interfaces、at（地址转换）、ip组等。
我们仅讨论UDP组中的变量，这个组比较简单，它包含几个变量和一个表格。
以下是udp组的结构：
udp组中包含4个简单变量和由2个简单变量组成的表格，以下是对这4个简单变量的描述：
上图中，R/W列为空，表示该变量是只读的，如果该变量可读可写，则用·表示。数据类型列中，如果数据类型是INTEGER且有范围限制，则该列会填其上下限。这两点在后面的图中也是这样。
以下是udp组中，2个简单变量组成的表格的描述：
以下三个计数器是有相互关系的：
上图表明udpInDatagram不包括udpInError和udpNoPorts且分组的所有数据路径都被计数。
当查询和设置变量的值时，必须对MIB的变量进行标识，只有叶子结点是可操作的，且SNMP没法处理表格的一整行或一整列。
简单变量的标识直接在其对象标识后面添加.0即可，如计数器udpInDatagrams，它的对象标识是1.3.6.1.2.1.7.1，它的实例标识为1.3.6.1.2.1.7.1.0，其对应的文字名称为iso.org.dod.internet.mgmt.mid.udp.udpInDatagrams.0，该变量通常缩写为udpInDatagrams.0。在SNMP报文中，该变量的名称为1.3.6.1.2.1.7.1.0。
表格的实例标识要更复杂，每个MIB中的表格都有一个或以上的索引，对于图25-9中的表格，MIB定义了包含两个变量的联合索引，这两个变量分别为udpLocalAddress（它是一个IP地址）和udpLocalPort（它是一个整数）。假设该表格有3行，如下图：
对以上表格中的6个变量进行MBI字典式排序，这个排序是按对象标识的字典顺序进行的，以上表格中的6个变量为：
将上图中的6个变量经过字典排序后的结果如下：
这种字典排序有两个结果：
1.一个给定变量（这里指udpLocalAddress）的所有实例都在下个变量（这里指udpLocalPort）的所有实例之前显示，这暗示表格操作的顺序是先列后行。这是由于对对象标识进行字典式排序所得到的，而不是按照人们的阅读习惯而排列的。
2.表格中对行的排序与表格中的值有关。如上图，67的字典序小于161，而161的字典序小于250。
从代理进程处进行查询的程序属于ISODE（ISO开发环境，ISO Development Environment）系统，这个程序叫做snmpi。
从一个路由器处取两个udp组的简单变量值：
snmpi程序的-a选项表示要通信的代理进程名，-c选项表示SNMP的共同体名（即由客户进程snmpi提供，同时能被服务器进程（即代理进程gateway）所识别的一个口令，共同体名称是管理进程请求的权限标志）。代理进程允许管理进程用一个共同体名对变量进行只读操作，用另一个共同体名对变量进行读写操作。
上图中的get命令会使用get-request报文段。
以上过程的tcpdump输出：
对这两个变量的查询请求是封装在一个UDP数据报中的，响应也在一个UDP数据报中。tcpdump显示的变量是以其对象标识的形式显示的，这是在SNMP报文中实际传输的内容。我们必须指定这两个变量的实例是0。
get-next操作是基于MIB的字典式排序的，下面的例子中，首先向代理进程询问udp节点后的下一个对象标识（udp节点不是一个叶子对象，即我们没有指定任何实例），代理进程将返回UDP组中的第1个对象，然后我们继续向代理进程取该对象的下一个对象标识，此时第2个对象将被返回：
该方式可从MIB树的顶点开始，对代理进程一步步地进行查询，就可得到代理进程处所有的变量值和标识。get-next请求的另一个用处就是对表格进行遍历。
遍历udpTable，由于udpTable不是叶子对象，我们不能指定一个实例，但我们可以使用next命令返回表格中的对象，然后以返回的结果为基础进行下一步操作，返回顺序是先列后行，如遍历图25-13中的表：
如上图，当返回的变量名是表格之外的变量时，就获取完了表格中的内容。
MIB中的system（系统标识）组只包含以下7个简单变量：
我们可以对netb路由器做system组的变量值的查询：
如上图查询，netb路由器的system组中的对象标识符sysObjectID在iso.org.dod.internet.private.enterprises（1.3.6.1.4.1）组中，在Assigned Numbers RFC中可知，下一个对象标识符12指派给了厂家Epilogue。此外，根据sysService变量为4和8，则说明它支持网络层（如选路）和运输层的应用。
MIB中的interface（接口）组中定义了一个简单变量：
此外interface组中还有一个表格变量，其中有22列，表格中每行定义了接口的一些特征参数：
如向主机sun查询3个接口的一些变量：
上图中，对于SLIP链路的接口类型，报告的是点对点的专用串行链路，而非SLIP链路，且速率没有报告。
上例中，get-next操作返回的是表格中下一行所对应的变量，而不是同一行中的下一个变量，这就是先列后行。
MIB的at（地址转换）组对所有系统都是必需的，但在MIB-Ⅱ中已经没有这个组，从MIB-Ⅱ开始，每个网络协议组（如IP组）都包含它们自己的网络地址转换表，如IP组的网络地址转换表是ipNetToMediaTable。
at组中只有一个由3列组成的表格变量，下图中atIfIndex列的含义应该是接口的索引，而非接口数：
可用snmpi程序中的命令dump来获取整个表格，下图向名叫kinetics的路由器查询其整个ARP高速缓存，其输出是字典式排序后的整个表格内容：
路由器kinetics的ARP高速缓存内容如下：
snmpi的dump命令是通过get-next操作获取整张表。
路由器kinetics的路由表中，接口2的物理地址是32bit的，这是由于接口2连接的是一个AppleTalk网络。
MIB的ip组中的简单变量：
ip组中的一个表格变量是IP地址表ipAddrTable，系统中每个IP地址对应表格中的一行，每行有5个变量，表中ipAdEntIfIndex列表示的含义应该是接口的索引，而非接口数：
IP路由表ipRouteTable也是ip组中的表格变量，该表中每行记录的索引是目的IP地址，下表中的ipRouteIfIndex列的含义应该是接口索引，而非接口数：
ip组中最后一张表是ipNetToMediaTable，该表用于替换at组中的地址转换表：
MIB的icmp组包括以下变量：
MIB的tcp组包含以下简单变量，其中变量tcpRetransSegs的数据类型是Counter：
tcp组中还包括一个表格变量TCP连接表tcpConnTable，对于每一个TCP连接，都对应表格中的一条记录：
观察sun系统上的tcpConnTable表，由于有很多服务器进程在监听，因此我们只显示该表的一部分内容，在dump全部表格之前，我们先建立两条TCP连接：
在所有正在监听的服务器进程中，我们仅列出了FTP服务器的情况，它使用端口21：
相比于rlogin登录到localhost，rlogin登录到gemini在上图中只有一行记录，这是因为localhost是本机，而gemini是另一台主机，并且通过rlogin登录到gemini的这一行记录我们只能看到连接的客户端信息（端口1023）。但rlogin登录到localhost的连接，客户端（端口1415）和服务器端（端口23）都显示，这是因为这种连接通过环回接口。FTP服务器监听的本地IP是0.0.0.0，表明它接受来自任何接口的连接。
可通过SNMP获取SLIP链路的MTU，首先从IP路由表中找出SLIP连接对应的端口号，然后通过端口号在接口表中找到这个接口的MTU：
可见，即使连接类型是SLIP连接，但MTU仍设为以太网的1500，目的可能是为了避免分片。
从域名服务器返回的第1个IP地址总是和客户有相同的子网掩码，虽然其他IP也能正常工作，但效率比较低。
路由器gemini是一个多接口主机，有两个以太网接口，首先确认两个接口都可从sun机器Telnet登录：
使用traceroute命令查看这两个地址选路方面的不同：
可见如果采用属于140.252.3子网的地址，会多额外一跳。以下是系统的连接关系图：
由上图，主机gemini和路由器swnrt都连接了两个网段：140.252.3和140.252.1。
路由器netb采用了ARP代理，使得sun工作站好像是直接连接到140.252.1子网上。我们忽略了sun和netb之间SLIP连接的调制解调器，因为这和我们的讨论不相关。
上图中，用虚线画出了当Telnet到140.252.3.54时的路径，返回的数据报没有从原路返回。我们可以看下带有宽松选路特性的traceroute的输出结果：
如上图，在命令中指明宽松源站选路时，swnrt路由器不会回应，由不指定宽松源站选路选项的traceroute输出可知，swnrt是事实上的第二跳，而在上例中，swnrt却超时了，原因在于swnrt在指定了源站宽松选路时没有产生ICMP超时差错（当路由器收到TTL为0的数据报时，会丢弃该数据报并返回一个ICMP超时差错）。我们发现，返回路径中确实没有经过swnrt路由器。
为获取netb路由器的路由表，在主机sun上用snmpi程序的get命令取netb上140.252.3.0的下一跳路由器的值：
可见netb路由器会把分组发给swnrt路由器。
而gemini把分组回送给sun时，由于目的地址是140.252.1.29，而子网140.252.1是直接连到gemini上的，因此gemini会将分组传给netb。
以上讨论的例子都是从管理进程到代理进程的，代理进程也可以主动发送trap到管理进程，以告诉管理进程在代理进程侧有某些管理进程所关心的事件发生，trap会发送到管理进程的162号端口。
现在已经定义了6种trap类型，第7种类型是由供应商自己定义的特定类型：
用tcpdump看trap的情况，我们在系统sun上启动SNMP代理进程，然后让它产生coldStart类型的trap（我们告诉代理进程把trap信息发送到bsdi主机，虽然该主机上没有处理trap的管理进程，但可以用tcpdump查看产生了什么样的分组，trap不需要管理进程给代理进程发送确认，所以我们不需要trap的处理程序），然后我们用管理进程端的snmpi程序向sun发送一个请求，但该请求的共同体名称是无效的，这将使sun产生一个authenticationFailure类型的trap，以下是tcpdump的输出：
上图中，两个UDP数据报都是从SNMP代理进程（端口号161，图中显示的名称是snmp）发送到目的端口号是162（图中显示的名称是snmp-trap）的服务器进程上的。
上图中的C=traps是trap消息的共同体名，这是一个由ISODE SNMP代理进程使用的配置选项。
上图中，第一行的Trap(28)和第二行的Trap(29)是PDU类型和长度。
上图中两个输出行的第一项内容是相同的E:unix.1.2.5，这是企业名字段，即代理进程的sysObjectID，它是1.2.6.1.4.1（iso.org.dod.internet.private.enterparses）结点下面的某个结点，所以代理进程的对象标识是1.2.6.1.4.1.4.1.2.5，，它的简称是unix.agents.fourBSD-isode.5，最后的数字5代表ISODE代理进程软件的版本号。此企业名代表产生trap的代理进程的软件信息。
上图中输出的下一项是代理进程的IP地址140.252.13.33。
上图第一行中，trap的类型是coldStart，第二行中，是authenticationFailure，与之对应的trap类型值分别为0和4，由于这些都不是厂家自定义的trap，所以特定代码字段（specific code，见图25-30）是0，在图中没有打印出来。
上图中两个trap的最后一个输出分别是20和1907，这是时间戳字段，它是TimeTicks类型值，表示从代理进程初始化到trap发生所经历了多少百分之一秒，在冷启动trap的情况下，在代理进程初始化后到trap的产生共经历了200ms，上图显示，第2个trap在第1个trap产生的18.86秒后出现，这与19.07-0.2的结果很接近。
trap报文中还可以包含很多代理进程想发送给管理进程的变量，但上例中没有包含任何变量。
正式的SNMP规范中采用的是ASN.1（Abstract Syntax Notation 1，抽象语法标记1）语法，在SNMP报文中比特的编码采用BER（Basic Encoding Rule，基本编码规则）。
ASN.1是一种描述数据和数据特征的语言，它和数据的存储和编码无关。MIB和SNMP报文中的所有字段都是用ASN.1描述的，如ASN.1这样描述SNMP的数据类型ipAddress：
ASN.1这样描述MIB中的简单变量：
对于以上ASN.1的定义，有多种编码方式把数据编码为传输的比特流，SNMP使用的是BER，如一个简单的整数64，在BER中需要3个字节来表示，第一个字节说明这是一个整数，下个字节说明用了多少字节来存储该整数（此处是1），最后一个字节才是该整数的值。
ASN.1和BER这两个繁琐的概念只有在实现SNMP时才重要，对我们理解网络管理的概念和流程并没有太大关系。
1993年，发表了定义新版本SNMP的11个RFC，RFC 1441是其中的第一个，它系统地介绍了SNMPv2，当时已经有了两个SNMPv2的基本模型，但厂家的实现在1994年才能广泛使用。
SNMPv2中新增内容：
1.新的报文类型get-bulk-request，它高效地从代理进程读取大块数据。
2.新的报文类型inform-request，它使一个管理进程向另一个管理进程发送信息。
3.两个新MIB：SNMPv2 MIB和SNMPv2-M2M MIB（管理进程到管理进程的MIB）。
4.SNMPv2比SNMPv1更安全。SNMPv1中从管理进程发往代理进程的共同体名是一个明文密码，SNMPv2可提供加密和身份验证。
如果管理进程和代理进程使用的是同一个端口，则一个主机就不能同时是管理进程和代理进程，因为端口会被另一个进程占用。
