路由器重温——串行链路链路层协议积累

对于广域网接口来说，主要的不同或者说主要的复杂性在于理解不同接口的物理特性以及链路层协议，再上层基本都是IP协议，基本上都是相同的。

WAN口中的serial接口主要使用点对点的链路层协议有，如PPP协议。

网络按传输方式，分为点对点传输网络、点对多点传输网络、广播式传输网络

点对点传输网络中采用的通信协议都是基于点对点通信的，如SLIP（串行线路Internet协议）、PPP（点对点协议）、PPPoE（基于以太网的点对点协议）、PPTP（点对点隧道协议）等。各种Modem拨号，以及路由器串口的连接，所使用的都是PPP或PPPOE。

在点对点传输网络中，数据是以点对点的方式（或说是“一对一”方式）在计算机或通信设备中传输的，也就是某个端口只能和与它相接、相连的对端端口进行通信，不能把数据发送到本网络的其他链路中，只能单点“联系”。点对点传输网络是由许多互相连接的节点构成的，在每对机器之间都有一条专用的通信信道，也就是说这两台机器是独占通信线路的。点对点网络中，不存在信道共享与复用的情况。

区分是哪种传输方式网络，最关键的是看它里面所用的通信协议。

数据链路层中常见的协议可分为两大类：面向字符的链路层协议和面向比特的链路层协议（这些都属于同步传输模式协议）。面向字符的链路层协议主要有IBM BSC协议、DEC DDCMP协议、SLIP协议、PPP等；面向比特的链路层协议主要有IBM SDLC、ANSI 通过修改SDLC的ADCCP、ISO通过修改SDLC的HDLC、CCITT通过修改HDLC的LAP等。

通过上一章的学习串口同异步模式配置，能够看出，在链路层协议中一般是使用同步传输模式，异步模式主要是用在外部终端通过串口登录设备进行交互用的，同步传输的速率比较快，效率高。

而这里讲到数据链路层协议分两大类，都是针对同步传输模式，关于同步，再说几句，接收端的时钟同步不是为了获得和发端完全相同的绝对时间，而是为了获得和接收到的数据对齐的时钟信息，以便能够从接收到的数据波形中正确恢复出数据。
现实中不存在绝对精确的时钟，标称值同样是1MHz，发端和接收端的时钟总会存在差异，如果接收端不进行时钟同步，而是使用自己本地的时钟，则足够长的时间后接收到的数据总会出现不可预知的重复或丢失，导致接收错误。
因此发端必须将与数据速率相关的时钟信号传输给接收端，时钟信号可以走单独的信号线，也可以用一定的方式隐含在数据信号中。接收端对此时钟信号进行同步，从而能够“不多也不少”地从接收的数据波形中恢复数据。
另外传输过程中，数据信号多少会发生一定的畸变，时钟同步的另外一个作用是保证接收端在波形畸变最少的时刻恢复数据，减少出错概率

在同步传输模式下又分为两类：一类是面向字符的，一类是面向比特的。面向字符的同步方法也称为“字符填充的首尾定界符法“。在该同步方法中，数据帧中的数据都被看做字符序列（所以称之为面向字符的同步传输），所有的控制信息也都是字符形式（当然，数据的表示形式还是二进制比特流）。所谓的面向字符，就是控制信息和数据都是某一个字符集中的字符，如都是ASCII字符集中的字符，在数据中心出现控制字符时，使用转义字符进行转义（DLE，Data link Escape数据链路封装）。因为控制字符比较多，很容易与数据中的字符冲突，导致实现起来麻烦，所以就产生了面向比特的同步传输协议。面向字符的规程也称为基本型传输控制规程。在这类规程中，用字符编码集中的几个特定字符来控制链路的操作，监视链路的工作状态，例如，采用国际5号码中的SOH、STX作为帧开始，ETX、ETB作为结束，ENQ、EOT、ACK、NAK等字符控制链路操作。面向字符型规程有一个很大的缺点，就是它与所用的字符集有密切的关系，使用不同字符集的两个站之间，很难使用该规程进行通信。面向字符型规程主要适用于中低速异步或同步传输，很适合于通过电话网的数据通信。

面向比特的同步传输协议中，数据块是作为比特流来处理的（而不是作为字符流来处理）。在面向比特的同步传输汇中，每个数据块的头部和尾部都用一个特殊的比特流（如01111110）来标记数据块的开始和结束，这就是面向比特的同步传输协议中的基本成帧原理，或者说是基本的帧同步原理。局域网中所采用的传输方式都是面向位流的同步传输方式。

SDLC属于单链路规程，HDLC属于多链路规程。所有面向比特的数据链路控制（DLC）协议均采用统一的帧格式，且不论是数据还是单独的控制信息均以帧为单位传送。

SDLC支持识别两类网络站点：主站点（Primary Station）和从站点（Secondary Station）

HDLC也采用主站点和从站点操作方式，在链路上起控制作用的站点称为主站点，其他的受主站点控制的站点称为从站点，主站点发出的帧为命令帧，从站点返回主站点的帧为响应帧。

HDLC提供了三种操作方式：正常响应方式（NRM）、异步响应方式（ARM）和异步平衡方式（ABM）。还有三种扩充方式，即扩充正常响应方式（SNRM）、扩充异步响应方式（SARM）、扩充异步平衡方式（SABM）。

地址字段表明帧是来自主站点还是来自从站点。主站点或复合站点发送的命令帧中地址字段是对方从站点的地址，而从站点发出的响应帧的地址字段是本站点的地址。地址字段通常采用8位地址格式，有效地址数是254个，00000000为空地址，11111111为广播地址。也可以扩充地址字段，采用16位，在扩充时，每个地址字段的第一位用作扩充指示，即当第一位为0时，表示后续一个字节为扩充地址字段。

控制字段，发送方主站点或复合站点利用控制字段来通知被寻址的从站点执行约定操作，而从站点用该字段对来自主站点或复合站点的命令帧进行响应，报告已完成的操作或状态的变化。

如上控制字段，根据其最前面两个比特的取值，将HDLC帧划分为三大类，即信息帧I（Information）、监控帧S（Supervisory）和无编号帧U（Unnumbered）。

最难理解的是第5位P/F（Poll/Final，查询/结束）位。在主站点发出的命令帧中取“P”位，起查询的作用，即当该位为1时，要求被查询的从站点做出响应；在从站点响应主站点的帧中取“F”位，起结束数据发送或确认结束的作用，即当该位为1时，表示从站点数据发送完毕，或者响应完毕。

信息帧（I帧）用于用户数据传输，包含信息字段。I帧控制字段2~4位为N（S），用于标志要发送的帧的序号；6~8位为N（R），用于标志期待要接收的帧序号（两层含义，一是表示发送端已确认了前N-1个帧，另一个是发送端期待发送第N帧的确认帧）。

监控帧（S帧）用于监视和控制数据链路，完成I帧的接收确认、重发请求、暂停发送请求等功能。S帧没有信息字段（一共只有48位）。S帧控制字段3、4位为S，，代表控制功能；5~8位同I帧。监控功能的S共2位，其中00——接收就绪（RR）；01——拒绝（REJ）；10——接收未就绪（RNR）；11——选择拒绝（SREJ）。

无编号帧（U帧）用于数据链路的控制，不带编号，可以在任何需要的时刻发出，而不影响带编号的信息帧的交换顺序。3、4位和6~8位均为M，代表无编号功能。U帧分为命令帧（C）和响应帧（R），通过5个M位来表示不同的功能。

信息帧（I帧）用于用户数据传输，包含信息字段。I帧控制字段2~4位为N（S），用于标志要发送的帧的序号；6~8位为N（R），用于标志期待要接收的帧序号（两层含义，一是表示发送端已确认了前N-1个帧，另一个是发送端期待发送第N帧的确认帧）。

监控帧（S帧）用于监视和控制数据链路，完成I帧的接收确认、重发请求、暂停发送请求等功能。S帧没有信息字段（一共只有48位）。S帧控制字段3、4位为S，，代表控制功能；5~8位同I帧。监控功能的S共2位，其中00——接收就绪（RR），主站点可以使用RR型S帧来查询从站点，即希望从站点传输控制字段中N（R）所指示的编号为N（R）的I帧，如果从站点存在这样的帧，便进行传输。从站点也可以用RR型S帧来作为对主站点的响应帧，表示从站点希望从主站点那里接收的下一个I帧的编号是N(R)；01——拒绝（REJ），用于接收端要求发送端从对从编号为N(R)开始的帧及其以后所有的帧进行重发，也暗示N(R)以前的I帧已被正确接收；10——接收未就绪（RNR），用于接收端通知发送端编号小于N(R)的I帧已被接收到，但目前处于忙状态，尚未准备好接收编号N(R)的I帧，可用来对链路流量进行控制；11——选择拒绝（SREJ），用于接收端要求发送端发送编号为N(R)的单个I帧，并暗示其他编号的I帧已全部确认。

无编号帧（U帧）用于数据链路的控制，不带编号，可以在任何需要的时刻发出，而不影响带编号的信息帧的交换顺序。3、4位和6~8位均为M，代表无编号功能。第5位P/F与I帧一样。U帧分为命令帧（C）和响应帧（R），通过5个M位来表示不同的功能。

以下是抓包实验结果：

HDLC具有数据帧确认反馈的机制，是确保数据信息可靠互通的重要数据链路层协议，但是随着通讯技术的进步，目前通信信道的可靠性有了非常大的改进，已经没有必要在数据链路层使用很复杂的协议（包括编号、检错重传等技术）来保证数据的可靠传输。因此，不可靠的传输协议PPP成为数据链路层的主流协议，而可靠传输的任务落到了运输层的TCP协议上。

PPP协议详解

BSC、SDLC、HDLC都属于局域网中的数据链路层协议，而PPP是一种应用非常广泛的广域网数据链路层协议。

点对点协议最早是SLIP（Serial Line Internet Protocol，串行线路网际协议）。缺点是速率低，不能自动分配IP地址，无协议类型字段，无帧校验序列字段；SLIP帧只是在IP包的最前面和最后面各增加一个END字符（0xc0）。

 PPP是一种数据链路层协议，遵循HDLC（高级数据链路控制协议）族的一般报文格式。PPP是为了在点对点物理链路(例如RS232串口链路、电话ISDN线路等)上传输OSI模型中的网络层报文而设计的，它改进了之前的一个点对点协议–SLIP协议–只能同时运行一个网络协议、无容错控制、无授权等许多缺陷，PPP是现在最流行的点对点链路控制协议。

PPP协议主要包括三部分：LCP（Link Control Protocol）链路控制协议、NCP（Network Control Protocol）网络控制协议、口令认证协议（Password Authentication Protocol，PAP）和质询握手协议（Challenge-Handshake Authentication Protocol，CHAP）和PPP的扩展协议（如Multilink Protocol）。
PPP协议默认是不进行认证配置参数选项的协商，它只作为一个可选的参数，当点对点线路的两端需要进行认证时才需配置。

LCP是PPP协议的一个子集。为了能适应复杂多变的网络环境，PPP协议提供了一种链路控制协议来配置和测试数据通信链路，它能用来协商PPP协议的一些配置参数选项；处理不同大小的数据帧；检测链路环路、一些链路的错误；终止一条链路。

网络控制协议（NCP）根据不同的网络层协议可提供一族网络控制协议，常用的有提供给TCP/IP网络使用的IPCP网络控制协议和提供给SPX/IPX网络使用的IPXCP网络控制协议等，但最为常用的是IPCP协议。当点对点的两端进行NCP参数配置协商时，主要是用来获得通信双方的网络层地址。

PPP协议格式

比较PPP与HDLC帧结构，主要区别是PPP帧结构中多了一个协议字段（用来封装的三层协议报文类型），而且PPP是面向字符的协议，HDLC是面向比特列的协议，字符填充方式也不一样。前面抓包的HDLC是思科的HDLC包，感觉其帧结构与PPP相同了，都带有protocol协议字段。

看下面的抓包

标志（flag）字段用来标志帧的起始和结束，恒为0x7E；

地址(adress)字段本来是用来标志对方节点地址的，因为PPP是点对点通信协议，是明确知道对方节点的，在实际通信中无须知道对方的数据链路层地址（即MAC），从实际通信角度考虑，此地址字段没有实际上的意义，所以恒为0xFF，标准广播地址；

所以HDLC可以用于点对点和点对多点的网络，PPP用于点对点的网络。

控制(control)字段，因为PPP本身是一种可靠的点对点数据链路层通信协议，无须像HDLC协议那样需要额外提供可靠的链路连接服务，所以PPP只有一种帧类型，就是UI（无编号信息）帧，因为他是无编号信息帧，无须接收端对收到的帧进行确认，所以恒为0x03；协议（protocol）字段是PPP与HDLC的最大区别，HDLC只封装IP报文，PPP可以封装多种网络层协议包，表示PPP报文中封装的payload（data字段）的类型，如果为0x0021，则表示PPP封装的IP报文，0x002B表示IPX报文，0x0029表示AppleTalk报文，这几种都属于PPP的数据报文；如果为0xC021则表示PPP的LCP报文（用来协商连接），如果为0x8021则表示PPP的NCP报文（用来协商封装的三层协议），这些属于PPP的控制报文。0xc023表示PAP协议认证报文，0xc223表示CHAP协议认证报文。——这里可以看出PPP上的报文主要有数据报文、控制报文和认证报文。

信息或数据（data payload）表示自上层（“网络层”）的有效数据。

我们熟知网络是分层的，且对等层之间进行相互通信，而下层为上层提供服务。当对等层进行通信时首先需获知对方的地址，而对不同的网络，在数据链路层则表现为需要知道对方的MAC地址、X.21地址、ATM地址等；在网络层则表现为需要知道对方的IP地址、IPX地址等；而在传输层则需要知道对方的协议端口号。例如如果两个以太网上的主机希望能够通信的话，首先发送端需获知对端的MAC地址。

但由于PPP协议是被运用在点对点的链路上的特殊性，它不像广播或多点访问的网络那样，需要标识通信的对方。因为点对点的链路就可以唯一标识对方，因此使用PPP协议互连的通信设备的两端无须知道对方的数据链路层地址，所以该字节已无任何意义，按照协议的规定将该字节填充为全1的广播地址。

PPP链路建立、使用和拆除流程（也可以叫做PPP协议状态机）

五个阶段，Dead（死亡）阶段、Establish（链路建立）阶段、Authentication（身份认证）阶段、Network（网络协议协商）阶段和Terminate（结束）阶段。

1、链接建立阶段，PPP使用LCP报文来协商连接（一种发送配置请求，然后接收响应的简单“握手”过程），该阶段主要是发送一些配置报文来配置数据链路，这些配置的参数不包括网络层协议所需的参数。协商中双方获得当前点对点连接的状态配置等，之后的“鉴别”阶段使用哪种鉴别方式也在这个协商中确定下来。先通过封装了LCP的PPP帧与接口进行协商，包括工作方式是SP（单PPP通信）还是MP（多PPP通信）、认证方式和最大传输单元等。

个人总结：所以在链路建立阶段前，实际上物理链路应该是建立起来的，这就是上一章中讲述的关于同步方式下串口物理属性的配置，包括串口工作模式、波特率、时钟、时钟信号翻转，DSR、DTR检测，DTD检测等，这些配置正确，系统上电，在物理电路层是可以连通的（这应该就是状态机中从静态检测到载波了），然后还要配置链路层协议，如使用PPP协议，CRC校验位、编码方式、空闲码、MTU等，这些配置好了，相当于双方可以发送PPP报文了，然后才是接下来的连接建立，即协商一些其他的参数，也就是链路的建立，其一半是手工配置（或者是设备默认的配置），一部分是协商来的，而这里所讲的链路建立阶段，就是后一半的协商过程，否则如果PPP报文都无法相互识别，何来发送LCP协议报文。当然协商也可以改变手工或默认的PPP链路层参数，如MTU、CRC等。

2、鉴别阶段是可选的，如果链接协商阶段并没有设置鉴别方式，则将忽略本阶段直接进入“网络”阶段。鉴别阶段使用链接协商阶段确定下来的鉴别方式来为连接授权，以起到保证点对点连接安全，防止非法终端接入点对点链路的功能。

链路质量的检测也会在这个阶段同时发生，但协议规定不会让链路质量的检测无限制的延迟验证过程。

常用的鉴别认证方式有CHAP和PAP方式。

3、如果鉴别阶段成功，则PPP状态机进入“网络”阶段。这个阶段主要是使用NCP报文来协商将PPP封装怎样的网络层的问题。这是可以为用户分配一个临时的网络层地址（如IP地址等）。

4、经过网络阶段后，PPP状态机进入OPEN打开状态，在这个状态下，PPP链路上的三层数据报文即可正常通信了。

5、一旦任何一端收到LCP或NCP的链路关闭报文（一般而言协议是不要求NCP有关闭链路的能力的，因此通常情况下关闭链路的数据报文是在LCP协商阶段或应用程序会话阶段发出的）、授权失败、链路质量检测失败、物理层无法检测到载波、管理人员对该链路进行关闭操作，都会将该条链路终止，从而终止PPP会话。

CHAP方式的原理是：

由一端定期发起挑战“challenge”，收到“challenge”的一端将收到的“challenge”报文中的密钥使用之前双发协商好的一种算法加密后再把结果发回发起端，这种算法应该是结果唯一（不同输入必得到不同输出）且不可逆（由输出无法得到输入）的，发起端也使用该算法计算后验证结果是否正确来为对端授权认证。

一个常用的方案实例是：发起端发送随机长度及内容的字符串加上自己的用户名作为“密钥”发送出来，接受到“challenge”的一方将收到的字符串和与对方用户名相对应的本端用户的密码使用MD5算法计算后发回，然后发起端将收到的计算结果和本端MD5计算该随机字符串加自己密码的结果相对照，如果双发一致，则认证成功。

PAP方式简单很多，原理：

直接由被验证方将自己的用户名和密码明文方式发送给对端，由对端对用户名和密码验证来决定是否认证成功。PAP身份认证可以在一方进行，即由一方认证另一方，也可以进行双向认证，也即要PAP服务器对PAP客户端进行认证，PAP客户端也需要对PAP服务器进行认证，以保证用于认证的服务器是合法的。所以，比较而言，CHAP是一种相对更安全一些的验证方式。

需要注意的是，PPP两端双方向的鉴权方式可以不同，即A端为B端鉴权时使用PAP方式（B发送自己的用户名和密码给请A认证），而同时B端使用CHAP方式为A端鉴权（B向A发起CHAP挑战），是完全可以的。

LCP协议格式

LCP位于物理层之上，负责设备之间链路的创建、维护和终止。LCP数据报文被封装在PPP信息字段中，该PPP协议字段表示类型为十六进制0xc021 (链路控制协议)。

LCP的协议结构：

8bit	8bit	16bit	变长
code	Indentifier	Length	Data

 

 

 

码域 code：长度为一个字节，主要用来标识LCP数据报文的类型。在链路建立阶段时，接收方收到LCP数据报文的代码域无法识别时，就会向对端发送一个LCP的代码拒绝报文（Code-Reject报文）。

Code域包括如下类型：

0x01——Configure-Request

0x02——Configure-Ack

0x03——Configure-Nak

0x04——Configure-Reject

0x05——Terminate-Request

0x06——Terminate-Ack

0x07——Code-Reject

0x08——Protocol-Reject

0x09——Echo-Request

0x0A——Echo-Reply

0x0B——Discard-Request

0x0C——Reserved

标识域 Indentifier：一个字节，其目的是用来匹配请求和响应报文。一般而言在进入链路建立阶段时，通信双方无论哪一端都会连续发送几个配置请求报文（Config-Request报文），而这几个请求报文的数据域Data可能是完全一样的，而仅仅是它们的标识域不同罢了。通常一个配置请求报文的ID（标识域 Indentifier）是从0x01开始逐步加1的，当对端接收到该配置请求报文后，无论使用何种报文（回应报文可能是Config-Ack、Config-Nak和Config-Reject三种报文中的一种）来回应对方，要求回应报文中的ID要与接收报文中的ID一致，当通信设备收到回应后就可以将该回应ID与发送时的ID进行比较来决定下一步的操作。

长度域 Length：两个字节长，表示总字节数（代码域 + 标志域 + 长度域 + 数据域）。长度域所指示字节数之外的字节将被当作填充字节而忽略掉，而且该域的内容不能超过MRU的值。

数据域 Data：内容根据不同的LCP数据报文的内容也是不一样的。

LCP报文详解

下面说一下LCP包括的几种报文类型，不同的报文在标识域中所填充的内容也不同。

LCP报文主要分为：

1、链路配置报文，主要用来建立和配置一条链路；

2、链路终止报文，主要用来终止一条链路；

3、链路维护报文，主要用来维护和调试链路。

链路配置报文

链路配置报文主要用来建立和配置一条链路，包括：Config-Request、Config-Ack、Config-Nak和Config-Reject四种报文。

链路配置报文与其它两类报文有着明显的区别，它主要是用来协商链路的配置参数选项的，因此这种报文的数据域还要携带许多配置参数选项的，而另外两类报文中部分报文的格式会稍有不同，下图表明了数据配置选项的报文格式：

类型域1字节长；长度域1字节，表示当前LCP配置选项的总长度（类型域 + 长度域 + 数据域）。

1、当通信双方需要建立链路时，无论哪一方都需要发送Config-Request报文并携带每一端自已所希望协商的配置参数选项。下表为可选的配置参数选项：

类型值	参数选项	类型值	参数选项
0x00	Reserved	0x05	Magic-Number
0x01	Maximum-Recieve-Unit	0x06	CBCP
0x02	Async-Control-Character-Map	0x07	Protocol-Field-Compress
0x03	Authentication-Protocol	0x08	Address-and-Control-Field-Compress
0x04	Quality-Protocol	0x0D	Multilink-Protocol

2、当接收方收到Config-Request报文时，会在剩下的三种类型的报文中选择一种来响应对方的请求报文，到底选择哪种报文来响应对方需依据以下两个条件：

A、能不能完全识别配置参数选项的类型域。我们知道一个Config-Request报文中会同时携带多个配置参数选项，而对于一个支持PPP协议的通信设备也不一定会支持上表中所有列出的配置选项，即使支持，也可能在实际应用中关闭掉某些选项功能。（例如：当使用PPP协议通信的一端可能将一些无用的配置选项都关闭了，而仅支持0x01和0x03两个配置参数选项，因此当对方发送的Config-Request报文中含有0x04配置选项时，对于本端而言这个配置参数选项就无法识别，也即是不支持这个配置参数选项的协商）。

B、如果能支持完全识别配置参数选项，能不能认可Config-Request报文中配置参数选项数据域中的内容（例如：当一端发送魔术字配置参数选项中的魔术字为全0，而对端认为应该为其它值，这种情况就属于不支持配置参数选项中的内容）。

所以依据上面的两个条件，我们就可以明确在回应对方配置请求报文时，采用何种报文回应：

A、当接收Config-Request报文的一端能识别发送过来的所有配置参数选项且认可所有配置参数选项数据域的内容时，接收端将会给对端回一个Config-Ack报文，并将配置请求报文中的配置参数选项原封不动的放置在Config-Ack报文的数据域内（根据协议的规定是不可改变配置参数选项的顺序）。当配置请求报文的发送端收到Config-Ack报后，则会从当前阶段进入到下一个阶段。

假设点对点通信的一端发送了一个Config-Request报文，报文内容如下 ：

 

当对端正确接收到了该报文后，应该发送一个Config-Ack报文，报文内容如下：

B、当接收Config-Request报文的一端B能识别发送端A所发送过来的所有配置参数选项，但对部分配置参数选项数据域中的内容不认可时，接收端B将会给对端A回应一个Config-Nak报文（注意，是能够识别，只是对部分参数内容不认可，所以不是Config-Reject报文）。该报文中只携带不认可的配置参数选项，而这些配置参数选项的数据内容为本端希望的值。然后，当A收到Config-Nak报文后，会重新发送Config-Request报文，而这个Config-Request报文与上一次所发送的Config-Request报文区别在于：那些被对端B不认可的配置参数选项的内容被填写到刚刚协商完后再次发送的Config-Request报文中（Config-Nak报文发送回来的那些配置参数选项）。

假设还是刚才的Config-Request报文：

当对端B正确接收到了该报文后，发现类型域为0x02的配置参数选项可识别，但该配置参数选项数据域的内容不认可，应发送一个Config-Nak报文且该报文中将携带希望的配置参数选项内容，报文内容如下：

当发端A收到该报文后会重新发送一个Config-Request报文，报文内容如下：

C、当接收Config-Request报文的一端B不能识别所有的发送端A发送过来的配置参数选项时，此时接收端B将会向对端A回一个Config-Reject报文，该报文中的数据域只携带那些不能识别的配置参数选项。当对端A接收到Config-Reject报文后，同样会再次发送一个Config-Request报文，这个配置请求报文与上一次发送的区别在于将不可识别的那些配置参数选项给删除了。

对于PPP的两个端点而言，两者是独立完成各自的配置参数选项的协商过程的。

链路终止报文

链路终止报文主要用来终止一条链路，分为Terminate-Request和Terminate-Reply两种报文。

LCP报文中提供了一种机制来关闭一个点对点的连接，想要关断链路的一端A会持续发送Terminate-Request报文，直到收到一个Terminate-Reply为止。接收端B一旦收到了一个Terminate-Request报文后，必须回应一个Terminate-Reply报文，同时等待对端A先将链路断开后，再完成本端的所有断开的操作。

LCP的链路终止报文的数据域与链路配置报文的数据域不一样，链路终止报文中无需携带各配置参数选项。对于链路终止报文也同样需要ID一致，当接收到Terminate-Reply报文才会做链路终止操作。

链路维护报文

除上述两种报文类型以外，剩余的所有报文类型均归属链路维护报文。

（1）当接收端发现LCP报文的代码域code是一个不合法的值时，将会向发送端回应一个Code-Reject报文，在回应报文中会将所拒绝报文的全部内容附加上(注：code只有在LCP协议头中才存在)。

（2）当接收端发现所接收到的PPP数据帧的协议域Protocol是一个不合法的值时，将会向发送端回应一个Protocol-Reject报文，发送端收到该拒绝报文后将停止发送该种协议类型的数据报文了（注：Protocol只有在PPP协议头中才存在）。

Protocol-Reject报文只能在LCP的状态机处于Opened状态时才可被处理，而在其它状态接收到该报文将被丢弃。在Protocol-Reject报文的数据域内将携带所拒绝报文的协议类型和报文内容。

（3）Echo-Request报文和Echo-Reply报文主要用来检测双向链路上自环的问题，除此之外还可附带做一些链路质量的测试和其它功能。当LCP状态机处于Opened状态时，如果接收到了Echo-Request，就需向对端回送一个Echo-Reply报文。否则在其它LCP状态下，该类型的报文会被丢弃。

这种类型数据报文的长度域后不是直接跟数据域，而是要插入4个字节的Magic-Number（魔术字），该魔术字是在LCP的Config-Request的配置参数选项协商时获得的。

魔术字

魔术字的含义，这是在链路建立过程中比较重要的一个参数，这个参数是在Config-Request里面被协商的，主要的作用是防止环路，如果在双方不协商魔术字的情况下，某些LCP的数据报文需要使用魔术字时，那么只能是将魔术字的内容填充为全0；反之，则填充为配置参数选项协商后的结果。

魔术字在目前所有的设备当中都是需要进行协商的，它被放在Config-Request的配置选项参数中进行发送，而且需要由自身的通信设备独立产生，协议为了避免双方可能产生同样的魔术字，从而导致通信出现不必要的麻烦，因此要求由设备采用一些随机方法产生一个独一无二的魔术字。一般来说魔术字的选择会采用设备的系列号、网络硬件地址或时钟。双方产生相同魔术字的可能性不能说是没有的，但应尽量避免，通常这种情况是发产在相同厂商的设备进行互连时，因为一个厂商所生产的设备产生魔术字的方法是一样的。

我们知道魔术字产生的作用是用来帮助检测链路是否存在环路，当接收端B收到一个Config-Request报文时，会将此报文与上一次所接收到（应该是上一次发送出）的Config-Request进行比较，如果两个报文中所含的魔术字不一致的话，表明链路不存在环路。但如果一致的话，接收端B认为链路可能存在环路，但不一定存在环路，还需进一步确认。此时接收端B将发送一个Config-Nak报文，并在该报文中携带一个重新产生的魔术字，而且此时在未接收到任何Config-Request或Config-Nak报文之前，接收端B也不会发送任何的Config-Request报文。这时我们假设可能会有以下两种情况发生：

1.链路实际不存在环路，而是由于对方A在产生魔术字时与接收端B产生的一致，但实际这种情况出现的概率是很小的。当Config-Nak被对端A接收到后，A应该发送一个Config-Request报文（此报文中的魔术字为接收到的Nak报文中的），当B接收到后，与上次的Config-Request比较，由于接收端B已经在上一次的Nak报文中产生了一个不同的魔术字，此时接收端B收到的Config-Request报文中的魔术字与上次B发出的Config-Request配置请求报文中不一样，所以接收端B可断定链路不存在环路。

2.链路实际上确实存在环路，一段时间后Config-Nak报文会返回到发送该报文的同一端B。这时接收端B比较这个Config-Nak报文与上一次发出去的Config-Nak报文一样，因此链路存在环路的可能性又增大了。我们知道当一端收到了一个Config-Nak报文时，又会发送一个Config-Request报文（该报文中的魔术字与Config-Nak中的一致），这样又回到了最初的状态，在这条链路上就会不断的出现Config-Request、Config-Nak报文，因此这样周而复始下去，接收端就会认为PPP链路存在环路的可能性在不断增加，当达到一定数量级时，就可认为此链路存在环路。（注意，不是第一次受到相同的魔术字就判断有环路的）

但在实际应用中根据不同设备实现PPP协议的方法，我们在链路环路检测时可采用两种方法。第一种机制就是如上面所述的，这个过程不断地重复，最终可能会给LCP状态机发一个Down事件，这时可能会使LCP的状态机又回到初始化阶段，又开始新一轮的协商。当然对于某些设备还会采用第二种机制，就是不产生任何事件去影响当前LCP的状态机，而是停留在请求发送状态。但这时认为链路有环路的一端设备需要不断的向链路上发送Echo-Request报文来检测链路环路是否被解除，当接收端收到Echo-Reply报文时，就认为链路环路被解除，从而就可能进行后续的PPP的过程。

NCP协议

NCP协议的数据报文是在网络阶段被交换的，在这个阶段所需的一些配置参数选项协商完后，就可以进行网络层的通信，也即是在点对点的链路上可以开始传送网络层的数据报文了。

NCP协议主要包括IPCP、IPXCP等，在实际当中最常遇见的也只有IPCP协议了。

IPCP控制协议

IPCP控制协议主要是负责完成IP网络层协议通信所需配置参数的选项协商，负责建立，使能和中止IP模块。IPCP在运行的过程当中，主要是完成点对点通信设备的两端动态的协商IP地址。IPCP包在PPP没有达到网络层协议阶段以前不能进行交换，如果有IPCP包在到达此阶段前到达会被抛弃。

IPCP的数据的报文同LCP的数据报文非常类似，不同之处有两点：

1、IPCP是在网络层协议阶段协商配置参数选项，Protocol字段为0x8021，而LCP协议则是在链路建立阶段协商配置参数选项的，Protocol字段为0xC021。

2、代码域字段。LCP共包括十几种报文，而IPCP只包括7种报文，但它的报文类型只是LCP数据报文的一个子集（只有LCP代码域从1到7这七种报文：Config-Request，Config-Ack，Config-Nak，Config-Reject，Terminate-Request，Terminate-Ack和Code-Reject），而且实际的数据报文交换过程中链路终止报文一般而言是不在网络协议阶段使用的。

IPCP协议类型域的值如下所示：（在PPP头中的协议字段中

）

0x01 IP-Addresses   IP地址选项配置

0x02 IP-Compression-Protocol

0x03 IP-Address   IP地址配置

IP-Addresses  0x01 ，IP地址选项配置。使用本IP地址选项配置是不好的，这在实现中已经证明了。IP地址配置(0x03)可以替换这个域， 应该使用IP地址配置0x03。如果接收到的配置请求中包括IP地址或IP地址选项，此选项不应该在配置请求中包括这个选项。只有因为IP地址选项而收到配置拒绝时，或接收到的配置未确认中包括IP地址选项作为附加选项时，才发送这一选项。

IP-Compression-Protocol  0x02，用来提供协商使用指定的压缩协议，默认不使用压缩选项。选项的格式如下：

类型（1字节）	长度（1字节）	IP压缩协议（2字节）	数据
2	》=4	要使用的压缩协议	根据协议指定的内容

 

 

 

IP压缩协议域指明要使用的压缩协议，协议编号与PPP协议域中的协议编号相同。

目前支持的协议有Van Jacobson Compressed TCP/IP[29],编号为002D(16进制)。

IP-Address 0x03，IP地址配置。IP-Address用来协商本地使用的IP地址。该选项允许请求发送者提供自己的IP地址（静态）或请求对方给自己分配IP地址（动态），在后一种情况下，请求者发送一个全为0的IP地址，对方在一个NAK数据帧中给出请求者的IP地址。

我们依据两端设备的配置选项可将IPCP的协商过程分为：“静态”和“动态”。在下面会具体描述这两个过程。

以下就具体介绍一下IPCP控制协议的静态和动态的两个过程，实际上两者的区分是在于互连设备IP地址的获取过程。

静态协商

静态协商，也即是不协商。点对点的通信设备两端在PPP协商之前已配置好了IP地址，所以就无须在网络层协议阶段协商IP地址，而双方唯一要做的就是告诉对方自身的IP地址。

在IPCP控制协议完成整个配置的过程时，最理想的情况将会看到前述的四种报文，而无其它报文再被发送。

如果当配置请求中所携带的网络层配置参数选项类似于LCP配置参数选项协商过程一样，可能会有对方不识别的配置参数选项或不被对方所认可的配置参数选项的内容。

这样在这个阶段的协商过程中可能还会看到其它的一些报文。

在静态协商时，如果IPCP的Config-Request报文中只含有地址配置参数选项时（实际中可能还会附带其它配置参数选项，这些配置参数选项的协商与LCP阶段的一样，而我们这里只提到了IP地址配置参数选项），无论是发送方还是接收方都同时发送Config-Request报文，其中配置选项中只含有各自的IP地址。

当对端收到该报文后，会发送一个Config-Ack报文，这个目的是告诉对端我已经知道了你的IP地址，对路由器而言会增加一条到对端接口的主机路由。

刚进入网络层协议阶段时，IPCP的状态机是initial的，但当完成了上述的整个过程后，IPCP的状态机改变为Opened，双方也就可以开始网络层数据网的传送了。

IPCP协议中并未规定点对点两端的IP地址必须在同一网段。当一端接收到Config-Request报文后，它从报文的配置参数选项中可获知对端的IP地址，但并不与本端的IP地址进行比较。我们也知道，一般而言点对点的两端应该是在一个网段。但如果双方的地址不在一个网段，也无条件向对方回应Config-Ack报文。

因此说点对点通信的两端如果是手动设置每一端的IP地址时，无须双方地址在同一网段。

例：

假设IPCP在网络层协议阶段开始协商配置参数选项（这里只举协商IP地址的配置参数选项地的过程），发送方设置IP地址为192.168.0.1，接收方设置IP地址为192.168.0.2，发送方发送Config-Request报文内容如下：

在这个例子中能看见明显的改变之处在于PPP协议域字段由原先的0xC021（LCP）改变为0x8021（NCP中的IPCP），下划线的部分表示本端的IP地址(192.168.0.1)。

当对端正确接收到了该报文后，应该回应一个Config-Ack报文，报文内容如下：

同样的接收方给发送方也发送一个Config-Request报文内容如下，但此时报文中IP地址配置参数选项的值为本端的IP地址（192.168.0.2）：

发送方回应一个Config-Ack报文给接收方，报文内容如下：

动态协商

动态协商是一端配置为动态获取IP地址，另一端通过手动方式配置IP地址，且允许给对端分配IP地址。

这个过程实际上可与窄带拨号上网的过程相一致，如果我们想用计算机上网，均会安装一个拨号适配器，而且计算机中的拨号网络适配器是采用动态获取IP地址的方式。

这个例子与上一个例子相似，也就是在IPCP的Config-Request报文中只携带IP地址的配置参数选项。如果是配置参数选项中含有其它配置参数选项，则可能会遇到其它的一些情况（如不识别配置参数选项的代码域或不认可配置参数选项的内容，但对于这些情况的处理方法和LCP配置参数选项的处理方法一致）。

在这种情况下，发送方连续发送了两次Config-Request报文，才能完成发送方的协商过程。而接收方仍然只需要发送一次Config-Request即可完成本端的协商过程。

由于发送方没有配置IP地址（而是动态获取IP地址），所以在IPCP的Config-Request报文的IP地址配置参数配置选项中的IP地址填充全0（也即是0.0.0.0），当接收方收到该配置请求报文后会检测IP地址的内容，如果发送为全0，则认为对端的这个IP地址不是我所希望的值，这样就回应一个Config-Nak报文，并将希望分配给对方的IP地址填充到Config-Nak报文内。这时当接收方收到Config-Nak报文后，就会重新发送一个Config-Request报文，这个报文中的IP地址配置选项为对方在Nak报文中所提供的。

接收方IP地址的配置过程与静态时的一样，只需发送一个Config-Request报文即可，当收到发送方的Config-Ack报文，就表示接收方的IP地址配置完成。

例：

假设IPCP在网络层协议阶段开始协商配置参数选项（这里只举协商IP地址的配置参数选项地的过程），发送方没有配置IP地址，而接收方配置了IP地址为192.168.0.2，接收方可给发送方分配IP地址（192.168.0.1），发送方发送给接收方的Config-Request报文内容如下：

有下划线的部分表示本端的IP地址。当接收方端正确接收到了该报文后，应该回应一个Config-Nak报文，报文内容如下：

当发送方正确收到该报文后，重新发送一个Config-Request报文，报文内容如下：

接收方再次收到发送方的一个Config-Request报文，此时将回应一个Config-Ack报文，报文内容如下：

同样的接收方给发送方也发送一个Config-Request报文，报文内容如下：

发送方回应一个Config-Ack报文给接收方，报文内容如下：

做了一个实验，如下

在AR1S4/0/0接口配置ip为192.168.1.1/24，在AR2的S3/0/0配置IP为192.168.2.1/24，结果双方能PING通，看其路由表

当PPP的NCP协商完成时，对端的IP就在路由表中存在了，并且下一跳的出口就是对应的串口。说明串口两端的IP地址不必再同一个子网中，也能互相连通。

抓包过程：

这时说明链路建立阶段已完成，因为没有配置认证，下一步进入网络阶段，

然后进入链路维持阶段