Demon_运维笔记

可能原因

处理建议

1. 执行命令display cpu-usage检查CPU占用率是否过高。

   当CPU占用率超过80%时，可以检查是否配置了SA、攻击防范等特性。若配置了可以先关闭，然后再检查CPU占用率。

2. 执行命令display ike peer检查两端DPD报文中的载荷顺序是否一致。

   如果两端DPD报文中的载荷顺序不一致，则修改DPD报文中的载荷顺序。

   例如，配置DPD报文中的载荷顺序为seq-hash-notify、检测模式为periodic、DPD空闲时间20秒、DPD报文重传间隔10秒、重传次数4次。

   <Huawei> system-view
   [Huawei] ike peer pp1
   [Huawei-ike-peer-pp1] dpd msg seq-hash-notify
   [Huawei-ike-peer-pp1] dpd type periodic
   [Huawei-ike-peer-pp1] dpd idle-time 20
   [Huawei-ike-peer-pp1] dpd retransmit-interval 10
   [Huawei-ike-peer-pp1] dpd retry-limit 4

3. 执行命令ping -s packetsize -a source-ip-address host检查业务经过的公网是否有丢包。

   在IPSec隧道两端的接口分别执行命令undo ipsec policy取消应用IPSec策略，然后进行Ping测试，若有丢包说明公网质量有问题，请服务提供商协助解决。

4. 执行命令ping -s packetsize -a source-ip-address host检查IPSec报文是否被分片。

   Ping测试不同大小的报文，确定是否有丢包或Ping不通，找到一个临界值（大于临界值时，Ping有丢包或不通现象）。

   根据该临界值，在接口视图下执行命令mtu mtu修改MTU值。

   修改后，还是出现部分TCP业务访问速度慢或访问时断时续现象时，请在接口视图下执行命令tcp adjust-mss value修改TCP最大报文段长度。

更多信息

因为报文分片消耗CPU资源导致IPSec业务质量下降，所以部署IPSec时需注意如下两个方面。

• 考虑MTU值

  一条链路所能传输的最大报文长度被称为MTU（Maximum Transfer Unit），MTU大小与接口类型有关（例如以太网口缺省MTU为1500字节），链路MTU由这条链路上MTU最小的接口决定。当待发送的报文尺寸超过接口MTU时，设备会先对加密后的报文进行分片，然后再发送。接收端收到一个IP报文的所有分片后需要先进行重组，然后再解密。分片及重组都需要消耗CPU资源。

  从IPSec报文的封装过程来看，IPSec对收到的原始IP报文再次封装，每次封装都会增加新的开销（每封装一层增加的开销与封装的协议有关）。假设IPSec处理流程中新增开销总计为80字节，大于1420字节的报文经IPSec封装后将超过1500字节，发送前都需要进行分片。当数据流中的报文大多数是超过1420的大包时，CPU资源消耗巨增，IPSec业务的访问速度和质量也会因此而大大下降。

  协议开销字节列表

  协议	增加的开销（字节）
  ESP	缺省为56 ESP报文增加的开销跟使用的加密算法和是否使用验证算法有关
  AH	24
  GRE	24
  NAT-T	8
  L2TP	12
  PPPoE	8
  IPSec隧道模式	20
  TCP	8

• 考虑TCP MSS值

  TCP MSS（Max Segment Size）指定了TCP最大报文段长度，如果MSS值加上各种开销的报文总长度（MSS+TCP报文头+IP报文头+IPSec报文头）大于链路的MTU值，则数据报文会被分片发送。分片的过程会消耗更多的CPU资源，分片报文的加密解密同样会消耗传输链路中设备的CPU资源。当CPU资源消耗过多，就会造成数据报文的丢失。

  同时，对于某些高层应用（例如HTTP等应用层协议等）会将IP报文的DF(Don't Fragment)标记位置为有效，以防止TCP报文分片。如果DF标记位被置为有效，而接口MTU小于MSS的值，此时设备会因为不能强制分片TCP报文而将报文丢弃。