CCIE LAB K4 试验分解系列1 – PPPOE

zhenglxd · 发表于 2012-6-2 09:37:26

                                                      <<CCIE LAB K4 试验分解系列1 – PPPOE>>
                                                                        作者：  -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来完成。
<a>什么叫避免不必要的分段？
通常我们会把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的。

<b>那么如何解决这个所谓的”避免不必要的分片”呢？
首先将PPPOE的MTU设置为1492，可以起到优化的作用
其次为了保护TCP，通常我们会把部署PPPOE时，将MSS（最大分段大小）的值设置为1452
<c>那么什么是MSS？MSS的值为1452是怎么来的呢？
我们知道TCP是一个传输层的协议，传输层的主要任务就是进行分段，就好比你要把一根长度为100米的木头，想从一个地方运到另外一个地方。但由于木头太长了，所以在传输层你要负责把这条很长的木头切成很多段，切完后在网络层将他打包进一个个集装箱中，但是如果你这个分段的长度，比集装箱还长怎么办？是不是就放不下了？于是在网络层就要进行再分片，这样就会导致，如果你的集装箱只能容纳每个长度为10米的分段，而如果某个木头长度为11米，那么木头要被切成2段，1段10米被装进一个集装箱，另外一端1米的被装进另外一个集装箱。显然对于后者，你用一个原本能装10米的集装箱去装一个1米的木头是资源的浪费。而且你要多运一个集装箱才行！
而所谓的MSS值就相当于控制了你这个数据在传输层被分段所允许的最大值。显然如果大于MTU了，就好比上文的这块木头长度是11米，而集装箱只能装10米这样一个情形。

<d>最后说下1452这个值是怎么来的，和为什么要用1452这个数字？
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

有趣的现象：
dialer persistent和diale idle time out 0作用都能实现不需要感兴趣流使接口永远UP，但是cisco官方文档有这样一段话我按原文贴：
cisco原文：
Dialer Persistent
The Dialer Persistent feature allows the connection settings in the dialer profile to be configured as persistent, that is, the connection is not torn down until the shutdown interface command is entered on the dialer interface.
The dialer idle-timeout interface configuration command cannot be configured when the dialer persistent command is configured
注意看颜色加深的那一句话，意思是如果你配了Dialer Persistent ，那么diale idle time out 0是不能配的，但是其实你如果去show run看配置话会发现，只要你接口敲了Dialer Persistent，那么diale idle time out 0会自动的配上去，并且删除不了！
例如：
R2#sh run interface dialer 1
Building configuration...

Current configuration : 185 bytes
!
interface Dialer1
mtu 1492
ip address negotiated
encapsulation pppm
ip tcp adjust-mss 1452
dialer pool 1
dialer idle-timeout 0
dialer persistent
ppp chap password 0 cisco

R2(config)#int dialer 1
R2(config-if)#no dialer idle-timeout 0
%Remove dialer persistent command first

出于研究目的，我再提供一个在纯IOS 12.3上的一个PPPOE配法，大家可以和上面12.4的命令做个对比，由于目前有很多机构的PPPOE解法，“所谓的满分解法”都是混杂了12.3和12.4的解法一起的，但其实很多命令都是垃圾配置（针对12.3 IOS的）根本不起效，只不过不影响结果而已。大家如果有拿到的话也可以和我的解法对比下，自然知道哪个更加可靠一些了。
IOS 12.3的PPPOE配法：此解法仅仅是处于研究的目的，没有任何的考试价值，也遵循最小化原则
拓扑与需求和上面一致,这个实验我是在dynamips CCNP标准版上做的，所以接口都变成F0/0了。
解法：
R1
username R2 password cisco
vpdn enable
vpdn-group pppoe
accept-dialin
  protocol pppoe
  virtual-template 1
exit
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
int f0/0
ip add 10.1.12.1 255.255.255.0
pppoe enable
no sh

R2
vpdn enable
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
int f0/0
pppoe-client dial-pool-number 1
no shut

效果：
R2#sh ip int bri
Interface                IP-Address    OK? Method Status             Protocol
FastEthernet0/0          unassigned    YES unset  up                   up
Serial1/0                unassigned    YES unset  administratively down down
Serial1/1                unassigned    YES unset  administratively down down
Serial1/2                unassigned    YES unset  administratively down down
Serial1/3                unassigned    YES unset  administratively down down
Serial2/0                unassigned    YES unset  administratively down down
Serial2/1                unassigned    YES unset  administratively down down
Serial2/2                unassigned    YES unset  administratively down down
Serial2/3                unassigned    YES unset  administratively down down
Virtual-Access1          unassigned    YES unset  up                   up
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 = 8/20/44 ms

五. 结束语、下周预告、联系方式:

任何技术有争论才有学习和进步，当然是在文明用语的前提下，所以大家如果有疑问的地方，或者你觉得我说错了，有哪些地方需要改经，可以跟贴留言，或在我的微薄留言，或者直接qq联系我，我如果看到了一定一一给大家回复。

下周预告：
下周会对K4中的802.1q tunnel进行相关的扫盲和技术讲解解法揭秘！

qq360870025 · 发表于 2012-6-2 10:08:52

本帖最后由 qq360870025 于 2012-6-2 10:12 编辑

这下懂了，之前一直不明白为什么要设置TCP的大小，楼主好比喻啊
期待楼主的下周 802.1q tunnel 的讲解
{:soso__14993238364229783703_1:}

zhenglxd · 发表于 2012-6-2 10:11:04

嘿嘿
如果有其他疑问可以留言，我看到了一定给予回复

xdjs · 发表于 2012-6-2 17:02:34

fanjiass · 发表于 2012-6-2 19:44:16

不错，非常有营养的帖子

疯狂的尼采 · 发表于 2012-6-2 20:40:23

xpiebus · 发表于 2012-6-3 02:08:55

pppoe

qihouyang · 发表于 2012-6-5 22:46:44

果断收了

天沐 · 发表于 2012-6-5 22:23:50

MaoErQuan · 发表于 2012-6-5 17:51:59

好帖子，最近K4很多人在说，看得云里雾里的。

voice12 · 发表于 2012-6-5 16:15:30

SteinerChen · 发表于 2012-6-3 05:05:18

好东西，学习了~~~

tiq · 发表于 2012-6-3 22:54:08

谢谢了，这么好的帖子留着

huangtidi · 发表于 2012-6-4 11:48:44

lzx911102 · 发表于 2012-6-7 21:36:32

账号		自动登录	找回密码
密码			论坛注册

CCIE LAB K4 试验分解系列1 – PPPOE

评分

相关帖子

客服中心

投诉建议

${:1_1:}$