思科怎么隐藏端口_思科 vs Juniper：哪家在GRE隧道用DF-bit？

弈心：从事计算机网络工作十年(新加坡7年，沙特3年)，2013年考取CCIE，在新加坡先后任职于AT&T，新加坡交通部，苹果，Equinix，苏格兰皇家银行等大型企业、银行和政府部门。 目前供职于“世界第一土豪大学“沙特阿卜杜拉国王科技大学(KAUST)，担任Senior Network Engineer，为KAUST校史上第一位也是唯一一位华人IT部门高级职员。2019年6月在知乎发布了华语圈第一本专门为编程零基础的网络工程师量身打造的Python教程《网络工程师的Python之路》。

读过我专栏文章的朋友都知道，笔者的文章都是庖丁解牛的风格，对问题的技术解析很深入，很透彻，凡是问题涉及到和稍微涉及到的知识点都会深挖到底，有理有据的进行分析和讲解，能够帮助读者朋友梳理、复习网络中各项热门、冷门技术的知识要点，保证大家在读完我的每篇专栏文章后都能学到一些不为大多数人所知的网络技术干货，本篇自然也不会例外。好了，废话不多说，下面进入正文。

背景：

某公司A使用的是MPLS网络，总部CE和分部CE之间跑的是GRE+eBGP， 所有设备包括CE，PE, P路由器全部为思科设备。公司A和公司B最近有业务往来，需要公司B加入公司A的MPLS网络，并且公司B的路由器也需要和公司A的总部CE建立GRE隧道和eBGP连接，唯一不同的地方是公司B连接外网的路由器是Juniper的。

公司B加入MPLS后的拓扑如下：

公司B加入MPLS后网络一切正常。某天公司A的网络安全部门要求在所有CE连接外网的物理端口(即CE连接PE的端口)上做ACL，用来阻挡所有ICMP包。

问题：

在所有CE上阻挡了ICMP包后，全部为Cisco路由器的总部CE和分部CE之间的链路没有任何问题，唯独总部的Cisco CE和公司B的Juniper CE之间的BGP一直不停地发生剧烈震荡, bgp邻居关系不停地up/down，严重影响了公司A和公司B之间的网络连接。

下面是每个CE的配置详情，请问为什么Cisco CE之间没有问题，唯独和Juniper CE之间的BGP发生了震荡？如何解决？

总部Cisco CE的配置

公司B的Juniper CE配置

分部Cisco CE的配置

解析：

为了不浪费大家的时间，首先告诉大家上面的配置没有任何问题，不用去纠结Juniper的配置是否有问题。

要分析这道题首先要考虑在路由器连接外网的端口上deny掉所有ICMP包会有什么后果，安全性提高了？ping和traceroute不通，造成以后排错困难了？这几点都没错，但是除了这几点外还有一点估计是大家不太熟悉的：ICMP包被阻挡后， PMTUD(Path MTU Discovery,路径MTU发现)也会受影响。PMTUD相信大家不会陌生，它是基于ICMP，用来动态侦测路径MTU大小的工具，它取路径上每一跳的MTU之中的最小值，让主机做参考来调整自己的MTU大小，避免主机的流量被路径中的路由器分片(fragmentation)。

那么PMTUD受影响会发生什么情况？它会影响代表Fragmentation Needed(需要分片)的ICMP code 4 (ICMP包代码4)和代表Destination Unreachable (目标不可达)ICMP type 3 (ICMP包类型3)的这两条重要ICMP信息，导致接收端收不到这两条信息。这和这道问题有什么关系？接着往下面看就知道了。

这道题有个信息笔者在背景里没有给出来，目的是为了提高这道题的难度，那就是笔者在搭建拓扑的时候并没有修改MPLS网络的MTU，导致MPLS网络内部的MTU仍然为默认的1500。

首先来回顾一下MTU的知识点，这是突破这道题的关键点之一(注意是“之一”)：

• 以太网的MTU默认为1500 bytes，如果算上二层封装则为1518 bytes = 1514 Ethernet Header + 4 checksum
• GRE的MTU默认为1476 bytes, 1500去掉20 bytes的IP header(外)以及4 bytes的GRE header
• 默认情况下，TCP MSS(Maximum Segment Size)的大小为MTU - 40 bytes，这40 bytes由20 bytes的IP header和20 bytes的TCP header构成。举例来说，以太网端口的MSS为1500 - 40 = 1460 bytes, 被GRE封装的端口的MSS为1476 - 40 = 1436 bytes。
• MPLS网络默认为IP报文添加两个标签，一个transport label，一个VPN label，每个标签均为4 bytes, 所以MPLS的默认MTU为 1500 - 4 -4 = 1492 bytes ，请不要和下图的1508 bytes搞混，1508说的是在MPLS的PE和P路由器上需要配置的MTU(这样通信终端依然可以继续使用以太网默认的1500 bytes，而不会被PE分片)，如果MPLS的MTU不变，依然为1500的话，那就需要通信终端设备自降MTU到1492 bytes, 这样PE在加上8 byte的两个标签后，终端设备的流量依然能以1500 bytes的体积“畅游” MPLS网络，而不会被PE分片。

下图为这道题里的数据包MTU详细分解：

为什么这里1436 bytes的MSS我特意提到了BGP Update？一是为了提醒读者，BGP是基于TCP的应用，二是不要忘了这道题里Cisco CE和Juniper CE之间的BGP连接有持续震荡的问题。

关键点来了：

根据上图，当CE的BGP Update包到达PE后，该包的大小为1436 + 20 (TCP header) + 20 (内部IP header) + 4 (GRE header) + 20 (外部IP header) = 1500 byte，因为PE还要给该包加上8 byte的两个标签，导致该包的实际MTU，即1508 bytes大于了这道题里MPLS网络的MTU即1500 bytes, 导致PE必须对该BGP Update包做分片了。

PE这个时候开始为难了，PE此时的内心独白如下：

你CE发了个超出MPLS MTU值的BGP Update包给我，还不允许我分片，你要我怎么办？ 那对不起，我只能丢包了，但是丢包前我会建议你修改你的MTU大小，改到多少呢？ 1492 byte就行了，这样我给你的包加上两个标签刚好为1500 byte，刚刚等于我们MPLS的MTU值。

空口无凭，整个PE的内心戏可以用下面从Juniper CE和它直连的PE流量中抓来的包，以及在PE上的日志来佐证和演示：

注意看抓包红色部分里有前面提到的ICMP Type 3 (Destination unreachable)和 ICMP Code 4 (Fragmentation needed)

DF-Bit, 这道题的突破关键点之二：

为什么这里Cisco CE之间的BGP连接没有问题？ 不是因为它们听从了PE的建议把MTU改成1492了(PMTUD现在因ICMP流量被阻挡已经不工作了)，而是因为：默认状态下，思科路由器不会对GRE隧道端口的流量开启DF-bit，这样的话PE就可以对CE的BGP Update包做分片了，而不会去丢弃它！ 虽然分片也不是什么好事情，但不管怎么说，分片总比直接丢包强，所以Cisco CE之间的BGP连接没有问题。

而Juniper则刚好相反，默认状态下J家的路由器会对GRE隧道端口的流量开启DF-bit，又因为现在PMTUD不工作了，Juniper不会把MTU改成1492，导致PE只有把Juniper CE发来的BGP Update包丢弃了，从而导致公司A总部的Cisco CE和公司B的Juniper CE之间的BGP持续发生up/down的震荡。

如果你想深入了解BGP震荡发生时的状况，可以参考下图

总部CE的BGP连接情况，两点值得注意：

1. 从Juniper学到的bgp前缀为0
2. Up/Down永远不会大于1:29，也就是BGP默认的holdtime(90秒)。

Juniper这边的情况：

1. 同样学到了0条前缀。
2. Up/Down同样永远不会大于1:29，也就是BGP默认的holdtime(90秒)。
3. 注意Flaps counter为非零 (10)。
4. 注意看Juniper这边的firewall日志显示Juniper拒绝了"Destination Unreachable" (ICMP type :3) 和"Fragmentation Needed" ( ICMP code:4 )包，导致PMTUD失效！
5. deny-icmp这个ACL的计数器显示总共有92个这样的包被Juniper丢弃了！

解法：

这道题有多种解法，解释如下：

解法1：把MPLS的MTU改为1508

解铃还须系铃人，最简单的方法就是把MPLS的MTU值改为1508(实际网络中运营商通常会改成1516， 来匹配总共4个标签，但是为了配合这道题，这里改成1508)

解法2: 在Juniper上修改ACL, 允许Juniper CE接收"Fragmentation Needed"和"Destination Unreachable"两条重要的ICMP信息。

前面已经分析到了代表Fragmentation Needed(需要分片)的ICMP code 4 (ICMP包代码4)和代表Destination Unreachable (目标不可达)ICMP type 3 (ICMP包类型3)的这两条PMTUD重要组成部分的ICMP信息有多重要了，开启它们就等于开启了PMTUD，Juniper就会顺应PE的建议把MTU改成1492 bytes了。

新的ACL生效，ICMP type 3和code 4被Juniper“放行“了！

解法3: 在Juniper上的GRE隧道端口上关闭DF-bit，允许分片

这个没什么好说的，一切向思科学习！

解法4: 在总部CE修改MSS

通过修改MSS来达到修改MTU，从而避免分片已经是老生常谈的话题了，这里也不多做解释了。

结语：

这篇文章涉及的知识点还是很丰富的，有几点值得注意的总结如下：

1. C家和J家在GRE隧道上一个默认开启df-bit,一个默认没有开启，这个不自己亲身做实验经历一次估计是一辈子都不会知道的。
2. 一刀切关掉ICMP并不是不行，但是有个前提：保留"Fragmentation Needed"，这个也是行业里公认的best practise.
3. MPLS的MTU配错的情况在实际网络中很少发生，这是我在做实验的时候歪打正着自己给自己挖的坑，但是也给自己上了一课。
4. MTU是网络的重中之重，很多“莫名其妙”的问题都是因为它引起的，作为网工必须把它吃透。
5. 多用抓包去排错，抓到的包认真的去读，花时间去研究，对任何问题都要做到“知其然还要知其所以然”。
6. 网络出了任何问题不要只知道看配置找原因，搜集信息，知道近期网络发生了什么变化，能够举一反三知道该变化会带来什么后果。做个有责任心，有能力的网工比什么都重要。