文章目录

  • 一、PPP报文格式。
  • 1.PPP报文封装的帧格式。
  • 2.LCP报文封装的帧格式。
  • 二、PPP的工作机制。
  • 1.PPP的建链过程。
  • 2.LCP协商过程。
  • 3.PAP认证和CHAP的认证过程。
  • 4.连接关闭。
  • 5.NCP的IPCP协商过程。
  • 三、PPP的配置。
  • 四、PPPoE报文格式。
  • 五、PPPoE拨号过程。
  • 1.PPPoE发现阶段。
  • 2.PPPoE会话阶段。
  • 3.PPPoE会话终结阶段。
  • 六、PPPoE的配置。


一、PPP报文格式。

HCIE数通python_HCIE数通python

1.PPP报文封装的帧格式。
  • Flag域：标识一个物理帧的起始和结束，该字节为0x7E。
  • Address域：可以唯一标识对端。PPP协议是被运用在点对点的链路上，因此，使用PPP协议互连的两个通信设备无须知道对方的数据链路层地址。按照协议的规定将该字节填充为全1的广播地址，对于PPP协议来说，该字段无实际意义。
  • Control域：


  • Protocol域：协议域可用来区分PPP数据帧中信息域所承载的数据报类型。
  • Information域最大长度是1500字节，其中包括填充域的内容。Information域的最大长度称为最大接收单元MRU（Maximum Receive Unit）。MRU的缺省值为1500字节，在实际应用当中可根据实际需要进行MRU的协商。
  • FCS域的功能主要对PPP数据帧传输的正确性进行检测。
2.LCP报文封装的帧格式。
  • Code域：主要是用来标识LCP数据报文的类型。
  • Identifier域：


  • Length域：该LCP报文的总字节数据。它是代码域、标志域、长度域和数据域四个域长度的总和。
  • Data域：



二、PPP的工作机制。

1.PPP的建链过程。

HCIE数通python_PPP_02

  • 通信双方开始建立PPP链路时，先进入到Establish阶段。
  • 在Establish阶段，PPP链路进行LCP协商。协商内容包括工作方式是SP（Single-link PPP）还是MP（Multilink PPP）、最大接收单元MRU（Maximum Receive Unit）、验证方式和魔术字（magic number）等选项。



  • 如果配置了验证，将进入Authenticate阶段，开始CHAP或PAP验证。如果没有配置验证，则直接进入Network阶段。
  • 在Authenticate阶段，如果验证失败，进入Terminate阶段，拆除链路，LCP状态转为Down。如果验证成功，进入Network阶段，此时LCP状态仍为Opened。
  • 在Network阶段，PPP链路进行NCP协商。通过NCP协商来选择和配置一个网络层协议并进行网络层参数协商。只有相应的网络层协议协商成功后，该网络层协议才可以通过这条PPP链路发送报文。
  • NCP协商成功后，PPP链路将一直保持通信。PPP运行过程中，可以随时中断连接，物理链路断开、认证失败、超时定时器时间到、管理员通过配置关闭连接等动作都可能导致链路进入Terminate阶段。
  • 在Terminate阶段，如果所有的资源都被释放，通信双方将回到Dead阶段，直到通信双方重新建立PPP连接，开始新的PPP链路建立。
2.LCP协商过程。

  在Establish阶段，PPP链路进行LCP协商。协商内容包括工作方式是SP（Single-link PPP）还MP（Multilink PPP）、最大接收单元MRU（Maximum Receive Unit）、验证方式和魔术字（magic number）等选项。LCP协商成功后进入Opened状态，表示底层链路已经建立。

（1）LCP报文类型。

  • 链路配置包，用于建立和配置链路：Configure-Request（匹配请求），Configure-Ack（匹配确认），Configure-Nak（匹配否认），和Configure-Reject（匹配拒绝）。
  • 链路结束包，用于结束一个链路：Terminate-Request（终止请求） 和 Terminate-Ack（终止确认）。
  • 链路维修包，用于管理和调试一个链路：Code-Reject（代码拒绝）, Protocol-Reject（协议拒绝）, Echo-Request（回波请求）, Echo-Reply（回波应答）, 和 Discard-Request（抛弃请求）。

（2）LCP协商的参数。

  • 链路工作模式：是采用SP还是MP。
  • 最大接收单元MRU：PPP数据帧中Information字段的总长度，使用两端设置的较小的值，默认值是1500。
  • 认证协议：认证对端使用的认证协议，被认证方必须支持认证方使用的认证协议并正确配置，否则协商不成功。
  • 魔术字Magic-Number：魔术字为一个随机产生的数字，用于检测链路环路，如果收到的LCP报文中的魔术字和本地产生的魔术字相同，则认为链路有环路。两端魔术字不同，表示链路无环路，认为协商成功；两端都支持则使用检测机制检测环路。

（3）协商过程。

  • 正常协商




  • 参数不匹配




  • 参数不识别


注意：Auth_Type不能被通过Configure-Nak、Configure-Reject报文被协商修改，即如果R1和R2在进行LCP协商过程中出现Auth_Type不一致的情况则直接回到Dead阶段。

3.PAP认证和CHAP的认证过程。

（1）PAP认证。

  • Authenticate-Request：用于被验证方发送用户名和密码，Data字段包含明文用户名和密码信息。
  • Authenticate-Ack：用于验证方发送验证成功信息，Data字段可以包含文本提示信息。
  • Authenticate-Nak：用于验证方发送验证失败信息，Data字段可以包含文本提示信息。

HCIE数通python_HCIE数通python_03


  PAP报文直接封装在PPP报文中，PAP认证协议为两次握手认证协议，密码以明文方式在链路上发送，过程如下：

  • 被认证方将配置的用户名和密码信息使用Authenticate-Request报文 以明文方式发送给认证方。
  • 认证方收到被认证方发送的用户名和密码信息之后，根据本地配置的用户名和密码数据库检查用户名和密码信息是否匹配；如果匹配，则返回Authenticate-Ack报文，表示认证成功。否则，返回Authenticate-Nak报文，表示认证失败。

（2）CHAP认证。

  • Challenge：用于验证方向被验证方发送Challenge，发起验证过程.
  • Response：用于被验证方向验证方返回用户信息，Data字段含有返回的用户名以及加密运算之后的密码信息。
  • Success：用于验证方向被验证方发送认证成功信息，Data字段可以包含文本提示信息。
  • Failure：用于验证方向被验证方发送认证失败信息，Data字段可以包含文本提示信息。

HCIE数通python_链路_04


  CHAP验证协议为三次握手验证协议。它只在网络上传输用户名，而并不传输用户密码，因此安全性要比PAP高。CHAP单向验证过程分为两种情况：验证方配置了用户名和验证方没有配置用户名。推荐使用验证方配置用户名的方式，这样可以对验证方的用户名进行确认。

  • 验证方配置了用户名的验证过程：
  • 认证方主动发起认证请求，认证方向被认证方发送Challenge报文，报文内包含随机数、用户名和ID。
  • 被认证方收到此Challenge报文之后，先检查本端接口上是否配置了ppp chap password命令，如果配置了该命令，则被验证方用报文ID、命令中配置的用户密码和随机数进行HASH/MD5运算，如果接口上未配置ppp chap password命令，则根据此报文中验证方的用户名在本端的用户表查找该用户对应的密码，用报文ID、此用户的密钥（密码）和随机数进HASH/MD5运算。
  • 运算公式为MD5{ ID＋随机数＋密码}，意思是将Identifier、随机数和密码三部分连成一个字符串，然后对此字符串MD5运算，得到一个16 Byte长的摘要信息，然后将此摘要信息和端口上配置的CHAP用户名一起封装在Response报文中发回认证方。
  • 认证方接收到被认证方发送的Response报文之后，按照其中的用户名在本地查找相应的密码信息，得到密码信息之后，进行一次加密运算，运算方式和被认证方的加密运算方式相同；然后将加密运算得到的摘要信息和Response报文中封装的摘要信息做比较，相同发送Success报文则认证成功，不相同发送Failure报文则认证失败。
  • 验证方没有配置用户名的验证过程：
  • 验证方主动发起验证请求，验证方向被验证方发送Challenge报文，报文中包含随机数和ID字段。
  • 被验证方接到验证方的验证请求后，利用报文ID、ppp chap password命令配置的CHAP密码和随机数进行HASH/MD5运算，将生产的HASH值和自己的用户名发回验证方（Response）。
  • 认证方接收到被认证方发送的Response报文之后，按照其中的用户名在本地查找相应的密码信息，得到密码信息之后，进行一次加密运算，然后将加密运算得到的摘要信息和Response报文中封装的摘要信息做比较，相同发送Success报文则认证成功，不相同发送Failure报文则认证失败。

（3）CHAP与PAP验证过程对比。

  • PAP认证中，口令以明文方式在链路上发送，完成PPP链路建立后，被验证方会不停地在链路上反复发送用户名和口令，直到身份验证过程结束，所以安全性不高。当实际应用过程中，对安全性要求不高时，可以采用PAP认证建立PPP连接。
  • CHAP认证中，验证协议为三次握手验证协议。它只在网络上传输用户名，而并不传输用户密码，因此安全性比PAP认证高。当实际应用过程中，对安全性要求较高时，可以采用CHAP认证建立PPP连接。
4.连接关闭。

HCIE数通python_链路_05

  • 认证不成功或者管理员手工关闭等原因可以使LCP关闭已经建立的连接。
  • LCP关闭连接使用Terminate-Request报文和Terminate-Ack报文，Terminate-Request报文用于请求对端关闭连接，一旦收到一个Terminate-Request报文，LCP必须回应一个Terminate-Ack报文确认连接关闭。
  • 在没有收到Terminate-Ack报文的情况下，每隔3秒重传一次Terminate-Request报文，连续两次重传没有收到Terminate-Ack报文，则认为对端不可用，连接关闭。
  • pap认证失败被认证方先发Terminate-Request报文。
  • chap认证失败认证方先发Terminate-Request报文。
5.NCP的IPCP协商过程。

  PPP认证协商后，双方进入NCP协商阶段，协商在数据链路上所传输的数据包的格式与类型。以常见的IPCP协议为例，它分为静态IP地址协商和动态IP地址协商。

（1）静态IP地址协商。

HCIE数通python_PPP_06


  静态IP地址协商需要手动在链路两端配置IP地址，静态IP地址商过程如下：

  • 每一端都要发送Configure-Request报文，在此报文中包含本地配置的IP地址；
  • 每一端接收到此Configure-Request报文之后，检查其中的IP地址，如果IP地址是一个合法的单播IP地址，而且和本地配置的IP地址不同（没有IP冲突），则认为对端可以使用该地址，回应一个Configure-Ack报文。

（2）动态IP地址协商。

HCIE数通python_HCIE数通python_07


  动态IP地址协商支持PPP链路一端为对端配置IP地址，动态协商IP地址的过程如下：

  • R1向R2发送一个Configure-Request报文，此报文中会包含一个IP地址0.0.0.0，表示向对端请求IP地址；
  • R2收到上述Configure-Request报文后，认为其中包含的地址（0.0.0.0）不合法，使用Configure-Nak回应一个新的IP地址10.1.1.1；
  • R1收到此Configure-Nak报文之后，更新本地IP地址，并重新发送一个Configure-Request报文，包含新的IP地址10.1.1.1；
  • R2收到Configure-Request报文后，认为其中包含的IP地址为合法地址，回应一个Configure-Ack报文；
  • 同时，R2也要向R1发送Configure-Request报文请求使用地址10.1.1.2，R1认为此地址合法，回应Configure-Ack报文

注：PPP链路的两个接口没有在同一个网段是可以协商成功的，因为在PPP链路上配置接口地址时会彼此为对方接口地址产生一个32位的主机路由。

三、PPP的配置。

HCIE数通python_链路_08

  • ip address ppp-negotiate命令用来为本端接口配置IP地址可协商属性，使本端接口接受PPP协商产生的由对端分配的IP地址。
  • remote address命令用来配置为对端分配IP地址或指定地址池。

四、PPPoE报文格式。

HCIE数通python_HCIE数通python_09


  PPPoE报文封装在Ethernet帧中，Ethernet中各字段解释如下：

  • DMAC：表示目的设备的MAC地址，通常为以太网单播目的地址或者以太网广播地址（0xFFFFFFFF）。
  • SMAC：表示源设备的以太网MAC地址。
  • Eth-Type：表示协议类型字段，当值为0x8863时表示承载的是PPPoE发现阶段的报文。当值为0x8864时表示承载的是PPPoE会话阶段的报文。

  PPPoE字段中的各个字段解释如下：

  • VER：表示PPPoE版本号，值为0x01。
  • Type：表示类型，值为0x01。
  • Code：表示PPPoE报文类型，不同取值标识不同的PPPoE报文类型。
  • PPPoE会话ID：与以太网SMAC和DMAC一起定义了一个PPPoE会话。
  • Length：表示PPPoE报文的长度。

五、PPPoE拨号过程。

1.PPPoE发现阶段。

  PPPoE协议发现有四个步骤：客户端发送请求、服务端响应请求、客户端确认响应和建立会话。

  • PPPoE客户端在本地以太网中广播一个PADI报文，此PADI报文中包含了客户端需要的服务信息。


  • 如果服务器端可以提供客户端请求的服务，就会回复一个PADO报文。
  • PADO报文的目的地址是发送PADI报文的客户端MAC地址，Code字段为0x07，Session ID字段为0x0000。
  • 客户端可能会收到多个PADO报文，此时将选择最先收到的PADO报文对应的PPPoE服务器端，并发送一个PADR报文给这个服务器端。
  • PADR报文的目的地址是选中的服务器端的MAC地址，Code字段为0x19，Session ID字段为0x0000。
  • PPPoE服务器端收到PADR报文后，会生成一个唯一的Session ID来标识和PPPoE客户端的会话，并发送PADS报文。
  • 会话建立成功后，PPPoE客户端和服务器端进入PPPoE会话阶段。
2.PPPoE会话阶段。

  PPPoE Session上的PPP协商和普通的PPP协商方式一致，分为LCP、认证、NCP三个阶段：

  • LCP阶段主要完成建立、配置和检测数据链路连接。
  • LCP协商成功后，开始进行认证，认证协议类型由LCP协商结果决定。
  • 认证成功后，PPP进入NCP阶段，NCP是一个协议族，用于配置不同的网络层协议，常用的是IP控制协议（IPCP），它负责配置用户的IP地址和DNS服务器地址等。

  PPPoE Session的PPP协商成功后，就可以承载PPP数据报文。在这一阶段传输的数据包中必须包含在发现阶段确定的Session ID并保持不变。

3.PPPoE会话终结阶段。
  • 当PPPoE客户端希望关闭连接时，会向PPPoE服务器端发送一个PADT报文，用于关闭连接。同样，如果PPPoE服务器端希望关闭连接时，也会向PPPoE客户端发送一个PADT报文。
  • 在PADT报文中，目的MAC地址为单播地址，Session ID为希望关闭的连接的Session ID。一旦发送或收到一个PADT报文之后，连接随即关闭，就不允许再使用该会话发送PPP流量了。

六、PPPoE的配置。

HCIE数通python_PPP_10

  • dialer-rule 1 ip permit 配置某个拨号访问组对应的拨号访问控制列表，ip permit 代表允许IPv4协议的数据报文
  • interface Dialer1 进入拨号接口
  • dialer bundle 1 指定Dialer接口使用的Dialer bundle，而Dialer bundle中指定了有哪些物理端口
  • dialer-group 1 配置接口所属的拨号访问组，按需拨号中必须确保命令dialer-group中的参数group-number和命令dialer-rule中的dialer-rule-number保持一致
  • pppoe-client dial-bundle-number 1 指定PPPoE会话所对应的Dialer bundle,自动拨号
  • pppoe-client dial-bundle-number 1 on-demand 指定PPPoE Client拨号方式为按需拨号