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失效，而并非所有故障都会使全部10 ping失效。并不是很糟糕。
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#
#1 楼
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分钟的统计数据，就好像该时间段内的流量相对恒定。传呼问题）...
show clock
show traffic detail | i ^[a-zA-Z]|overrun|packets dropped
show asp drop
现在绘制出每隔几秒钟您看到的流量与下降的流量；如果您在流量激增时看到大量的政策激增或超支，那么您就更接近罪魁祸首了。
如果您需要，您可以直接在ASA上嗅一下帮助确定导致ASA崩溃的原因...有时您必须快速赶上这一点。
评论
甜！感谢您提供有关“显示int细节”的信息〜
–玉米片
13年7月23日在11:59
我们的内部数据超速增长非常快，所以这看起来像是问题。但是我不明白为什么防火墙超载，它接近使用10Gbps。您能解释为什么即使CPU和带宽都很低时我们仍会看到超速运行吗？ CPU大约为5％，任一方向的带宽都永远不会高于1.4Gbps。
–user2096
13年7月25日在9:12
@ user2096，我编辑了答案以回复...
–迈克·彭宁顿
13年7月25日在10:53
这似乎没有意义-这是透明的防火墙，有10GE进出和10GE出进。内部数据路径不适用10GE？似乎是产品设计失败。
–烟碱
13年7月27日在15:47
@ nicotine，OP购买了SSP-20，并且内部将SSP-20限制为不超过5Gbps（请参阅Cisco数据表）。如果要使用完整的10Gbps防火墙，则必须购买另一种选择（如果CPS成为问题，甚至可能是SSP-60）。如果超出包装盒的内部缓冲容量，这仅仅是设计失败。我见过用10GE的SSP-20很好的用例。
–迈克·彭宁顿
13年7月27日在17:10
评论
数据包丢失是否与流量水平达到峰值时一致？在此之前，此环境是否曾经免费发行过？到目前为止，已采取什么措施进行故障排除？流量水平无关紧要。当通过防火墙的流量较低或较高时，就会发生数据包丢失。我们已经与TAC开了一个案例，为期一周，他们找不到任何接口上的数据包丢失。交换机或防火墙上没有CPU问题。我们使用dmz已有将近一年的时间，并且丢包仅在上个月左右开始。
嗨，队友，您是否在两个ASA接口中的一个上启用了IPS？我相信我们可以找到罪魁祸首。
根据mtr信息，并且您可以在交换机之间进行ping操作而不会出现问题，我认为问题出在您的core1交换机和通往nm的下一跳之间。
@Santino，现在说这是在core01上游丢失还是在它与dmzsw之间的某个位置为时尚早。 user2096，请发布show interface detail的输出| i ^接口|溢出|错误并显示防火墙上的资源使用情况