国外流传的一道CCIE挑战题,这道题难度不低,出题的人是一位罗马尼亚裔的美籍CCIE。为了防止作弊,所有参与者的回答都被出题人屏蔽,自己和出题者交流了一会,在得到所有自己所需要的信息后,花了几天的时间做模拟实验,找相关资料研究,最终给出了正确的答案。出题者肯定了我的解法,但是提醒我解法不止一种,并向我解释了其他的解法,自己受益颇多,对ACL和Fragmentation(数据包分片)也有了更深层的理解。
先来看看这道题的拓扑,背景信息以及问题。
图1
![从一道CCIE挑战题深入理解ACL和数据包分片](https://www.spoto.net/uploadfile/2018/0622/20180622041847242.jpg)
图2
![从一道CCIE挑战题深入理解ACL和数据包分片](https://www.spoto.net/uploadfile/2018/0622/20180622041915367.jpg)
背景信息:
1. 某公司有三个site,分别为R1,R2,R3。
2. R3和R2之间跑GRE隧道,R2和R3的interface tunnel的MTU被人为的从1476改为1440.
3. R2和R1之间有两条connection,一条是它们两个互相直连的Backdoor(192.168.12.0/24),另外一条是通过ISP走Internet,R2-ISP-R1,走Internet的流量做了NAT(严格来说是PAT),走Backdoor的流量没有NAT。
4. 用户(172.16.1.10)直连R3,服务器(1.1.1.10)直连R1,服务器上运行的程序需要用到TCP port 1001和1002.
5. 需求: 如图2所示,在R2上用PBR分流,实现TCP 1001的流量走R3-R2-R1, TCP 1002的流量走R3-R2-ISP-R1。
问题:
图1给出了R2的配置,测试结果是走R3-R2-R1这条route的TCP1001的流量正常(图3),走R3-R2-ISP-R1的TCP 1002的流量则有问题:TCP三次握手已经完成,但是session随后卡住,不久之后session timeout(图4),需要找出原因并给出解法。
图3(TCP1001流量正常)
![TCP1001流量正常](https://www.spoto.net/uploadfile/2018/0622/20180622041957122.jpg)
图4(TCP1002流量:TCP三次握手成功,但是随即卡住并Timeout)
![TCP1002流量:TCP三次握手成功,但是随即卡住并Timeout)](https://www.spoto.net/uploadfile/2018/0622/20180622042016812.jpg)
解题思路:
1.
首先通看一遍出题者给的R2的配置,没发现什么大问题。因为既然用户端(172.16.1.10)和服务器(1.1.1.10)之间的TCP 1001和1002两种流量的TCP三次握手都成功完成了,那就说明了无论是路由,PBR,GRE隧道,还是PAT等等的配置都没有任何问题。
2. 重新读一遍题目的背景信息,其中第二条引起了我的注意:“R2和R3的interface tunnel的MTU被人为地从1476改为1440”。众所周知,GRE隧道的header是24 Byte,所以通常来说GRE隧道端口的MTU是1500-24=1476 Byte (前提是配置GRE之前,物理端口使用的MTU是默认的1500),那么再被人为地改为1440之后有什么影响呢?这里有很重要的一点要考虑,那就是用户端(172.16.1.10)是否开启了PMTUD(Path MTU Discovery),也就是“路径MTU发现”的功能,因为这直接影响到用户端的IP包在经过R3时会不会因为前后MTU的不匹配而导致被R3进行Fragmentation (IP数据包分片),因为通常来说,Fragementation有一个很大的缺点,那就是它大大降低了网络的传输性能,会引起很多诸如丢包,延时,线路不稳定,甚至连接失效的问题,对于这个问题,因为出题者在背景信息里没有明确说明,我特此询问了他,得到的回答是,在他的实验环境里,用户端(172.16.1.10)实际上是一台跑FreeBSD的服务器,他在用户端通过PMTUD探测到了GRE的MTU(1476)之后,故意关闭了PMTUD,并给我解释他之所以没在背景信息里给出这个条件,目的就是为了提高这道题的难度,并说我能考虑到这点,说明我的思路是对的,叫我继续做下去。
3.顺着这个思路继续往下看,现在用户端的MTU是1476(PMTUD被关闭之前学到的),PMTUD被关闭后,用户端无法重新探测到R2和R3的GRE隧道的新MTU(1440),所以用户端还是照旧把1476的包丢给R3,又因为1476大于1440,导致这时R3不得不对用户端的包做IP分片了。这就导致了R2从R3接收到的用户端的包其实是一大堆fragments(IP碎片)。考虑到这里后,虽然自己清楚IP分片会导致各种各样的链路问题,但针对这道题来说,究竟是什么导致了TCP1002流量的问题,自己曾一时毫无头绪。
4. 既然用户端的包有被R3做IP分片的事实存在,那么为什么走R3-R2-R1的TCP 1001的流量没有问题,唯独走R3-R2-ISP-R1的TCP 1002却有问题呢?带着这个疑问,回头再看R2的配置,下面这个被PBR用来分流的ACL引起了我的注意。
ip access-list extended ACL_USE_BACKDOOR
permit tcp host 172.16.1.10 host 1.1.1.10 eq 1001
exit
这个ACL表达的意思一目了然:匹配所有从用户端172.16.1.10去往服务器1.1.1.10,TCP端口为1001的数据。乍一看没有任何问题,实则这里面隐含了一个巨大的玄机,那就是当4层ACL遇到IP碎片时所产生的一些列“化学反应",要搞清楚这个,必须先弄明白IP碎片到底是怎么一回事,为此我特意画了下面两个图来说明。图5为正常情况下,没有被路由器fragmented的一个完整的IP包(MTU为1500),图6则是这道题里,已经被R3(MTU 1440)做了IP分片后的用户端的包(MTU 1476),分别为“第一个碎片”和“第二个碎片”
图5
![从一道CCIE挑战题深入理解ACL和数据包分片](https://www.spoto.net/uploadfile/2018/0622/20180622042052429.jpg)
图6
![从一道CCIE挑战题深入理解ACL和数据包分片](https://www.spoto.net/uploadfile/2018/0622/20180622042112294.jpg)
5.图5很好理解,通常一个完整IP包的MTU是1500 Byte,扣去3层的IP header (20 Byte,蓝色部分)和4层的TCP header (20 Byte,橙色部分),剩下的data payload为1460 Byte, 这个1460 Byte在TCP里又叫做MSS (Maximum Segment Size,注意只有TCP有MSS,UDP没有这个东西),MSS是后话,暂且不表。
6. 图6是解出这道题的关键所在。第一个碎片(1440 Byte)和第二个碎片(56 Byte)的区别一目了然,第一个碎片有4层header(橙色),第二个碎片没有,这种情况对1001和1002的包有什么影响呢?详解如下:
首先再回顾一次这个ACL,看它对TCP 1001和TCP 1002两种IP碎片包产生了什么影响:
ip access-list extended ACL_USE_BACKDOOR
permit tcp host 172.16.1.10 host 1.1.1.10 eq 1001
exit
TCP 1001的第一个碎片,Src IP = 172.16.1.10, Dst IP = 1.1.1.10, Src tcp port = any, Dst tcp port = 1001,符合ACL的条件,R2对这个碎片做PBR,即将它丢给R1。
TCP 1001的第二个碎片,Src IP = 172.16.1.10, Dst IP = 1.1.1.10, 依然符合ACL的条件,R2对这个碎片做PBR,即将它丢给R1。
TCP 1002的第一个碎片,Src IP = 172.16.1.10, Dst IP = 1.1.1.10, Src tcp port = any, Dst tcp port = 1002,不符合ACL的条件,R2对这个碎片做PAT,将它丢给ISP。
TCP 1002的第二个碎片,Src IP = 172.16.1.10, Dst IP = 1.1.1.10, 符合ACL的条件,R2对这个碎片做PBR,即将它丢给R1。
结论:
A.TCP 1001的第一个和第二个碎片都满足ACL,都被R2的PBR丢给了R1,R1再将两个碎片包传给服务器1.1.1.10,所以TCP 1001的流量正常。
B.TCP 1002的第一个碎片(1440 Byte)没有满足ACL,被R2的PBR丢给了ISP,第二个碎片(56 Byte)满足了ACL,被R2的PBR丢给了R1,现在两个碎片被活生生的拆散开了,两个碎片包“分道扬镳”的结果造成了TCP 3次握手成功,但是随即timeout的问题。
解法:
前面已经很系统地分析出了问题所在:因为用户端关闭了PMTUD,再加上R3和R2的MTU从1476被改小到1440,导致MTU不匹配,从而引发了R3对用户端的包进行Fragmentation(IP 分片)的行为,而又因为R2上配置的4层ACL导致了TCP 1002的第一个和第二个碎片包被R2分别丢去了ISP和R1,导致碎片无法复原,最终造成TCP 1002数据的连接问题。
弄清楚了问题出在哪里后,接下来就是对症下药了,这道题解法有多种,一一解释如下。
解法1
用户端172.16.1.10开回PMTUD,让用户端学习到新的MTU(1440),从而避免fragmentation。这是最直接也是最简单的解法,这也是为什么出题者在背景信息里没有给出“关闭了PMTUD"这个条件,不然的话,每个人都回答“开回PMTUD",那这道挑战CCIE的题还有什么挑战性可言?
解法2
在R3端口上修改MSS,命令为ip tcp adjust-mss,避免fragmentation。
前面简单提到过MSS这个东西,关于MSS,一些总结如下:
1. MSS出现在TCP的SYN包里, 它和UDP无关。
2.MSS和MTU的区别在于,MSS是TCP数据包每次能够传输的最大数据分段,它永远比MTU小40 Byte,这40 Byte是什么?前面的图5已经解释过了,即3层包头(20 Byte)和4层包头(20 Byte)。以这道题为例,用户端包的MTU 为1476,那么它TCP SYN包里的MSS就为1436。
3. 顾名思义,思科的ip tcp adjust-mss这个命令的作用就是用来修改MSS大小的,以这道题为例,在R3上配置ip tcp adjust-mss 1300,当用户端的包(MSS 1436)到了R3上后,因为1436>1300,这时R3就会把用户端TCP包的MSS修改为1300,然后丢给R2, R2看到1300<1400,也就不会再对这个包做IP分片了,从而避免了fragmentation。
4. ip tcp adjust-mss这个命令是在端口下配置,至于配置在哪个端口,没有硬性规定,就这道题来说,把它配置在直连用户端的端口或者连接R2的端口上都可以,效果一样。
解法3
修改PBR的ACL,让TCP 1002的碎片也走R3-R2-R1。
Ip access-list extended ACL_USE_BACKDOOR
permit tcp host 172.16.1.10 host 1.1.1.10 eq 1001
Permit tcp host 172.16.1.10 host 1.1.1.10 eq 1002
这个解法不完美,主要有两个原因:
1. 违反了题目的规定,即TCP 1002的流量要走R3-R2-ISP-R1。
2. 这个解法治标不治本,因为将来如果遇到其他TCP端口的类似需求怎么办,一直违背分流的初衷?
解法4
修改PBR的ACL,逼迫TCP 1002的碎片被PAT,然后走R3-R2-ISP-R1。
ip access-list extended ACL_USE_BACKDOOR
deny tcp host 172.16.1.10 host 1.1.1.10 eq 1002
permit tcp host 172.16.1.10 host 1.1.1.10 eq 1001
这个解法同样不完美,原因很简单,TCP 1001的第一个碎片没问题,但是第二个碎片也被丢给了ISP,同样的问题又发生了,只是这次出问题的是TCP 1001。