61阅读

ospf协议详解-19ppp协议详解

发布时间:2017-12-18 所属栏目:arp

一 : 19ppp协议详解

资料编码

使用对象

编写部门用服工程师交换接入产品技术支援管理

部产品名称产品版本资料版本

PPP专题拟 制:

审 核:

审 核:

批 准:周一帆日 期:日 期:日 期:日 期:2002-01-05

修 订 记 录

日 期

2002/01/05修订版本v1.0作 者周一帆

描 述

深 圳 市 华 为 技 术 有 限 公 司

目 录第一章 概 述...................................................................1

1.1 PPP协议的基本概念.......................................................1

1.1.1 PPP协议出现的背景.....................................................1

1.1.1.1 SLIP协议的基本概念...............................................1

1.1.1.2 SLIP协议的封装格式...............................................1

1.1.2 PPP协议简介...........................................................2

1.2 总结....................................................................3

1.3 思考....................................................................3

第二章 PPP协议的三组件........................................................4

2.1 PPP协议的组件...........................................................4

2.1.1 PPP协议的封装.........................................................4

2.1.2 LCP协议...............................................................6

2.1.3 NCP协议...............................................................7

2.2 总结....................................................................7

2.3 思考....................................................................7

第三章 PPP链路的建立..........................................................8

3.1 PPP链路的建立过程.......................................................8

3.1.1 PPP的状态转移图.......................................................8

3.1.2 LCP协议..............................................................10

3.1.2.1 LCP数据报文的封装方式...........................................10

3.1.2.2 LCP数据报文的分类...............................................12

3.1.2.3 LCP的链路配置报文...............................................12

3.1.2.4 LCP的链路终止报文...............................................15

3.1.2.5 LCP的链路维护报文...............................................15

3.1.3 NCP协议..............................................................16

3.1.3.1 IPCP............................................................16

3.2 总结...................................................................20

3.3 思考...................................................................20

第四章 LCP的可选配置参数.....................................................21

4.1 LCP的参数配置选项.....................................................21

4.1.1 魔术字(Magic-Number)...............................................21

4.1.2 认证协议..............................................................22

4.1.2.1 PAP认证.........................................................22

4.1.2.2 CHAP认证.......................................................24

4.1.3 MRU(Maxium Receive Unit)...........................................25

4.2 总结...................................................................25

4.3 思考...................................................................26

第五章 PPP扩展协议...........................................................27

5.1 PPP扩展协议概述........................................................27

5.1.1 MP出现的背景.........................................................27

5.1.2 MP(Multilink Protocol)协议............................................27

5.2 总结...................................................................28

5.3 思考...................................................................28

第六章 PPP的状态机...........................................................29

6.1 PPP扩展协议概述........................................................29

第一章 概 述

1.1 PPP协议的基本概念

1.1.1 PPP协议出现的背景

在提及PPP协议时,不可不提及它的老祖宗SLIP(Serial Line Internet Protocol )协议。虽然它已被淡忘在历史的长河中,但毕竟有过辉煌的日子。它曾经主载了Internet半边江山,人们不仅可以通过在计算机上安装该协议实现浏览Internet的梦想,而且还可以互连许多网络设备(如路由器与路由器的互连、路由器与主机的互连和主机与主机的互连)。随着网络技术的不断日新月异,特别是计算机技术的发展,人们开始渐渐认识到使用SLIP协议已不能满足日益增长的网络需求,如何在串行点对点的链路上封装IPX、AppleTalk等网络层的协议呢?这就给我们网络专家提出了新的挑战,也为PPP协议的出现提供了契机,PPP由于自身的诸多的优点已成为目前被 广泛使用的数据链路层协议。

????说明

如果对SLIP不感举趣,可直接跳到1.1.2节

1.1.1.1 SLIP协议的基本概念

SLIP协议出现在80年代中期,并被使用在BSD UNIX主机和SUN的工作站上,因为SLIP简单好用,所以后来被大量使用在线路速率从1200bps到19.2Kbps的专用线路和拨号线路上互连主机和路由器,到目前为止仍有问大部分UNIX主机保留对该协议的支持。在80年代末90年代初期,被广泛用于家庭中每台有RS232串口的计算机和调制解调器连接到Internet。SLIP是一种在点对点的串行链路上封装IP数据报的简单协议,它并非是Internet的标准协议。

1.1.1.2 SLIP协议的封装格式

SLIP协议的封装格式必需遵循以下几条原则:

y通过在被发送IP数据报的尾部增加特殊的END字符(0xC0 )从而形成一

个简单的SLIP的数据帧,而后该帧会被传送到物理层进行发送。为了防止线路噪声被当成数据报的内容在线路上传输,通常发送端在被传送数1

据报的开始处也传一个END字符。如果线路上的确存在噪声,则该数据报起始位置的END字符将结束这份错误的报文,这样当前正确的数据报文就能正确的传送了,而前一个含有无意义报文的数据帧会在对端的高层被丢弃。

y当被传送的IP数据报文中含有END字符时,则需要对该字符进行转意

(就是使用其它字符来表示),可使用连续传输的两个字节来代替它(如0xdb和0xdc)。如果当被转意后的字符也包含在数据报中,则也需要对其进行同样的操作,直至不出现歧义为止。下图为SLIP数据帧的封

装格式:

SLIP简单封装方式的缺陷:

y从上图可以看出SLIP帧的封装格式非常简单,通信双方无需在数据报发

送前协商任何配置参数选项(在PPP协议中需协商配置参数选项),所以双方IP层通信前必需先获知对方的IP地址,才能进行网络层的通信,否则链路层发送的数据帧在被送到对方网络层时将无法进行转发。

由于数据帧中也没有类似于以太网、HDLC和PPP等数据链路层协议中定义的协议域字段,因此SLIP仅支持一种网络层协议(IP协议)同一时刻在串行链路上发送。

SLIP协议没有在数据帧的尾部加上CRC校验和,如果由于线路噪声的干扰影响传送数据包的内容是无法在对端的数据链路层中发现的,必须交由上层的应用软件来处理。yy

正是由于上面的诸多缺点,导致了SLIP很快的被后面要讲的PPP协议所替代。

1.1.2 PPP协议简介

PPP提供了一种在点对点的链路上封装多协议数据报(IP、IPX和AppleTalk)的标准方法。它不仅能支持IP地址的动态分配和管理;同步(面向位的同步数据块的传送)或异步(起始位+数据位+奇偶校验位+停止位)物理层的传输;网络层协议的复用;链路的配置、质量检测和纠错;而且还支持多种配置参数选项的协商。

PPP协议主要包括三部分:LCP(Link Control Protocol)链路控制协议、NCP(Network Control Protocol)和PPP的扩展协议(如Multilink Protocol,2

19ppp协议详解_19ppp

华为技术

1.2 总结

1.3 思考PPP专题详见第五章)。随着网络技术的不断发展,网络带宽已不在是瓶颈,所以PPP扩展协议的应用也就越来越少,因此往往人们在叙述PPP协议时经常会忘记它的存在。而且大部分网络教材上会将PPP的认证也作为PPP协议的一个主要部分,实际上这是一个错误概念的引导。PPP协议默认是不进行认证配置参数选项的协商,它只作为一个可选的参数,当点对点线路的两端需要进行认证时才需配置。当然在实际应用中这个过程是不可忽略的,例如我们使用计算机上网时,需要通过PPP协议与NAS设备互连,在整个协议的协商过程中,我们需要输入用户名和密码。因此当别人说PPP协议主要包括LCP、认证和NCP协议三个部分时,你不要认为他的说法有误,而只是不够准确罢了。yPPP协议由于自身诸多的优点取代了SLIP协议,从而成为目前被广泛使用的数据链路层协议ySLIP协议归咎其其简单数据包的封装方式,使其仅能在点对点的链路上封装单一的网络层协议(IP协议)yPPP协议包括LCP协议、NCP协议和PPP扩展协议yRFC1661文档中说明了PPP协议缺省是不进行PAP和CHAP认证

1、当SLIP协议封装的IP数据报文中存在END字符时,发送该数据帧的网络设备会对该数据报文做什么样的处理?

2、SLIP协议没有引入CRC校验机制,那么它是如何保证数据发送的正确性的?

3、PPP协议不仅可以支持同步物理层传输,而且还支持异步物理层传输,请比较一下两者的区别?

4、PPP协议和SLIP协议的区别,可从封装格式,IP地址分配等方面考虑?

第二章 PPP协议的三组件

2.1 PPP协议的组件

首先简单介绍一下PPP协议的三组件:PPP协议的封装方式、LCP协议的协商过程和NCP协议的协商过程,然后再结合具体的LCP和NCP数据报的封装格式和两个阶段实际数据报文的交换过程,进一步理解PPP的LCP和NCP协商阶段的具体内容。

2.1.1 PPP协议的封装

我们知道ISO参考模型共分七层,自下而上分别是物理层、数据链路层、网络层、传输层、会话层、表示层和应用层。通常我们会依据协议所完成的功能将它与这七层进行对照,PPP

协议就属于数据链路层协议。

我们在提及PPP协议的报文封装格式时,不可不先提一下HDLC协议。HDLC也是最常用的数据链路层协议,它是从SDLC协议衍进过来的,许多常用的数据链路层协议的封装方式都是基于HDLC的封装格式的,同样PPP协议也不例外,它也采用了HDLC的定界帧格式。下图为PPP数据帧的

封装格式:

以下为对PPP数据帧封装格式的一点说明:

y

y每一个PPP数据帧均是以一个标志字节起始和结束的,该字节为0x7E。紧接在起始标志字节后的一个字节是地址域,该字节为0xFF。我们熟知

网络是分层的,且对等层之间进行相互通信,而下层为上层提供服务。当对等层进行通信时首先需获知对方的地址,而对不同的网络,在数据链路层则表现为需要知道对方的MAC地址、X.121地址、ATM地址等;在网络层则表现为需要知道对方的IP地址、IPX地址等;而在传输层则需要知道对方的协议端口号。例如如果两个以太网上的主机希望能够通信的话,首先发送端需获知对端的MAC地址。但由于PPP协议是被运用在点对点的链路上的特殊性,它不像广播或多点访问的网络一样,因为点对点的链路就可以唯一标示对方,因此使用PPP协议互连的通信设备的两端无须知道对方的数据链路层地址,所以该字节已无任何意义,按照协议的规定将该字节填充为全1的广播地址。

同地址域一样,PPP数据帧的控制域也没有实际意义,按照协议的规定通信双方将该字节的内容填充为0x03。

就PPP协议本身而言,我们最关心的内容应该是它的协议域和信息域。协议域可用来区分PPP数据帧中信息域所承载的数据报文的内容。协议域的内容必须依据ISO 3309的地址扩展机制所给出的规定。该机制规定协议域所填充的内容必须为奇数,也即是要求低字节的最低位为”1”,高字节的最低位为”0”。如果当发送端发送的PPP数据帧的协议域字段不符合上述规定,则接收端会认为此数据帧是不可识别的,那么接收端会

yy

向发送端发送一个Protocol-Reject报文,在该报文尾部将完整地填充被拒绝的报文。协议域的具体取值如下表所示:协议域类型

0x0*** - 0x3***

ISO

0xc*** - 0xf***

0xc021

最典

型的

几种

取值0x8021

0x00210xc0230xc2230x4*** - 0x7***0x8*** - 0xb***说明信息域中承载的是网络层的数据报文信息域中承载的是与NCP

无关的低整流量信息域中承载的是网络控制协议(NCP)的数据报文信息域中承载的是链路控制协议(LCP)的数据报文信息域中承载的是链路控制协议(LCP)的数据报文信息域中承载的是PAP协议的认证报文信息域中承载的是CHAP协议的认证报文信息域中承载的是网络控制协议(NCP)的数据报文信息域中承载的是IP数据报文????说明

协议域类型中的*号表示可从(0-F)中任意取值

y信息域缺省时最大长度不能超过1500字节,其中包括填充域的内容(在

图2-1中并未表示,因为它属于信息域的一部分),1500字节大小等于PPP协议中配置参数选项MRU(Maximum Receive Unit)的缺省值,在实际应用当中可根据实际需要进行信息域最大封装长度选项的协商。信息域如果不足1500字节时可被填充,但不是必须的,如果填充则需通信双方的两端能辨认出有用与无用的信息方可正常通信。

我们通常在通信设备的配置过程中,遇到最多的也是MTU(Maximum Transmit Unit)。对于一个设备而言,它网络的层次均使用MTU和MRU两个值,一般情况下设备的MRU会比MTU稍大几个字节,但这需根据各厂商的设备而定。

yCRC校验域主要是对PPP数据帧传输的正确性进行检测的,当然在数据

帧中引入了一些传输的保证机制是好的,但可以反过来说,同样我们会引入更多的开销,这样可能会增加应用层交互的延迟,对于这个字节的使用我们可以参考一下X.25协议和FR协议就知道了。

2.1.2 LCP协议

为了能适应复杂多变的网络环境,PPP协议提供了一种链路控制协议来配置和测试数据通信链路,它能用来协商PPP协议的一些配置参数选项;处理不同大小的数据帧;检测链路环路、一些链路的错误;终止一条链路。????说明

详细内容请见3.1.2节LCP协议

2.1.3 NCP协议

PPP的网络控制协议根据不同的网络层协议可提供一族网络控制协议,常用的有提供给TCP/IP网络使用的IPCP网络控制协议和提供给SPX/IPX网络使用的IPXCP网络控制协议等,但最为常用的是IPCP协议,当点对点的两端进行NCP参数配置协商时,主要是用来通信双方的网络层地址。

????说明

详细内容请见3.1.3节NCP协议

2.2 总结

y

y

y

y

yPPP协议的三组件包括PPP协议的封装方式、LCP协议和NCP协议PPP协议是数据链路层协议,它的数据帧封装格式非常类似于HDLCPPP协议可通过协议域来区分数据域中净载荷的数据类型PPP协议通过LCP协议完成数据链路的配置和测试PPP协议通过NCP协议完成点对点通信设备之间网络层通信所需参数的

配置

2.3 思考

1、PPP数据帧中的地址域被填充为0xFF(广播地址),在实际应用当中该域已没有任何意义,请想一下为什么使用PPP协议通信的设备不需要类似于以太网的数据链路层寻址机制?

2、PPP协议数据域缺省的最大值是多少?

19ppp协议详解_19ppp

3、当发送端发送的PPP数据帧的协议域不被接收方识别时,接收方将如何处理这个数据帧?

4、IPCP协议的主要功能?

第三章 PPP链路的建立

3.1 PPP链路的建立过程

3.1.1 PPP的状态转移图

数据通信设备(在本文中指路由器)的两端如果希望通过PPP协议建立点对点的通信,无论哪一端的设备都需发送LCP数据报文来配置链路(测试链路)。一旦LCP的配置参数选项协商完后,通信的双方就会根据LCP配置请求报文中所协商的认证配置参数选项来决定链路两端设备所采用的认证方式。协议缺省情况下双方是不进行认证的,而直接进入到NCP配置参数选项的协商,直至所经历的几个配置过程全部完成后,点对点的双方就可以开始通过已建立好的链路进行网络层数据报文的传送了,整个链路就处于可用状态。只有当任何一端收到LCP或NCP的链路关闭报文时(一般而言协议是不要求NCP有关闭链路的能力的,因此通过情况下关闭链路的数据报文是在LCP协商阶段或应用程序会话阶段发出的);物理层无法检测到载波或管理人员对该链路进行关闭操作,都会将该条链路断开,从而终止PPP会话。以下为PPP

协议整个链路过程需经历阶段的状态转移图:

在点对点链路的配置、维护和终止过程中,PPP需经历以下几个阶段:

y链路不可用阶段,有时也称为物理层不可用阶段,PPP链路都需从这个

阶段开始和结束。当通信双方的两端检测到物理线路激活(通常时检测到链路上有载波信号)时,就会从当前这个阶段跃迁至下一个阶段(即链路建立阶段)。先简单提一下链路建立阶段,在这个阶段主要是通过LCP协议进行链路参数的配置,LCP在此阶段的状态机也会根据不同的

事件发生变化。当处于在链路不可用阶段时,LCP的状态机是处于initial(初始化状态)或starting(准备启动状态),一旦检测到物理线路可用,则LCP的状态机就要发生改变。当然链路被断开后也同样会返回到这个阶段,往往在实际过程中这个阶段所停留的时间是很短的,仅仅是检测到对方设备的存在。

y链路建立阶段,也是PPP协议最关键和最复杂的阶段。该阶段主要是发

送一些配置报文来配置数据链路,这些配置的参数不包括网络层协议所需的参数。当完成数据报文的交换后,则会继续向下一个阶段跃迁,该下一个阶段既可是验证阶段,也可是网络层协议阶段,下一阶段的选择是依据链路两端的设备配置的(通常是由用户来配置,但对NAS或BAS设备的PPP模块缺省就需要支持PAP或CHAP中的一种认证方式)。在此阶段LCP的状态机会发生两次改变,前面我们说了当链路处于不可用阶段时,此时LCP的状态机处于initial或starting,当检测到链路可用时,则物理层会向链路层发送一个UP事件,链路层收到该事件后,会将LCP的状态机从当前状态改变为Request-Sent(请求发送状态),根据此时的状态机LCP会进行相应的动作,也即是开始发送Config-Request报文来配置数据链路,无论哪一端接收到了Config-Ack报文时,LCP的状态机又要发生改变,从当前状态改变为opened状态,进入Opened状态后收到Config-Ack报文的一方则完成了当前阶段,应该向下一个阶段跃迁。同理可知,另一端也是一样的,但须注意的一点是在链路配置阶段双方是链路配置操作过程是相互独立的。如果在该阶段收到了非LCP数据报文,则会的将这些报文丢弃。在实际配置当中在该阶段可能会遇到很多情况,在LCP协议章节中会详细介绍可能遇到的情况,但最好结合一些troubleshooting案例能更好的帮助理解。

验证阶段,多数情况下的链路两端设备是需要经过认证后才进入到网络层协议阶段,缺省情况下链路两端的设备是不进行认证的。在该阶段支持PAP和CHAP两种认证方式,验证方式的选择是依据在链路建立阶段双方进行协商的结果。然而,链路质量的检测也会在这个阶段同时发生,但协议规定不会让链路质量的检测无限制的延迟验证过程。在这个阶段仅支持链路控制协议、验证协议和质量检测数据报文,其它的数据报文都会被丢弃。如果在这个阶段再次收到了Config-Request报文,则又会返回到链路建立阶段。

网络层协议阶段,一旦PPP完成了前面几个阶段,每种网络层协议(IP、IPX和AppleTalk)会通过各自相应的网络控制协议进行配置,每个NCP协议可在任何时间打开和关闭。当一个NCP的状态机变成Opened状态时,则PPP就可以开始在链路上承载网络层的数据包报文了。如果在个阶段收到了Config-Request报文,则又会返回到链路建立阶段。网络终止阶段,PPP能在任何时候终止链路。当载波丢失、授权失败、链路质量检测失败和管理员人为关闭链路等情况均会导致链路终止。链yyy

路建立阶段可能通过交换LCP的链路终止报文来关闭链路,当链路关闭时,链路层会通知网络层做相应的操作,而且也会通过物理层强制关断链路。对于NCP协议,它是没有也没有必要去关闭PPP链路的。

3.1.2 LCP协议

3.1.2.1 LCP数据报文的封装方式

LCP数据报文是在链路建立阶段被交换的,它作为PPP的净载荷被封装在PPP数据帧的信息域中,此时PPP数据帧的协议域固定填充0xC021,但在链路建立阶段的整个过程中信息域的内容是在变化的,它包括很多种类型的报文,所以这些报文也要通过相应的字段来区分。LCP数据报文的一般封装方

式如下图所示:

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

链路建立阶段时,接收方收到LCP数据报文的代码域无法识别时,就会向对端发送一个LCP的代码拒绝报文(Code-Reject报文)。根据RFC的规定,到目前为止LCP共包括以下几种类型的数据报文:代码值

0x01

0x02

0x03

0x040x05

0x06报文类型Config-RequestConfig-AckConfig-NakConfig-RejectTerminate-RequestTerminate-Ack代码0x070x080x090x0A0x0B0x0C报文类型Code-RejectProtocol-RejectEcho-RequestEcho-ReplyDiscard-RequestReserved

y标识域也是一个字节,其目的是用来匹配请求和响应报文。一般而言在

进入链路建立阶段时,通信双方无论哪一端都会连续发送几个配置请求报文(Config-Request报文),而这几个请求报文的数据域可能是完全一

样的,而仅仅是它们的标志域不同罢了。通常一个配置请求报文的ID是从0x01开始逐步加1的,当对端接收到该配置请求报文后,无论使用何种报文(回应报文可能是Config-Ack、Config-Nak和Config-Reject三种报文中的一种)来回应对方,但必须要求回应报文中的ID要与接收报文中的ID一致,当通信设备收到回应后就可以将该回应与发送时的进行比较来决定下一步的操作。

????说明

后面教材中的所有例子,均可参考以下色标的含义

范例中报文色标含义如下图所示:

例1:假设点对点通信的一端发送了一个Config-Request报文,报文内容如下:

7E FF 03 C0 21 01 01 00 17 02 06 00 0A 00 00 05 06 00 0B 42 CB 07 02 08 02 0D 03 06 7E从报文中可以看出这个配置请求报文包括5个配置参数选项。

当对端正确接收到了该报文后,应该回应一个Config-Ack报文,报文内容如下:

19ppp协议详解_19ppp

华为技术PPP专题

7E FF 03 C0 21 02 01 00 17 02 06 00 0A 00 00 05 06 00 0B 42 CB 07 02 08 02 0D 03 06 7E该报文中唯一修改的内容就是代码域(02表示是Config-Ack报文),标识域与原报文中的一样。

y长度域的内容 = 总字节数据(代码域+标志域+长度域+数据域)。长度

域所指示字节数之外的字节将被当作填充字节而忽略掉,而且该域的内容不能超过MRU的值。

数据域的内容依据不同LCP数据报文的内容也是不一样的。y

????说明

数据域的详细内容请见3.1.2.3节

3.1.2.2 LCP数据报文的分类

在前一小节我们可以看到,一共包括12种LCP数据报文,我们依据各报文的的功能又将其具体细化为以下三类:

y

y

y链路配置报文,主要用来建立和配置一条链路的。链路终止报文,主要用来终止一条链路的。链路维护报文,主要用来维护和调试链路的。

3.1.2.3 LCP的链路配置报文

链路配置报文与其它两类报文有着明显的区别,它主要是用来协商链路的配置参数选项的,因此这种报文的数据域还要携带许多配置参数选项的,而另外两类报文中部分报文的格式会稍有不同(请参见RFC1661),图3-4表明了

数据配置选项的报文格式:

链路配置报文主要包括Config-Request、Config-Ack、Config-Nak和Config-Reject四种报文。

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

0x00

0x01

0x02

0x03

0x04参数选项ReservedMaximum-Recieve-UnitAsync-Control-Character-MapAuthentication-ProtocolQuality-Protocol类型值0x050x060x070x080x0D参数选项Magic-NumberCBCPProtocol-Field-CompressAddress-and-Control-Field-CompressMultilink-Protocol

这个表格内的内容并非完全,可能还有一新定议的配置选项未列在其中,如有兴趣可参照相关的文档说明。

当接收方收到Config-Request报文时,会在剩下的三种类型的报文中选择一种来响应对方的请求报文,到底选择哪种报文来响应对方需依据以下两个条件:

y不能完全识别配置参数选项的类型域,我们知道一个Config-Request报文

中会同时携带多个配置参数选项,而对于一个支持PPP协议的通信设备也不一定会支持上表中所有列出的配置选项,即使支持,也可能在实际应用中关闭掉某些选项功能。(例如:当使用PPP协议通信的一端可能将一些无用的配置选项都关闭了,而仅支持0x01

和0x03两个配置参数选项,因此当对方发送的Config-Request报文中含有0x04配置选项时,对于本端而言这个配置参数选项就无法识别,也即是不支持这个配置参数选项的协商)。

如果能支持完全识别配置参数选项,但接收端也可能不认可Config-Request报文中配置参数选项数据域中的内容(例如:当一端发送魔术字配置参数选项中的魔术字为全0,而对端认为应该为其它值,这种情况就属于不支持配置参数选项中的内容)。y

所以依据上面的两个条件,我们就可以明确在回应对方配置请求报文时,采用何种报文回应。

y当接收Config-Request报文的一端能识别发送过来的所有配置参数选项且

认可所有配置参数选项数据域的内容时,接收端将会给对端回一个Config-Ack报文并将配置请求报文中的配置参数选项原封不动的放置在Config-Ack报文的数据域内(根据协议的规定是不可改变配置参数选项

的顺序)。当配置请求报文的发送端收到Config-Ack报后,则会从当前阶段进入到下一个阶段。

例2:假设点对点通信的一端发送了一个Config-Request报文,报文内容如下:

7E FF 03 C0 21 01 01 00 17 02 06 00 0A 00 00 05 06 00 0B 42 CB 07 02 08 02 0D 03 06 7E当对端正确接收到了该报文后,应该发送一个Config-Ack报文,报文内容如下:

7E FF 03 C0 21 02 01 00 17 02 06 00 0A 00 00 05 06 00 0B 42 CB 07 02 08 02 0D 03 06 7E唯一改变的内容就是代码域(02表示是Config-Ack报文),此例与例1完全一样,但两都说明的问题有则重点。

y当接收Config-Request报文的一端能识别发送端所发送过来的所有配置参

数选项,但对部分配置参数选项数据域中的内容不认可时,接收端将会给对端回应一个Config-Nak报文,该报文中只携带不认可的配置参数选项,而这些配置参数选项的数据内容为本端希望的值。然而当接收端收到Config-Nak报文后,会重新发送Config-Request报文,而这个Config-Request报文与上一次所发送的Config-Request报文区别在于那些被对端不认可的配置参数选项的内容被填写到刚刚协商完后再次发送的Config-Request报文中(Config-Nak报文发送回来的那些配置参数选项)。例3:假设点对点通信的一端发送了一个Config-Request报文,报文内容如下:

该数据报文中有下划线的配置参数选项的内容为对端不认可的。

当对端正确接收到了该报文后,发现类型域为0x02的配置参数选项可识别,但该配置参数选项数据域的内容不认可,应发送一个Config-Nak报文且该报文中将携带希望的配置参数选项内容,报文内容如下:

该报文中返回的值已经被更改,且当发端收到该报文后会重新发送一个Config-Request报文,报文内容如下:

仔细观察是不是新的配置请求报文与老的配置请求的报文ID不一样。

y当接收Config-Request报文的一端不能识别所有的发送端发送过来的配置

参数选项时,此时接收端将会向对端回一个Config-Reject报文,该报文中的数据域只携带那些不能识别的配置参数选项(当配置参数选项的类型域不识别时)。当对端接收到Config-Reject报文后,同样会再次发送一个Config-Request报文,这个配置请求报文与上一次发送的区别在于将不可识别的那些配置参数选项给删除了。

例4:假设点对点通信的一端发送了一个Config-Request报文,报文内容如下:

下划线所表示的配置参数选项为对端不可识别的。

当对端正确接收到了该报文后,发现类型域为0x02的配置参数选项不识别,应该回应一个Config-Reject报文,报文内容如下:

该报文如果被原发送端接收后,又会重新发送一个Config-Request报文,报文内容如下:7E FF 03 C0 21 01 04 00 11 05 06 00 0B 42 CB 07 02 08 02 0D 03 06 7E

这时我们能看到,类型域为02的配置选项在下一次的请求报文中被删除了。

所以我们能够看出,链路配置阶段也可能要经过几次协商后才能完成,但这与点对点两端的设备有着密切的联系。对于PPP的两个端点而言,两者是独立完成各自的配置参数选项的协商过程的。具体的配置参数选项待后续的章节中讲解。

3.1.2.4 LCP的链路终止报文

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

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

3.1.2.5 LCP的链路维护报文

除上述两种报文类型以外,剩余的所有报文类型均归属链路维护报文。

y当接收端发现LCP报文的代码域是一个不合法的值时,将会向发送端回

应一个Code-Reject报文,在回应报文中会将所拒绝报文的内容附加上。例5:假设点对点通信的一端发送了一个Config-Request报文,报文内容如下:

有下划线的部分表示这个代码域在标准中未定义,从而无法识别。

当对端正确接收到了该报文后,发现LCP数据报文的代码域为0x0E时,应该发送一个Code-Reject报文,报文内容如下:7E FF 03 C0 21 07 01 00 1D 0E 01 00 19 02 06 00 0A 00 00 05 06 00 0B 42 CB 07 02 08 02 0D 03

华为技术PPP专题

y当接收端发现所接收到的数据帧的协议域是一个不合法的值时,将会向

发送端回应一个Protocol-Reject报文,发送端收到该拒绝报文后将停止发送该种协议类型的数据报文了。Protocol-Reject报文只能在LCP的状态机处于Opened状态时才可被处理,而在其它状态接收到该报文将被丢弃。在Protocol-Reject报文的数据域内将携带所拒绝报文的协议类型和报文内容。

例6:假设点对点通信的一端发送了一个协议域未定义(无法识别)的报文,报文内容如下:

其中下划线部分为PPP数据帧的协议域,0x7777表示一个未定义的类型(也即对端无法识别)。

当对端正确接收到了该报文后,发现该报文的协议域为0x7777,该值未在RFC中未有明确定义,应该发送一个Protocol-Reject报文,报文内容如下:7E FF 03 C0 21 08 01 00 18 77 77 01 00 00 19 02 06 00 0D 00 00 05 07 03 09 02 0D 04 06 2F 02

7E

yEcho-Request报文和Echo-Reply报文主要用来检测双向链路上自环的问题,

除此之外还可附带做一些链路质量的测试和其它功能。当LCP状态机处于Opened状态时,如果接收到了Echo-Request,就需向对端回送一个Echo-Reply报文。否则在其它LCP状态下,该类型的报文会被丢弃。这种类型数据报文的长度域后不是直接跟数据域,而是要插入4个字节的Magic-Number(魔术字),该魔术字是在LCP的Config-Request的配置参数选项协商时获得的。

例7:假设点对点通信的一端接收到了一个Echo-Request报文,报文内容如下:

有下划线的部分表示魔术字。

当对端正确接收到了该报文后,应该发送一个Echo-Reply报文,报文内容如下:

19ppp协议详解_19ppp

华为技术PPP专题

3.1.3 NCP协议

3.1.3.1 IPCPNCP协议的数据报文是在网络层协议阶段被交换的,在这个阶段所需的一些配置参数选项协商完后,就可以进行网络层的通信,也即是在点对点的链路上可以开始传送网络层的数据报文了。NCP协议主要包括IPCP、IPXCP等,但我们在实际当中最常遇见的也只有IPCP协议了,如果对IPXCP或其它的一些网络控制协议有兴趣,则可参见RFC1552。

IPCP控制协议主要是负责完成IP网络层协议通信所需配置参数的选项协商的。IPCP在运行的过程当中,主要是完成点对点通信设备的两端动态的协商IP地址。我们依据两端设备的配置选项可将IPCP的协商过程分为”静态”和”动态”。何为静态,何为动态,这是一个相对的概念,也是自已总结出来的,可能不太准确,只作为参考使用。我们在下面会具体描述这两个过程。IPCP的数据的文同LCP的数据报文非常类似,只不过一个是在网络层协议阶段协商配置参数选项,而LCP协议则是在链路建立阶段协商配置参数选项的。除此之外是两者在所使用报文上的相似之处,我们知道LCP共包括十几种报文,而IPCP也包括多种报文,但它的报文类型只是LCP数据报文的一个子集(只有LCP代码域从1到7这七种报文),而且实际的数据报文交换过程中也仅涉及以下几种:Config-Request、Config-Ack、Config-Nak和Config-Reject(代码域从1到4,而链路终止报文一般而言是不在网络协议阶段使用的,而且也是不需要的)。以下就具体介绍一下IPCP控制协议的静态和动态的两个过程,实际上两者的区分是在于互连设备IP地址的获取过程。

y静态协商,也即是不协商。点对点的通信设备两端在PPP协商之前已配

置好了IP地址,所以就无须在网络层协议阶段协商IP地址,而双方唯一要做的就是告诉对方自身的IP地址。在IPCP控制协议完成整个配置的过程时,最理想的情况将会看到如图所示的四种报文,而无其它报文再被发送。如果当配置请求中所携带的网络层配置参数选项类似于LCP配置参数选项协商过程一样,可能会有对方不识别的配置参数选项或不被对方所认可的配置参数选项的内容。这样在这个阶段的协商过程中可能还会看到其它的一些报文。

华为技术PPP专题

在静态协商时,如果IPCP的Config-Request报文中只含有地址配置参数选项时(实际中可能还会附带其它配置参数选项,这些配置参数选项的协商与LCP阶段的一样,而我这里只提到了IP地址配置参数选项),无论是发送方还是接收方都同时发送Config-Request报文,其中配置选项中只含有各自的IP地址。当对端收到该报文后,会发送一个Config-Ack报文,这个目的是告诉对端我已经知道了你的IP地址,对路由器而言会增加一条到对端接口的主机路由。 刚进入网络层协议阶段时,IPCP的状态机是initial的,但当完成了上述的整个过程后,IPCP的状态机改变为Opened,双方也就可以开始网络层数据网的传送了。

IPCP协议中并未规定,当一端接收到Config-Request报文后,它从报文的配置参数选项中可获知对端的IP地址,但并不与本端的IP地址进行比较.我们也知道,一般而言点对点的两端应该是在一个网段。但如果双方的地址不在一个网段,就不给对方回应Config-Ack报文,而是无条件的回送一个回应报文。因此说点对点通信的两端如果是手动设置每一端的IP地址时,无须双方地址在同一网段。

例8:假设IPCP在网络层协议阶段开始协商配置参数选项(这里只举协商IP地址的配置参数选项地的过程),发送方设置IP地址为192.168.0.1,接收方设置IP地址为192.168.0.2,发送方发送给Config-Request报文内容如下:

在这个例子中我们能看见明显的改变之处再于PPP协议域字段由原先的0xC021改变为0x8021,下划线的部分表示本端的IP地址。

当对端正确接收到了该报文后,应该回应一个Config-Ack报文,报文内容如下:

同样的接收方给发送方也发送一个Config-Request报文内容如下,但此时报文中IP地址配置参数选项的值为本端的IP地址(192.168.0.2):

华为技术PPP专题

发送方回应一个Config-Ack报文给接收方,报文内容如下:

y动态协商,也即是一端配置为动态获取IP地址,另一端通过手动方式配

置IP地址,且允许给对端分配IP地址,这个过程实际上可与窄带拨号上网的过程相一致,如果我们想用计算机上网,均会安装一个拨号适配器,

且计算机中的拨号网络适配器是采用动态获取IP地址的方式。

这个例子与一个例子相似,也就是在IPCP的Config-Request报文中只携带IP地址的配置参数选项。如果是配置参数选项中含有其它配置参数选项,则可能会遇到其它的一些情况(如不识别配置参数选项的代码域或不认可配置参数选项的内容,但对于这些情况的处理方法和LCP配置参数选项的处理方法一致)。图3-6中我们可以看出发送方连续发送了两次Config-Request报文,才能完成发送方的协商过程。而接收方仍然只需要发送一次Config-Request由于发送方没有配置IP地址(而是动态获取IPIPCP的IP地址配置参数配置选项中的IP地址填充全0(也即是0.0.0.0),这样当对端收到这个Config-Request报文时,当接收方收到该配置请求报文后会迅检测IP地址的内容,如果发送为全0,则认为对端的这个地址不是我所希望的值,这样就回应一个Config-Nak报文,并将希望分配给对方的IP地址填充到Config-Nak报文内。这时当接收方

3.2 总结

收到Config-Nak报文后,就会重新发送一个Config-Request报文,这个报文中的IP地址配置选项为对方在Nak报文中所提供的。接收方IP地址的配置过程与静态时的一样,只需发送一个Config-Request报文即可,当收到发送方的Config-Ack报文,就表示接收方的IP地址配置完成。例9: 假设IPCP在网络层协议阶段开始协商配置参数选项(这里只举协商IP地址的配置参数选项地的过程),发送方没有配置IP地址,而接收方配置了IP地址为192.168.0.2,接收方可给发送方分配IP地址(192.168.0.1),发送方发送给接收方的Config-Request报文内容如下:

有下划线的部分表示本端的IP地址。当对端正确接收到了该报文后,应该回应一个Config-Nak报文,报文内容如下:

当接收方收到该报文后,重新发送一个Config-Request报文,报文内容如下:

接收方再次收到发送方的一个Config-Request报文,此时将回应一个Config-Ack报文,报文内容如下:

请仔细观察一下这些报文在交互过程中,PPP数据帧净载荷内的数据报文的类型域和报文ID。同样的接收方给发送方也发送一个Config-Request报文,报文内容如下:

发送方应回送一个Config-Ack给接收方,报文内容如下:

本章节的一些内容可能没有明确写出,只是将IPCP配置参数选项配置过程中最关键的部分做了一些说明,如果想深入了解决IPCP或IPXCP,可参见相关的RFC文档。

yPPP协议的状态转移图包括链路不可用阶段、链路建立阶段、认证阶段、

网络层协议阶段和链路终止阶段

yLCP协议依据报文的功能可分为链路配置报文、链路终止报文和链路维

护报文

3.3 思考

yLCP协议的链路配置报文主要是用来协商一些可选的配置参数选项yLCP协议的链路终止报文主要是用来终止一条PPP链路yLCP协议的链路维护报文主要是用来测试和调试PPP链路yNCP协议主要负责网络层配置参数选项的协商,它包括”静态协商”和”动态协商”

1、当发送端在链路建立阶段开始时,发送一个Config-Request报文,那么当接收端接收到该数据报文后,什么情况下回应Config-Ack报文,什么情况下回应Config-Nak报文,而什么情况下又回应Config-Reject报文?

2、按功能分,Echo-Request报文和Echo-Reply报文属于LCP协议哪种类型报文,在这种报文中需要携带链路配置报文中协商何种配置参数选项?

3、IPCP协议在进行网络层配置参数选项协商时可能会遇到哪两种协商,当只协商IP地址选项时,请对比一下这两种配置参数选项的区别?当需要进行多种参数配置参数选项时(请回忆一下LCP配置参数选项协商的情况),可能会出现哪几种情况?

19ppp协议详解_19ppp

第四章 LCP的可选配置参数

4.1 LCP的参数配置选项

LCP协议在对链路配置过程中需要进行一些可选配置参数选项的协商,我们在前面讲述的过程中已列举了许多配置参数选项,但我们只挑选其中较为重要的几个参数做相应的扩展说明(魔术字和认证协议选项)。关于一些更具体的细节和未涉及到的配置参数选项,请参数PPP的RFC文档(RFC1661)。

4.1.1 魔术字(Magic-Number)

魔术字是在LCP的Config-Request报文中被协商的,并且可被其它一些其它类型的LCP数据报文所使用,如前面已经说过的Echo-Request、Echo-Reply报文和Quality-Protocol报文等。对于PPP协议本身它是不要求协商魔术字的,如果在双方不协商魔术字的情况下,某些LCP的数据报文需要使用魔术字时,那么只能是将魔术字的内容填充为全0;反之,则填充为配置参数选项协商后的结果。

魔术字在目前所有的设备当中都是需要进行协商的,它被放在Config-Request的配置选项参数中进行发送,而且需要由自身的通信设备独立产生,协议为了避免双方可能产生同样的魔术字,从而导致通信出现不必要的麻烦,因此要求由设备采用一些随机方法产生一个独一无二的魔术字。一般来说魔术字的选择会采用设备的系列号、网络硬件地址或时钟。双方产生相同魔术字的可能性不能说是没有的,但应尽量避免,通常这种情况是发产在相同厂商的设备进行互连时,因为一个厂商所生产的设备产生魔术字的方法是一样的。

我们知道魔术字产生的作用是用来帮助检测链路是否存在环路,当接收端收到一个Config-Request报文时,会将此报文与上一次所接收到的Config-Request进行比较,如果两个报文中所含的魔术字不一致的话,表明链路不存在环路。但如果一致的话,接收端认为链路可能存在环路,但不一定存在环路,还需进一步确认。此时接收端将发送一个Config-Nak报文,并在该报文中携带一个重新产生的魔术字,而且此时在未接收到任何Config-Request或Config-Nak报文之前,接收端也不会发送任何的Config-Request报文。这时我们假设可能会有以下两种情况发生:

y链路实际不存在环路,而是由于对方在产生魔术字时与接收端产生的一

致,但实际这种情况出现的概率是很小的。当Config-Nak被对端接收到后,应该发送一个Config-Request报文(此报文中的魔术字为Nak报文中

的),当对端接收到后,与上次比较,由于接收端已经在Nak报文中产生了一个不同的魔术字,此时接收端收到的Config-Request报文中的魔术字与上次配置请求报文中不一样,所以接收端可断定链路不存在环路。y链路实际上确实存在环路,一段时间后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的过程。

4.1.2 认证协议

PPP协议也提供了可选的认证配置参数选项,缺省情况下点对点通信的两端是不进行认证的。在LCP的Config-Request报文中不可一次携带多种认证配置选项,必须二者择其一(PAP/CHAP),选择最希望的那一种,一般是在PPP设备互连的设备上进行配置的,但一般设备会默认支持一个缺省的认证方式(PAP是大部分设备所默认的认证方式)。当对端收到该配置请求报文后,如果支持配置参数选项中的认证方式,则回应一个Config-Ack报文;否则回应一个Config-Nak报文,并附带上自希望双方采用的认证方式。当对方接收到Config-Ack报文后就可以开始进行认证了,而如果收到得是Config-Nak报文,则根据自身是否支持Config-Nak报文中的认证方式来回应对方,如果支持则回应一个新的Config-Request(并携带上Config-Nak报文中所希望使用的认证协议),否则将回应一个Config-Reject报文,那么双方就无法通过认证,从而不可能建立起PPP链路。

PPP支持两种授权协议:PAP(Password Authentication Protocol)和CHAP(Challenge Hand Authentication Protocol)。

4.1.2.1 PAP认证

我们所知两个设备在使用PAP进行认证之前,应该确认那一方是验证方,那一方是被验证方。实际上对于使用PPP协议互连的两端来说,既可作为认证方,也可作为被认证方。但通常情况下,PAP只使用一个方向上的认证。一般在两端设备使用PAP协议之前,均会设备上进行一些相应的配置,对于宽带工程师而言MA5200可谓是大家最熟悉的产品了,它默认就作为验证方,但可通过使用命令PAP Authentication PAP/CHAP来更改认证方式,而对于被验证方而言只需设置用户名和密码即可。

PAP认证是两次握手,在链路建立阶段,依据设备上的配置情况,如果是使用PAP认证,则验证方在发送Config-Request报文时会携带认证配置参数选项,而对于被验证方而言则是不需要,它只需要收到该配置请求报文后根据自身的情况给对端返回相应的报文。如果点对点的两端设备采用的是PAP双向认证时,也即是它同时也作为验证方,则此时需要在配置请求报文中携带认证配置参数选项。因此,我们可以总结一下,如果对于点对点的两个设备在PPP链路建立的过程中使用的认证方式为PAP的话,那么验证方在其Config-Request报文中必须含有认证配置参数选项,且该认证配置参数选项的数据域为0xC023,下图为PAP

认证的过程:

当通信设备的两端在收到对方返回的Config-Ack报文时,就从各自的链路建立阶段进入到认证阶段,那么作为被验证方此时需要向验证方发送PAP认证的请求报文,该请求报文携带了用户名和密码,当验证方收到该认证请求报文后,则会根据报文中的实际内容查找本地的数据库,如果该数据库中有与用户名和密码一致的选项时,则回向对方返回一个认证请求响应,告诉对方认证已通过。反之,如果用户名与密码不符,则向对方返回验证不通过的响应报文。如果双方都配置为验证方,则需要双方的两个单向验证过程都完成后,方可进入到网络层协议阶段,否则在一定次的认证失败后,则会从当前状态返回链路不可用状态。

例10: 如图4-1所示,当路由器A(被验证方)收到了路由器B 的Config-Ack报文后,因为是使用PAP认证,所以作为被验证方的路由器A应主动向验证方(路由器B)发送认证请求报文(PAP Authenticate),用户名和密码均为163,报文的内容如下:

下划线的前四个字节是用户名,后四个字节是密码。

当路由器B收到了该报文后,会向路由器A回应一个PAP Authenticate Ack报文,报文内容

如下:

此时所回应的报文中,并未携带任何数据,如果是认证不通过,则会在返回的报文中指是因何原因无法认证通过,可能是无此用户名或密码不匹配。

4.1.2.2 CHAP认证

与PAP认证比起来,CHAP认证更具有安全性,从前面认证过程的数据包交换过程中不然发现,采用PAP认证时,被验证是采用明文的方式直接将用户名和密码发送给验证方的,而对于PAP认证则不一样。

CHAP为三次握手协议,它只在网络上传送用户名而不传送口令,因此安全性比PAP高。在验证一开始,不像PAP一样是由被验证方发送认证请求报文了,而是由验证方向被验证方发送一段随机的报文,并加上自己的主机名,我们通称这个过程叫做挑战。当被验证方收到验证方的验证请求,从中提取出验证方所发送过来的主机名,然后根据该主机名在被验证方设备的后台数据库中去查找相同的用户名的记录,当查找到后就使用该用户名所对应的密钥,然后根据这个密钥、报文ID和验证方发送的随机报文用Md5加密算法生成应答,随后将应答和自己的主机名送回,同样验证方收到被验证方发送回应后,提取被验证方的用户名,然后去查找本地的数据库,当找到与被验证方一致用户名后,根据该用户名所对应的密钥、保留报文ID和随机报文用Md5加密算法生成结果,和刚刚被验证方所返回的应答进行比较,相同则返回Ack,否则返回Nak

,下图为CHAP的认证过程:

例11: 如图4-2所示,当路由器A(被验证方)收到了路由器B 的Challenge报文后,报文内容如下:

下划线的前16个字节是验证方随机产生的一段报文,后7个字节是验证方的主机名(MA5200A),而且单个字节10表示随机报文的长度。

而此时路由器A会根据用户名所对应的密钥使用报文的ID和该报文的内容生成一个回应报文,报文内容如下:

我们将这个回应报文与验证方发送的挑战报文进行比较,报文的代码域已由原01改为02,总报文的长度有变化,主要后而一个下划线的内容是被验证方的主机名(ppkiss@hua),而且此时回应的16个字节的报文已经是经过MD5算法加密过的。

当验证方收到了这个回应报文后,会根据报文中被验证方的主机名(ppkiss@hua)在本地的数据库中去查找密钥,然后再对原发先发送的那段挑战报文进行MD5的算法加密,如果所得的结果与对方刚发过来的16个字节的加密值一样的话,则就会发送一个报文通知被验证方,你的认证已经通过,我们可以进入到下一个阶段了。在实际应用当中,我们很多都是使用PC机来进行拨号这个过程,实际中当验证方发送挑战后,PC机只接收而并不去查本地数据库,而直接使用在拨号对话框中所输入的密码和报文的ID及报报文的内容进行MD5算法加密(这个在PC机采用PPPOE软件拨入到MA5200时就是这样的)。

下面来看一下验证通过时,验证方给被验证方所发送的一段报文内容:

7E

此时所回应的报文的代码域为03,且报文的实际内容是,Welcom to MA5200A。

4.1.3 MRU(Maxium Receive Unit)

这个配置参数选项主要是Config-Request报文的发送端告诉接收端,本端接收到的PPP数据帧的数据域的最大值。通常情况下这个参数选项使用默认值(1500

字节),因此在Config-Request报文中双方都不会携带这个配置参数

19ppp协议详解_19ppp

华为技术

4.2 总结

4.3 思考PPP专题选项。 当在某些特殊应用中,可能会使用到小于1500字节或大于1500字节的情况,这时在Config-Request报文就会携带要协商的MRU配置参数选项值。y魔术字可以在链路配置阶段被协商,数据报文可借助魔术字来检PPP链路是否存在环路yPAP(密码认证协议)认证是二次握手,它是直接在网络上传送明文的用户名和密码,因此这种协议安全性不高yCHAP(挑战性握手认证协议)认证是三次握手,它只在网络上传送验证方和被验证方的主机名,而并不传送密码,因此相比之处CHAP比PAP更安全yPPP协议缺省的MRU是1500,而对于通信的双方可根据实际需要对MRU进行协商

1、PPP协议可通过几种方式来检测PPP链路是否存在环路?

2、请比较PAP认证和CHAP认证?

华为技术PPP专题

第五章 PPP扩展协议

5.1 PPP扩展协议概述

5.1.1 MP出现的背景

我们知道ISDN可以在两个系统之间提供2B+D和30B+D多通道捆绑能务,从而为用户能够提供更多可用的带宽。诸如上述的许多链路捆绑功能需要软件和硬件的协同工作,而且更多的基于硬件来实现的。然而我们是否考虑过仅仅通过软件的实现来完成链路捆绑的功能,同时还考虑到很多实际链路的情况,对于软件在实现过程中还要能对不同速率的链路进行捆绑。我们可以通过在发送数据之前增加一定数据的字节头,其中含有为重组数据而所需的一些字段。

随着PPP的广泛应用,MP作为PPP功能扩展协议应运而生。它可为用户提供更大的带宽,实现数据的快速转发。同时,还可实现对链路资源进行动态分配,有效的利用宝贵的资源。但随着网络技术的发展,网络的带宽已不再是瓶颈,所以对于使用PPP扩展协议已没有实际意义,只在本章中简单做一下介绍,如果想进一步了解该协议,可参考相应的RFC1717或提供的参考书目。

5.1.2 MP(Multilink Protocol)协议

MP的协商较为特殊。MP配置参数选项的协商是在LCP协商过程中完成的,协商MP配置参数选项的目的完成以下几个过程:

y表明系统是否支持将多个物理链路捆绑成一个逻辑链路

y系统在多链路上接收到了对端发送的数据单元后,能够通过附加在这些

数据之前的重组字段对这些分段的数据单元进行重组

y逻辑链路为了能够提高传输的效率,可以不使用单一PPP物理链路上的

最大接收单元,可以重新协商新的逻辑链路上使用的最大接收单元进行数据报文的发送和接收。

MP协议可以用来灵活的调整点对点系统之间的多条独立物理链路,它可为整个系统提供一个虚拟链路,虚拟链路的带宽是N个链路的捆绑之和(N≥1 )。而对于被捆绑的链路并未做出特殊要求,可以将同步链路和异步链路进行捆绑,同样也可将低速链路和高速链路进行捆绑。使用该协商可将多个PPP的链路捆绑成一条使用,而决定不同通道是否需进行多链路捆绑有两个条件: 只有两个链路的Discriminator和验证方式、用户完全相符时,才能对两个链路进行捆绑。这就意味着只有当验证完成后,才能真正完成MP的协

华为技术

5.2 总结

5.3 思考PPP专题商过程。MP不会导致链路的拆除。 如果配置了MP,两个链路不符合MP条件,则会建立一条新的MP通道,这同时也表明允许MP为单链路。MP的捆绑是完全依照用户进行的,只有相同用户才能进行捆绑。如一端配置了MP,另一端不支持或未配MP,则建立起来的链路为非MP链路。yMP协议属于PPP协议的扩展协议yMP协议可依据终端指示符和验证方式对不同的物理链路进行捆绑

1、如下图所示,设备1与设备2通过两条物理链路互连(使用链路1和链路

2),而设备1与设备3也通过两条物理链路互连(使用链路3和链路4),我

们知道

设备链路的捆绑是依据终端指示符和验证方式的组合进行的,试想一下使用这两项的4种组合设备1在进行链路捆绑中会出现哪些情况。

华为技术PPP专题

第六章 PPP的状态机

6.1 PPP扩展协议概述

由于PPP的状态机,对于我们实际使用当中没有太大的意义,如果想进一步深入了解PPP协议的话,请参见PPP的RFC文档。

二 : ARP协议详解之GratuitousARP(免费ARP)

ARP协议详解之Gratuitous ARP(免费ARP)[www.61k.com]

Gratuitous ARP(免费ARP)

Gratuitous ARP也称为免费ARP,无故ARP。Gratuitous ARP不同于一般的ARP请求,它并非期待得到IP对应的MAC地址,而是当主机启动的时候,将发送一个Gratuitous arp请求,即请求自己的IP地址的MAC地址。

免费ARP的产生

免费ARP数据包是主机发送ARP查找自己的IP地址。通常,它发生在系统引导期间进行接口配置的时候。这里可以使用Wireshark捕获主机启动时候的数据,以验证是否发送Gratutious arp数据包。这里捕获到的数据包,如图1.21所示。
arp ARP协议详解之GratuitousARP(免费ARP)
图1.21 Gratuitous ARP包
从该界面可以看到第44、45、47数据包都是Gratuitous ARP包。

免费ARP的作用

免费ARP有两个方面的作用。分别如下所示:
1.验证IP是否冲突
一个主机可以通过它来确定另一个主机是否设置了相同的IP地址。发送主机并不需要一定收到此请求的回答。如果收到一个回答,表示网络中存在与自身IP相同的主机。如果没有收到应答,则表示本机所使用的IP与网络中其它主机并不冲突。
【实例1-176】通过使用Wireshark捕获数据包,分析是否有IP冲突的情况。实验环境如图1.22所示。
arp ARP协议详解之GratuitousARP(免费ARP)
图1.22 验证IP是否冲突
(1)在主机A上配置一个IP地址为192.168.7.8。然后重新启动主机A。
(2)在主机A启动时,这里也将主机B的IP地址修改为192.168.7.8。
(3)此时看Wireshark获取到的数据包,如图1.23所示。
arp ARP协议详解之GratuitousARP(免费ARP)
图1.23 免费ARP包
从该界面主要分析91、92帧。如下所示:
(1)从91帧中可以看到MAC地址为00:23:8b:c4:05:bf的主机(主机A),向这个局域网发送免费ARP广播包。告诉局域网中所有的主机,它请求使用192.168.7.8。
(2)92帧表示MAC地址为00:19:21:3f:c3:e5的主机(主机B),向整个局域网发送ARP广播包。告诉局域网中所有的主机,192.168.7.8的MAC地址是00:19:21:3f:c3:e5(主机B)。意思是主机B已经使用了192.168.7.8。
从这两个数据包,可以看出主机B响应了主机A发送的免费ARP包,表示网络中存在与A有相同IP的主机。所以A主机启动后,将会看到如图1.24所示的窗口。
arp ARP协议详解之GratuitousARP(免费ARP)
图1.24 IP冲突提示
从该窗口的提示信息中可以看到本机的IP地址与网络上其他系统的IP地址冲突。
2.更换物理网卡
如果发送ARP的主机正好改变了物理地址(如更换物理网卡),可以使用此方法通知网络中其它主机及时更新ARP缓存。
【实例1-18】下面验证更换物理网卡后,发送免费ARP的请求包。具体操作步骤如下所示:
本例中使用的实验环境,如图1.25所示。在该环境中,主机A和主机B的IP、MAC地址已经标出。在实验之前这两台主机已经能正常通行,也就是说它们分别有对方的ARP条目。其中,主机A的操作系统为KaliLinux;主机B为Windows 7。
arp ARP协议详解之GratuitousARP(免费ARP)
图1.25 验证免费ARP
(1)查看主机A的ARP缓存表。执行命令如下所示:

root@kali:~# arp

Address HWtype HWaddress Flags Mask Iface

192.168.1.2 ether 00:23:8b:c4:05:bf C eth0

从输出的信息中,可以看到该缓存表中有一条ARP条目。其中IP地址为192.168.1.2,MAC地址为00:23:8b:c4:05:bf。

(2)修改主机B的MAC地址。如下所示:

在桌面上右键单击“网络”|“属性”,打开网络和共享中心。在该界面单击“更改适配器设置”命令,将显示如图1.26所示。

arp ARP协议详解之GratuitousARP(免费ARP)

图1.26 网络连接 图1.27 本地连接 属性

在该界面右键单击“本地连接”|“属性”,将显示如图1.27所示的界面。

在该界面单击“配置”按钮,将显示如图1.28所示的界面。在该界面选择“高级”选项卡,如图1.29所示。

arp ARP协议详解之GratuitousARP(免费ARP)

图1.28 Realtek PCLe GBE Family Controller属性 图1.29 高级设置

在该界面的属性一览中找到“网络地址”(有的系统是Locally Administered Address或Network Address),然后单击“值”,并输入要更改的MAC地址(这里输入的MAC地址间不需要使用“-”符号)。

(3)查看Wireshark捕获的数据包,如图1.30所示。

arp ARP协议详解之GratuitousARP(免费ARP)

图1.30 免费ARP广播包

从该界面可以看到有三个免费ARP包,分别是11、15、18。这三个包都是MAC地址为00:19:21:3f:c3:e4的主机向局域网中其它主机发送的免费ARP包,告诉其它主机它将使用192.168.1.2的IP地址。免费ARP包中的数据,如图1.31所示。

扩展:gratuitous arp / gratuitous arp for / 大量gratuitous arp

arp ARP协议详解之GratuitousARP(免费ARP)

图1.31 免费ARP广播包

从该界面可以看到第三行信息为ARP协议(请求/免费ARP)信息。从中可以查看的发生方的MAC地址、IP地址及目标MAC地址、IP地址。这里的目标MAC地址是00:00:00:00:00:00,表示这是一个ARP广播请求。局域网中其它的计算机都会收到。如果有某主机中记录了相关该地址的ARP条目将会被更新。

(4)查看主机中的ARP缓存表。如下所示:

root@kali:~# arp

Address HWtype HWaddress Flags Mask Iface

192.168.1.2 ether 00:19:21:3f:c3:e4 C eth0

从输出的信息中可以看到,地址为192.168.1.2的ARP条目的MAC地址更新为00:19:21:3f:c3:e4。

扩展:gratuitous arp / gratuitous arp for / 大量gratuitous arp

三 : Lua的协程和协程库详解

我们首先介绍一下什么是协程、然后详细介绍一下coroutine库,然后介绍一下协程的简单用法,最后介绍一下协程的复杂用法。(www.61k.com]

一、协程是什么?

(1)线程

首先复习一下多线程。我们都知道线程——Thread。每一个线程都代表一个执行序列。

当我们在程序中创建多线程的时候,看起来,同一时刻多个线程是同时执行的,不过实质上多个线程是并发的,因为只有一个CPU,所以实质上同一个时刻只有一个线程在执行。

在一个时间片内执行哪个线程是不确定的,我们可以控制线程的优先级,不过真正的线程调度由CPU的调度决定。

(2)协程

那什么是协程呢?协程跟线程都代表一个执行序列。不同的是,协程把线程中不确定的地方尽可能的去掉,执行序列间的切换不再由CPU隐藏的进行,而是由程序显式的进行。

所以,使用协程实现并发,需要多个协程彼此协作。

二、resume和yeild的协作。

resume和yeild的协作是Lua协程的核心。这边用一幅图描述一下,有一个大体的印象。对照下面的coroutine库的详细解释和最后的代码,应该可以搞清楚协程的概念了。

注:这是在非首次resume协程的情况下,resume和yield的互相调用的情况。如果是首次resume协程,那么resume的参数会直接传递给协程函数。

协程 Lua的协程和协程库详解

三、coroutine库详解

(1)coroutine.create (f)

传一个函数参数,用来创建协程。返回一个“thread”对象。

(2)coroutine.isyieldable ()

如果正在运行的协程可以让出,则返回真。值得注意的是,只有主协程(线程)和C函数中是无法让出的。

(3)coroutine.resume (co [, val1, ···])

这是一个非常重要的函数。用来启动或再次启动一个协程,使其由挂起状态变成运行状态。

可以这么说,resume函数相当于在执行协程中的方法。参数Val1...是执行协程co时传递给协程的方法。

首次执行协程co时,参数Val1...会传递给协程co的函数;

再次执行协程co时,参数Val1...会作为给协程co中上一次yeild的返回值。

不知道这句话大家理解了没,这是协程的核心。如果没理解也不用急,继续往下看,稍后我会详细解释。

resume函数返回什么呢?有3种情况:

1)、如果协程co的函数执行完毕,协程正常终止,resume返回 true和函数的返回值。

2)、如果协程co的函数执行过程中,协程让出了(调用了yeild()方法),那么resume返回true和协程中调用yeild传入的参数。

3)、如果协程co的函数执行过程中发生错误,resume返回false与错误消息。

可以看到resume无论如何都不会导致程序崩溃。它是在保护模式下执行的。

(4)coroutine.running ()

用来判断当前执行的协程是不是主线程,如果是,就返回true。

(5)coroutine.status (co)

返回一个字符串,表示协程的状态。有4种状态:

1)、running。如果在协程的函数中调用status,传入协程自身的句柄,那么执行到这里的时候才会返回running状态。

2)、suspended。如果协程还未结束,即自身调用了yeild或还没开始运行,那么就是suspended状态。

3)、normal。如果协程Aresume协程B时,协程A处于的状态为normal。在协程B的执行过程中,协程A就一直处于normal状态。因为它这时候既不是挂起状态、也不是运行状态。

4)、dead。如果一个协程发生错误结束,或正常终止。那么就处于dead状态。如果这时候对它调用resume,将返回false和错误消息。

(6)coroutine.wrap (f)

wrap()也是用来创建协程的。只不过这个协程的句柄是隐藏的。跟create()的区别在于:

1)、wrap()返回的是一个函数,每次调用这个函数相当于调用coroutine.resume()。

2)、调用这个函数相当于在执行resume()函数。

3)、调用这个函数时传入的参数,就相当于在调用resume时传入的除协程的句柄外的其他参数。

4)、调用这个函数时,跟resume不同的是,它并不是在保护模式下执行的,若执行崩溃会直接向外抛出。

(7)coroutine.yield (···)

使正在执行的函数挂起。

传递给yeild的参数会作为resume的额外返回值。

同时,如果对该协程不是第一次执行resume,resume函数传入的参数将会作为yield的返回值。

四、例子进阶。

(1)、例子1:简单实用resume、yield,如下:

coco =coroutine.create(function(a,b)print("resume args:"..a..","..b)yreturn=coroutine.yield()print("yreturn :"..yreturn)end)coroutine.resume(coco,0,1)coroutine.resume(coco,21)

输出:

resume args:0,1yreturn :21

(2)、例子2:简单使用wrap,如下:

coco2 =coroutine.wrap(function(a,b)print("resume args:"..a..","..b)yreturn=coroutine.yield()print("yreturn :"..yreturn)end)print(type(coco2))coco2(0,1)coco2(21)

输出:

functionresume args:0,1yreturn :21

很明显,wrap的使用更方便。

(3)、如果还没有足够的理解,且看我放大招,看这个例子:

functionstatus()print("co1's status :"..coroutine.status(co1)..",co2's status:"..coroutine.status(co2))endco1=coroutine.create(function( a )print("arg is :"..a)status()localstat,rere =coroutine.resume(co2,"2")print("resume's return is"..rere)status()localstat2,rere2 =coroutine.resume(co2,"4")print("resume's return is"..rere2)localarg =coroutine.yield("6")end)co2=coroutine.create(function( a )print("arg is :"..a)status()localrey =coroutine.yield("3")print("yeild's return is".. rey)status()coroutine.yield("5")end)--主线程执行co1,传入字符串“main thread arg”stat,mainre =coroutine.resume(co1,"1")status()print("last return is"..mainre)

扩展:lua 协程 / lua 协程 例子 / lua 协程的应用场景

用一个函数status()输出2个协程的状态,最后输出如下:

arg is :1co1's status :running ,co2's status: suspendedarg is :2co1's status :normal ,co2's status: runningresume's return is 3co1's status :running ,co2's status: suspendedyeild's return is 4co1's status :normal ,co2's status: runningresume's return is 5co1's status :suspended ,co2's status: suspendedlastreturnis6

(4)、最后附一个云风在Lua5.3参考手册中给出的例子:

functionfoo(a)print("foo", a)returncoroutine.yield(2*a)endco=coroutine.create(function( a, b )print("co-body", a, b)localr = foo(a +1)print("co-body", r)localr, s =coroutine.yield(a + b, a -b)print("co-body", r, s)returnb,"end"end)print("main",coroutine.resume(co,1,10))print("main",coroutine.resume(co,"r"))print("main",coroutine.resume(co,"x","y"))print("main",coroutine.resume(co,"x","y"))

输出如下:

co-body110foo2maintrue4co-body rmaintrue11-9co-body x ymaintrue10endmainfalsecannot resume dead coroutine

扩展:lua 协程 / lua 协程 例子 / lua 协程的应用场景

四 : OSPF协议之详细图解

OSPF是一种基于SPF算法的链路状态路由协议。

www.2cto.com 下面老马就将本协议的详细工作过程做一总结,希望对大家有所帮助……

ospf协议 OSPF协议之详细图解

上图是在一个OSPF区域里面添入一台新的路由器的时候,OSPF协议的工作过程,如果你能非常详细的叙述出这张图的话,基本上OSPF协议的工作过程你就掌握了。下面老马的主要工作就是分析这张图。

首先大家要清楚,一台运行了OSPF协议的路由器,最终都会存储三张表:邻居表、拓扑表、路由表。老马下面以这三张表的产生过程为线索,来分析在这个过程中,路由器发生了那些变化,从而说明OSPF协议的工作过程。

(一)邻居表的建立
一台新加入OSPF区域的路由器首先要跟邻居路由器建立邻接关系,过程如下:
www.2cto.com

ospf协议 OSPF协议之详细图解
图1

ospf协议 OSPF协议之详细图解
图2

ospf协议 OSPF协议之详细图解
图3
通过上面3步,新加入的路由器和其邻居路由器已经建立了邻接关系。

(二)拓扑表的建立
www.2cto.com 在建立拓扑表的时候,新加入的路由器要经历预启动状态、交换状态、加载状态、完全邻接状态。下面老马就将此过程,以图的形式展示给大家:

ospf协议 OSPF协议之详细图解
图1

ospf协议 OSPF协议之详细图解
图2

ospf协议 OSPF协议之详细图解
图3

ospf协议 OSPF协议之详细图解
经过以上四步,此OSPF区域的所有路由器的数据拓扑图都达到了同步。

(三) 然后每个路由器按照产生的全区域数据拓扑图,在运行SPF算法,产生到达目标网络的路由条目。
经过以上三大步,OSPF协议的运行过程基本结束。

注意:在上面的过程当中有几个很重要的问题需要注意
1》此协议的管理距离是110、OSPF路由进程ID的范围必须在1-65535之间,而且只具有本地含义,不同路由器的路由进程ID可以不同、区域ID在0-4294967295,当区域值取0时本区域称为主干区域。
www.2cto.com
2》确定router ID遵循如下顺序:
用router ID 命令指定的路由器ID的优先级最高
如果没有指定,那么选IP地址最大的环回接口的IP地址为route ID
如果没有换回接口,就选择UP端口中IP值最大的为router ID
但还是建议使用命令指定,这样可控性比较好。

3》DR选举的原则
首要因素是时间,最先启动的路由器被选举成为DR
如果同时启动,或者重新选举,则看接口优先级(0-255),优先级最高的被选举成DR,在默认情况下,多路访问网络的接口优先级为1,点到点网络的接口优先级为0,修改接口优先级的命令是“ip ospf priority”,如果接口的优先级被设置为0,那么该接口不参与DR选举。

如果前两者相同,最后看路由器ID,路由器ID最高的被选举成DR。
DR选举时非抢占的,除非人为地重新选举。重新选举DR的方法有两种,一是路由器重新启动;二是执行“clear ip ospf process"命令

扩展:ospf协议 / ospf协议配置命令 / ospf协议详解

五 : OSPF协议详解(最终版)

OSPF协议总结(完整版)

OSPF的五个包:

1.Hello:9项内容,4个必要

2.DBD:数据库描述数据包(主要描述始发路由器数据库中的一些或者全部LSA信息),主要包括接口的MTU,主从位MS,数据库描述序列号等);

3.LSR:链路状态请求数据包(查看收到的LSA是否在自己的数据库,或是更新的LSA,如果是将向邻居发送请求);

4.LSU:链路状态更新数据包(用于LSA的泛洪扩散和发送LSA去响应链路状态请求数据包);

5.LSACK:链路状态确认数据包(用来进行LSA可靠的泛洪扩散,即对可靠包的确认)。

Hello包作用:

1.发现邻居;

2.建立邻居关系;

3.维持邻居关系;

4.选举DR,BDR

5.确保双向通信。

2.邻居关系为FULL状态;而邻接关系是处于TWO-WAY状态。

Hello时间间隔:

在点对点网络与广播网络中为10秒;

在NBMA网络与点对多点网络中为30秒。

注:

保持时间为hello时间4倍

虚电路传送的LSA为DNA,时间抑制,永不老化.

OSPF的组播地址:

DR将使用组播地址224.0.0.5泛洪扩散更新的数据包到DRothers

DRothers使用组播地址224.0.0.6发送更新数据包

组播的MAC地址分别为:0100.5E00.0005,0100.5E00.0006

OSPF的包头格式:

| 版本 | 类型 | 长度 | 路由器ID | 区域ID | 验证和 | 验证类型 |验证 | 数据 | | 1 byte | 1 | 2 | 4 | 4 | 2 | 2 | 8 | variance |

OSPF支持的验证类型:

OSPF支持明文和md5认证,用Sniffer抓包看到明文验证的代码是“1”,md5验证的代码是“2”。

OSPF支持的网络类型:

1.广播

2.非广播

3.点对点(若MTU不匹配 将停留在EX-START状态)

4.点对多点

5.虚电路(虚电路的网络类型是点对点)

虚链路必须配置在ABR上,

虚链路的配置使用的命令是area transit-area-id virtual-link router-id

虚链路的Metric等同于所经过的全部链路开销之和

DR /BDR选举:

1.优先级(0~255; 0代表不参加选举;默认为1);

2.比较Router-id。

次者为BDR。

在Point-to-Point, Point-to-Multipoint(广播与非广播)这三种网络类型不选取DR与BDR; Broadcast, NBMA选取DR与BDR。

先启动OSPF进程的路由器会等待一段时间,这个时间内你没有启动其它路由的OSPF进程的话,第一台路由就认为自己是DR,之后再加进来的也不能在选举了,这个等待时间叫做Wait Timer计时器,CISCO规定的Wait Timer是40秒。这个时间内你启动的路由是参与选举的,所以真实工作环境中,40秒你大概只启动了两台,DR会再前两台启动的路由中产生,工作一段时间以后,活的最久的路由最有可能成为DR

OSPF over FRAME-RELAY 的配置:

(1) NBMA : 在HUB上指定邻居;SPOKE上设置优先级为0。

(2) P-TO-P: 接口下配置命令 ip ospf network point-to-point。

(3) P-TO-MULT P:接口下配置命令 ip ospf network point-to-multipoint。

按需电路配置:

接口下配置命令 ip ospf demand-cricuit。

孤立区域问题解决:

1.虚电路 (虚电路穿过的区域一定是标准区域,标准区域一定是全路由的)

2.隧道

3.多进程重分发

注:如果中间间隔区域为stub区域,则只能用隧道解决.

OSPF分区域的原因:

1.LSA数据过大,造成带宽负载过大。

2.计算全网拓扑,对cup要求过高。

3.数据库过大,对内存要求过高。

OSPF的区域类型:

骨干: LSA:1 2 3 4 5

标准: LSA:1 2 3 4 5

stub: LSA1 2 3

nssa: LSA1 2 3 7 7(default)

AREA 1 NSSA DEFAULT INFORMATION-ORIGINATE (ABR上产生默认路由LSA 7)

total-stub: 1 2一条默认3

total-nssa: 1 2 7一条默认3

LSA的类型:

类型1: 路由器链路信息

内容包括:路由器链路Router-id; 接口地址; 接口网络; 接口花费 可使用show ospf database router命令查看。

类型2: 网络链路信息

由DR通告,如果是点对点的网络类型,没有LSA2

类型3、4:汇总链路(都是ABR通告)

3号通告ospf区域间信息

4号通告asbr的router-id信息(通告nssa区域的abr)

类型5: 通告外部路由

类型7: nssa区域外部路由

OSPF邻居建立过程:

A-------------------------B

down

init B收到A 发来hello进入init状态

two way hello 4个“*”匹配,选举DR BDR ;A在hello中发现自己的Router-id; exstart 交换DBD;确立主从关系(多路访问Router-id高为主,低为从; 串行接口

下接口地址大的为主)

exchange 交换数据DBD (主的先发)

loading 交换完整数据包LSR LSU

full

注:

每个LSA由序列号确认为最新的更新。

当路由器收到LSA之后的处理过程:

(1)如果数据库有这样的,再查看序列号,如果序列号相同,忽略这条LSA;如果序列号偏大,将其转到数据库,并进行SPF,更新路由表;如果序列号偏小,将一个包含自己的LSA新信息发送给发送方。

(2)如果数据可没有这样的,将其加到数据库表,并发一个ACK返回,并运行SPF,更新路由表。‘

OSPF的Metric值:

Cost=10的8次方/带宽,简便记做100Mb/带宽值。Metric值是由cost值逐跳累加的。

环回口的路由,掩码为/32,既我们所说的“主机路由”。在实际应用中,环回口以32位的居多,用作ospf的管理接口。但是如果你想让环回口模拟一个网段,我们可以通过以下配置来消除。

R1(config)#int loopback 0

R1(config-if)#ip ospf network point-to-point

环回口只能配置成point-to-point这种类型,不可以配置成其它的类型。

其他:

1.当一个路由器既是ABR又是ASBR时为了不让巨量外部路由分发进nssa区

域使用命令:area 1 nssa no-redistribution default-information originate

2.配置命令show ip ospf database router用来查询拓扑

3.一个路由器在理论上支持65535个OSPF进程,在实际环境中一个路由器可支持的OSPF

进程数量与其可用物理接口数量相等。(这个我对老师说的有疑问,如果我启用了很多环回口,每个环回口一个区域不可以吗?)

OSPF汇总

在OSPF骨干区域当中,一个区域的所有地址都会被通告进来。但是如果某个子网忽好忽坏不稳定,那么在它每次改变状态的时候,都会引起LSA在整个网络中泛洪。为了解决这个问题,我们可以对网络地址进行汇总。

Cisco路由器的汇总有两种类型:区域汇总和外部路由汇总。区域汇总就是区域之间的地址汇总,一般配置在ABR上;外部路由汇总就是一组外部路由通过重发布进入OSPF中,将这些外部路由进行汇总。一般配置在ASBR上。

区域汇总:

area area-id range ip-address mask

外部路由汇总:

summary-address ip-address mask

我设计的两个试验,把几个知识点串起来

试验一

用一个试验总结一下ospf over 桢中继的时候,OSPF几种网络类型的差别。

封装好FR,DEBUG看到的几种情况

情况一:两边只起了OSPF进程,其它全部默认

这种情况下邻居需要手动配置!

R2(config)#router ospf 10

R2(config-router)#neighbor 12.1.1.3

选举了DR,BDR

hello的间隔是30s

OSPF的数据包是单播传送的。

情况二:两边的网络类型改为Broadcast(命令接口下ip ospf network broadcast) 这种网络类型下是不需要手动配置邻居关系

有DR与BDR的选举。

Hello时间间隔为10s。

使用224.0.0.5这个组播地址传送数据包。

情况三:网络类型改为Point-to-Point(命令接口下ip ospf net point-to-point) 不需要手动指定邻居

没有DR/BDR的选举

Hello时间间隔为10s

使用224.0.0.5这个组播地址传送数据。

情况四:Point-to-Multipoint(命令接口下ip ospf network point-to-multipoint)

不需要手动指定邻居 没有DR和BDR的选举 Hello时间间隔为30s

以224.0.0.5这个组播地址发送数据

情况五:非广播的Point-to-Multipoint

(命令接口下ip ospf network point-to-multipoint non-broadcast) 邻居需要手动指定,但是邻居只要在一边指定即可。 没有DR和BDR的选取 Hello时间间隔为30s 使用单播传送OSPF数据

试验二

OSPF的认证总结:

OSPF的认证有2种类型(不验证也算的话是3种),使用DEBUG可以看到type0表示无认证,type1表示明文认证,type2表示MD5认证。明文认证发送密码进行认证,而MD5认证发送的是报文摘要。

OSPF的认证可以在链路上进行,也可以在整个区域内进行认证。另外虚链路同样也可以进行认证。

同样也是分情况来讨论。

情况一:R1和R2明文验证

R1(config)#int s1/0

R1(config-if)#ip ospf authentication(启用认证)

R1(config-if)#ip ospf authentication-key cisco(配置密码)

不配置R2的话

通过debug工具我们可以看到如下信息:

*Aug 15 22:51:54.275: OSPF: Rcv pkt from 10.1.1.2, Serial1/0 : Mismatch Authentication type. Input packet specified type 0, we use type 1

这里的type0是指对方没有启用认证,type1是明文认证。

在R2上配置认证,使得邻居关系恢复。

R2(config)#int s1/0

R2(config-if)#ip ospf authentication

R2(config-if)#ip ospf authentication-key cisco

*Aug 15 22:54:55.815: %OSPF-5-ADJCHG: Process 10, Nbr 1.1.1.1 on Serial1/0 from LOADING to FULL, Loading Done

情况二:在R2和R3的串行链路上进行MD5认证的:

R2(config)#int s1/1

R2(config-if)#ip ospf authentication message-digest(定义认证类型为MD5) R2(config-if)#ip ospf message-digest-key 1 md5 cisco(定义key和密码) R3(config)#int s1/0

R3(config-if)#ip ospf authentication message-digest

R3(config-if)#ip ospf message-digest-key 1 md5 cisco

情况三:增加R2和R3上串行链路的MD5认证的密码:

在R2原有的配置上加上下面这条命令:

R2(config-if)#ip ospf message-digest-key 2 md5 openlab

R2#sho ip ospf neighbor

Neighbor ID Pri State Dead Time Address Interface

3.3.3.3 0 FULL/ - - 11.1.1.2 OSPF_VL0

1.1.1.1 1 FULL/BDR 00:00:34 21.1.1.1 FastEthernet0/0

1.1.1.1 0 FULL/ - 00:00:37 10.1.1.1 Serial1/0

3.3.3.3 0 FULL/ - 00:00:31 11.1.1.2 Serial1/1 邻居关系没有丢失。

增加新的密码钥匙,然后在将原来的密码删除,候邻居关系不受影响。

情况四:在Area0上进行区域认证(以前没做过吧)

R1(config)#router ospf 10

R1(config-router)#area 0 authentication

还没有写下一步,就是刚启用,还没设置密码,邻居就down掉了 同样,R2上启用一下,邻居就恢复

或者都设置相同的密码也可以。

情况五:Area0上进行区域认证以后。。。

R2#clear ip ospf pro清进程,A2区域的学不到邻居了。R3是通过虚链路连接到骨干区域的。因为virtual-link属于Area0,因此在R2配置完成Area0区域认证后,R3也需要相应的配置。

R3(config)#router ospf 10

R3(config-router)#area 0 authentication

这样就可以了

情况六:单纯的虚链路的认证(这个以前也没做过吧)

明文认证,MD5认证。配置命令如下:

明文:

R2(config-router)#area 1 virtual-link 3.3.3.3 authentication-key cisco

R3(config-router)#area 1 virtual-link 2.2.2.2 authentication-key cisco

MD5:

R2(config-router)#area 1 virtual-link 3.3.3.3 authentication message-digest R2(config-router)#area 1 virtual-link 3.3.3.3 message-digest-key 1 md5 cisco R3(config-router)#area 1 virtual-link 2.2.2.2 authentication message-digest R3(config-router)#area 1 virtual-link 2.2.2.2 message-digest-key 1 md5 cisco

另外通过实验知道虚链路在建立起来后是DNA LSA(不老化LSA),所以如果没有重启OSPF进程的话,即使一端配置了认证,虚链路也是不会断开的。

后面是sniffer抓得包

Hello包

Lsu包

LSACK包

上面是一般情况,下面是明文验证的几个包

Hello

DBD

LSR

LSU

LSACK

下面是MD5加密认证得包

Hello

DBD

LSR

LSU

LSACK

本文标题:ospf协议详解-19ppp协议详解
本文地址: http://www.61k.com/1162855.html

61阅读| 精彩专题| 最新文章| 热门文章| 苏ICP备13036349号-1