[原创] GRE-Over-IPSec VPN实施中需要规避的问题

案例：GRE-Over-IPSec VPN实施中需要规避的问题【组网拓扑】
SecPath1000―――100M―――Internet―――100M―――SecPath100V

|

|

100M

|

|

SecPath100V

分部通过野蛮IPSec的方式连接到中心，采用GRE -Over-IPSec的方式，在tunnel上运行OSPF协议来实现总部和分部之间的互通。
【问题描述】
某单位骨干网项目中采用我司SecPath1000和SecPath100V组建VPN网，用来跑数据业务以及实现对专网的备份。在A省与总部对调的时候出现了SecPath100V Tunnel口下MTU值配置异常！配置显示MTU值为84。
interface Tunnel0
mtu 84         //正常值应该为1476
ip address 10.255.2.57 255.255.255.252
source LoopBack0
destination 10.255.254.250
我司GRE Tunnel口的MTU值是动态设置的。正常情况下Tunnel口的Mtu值满足下面的公式：
       Tunnel Mtu值＝数据包出接口Mtu值－24（GRE包头的大小）
例如当Tunnel接口的数据从以太口出去的时候，会检查以太口的MTU为1500，然后减24后设置成自己的Mtu值。所以正常情况下，我们看到的Tunnel口的Mtu值一般为1476。
当Tunnel处于Down状态的时候Mtu值为64000。
现在我们来看看为什么A省SecPath100V的Tunnel接口上会出现Mtu 84这个值。在A省SecPath100V上抓包发现有“prompt: Too Many Loops!”的信息！且Mtu值呈现递减的规律！
抓包部分信息如下：
dis int Tunnel
Tunnel0 current state :UP   
Line protocol current state :UP
Description :  Tunnel0 Interface
The Maximum Transmit Unit is 756     //这里的MTU为756
Internet Address is 10.255.2.29/30
Encapsulation is TUNNEL, loopback not set
Tunnel source 10.255.254.208, destination 10.255.254.250
GRE keepalive disable
Tunnel protocol/transport GRE/IP, key disabled
Checksumming of packets disabled
    5 minutes input rate 0 bytes/sec, 0 packets/sec
    5 minutes output rate 0 bytes/sec, 0 packets/sec
    0 packets input,  0 bytes
    0 input error
    2324 packets output,  1000704 bytes
    0 output error
dis int Tunnel 0
Tunnel0 current state :UP   
Line protocol current state :UP
Description :  Tunnel0 Interface
The Maximum Transmit Unit is 732     //这里变成732了，比上面756少了24！
Internet Address is 10.255.2.29/30
Encapsulation is TUNNEL, loopback not set
Tunnel source 10.255.254.208, destination 10.255.254.250
GRE keepalive disable
Tunnel protocol/transport GRE/IP, key disabled
Checksumming of packets disabled
    5 minutes input rate 0 bytes/sec, 0 packets/sec
    5 minutes output rate 0 bytes/sec, 0 packets/sec
    0 packets input,  0 bytes
    0 input error
    2324 packets output,  1000704 bytes
    0 output error
terminal monitor
% Current terminal monitor is on

debugging ip packet

ping 10.192.0.30
  PING 10.192.0.30: 56  data bytes, press CTRL_C to break
*0.956903236 V1-B-JL-JTT IP/8/debug_icmp:
ICMP Send: echo(Type=8, Code=0), Dst = 10.192.0.30

*0.956903238 V1-B-JL-JTT IP/8/debug_case:
Sending, interface = Tunnel0, version = 4, headlen = 20, tos = 0,
pktlen = 84, pktid = 4958, offset = 0, ttl = 255, protocol = 1,
checksum = 36945, s = 10.255.2.29, d = 10.192.0.30
prompt: Sending the packet from local at Tunnel0
……………………..
*0.956903245 V1-B-JL-JTT IP/8/debug_case:
Discarding, interface = Tunnel0, version = 0, headlen = 0, tos = 0,
pktlen = 0, pktid = 0, offset = 0, ttl = 0, protocol = 0,
checksum = 0, s = 0.0.0.0, d = 0.0.0.0
prompt: Too Many Loops!

    Request time out
*0.956905245 V1-B-JL-JTT IP/8/debug_icmp:
ICMP Send: echo(Type=8, Code=0), Dst = 10.192.0.30
…………………..
*0.956905255 V1-B-JL-JTT IP/8/debug_case:
Discarding, interface = Tunnel0, version = 0, headlen = 0, tos = 0,
pktlen = 0, pktid = 0, offset = 0, ttl = 0, protocol = 0,
checksum = 0, s = 0.0.0.0, d = 0.0.0.0
prompt: Too Many Loops!

    Request time out
*0.956907265 V1-B-JL-JTT IP/8/debug_icmp:
ICMP Send: echo(Type=8, Code=0), Dst = 10.192.0.30

结论是：因为分支路由配置的问题导致了该问题的产生。
在网络地址规划初期，将每台Vpn设备上用于起GRE Tunnel的LoopBack接口地址规划为10.255.254.x网段，每台设备掩码均为32位。而规划的私网地址为10.192.0.0/255.192.0.0段，显而易见私网网段包含Tunnel接口地址所处的网段。
这样的地址规划导致在配置路由的时候，分支点必须配置三条路由：
ip route-static 0.0.0.0 0.0.0.0 218.65.87.9 preference 60
ip route-static 10.192.0.0 255.192.0.0 Tunnel 0 preference 60
ip route-static 10.255.254.250 255.255.255.255 218.65.87.9 preference 60
第一条为默认路由，下一跳指向公网。满足用户上Internet的需要。
第二条为私网路由，下一跳指向Tunnel口。满足用户上私网的需要。
第三条为主机路由，下一跳指向公网。让用GRE封装后的报文往公网上丢，从而触发建立IPSec隧道以及进行IPSec加密。

在Tunnel口源和目的地址不在私网网段内的案例中，我们只需要前两条路由就可以了，第一条路由也能够触发建立IPSec隧道以及IPSec加密。

综上所述，A省SecPath100V出现MTU异常值84的原因在于：现场工程师在调试100V的过程中Eth0/0口down掉了，导致配置的三条路由中的第一条和第三条失效，从而造成Tunnel口MTU值循环计算直到84不在减小。
【规避方案】
实际上只要Eth0/0 Up了且路由恢复以后，MTU值是可以跟着恢复正常的。
可以在分支再添加一条黑洞路由：
ip route-static 10.255.254.250 255.255.255.255 Tunnel 0 preference 80 blackhole
配置一个优先级低于正常路由的黑洞路由，正常情况下不生效，出问题的时候，由于掩码低，就生效了，保证tunnel down。
两端Tunnel口配置里增加Keepalive配置保证当Eth0/0 down的时候，Tunnel口也跟着down掉。
最好的办法是在规划地址的时候，不要将用于起Tunnel的LoopBack接口地址与私网地址有包含的关系。比如可以让私网使用10.0.0.0/8段的地址，而LoopBack接口使用192.168.0.0/24段的地址。
【总结】
该问题在目前网上运行的SecPath系列设备以及AR系列路由器中应该是普遍存在的，好在该问题即使出现了也不会有大影响，因为该问题仅在物理端口down掉的时候出现，而物理端口down掉业务也就down掉了，当物理端口up以后短时间内便可以恢复。