<
作者: -NULL
上海亚威原创,转载请注明出处
一. 前言:
相信CCIE RS试验考试目前最火的话题就是K4了,K4的需求和解法,国外国内网上都有,但解法终究是解法,其解题的思路,网上资料甚少,甚至出现一套题多解法的现象。 而我写这个文章的目的,仅仅是针对LAB中比较有歧义,比较冷门或者比较有趣的的技术和现象,以及对多解法的各种利弊,抛砖引玉,和大家进行探讨, 如果时间够,预期我会把RS整个考试中所有LAB 和TS 都为大家进行一个所谓的解法揭秘,当然这是在不违反cisco保密条例的情况下,具体的一些其他信息大家可以留意我的最新微博,里面还有一个我对RS 4.0的考纲的分析。
当然虽然打着考试的口号,但是其实研究重点还是技术!所以也请大家不吝赐教!
作者和读者的约定:
我的解法会以试验分解的形式,是指我把我解题的试验思路一步一步分解出来,特别是有歧义的地方,在这里我们可以自由的进行探讨,不管你有任何天马行空的想法。 最后我还会以附件的形式上传此文档的主要内容,我的所有文档都保证是原创,并且该文档可以被任意转载,修改,但请不要删除我的logo。转载请注明出处和首发,文章只针对技术,不针对任何个人和团体。
我以黄色背景加粗标出的意味着这句话或后面的内容或段落是比较有趣或者重要的知识点 为了避免产生歧义,下文中我所谓的PPP头部实质是指不含以太帧头的纯PPPOE头部
二. 简单的技术介绍: PPPOE :PPP over ethernet
简单讲就是在以太网上跑PPP,因为以太网是非常成熟,廉价和易部署的协议,例如用户只要把网线插入交换机就可以实现互联,所以他很流行,但是缺点是,他没有基于链路层的认证机制,而恰恰PPP有,所以PPPOE简单讲就是利用以太帧头做为传输工具,而内嵌的PPPOE头部作为认证工具,当然PPPOE还可以做一些其他扩展,例如地址分配,计费等。
三. 需求分析和知识点扫盲:
K4中的PPPOE:
大致的需求是这样的:
拓扑:R1---R2(用F0/0互连) 假设R1是PPPoe的server,R2是PPPoe的client,要求即使没有感兴趣流,链路依然是UP,并且R2的F0/0始终能通过PPPoe从R1获得一个IP 10.1.12.2/32 不允许使用DHCP来分配该地址 避免不必要的分段
Client必须使用chap与server进行认证,使用的hostname 为自身主机名,密码可以随意配
需求分析和知识点扫盲:
R1和R2部署PPPoE,R1是server,R2是client,R2是认证方要求R1 进行认证,认证的协议是chap,认证的依据是本地数据库以R2做为hostname,password可以随便写
并且要求即使没有感兴趣流,链路依然UP,这里我解释下PPPoe之所以称为拨号技术,因为通常他是以感兴趣流去触发拨号的,就好比以前我们要上网需要在windows上去建立一个所谓的拨号连接,输入ISP给你的用户名和密码,然后点击拨号,并且最早以前是按照流量或者时间计费的,所以可以设置一个功能,就是一旦链路UP后,如果一段时间内没有用户的流量,那么链路可以自动断开,从而节约客户的宽带成本,而K4所谓的不需要感兴趣流,简单讲就是好比现在我们比较流行的就是那种你的PC一开机,windows不需要额外的什么配置,就立刻可以上网了,因为相关设置其实路由器上都帮你配好了,而且不管你有没有所谓的感兴趣流,他的链路永远是UP的,因为现在的用户大部分都是包年报月的,宽带的带宽和价格也都非常便宜,所以没有必要设置所谓的超时断开了。断开了也不会为客户节约什么钱。
而且PPPoe是具有地址协商功能,可以主动给client去下方一个/32的主机地址,所以有的时候你发现的你的PC掩码是255.255.255.255不要奇怪很正常,虽然正常情况下你在windows里是配不上/32的掩码的。当然下发地址的方式有很多,既然说了不允许用DHCP,那么可以用pppoe pool来完成。 什么叫避免不必要的分段?
通常我们会把PPPOE的相关接口MTU设置为1492,因为PPP的头部大小是8个字节,而正常的以太接口的MTU是1500。如果有一个满负荷的数据(即大小已经是1500字节了)那么你再去内嵌一个ppp头部会导致mtu大于1500,然后超出的部分会被强行分片,而分片会带来若干的坏处:
1.分片很消耗路由器硬件资源
2.为了重新封装那超出的8个字节的分片,你要重新将其进行多层封装,而所谓的封装就是指每一层都要加载不同的PDU(例如3层叫IP,2层叫帧),最终可能你会发现,你用于封装所占用的带宽,会远远高于那8个字节的分片。就好比我们知道飞机场是按照你托运行李的重量去收费的,而你拿一个很重的保险箱,但其实这个保险箱里仅仅存了一块钱,你为了运这个一块钱,其实却花了更多的钱。但其实通过将MTU改为1492,仅仅是作为一个优化,并不能改变分片的情况,例如你有一个数据本身就很大了,比如已经是1500字节了,那么如果你的MTU是1500,一旦内嵌了PPP头部后发现MTU为1508大于设置的MTU 1500了,执行封片。而你如果把MTU设置为1492,就意味着如果一个1500字节大小的包过来,立刻就发现MTU大于1492了立刻就直接进行分片,节约了一个封装的步骤,所以这只能说是优化不能说是解决这类问题
3.某些应用是不允许分片的,我们知道IP包内有一个字段叫做DF位,或者叫分片位,默认该位的值为0,意思是允许分片,反之如果该位为1了就代表拒绝分片,此时如果一个数据包必须分片的话,就会导致丢弃,如果是一个TCP的应用,丢弃可能会导致会话建立失败,或断开。因为UDP是无连接的,所以分片会非常实际的对TCP产生影响。所以你要理解所谓的避免不必要分段,是针对TCP的。
那么如何解决这个所谓的”避免不必要的分片”呢? 首先将PPPOE的MTU设置为1492,可以起到优化的作用
其次为了保护TCP,通常我们会把部署PPPOE时,将MSS(最大分段大小)的值设置为1452
度为100米的木头,想从一个地方运到另外一个地方。但由于木头太长了,所以在传输层你要负责把这条很长的木头切成很多段,切完后在网络层将他打包进一个个集装箱中,但是如果你这个分段的长度,比集装箱还长怎么办?是不是就放不下了?于是在网络层就要进行再分片,这样就会导致,如果你的集装箱只能容纳每个长度为10米的分段,而如果某个木头长度为11米,那么木头要被切成2段,1段10米被装进一个集装箱,另外一端1米的被装进另外一个集装箱。显然对于后者,你用一个原本能装10米的集装箱去装一个1米的木头是资源的浪费。而且你要多运一个集装箱才行!
而所谓的MSS值就相当于控制了你这个数据在传输层被分段所允许的最大值。显然如果大于MTU了,就好比上文的这块木头长度是11米,而集装箱只能装10米这样一个情形。
1500-20-20-8=1452 ,1500自然是以太网默认的MTU值,第一个20是TCP头部的大小,第二个20是IP头部的大小,第三个8是PPP头部的大小
那么显然你通过修改MSS值强制把TCP的分段设死在1452,也就是你这个分段大小最大也就是1452,那么这个分段被组帧的时候算上各层封装的消耗,最大字节数就是1500,并且是内嵌ppp头部时情形,也就意味着,不可能会出现在PPPOE上部署的TCP时,流量被分片的情形了!
四. 解法:
针对此需求我认为的最优解法是什么? 需求:
拓扑:R1[f0/0]-----------R2[f0/1] R1的F0/0 IP地址为10.1.12.1/24 ,他要给R2分配的IP为10.1.12.2/32
假设R1是PPPoe的server,R2是PPPoe的client,要求即使没有感兴趣流,链路依然是UP,并且R2的F0/0始终能通过PPPoe从R1获得一个IP 10.1.12.2/32 不允许使用DHCP来分配该地址 避免不必要的分段
Client必须使用chap与server进行认证,使用的hostname 为自身主机名,密码可以随意配 解法:此解法针对cisco目前考试最新的IOS 12.4,此解法可100%得分,此解法遵循最完善最小化配置原则,即没有作用的命令不配 R1
username R2 password cisco vpdn enable
bba-group pppoe global virtual-template 1 exit
int f0/0
ip add 10.1.12.1 255.255.255.0 pppoe enable group global no sh
interface Virtual-Template1 encapsulation ppp mtu 1492
ip tcp adjust-mss 1452
ip unnumbered FastEthernet0/0 peer default ip address pool pppoe ppp authentication chap
ip local pool pppoe 10.1.12.2 R2
vpdn enable int f0/1
pppoe-client dial-pool-number 1 no shut
interface dialer 1 encapsulation ppp ip address negotiated dialer pool 1 dialer persistent mtu 1492
ip tcp adjust-mss 1452 ppp chap hostname R2 ppp chap password 0 cisco
效果
R2#sh ip int bri
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 unassigned YES unset administratively down down FastEthernet0/1 unassigned YES TFTP up up
Serial0/0/0 unassigned YES unset administratively down down Serial0/1/0 unassigned YES unset administratively down down Virtual-Access1 unassigned YES unset up up
Virtual-Template1 unassigned YES unset down down Virtual-Access2 unassigned YES unset down down Dialer1 10.1.12.2 YES IPCP up up R1#p 10.1.12.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.12.2, timeout is 2 seconds: !!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
有趣的现象:

