PPP的基本概念
PPP的基本架构
PPP协议处于TCP/IP的数据链路层,主要用在支持全双工的同异步链路上,进行点到点之间的数据传输。
图8-16 PPP在协议栈中的位置
PPP主要由以下几类协议族组成:
- 链路控制协议族,主要用来建立、拆除和监控PPP数据链路。
- 网络层控制协议族,主要用来协商在该数据链路上所传输的数据包的格式与类型。
- PPP扩展协议族,主要用于提供对PPP功能的进一步支持。例如,PPP提供了用于网络安全方面的验证协议族CHAP和PAP。
PPP报文封装的帧格式
PPP报文封装格式如图8-17所示。
图8-17 PPP报文格式
各字段的含义如下:
-
Flag域
Flag域标识一个物理帧的起始和结束,该字节为0x7E。
-
Address域
Address域可以唯一标识对端。PPP协议是被运用在点对点的链路上,因此,使用PPP协议互连的两个通信设备无须知道对方的数据链路层地址。按照协议的规定将该字节填充为全1的广播地址,对于PPP协议来说,该字段无实际意义。
-
Control域
该字段默认值为0x03,表明为无序号帧,PPP默认没有采用序列号和确认机制来实现可靠传输。
Address和Control域一起标识此报文为PPP报文,即PPP报文头为FF03。
-
Protocol域
Protocol域可用来区分PPP数据帧中信息域所承载的数据包类型。
Protocol域的内容必须依据ISO 3309的地址扩展机制所给出的规定。该机制规定协议域所填充的内容必须为奇数,也就是要求最低有效字节的最低有效位为“1”,最高有效字节的最低有效位为“0”。
如果当发送端发送的PPP数据帧的协议域字段不符合上述规定,接收端则会认为此数据帧是不可识别的。接收端向发送端发送一个Protocol-Reject报文,在该报文尾部将填充被拒绝报文的协议号。
表8-4 常见的协议代码
协议代码 协议类型 0021 Internet Protocol 002b Novell IPX 002d Van Jacobson Compressed TCP/IP 002f Van Jacobson Uncompressed TCP/IP 8021 Internet Protocol Control Protocol 802b Novell IPX Control Protocol 8031 Bridging NC C021 Link Control Protocol C023 Password Authentication Protocol C223 Challenge Handshake Authentication Protocol -
Information域
Information域最大长度是1500字节,其中包括填充域的内容。Information域的最大长度称为最大接收单元MRU(Maximum Receive Unit)。MRU的缺省值为1500字节,在实际应用当中可根据实际需要进行MRU的协商。
如果Information域长度不足,可被填充,但不是必须的。如果填充则需通信双方的两端能辨认出填充信息和真正需要传送的信息,方可正常通信。
-
FCS域
FCS域的功能主要对PPP数据帧传输的正确性进行检测。
在数据帧中引入了一些传输的保证机制,会引入更多的开销,这样可能会增加应用层交互的延迟。
LCP报文封装的帧格式
LCP报文封装格式请参见图8-17。
在链路建立阶段,PPP协议通过LCP报文进行链路的建立和协商。此时LCP报文作为PPP的净载荷被封装在PPP数据帧的Information域中,PPP数据帧的协议域的值固定填充0xC021。
在链路建立阶段的整个过程中信息域的内容是变化的,它包括很多种类型的报文,所以这些报文也要通过相应的字段来区分。
-
Code域
Code域的长度为一个字节,主要是用来标识LCP数据报文的类型。
在链路建立阶段,接收方接收到LCP数据报文。当其Code域的值无效时,就会向对端发送一个LCP的代码拒绝报文(Code-Reject报文)。
表8-5 常见code值
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 -
Identifier域
Identifier域为1个字节,用来匹配请求和响应,当Identifier域值为非法时,该报文将被丢弃。
通常一个配置请求报文的ID是从0x01开始逐步加1的。当对端接收到该配置请求报文后,无论使用何种报文回应对方,但必须要求回应报文中的ID要与接收报文中的ID一致。
-
Length域
Length域的值就是该LCP报文的总字节数据。它是Code域、Identifier域、Length域和Data域四个域长度的总和。
Length域所指示字节数之外的字节将被当作填充字节而忽略掉,而且该域的内容不能超过MRU的值。
-
Data域
Data域所包含的是协商报文的内容,这个内容包含以下字段。
- Type为协商选项类型。
- Length为协商选项长度,它是指Data域的总长度,也就是包含Type、Length和Data。
- Data为协商选项的详细信息。
表8-6 常见Type中的协商类型值
协商类型值 协商报文类型 0x01 Maximum-Receive-Unit 0x02 Async-Control-Character-Map 0x03 Authentication-Protocol 0x04 Quality-Protocol 0x05 Magic-Number 0x06 RESERVED 0x07 Protocol-Field-Compression 0x08 Address-and-Control-Field-Compression
PPP的建链过程
PPP链路的建立是通过一系列的协商完成的。
图8-18 PPP链路建立过程
PPP运行的过程如图8-18所示。
-
通信双方开始建立PPP链路时,先进入到Establish阶段。
-
在Establish阶段,PPP链路进行LCP协商。协商内容包括工作方式是SP(Single-link PPP)还是MP(Multilink PPP)、最大接收单元MRU、验证方式和魔术字(magic number)等选项。LCP协商成功后进入Open状态,表示底层链路已经建立。
-
如果配置了验证,将进入Authenticate阶段,开始CHAP或PAP验证。如果没有配置验证,则直接进入Network阶段。
-
在Authenticate阶段,如果验证失败,进入Terminate阶段,拆除链路,LCP状态转为Down。如果验证成功,进入Network阶段,此时LCP状态仍为Open。
-
在Network阶段,PPP链路进行NCP协商。通过NCP协商来选择和配置一个网络层协议并进行网络层参数协商。只有相应的网络层协议协商成功后(相应协议的NCP协商状态为Open),该网络层协议才可以通过这条PPP链路发送报文。
NCP协商包括IPCP(IP Control Protocol)、MPLSCP(MPLS Control Protocol)等协商。IPCP协商内容主要包括双方的IP地址。
-
NCP协商成功后,PPP链路将一直保持通信。PPP运行过程中,可以随时中断连接,物理链路断开、认证失败、定时器超时、管理员通过配置关闭连接等动作都可能导致链路进入Terminate阶段。
-
在Terminate阶段,如果所有的资源都被释放,通信双方将回到Dead阶段,直到通信双方重新建立PPP连接,开始新的PPP链路建立。
Dead阶段(链路不可用阶段)
Dead阶段也称为物理层不可用阶段。PPP链路都需从这个阶段开始和结束。
当通信双方的两端检测到物理线路激活(通常是检测到链路上有载波信号)时,就会从Dead阶段跃迁至Establish阶段,即链路建立阶段。
链路被断开后也同样会返回到链路不可用阶段。
Establish阶段(链路建立阶段)
在Establish阶段,PPP链路进行LCP协商。协商内容包括工作方式是SP(Single-link PPP)还是MP(Multilink PPP)、最大接收单元MRU、验证方式和魔术字(magic number)等选项。当完成配置报文的交换后,则会继续向下一个阶段跃迁。
在Establish阶段,LCP的状态机会发生如下改变。
- 当链路处于不可用阶段时,此时LCP的状态机处于初始化Initial状态或准备启动Starting状态。当检测到链路可用时,则物理层会向链路层发送一个Up事件。链路层收到该事件后,会将LCP的状态机从当前状态改变为Request-Sent(请求发送)状态,根据此时的状态机LCP会进行相应的动作,也就是开始发送Configure-Request报文来配置数据链路。
- 如果本端设备先收到Configure-Ack报文,则LCP的状态机从Request-Sent状态改变为Ack-Received状态,本端向对端发送Configure-Ack报文以后,LCP的状态机从Ack-Received状态改变为Open状态。
- 如果本端设备先向对端发送Configure-Ack报文,则LCP的状态机从Request-Sent状态改变为Ack-Sent状态,本端收到对端发送的Configure-Ack报文以后,LCP的状态机从Ack-Sent状态改变为Open状态。
- LCP状态机变为Open状态以后就完成当前阶段的协商,并向下一个阶段跃迁。
下一个阶段既可能是验证阶段,也可能是网络层协议阶段。下一阶段的选择是依据链路两端的设备配置的,通常由用户来配置。
Authenticate阶段(验证阶段)
缺省情况下,PPP链路不进行验证。如果要求验证,在链路建立阶段必须指定验证协议。
PPP提供密码验证协议PAP和质询握手验证协议CHAP两种验证方式。
PPP的验证方式又可以分为单向验证和双向验证。单向验证是指一端作为验证方,另一端作为被验证方。双向验证是单向验证的简单叠加,即两端都是既作为验证方又作为被验证方。在实际应用中一般只采用单向验证。
PAP验证过程
PAP验证方式为两次握手验证,采用简单口令。
PAP验证的过程如图8-19所示。
图8-19 PAP认证过程
- 被验证方把本地用户名和口令发送到验证方。
- 验证方根据本地用户表查看是否有被验证方的用户名
- 若有,则查看口令是否正确,
- 若口令正确,则认证通过;
- 若口令不正确,则认证失败。
- 若没有,则认证失败。
- 若有,则查看口令是否正确,
PAP验证报文帧格式
PAP报文封装在协议域为0xC023的PPP数据链路层帧的信息域中。PAP报文的帧格式如图8-20所示。
图8-20 PAP验证报文帧格式
PAP验证报文帧格式中各字段的含义如表8-7所示。
表8-7 PAP验证报文帧格式各字段解释表
字段 | 长度(字节) | 取值与含义 |
---|---|---|
Code | 1 | 标识PAP数据报的类型。Authenticate-Request报文的该字段取值为0x01。Authenticate-Ack报文的该字段取值为0x02。Authenticate-Nak报文的该字段取值为0x03。 |
Identifier | 1 | 标识请求报文和应答报文是否匹配。 |
Length | 2 | 标识包括Code、Identifier、Length和Data域在内的PAP报文长度。超出此长度的报文将被认为是填充字节并被丢弃。 |
Data | 0或者多个字节 | Data域的内容由Code域来决定。 |
CHAP验证过程
CHAP验证方式为三次握手验证协议。它只在网络上传输用户名,而并不传输用户密码,因此安全性要比PAP高。
CHAP的验证过程如图8-21所示。
图8-21 CHAP的验证过程
CHAP单向验证过程分为两种情况:验证方配置了用户名和验证方没有配置用户名。推荐使用验证方配置用户名的方式,这样可以对验证方的用户名进行确认。
- 验证方配置了用户名的验证过程
- 验证方主动发起验证请求,验证方构造一个包含随机数的报文,并同时附带本端的用户名发送给被验证方(Challenge)。
- 被验证方接到验证方的验证请求后,先检查本端接口上是否配置了CHAP密码。
- 如果接口配置CHAP密码,则被验证方根据报文ID、CHAP密码和报文中的随机数,利用hash算法计算hash值,将所得hash值和被验证方自己的用户名发回验证方(Response)。
- 如果接口未配置CHAP密码,则根据此报文中验证方的用户名在本端的用户表查找该用户对应的密码,根据报文ID、此用户密码和报文中的随机数,利用hash算法计算hash值,将所得hash值和被验证方自己的用户名发回验证方(Response)。
- 验证方根据报文ID、自己保存的被验证方密码和Challenge报文中的随机数,利用hash算法计算hash值,并与Response报文中的hash值进行比较,若比较结果一致,认证通过,若比较结果不一致,认证失败。
- 验证方没有配置用户名的验证过程
- 验证方主动发起验证请求,验证方向被验证方发送一个包含随机数的报文(Challenge)。
- 被验证方接到验证方的验证请求后,根据报文ID、ppp chap password命令配置的CHAP密码和报文中的随机数,利用hash算法计算hash值,将所得Hash值和自己的用户名发回验证方(Response)。
- 验证方根据报文ID、自己保存的被验证方密码和Challenge报文中的随机数,利用hash算法计算hash值,并与Response报文中的hash值进行比较,若比较结果一致,认证通过,若比较结果不一致,认证失败。
CHAP验证报文帧格式
CHAP报文封装在协议域为0xC223的PPP数据链路层帧的信息域中。CHAP报文的帧格式如图8-22所示。
图8-22 CHAP验证报文帧格式
CHAP验证报文帧格式中各字段的含义如表8-8所示。
表8-8 CHAP验证报文帧格式各字段解释表
字段 | 长度(字节) | 取值与含义 |
---|---|---|
Code | 1 | 标识CHAP报文的类型:Challenge报文的该字段取值为0x01。Response报文的该字段取值为0x02。Success报文的该字段取值为0x03。Failure报文的该字段取值为0x04。 |
Identifier | 1 | 标识Challenge报文和Response报文的对应关系。 |
Length | 2 | 标识包括Code、Identifier、Length和Data域在内的CHAP报文长度。超出此长度的报文将被认为是填充字节并被丢弃。 |
Data | 0或者多个字节 | Data域的内容由Code域来决定。 |
CHAP与PAP验证存在如下差异:
- PAP认证中,在链路上发送简单口令,完成PPP链路建立后,被验证方会不停地在链路上反复发送用户名和口令,直到身份验证过程结束,所以安全性不高。当实际应用过程中,对安全性要求不高时,可以采用PAP认证建立PPP连接。
- CHAP认证中,验证协议为三次握手验证协议。它只在网络上传输用户名,而并不传输用户密码,因此安全性比PAP认证高。当实际应用过程中,对安全性要求较高时,可以采用CHAP认证建立PPP连接。
Network阶段(网络层协议阶段)
PPP完成了前面几个阶段,通过NCP协商来选择和配置一个网络层协议并进行网络层参数协商。每个NCP协议可在任何时间打开和关闭,当一个NCP的状态机变成Open状态时,则PPP就可以开始在链路上承载网络层数据传输。
Terminate阶段(网络终止阶段)
PPP能在任何时候终止链路。当载波丢失、认证失败或管理员人为关闭链路等情况均会导致链路终止。
PPP的魔术字校验
产生原因
在网络中,两台设备通过中间的传输设备彼此互连。在传输的过程中,若发现两者互连关系错误,会对其互连关系进行重新调整。在调整过程中,两端的接口是无法感知的(因为接口没有Down/Up),因此不会触发LCP重协商。由于PPP协议只在LCP协商过程中才会去学习对端的主机路由,导致新互连关系的两个接口仍然学习着原互连关系的主机路由,引起传输错误。
若配置了PPP魔术字校验功能,当设备互连关系重新调整后,即使传输两端的接口未感知,也可以通过PPP的魔术字校验功能,触发LCP重新协商,重新学习对端32位主机路由。
实现原理
魔术字是由各通信设备独立产生的。为了避免产生相同的魔术字,通常会采用随机方法产生一个独一无二的魔术字。一般来说魔术字会采用设备的系列号、网络硬件地址或时钟等。
在LCP协商阶段会彼此协商魔术字,LCP阶段的后续协商过程中的ECHO报文均携带此字段,且ECHO报文中该字段值必须与协商成功时本端的值保持一致。
如图8-23所示,DeviceA、DeviceB、DeviceC与DeviceD,通过传输设备互连,且DeviceA与DeviceB、DeviceC与DeviceD之间建立PPP连接,并成功完成LCP协商。此时,发现互连关系错误,需要重新调整互连关系,在DeviceA与DeviceC之间建立PPP连接,则触发LCP重协商过程如下:
- DeviceA向DeviceC发送Echo-Request报文,且该Echo-Request报文中携带DeviceA的魔术字。
- DeviceC收到Echo-Request报文后,与其之前协商成功时对端的魔术字(DeviceD的魔术字)进行比较,结果不同,则错误计数加1。
- DeviceC向DeviceA回应Echo-Reply报文,且该Echo-Reply报文中携带DeviceC的魔术字。
- DeviceA收到DeviceC回应的Echo-Reply报文后,先与之前协商成功时自己生成的魔术字(DeviceA的魔术字)进行比较,不同后,再与之前协商成功时对端魔术字(DeviceB的魔术字)进行比较,仍然不同,再将错误计数加1。
- 重复上述过程,当错误计数累计超过一定次数后,触发LCP状态断连并重新协商。
图8-23 触发LCP重协商过程图
此时,图8-23为重连后触发LCP重新协商之前的状态,DeviceA和DeviceC中所保存在魔术字仍然是之前协商成功时所保存的本端及对端信息,只有在触发LCP重协商后,协商魔术字信息才会进行更新。
PPP协议震荡抑制
产生原因
网络应用中,由于底层物理状态不稳定、链路层配置错误等原因可能导致封装PPP协议的接口频繁的进行PPP协议协商,PPP协议链路状态频繁地交替出现Up和Down状态,造成路由协议、MPLS等反复震荡,对设备和网络产生较严重影响,甚至可能造成部分设备瘫痪,网络不可使用。
配置PPP协议震荡抑制功能对PPP链路层协议频繁Up/Down事件进行控制,使其小于一定的频率,以减小对设备及网络稳定性的影响。
实现原理
在PPP协议协商震荡抑制中,有以下几个概念:
- PPP协议协商抑制惩罚值(penalty value):PPP协议协商抑制惩罚值是根据PPP协议状态Up/Down的情况由抑制算法计算出来的一个值,其算法的核心是PPP协议协商抑制惩罚值随PPP协议状态Up/Down的次数线性增加,同时按指数衰减。
- PPP协议协商抑制门限(suppress):当PPP协议协商抑制惩罚值超过此值时,PPP协议协商将被抑制,协议状态保持Down。
- PPP协议协商重用门限(reuse):当PPP协议协商抑制惩罚值小于此值时,PPP协议协商抑制被解除,进行正常协商。
- PPP协议协商抑制惩罚值最大值(ceiling):PPP协议协商抑制惩罚值的最大值,当PPP协议协商抑制惩罚值增加到最大值时便不再增加,防止PPP协议由于长时间抑制而无法协商。ceiling=reuse×2(MaxSuppressTime/HalfLifeTime)
- PPP协议协商抑制惩罚值半衰期(half-life-period):PPP协议协商抑制惩罚值的半衰期。从PPP协议状态第一次变为Down,开始计算半衰期。如果达到半衰期,抑制惩罚值减半。一个半衰期结束后,下一个半衰期开始。
- 最长抑制时间(max-suppress-time):PPP协议被抑制后,最长抑制协议协商的时间。超过该时间后,PPP协议重新进行协商,并按照协商结果上报协议状态。
以上参数之间的关系可以用图8-24来说明。
图8-24 PPP协议协商震荡抑制示意图
PPP协议状态在t1时刻由于发生Down事件而受到惩罚,惩罚值加1000,随后接口Up信号到达,惩罚值按照半衰期法则进行指数衰减,到t2时,PPP协议状态再次发生Down事件,惩罚值加1000,达到1600,已经超出suppress值1500,PPP协议状态被抑制。由于接口持续震荡,惩罚值持续增加,tA时刻到达ceiling值10000后惩罚值不再增加。随着时间的推移,惩罚值逐渐降低,在tB时刻已下降到reuse值750,PPP协议协商抑制解除。
MP基本原理
产生原因
MP(MultiLink PPP)是出于增加带宽和可靠性的考虑,将多个PPP链路捆绑使用的技术。MP会将报文分片(小于最小分片包长时不分片)后,从MP链路下的多个PPP通道发送到PPP对端,对端将这些分片组装起来递给网络层。
实现方式
MP-Group接口是MP的专用接口,不能支持其他应用,通过将多条PPP链路加入到MP-Group可以实现MP。
协商过程
MP的协商较为特殊。MP一些选项的协商是在LCP协商过程中完成的,如最大接收重组单元MRRU(Max Receive Reconstructed Unit)、终端描述符ED(Endpoint Discriminator)等。
MP的协商包括LCP协商和NCP协商两个过程:
- LCP协商:两端首先进行LCP协商,除了协商一般的LCP参数外,还要验证对端接口是否也工作在MP方式下。如果两端工作方式不同,LCP协商不成功。
- NCP协商:根据MP-Group接口的各项NCP参数(如IP地址等)进行NCP协商,物理接口配置的NCP参数不起作用。
NCP协商通过后,即可建立MP链路。
使用价值
MP的使用价值主要有:
- 增加带宽
- 负载分担
- 链路备份
- 利用分片降低时延