Trovare perdita trasparente di pacchetti firewall

Utilizziamo Cisco ASA 5585 in modalità trasparente layer2. La configurazione è solo due collegamenti 10GE tra il nostro partner commerciale dmz e la nostra rete interna. Una semplice mappa è simile a questa.

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

L'ASA ha 8.2 (4) e SSP20. Gli interruttori sono 6500 Sup2T con 12.2. Non ci sono drop di pacchetti su alcun interruttore o interfaccia ASA !! Il nostro traffico massimo è di circa 1,8 Gbps tra gli switch e il carico della CPU sull'ASA è molto basso.

Abbiamo uno strano problema. Il nostro amministratore nms vede una pessima perdita di pacchetti iniziata a giugno. La perdita di pacchetti sta crescendo molto rapidamente, ma non sappiamo perché. Il traffico attraverso il firewall è rimasto costante, ma la perdita di pacchetti sta crescendo rapidamente. Questi sono gli errori di ping nagios che vediamo attraverso il firewall. Nagios invia 10 ping a ogni server. Alcuni dei guasti perdono tutti i ping, non tutti i guasti perdono tutti i dieci ping.

inserisci qui la descrizione dell'immagine

La cosa strana è che se usiamo mtr dal server nagios, la perdita di pacchetti non è molto grave.

                             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 eseguiamo il ping tra gli switch, non perdiamo molti pacchetti, ma è ovvio che il problema inizia da qualche parte tra gli switch.

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#

Come possiamo avere così tanti errori di ping e nessuna caduta di pacchetti sulle interfacce? Come possiamo trovare dov'è il problema? Cisco TAC si sta concentrando su questo problema, continuano a chiedere tecnologia per lo spettacolo da così tanti switch diversi ed è ovvio che il problema è tra core01 e dmzsw. Qualcuno può aiutare?

Aggiornamento del 30 luglio 2013

Grazie a tutti per avermi aiutato a trovare il problema. Era un'applicazione che si comportava male e che inviava molti piccoli pacchetti UDP per circa 10 secondi alla volta. Questi pacchetti sono stati negati dal firewall. Sembra che il mio manager voglia aggiornare il nostro ASA, quindi non abbiamo più questo problema.

Maggiori informazioni

Dalle domande nei commenti:

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#

— user2096
fonte

La perdita di pacchetti coincide con il picco del traffico? questo ambiente è mai stato privo di problemi prima? cosa è stato fatto per risolvere i problemi finora?

— DrBru,

I livelli di traffico non contano. La perdita di pacchetti si verifica quando il traffico attraverso il firewall è basso o alto. Abbiamo un caso aperto con TAC per una settimana e non riescono a trovare la perdita di pacchetti su nessuna interfaccia. Nessun problema con la CPU su switch o firewall. Abbiamo avuto il dmz per quasi un anno e la perdita di pacchetti è iniziata solo nell'ultimo mese circa.

— user2096

Ciao amico, hai abilitato IPS su una delle due interfacce ASA? Credo che potremmo trovare il colpevole.

— fatto il

Sulla base delle informazioni mtr e che è possibile eseguire il ping tra switch senza problemi, offrirei che il problema è tra il tuo switch core1 e il suo salto successivo verso il tuo nms.

— Santino,

@Santino, è prematuro dire se si tratta di una perdita a monte di core01, o da qualche parte tra essa e il dmzsw. user2096, pubblica l'output di show interface detail | i ^Interface|overrun|errore show resource usagesul 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

Si mostrano superamenti sulle interfacce InternalData, così si sta cadendo il traffico attraverso l'ASA. Con così tante gocce, non è difficile immaginare che ciò stia contribuendo al problema. I sovraccarichi si verificano quando traboccano le code RIF FIFO interne (normalmente a causa di qualche problema con il carico).

MODIFICA per rispondere a una domanda nei commenti :

Non capisco perché il firewall sia sovraccarico, non è vicino all'utilizzo di 10 Gbps. Puoi spiegare perché stiamo assistendo a sovraccarichi anche quando la CPU e la larghezza di banda sono basse? La CPU è circa del 5% e la larghezza di banda in entrambe le direzioni non supera mai 1,4 Gbps.

Ho visto questo accadere ripetutamente quando un collegamento sta vedendo micro-scoppi di traffico , che superano la larghezza di banda, la connessione al secondo o la potenza del pacchetto al secondo del dispositivo. Così tante persone citano statistiche da 1 o 5 minuti come se il traffico fosse relativamente costante in quel lasso di tempo.

Darei un'occhiata al tuo firewall eseguendo questi comandi ogni due o tre secondi (esegui term pager 0per evitare problemi di paging) ...

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

Ora mostra quanto traffico stai vedendo ogni pochi secondi rispetto alle cadute; se vedi picchi massicci nelle cadute della politica o sovraccarichi quando il tuo traffico aumenta, allora sei più vicino a trovare il colpevole.

Non dimenticare che puoi annusare direttamente l'ASA con questo se hai bisogno di aiuto per identificare ciò che sta uccidendo l'ASA ... devi essere veloce a prenderlo a volte.

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

Anche il flusso di rete sui tuoi switch upstream potrebbe aiutare.

— Mike Pennington
fonte

dolce! grazie per informazioni su 'show int detail' ~

— Nachos,

I nostri sovraccarichi internaldata stanno aumentando molto rapidamente, quindi questo sembra il problema. MA non capisco perché il firewall sia sovraccarico, non è vicino all'utilizzo di 10 Gbps. Puoi spiegare perché stiamo assistendo a sovraccarichi anche quando la CPU e la larghezza di banda sono basse? La CPU è circa del 5% e la larghezza di banda in entrambe le direzioni non supera mai 1,4 Gbps.

— user2096

@ user2096, ho modificato la mia risposta per rispondere ...

— Mike Pennington,

Questo non sembra avere senso: è un firewall trasparente, con 10GE in entrata e 10GE in uscita. Il datapath interno non è valutato per 10GE? Sembra un errore di progettazione del prodotto.

— Nicotina,

@nicotine, l'OP ha acquistato un SSP-20 e l'SSP-20 è limitato internamente a non più di 5 Gbps (consultare la scheda tecnica Cisco ). Se si desidera un firewall completo da 10 Gbps, è necessario acquistare un'altra opzione (forse anche SSP-60, se CPS è un problema). È solo un errore di progettazione se si supera la capacità di buffering interna della scatola. Ho visto casi d'uso in cui un SSP-20 con 10GE va bene.

— Mike Pennington,