欢迎光临散文网 会员登陆 & 注册

广域网学习笔记

2022-05-26 23:13 作者:耳朵发烧  | 我要投稿

因为内容是我从Word复制粘贴进来,有些格式会消失了,有些文字位置会变动,一共三千多笔记,够考试用了。 

广域网技术

什么是广域网?

       

       

早期广域网技术介绍:

       

       

早期广域网技术应用

早期的广域网技术主要是针对不同的物理链路类型,在数据链路层进行不同的二层封装。在CE与PE之间常用的广域网封装协议有PPP/HDLC/FR等,用于解决用户接入广域网的长距离传输问题。在ISP内部常用的广域网协议主要是ATM,它用于解决骨干网高速转发的问题。

       

       

广域网设备角色

       

       



HDLC

基本信息:

       

       

报文封装格式:

       

       

HDCL中ICMP报文封装格式:

       

       


HDLC环路与原因

       

       

首次查看一下产生的路由表,配置好路由之后,AR1设备会自动生成两条直连路由,其中一个是24位掩码的,下一跳是10.1.1.1 出接口是s1/0/0。

       

       

假设此时我们访问数据包访问10.1.1.3,因为广域网协议封装是没有ARP的概念的,不需要MAC地址信息,所以路由器会查找路由表信息,从s1/0/0口出去到达AR2                

       

AR2路由器收到之后也会查找路由器表信息。同理从自己s1/0/0口出去。                

       

此时环路产生。对此我们解决方法是配置掩码为30的网段,用来确保该网段只有只有两个IP可用,这样也符合P2P(点到点)的设计。如果要实现更加节约地址也可以配置31位掩码的地址。

实现同链路上不通网段IP通信

AR1 接口IP和AR2接口IP

       

                       

       

首先AR1是上是不具备AR2网段的路由,所以根本不可能发送出去ping包。

       

       

       

       

此时我们手工指定一条静态路由,这样对于路由器来说就知道如何发送出去数据报文了。

       

       

很明显通过抓包工具,路由器已经把ICMP报文发送出去了,但是没有回包;很显然是没有AR2路由器没有回包,为什么没有回包?同理AR2也是不知道如何回包,没有路由信息。此时需要我们相同操作指定路由。

       

       

       

       

       

       

路由写完之后就可以测试回包成功,完成通信。

   

IP-TRUNK

背景:HDLC的链路聚合,提升带宽,提高冗余。

       

       



[Huawei]int Ip-Trunk 1  //创建Trunk 1
[Huawei-Serial0/0/0]link-protocol hdlc   //注意前提要把链路协议改位HDLC
[Huawei-Serial0/0/0]ip-trunk 1 //绑定s0/0/0到trunk1



[Huawei]dis interface Ip-Trunk 1  //通过命令查看效果
..........




PortName                      Status      Weight
-----------------------------------------------------
Serial0/0/0                   DOWN        1
-----------------------------------------------------
The Number of Ports in Trunk : 1
The Number of UP Ports in Trunk : 0


之后的IP地址配置就可以到IP-trunk1里面配置

       

       

{批注:HDCL介绍完毕,开始PPP协议}


PPP协议

概述:

       

       

PPP链路建立的流程

       

       

PPP 报文格式

       

       

•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。

▫当Protocol字段为0XC021时,Information结构如下:

▪Identifier字段为1个字节,用来匹配请求和响应。

▪Length域的值就是该LCP报文的总字节数据。

▪Data字段则承载各种TLV(Type/Length/Value)参数用于协商配置选项,包括最大接收单元,认证协议等等。

•LCP报文携带的一些常见的配置参数有MRU、认证协议和魔术字。

▫在VRP(Versatile Routing Platform,通用路由平台)平台上,MRU参数使用接口上配置的MTU(Maximum Transmission Unit,最大传输单元)值来表示。

▫常用的PPP认证协议有PAP和CHAP,一条PPP链路的两端可以使用不同的认证协议认证对端,但是被认证方必须支持认证方要求使用的认证协议并正确配置用户名和密码等认证信息。

▫LCP使用魔术字来检测链路环路和其他异常情况。魔术字是随机产生的一个数字,随机机制需要保证两端产生相同魔术字的可能性几乎为0。


LCP正常协商过程

       

       

       

       

正常协商过程抓包、

       

       

根据标注,很明显分为LCP协商过程,NCP协商过程,因为没有配置认证,所以没有认证协商。

请求报文格式                

       

报文格式简单,PPP协议中protocol字段是0xc021代表后续是LCP协议,LCP协议携带字段简单,code ,ID,还有长度,其中option字段中携带了需要协商的参数。协商成功则回复ACK报文,具体内容如下:

       

       

需要值得注意的ID值和request报文的ID值相同,相对应。

NCP协商

PPP协议提供各种NCP(network control protocol)协议,如,IPCP,IPXCP用于各种网络层属性的协商更好的支持了网络层协议。

IPCP(IP控制协议)

IPCP,用于协商控制IP参数,使PPP可用于传输IP数据包。

IPCP使用和LCP相同的协商机制、报文类型,但IPCP并非调用LCP,只是工作过程、报文等和LCP相同。

静态IP地址协商

       

       

协商双方会相互发送request报文,如图。其中在请求报文中会携带接口IP地址。

       

       

       

       

对方收到request报文后会判断地址的合法性,因为报文中根本没有携带掩码信息,所以首先需要判断这个IP是否是一个合法的单播IP地址,并且这个单播地址和我本地配置的IP并不冲突。

如果判断合法,则回复一个configure-ACK报文。

R2在收到configure-request报文之后,还会在本地生成一条到达对端地址的直连主机路由。同理R1收到request报文也会生成直连主机路由。下一跳为127.0.0.1。

       

       

因为通告静态地址协商,生成去往对端的主机路由就可以实现即使同一链路的IP地址不在同一个网段也可以通讯。

 

动态IP地址协商

       

       

AR1配置


interface Serial1/0/0
    link-protocol ppp
   ip address ppp-negotiate    //用来配置接口通过PPP协商获取IP地址。


AR2配置


interface Serial1/0/0
link-protocol ppp
remote address 10.1.1.1    //远端地址
ip address 10.1.3.1 255.255.255.0


配置完成之后检查配置

       

       

检查报文

一开始的发送的请求报文的option字段中IP地址为0.0.0.0,AR2收到之后会发现这个该地址不合法就回复NAK报文

       

       

然后你会发现是通过nak报文把地址发送给对方

       

       

收到对方的nak后,修改为正确的IP地址,然后再次发送config request报文进行请求

       

       

参数合规,完成建立、

 

PPP认证协商

PAP认证

       

       

       

       

认证方:是提供认证服务的,携带用户名和密码的一方;

被认证方:需要被认证方认证的;

首先配置认证方AR2 上面的账号和密码


[R2-aaa]local-user HUAWEI service-type ppp
[R2-aaa]local-user HUAWEI password cipher huawei


然后启用进入接口视图启动PAP认证


[R2-Serial1/0/0]ppp authentication-mode pap


作为被认证方的AR1,自然需要提供正确的认证账号和密码才能认证成功而完成链路之间的建立。如果没有提供,则会产生错误信息。抓包如下:

       

                       

       

在回复的reject消息中的options字段显示认证参数协商不通过。这是因为一方面配置了认证参数,另一方没有配置认证,在LCP协商阶段会协商认证字段。

接着我在认证方接口配置中启动了PAP认证,但是输入的密码错误,这时候来看抓包


[R1-Serial1/0/0]ppp pap local-user huawei password cipher 123


       

       

根据抓包可知,当配置了错误的密码之后,会认证不通过,会被返回auth-nak报文。最后部分返回termination request报文断开连接,对于这两个报文,后续会介绍。

接下来我通过命令,修改为正确的用户名和密码


[R1-Serial1/0/0]ppp pap local-user huawei password cipher huawei


       

       

这时候就完成了LCP的协商,PAP认证协商,NCP(IPCP)的协商,最后通过echo request和replay保活。


CHAP认证


工作原理

       

       

报文:

挑战握手认证报文

报文类型:

Challenge:用于验证方向被验证方发送Challenge,发起验证过程。

Response:用于被验证方向验证方返回用户信息。

Success:用于验证方向被验证方发送认证成功信息。

Failure:用于验证方向被验证方发送认证失败信息。


这个是由认证方主动发起,其中challenge报文中会携带{ID+随机数(random)}发送给对方

       

       

对方收到这些参数之后会把{id+random+接口配置的密码}进行hash计算,计算会得出一个MD5值。该值具有唯一性。

接下来对方会回复response报文,报文中会携带{id+用户名+md5值}交给认证方

       

       

认证方收到之后,会根据response中携带用户名进行查找本地“账号数据库”根据数据库中的用户名所记录的密码,再次进行本地的hash计算,得出一个md5值。如果md5值相同,则认证通过。这是因为只有相同的账号和密码才会计算出相同的md5值。

       

       

配置

       

       

认证方:


aaa            //配置认证数据库
    local-user huawei password cipher huawei
    local-user huawei service-type ppp
interface Serial0/0/3    //接口启用CHAP认证
    link-protocol ppp
    ppp authentication-mode chap
    ip address 10.1.12.1 255.255.255.0    


被认证方配置:


interface Serial0/0/3
    link-protocol ppp
    ppp chap user huawei
    ppp chap password cipher hauwei
    ip address 10.1.12.2 255.255.255.0



如果认证方接口下配置了用户名,则认证方发送的challenge报文中会携带该用户名,但在计算md5值的时候并不参与,所以不会影响认证协商。

       

                       

                       

       

双方互为认证方和被认证方的情况

       

       

       

       


还有另一种情况,对于被认证方(R4)接口视图下没有配置密码的情况。

       

       

这时候被认证方会根据这个配置的用户名去查找本地账号数据库,也就是aaa视图下配置的账号和密码,根据aaa视图下的密码进行hash计算,然后进行认证。


MP-group

类似于IP-trunk用于提高带宽,提供冗余。

       

       

在配置mp-group之后,抓包也可以看到进行mp多链路的协商参数

       

       

PPPoE

PPPoE会话建立,有三个阶段,分别是PPPoE发现阶段,PPPoE会话阶段和PPPoE终结阶段

       

       

       

       

PPPoE发现阶段

       

       

PADI:PPPoE激活发现起始报文。通过广播的方式发送,因为网络中可能存在多个PPPoE服务器。

       

       

PADO:接下来会收到服务器发送来的PADO报文,该报文会携带服务器的MAC地址。此时session ID为0

       

       

PADR:客户端收到服务发送的PADO之后就会知道了服务器的MAC地址,我应该向谁去请求。所以客户端会发送PADR报文,进行请求。目的MAC是服务器的MAC。此时session ID为0

       

       

PADS:服务器收到客户端发送的请求报文后,就会回复PADS报文,这时候目的MAC是客户端的MAC;并且携带了session ID,很显然这个会话ID是服务器给客户端的。后续就会进入到PPPoE会话阶段

       

       


       

       


PPPoE会话阶段

       

       

在后续会话阶段,都会使用这个会话ID来表示整个会话。后续和PPP协商一样,不再赘余

       

       


PPPoE会话终结阶段

当PPPoE客户端希望关闭连接时,会向PPPoE服务器端发送一个PADT报文,用于关闭连接。

同样,如果PPPoE服务端希望关闭连接时,也会想PPPoE客户端发送一个PADT报文

PADT中通过携带session ID值来标识需要关闭的会话。

       

       



实验部分

       

       

AR1作为PPPoE_Client ;AR2作为PPPoE_Server;

实验理解

双方使用建立连接使用的是以太网线路,而我们的又会用到ppp协议,所以以太网链路是不能运行PPP协议的,所以我们通过使用一个虚拟的网口来建立连接。

所以我们把客户端的虚拟网口叫拨号口,服务端的接口叫虚拟模板,下面是配置。

客户端:拨号口

服务端:虚模板接口

       

       


interface Dialer0    //创建拨号口
    link-protocol ppp    //链路协议改为PPP
   ppp authentication-mode chap    //启用CHAP认证
    ppp chap password cipher 123
    ppp chap user  123
    dialer user 123    //启用拨号口的用户名
    dialer bundle 1    //拨号口与物理接口管理的ID,通过此ID可以实现与物理口相绑定
    ip address ppp-negotiate    //配置接口IP通过邻居协商获取


配置好拨号口配置后,然后把拨号口和物理口进行绑定


interface GigabitEthernet0/0/0
    pppoe-client dial-bundle-number 1


此时完成了客户端的配置,对于服务器端同样的道理。

配置aaa的账号和密码,这里不在描述



interface Virtual-Template1    //创建虚拟模板
    remote address 100.100.100.100 //设置给邻居的IP
    ip address unnumbered interface GigabitEthernet0/0/0 //公用0/0/0的IP地址
    ppp authentication-mode chap //启用CHAP认证


然后物理网口配置


interface GigabitEthernet0/0/0
pppoe-server bind Virtual-Template 1    //把虚拟网口板关联到物理网卡
ip address 100.100.100.99 255.255.255.0


       


       



广域网学习笔记的评论 (共 条)

分享到微博请遵守国家法律