투명한 방화벽 패킷 손실 찾기


19

Cisco ASA 5585는 layer2 투명 모드에서 사용합니다. 구성은 비즈니스 파트너 dmz와 내부 네트워크 사이의 두 개의 10GE 링크입니다. 간단한지도는 다음과 같습니다.

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

ASA에는 8.2 (4) 및 SSP20이 있습니다. 스위치는 12.2의 6500 Sup2T입니다. 스위치 또는 ASA 인터페이스에 패킷 손실이 없습니다 !! 스위치 사이의 최대 트래픽은 약 1.8Gbps이며 ASA의 CPU로드는 매우 낮습니다.

이상한 문제가 있습니다. 우리 nms 관리자는 6 월에 언젠가 시작된 매우 나쁜 패킷 손실을 봅니다. 패킷 손실이 매우 빠르게 증가하고 있지만 그 이유를 모릅니다. 방화벽을 통한 트래픽은 일정하게 유지되었지만 패킷 손실은 빠르게 증가하고 있습니다. 이것이 방화벽을 통해 볼 수있는 nagios ping 실패입니다. Nagios는 모든 서버에 10 개의 핑을 보냅니다. 일부 장애는 모든 핑을 잃어 버리지 만 모든 장애가 10 개의 핑을 모두 잃는 것은 아닙니다.

여기에 이미지 설명을 입력하십시오

이상한 점은 우리가 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

스위치 사이를 핑할 때 많은 패킷을 잃지 않지만 스위치 사이에서 문제가 시작되는 것은 분명합니다.

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#

핑 장애가 많고 인터페이스에서 패킷 손실이없는 방법은 무엇입니까? 문제가 어디에 있는지 어떻게 알 수 있습니까? Cisco TAC는이 문제를 해결하기 위해 계속 노력하고 있으며, 수많은 다른 스위치에서 쇼 기술을 계속 요구하고 있으며 문제는 core01과 dmzsw 사이에 있음이 분명합니다. 누군가 도울 수 있습니까?

2013 년 7 월 30 일 업데이트

문제를 찾도록 도와 주신 모든 분들께 감사드립니다. 한 번에 약 10 초 동안 많은 작은 UDP 패킷을 보낸 것은 오작동 응용 프로그램이었습니다. 이 패킷은 방화벽에 의해 거부되었습니다. 관리자가 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#

트래픽 수준이 최고 일 때 패킷 손실이 일치합니까? 이 환경이 전에 무료로 문제가 있었습니까? 지금까지 문제 해결을 위해 수행 한 작업은 무엇입니까?
DrBru

교통량은 중요하지 않습니다. 방화벽을 통한 트래픽이 적거나 높을 때 패킷 손실이 발생합니다. 우리는 일주일 동안 TAC에 대한 사례를 열었고 어떤 인터페이스에서도 패킷 손실을 찾을 수 없습니다. 스위치 나 방화벽에 CPU 문제가 없습니다. 우리는 거의 1 년 동안 dmz를 가지고 있었고 패킷 손실은 지난 달 정도에 시작되었습니다.
user2096

안녕하십니까, 두 ASA 인터페이스 중 하나에서 IPS가 활성화되어 있습니까? 나는 우리가 범인을 찾을 수 있다고 생각합니다.
laf

2
mtr 정보를 기반으로 문제없이 스위치 사이를 핑 (ping) 할 수 있다는 점에서 코어 1 스위치와 nm를 향한 다음 홉 사이에 문제가 있다고 제안합니다.
Santino

2
@Santino, 이것이 core01의 상류에서 손실인지 또는 dmzsw와의 어딘가에서 말하는 것은 너무 이릅니다. user2096, 방화벽 의 출력 show interface detail | i ^Interface|overrun|errorshow resource usage방화벽에 게시하십시오
Mike Pennington

답변:


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 분 통계를 인용합니다.

2 ~ 3 초마다 이러한 명령을 실행하여 방화벽을 살펴보십시오 ( 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도 도움이 될 수 있습니다.


단! 'show int detail'에 대한 정보는 고맙습니다 ~
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
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.