|
|
<h1><center>PPP协议&PPPOE协议</center></h1>
|
|
|
|
|
|
> 作者：行癫
|
|
|
|
|
|
------
|
|
|
|
|
|
<h3>第一节：早期广域网技术概述</h3>
|
|
|
|
|
|
<h4>一：广域网技术</h4>
|
|
|
|
|
|
<h5>1.什么是广域网</h5>
|
|
|
|
|
|
广域网是连接不同地区局域网的网络，通常所覆盖的范围从几十公里到几千公里，他能连接多个地区、城市和国家，或横跨几个洲提供远距离通信，形成国际性的远程网络
|
|
|
|
|
|
<img src="https://xingdian-image.oss-cn-beijing.aliyuncs.com/xingdian-image/image-20220216094441380.png" alt="image-20220216094441380" style="zoom:50%;" />
|
|
|
|
|
|
<h5>2.广域网与局域网区别</h5>
|
|
|
|
|
|
<img src="https://xingdian-image.oss-cn-beijing.aliyuncs.com/xingdian-image/image-20220216094541854.png" alt="image-20220216094541854" style="zoom:50%;" />
|
|
|
|
|
|
局域网是一种覆盖地理区域比较小的计算机网络
|
|
|
|
|
|
广域网是一种通过租用ISP网络或者自建专用网络来构建的覆盖地理区域比较广的计算机网络
|
|
|
|
|
|
**广域网与局域网的区别主要体现在以下几个方面**
|
|
|
|
|
|
局域网带宽高但是传输距离短，无法满足广域网长距离传输
|
|
|
|
|
|
局域网设备通常是交换机，广域网设备大多都是路由器
|
|
|
|
|
|
局域网属于某一单位或者组织，广域网服务大多由ISP提供
|
|
|
|
|
|
广域网与局域网一般仅在物理层和数据链路层采用不同的协议或技术，其他层次基本没有差异
|
|
|
|
|
|
银行、政府、军队、大型公司的专用网路也属于局域网，且与Internet实现物理隔离
|
|
|
|
|
|
Internet只是广域网的一种，小企业借用Internet作为广域网连接
|
|
|
|
|
|
<h5>3.早期广域网技术介绍</h5>
|
|
|
|
|
|
早期广域网与局域网的区别在于数据链路层和物理层的差异性，在TCP/IP参考模型中，其他各层无差异
|
|
|
|
|
|
<img src="https://xingdian-image.oss-cn-beijing.aliyuncs.com/xingdian-image/image-20220216100225306.png" alt="image-20220216100225306" style="zoom:50%;" />
|
|
|
|
|
|
<h5>4.广域网络设备角色介绍</h5>
|
|
|
|
|
|
广域网络设备基本角色有三种，CE（Customer Edge 用户边缘设备）、PE（Provider Edge 服务提供商边缘设备）和P（Provider 服务提供商设备）
|
|
|
|
|
|
CE：用户端连接服务提供商的边缘设备，CE连接一个或多个PE，实现用户接入
|
|
|
|
|
|
PE：服务提供商连接CE的边缘设备，PE同时连接CE和P设备，是重要的网络节点
|
|
|
|
|
|
P：服务提供商不连接任何CE设备
|
|
|
|
|
|
<img src="https://xingdian-image.oss-cn-beijing.aliyuncs.com/xingdian-image/image-20220216100621668.png" alt="image-20220216100621668" style="zoom:50%;" />
|
|
|
|
|
|
<h5>5.早期广域网技术的应用</h5>
|
|
|
|
|
|
早期的广域网技术主要是针对不同的物理链路类型，在数据链路层进行不同的二层封装，在CE与PE之间常用的广域网封装协议有PPP/HDLC/FR等，用于解决用户接入广域网的常居鲁传输问题，在ISP内部常用的广域网协议主要是ATM，它用于解决骨干网高速转发的问题
|
|
|
|
|
|
<img src="https://xingdian-image.oss-cn-beijing.aliyuncs.com/xingdian-image/image-20220216100951320.png" alt="image-20220216100951320" style="zoom:50%;" />
|
|
|
|
|
|
<h3>第二节：PPP协议原理与配置</h3>
|
|
|
|
|
|
<h4>一：PPP协议原理</h4>
|
|
|
|
|
|
<h5>1.PPP协议概述</h5>
|
|
|
|
|
|
PPP（点到点协议）是一种常见的广域网数据链路层协议，主要用于在全双工的链路上进行点到点的数据传输封装
|
|
|
|
|
|
PPP提供了安全认证协议族PAP（密码验证协议）和CHAP（挑战握手认证协议）
|
|
|
|
|
|
PPP协议具有良好的扩展性，例如，当需要在以太网链路上承载PPP协议时，PPP可以扩展为PPPoE
|
|
|
|
|
|
PPP协议提供了LCP（链路控制协议），用于各种链路层参数的协商，例如最大接收单元、认证模式等
|
|
|
|
|
|
PPP协议提供各种NCP（网络控制协议）。如IPCP（IP控制协议），用于各种网络层参数的协商，更好地支持网络层协议
|
|
|
|
|
|
<img src="https://xingdian-image.oss-cn-beijing.aliyuncs.com/xingdian-image/image-20220216101849678.png" alt="image-20220216101849678" style="zoom:50%;" />
|
|
|
|
|
|
<h5>2.PPP链路建立流程</h5>
|
|
|
|
|
|
PPP链路的建立有三个阶段的协商过程，链路层协商、认证协商（可选）和网络层协商
|
|
|
|
|
|
链路层协商：通过LCP报文进行链路层协商，建立链路层连接
|
|
|
|
|
|
认证协商（可选）：通过链路建立阶段协商的认证方式进行链路认证
|
|
|
|
|
|
网络层协商：通过NCP协商来选择和配置一个网络层协议并进行网络层参数协商
|
|
|
|
|
|
<img src="https://xingdian-image.oss-cn-beijing.aliyuncs.com/xingdian-image/image-20220216102337987.png" alt="image-20220216102337987" style="zoom:50%;" />
|
|
|
|
|
|
<h5>3.PPP链路接口状态机</h5>
|
|
|
|
|
|
PPP协商由链路两端的接口完成，接口的状态表示了协议的协商阶段
|
|
|
|
|
|
<img src="https://xingdian-image.oss-cn-beijing.aliyuncs.com/xingdian-image/image-20220216102559769.png" alt="image-20220216102559769" style="zoom:80%;" />
|
|
|
|
|
|
通信双方开始建立PPP链路时，先进入到Establish阶段
|
|
|
|
|
|
在Establish阶段，进行LCP协商：协商通信双方的MRU（Maximum Receive Unit，最大接收单元）、认证方式和魔术字（Magic Number）等选项。协商成功后进入Opened状态，表示底层链路已建立
|
|
|
|
|
|
如果配置了认证，将进入Authenticate阶段。否则直接进入Network阶段
|
|
|
|
|
|
在Authenticate阶段，会根据连接建立阶段协商的认证方式进行链路认证。认证方式有两种：PAP和CHAP。如果认证成功，进入Network阶段，否则进入Terminate阶段，拆除链路，LCP状态转为Down
|
|
|
|
|
|
在Network阶段，PPP链路进行NCP协商。通过NCP协商来选择和配置一个网络层协议并进行网络层参数协商。最常见的NCP协议是IPCP，用来协商IP参数
|
|
|
|
|
|
在Terminate阶段，如果所有的资源都被释放，通信双方将回到Dead阶段
|
|
|
|
|
|
<h5>4.LCP报文格式</h5>
|
|
|
|
|
|
PPP报文可由Protocol字段标识不同类型的PPP报文，例如，当Protocol字段为0xC021时，代表是LCP报文，此时又由Code字段标识不同类型LCP报文
|
|
|
|
|
|
<img src="https://xingdian-image.oss-cn-beijing.aliyuncs.com/xingdian-image/image-20220216102928486.png" alt="image-20220216102928486" style="zoom:80%;" />
|
|
|
|
|
|
**PPP帧格式： **
|
|
|
|
|
|
Flag字段标识一个物理帧的起始和结束，该字节为二进制序列01111110（0X7E）
|
|
|
|
|
|
PPP帧的Address字段字节固定为11111111 （0XFF），是一个广播地址
|
|
|
|
|
|
PPP数据帧的Control字段默认为00000011（0X03），表明为无序号帧
|
|
|
|
|
|
帧校验序列（FCS）字段是个16 bit的校验和，用于检查PPP帧的完整性
|
|
|
|
|
|
Protocol字段用来说明PPP所封装的协议报文类型，0XC021代表LCP报文，0XC023代 表PAP报文，0XC223代表CHAP报
|
|
|
|
|
|
Information字段包含Protocol字段中指定协议的内容，该字段的最大长度被称为最大接收单元MRU，缺省值为1500
|
|
|
|
|
|
**LCP报文携带的一些常见的配置参数有MRU、认证协议和魔术字**
|
|
|
|
|
|
在VRP（Versatile Routing Platform，通用路由平台）平台上，MRU参数使用接口上配置的MTU（Maximum Transmission Unit，最大传输单元）值来表示
|
|
|
|
|
|
常用的PPP认证协议有PAP和CHAP，一条PPP链路的两端可以使用不同的认证协议认证对端，但是被认证方必须支持认证方要求使用的认证协议并正确配置用户名和密码等认证信息
|
|
|
|
|
|
LCP使用魔术字来检测链路环路和其他异常情况。魔术字是随机产生的一个数字，随机机制需要保证两端产生相同魔术字的可能性几乎为0
|
|
|
|
|
|
<h5>5.LCP协商过程-正常协商</h5>
|
|
|
|
|
|
LCP协商由不同的LCP报文交互完成，协商由任意一方发送Configure-Request报文发起，如果对端接收此报文且参数匹配，则通过回复Configure-Ack响应协商成功
|
|
|
|
|
|
<img src="https://xingdian-image.oss-cn-beijing.aliyuncs.com/xingdian-image/image-20220216103839475.png" alt="image-20220216103839475" style="zoom:80%;" />
|
|
|
|
|
|
R1和R2使用串行链路相连，运行PPP协议。当物理层链路变为可用状态之后，R1和R2使用LCP协商链路参数
|
|
|
|
|
|
本例中，R1首先发送一个Configure-Request报文，此报文中包含R1上配置的链路层参数。当R2收到此Configure-Request报文之后，如果R2能识别并接受此报文中的所有参数，则向R1回应一个Configure-Ack报文。同样的，R2也需要向R1发送Configure-Request报文，使R1检测R2上的参数是不是可接受的
|
|
|
|
|
|
R1在没有收到Configure-Ack报文的情况下，会每隔3秒重传一次Configure-Request报文，如果连续10次发送Configure-Request报文仍然没有收到Configure-Ack报文，则认为对端不可用，停止发送Configure-Request报文
|
|
|
|
|
|
<h5>6.LCP协商过程-参数不匹配</h5>
|
|
|
|
|
|
在LCP报文交互中出现LCP参数不匹配时，接收方回复Configure-Nak响应告知对端修改参数然后重新协商
|
|
|
|
|
|
<img src="https://xingdian-image.oss-cn-beijing.aliyuncs.com/xingdian-image/image-20220216104304430.png" alt="image-20220216104304430" style="zoom:80%;" />
|
|
|
|
|
|
当R2收到R1发送的Configure-Request报文之后，如果R2能识别此报文中携带的所有链路层参数，但是认为部分或全部参数的取值不能接受，即参数的取值协商不成功，则R2需要向R1回应一个Configure-Nak报文
|
|
|
|
|
|
在这个Configure-Nak报文中，只包含不能接受的链路层参数，并且此报文所包含的链路层参数将被修改为R2上可以接受的取值（或取值范围）
|
|
|
|
|
|
在收到Configure-Nak报文之后，R1需要根据此报文中的链路层参数重新选择本地配置的其他参数，并重新发送一个Configure-Request
|
|
|
|
|
|
<h5>7.LCP协商过程-参数不识别</h5>
|
|
|
|
|
|
在LCP报文交互中出现LCP参数不识别，接收方回复Configure-Reject响应告知对端删除不识别的参数然后重新协商
|
|
|
|
|
|
<img src="https://xingdian-image.oss-cn-beijing.aliyuncs.com/xingdian-image/image-20220216104758334.png" alt="image-20220216104758334" style="zoom:80%;" />
|
|
|
|
|
|
当R2收到R1发送的Configure-Request报文之后，如果R2不能识别此报文中携带的部分或全部链路层参数，则R2需要向R1回应一个Configure-Reject报文。在此Configure-Reject报文中，只包含不能被识别的链路层参数
|
|
|
|
|
|
在收到Configure-Reject报文之后，R1需要向R2重新发送一个Configure-Request报文，在新的Configure-Request报文中，不再包含不被对端（R2）识别的参数
|
|
|
|
|
|
<h5>8.PPP认证模式PAP</h5>
|
|
|
|
|
|
链路协商成功后，进行认证协商，认证协商有两种模式，PAP和CHAP
|
|
|
|
|
|
PAP认证双方有两次握手，协商报文以明文的形式在链路上传输
|
|
|
|
|
|
<img src="https://xingdian-image.oss-cn-beijing.aliyuncs.com/xingdian-image/image-20220216105600739.png" alt="image-20220216105600739" style="zoom:80%;" />
|
|
|
|
|
|
LCP协商完成后，认证方要求被认证方使用PAP进行认证
|
|
|
|
|
|
PAP认证协议为两次握手认证协议，密码以明文方式在链路上发送，过程如下
|
|
|
|
|
|
被认证方将配置的用户名和密码信息使用Authenticate-Request报文以明文方式发送给认证方
|
|
|
|
|
|
认证方收到被认证方发送的用户名和密码信息之后，根据本地配置的用户名和密码数据库检查用户名和密码信息是否匹配；如果匹配，则返回Authenticate-Ack报文，表示认证成功。否则，返回Authenticate-Nak报文，表示认证失败
|
|
|
|
|
|
<h5>9.PPP认证模式-CHAP</h5>
|
|
|
|
|
|
CHAP认证双方有三次握手，协商报文被加密后再在链路上传输
|
|
|
|
|
|
<img src="https://xingdian-image.oss-cn-beijing.aliyuncs.com/xingdian-image/image-20220216110540905.png" alt="image-20220216110540905" style="zoom:80%;" />
|
|
|
|
|
|
LCP协商完成后，认证方要求被认证方使用CHAP进行认证
|
|
|
|
|
|
CHAP认证过程需要三次报文的交互。过程如下：
|
|
|
|
|
|
认证方主动发起认证请求，认证方向被认证方发送Challenge报文，报文内包含随机数（Random）和ID
|
|
|
|
|
|
被认证方收到此Challenge报文之后，进行一次加密运算，运算公式为MD5{ ID＋随机数＋密码}，意思是将Identifier、随机数和密码三部分连成一个字符串，然后对此字符串做MD5运算，得到一个16 Byte长的摘要信息，然后将此摘要信息和端口上配置的CHAP用户名一起封装在Response报文中发回认证方
|
|
|
|
|
|
认证方接收到被认证方发送的Response报文之后，按照其中的用户名在本地查找相应的密码信息，得到密码信息之后，进行一次加密运算，运算方式和被认证方的加密运算方式相同；然后将加密运算得到的摘要信息和Response报文中封装的摘要信息做比较，相同则认证成功，不相同则认证失败
|
|
|
|
|
|
使用CHAP认证方式时，被认证方的密码是被加密后才进行传输的，这样就极大的提高了安全性
|
|
|
|
|
|
<h5>10.NCP协商-静态IP地址协商</h5>
|
|
|
|
|
|
PPP认证协商后，双方进入NCP协商阶段，协商在数据链路上所传输的数据包的格式与类型，以常见的IPCP协议为例，他为分静态IP地址协商和动态IP地址协商
|
|
|
|
|
|
<img src="https://xingdian-image.oss-cn-beijing.aliyuncs.com/xingdian-image/image-20220216110927492.png" alt="image-20220216110927492" style="zoom:80%;" />
|
|
|
|
|
|
NCP主要用来建立和配置不同的网络层协议，协商在该数据链路上所传输的数据包的格式与类型。常见的有IPCP等
|
|
|
|
|
|
**静态IP地址协商过程如下：**
|
|
|
|
|
|
每一端都要发送Configure-Request报文，在此报文中包含本地配置的IP地址
|
|
|
|
|
|
每一端接收到此Configure-Request报文之后，检查其中的IP地址，如果IP地址是一个合法的单播IP地址，而且和本地配置的IP地址不同（没有IP冲突），则认为对端可以使用该地址，回应一个Configure-Ack报文
|
|
|
|
|
|
<h5>11.NCP协商-动态IP地址协商</h5>
|
|
|
|
|
|
动态IP地址协商支持PPP链路一端为对端配置IP地址
|
|
|
|
|
|
<img src="https://xingdian-image.oss-cn-beijing.aliyuncs.com/xingdian-image/image-20220216111415722.png" alt="image-20220216111415722" style="zoom:80%;" />
|
|
|
|
|
|
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报文
|
|
|
|
|
|
<h4>二：PPP协议配置</h4>
|
|
|
|
|
|
<h5>1.PPP基本配置命令</h5>
|
|
|
|
|
|
|
|
|
|
|
|
<h5>2.PAP认证配置命令</h5>
|
|
|
|
|
|
|
|
|
|
|
|
<h5>3.CHAP认证配置命令</h5>
|
|
|
|
|
|
|
|
|
|
|
|
<h5>4.配置举例-PAP认证</h5>
|
|
|
|
|
|
<img src="https://xingdian-image.oss-cn-beijing.aliyuncs.com/xingdian-image/image-20220216112135703.png" alt="image-20220216112135703" style="zoom:50%;" />
|
|
|
|
|
|
**实验要求：**
|
|
|
|
|
|
在R1与R2之间的PPP链路上启用PAP认证功能
|
|
|
|
|
|
在R1配置为认证方
|
|
|
|
|
|
将R2配置为被认证方
|
|
|
|
|
|
<img src="https://xingdian-image.oss-cn-beijing.aliyuncs.com/xingdian-image/image-20220216112329613.png" alt="image-20220216112329613" style="zoom:80%;" />
|
|
|
|
|
|
<h5>5.配置举例-CHAP认证</h5>
|
|
|
|
|
|
<img src="https://xingdian-image.oss-cn-beijing.aliyuncs.com/xingdian-image/image-20220216112439701.png" alt="image-20220216112439701" style="zoom:50%;" />
|
|
|
|
|
|
**实验要求：**
|
|
|
|
|
|
在R1与R2之间的PPP链路上启用CHAP认证功能
|
|
|
|
|
|
将R1配置为认证方
|
|
|
|
|
|
将R2配置为被认证方
|
|
|
|
|
|
<img src="https://xingdian-image.oss-cn-beijing.aliyuncs.com/xingdian-image/image-20220216112608226.png" alt="image-20220216112608226" style="zoom:80%;" />
|
|
|
|
|
|
<h3>第三节：PPPoE原理与配置</h3>
|
|
|
|
|
|
<h4>一：PPPoE概述</h4>
|
|
|
|
|
|
<h5>1.什么时PPPoE</h5>
|
|
|
|
|
|
PPPoE（以太网承载PPP协议）是一种把PPP帧封装到以太网帧中的链路层协议，PPPoE可以使以太网网络中的多台主机连接到远端的宽带接入到服务器
|
|
|
|
|
|
PPPoE集中了PPP和Ethernet两个技术的优点，即有以太网的组网灵活优势，又可以利用PPP协议实现认证、计费等功能
|
|
|
|
|
|
<img src="https://xingdian-image.oss-cn-beijing.aliyuncs.com/xingdian-image/image-20220216113003768.png" alt="image-20220216113003768" style="zoom:50%;" />
|
|
|
|
|
|
<h5>2.PPPoE应用场景</h5>
|
|
|
|
|
|
PPPoE实现了在以太网上提供点到点的连接，PPPoE客户端与PPPoE服务器端之间建立会话，封装PPP数据报文，为以太网上的主机提供接入服务，实现用户控制和计费，在企业网络与运行商网络中广泛应用
|
|
|
|
|
|
PPPoE的常见应用场景有家庭用户拨号上网、企业用户拨号上网等
|
|
|
|
|
|
<img src="https://xingdian-image.oss-cn-beijing.aliyuncs.com/xingdian-image/image-20220216113228048.png" alt="image-20220216113228048" style="zoom:80%;" />
|
|
|
|
|
|
<h5>3.PPPoE会话建立</h5>
|
|
|
|
|
|
PPPoE的会话建立有三个阶段，PPPoE发现阶段、PPPoE会话阶段和PPPoE终结阶段
|
|
|
|
|
|
<img src="https://xingdian-image.oss-cn-beijing.aliyuncs.com/xingdian-image/image-20220216114905886.png" alt="image-20220216114905886" style="zoom:80%;" />
|
|
|
|
|
|
<h5>4.PPPoE报文</h5>
|
|
|
|
|
|
PPPoE会话的建立通过不同的PPPoE报文交互实现
|
|
|
|
|
|
<img src="https://xingdian-image.oss-cn-beijing.aliyuncs.com/xingdian-image/image-20220216115057158.png" alt="image-20220216115057158" style="zoom:80%;" />
|
|
|
|
|
|
DMAC：表示目的设备的MAC地址，通常为以太网单播目的地址或者以太网广播地址
|
|
|
|
|
|
SMAC：表示源设备的以太网MAC地址
|
|
|
|
|
|
Eth-Type：表示协议类型字段，当值为0x8863时表示承载的是PPPoE发现阶段的报文。当值为0x8864时表示承载的是PPPoE会话阶段的报文
|
|
|
|
|
|
VER：表示PPPoE版本号，值为0x01
|
|
|
|
|
|
Type：表示类型，值为0x01
|
|
|
|
|
|
Code：表示PPPoE报文类型，不同取值标识不同的PPPoE报文类型
|
|
|
|
|
|
PPPoE会话ID，与以太网SMAC和DMAC一起定义了一个PPPoE会话
|
|
|
|
|
|
Length：表示PPPoE报文的长度
|
|
|
|
|
|
<h5>5.PPPoE发现阶段</h5>
|
|
|
|
|
|
PPPoE协议发现有四个步骤：客户端发送请求、服务端响应请求、客户端确认响应和建立会话
|
|
|
|
|
|
<img src="https://xingdian-image.oss-cn-beijing.aliyuncs.com/xingdian-image/image-20220216115656976.png" alt="image-20220216115656976" style="zoom:80%;" />
|
|
|
|
|
|
PPPoE客户端在本地以太网中广播一个PADI报文，此PADI报文中包含了客户端需要的服务信息
|
|
|
|
|
|
PADI报文的目的MAC地址是一个广播地址，Code字段为0x09，Session ID字段为0x0000
|
|
|
|
|
|
所有PPPoE服务器端收到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报文
|
|
|
|
|
|
PADS报文的目的地址是PPPoE客户端的MAC地址，Code字段为0x65，Session ID字段是PPPoE服务器端为本PPPoE会话产生的Session ID
|
|
|
|
|
|
会话建立成功后，PPPoE客户端和服务器端进入PPPoE会话阶段
|
|
|
|
|
|
<h5>6.PPPoE会话阶段</h5>
|
|
|
|
|
|
PPPoE会话阶段会进行PPP协商，分为LCP协商、认证协商、NCP协商三个阶段
|
|
|
|
|
|
<img src="https://xingdian-image.oss-cn-beijing.aliyuncs.com/xingdian-image/image-20220216120028193.png" alt="image-20220216120028193" style="zoom:80%;" />
|
|
|
|
|
|
**PPPoE会话阶段可分为两部分：**
|
|
|
|
|
|
PPP协商阶段
|
|
|
|
|
|
PPP报文传输
|
|
|
|
|
|
**PPPoE Session上的PPP协商和普通的PPP协商方式一致，分为LCP、认证、NCP三个阶段：**
|
|
|
|
|
|
LCP阶段主要完成建立、配置和检测数据链路连接
|
|
|
|
|
|
LCP协商成功后，开始进行认证，认证协议类型由LCP协商结果决定
|
|
|
|
|
|
认证成功后，PPP进入NCP阶段，NCP是一个协议族，用于配置不同的网络层协议，常用的是IP控制协议（IPCP），它负责配置用户的IP地址和DNS服务器地址等
|
|
|
|
|
|
PPPoE Session的PPP协商成功后，就可以承载PPP数据报文。在这一阶段传输的数据包中必须包含在发现阶段确定的Session ID并保持不变
|
|
|
|
|
|
<h5>8.PPPoE会话终结阶段</h5>
|
|
|
|
|
|
当PPPoE客户端希望关闭连接时，会向PPPoE服务器端发送一个PADT报文，用于关闭连接
|
|
|
|
|
|
同样，如果PPPoE服务器端希望关闭连接时，也会向PPPoE客户端发送一个PADT报文
|
|
|
|
|
|
<img src="https://xingdian-image.oss-cn-beijing.aliyuncs.com/xingdian-image/image-20220216120430002.png" alt="image-20220216120430002" style="zoom:80%;" />
|
|
|
|
|
|
在PADT报文中，目的MAC地址为单播地址，Session ID为希望关闭的连接的Session ID。一旦收到一个PADT报文之后，连接随即关闭
|
|
|
|
|
|
<h5>二：PPPoE基础配置</h5>
|
|
|
|
|
|
<h5>1.PPPoE基础配置</h5>
|
|
|
|
|
|
|
|
|
|
|
|
<h5>2.配置实例-PPPoE客户端</h5>
|
|
|
|
|
|
<img src="https://xingdian-image.oss-cn-beijing.aliyuncs.com/xingdian-image/image-20220216120822584.png" alt="image-20220216120822584" style="zoom:80%;" />
|
|
|
|
|
|
**实验要求：**
|
|
|
|
|
|
将R1设置为PPPoE客户端，R2为PPPoE服务器端
|
|
|
|
|
|
在R1上配置PPPoE客户端拨号接口
|
|
|
|
|
|
在R1上配置PPPoE客户端拨号接口的认证功能
|
|
|
|
|
|
R1上的拨号接口获取PPPoE服务器端分配的IP地址
|
|
|
|
|
|
R1通过拨号接口可以访问服务器端
|
|
|
|
|
|
<img src="https://xingdian-image.oss-cn-beijing.aliyuncs.com/xingdian-image/image-20220216121013241.png" alt="image-20220216121013241" style="zoom:80%;" />
|
|
|
|
|
|
**PPPoE客户端配置包括三个步骤：**
|
|
|
|
|
|
第一步配置一个拨号接口
|
|
|
|
|
|
**dialer-rule**命令用于进入Dialer-rule视图，在该视图下，可以通过拨号规则来配置发起PPPoE会话的条件
|
|
|
|
|
|
**interface dialer** *number*命令用来创建并进入Dialer接口
|
|
|
|
|
|
**dialer user** *user-name*命令用于配置对端用户名，这个用户名必须与对端服务器上的PPP用户名相同
|
|
|
|
|
|
**dialer-group** *group-number*命令用来将接口置于一个拨号访问组
|
|
|
|
|
|
**dialer bundle** *number*命令用来指定Dialer接口使用的Dialer bundle。设备通过Dialer bundle将物理接口与拨号接口关联起来
|
|
|
|
|
|
注：必须确保命令**dialer-group**中的参数*group-number*和命令**dialer-rule**中的*dialer-rule-number*保持一致
|
|
|
|
|
|
第二步是在接口上将Dialer Bundle和接口绑定
|
|
|
|
|
|
**pppoe-client dial-bundle-number** *number*命令来实现Dialer Bundle和物理接口的绑定，用来指定PPPoE会话对应的Dialer Bundle，其中number是与PPPoE会话相对应的Dialer Bundle编号
|
|
|
|
|
|
第三步配置一条缺省静态路由，该路由允许在路由表中没有相应匹配表项的流量都能通过拨号接口发起PPPoE会话
|
|
|
|
|
|
<h5>3.配置实例-PPPoE服务器端</h5>
|
|
|
|
|
|
<img src="https://xingdian-image.oss-cn-beijing.aliyuncs.com/xingdian-image/image-20220216121333431.png" alt="image-20220216121333431" style="zoom:80%;" />
|
|
|
|
|
|
**实验要求：**
|
|
|
|
|
|
在PPPoE服务器端上创建为客户端分配IP地址的地址池
|
|
|
|
|
|
PPPoE服务器端完成PPPoE客户端认证并分配合法的IP地址
|
|
|
|
|
|
<img src="https://xingdian-image.oss-cn-beijing.aliyuncs.com/xingdian-image/image-20220216121440189.png" alt="image-20220216121440189" style="zoom:80%;" />
|
|
|
|
|
|
**PPPoE服务器端配置**
|
|
|
|
|
|
**interface virtual-template**命令用来创建虚拟模板接口，或者进入一个已经创建的虚拟模板接口视图
|
|
|
|
|
|
**pppoe-server bind**命令用来配置PPPoE接入用户上线绑定的虚拟模板接口
|
|
|
|
|
|
<h5>4.验证配置</h5>
|
|
|
|
|
|
**查看拨号接口详细信息**
|
|
|
|
|
|
<img src="https://xingdian-image.oss-cn-beijing.aliyuncs.com/xingdian-image/image-20220216121550850.png" alt="image-20220216121550850" style="zoom:80%;" />
|
|
|
|
|
|
**查看PPPoE-Client会话初始状态**
|
|
|
|
|
|
<img src="https://xingdian-image.oss-cn-beijing.aliyuncs.com/xingdian-image/image-20220216121617502.png" alt="image-20220216121617502" style="zoom:80%;" />
|
|
|
|
|
|
**查看PPPoE-client会话建立状态信息**
|
|
|
|
|
|
<img src="https://xingdian-image.oss-cn-beijing.aliyuncs.com/xingdian-image/image-20220216121703292.png" alt="image-20220216121703292" style="zoom:80%;" />
|
|
|
|
|
|
**注意：**
|
|
|
|
|
|
**display interface dialer**[ **number** ]命令用于查看拨号接口的配置，便于定位拨号接口的故障
|
|
|
|
|
|
LCP opened, IPCP opened表示链路的状态完全正常
|
|
|
|
|
|
**display pppoe-client session summary**命令用于查看PPPoE客户端的PPPoE会话状态和统计信息
|
|
|
|
|
|
ID表示PPPoE会话ID，Bundle ID和Dialer ID的值与拨号参数配置有关
|
|
|
|
|
|
Intf表示客户端侧协商时的物理接口
|
|
|
|
|
|
State表示PPPoE会话的状态，包括以下四种
|
|
|
|
|
|
IDLE表示当前会话状态为空闲
|
|
|
|
|
|
PADI表示PPPoE会话处于发现阶段，并已经发送PADI报文
|
|
|
|
|
|
PADR表示PPPoE会话处于发现阶段，并已经发送PADR报文
|
|
|
|
|
|
UP表示PPPoE会话建立成功
|
