• 文章搜索:
  • 易筋洗髓

        • 分享到...

        • 新浪微博
        • 腾讯微博
        • 推荐到豆瓣 豆瓣空间
        • 分享到搜狐微博 搜狐微博
        • 分享到QQ空间 QQ空间
        • 分享到腾讯朋友 腾讯朋友
        • 网易微博分享 网易微博
        • 添加到百度搜藏 百度搜藏
        • 转贴到开心网 开心网
        • 转发好友 告诉聊友
    • 推荐
    • 打印
    • 收藏

    寻医问药之防火墙VRRP切换篇

    作者:  |  上传时间:2014-05-20  |  关键字:寻医问药之防火墙VRRP切换篇

    一、     机理介绍:

    VRRPVirtual Router Redundancy Protocol,虚拟路由器冗余协议)使用IP协议号112,固定组播地址224.0.0.18发送协议报文,冗余设备之间形成一个虚拟网关节点,并通过选举方式选定主设备承担虚拟网关的所有功能。

    一、        发病人群:

    各行各业,运营商、金融、电力、教育等等大小客户群普遍存在,VRRP组网现网部署量很大;病原体多样化,路由器、交换机、防火墙等设备都可导致病发;易感难治,悄无声息突然发病,来的快去的快,患者措不及防。

    二、        专家论证:

    经数代人推敲论证,此类问题突破口在于协议报文来去无踪,神龙见首不见尾。VRRP依赖于定时发送的协议报文维持组内成员的主备状态,而此协议报文往往依赖于设备外侧链路传输,难保在收发或者传输阶段发生丢弃,所以查清协议报文为何发生异常,病因自会浮出水面。

    三、        临床案例:

    1.     特定组号或者经过相同路径转发业务的VRRP组发生切换(仅备机)

    某病例提供的日志记录只有特定几组VRRP频繁切换,其他组号正常。

    此类切换基本和防火墙无关,可以在防火墙接收侧通过流统计或debug判断是否有正常收到协议报文,经过排查发现,经过转发故障组VRRP报文的交换机上有其他业务也有异常,初步锁定是交换机故障,经过进一步定位是交换机存在丢包记录,原因是有异常流量冲击交换机导致。

    案例小结:

    此问题与防火墙无关,VRRP报文经过的转发路径上其他设备也是有丢包可能的。处理此类问题,除了明确的信息(非防火墙转发业务也受到影响)外,建议在防火墙出入方向统计VRRP报文,判断是否防火墙自身处理丢包。

    2.     特定时间点或时间段发生切换(主备都切VRRP设备自身丢包)

    某几次病例提供的日志中每天发生切换的时间点非常集中,甚至分钟都不差。

    此类病例一般是由有规律的突发流量导致VRRP设备或者转发VRRP协议报文的设备压力过载发生丢包导致,经排查定位,此处发生的多组VRRP同时监控同一组NQA,且NQA的探测条件比较敏感,相关参数设置较短,经过了解客户系统有每天定时备份业务的操作,且突发流量较大,现网存在明显丢包可能。经过增加聚合链路,增大NQA探测延时问题解决。

    案例小结:

    此问题日志信息VRRP的切换时间有明确的规律性,现场防火墙配置及组网又存在明确的丢包可能,建议了解现场情况确认固定时间点发生是否有大流量突发,是否为正常业务。

    3.     不规律且切换次数较多(主备都切转发设备丢包)

    某病例中交换机VRRP不规律且换,且切换组的VRRP调用同一组NQA,而NQA探测报文经过防火墙插卡转发。

    经过在交换机万兆口做流统计判断防火墙存在少量丢包,初步锁定目标后进一步排查,NQAICMP探测报文在防火墙上走CPU转发,查看防火墙CPU使用情况发现转发平面明显偏高,连续清空并收集快转统计信息发现CPU有丢包,经过检查配置发现组网存在环路,部分接口下报文统计TTL超时报文非常多,环路报文大量转发使防火墙转发平面压力过大,修改配置后解决。

    案例小结:

    此问题属于CPU压力下丢包,应首先明确影响业务的这部分丢包是什么报文,这些报文经过防火墙转发是快转流程还是慢转流程,然后排查CPU的丢包迹象。建议此类问题收集三次诊断信息,先收集一次诊断信息,然后清空关键统计再收集一次,间隔一段时间后再收集一次。

    4.     偶然感冒,闪你一下N久不再复现;持续发烧,耿直的双主。

    这样的病例及其少见,遇到真是医者欲哭,病者无泪。

    根据以往案例经验,突然闪一下一般是有异常的突发流量导致,这个可以结合直连设备如交换机接口下的峰值记录或者网管监控等其他渠道了解切换时段的流量是否异常;另外一种异常流量是攻击流量,并发可能比较高如DDoS攻击,常见类型是SYN Flood。可以排查下内部服务器是否有中毒可能;持续双主问题建议先排查协议报文转发链路,是否配置有阻断转发端口的协议或者认为修改配置导致,可以选择VRRP设备互相Ping测试。如果基本可以排除以上可能可以查看公司公告。

    四、        病原病理分析:

    1.    难缠的DDoS流量:根据多年临床经验,此为有发防火墙患病的头号杀手,特点是顽固、普遍、杀伤力大、行踪诡异和难以排查,但此类患者症状相对明显,一般表现并发会话较高甚至打满设备规格,CPU占用率也会升高,原因是突如其来的并发会直接冲击CPU,排查手段一般是故障时打印设备详细会话表项从中不难观察出异常流量的起始ip和端口等信息,根源一般为内部服务器主动发起或少数被攻击。

    2.    路由环路或广播风暴:此类病因属组网规划不合理,人为间接触发所致,一般表现CPU较高,可通过查看接口统计和ip统计手段排查。

    3.    Track触发:此类外因较多,因为常规VRRP组网中很多采用NQA联动以实现监控链路状态和实现多组VRRP协同切换的目的,NQA检测报文可能跨一跳或多跳,中间链路可能存在不稳定,此类症状最好的定位手段是查看日志,首先判断是否为NQA触发所致切换,如果是继续排查NQA检测报文链路,可以通过debug和流统计手段明确NQA报文丢包位置。

    4.    正常突发流量:此类病症仍归于内因,表现症状比较明显,VRRP切换时间比较集中,根因一般处于定时的大数据备份业务,由于瞬间突发较高,设备资源处理紧张所致。

    5.    安全特性配置类:曾经遇见几起事故,原因是防火墙配置了到local域的域间阻断策略,导致协议报文备机不能接收而出现长时间双主故障,客户本想增加设备安全性,不料弄巧成拙,此类病症间接提醒攻城狮们,故障时不要忘了问下故障前是否有人为操作,这属于突然故障,正所谓小心使得万年船。

    五、        临床经验总结:

    此类症状关键点在于冷静查看日志,从患病特征中寻找规律谋得突破口,重点关注日志记录的切换时间、组号及多组间可能存在的关联;摸清组网,熟悉报文转发路径,仔细分析可能存在的故障点,重点关注属于哪一类的切换,是备机超时抢主还是主机主动退位让贤,明确是超时丢包还是NQA使主机降低优先级;最后是要有大局观,当已有信息很难明确定位时,要考虑全面寻求可能性,重点关注异常突发流量,熟悉产品相关处理机制并对客户组网提出合理优化建议,防患于未然。