以太网协议报文格式

TCP/IP协议族

IP/TCP

Telnet 和R login、FTP 以及SMTP

IP/UDP

DNS 、TFTP 、BOOTP 、SNMP

ICMP 是IP 协议的附属协议、IGMP 是Internet 组管理协议

ARP （地址解析协议）和RARP （逆地址解析协议）是某些网络接口（如以太网和令牌环 网）使用的特殊协议，用来转换I P层和网络接口层使用的地址。

1、 以太帧类型 以太帧有很多种类型。不同类型的帧具有不同的格式和MTU 值。但在同种物理媒体上都可同时存在。

标签协议识别符(Tag Protocal Identifier, TPID): 一组16位元的域其数值被设定在0x8100以用来辨别某个IEEE 802.1Q的帧为已被标签的，而这个域所被标定位置与乙太形式/

长度在未标签帧的域相同，这是为了用来区别未标签的帧。 优先权代码点(Priority Code Point, PCP): 以一组3位元的域当作优先权的参考，从0(最低) 到7(最高) ，用来对资料流(音讯、影像、档案等等) 作传输的优先级。

标准格式指示(Canonical Format Indicator, CFI): 1位元的域。若是这个域的值

为1，则MAC 地指则为非标准格式；若为0，则为标准格式；在乙太交换器中他通常默认为0。在乙太和令牌环中，CFI 用来做为两者的相容。若帧在乙太端中接收资料则CFI 的值须设为1，且这个端口不能与未标签的其他端口桥接。 虚拟局域网识别符(VLAN Identifier, VID ): 12位元的域，用来具体指出帧是属于

哪个特定VLAN 。值为0时，表示帧不属于任何一个VLAN ；此时，802.1Q 标签代表优先权。16位元的值0x000和0xFFF 为保留值，其他的值都可用来做为共4094个VLAN 的识别符。在桥接器上，VLAN1在管理上做为保留值。这个12位元的域可分为两个6位元的域以延伸目的(Destination)与源(Source)之48位元地址，18位元的(Triple-Tagging)可和原本的48位元相加成为66位元的地址。

0、以太网的封装格式（RFC 894）

IEEE 802.2/802.3（RFC 1042）

一个0x0800的以太类型说明这个帧包含的是IPv4数据报。同样的，一个0x0806的以太类型说明这个帧是一个ARP 帧，0x8100说明这是一个IEEE 802.1Q帧，而0x86DD 说明这是一个IPv6帧，而0x 8864有PPPoE 封装 （其他以太网类型见附2）

1、以太网PAUSE 帧

IEEE 802.3x 是全双工以太网数据链路层的流控方法。当客户终端向服务器发出请求后, 自身系统或网络产生拥塞时, 它会向服务器发出PAUSE 帧, 以延缓服务器向客户终端的数据传输。

有关交换机的流量控制机制：

定义：流量控制用于防止在端口阻塞的情况下丢帧，这种方法是当发送或接收缓冲区开始溢出时通过将阻塞信号发送回源地址实现的。流量控制可以有效的防止由于网络中瞬间的大量数据对网络带来的冲击，保证用户网络高效而稳定的运行。

两种控制流量的方式：

1，在半双工方式下，即半双工背压控制，是通过反向压力（backpressure ）即我们通常说的背压计数实现的，这种计数是通过向发送源发送jamming 信号使得信息源降低发送速度。

2， 在全双工方式下，流量控制一般遵循IEEE 802.3X 标准，是由交换机向信息源发送“pause ”帧令其暂停发送。

采用流量控制，使传送和接受节点间数据流量得到控制，可以防止数据包丢失。

PAUSE 帧格式：

MAC 控制帧通过其唯一的类型域标识符（0x8808）识别。

pause 格式：

目的地址： 组播地址（01-80-C2-00-00-01）

源地址：

类型： 8808

MAC 控制操作码:2个字节 0x0001 （Pause 帧仅是MAC 控制帧的一种，对于Pause 帧，其在MAC 控制帧中的操作码为00-01; ）

MAC 控制操作参数域：2个字节 代表要求对方停止的时间。（MAC 控制参数域，包含用于MAC 控制相关的参数。

保留域。

对于Pause 帧，此处应填入要求对端设备暂停发送的时间长度， 由两个字节 (16位) 来表示该长度，每单位长度为物理层芯片发送512位数据的时间。 所以发送一次Pause 帧，要求对端设备暂停发送的时间长度为：0-65535×(512/以太网传输速率) 。）

2、以太网VLAN 帧格式

一、IEEE 802.1Q 标签帧格式

7B 1B 6B 6B 4B 2B 42-1496B 4B

Vlan tag

：4字节，包含2个字节的标签协议标识(TPID)和2个字节的标签控制信息(TCI)，TCI 字段具体又分为： priorty 、CFI 、Vlan ID，具体格式如下所示：

2B 1b 12b 3b

⏹ TPID （标签协议标识）：2字节，用于标识帧的类型，其值为0x8100时表示802.1Q/802.1P

的帧。设备可以根据这个字段判断对它接收与否。

⏹ TCI （标签控制信息字段）：2字节，包括用户优先级（User Priority ）、规范格式指示器

（Canonical Format Indicator）和 VLAN ID。

● User Priority ：3个bti ，表示帧的优先级，取值范围0~7，值越大优先级越高，用

于802.1p 。

● CFI ，1bit ，值为0代表MAC 地址是以太帧的MAC ，值为1代表MAC 地址是FDDI 、

令牌环网的帧。

● VID （VLAN ID）：12bit ，表示VLAN 的值。12bit 共可以表示4096个VLAN ，实际上，

由于VID 0和4095被802.1Q 协议保留，所以VLAN 的最大个数是4094(1-4094)个

（据说VID ＝0 用于识别帧优先级。 4095（FFF ）作为预留值）

二、IEEE 802.1ad(QinQ)帧格式

基本概念

IEEE 802.1ad 的全称是“Virtual Bridged Local Area Networks Amendment 4: Provider Bridges”，该协议的目标是业务提供商在为客户提供业务时使客户间的服务相互独立，没有相互依赖关系，同时尽量做到业务提供商透明地为客户提供业务。该标准描述了业务提供商（运营商）如何利用和扩展802.1Q 在一个统一的网络中为相互独立的客户提供以太网业务。

QinQ 技术〔也称Stacked VLAN 或Double VLAN〕。标准出自IEEE 802.1ad,其实现将用户私网VLAN Tag封装在公网VLAN Tag中，使报文带着两层VLAN Tag穿越运营商的骨干网络（公网）。在公网中报文只根据外层VLAN Tag（即公网VLAN Tag）传播，用户的私网VLAN Tag被屏蔽。

带双层VLAN Tag的报文结构，802.1ad 的报文格式，基本同前面我们所讲的QinQ 报文格式一致，主要的区别就是802.1ad 中重新定义了TPID 的值和把原来的CFI 位修改为DEI （丢弃标识）位，如下图所示：

• C-VLAN：Customer VLAN，是用户网络内部使用的VLAN ；

• S-VLAN：Service VLAN ，服务提供商网络中使用的VLAN ，该VLAN 标识VPN 用户或者是用户的业务；

• Customer Bridge:Customer网络中的Bridge ，只能识别C-VLAN ；

• Provider Bridge：服务提供商网络中的Bridge ，根据处理内容的不同又分为S-VLAN Bridge和Provider Edge Bridge。其中S-VLAN Bridge只能识别S-VLAN ； Provider Edge Bridge可以同时识别C-VLAN 和S-VLAN ；

• C-VLAN Component:在Bridge 内可识别、插入、删除C-VLAN 的实体，每个端口一个，对C-VLAN 的操作互相独立（两个端口上接收到相同的C-VLAN ，但由于属于不同的客户最后的处理结果会不同）；

• S-VLAN Component:在Bridge 内可识别、插入、删除S-VLAN 的实体，由于在一个Bridge 内不存在相同的S-VLAN 属于不同服务提供商的情况，因此在一个桥内只有一个S-VLAN 的实体。

QinQ 技术上完全可以多层堆叠，没有限制，仅受Ethernet 报文长度的限制，具有很好的扩充性。对于QinQ ，业界有多种不同的称呼，比如Tag in Tag、VLAN VPN、StackVLAN 、SVLAN QinQ 每增加一层VLAN 标签，就可以将所覆盖的用户VLAN 数量增加4096倍，两层VLAN 标签可以支持4K×4K VLAN，一般来说两层VLAN 就可以满足绝大多数需求了。

相对基于MPLS 的二层VPN ，QinQ 具有如下特点：

为用户提供了一种更为简单的二层VPN 隧道；

不需要信令协议的支持，可以通过纯静态配置实现；

由于QinQ 的实现是基于802.1Q 协议中的Trunk 端口概念，要求隧道上的设备都必须

支持802.1Q 协议。

QinQ 主要可以解决如下几个问题：

缓解日益紧缺的公网VLAN ID资源问题；

用户可以规划自己的私网VLAN ID，不会导致和公网VLAN ID冲突；

为小型城域网或企业网提供一种较为简单的二层VPN 解决方案；

QinQ 实现过程如图3 所示：

图 3 QinQ功能示意图

图3中CE 交换机上行报文带有内层Vlan 标签，报文到达汇聚交换机后，汇聚交换机可以根据不同的交换机端口给报文打上相应的外层标签，这样汇聚交换机每端口可以支持4KVlan 的接入。

QinQ 报文封装

QinQ 的报文封装就是在原有802.1Q 报文中的TAG 头上再加上一层TAG 封装，

用来扩

展VLAN 的范围，如图1所示：

图1 QinQ报文封装

QinQ 的报文转发过程

在通过QinQ 实现简单的二层VPN 过程中报文是按如下方式转发：

图2 QinQ报文转发过程

图2中在运营商网中使用VLAN20来标识客户A 、VLAN30标识客户B ，当客户A 的报文到达运营商的边缘交换机时，边缘交换机均给客户A 的报文打上一个外层标签（VLAN20），然后在VLAN20中转发，不会转发到VLAN30，报文在离开运营商网络时再剥离掉外层的标签，转发到用户A 的网络，从而实现一个简单二层VPN 功能。

QinQ 报文的TPID 值可调功能

TPID （Tag Protocol Identifier，标签协议标识）是VLAN Tag中的一个字段，IEEE 802.1Q协议规定该字段的取值为0x8100。IEEE 802.1Q协议定义的以太网帧的Tag 报文结构如下：

图3 IEEE 802.1Q报文结构

通常在QinQ 中设备的内外层标签的TPID 值均采用协议规定的0x8100，但是某些厂商的设备将QinQ 报文外层Tag 的TPID 值设置为0x9100或0x9200，为了和这些设备兼容，并提供较高的灵活性，我司支持QinQ 功能的交换机基本上均提供了QinQ 报文TPID 值可调功能（需要注意有的设备整机支持，有的设备是端口支持），能修改QinQ 设备的外层标签的TPID 值。（在本文的802.1ad 部分我们将会看到802.1ad 所规定的TPID 为0x88a8，所以当设备同标准802.1ad 设备作QinQ 对接时也需要TPID 可调功能）。

灵活QinQ （Selective QinQ）

在前面我们所讲的QinQ 中，通常是以物理端口来划分用户或用户网络，当多个不同用户以不同的VLAN 接入到同一个端口时则无法区分用户。另外前面的QinQ 方案是一种简单二层VPN 的应用，在运行营商接入环境中往往需要根据用户的应用或接入地点（设备）来区分用户，基于这种应用产生了灵活QinQ 方案。

简单讲灵活QinQ 就是根据用户报文的Tag 或其他特征（IP/MAC等），给用户报文打上相应的外层Tag ，以达到区分不同用户或应用的目的。

当前灵活QinQ 主要应用在运营商的接入网络中，在运营商网络中给接入用户分配一个VLAN ，以达到便于问题追踪和防止不同用户间互访，用外层标签区分用户的应用；或在接入的环境中用外层标签来区分不同的接入地点，用内外两层标签唯一标识出一个接入用户。在这样的应用中需要BRAS/SR设备支持QinQ 的应用（能够终结双Tag ）。

下面我们以S9500为例，看一下灵活QinQ 的应用场景：

在S9500上实施QinQ ，并在S9500上进行业务分流，分流的方式是利用灵活QinQ 功能，灵活QinQ 分流的依据有下面几种：

1) 根据端口的VLAN 区间分流：比如PC 的VLAN 范围1～1000，STB 的VLAN 范围1001～2000，网吧的VLAN 范围2001～3000；

2) 根据报文的协议号分流：比如PC 采用PPPoE 、STB 采用IPoE ，这些终端都通过一个VLAN 上行，可以根据PPPoE 和IPoE 报文不同的协议号作为QinQ 的分流依据；

3) 根据报文的目标IP 地址分流：对于相同源IP 地址，相同报文封装不同的业务应用报文，比如PC 上的SoftPhone 产生的报文，需要根据报文目的IP 地址实施灵活QinQ 进行业务分流；

4) 根据QinQ 的内层标签的区间，在某些级联交换机的组网模式中，

下连的交换机已经

实施了基于端口的QinQ ，为了实现业务分流，可以根据QinQ 的内层VLAN 标签的区间实施灵活QinQ 进行业务分流。 上述应用场景可以用图4来直观的加以描述：

图4 灵活QinQ 对多业务的识别标记

BPDU Tunnel(L2 Protocol Tunnel)

QinQ 网络中，运营商网络对客户透明，当客户和运营商网络之间的连接有冗余时必然导致环路问题，如QinQ 应用示意图2中的A 客户。这就需要运营商网络能透明传输STP/RSTP/MSTP报文，这样客户可以跨运营商网络构建自己的STP 树，切断冗余链路。另外为了保证客户全网VLAN 配置的一致性，动态VLAN 协议如GVRP 、VTP 等也要求通过运营商网络透传，如果客户使用GMRP 作组播应用的话，GMRP 报文也要求透传。同时在透传这些报文时，需要区分开不同用户的二层协议报文。

我们知道以上这些BPDU 报文是桥设备的二层控制报文（基本上是以LLC 封装的），是与设备全局相关的，不带VLAN Tag，所以需要一种机制来传输用户的二层控制报文，从而引入了BPDU Tunnel (Cisco:Layer 2 Protocol Tunneling)的概念，通过Tunnel 来传播用户的二层控制报文。

通常BPDU Tunnel 是这样实现的：当Tunnel 端口收到一个用户的BPDU 后，把目的MAC 修改为一个组播MAC ，然后再给协议报文打上用户所属VLAN 的Tag 信息，组播MAC 保证报文在VLAN 内广播，同时标识这个报文是个BPDU-Tunnel 报文，交换机在收到这个报文时上送CPU 处理，还原其BPDU 身份，并根据报文中用户所属的VLAN 信息，把报文送到相应的客户网络。

当前我司的实现就采取了上述这种方法，收到用户的BPDU 报文后，给这个报文的目的MAC 修改为：01-00-0c-cd-cd-d0，再加上运营商分配该用户的VLAN Tag，如图5所示：

图5 BPDU-Tunnel报文封装

在传统的QinQ Tunnel中是通过修改原协议报文的目的地址及加上用户所属VLAN 标识来传递用户L2协议报文的（这样做的缺点在于需要在边缘设备上对报文进行修改加重设备CPU 的负担）。

在802.1ad 中为C-VLAN 及S-VLAN 分配了不同的保留地址，在Ｓ-VLAN 中处理C-VLAN 中的协议报文和处理普通的数据报文一样，从而不需要Tunnel 就可以透明传输用户二层协议报文。

表格 2：保留的地址

Spanning Tree Protocol

Provider 网络的STP 操作和Customer 网络的STP 操作完全独立运行，相互不关联。在Provider 网络内部采用不同的Bridge Group Address （01-80-C2-00-00-08），对于用户的BPDU 报文（01-80-C2-00-00-00）作为普通数据报文透传，不进行识别和处理。Provider 网络边缘的C-VLAN component端口可以参与用户STP 拓扑的计算和用户BPDU 的处理。 GVRP

Provider 网络的GVRP 操作和Customer 网络的GVRP 的操作完全独立运行，相互不关联。在Provider 网络内部采用不同的Provider Bridge GVRP Address（01-80-C2-00-00-0D ），对于用户GVRP 报文（01-80-C2-00-00-21）以及其他的GARP 保留地址作为普通数据报文透传，不进行识别和处理。Provider 网络边缘的C-VLAN component端口可以参与用户的GARP 报文的处理。

802.1ad 对灵活QinQ 的支持

802.1ad 对灵活QinQ 的支持同当前常见的灵活QinQ 基本一致，在802.1ad 中提供了两种确定用户所属S-VLAN 的方式：

1、基于端口（Port-based service interface ），在这种模式下用户是根据接入的端口来选择Ｓ-VLAN(Service Instance)的

2、基于C-VLAN （C-Tagged service interfaces），在这种模式下是根据用户使用的C-VID 来先择S-VLAN(Service Instance)，即同当前我们所见的灵活QinQ 类似。

2、 IP 报文格式

版本号：pv4-ipv6

IP 头部长度：5 words = 5*4 = 20字节（不含选项）

TOS ：服务类型，包括一个3 bit的IP 优先级字段（现在已被忽略），3 bit的TOS 子字段和2 bit 未用为0； 4 bit的TO S分别代表： Bit 3: 0 = Normal Delay, 1 = Low Delay.

Bits 4:

0 = Normal Throughput, 1 = High Throughput.

Bits 5: 0 = Normal Relibility, 1 = High Relibility. 0 1 2 3 4 5 6 7

+-----+-----+-----+-----+-----+-----+-----+-----+---------------------| | | | | | PRECEDENCE | TOS | MBZ | | | | | +-----+-----+-----+-----+-----+-----+-----+-----+---------------------| 1、IP 报文中，TOS （服务类型，现改名为DS ，即区分服务）字节占8位（P2 P1 P0 T3 T2 T1 T0 CU）；

其中：前三个比特（P2 P1 P0）定义为IP 优先级，取值范围为0-7； 第四至第七比特（T3 T2 T1 T0）为TOS 子字段,TO 位备用： 第8个比特为未用位。

2、DSCP DSCP 由RFC2474定义，它重新命名了IP 报头中TOS 使用的那1字节，DSCP 使用高6bit ，最低2bit 不用。 (DS5 DS4 DS3 DS2 DS1 DS0 CU CU ) RFC2474 定义最高3比特为级别／类别选择代码（Class Selector Codepoints，CS ）， 其意义和IPv4报头中IP 优先级的定义是相同的，CS0 ～ CS7的级别相等于IP 优先级0 ～ 7。 但它并没有定义第3到第5比特的具体含义以及使用规则。DSCP 使用6比特，可以定义64个优先级（0－63）。

IP 首部兼容性

由于ECN 修改了IP 首部，所以存在以下兼容性问题：

1、以下RFC 除了RFCs 731,2474,2780这三个标准可以兼容ECN 的增量部署之外，其他RFC 实现均无法兼容ECN 部署。

RFC 791 defined the ToS (Type of Service) octet in the IP header. 0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+

|PRECEDENCE| TOS | 0 | 0 | RFC 791 +-----+-----+-----+-----+-----+-----+-----+-----+

RFC 1122 included bits 6 and 7 in the TOS field, though it did not discuss any specific use for those two bits:

0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+

|PRECEDENCE| TOS | RFC 1122 +-----+-----+-----+-----+-----+-----+-----+-----+

The IPv4 TOS octet was redefined in RFC 1349 [RFC1349] as follows:

0 1 2 7

+-----+-----+-----+-----+-----+-----+-----+-----+

| PRECEDENCE| TOS |MBZ| RFC 1349 +-----+-----+-----+-----+-----+-----+-----+-----+

The IPv4 TOS octet was redefined in RFC 1349 [RFC1349] as follows:

0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+

| DSCP | CU | RFCs 2474, 2780 +-----+-----+-----+-----+-----+-----+-----+-----+

总长度字段： 数据段的长度。

标识字段：发一个包加1 ，唯一地标识主机发送的每一份数据报

标志字段：是否分片， bit1： bit2：是否允许分片（默认值0：允许），bit3：是否是最后一个分片（默认为0, ：最后一个分片）

片偏移字段：分片offset （供组装时使用）用于总长度字段是16bit ，所以要用13bit 表示16bit 的数，就需要片偏移字段值是8的整数倍。

TTL ：time-to-live ，生存时间字段设置了数据报可以经过的最多路由器数

协议字段：udp\tcp\igmp\icmp，IP 在首部中存入一个长度为8 bit的数值，称作协议域。 1表示为ICMP 协议，2表示为IGMP 协议，6表示为TCP 协议，17表示为UDP 协议。 检验和：checksum ，根据I P首部计算的检验和码，ICMP 、IGMP 、UDP 和TCP 在它们各自的 首部中均含有同时覆盖首部和数据检验和码。 SIP ： DIP ：

MTU ： 1500—以太网信息包最大值 1492—PPPoE 最佳值 1472—使用ping 命令的最大值 1468—DHCP 最佳值 1430—VPN PPTP最佳值 576—-拨号连接到ISP 的标准值

3、

ARP 协议的报文格式

arp-request 报文：192.196.1.98（00:60:f3:20:dc:55）想要192.168.1.97的mac 地址

arp-reply 报文：

4、

UDP 协议

5、 TCP 协议

6、

ICMP 协议

7、

IGMP V1 V2报文格式

1）Version ：1 表示IGMP 报文是V1版本；

2）Type ：1 表示组成员查询query

，2 表示成员报告report ；

3）Unused ：保留字段，发送的时候以0填充，接收的时候不作任何处理； 4）Checksum ：检验和，对IGMP 报文头每16bit 进行二进制反码求和；

5）Group Address：在成员查询中该字段填充0.0.0.0，在成员报告字段中它填充组地址。

1） 类型：

0x11 表示成员查询query

0x12 表示IGMP V1成员报告report 0x16 IGMP V2成员报告report

0x17 表示成员离开leave

0x22表示IGMP V3成员报告report

2）最大响应时间：最大响应时间只在成员关系查询消息中有意义，它以1/10秒为单位标明相应的报告发送所允许的最大延迟时间。在其它类型的消息中，发送者把该字段清0, 接收者忽略这个字段；

3）检验和：对IGMP 报文头每16bit 进行二进制反码求和； 4）组地址字段：

通用组成员查询 = 0.0.0.0 \ 特定组成员查询 = 指定的组播组IP 地址、 成员报告 = 指定的组播组IP 地址、 离开报文 = 指定的组播组IP 地址；

6）其它字段

需要注意的是，IGMP 消息是可能大于8个字节的，特别是将来的向下兼容的IGMP 版本。只要类型字段是可以被识别的，IGMPv2的实现在处理数据报时必须忽略超过8个字节的内容。但是IGMP 校验和始终是针对整个数据报的，而不仅仅是前面的8个字节。

8、 SNMP 系统构架及其协议

Manager-Agent 系统结构

我们在M 端利用 C 语言和SNMP 协议编写一个简单的应用程序 可以发送GET GET-NEXT SET等命令，对放在网络各处的安装了SNMP 代理的设备进行查询。 在SNMP 协议中M 端和A 端的通信是通过SNMP 协议数据单元 PDU 实现的 它们之间可以有三种类型的交互：

M 端执行GET 或GET-NEXT 操作从代理A 获得信息 M 端执行SET 操作对代理A 的属性进行设置

代理A 端向M 端发送陷阱异步通知信息告诉管理者关于自己的一些事件

SNMP 协议和编码格式 1、管理信息库(MIB)

管理信息库(MIB)规定了网络代理所保存的数据项目、数据类型，以及在每个数据项目中允许的操作。

通过对这些数据项目的存取访问来实现网络管理的5大功能： 配置管理、性能管理、失效管理、计费管理、安全管理。 Internet 标准的管理信息库(MIB)是 数形结构的数据库，其结构见图

2、MIB 对象定义

DEFINITIONS::=BEGIN IMPORTS

mgmt, OBJECT-TYPE, NetworkAddress, IpAddress,Counter, Gauge, TimeTicks mib OBJECT IDENTIFIER::={mgmt 1} system OBJECT IDENTIFIER::={mgmt 2} interface OBJECT IDENTIFIER::={mgmt 3} at OBJECT IDENTIFIER::={mgmt 4} ip OBJECT IDENTIFIER::={mgmt 5} icmp OBJECT IDENTIFIER::={mgmt 6}

tcp OBJECT IDENTIFIER::={mgmt 7} udp OBJECT IDENTIFIER::={mgmt 8} egp OBJECT IDENTIFIER::={mgmt 9}

3、ASN.1语法+ BER(Basic Encoding Rule) 编码方法

基本编码规则(BER)的数据都由三个域构成：标识域(tag)+长度域(length)+值域(value)。 标识域：指明数据的类型, 占用1个字节。

长度域：指明值域的长度, 不定长, 一般为一到三个字节。其格式可分为短格式和长格式. 长度域采用短/长指示器(Short/Long Form) 来标明长度指示符是否是单个字节, 指示器在bit8上。

如果短/长指示器是0, 则为短限定格式, 低7位包含的就是数据的长度, 长度值在0~127之间;

如果短/长指示器是1, 则为长限定格式, 其低7位的值表示后面紧跟的长度指示值的字节数,

而后续字节拼接起来的值就是数据字段的长度, 即数据的长度。

值域：保存的是数据的实际编码。虽然ASN.1定义了很多数据类型, 但大多数类型可由整形、对象标 识、空、串等基本数据类型和sequence 构造类型表示。例如有符号整数和无符号整数、TimeTicks 、Gauge 、Counter 统一用整数表示。

例子：

1、整型Integer

整型数据值域用补码表示 例：

2、对象标识ObjectID 例：1.3.6.1.2.1.1.1 其编码规则如下：

objectID::=0x06 length {subidentifier}* (规则1) subidentifier::={leadingbyte}* lastbyte (规则2) leadingbyte::=1 7bitvalue (规则3) lastbyte::=0 7bitvalue (规则4) 首两个ID 被合并为一个字节X*40+Y (规则5)

虽然规则很多, 但由于大多数子对象标识在0~127,只需按规则(1)、(5)即可; 当子对象标识大于127,

则按规则(2)、(3)、(4)将其分解为多个字节, 最后一个字节的高位为零, 其余字节的高位为一。

如:1.3.6.1.810.1,根据规则(5),首两个子对象标识1.3被合并为2B(1*40+3=43);子对象标识810超过127 , 根据规则(2)、(3)、(4)将其拆分为两个字节86 2A(810=11 0010 1010 ==> 1000 0110 0010 1010);

整个MIB 被编码为:0x06 0x06 0x2b 0x06 0x01 0x86 0x2a 0x01。

3、sequence 组合类型

sequence::=0x30 length {asndata}*

如:30 05 02 01 10 05 00表示一个sequence 结构, 内含两个成员, 其中一个为整型, 另一个为空类型(NULL)。

4、其它类型

如:30 05 02 01 10 05 00表示一个sequence 结构, 内含两个成员, 其中一个为整型, 另一个为空类型(NULL)。

5、SNMP 报文

SNMP 共有五种报文, 分别为Get_Request(0xA0)、Get_Next_Request(0xA1)、Get_Response(0xA2)、Set_Request(0xA3)和Trap(0xA4), 其结构如下:

SNMP_Message::=SEQUENCE{version Integer,community OcterString, pdu SNMP_PDUs}

SNMP_PDUs::=CHOICE{get_request PDU,get_next_request PDU,get_response PDU,set_request PDU,trap TrapPDU} PDU::=SEQUENCE{request-id Integer,error-status Integer,error index Integer,variable-bindings VarBindList}

TrapPDU ∷=SEQUENCE{enterprise ObjectID,agent_addr IPAddr, trap_type Integer, specific_type Integer,time TimeTicks, variable-bindings VarBindList}

4、SNMP 协议数据单元 PDU 的格式

在SNMP 中 信息按照SNMP 消息的形式在管理站和代理之间交换

注：Request-id 用于使响应和查询相匹配

③ Get Response

④ Trap

SNMPv1操作原语类型的ASN.1表示

操作原语类型（PDU type） ASN.1表示 GetRequest 0xA0 (160) GetNextRequset 0xA1 (161) GetRqsponse 0xA2 (162) SetRequest 0xA3 (163) Trap 0xA4 (164)

===SNMP协议包解析=== 30 82 00 59 //组合类型0x30 长格式两字节0x82 长度为0x0059=89 -02 01 00 //整形 短格式1字节 version=0,表示SNMPv1 -04 06 70 75 62 6c 69 63//字符串类型 6字节 community=“public ” -a2 82 00 4a //A2 get-response 长格式两字节0x82 长度为0x004a=74 --02 02 07 9f //request_id = 1951 流水号 --02 01 00 //error-status = 0 --02 01 00 //error-index = 0 --30 82 00 3c //variable-bindings 长格式两字节0x82 长度为0x003c=60 ---30 82 00 10 //1 items 长格式两字节0x82 长度为0x10=16

----06 0b 2b 06 01 02 01 19 03 02 01 05 01 //ObjectID类型 11字节 1.3.6.1.2.1.25.3.2.1.5.1 表示object-name ----02 01 02 值为2 ---30 82 00 10 //2 items 长格式两字节0x82 长度为0x10=16 ----06 0b 2b 06 01 02 01 19 03 05 01 01 01 //1.3.6.1.2.25.3.5.1.1.1 ----02 01 03 值为3 ---30 82 00 10 //3 items 长格式两字节0x82 长度为0x10=16 ----06 0b 2b 06 01 02 01 19 03 05 01 02 01 //1.3.6.1.2.1.25.3.5.1.2.1 ----04 01 00 字符为0 表示空

附1：SNMP 五种协议数据单元 && SNMP报文格式详解

版本

写入版本字段的是版本号减1，对于SNMP （即SNMPV1）则应写入0。

公共体

共同体就是一个字符串，作为管理进程和代理进程之间的明文口令，常用的是6个字符“public ”。

PDU 类型

根据PDU 的类型，填入0～4中的一个数字，其对应关系下表所示意图。

PDU 类型

get/set首部

请求标识符(request ID)

这是由管理进程设置的一个整数值。代理进程在发送get-response 报文时也要返回此请求标识符。

管理进程可同时向许多代理发出get 报文，这些报文都使用UDP 传送，先发送的有可能后到达。

设置了请求标识符可使管理进程能够识别返回的响应报文对于哪一个请求报文。

差错状态(error status)

由代理进程回答时填入0～5中的一个数字，见下表的描述。

差错状态描述

差错索引(error index)

当出现noSuchName 、badValue 或readOnly 的差错时，由代理进程在回答时设置的一个整数，它指明有差错的变量在变量列表中的偏移。

trap 首部 企业(enterprise)

填入trap 报文的网络设备的对象标识符。此对象标识符肯定是在图3的对象命名树上的enterprise 结点{1.3.6.1.4.1}下面的一棵子树上。

trap 类型

此字段正式的名称是generic-trap ，共分为表4中的7种。

trap 类型描述

当使用上述类型2、3、5时，在报文后面变量部分的第一个变量应标识响应的接口。

特定代码(specific-code)

指明代理自定义的时间（若trap 类型为6），否则为0。

时间戳(timestamp)

指明自代理进程初始化到trap 报告的事件发生所经历的时间，单位为10ms 。例如时间戳为1908表明在代理初始化后1908ms 发生了该时间。

变量绑定(variable-bindings)

指明一个或多个变量的名和对应的值。在get 或get-next 报文中，变量的值应忽略。

附2：EtherType ：以太网类型字段及值

EtherType 是以太帧里的一个字段，用来指明应用于帧数据字段的协议。根据 IEEE802.3，Length/EtherType 字段是两个八字节的字段，含义两者取一，这取决于其数值。在量化评估中，字段中的第一个八位字节是最重要的。而当字段值大于等于十进制值 1536 （即十六进制为 0600）时， EtherType 字段表示为 MAC 客户机协议（EtherType 解释）的种类。该字段的长度和 EtherType 详解是互斥的。

该类字段值取自 IEEE EtherType 字段寄存器。EtherType 字段是个极限空间，因此其分配是有限的。只有开发新的数据传输协议的人员需要使用 EtherType 字段，而不管他们实际上是否真正生产任何设备。IEEE RAC EtherType 字段批准权威机构负责检查和批准 EtherType 字段。

知名协议已经分配了 EtherType 值，下面表格中列出了 EtherType 字段中常用值及其对应的协议：

0x0000-0x05DC IEEE 802.3 长度 0x0101-0x01FF 实验 0x0600 XEROX NS IDP 0x0660

0x0661 DLOG

0x0800 网际协议（IP ） 0x0801 X.75 Internet 0x0802 NBS Internet 0x0803 ECMA Internet 0x0804 Chaosnet 0x0805 X.25 Level 3

0x0806 地址解析协议（ARP ： Address Resolution Protocol） 0x0808 帧中继 ARP （Frame Relay ARP） [RFC1701] 0x6559 原始帧中继（Raw Frame Relay） [RFC1701]

0x8035 动态 DARP （DRARP ：Dynamic RARP）反向地址解析协议（RARP ：Reverse Address Resolution Protocol）

0x8037 Novell Netware IPX 0x809B EtherTalk

0x80D5 IBM SNA Services over Ethernet

0x80F 3 AppleTalk 地址解析协议（AARP ：AppleTalk Address Resolution Protocol） 0x8100 以太网自动保护开关（EAPS ：Ethernet Automatic Protection Switching） 0x8137 因特网包交换（IPX ：Internet Packet Exchange）

0x814C 简单网络管理协议（SNMP ：Simple Network Management Protocol） 0x86DD 网际协议v6 （IPv6，Internet Protocol version 6） 0x8808 pause 帧 以太网的流控(802.3x)

0x880B 点对点协议（PPP ：Point-to-Point Protocol）

0x 880C 通用交换管理协议（GSMP ：General Switch Management Protocol）

0x8847 多协议标签交换（单播） MPLS ：Multi-Protocol Label Switching ） 0x8848 多协议标签交换（组播）（MPLS, Multi-Protocol Label Switching ）

0x8863 以太网上的 PPP （发现阶段）（PPPoE ：PPP Over Ethernet ） 0x8864 以太网上的 PPP （PPP 会话阶段） （PPPoE ，PPP Over Ethernet） 0x88BB 轻量级访问点协议（LWAPP ：Light Weight Access Point Protocol） 0x88CC 链接层发现协议（LLDP ：Link Layer Discovery Protocol） 0x8E88 局域网上的 EAP （EAPOL ：EAP over LAN） 0x9000 配置测试协议（Loopback ）

0x9100 VLAN 标签协议标识符（VLAN Tag Protocol Identifier） 0x9200 VLAN 标签协议标识符（VLAN Tag Protocol Identifier） 0xFFFF 保留