通过调整QoS队列解决FTP备份设备配置失败的经验案例

通过调整QoS队列解决FTP备份设备配置失败的经验案例

一    组网：

某集团网络局部拓扑如下，VRRP+MSTP组网，使能PIM、IGMP等组播协议，承载办公和监控业务：

二    问题描述：

因管理和维护需要，网管中心开发了一套应用程序，可以通过FTP方式周期性自动备份网络中核心和汇聚设备的版本、配置和日志文件。

该应用上线后经常发生设备无法FTP、FTP超时、备份文件失败等问题。手工FTP登录到设备操作也经常出现延时、缓慢等问题。与此同时Ping设备却稳定不丢包，Telnet设备操作也无任何延时和缓慢。

三    过程分析：

根据问题现象来分析：

第一，同一时刻且源和目的不变的情况下，针对不同应用（FTP、Telnet、Ping）有不同的两种表现，首先可以排除链路上的问题。

第二，根据流量统计和抓包分析，FTP备份文件失败时，网络设备可以正常收到服务器侧发送的相关请求报文，但并未回复导致交互失败，因此也排除了服务器端的问题。

那么最大的疑点就聚焦到了设备上。收集网络中相关设备的Diag信息来进行分析。

我们以其中一台S7506E为例，发现大量的上CPU报文被丢弃，这些报文将无法送达CPU进行处理：

HOLD.cpu0:    504,198,025,231   +504,198,025,231     13,169/s

查看软件Softcar记录发现大量的被丢弃报文为未知组播报文：

The softcar pps auto-adjust switch: On

 Index   Type                     Pkt_PSec     DisPkt_All   Pps     Switch Hash

 0       ROOT                     0            0            200     On     SMAC

 1       ISIS                     0            0            200     On     SMAC

 2       ESIS                     0            0            100     On     SMAC

 3       CLNP                     0            0            100     On     SMAC

 4       VRRP                     7            0            300     On     SMAC

 5       UNKNOWN_IPV4MC           1000         260036290    100     On     SMAC

 6       UNKNOWN_IPV6MC           0            0            100     On     SMAC

 7       IPV4_MC_RIP              0            0            150     On     SMAC

 8       IPV4_BC_RIP              0            0            150     On     SMAC

 9       MCAST_NTP                0            0            100     On     SMAC

通过catch手段根据目的IP进一步筛查发现这些未知组播报文均为用户监控网络的组播业务地址：

[7506E-1-diagnose]debug rxtx catch by dip 5

[7506E-1-diagnose]debug rxtx catch end 5   

Slot 5: information of Module RxTx

The Catch Result of dip is :

238.123.46.9 -------- 10668

238.123.200.33 -------- 33796

238.123.46.31 -------- 34179

238.123.200.4 -------- 11262

238.123.46.7 -------- 10666

238.123.46.5 -------- 10721

那么，这些组播业务报文为何成了未知组播呢？结合用户的组网不难发现，在VRRP环境中跑组播会产生Wrongif，Wrongif报文会以未知组播上CPU并在Vlan中进行广播：

00016. (192.168.192.107, 238.123.46.10)

     MID: 65, Flags: 0x100000:0

     Uptime: 31w:3d, Timeout in: 00:03:26

     Incoming interface: Vlan-interface200

     List of 1 outgoing interfaces:

       1: Vlan-interface807

     Matched 1270071 packets(1270850 bytes), Wrong If 49024716 packets

     Forwarded 1270071 packets(1270850 bytes)

这样会对设备CPU造成很大的冲击，大量的未知组播挤占了上CPU通道，继而产生拥塞和丢包，使CPU无法及时处理其它类型的上CPU报文。

那么为何FTP业务会受到很大影响，而Ping和Telnet却正常呢？

这里需要从设备具体的实现方式上来看，在上CPU的报文中分成0到7共8个COS队列，不同类型的报文根据其重要性被分在不同的队列中传输，例如STP（COS6）、VRRP（COS5）、BGP（COS3）。对于FTP报文和未知组播报文，设备默认都会映射到COS0队列，COS0队列拥塞会导致FTP报文丢包。而对于ICMP、TELNET报文，设备默认映射到COS1队列，因为COS1队列没有拥塞所以并没有出现问题。

Cos[00]=110432532   Cos[01]=54204       Cos[02]=7169        Cos[03]=1850   

Cos[04]=7983        Cos[05]=3568        Cos[06]=8422        Cos[07]=0      

四    解决方法：

找到了问题的根本原因，就有了解决方法：提升FTP报文映射的COS队列。

具体配置方法如下：

acl number 3456      //定义FTP数据流

 rule 0 permit tcp source-port eq ftp-data

 rule 1 permit tcp source-port eq ftp

 

traffic classifier ftps operator and

 if-match acl 3456

 

traffic behavior ftps

 remark dot1p 2      //标记dot1p优先级为2（dot1p 2 = COS 1）

 

qos policy ftps

 classifier ftps behavior ftps

 

qos apply policy ftps global inbound    //基于全局下发策略