PPP LCP原理

概念：

链路控制协议，简称LCP（Link Control Protocol）。它是PPP协议的一个子集，用来建立、拆除和监控PPP数据链路，完成二层协商。

LCP协议报文格式：

Code域
• 代码域的长度为一个字节，主要是用来标识LCP数据报文的类型。

Identifier域
• 标识域为1个字节，用来匹配请求和响应，当标识域值为非法时，该报文将被丢弃。
• 通常一个配置请求报文的ID是从0x01开始逐步加1的。当对端接收到该配置请求报文后，无论使用何种报文回应对方，但必须要求回应报文中的ID要与接收报文中的ID一致。例如我这端发送的是1，对方也需要回复1。

Length域
• 长度域的值就是该LCP报文的总字节数据。它是代码域、标志域、长度域和数据域四个域长度的总和（不包括FCS域和填充域）。
• 长度域所指示字节数之外的字节将被当作填充字节而忽略掉，而且该域的内容不能超过MRU的值，最大为1500字节。

Data域
• Type为协商选项类型。
• Length为协商选项长度，它是指Data域的总长度，也就是包含Type、Length和Data。
• Data为协商的选项具体内容。

LCP协议有3大类报文：

1.链路配置包，用于建立和配置链路： Configure-Request（匹配请求），Configure-Ack（匹配确认），Configure-Nak（匹配否认），和Configure-Reject（匹配拒绝）。

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

可以简单的说明一下比较重要的用于协商的参数：

认证协议：PPP和CHAP

魔术字作用：防止环路（具体步骤在最后）

config-request报文：

config-ack报文：

2.链路结束包，用于结束一个链路： Terminate-Request（终止请求） 和 Terminate-Ack（终止确认）。

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

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

Termination request报文：

Termination ACK报文：

3.链路维修包，用于管理和调试一个链路： Code-Reject（代码拒绝）, Protocol-Reject（协议拒绝）, Echo-Request（回波请求）, Echo-Reply（回波应答）, 和 Discard-Request（抛弃请求）。

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

当接收端发现所接收到的PPP数据帧的协议域Protocol是一个不合法的值时，将会向发送端回应一个Protocol-Reject报文，发送端收到该拒绝报文后将停止发送该种协议类型的数据报文了（注：Protocol只有在PPP协议头中才存在）。Protocol-Reject报文只能在LCP的状态机处于Opened状态时才可被处理，而在其它状态接收到该报文将被丢弃。在Protocol-Reject报文的数据域内将携带所拒绝报文的协议类型和报文内容。

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

Echo-request报文：

Echo-reply报文：

LCP协议具体工作流程：

场景1：链路协商成功

1.如图所示，R1和R2使用串行链路相连，运行PPP。当物理层链路变为可用状态之后，R1和R2使用LCP协商链路参数。本例中，R1首先发送一个LCP报文。
2.R1向R2发送Configure-Request报文，此报文包含在发送者（R1）上配置的链路层参数，每个链路层参数使用“类型，长度，取值”的结构表示。
3.当R2收到此Configure-Request报文之后，如果R2能识别此报文中的所有链路层参数，并且认为每个参数的取值都是可以接受的，则向R1回应一个Configure-Ack报文。
4.在没有收到Configure-Ack报文的情况下，每隔3秒重传一次Configure-Request报文，如果连续10次发送Configure-Request报文仍然没有收到Configure-Ack报文，则认为对端不可用，停止发送Configure-Request报文。

注：完成上述过程只是表明R2认为R1上的链路参数配置是可接受的。R2也需要向R1发送Configure-Request报文，使R1检测R2上的链路参数配置是不是可接受的。

场景2：链路协商参数不成功

1.当R2收到R1发送的Configure-Request报文之后，如果R2能识别此报文中携带的所有链路层参数，但是认为部分或全部参数的取值不能接受，即参数的取值协商不成功，则R2需要向R1回应一个Configure-Nak报文。
2.在这个Configure-Nak报文中，只包含不能接受的那部分链路层参数列表，每一个包含在此报文中链路层参数的取值均被修改为此报文的发送者（R2）上可以接受的取值（或取值范围）。
3. 在收到Configure-Nak报文之后，R1需要根据此报文中的链路层参数重新选择本地使用的相关参数，并重新发送一个Configure-Request，序列号需要和Nak报文中的相同。
4.连续五次协商仍然不成功的参数将被禁用，不再继续协商。

场景3：链路协商的参数不能被识别

1.当R2收到R1发送的Configure-Request报文之后，如果R2不能识别此报文中携带的部分或全部链路层参数，则R2需要向R1回应一个Configure-Reject报文。
2.在此Configure-Reject报文中，只包含不被识别的那部分链路层参数列表。
3.在收到Configure-Reject报文之后，1需要向R2重新发送一个Configure-Request报文，在新的Configure-Request报文中，不再包含不被对端（R2）识别的参数。

场景4：检测链路状态

1.LCP建立连接之后，可以使用Echo-Request报文和Echo-Reply报文检测链路状态，收到一个Echo-Request报文之后应当回应一个Echo-Reply报文，表示链路状态正常。
2.VRP平台默认每隔10秒发送一次Echo-Request报文。

场景5：LCP协议关闭连接

1.认证不成功或者管理员手工关闭等原因可以使LCP关闭已经建立的连接。
2.LCP关闭连接使用Terminate-Request报文和Terminate-Ack报文，Terminate-Request报文用于请求对端关闭连接，一旦收到一个Terminate-Request报文，LCP必须回应一个Terminate-Ack报文确认连接关闭。
3.在没有收到Terminate-Ack报文的情况下，每隔3秒重传一次Terminate-Request报文，连续两次重传没有收到Terminate-Ack报文，则认为对端不可用，连接关闭。

PPP链路防止环路具体流程：
魔术字在目前所有的设备当中都是需要进行协商的，它被放在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的过程。

参考资料：华为HCIE培训资料