查找透明的防火墙数据包丢失

19

我们在第2层透明模式下使用Cisco ASA 5585。该配置仅是我们的业务合作伙伴dmz与内部网络之间的两个10GE链接。一个简单的地图如下所示。

10.4.2.9/30                    10.4.2.10/30
core01-----------ASA1----------dmzsw

ASA具有8.2（4）和SSP20。交换机是6500 Sup2T和12.2。在任何交换机或ASA接口上都没有丢包！交换机之间的最大流量约为1.8Gbps，并且ASA上的CPU负载非常低。

我们有一个奇怪的问题。我们的nms管理员发现非常糟糕的数据包丢失始于6月的某个时候。丢包的速度非常快，但是我们不知道为什么。通过防火墙的流量保持不变，但是数据包丢失迅速增长。这些是我们通过防火墙看到的nagios ping故障。Nagios向每个服务器发送10次ping。有些故障会使所有ping失效，而并非所有故障会使所有十个ping失效。

在此处输入图片说明

奇怪的是，如果我们使用来自nagios服务器的mtr，则数据包丢失不是很严重。

                             My traceroute  [v0.75]
nagios    (0.0.0.0)                                    Fri Jul 19 03:43:38 2013
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                  Packets               Pings
 Host                           Loss%   Snt Drop   Last  Best   Avg  Wrst StDev
 1. 10.4.61.1                    0.0%  1246    0    0.4   0.3   0.3  19.7   1.2
 2. 10.4.62.109                  0.0%  1246    0    0.2   0.2   0.2   4.0   0.4
 3. 10.4.62.105                  0.0%  1246    0    0.4   0.4   0.4   3.6   0.4
 4. 10.4.62.37                   0.0%  1246    0    0.5   0.4   0.7  11.2   1.7
 5. 10.4.2.9                     1.3%  1246   16    0.8   0.5   2.1  64.8   7.9
 6. 10.4.2.10                    1.4%  1246   17    0.9   0.5   3.5 102.4  11.2
 7. dmz-server                   1.1%  1246   13    0.6   0.5   0.6   1.6   0.2

当我们在交换机之间执行ping操作时，我们不会丢失很多数据包，但是很明显，问题出在交换机之间。

core01#ping ip 10.4.2.10 repeat 500000

Type escape sequence to abort.
Sending 500000, 100-byte ICMP Echos to 10.4.2.10, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 99 percent (499993/500000), round-trip min/avg/max = 1/2/6 ms
core01#

我们怎么能有那么多ping故障并且接口上没有丢包？我们如何找到问题所在？思科TAC一直在解决这个问题，他们一直在寻求来自许多不同交换机的显示技术，而且很明显，问题出在core01和dmzsw之间。有人可以帮忙吗？

更新2013年7月30日

谢谢大家帮助我发现问题。这是一个行为异常的应用程序，每次发送大量小的UDP数据包的时间约为10秒。这些数据包被防火墙拒绝。看来我的经理想升级我们的ASA，所以我们不再遇到这个问题。

更多信息

从评论中的问题：

ASA1# show inter detail | i ^Interface|overrun|error
Interface GigabitEthernet0/0 "", is administratively down, line protocol is down
        0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
        0 output errors, 0 collisions, 0 interface resets
Interface GigabitEthernet0/1 "", is administratively down, line protocol is down
        0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
        0 output errors, 0 collisions, 0 interface resets
Interface GigabitEthernet0/2 "", is administratively down, line protocol is down
        0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
        0 output errors, 0 collisions, 0 interface resets
Interface GigabitEthernet0/3 "", is administratively down, line protocol is down
        0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
        0 output errors, 0 collisions, 0 interface resets
Interface GigabitEthernet0/4 "", is administratively down, line protocol is down
        0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
        0 output errors, 0 collisions, 0 interface resets
Interface GigabitEthernet0/5 "", is administratively down, line protocol is down
        0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
        0 output errors, 0 collisions, 0 interface resets
Interface GigabitEthernet0/6 "", is administratively down, line protocol is down
        0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
        0 output errors, 0 collisions, 0 interface resets
Interface GigabitEthernet0/7 "", is administratively down, line protocol is down
        0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
        0 output errors, 0 collisions, 0 interface resets
Interface Internal-Data0/0 "", is up, line protocol is up
     2749335943 input errors, 0 CRC, 0 frame, 2749335943 overrun, 0 ignored, 0 abort
         0 output errors, 0 collisions, 0 interface resets
           RX[00]: 156069204310 packets, 163645512578698 bytes, 0 overrun
           RX[01]: 185159126458 packets, 158490838915492 bytes, 0 overrun
           RX[02]: 192344159588 packets, 197697754050449 bytes, 0 overrun
           RX[03]: 173424274918 packets, 196867236520065 bytes, 0 overrun
Interface Internal-Data1/0 "", is up, line protocol is up
    26018909182 input errors, 0 CRC, 0 frame, 26018909182 overrun, 0 ignored, 0 abort
    0 output errors, 0 collisions, 0 interface resets
           RX[00]: 194156313803 packets, 189678575554505 bytes, 0 overrun
           RX[01]: 192391527307 packets, 184778551590859 bytes, 0 overrun
           RX[02]: 167721770147 packets, 179416353050126 bytes, 0 overrun
           RX[03]: 185952056923 packets, 205988089145913 bytes, 0 overrun
Interface Management0/0 "Mgmt", is up, line protocol is up
        0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
        0 output errors, 0 collisions, 0 interface resets
Interface Management0/1 "", is administratively down, line protocol is down
        0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
        0 output errors, 0 collisions, 0 interface resets
Interface TenGigabitEthernet0/8 "Inside", is up, line protocol is up
        0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
        0 output errors, 0 collisions, 0 interface resets
Interface TenGigabitEthernet0/9 "DMZ", is up, line protocol is up
        0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
        0 output errors, 0 collisions, 0 interface resets

ASA1#
cisco  switch  cisco-asa  firewall  packet-loss 
— 用户名
source
数据包丢失是否与流量水平达到峰值时一致？在此之前，该环境是否曾经免费发行过？到目前为止，已采取什么措施进行故障排除？
— DrBru
流量水平无关紧要。当通过防火墙的流量较低或较高时，就会发生数据包丢失。我们已经与TAC开了一个案例，为期一周，他们找不到任何接口上的数据包丢失。交换机或防火墙上没有CPU问题。我们使用dmz已有将近一年的时间，并且丢包仅在上个月左右开始。
— user2096 2013年
嗨，队友，您是否在两个ASA接口中的一个上启用了IPS？我相信我们可能会找到罪魁祸首。
— laf
2
根据mtr信息，并且您可以在各交换机之间ping通而不会出现问题，我认为问题出在您的core1交换机及其通往nm的下一跳之间。
— 桑蒂诺（Santino）
2
@Santino，现在说这是在core01上游丢失还是在它与dmzsw之间的某个位置为时尚早。user2096，请在show interface detail | i ^Interface|overrun|error和show resource usage上发布防火墙的输出
— Mike Pennington

Answers:

8 
Interface Internal-Data0/0 "", is up, line protocol is up
     2749335943 input errors, 0 CRC, 0 frame, 2749335943 overrun, 0 ignored, 0 abort
                                              ^^^^^^^^^^^^^^^^^^
         0 output errors, 0 collisions, 0 interface resets

您会在InternalData接口上显示超限，因此将丢弃通过ASA的流量。有了这么多滴，不难想象这是导致问题的原因。当内部Rx FIFO队列溢出时会发生溢出（通常是由于加载问题）。

编辑以评论中的问题：

我不明白为什么防火墙超载，它接近使用10Gbps。您能解释为什么即使CPU和带宽都很低时我们仍然看到超载吗？CPU大约为5％，任一方向的带宽都永远不会高于1.4Gbps。

我已经看到这种情况一遍又一遍地发生，当链路出现流量微突发时，这些突发超过了设备的带宽，每秒连接或每秒包的功率。如此多的人引用1或5分钟的统计数据，就好像该时间段内的流量相对稳定。

我每两三秒运行一次这些命令来查看您的防火墙（运行term pager 0以避免分页问题）...

show clock
show traffic detail | i ^[a-zA-Z]|overrun|packets dropped
show asp drop

现在，找出每几秒钟看到的流量与下降的流量；如果您在流量激增时看到政策大幅下降或超支，那么您将更接近罪魁祸首。

不要忘记，如果您需要帮助确定导致ASA崩溃的原因，可以直接在ASA上嗅探...有时您必须快速抓住这一点。

capture FOO circular-buffer buffer <buffer-size> interface <intf-name>

上游交换机上的Netflow也可以提供帮助。

— 迈克·彭宁顿
source
甜！thanx有关“显示int细节”的信息
— 〜– Nachos
我们的内部数据超速增长非常快，所以这看起来像是问题。但是我不明白为什么防火墙超载，它接近使用10Gbps。您能解释一下为什么即使CPU和带宽都很低时我们仍然会看到超载吗？CPU大约为5％，任一方向的带宽都永远不会高于1.4Gbps。
— user2096
@ user2096，我编辑了答案以回复...
— Mike Pennington
这似乎没有道理-它是透明的防火墙，有10GE进出和10GE出进。内部数据路径不适用10GE？似乎是产品设计失败。
— 尼古丁
2
@ nicotine，OP购买了SSP-20，并且内部将SSP-20限制为不超过5Gbps（请参阅Cisco数据表）。如果要使用完整的10Gbps防火墙，则必须购买另一种选择（如果CPS成为问题，甚至可能是SSP-60）。如果您超出包装盒的内部缓冲容量，这仅仅是设计失败。我见过用10GE的SSP-20很好的用例。
— Mike Pennington
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.