Este documento descreve como resolver a perda de ping em um túnel IPsec combinado com mensagens "%CRYPTO-4-RECVD_PKT_MAC_ERR" no syslog, como mostrado na caixa:
May 23 11:41:38.139 GMT: %CRYPTO-4-RECVD_PKT_MAC_ERR:
decrypt: mac verify failed for connection
id=2989 local=172.16.200.18 remote=172.16.204.18 spi=999CD43B
seqno=00071328
Uma pequena porcentagem dessas gotas é considerada normal. No entanto, uma alta taxa de queda por causa desse problema pode afetar o serviço e pode exigir a atenção do operador da rede. Observe que essas mensagens relatadas nos syslogs têm taxa limitada em intervalos de 30 segundos, portanto, uma única mensagem de log nem sempre indica que apenas um único pacote foi descartado. Para obter uma contagem precisa dessas quedas, emita o comando show crypto ipsec sa detail e examine o SA ao lado da ID de conexão vista nos registros. Entre os contadores SA, os pkts verify failed error counters contabilizam o total de descarte de pacotes devido à falha de verificação do código de autenticação da mensagem (MAC).
interface: GigabitEthernet0/1
Crypto map tag: MPLSWanGREVPN, local addr 172.16.204.18
protected vrf: (none)
local ident (addr/mask/prot/port): (172.16.204.18/255.255.255.255/47/0)
remote ident (addr/mask/prot/port): (172.16.205.18/255.255.255.255/47/0)
current_peer 172.16.205.18 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 51810, #pkts encrypt: 51810, #pkts digest: 51810
#pkts decaps: 44468, #pkts decrypt: 44468, #pkts verify: 44468
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#pkts no sa (send) 0, #pkts invalid sa (rcv) 0
#pkts encaps failed (send) 0, #pkts decaps failed (rcv) 0
#pkts invalid prot (recv) 0, #pkts verify failed: 8
#pkts invalid identity (recv) 0, #pkts invalid len (rcv) 0
#pkts replay rollover (send): 0, #pkts replay rollover (rcv) 0
#pkts replay failed (rcv): 0
#pkts internal err (send): 0, #pkts internal err (recv) 0
local crypto endpt.: 172.16.204.18, remote crypto endpt.: 172.16.205.18
path mtu 1500, ip mtu 1500, ip mtu idb GigabitEthernet0/1
current outbound spi: 0xD660992C(3596654892)
inbound esp sas:
spi: 0x999CD43B(2577191995)
transform: esp-3des esp-sha-hmac ,
in use settings ={Transport, }
conn id: 2989, flow_id: AIM-VPN/SSL-3:2989, sibling_flags 80000006,
crypto map: MPLSWanGREVPN
sa timing: remaining key lifetime (k/sec): (4257518/24564)
IV size: 8 bytes
replay detection support: N
Status: ACTIVE
outbound esp sas:
spi: 0xD660992C(3596654892)
transform: esp-3des esp-sha-hmac ,
in use settings ={Transport, }
conn id: 2990, flow_id: AIM-VPN/SSL-3:2990, sibling_flags 80000006,
crypto map: MPLSWanGREVPN
sa timing: remaining key lifetime (k/sec): (4199729/24564)
IV size: 8 bytes
replay detection support: N
Status: ACTIVE
Não existem requisitos específicos para este documento.
As informações neste documento são baseadas em testes feitos com o Cisco IOS® versão 15.1(4)M4. Embora ainda não testados, os scripts e a configuração devem funcionar com versões anteriores do software Cisco IOS, já que ambos os miniaplicativos usam a versão 3.0 do EEM (que é suportada na versão 12.4(22)T ou superior do IOS).
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
O "%CRYPTO-4-RECVD_PKT_MAC_ERR: descriptografar:" implica que um pacote criptografado foi recebido com falha na verificação MAC. Esta verificação é um resultado do conjunto de transformação de autenticação configurado:
Router (config)# crypto ipsec transform transform-1 esp-aes 256 esp-md5-hmac
No exemplo acima, "esp-aes 256" define o algoritmo de criptografia como AES de 256 bits, e "esp-md5" define o MD5 (variante HMAC) como o algoritmo de hash usado para autenticação. Algoritmos de hash como MD5 são normalmente usados para fornecer uma impressão digital do conteúdo de um arquivo. A impressão digital digital é frequentemente usada para garantir que o arquivo não tenha sido alterado por um invasor ou vírus. Assim, a ocorrência desta mensagem de erro geralmente implica:
Como essa mensagem de erro é normalmente causada por corrupção de pacote, a única maneira de fazer uma análise de causa básica é usar o EPC para obter capturas de pacote completas do lado da WAN em ambos os pontos finais do túnel e compará-las. Antes de obter as capturas, é melhor identificar que tipo de tráfego dispara esses logs. Em alguns casos, pode ser um tipo específico de tráfego; em outros casos, ele pode ser aleatório, mas facilmente reproduzido (como 5-7 descartes a cada 100 pings). Nessas situações, o problema fica um pouco mais fácil de ser identificado. A melhor maneira de identificar o gatilho é marcar o tráfego de teste com marcas DSCP e capturar os pacotes. O valor de DSCP é copiado para o cabeçalho ESP e pode ser filtrado com o Wireshark. Essa configuração, que pressupõe um teste com 100 pings, pode ser usada para marcar os pacotes ICMP:
ip access-list extended VPN_TRAFFIC
permit icmp <source> <destination>
class-map match-all MARK
match access-group name VPN_TRAFFIC
policy-map MARKING
class MARK
set dscp af21
Essa política agora deve ser aplicada à interface de ingresso onde o tráfego claro é recebido no roteador de criptografia:
interface GigabitEthernet0/0
service-policy MARKING in
Como alternativa, você pode executar esse teste com o tráfego gerado pelo roteador. Para isso, você não pode usar a Qualidade de Serviço (QoS) para marcar os pacotes, mas pode usar o Roteamento Baseado em Políticas (PBR - Policy-Based Routing).
ip access-list extended VPN_TRAFFIC
permit icmp <source> <destination>
route-map markicmp permit 10
match ip address vpn
set ip precedence critical
ip local policy route-map markicmp
Depois que a marcação de QoS for configurada para o tráfego ICMP, você poderá configurar a captura de pacotes embutidos:
Router(config)# ip access-list ext vpn_capo
Router(config)# permit ip host
Router(config)# permit ip host
Router(config)# exit //the capture is only configured in enable mode.
Router# monitor capture buffer vpncap size 256 max-size 100 circular
Router# monitor capture buffer vpncap filter access-list vpn_capo
Router# monitor capture point ip cef capo fastEthernet 0/1 both
Router# monitor capture point associate capo vpncap
Router# monitor capture point start capo //starts the capture.
To stop replace the "start" keyword with "stop"
Note: esse recurso foi apresentado no Cisco IOS versão 12.4(20)T. Consulte Captura de Pacotes Incorporados para obter mais informações sobre EPCs.
O uso de uma captura de pacote para solucionar esse tipo de problema exige que o pacote inteiro seja capturado, não apenas uma parte dele. O recurso EPC nas versões do Cisco IOS anteriores a 15.0(1)M tem um limite de buffer de 512K e um limite máximo de tamanho de pacote de 1024 bytes. Para evitar essa limitação, atualize para 15.0(1)M ou código mais recente, que agora suporta um tamanho de buffer de captura de 100M com um tamanho máximo de pacote de 9500 bytes.
Se o problema puder ser reproduzido com confiabilidade a cada ping de contagem de 100, o pior cenário é programar uma janela de manutenção para permitir apenas o tráfego de ping como um teste controlado e fazer as capturas. Esse processo deve levar apenas alguns minutos, mas interrompe o tráfego de produção por esse tempo. Se você usar a marcação de QoS, poderá eliminar a exigência de restringir pacotes somente a pings. Para capturar todos os pacotes de ping em um buffer, você deve garantir que o teste não seja realizado durante as horas de pico.
Se o problema não for facilmente reproduzido, você poderá usar um script EEM para automatizar a captura de pacotes. A teoria é que você começa as capturas de ambos os lados em um buffer circular e usa EEM para interromper a captura de um lado. Ao mesmo tempo, o EEM interrompe a captura, faça com que envie uma armadilha snmp para o peer, que interrompe sua captura. Esse processo pode funcionar. Mas se a carga for pesada, o segundo roteador pode não reagir com a rapidez suficiente para interromper sua captura. É preferível um teste controlado. Aqui estão os scripts do EEM que implementarão o processo:
Receiver
========
event manager applet detect_bad_packet
event syslog pattern "RECVD_PKT_MAC_ERR"
action 1.0 cli command "enable"
action 2.0 cli command "monitor capture point stop test"
action 3.0 syslog msg "Packet corruption detected and capture stopped!"
action 4.0 snmp-trap intdata1 123456 strdata ""
Sender
======
event manager applet detect_bad_packet
event snmp-notification oid 1.3.6.1.4.1.9.10.91.1.2.3.1.9.
oid-val "123456" op eq src-ip-address 20.1.1.1
action 1.0 cli command "enable"
action 2.0 cli command "monitor capture point stop test"
action 3.0 syslog msg "Packet corruption detected and capture stopped!"
Observe que o código na caixa anterior é uma configuração testada com 15.0(1)M. Talvez você queira testá-la com a versão específica do Cisco IOS que seu cliente usa antes de implementá-la no ambiente do cliente.
ip.dsfield.dscp==0x08
"0x08" é específico para o valor de DSCP AF21. Se um valor de DSCP diferente for usado, o valor correto pode ser obtido da própria captura de pacote ou da lista de valores de DSCP do gráfico de conversão. Consulte DSCP e Valores de Precedência para obter mais informações.
*Mar 1 00:01:38.923: After encryption:
05F032D0: 45000088 00000000 E.......
05F032E0: FF3266F7 0A01201A 0A012031 7814619F .2fw.. ... 1x.a.
05F032F0: 00000001 DE9B4CEF ECD9178C 3E7A7F24 ....^.LolY..>z.$
05F03300: 83DCF16E 7FD64265 79F624FB 74D5AEF2 .\qn.VBeyv${tU.r
05F03310: 5EC0AC16 B1F9F3AB 89524205 A20C4E58 ^@,.1ys+.RB.".NX
05F03320: 09CE001B 70CC56AB 746D6A3A 63C2652B .N..pLV+tmj:cBe+
05F03330: 1992E8AF 2CE2A279 46367BDB 660854ED ..h/,b"yF6{[f.Tm
05F03340: 77B69453 83E47778 1470021F 09436285 w6.S.dwx.p...Cb.
05F03350: CB94AEF5 20A65B1F 480D86F6 125BA12E K..u &[.H..v.[!.
4F402C90: 45000088 00000000 E.......
4F402CA0: FF3266F7 0A01201A 0A012031 7814619F .2fw.. ... 1x.a.
4F402CB0: 00000001 DE9B4CEF ECD9178C 3E7A7F24 ....^.LolY..>z.$
4F402CC0: 83DCF16E 7FD64265 79F624FB 74D5AEF2 .\qn.VBeyv${tU.r
4F402CD0: 5EC0AC16 B1F9F3AB 89524205 A20C4E58 ^@,.1ys+.RB.".NX
4F402CE0: 09CE001B 70CC56AB 00000000 00000000 .N..pLV+........
4F402CF0: 00000000 00000000 00000000 00000000 ................
4F402D00: 00000000 00000000 00000000 00000000 ................
4F402D10: 00000000 00000000 00000000 00000000 ................
Revisão | Data de publicação | Comentários |
---|---|---|
1.0 |
24-Oct-2013 |
Versão inicial |