PPP
![](https://images.cnblogs.com/OutliningIndicators/ContractedBlock.gif)
ethernet接口和POS接口的比较;路由器与传输设备的互联 ----------------------------------------------------------------------------------------------------------- ethernet接口和POS接口的比较 1.两者的速率都有10G/40G,但ethernet接口有100G。 2.POS接口采用ppp或hdlc的二层来封装承载IP,二层报头最长9字节,也可能是7字节。以太网封装报头固定为18字节。POS接口对IP报文的传输效率更高 3.ethernet接口的成本更低。例如10G的ethernet成本几乎只有POS接口的一半 ----------------------------------------------------------------------------------------------------------- 路由器之间存在传输设备的情况下,需要注意与传输设备的配合。 当传输设备是10G POS时,路由器可以用10G POS、10G WAN来配合; 当传输设备是10G以太时,路由器只能用10G LAN来配合; 比较新的传输设备,无论路由器侧是10G POS、10G WAN、10G LAN都可以支持,但要更换单板模块和软件配置
![](https://images.cnblogs.com/OutliningIndicators/ContractedBlock.gif)
ppp的环路现象: 比如在PPP的两端分别配置10.1.1.1/24和10.1.1.2/24 ------------------------- 比如在10.1.1.1/24端查看路由 ppp链路,在设备上查看有3条路由:10.1.1.1/24、10.1.1.1/32、10.1.1.2/32;ppp在链路建立后就学习了对端的32位IP的路由 ethernet链路,在设备上查看有2条路由:10.1.1.1/24、10.1.1.1/32 ------------------------- 在10.1.1.1/24端进行ping包测试 PPP 直接封装了ICMP报文,并且发送出去 ethernet需要先发送ARP请求解析IP的mac,没有mac根本就没发送ICMP报文
ppp的3个组件:1.数据封装方式;2.链路控制协议LCP;3.网络层控制协议NCP
![](https://images.cnblogs.com/OutliningIndicators/ContractedBlock.gif)
PPP建立过程
PPP协议主要有一下几个部分组成:链路控制协议LCP;网络控制协议NCP;认证协议,
链路控制协议LCP主要用于建立、拆除和监控PPP数据链路。
网络控制协议NCP主要用于协商在该数据链路上所传输的数据包的格式与类型。
认证协议包括密码认证协议PAP和挑战握手认证协议CHAP。认证协议用于保护数据链路的安全。
一个典型的PPP链路建立过程分为三个阶段。
阶段1:链路建立阶段
当物理层可用时,PPP首先进行LCP协商,协商内容包括工作方式是SP还是MP,验证方式,最大传输单元等。LCP协商通过后,此时LCP状态为Opened,表示链路已经建立。
阶段2:认证阶段
用户认证阶段是可选的。如果配置了用户认证,就进入认证阶段。在认证阶段可以选择PAP认证或者CHAP认证。认证通过后,进入Network协商阶段。
阶段3:网络层协议阶段
PPP完成前面的阶段后,每一个网络层协议(例如IP、IPX或者AppleTalk)必须通过各自相应的NCP分别进行协商。NCP协商支持IPCP协商,IPCP协商主要包括双方的IP地址。当一个NCP处于Opened状态时,该网络层协议就可以通过这条链路发送报文了。
这样,经过三个阶段以后,一条完整的PPP链路就建立起来了。
阶段1:链路建立阶段
![](https://images.cnblogs.com/OutliningIndicators/ContractedBlock.gif)
LCP协议报文类型;LCP协议用于协商的参数;LCP协商过程;LCP检测链路状态;LCP连接关闭 ================================================================== LCP协议---报文类型(共有3大类) 1.链路配置包,用于建立和配置链路 configure-request(匹配请求) configure-ack(匹配确认) configure-nak(匹配否认,表示request中的参数取值在本地不合法) configure-reject(匹配拒绝,表示request中的参数本地不能识别) 2.链路结束包,用于结束一条链路: terminate-request(终止请求)、terminate-ack(终止确认) 3.链路维修包,用于管理和调试一条链路: code-reject(代码拒绝)、protocol-reject(协议拒绝)、echo-request(回波请求)、echo-reply(回波应答)、discard-request(抛弃请求) -------------------------------------------- 协商内容包括工作方式(是SP还是MP)、验证方式和最大传输单元 LCP协议---用于协商的参数 最大接收单元MRU:ppp术语--------MTU最大传输单元:ethernet术语 认证协议:PAP、CHAP;默认不认证 魔术字magic-number:魔术字是一个随机产生的数字,用于检测链路环路,如果收到LCP报文中的魔术字和本地产生的魔术字相同,则认为链路有环路 收到configure-request后,将其中的魔术字与本地的魔术字进行比较,若不同,则表示链路无环路,返回configure-ack,表示魔术字协商成功。后续的报文若含有魔术字字段,则使用该协商成功的魔术字 若魔术字相同,则发送configure-nak,携带一个新的魔术字。不管新收到的configure-nak报文是否携带相同的魔术字,LCP都发送一个新的configure-request。 若有环路,持续这个过程;没有环路,协商成功 经测试:当端口均未配置认证时,lcp configure-request仅包含3个内容,ID,MRU,魔术字;configure-ack包含的内容相同 -------------------------------------------- 链路协商成功:一端发送configure-request,另一端回复configure-ack,即协商成功。但是这个协商是单向的,所以另一端也要发送configure-request,本端需要回复configure-ack。 若一直未收到对端的回复,每隔3秒时间重传一次configure-request,最多10次。 ----------------- 链路协商参数不成功:一端发送configure-request,另一端回复configure-nak;收到configure-nak后,根据configure-nak中的链路层参数重新选择本地使用的相关参数,并重发一个configure-request。连续5次协商成功将不再继续协商。 ----------------- 链路协商参数不能识别:一端发送configure-request,另一端回复configure-reject;收到configure-reject后,剔除对方不能识别的参数,重新发出configure-request。 实验现象:重发的configure-request将会收到configure-ack;然后随即发起terminate-request(终止请求)、terminate-ack(终止确认):链路关闭。 实验: 在一端修改MRU为1480,另一端使用默认的1500,协商还是成功的。。。 在认证端配置PAP认证,被认证端无配置时,将会回复configure-reject -------------------------------------------- LCP检测链路状态:LCP建立连接后,默认10秒发送一次echo-request(回波请求),收到后回复echo-reply(回波应答) 这个检测同样是单向的,所以10秒会有2组echo-request(回波请求)、echo-reply(回波应答) -------------------------------------------- LCP连接关闭:当认证不成功or管理员关闭等原因,使用terminate-request(终止请求)、terminate-ack(终止确认)。 发出一个terminate-request,必须回应terminate-ack;若没有收到terminate-ack,则每隔3秒重传一次terminate-request,最多重传2次。 也就是说一端发送terminate-request最多3次。
阶段2:认证阶段
![](https://images.cnblogs.com/OutliningIndicators/ContractedBlock.gif)
PAP认证 报文:authenticate-request,authenticate-ack,authenticate-nak 在pap认证中,认证端配置在端口的用户名密码是无效的,只使用AAA中的用户名和密码; 而被认证端,在pap中,仅使用配置在端口的用户名密码(因为根本就不支持只配置用户名,不配置密码) PAP认证为两次握手认证,口令为明文,PAP验证的过程如下: <1>PAP认证是由被认证方发起的,发出authenticate-request,明文携带用户名和密码。 <2>认证方收到报文后,到AAA中检查用户名和密码,正确则返回authenticate-ack;错误则返回authenticate-nak。 只有认证成功才会进入阶段3的协商。 PAP认证的特点是在网络上以明文的方式传递用户名及口令。如果在传输过程中被截获,便有可能对网络安全造成极大的威胁。
![](https://images.cnblogs.com/OutliningIndicators/ContractedBlock.gif)
CHAP认证 ======================================================== CHAP认证 报文:challenge(挑战报文)、response、success、failure MD5加密的原内容(Identifier+密码+challenge) Identifier不是用户名,一次认证过程使用相同的Identifier(Identifier应该不是随机数,抓包看到一次LCP建立连接后,只进行了3次CHAP认证过程,challenge分别为1.2.3) ------------------------------- CHAP认证过程(三次握手): 1.认证端发送challenge 2.被认证端回复response 3.认证端回复success/failure CHAP单向验证过程分2种情况:1.认证方配置了用户名;2.认证方没有配置用户名。(推荐使用配置用户名的方式,这样可以对验证方的用户名进行确认) 1.认证方配置了用户名的验证过程(即接口配置了ppp chap user username): 认证方主动发起验证请求challenge报文,携带了用户名和challenge(随机数) 被认证方收到challenge报文后,先查看本地端口上是否配置了ppp chap password: 若有配置,则进行MD5加密(Identifier+密码+challenge),然后回复response报文(含用户名+MD5值) 若没有配置,则根据challenge报文中的用户名在本地AAA中查找用户对应的密码,再进行MD5加密(Identifier+密码+challenge),然后回复response报文(含用户名+MD5值) 实际测试是根据配置在被认证端的用户名查找密码,在进行MD5加密的!!!!!!! 认证方收到response报文后,进行md5计算,然后进行比较MD5值 小结:优先使用端口的密码,没有再使用AAA的密码 2.认证方没有配置用户名: 认证方主动发起验证请求challenge报文,携带空的用户名和challenge(随机数) 被认证方使用端口配置的密码进行MD5加密(Identifier+密码+challenge),然后回复response报文(含用户名+MD5值) 认证方收到response报文后,进行md5计算,然后进行比较MD5值 ------------------------------- 认证方用户名和被认证方的用户名其实是没有关联的。 认证方配置了用户名,那么收到挑战报文后,被认证方优先使用接口上配置的密码;若被认证方接口不配置密码,则使用认证方的用户名去被认证方的AAA中查询密码。返回报文中携带响应的MD5字符串,被认证方的用户名 认证方没有配置用户名,那么被认证方的接口上必须配置密码。
阶段3:网络层协议阶段
![](https://images.cnblogs.com/OutliningIndicators/ContractedBlock.gif)
NCP协议 IPCP(IP control protocol)用于协商控制IP参数,使PPP可用于传输IP数据包 IPCP使用和LCP相同的协商机制、报文类型,但IPCP并非调用LCP,只是工作过程、报文等和LCP相同 两端静态配置IP地址的时候协商过程如下: R1R2都要发送configure-request报文,在此报文中包含本地配置的IP地址。 对端收到configure-request报文后,检查报文中的IP地址:如果IP地址是一个合法的单播IP地址,且和本地配置的IP地址不同(没有IP冲突),则认为对端可以使用该地址,回应一个configure-ack报文。 通过IPCP发送的信息,PPP链路的两端都可以知道对端使用的32位IP地址。 IPCP动态协商IP地址:(比如R2配置了静态IP12.1.1.2/24,且开启了给对端分配IP的能力) R1向R2发送一个configure-request报文,报文中含有IP地址0.0.0.0,该报文表示向对端请求IP地址。 R2收到configure-request报文后,认为其中包含的地址0.0.0.0不合法,使用configure-nak回应一个新的IP地址12.1.1.1 R1收到此configure-nak后,更新本地IP地址,并重新发送一个configure-request报文,包含新IP地址12.1.1.1 R2收到configure-request后,认为该IP地址合法,回应一个configure-ack报文。 同时R2也要向R1发送configure-request报文请求使用地址12.1.1.2,R1认为此地址合法,回应configure-ack报文。