Localizando perda transparente de pacotes de firewall

Usamos o Cisco ASA 5585 em um modo transparente layer2. A configuração são apenas dois links 10GE entre nosso parceiro de negócios dmz e nossa rede interna. Um mapa simples é assim.

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

O ASA possui 8.2 (4) e SSP20. Os comutadores são 6500 Sup2T com 12.2. Não há queda de pacotes em nenhum switch ou interface ASA !! Nosso tráfego máximo é de cerca de 1,8 Gbps entre os switches e a carga da CPU no ASA é muito baixa.

Temos um problema estranho. Nosso administrador do nms vê uma perda muito ruim de pacotes que começou em junho. A perda de pacotes está crescendo muito rapidamente, mas não sabemos o porquê. O tráfego através do firewall permaneceu constante, mas a perda de pacotes está crescendo rapidamente. Essas são as falhas de ping dos nagios que vemos através do firewall. O Nagios envia 10 pings para cada servidor. Algumas das falhas perdem todos os pings, nem todas as falhas perdem todos os dez pings.

insira a descrição da imagem aqui

O estranho é que, se usarmos o mtr do servidor nagios, a perda de pacotes não será muito ruim.

                             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

Quando fazemos ping entre os switches, não perdemos muitos pacotes, mas é óbvio que o problema começa em algum lugar entre os switches.

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#

Como podemos ter tantas falhas de ping e nenhum pacote cai nas interfaces? Como podemos encontrar onde está o problema? O Cisco TAC está circulando em círculos sobre esse problema, eles continuam solicitando o show tech de tantos switches diferentes e é óbvio que o problema está entre o core01 e o dmzsw. Alguém pode ajudar?

Atualização 30 de julho de 2013

Obrigado a todos por me ajudarem a encontrar o problema. Era um aplicativo com comportamento inadequado que enviava muitos pacotes UDP pequenos por cerca de 10 segundos por vez. Esses pacotes foram negados pelo firewall. Parece que meu gerente deseja atualizar nosso ASA, para que não tenhamos esse problema novamente.

Mais Informações

Das perguntas nos comentários:

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 user2096
fonte

A perda de pacotes coincide com o pico dos níveis de tráfego? esse ambiente já foi liberado antes disso? o que foi feito para solucionar problemas até agora?

22313 DrBru

Os níveis de tráfego não importam. A perda de pacotes ocorre quando o tráfego através do firewall é baixo ou alto. Temos um caso aberto com o TAC por uma semana e eles não conseguem encontrar a perda de pacotes em nenhuma interface. Sem problemas de CPU nos comutadores ou no firewall. Tivemos o dmz por quase um ano e a perda de pacotes só começou no último mês.

user2096

Olá, companheiro, você tem o IPS ativado em uma das duas interfaces ASA? Acredito que podemos encontrar o culpado.

laf 22/07/2013

Com base nas informações mtr e que você pode executar ping entre switches sem problema, eu ofereceria que o problema está entre o switch core1 e o próximo salto em direção ao seu nms.

Santino

@Santino, é prematuro dizer se isso é perda a montante do core01, ou em algum lugar entre ele e o dmzsw. user2096, publique a saída show interface detail | i ^Interface|overrun|errore show resource usageno firewall #

Mike Pennington

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

Você mostra excedentes nas interfaces InternalData, assim você está deixando cair o tráfego através do ASA. Com tantas gotas, não é difícil imaginar que isso esteja contribuindo para o problema. As ultrapassagens ocorrem quando as filas FIFO Rx internas excedem (normalmente devido a algum problema com a carga).

EDIT para responder a uma pergunta nos comentários :

Eu não entendo por que o firewall está sobrecarregado, não está perto de usar 10Gbps. Você pode explicar por que estamos vendo superações mesmo quando a CPU e a largura de banda estão baixas? A CPU é de cerca de 5% e a largura de banda em qualquer direção nunca ultrapassa 1,4 Gbps.

Eu já vi isso acontecer repetidamente quando um link está vendo microbursts de tráfego , que excedem a largura de banda, a conexão por segundo ou a potência do pacote por segundo do dispositivo. Muitas pessoas citam estatísticas de 1 ou 5 minutos como se o tráfego fosse relativamente constante nesse período.

Eu daria uma olhada no seu firewall executando esses comandos a cada dois ou três segundos (execute term pager 0para evitar problemas de paginação) ...

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

Agora, gráfico quanto tráfego você está vendo a cada poucos segundos versus quedas; se você observar picos maciços nas quedas ou ultrapassagens de políticas quando seu tráfego aumentar, estará mais perto de encontrar o culpado.

Não se esqueça de que você pode cheirar diretamente o ASA com isso se precisar de ajuda para identificar o que está matando o ASA ... você precisa ser rápido para capturar isso às vezes.

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

O Netflow nos seus switches upstream também pode ajudar.

Mike Pennington
fonte

doce! thanx por informações sobre 'show int detail' ~

Nachos

Nossas ultrapassagens de dados internos estão aumentando muito rapidamente, então isso parece o problema. MAS eu não entendo por que o firewall está sobrecarregado, não está perto de usar 10Gbps. Você pode explicar por que estamos vendo superações mesmo quando a CPU e a largura de banda estão baixas? A CPU é de cerca de 5% e a largura de banda em qualquer direção nunca ultrapassa 1,4 Gbps.

user2096

@ user2096, eu editei a minha resposta para responder ...

Mike Pennington

Isso não parece fazer sentido - é um firewall transparente, com entrada 10GE e saída 10GE. O caminho de dados interno não está classificado para 10GE? Parece uma falha no design do produto.

nicotina

@nicotine, o OP comprou um SSP-20 e o SSP-20 está internamente limitado a não mais que 5 Gbps (ref. Cisco Data Sheet ). Se você deseja um firewall completo de 10 Gbps, precisa comprar outra opção (talvez até o SSP-60, se o CPS for um problema). É apenas uma falha de design se você exceder a capacidade de buffer interno da caixa. Eu já vi casos de uso em que um SSP-20 com 10GE está bom.

Mike Pennington

Localizando perda transparente de pacotes de firewall

Respostas: