Explicações de falhas de queda de pacote na ACI
Contents
Introduction
Este documento descreve cada tipo de falha e o procedimento quando você vê essa falha. Durante a operação normal de uma estrutura da Cisco Application Centric Infrastructure (ACI), o administrador pode ver falhas em determinados tipos de quedas de pacotes.
Objetos Gerenciados
Na Cisco ACI, todas as falhas são geradas em Managed Objects (MO). Por exemplo, uma falha " F11245 - ingress drop packets rate (l2IngrPktsAg15min:dropRate) " está relacionada ao parâmetro dropRate em MO l2IngrPktsAg15min.
Esta seção apresenta alguns exemplos de objetos gerenciados (MO) relacionados a falhas de pacotes descartados.
| Exemplo | Descrição | Exemplos de parâmetros | Exemplo de MO contra quais falhas são geradas |
|
| l2IngrPkts | l2IngrPkts5min l2IngrPkts15min l2IngrPkts1h etc... |
Isso representa estatísticas de pacote de entrada por VLAN durante cada período | dropRate floodRate multicastRate unicastRate |
vlanCktEp (VLAN) |
| l2IngrPktsAg | l2IngrPktsAg15min l2IngrPktsAg1h l2IngrPktsAg1d etc... |
Isso representa estatísticas de pacote de entrada por EPG, BD, VRF etc... Ex.) As estatísticas de EPG representam a agregação de estatísticas de VLAN que pertencem ao EPG |
dropRate floodRate multicastRate unicastRate |
fvAEPg (EPG) fvAp (Perfil do Aplicativo) fvBD (BD) l3extOut (L3OUT) |
| eqptIngrDropPkts | eqptIngrDropPkts15min eqptIngrDropPkts1h eqptIngrDropPkts1d etc... |
Isso representa estatísticas de pacote de queda de entrada por interface durante cada período | *1 taxa de encaminhamento *1 taxa de erro *1 taxa de buffer |
l1PhysIf (porta física) pcAggrIf (canal de porta) |
*1: Esses contadores em eqptIngrDropPkts podem ser erguidos incorretamente devido a uma limitação de ASIC em várias plataformas Nexus 9000, porque os pacotes SUP_REDIRECT estão sendo registrados como descartes de encaminhamento. Ver também CSCvo68407 
e CSCvn72699 para mais detalhes e versões fixas.
Tipos de contador de queda de hardware
Nos switches Nexus 9000 em execução no modo ACI, há 3 contadores de hardware principais para o motivo de queda da interface de entrada no ASIC.
Uma dropRate em l2IngrPkts, l2IngrPktsAg inclui esses contadores. Três parâmetros (forwardingRate, errorRate, bufferRate) na tabela acima para eqptIngrDropPkts representam cada três contadores de interface.
Encaminhar
Descartes posteriores, são pacotes que são descartados no bloco de pesquisa (LU) do ASIC. No bloco de LU, uma decisão de encaminhamento de pacotes é tomada com base nas informações do cabeçalho do pacote. Se a decisão é descartar o pacote, Forward Drop é contado. Há uma variedade de razões pelas quais isso pode acontecer, mas vamos falar sobre os principais:
SECURITY_GROUP_DENY
Uma queda devido à falta de contratos para permitir a comunicação.
Quando um pacote entra na estrutura, o switch olha para o EPG de origem e de destino para ver se há um contrato que permita essa comunicação. Se a origem e o destino estiverem em EPGs diferentes e não houver contrato que permita esse tipo de pacote entre eles, o switch descartará o pacote e o rotulará como SECURITY_GROUP_DENY. Isso incrementa o contador de queda de encaminhamento.
VLAN_XLATE_MISS
Uma queda devido a uma VLAN inadequada.
Quando um pacote entra na estrutura, o switch examina o pacote para determinar se a configuração na porta permite esse pacote. Por exemplo, um quadro entra na estrutura com uma marca 802.1Q de 10. Se o switch tiver a VLAN 10 na porta, ele inspecionará o conteúdo e tomará uma decisão de encaminhamento com base no MAC de destino. No entanto, se a VLAN 10 não estiver na porta, ela a descartará e a rotulará como VLAN_XLATE_MISS. Isso incrementará o contador Forward Drop.
A razão para "XLATE" ou "Translate" é que, na ACI, o switch leaf pegará um quadro com uma capa 802.1Q e o traduzirá para uma nova VLAN que será usada para VXLAN e outra normalização dentro da estrutura. Se o quadro entrar com uma VLAN não implantada, a "conversão" falhará.
ACL_DROP
Uma gota por causa da câmera sup.
a sup-tcam em switches ACI contém regras especiais a serem aplicadas sobre a decisão normal de encaminhamento de L2/L3. As regras na câmera sup-tcam são incorporadas e não configuráveis pelo usuário. O objetivo das regras de comando sup-tcam consiste principalmente em lidar com algumas exceções ou parte do tráfego do plano de controle e não deve ser verificado ou monitorado pelos usuários. Quando o pacote está atingindo as regras de sup-tcam e a regra é descartar o pacote, o pacote descartado é contado como ACL_DROP e ele incrementará o contador Forward Drop. Quando isso ocorre, isso geralmente significa que o pacote está prestes a ser encaminhado contra os princípios básicos de encaminhamento da ACI.
Observe que, mesmo que o nome da queda seja ACL_DROP, essa "ACL" não é igual à lista de controle de acesso normal que pode ser configurada em dispositivos NX-OS autônomos ou em qualquer outro dispositivo de roteamento/switching.
SUP_REDIRECT
Isto não é uma gota.
Um pacote redirecionado sup (ou seja, CDP/LLDP/UDLD/BFD etc..) pode ser contado como Descarte de encaminhamento mesmo que o pacote seja processado corretamente e encaminhado para a CPU.
Isso pode ocorrer somente na plataforma -EX, como N9K-C93180YC-EX. Eles não devem ser contados como "drop", no entanto, é devido à limitação de ASIC na plataforma -EX.
Erro
Quando o switch recebe um quadro inválido em uma das interfaces do painel frontal, ele é descartado como um erro. Exemplos disso incluem quadros com erros de FCS ou CRC. Ao examinar as portas leaf Uplink/Downlink, ou portas Spine, é melhor verificar erros de FCS/CRC usando "show interface".
No entanto, em operações normais, espera-se que os Pacotes de Erro sejam incrementados em portas Uplink/Downlinks de leafs ou portas Spine, já que esse contador também inclui quadros que são podados pelo sistema e não devem ser enviados para fora da interface.
Exemplo: Falhas de TTL para pacotes roteados, mesma interface broadcast/quadros inundados.
Buffer
Quando o switch recebe um quadro e não há nenhum crédito de buffer disponível para entrada ou saída, o quadro será descartado com "Buffer". Isso geralmente indica congestionamento em algum lugar da rede. O link que está mostrando a falha pode estar cheio ou o link que contém o destino pode estar congestionado.
Exibição de estatísticas de queda na CLI
Objetos Gerenciados
Secure Shell (SSH) para um dos APIC e execute os seguintes comandos.
apic1# moquery -c l2IngrPktsAg15min
Isso fornecerá todas as instâncias de objeto para esta classe l2IngrPktsAg15min.
Aqui está um exemplo com um filtro para consultar um objeto específico. Neste exemplo, o filtro deve mostrar apenas um objeto com atributos dn que incluem "tn-TENANT1/ap-APP1/epg-EPG1" .
Além disso, este exemplo usa egrep para mostrar apenas os atributos necessários.
Exemplo de saída 1: Objeto de contador EPG (l2IngrPktsAg15min) do inquilino TENANT1, perfil de aplicação APP1, epg EPG1.
apic1# moquery -c l2IngrPktsAg15min -f 'l2.IngrPktsAg15min.dn*"tn-TENANT1/ap-APP1/epg-EPG1"' | egrep 'dn|drop[P,R]|rep'
dn : uni/tn-TENANT1/ap-APP1/epg-EPG1/CDl2IngrPktsAg15min dropPer : 30 <--- number of drop packet in the current periodic interval (600sec) dropRate : 0.050000 <--- drop packet rate = dropPer(30) / periodic interval(600s) repIntvEnd : 2017-03-03T15:39:59.181-08:00 <--- periodic interval = repIntvEnd - repIntvStart repIntvStart : 2017-03-03T15:29:58.016-08:00 = 15:39 - 15:29
= 10 min = 600 sec
Ou poderíamos usar outra opção -d em vez de -c para obter um objeto específico se você souber o objeto dn.
Exemplo de saída 2: Objeto de contador EPG (l2IngrPktsAg15min) do inquilino TENANT1, perfil de aplicação APP1, epg EPG2.
apic1# moquery -d uni/tn-TENANT1/ap-APP1/epg-EPG2/CDl2IngrPktsAg15min | egrep 'dn|drop[P,R]|rep' dn : uni/tn-jw1/BD-jw1/CDl2IngrPktsAg15min dropPer : 30 dropRate : 0.050000 repIntvEnd : 2017-03-03T15:54:58.021-08:00 repIntvStart : 2017-03-03T15:44:58.020-08:00
Contadores de hardware
Se você vir falhas ou quiser verificar quedas de pacote em portas de switch usando a CLI, a melhor maneira de fazer isso é visualizar os contadores de plataforma no hardware. A maioria, mas nem todos os contadores são mostrados usando show interface. Os 3 principais motivos para a queda só podem ser vistos com os contadores da plataforma. Para exibi-las, execute estas etapas:
Folha
SSH para a folha e execute esses comandos.
ACI-LEAF# vsh_lc
module-1# show platform internal counters port <X>
* onde X representa o número da porta
Exemplo de saída para Ethernet 1/31 :
ACI-LEAF# vsh_lc
vsh_lc
module-1#
module-1# show platform internal counters port 31
Stats for port 31
(note: forward drops includes sup redirected packets too)
IF LPort Input Output
Packets Bytes Packets Bytes
eth-1/31 31 Total 400719 286628225 2302918 463380330
Unicast 306610 269471065 453831 40294786
Multicast 0 0 1849091 423087288
Flood 56783 8427482 0 0
Total Drops 37327 0
Buffer 0 0
Error 0 0
Forward 37327
LB 0
AFD RED 0
----- snip -----
Spine
Para um tipo de caixa spine (N9K-C936PQ), é exatamente o mesmo que Leaf.
Para spines modulares (N9K-C9504 etc...), você deve primeiro conectar a placa de linha específica antes de visualizar os contadores da plataforma. SSH para a coluna e execute estes comandos
ACI-SPINE# vsh
ACI-SPINE# anexar módulo <X>
module-2# show platform internal counters port <Y>.
* onde X representa o número do módulo da placa de linha que você gostaria de ver
Y representa o número da porta
Exemplo de saída para ethernet 2/1 :
ACI-SPINE# vsh Cisco iNX-OS Debug Shell This shell should only be used for internal commands and exists for legacy reasons. User should use ibash infrastructure as this will be deprecated. ACI-SPINE#
ACI-SPINE# attach module 2 Attaching to module 2 ... To exit type 'exit', to abort type '$.' Last login: Mon Feb 27 18:47:13 UTC 2017 from sup01-ins on pts/1 No directory, logging in with HOME=/ Bad terminal type: "xterm-256color". Will assume vt100. module-2#
module-2# show platform internal counters port 1 Stats for port 1 (note: forward drops includes sup redirected packets too) IF LPort Input Output Packets Bytes Packets Bytes eth-2/1 1 Total 85632884 32811563575 126611414 25868913406 Unicast 81449096 32273734109 104024872 23037696345 Multicast 3759719 487617769 22586542 2831217061 Flood 0 0 0 0 Total Drops 0 0 Buffer 0 0 Error 0 0 Forward 0 LB 0 AFD RED 0 ----- snip -----
Falhas
F112425 - ingress drop packets rate (l2IngrPktsAg15min:dropRate)
Descrição:
Uma das razões populares para essa falha é que os pacotes da Camada 2 são descartados com a razão "Forward Drop" (Descarte de encaminhamento). Há várias razões, mas a mais comum é:
Em algumas plataformas (consulte CSCvo68407 ), há uma limitação em que os pacotes L2 que precisam ser redirecionados para a CPU (ou seja, CDP/LLDP/UDLD/BFD, etc.) serão registrados como "Forward Drop" (Descarte para frente) e serão copiados para a CPU. Isso se deve a uma limitação do ASIC usado nesses modelos.
Resolução:
As gotas descritas acima são puramente cosméticas, portanto a recomendação de melhores práticas é aumentar o limite para a falha, conforme mostrado na seção Limite de estatísticas. Para fazer isso, consulte as instruções no Limite de estatísticas.
F100264 - ingress buffer drop packets rate (eqptIngrDropPkts5min:bufferRate)
Descrição:
Essa falha pode aumentar quando os pacotes estão sendo descartados em uma porta com a razão "Buffer", conforme mencionado acima, isso normalmente acontece quando há congestionamento em uma interface na direção de entrada ou de saída.
Resolução:
Essa falha representa pacotes descartados reais no ambiente devido ao congestionamento. Os pacotes descartados podem estar causando problemas com aplicativos executados na estrutura da ACI. Os administradores de rede devem isolar o fluxo do pacote e determinar se o congestionamento é devido a fluxos de tráfego inesperados, balanceamento de carga ineficiente, etc.; ou a utilização esperada nessas portas.
F100696 - ingress forwarding drop packets (eqptIngrDropPkts5min:forwardingRate)
Essa falha é causada por alguns cenários. A mais comum é:
Descrição 1) Quedas de coluna
Se essa falha for observada em uma interface Spine, isso pode ser devido ao tráfego em direção a um endpoint desconhecido.
Quando um pacote ARP ou IP é encaminhado à coluna para uma pesquisa de proxy e o ponto final é desconhecido na estrutura, um pacote glean especial será gerado e enviado a todos os leafs no endereço de grupo multicast BD (interno) apropriado. Isso acionará uma solicitação ARP de cada folha no BD (Bridge Domain, Domínio da Bridge) para descobrir o ponto final. Devido a uma limitação, o pacote glean recebido pela folha também é refletido novamente na estrutura e aciona uma queda de encaminhamento no link spine conectado à folha. A queda de encaminhamento neste cenário é incrementada apenas no hardware spine de primeira geração.
Resolução 1)
Como se sabe que o problema é causado por um dispositivo que envia uma quantidade desnecessária de tráfego unicast desconhecido para a estrutura da ACI, é necessário descobrir qual dispositivo está causando isso e ver se ele pode ser evitado. Geralmente, isso é causado por dispositivos que verificam ou investigam endereços IP em sub-redes para fins de monitoramento. Para descobrir qual IP está enviando esse tráfego, faça SSH na folha conectada à interface spine mostrando a falha.
A partir daí, você pode executar esse comando para ver o Endereço IP de Origem (sip) que está disparando o pacote glean:
ACI-LEAF# show ip arp internal event-history event | grep glean | grep sip | more
[116] TID 11304:arp_handle_inband_glean:3035: log_collect_arp_glean;sip = 192.168.21.150;dip = 192.168.20.100;info = Received glean packet is an IP packet
[116] TID 11304:arp_handle_inband_glean:3035: log_collect_arp_glean;sip = 192.168.21.150;dip = 192.168.20.100;info = Received glean packet is an IP packet
Neste exemplo de saída, o pacote glean é disparado por 192.168.21.150 e é recomendável ver se isso pode ser atenuado.
Descrição 2 ) Quedas de Folha
Se essa falha for vista em uma interface leaf, a causa mais provável é a queda de SECURITY_GROUP_DENY mencionada.
Resolução 2 )
O leaf da ACI mantém um log de pacotes negados devido a violações de contrato.Esse log não captura todos eles para proteger os recursos da CPU, mas ainda fornece uma grande quantidade de logs.
Para obter os registros necessários, se a interface na qual a falha é gerada for parte de um canal de porta, é necessário usar esse comando e grep para o canal de porta. Caso contrário, a interface física pode ser cortada.
Esse log pode ser rapidamente revertido, dependendo da quantidade de quedas de contrato.
ACI-LEAF# show logging ip access-list internal packet-log deny | grep port-channel2 | more [ Sun Feb 19 14:16:12 2017 503637 usecs]: CName: jr:sb(VXLAN: 2129921), VlanType: FD_VLAN, Vlan-Id: 59, SMac: 0x8c604f0288fc, DMac:0x0022bdf819ff, SIP: 192.168.21.150, DIP: 192.168.20.3, SPort: 0, DPort: 0, Src Intf: port-channel2, Pr oto: 1, PktLen: 98 [ Sun Feb 19 14:16:12 2017 502547 usecs]: CName: jr:sb(VXLAN: 2129921), VlanType: FD_VLAN, Vlan-Id: 59, SMac: 0x8c604f0288fc, DMac:0x0022bdf819ff, SIP: 192.168.21.150, DIP: 192.168.20.3, SPort: 0, DPort: 0, Src Intf: port-channel2, Pr oto: 1, PktLen: 98
Nesse caso, 192.168.21.150 está tentando enviar mensagens ICMP (número de protocolo IP 1) para 192.168.20.3. No entanto, não há contrato entre os 2 EPGs que permita o ICMP, portanto, o pacote é descartado. Se o ICMP for suposto ser permitido, pode ser adicionado um contrato entre os dois EPG.
Limite de estatísticas
Esta seção descreve como alterar um limite para um objeto de estatísticas que pode potencialmente gerar uma falha no contador de queda.
Um limite para estatísticas de cada objeto (por exemplo, l2IngrPkts, eqptIngrDropPkts) é configurado através da Política de Monitoramento em relação à variedade de objetos.
Como mencionado na tabela no início, eqptIngrDropPkts é monitorado em, por exemplo, objetos l1PhysIf através da Política de Monitoramento.
Taxa de Pacotes de Descarte de Encaminhamento em eqptIngrDropPkts
Há duas partes para isso.
+ Políticas de acesso (portas para dispositivos externos. portas do painel frontal)
+ Políticas de estrutura (portas entre LEAF e SPINE). portas de estrutura t.c.a)
Cada objeto de porta (l1PhysIf, pcAggrIf) pode receber sua própria Política de Monitoramento através do Grupo de Política de Interface, como mostrado na figura acima.
Por padrão, há uma política de monitoramento padrão em Fabric > Access Policies e Fabric > Fabric Policies na GUI do APIC. Essas Políticas de monitoramento padrão são atribuídas a todas as portas, respectivamente. A política de monitoramento padrão em Políticas de acesso é para portas do painel frontal e a política de monitoramento padrão em Políticas de estrutura é para portas de estrutura.
A menos que seja necessário alterar limites por porta, a Política de monitoramento padrão em cada seção pode ser modificada diretamente para aplicar a alteração para todas as portas do painel frontal e/ou portas de estrutura.
O exemplo a seguir é para alterar os limites de Forward Drop em eqptIngrDropPkts em portas de estrutura (Políticas de estrutura). Execute a mesma coisa em Estrutura > Políticas de acesso para as portas do painel frontal.
1. Navegue para Estrutura >Políticas de estrutura >Políticas de monitoramento.
2. Clique com o botão direito do mouse e selecione "Criar política de monitoramento".
(Se a alteração de limite puder ser aplicada a todas as portas de estrutura, navegue até o padrão em vez de criar um novo)
3. Expanda a nova Política de Monitoramento ou o padrão e navegue para Políticas de Coleta de Estatísticas.
4. Clique no ícone do lápis do Objeto de Monitoramento no painel direito e selecione Configuração da Interface Física da Camada 1 (l1.PhysIf).
(Esta etapa 4 pode ser ignorada quando a política padrão é usada)
5. Na lista suspensa Objeto de Monitoramento no painel direito, escolha Layer 1 Physical Interface Configuration (l1.PhysIf) e Stats Type, escolha Ingress Drop Packets
6. Clique em + Próximo aos limites de configuração
7. Edite o Limite para Descarte de Encaminhamento
8. A recomendação é desabilitar os limites crescentes para a configuração de crítico, principal, secundário e aviso para taxa de queda de encaminhamento.
9. Aplique esta nova Política de Monitoramento ao Grupo de Política de Interface para as portas necessárias. Não se esqueça de configurar o Perfil da Interface, o Perfil do Switch, etc... em políticas de estrutura de acordo.
(Esta etapa 9 pode ser ignorada quando a política padrão é usada)
10. Se for para Portas do Painel Frontal (Políticas de Acesso), execute a mesma coisa para Interface Agregada (pc.AggrIf) ao contrário de Configuração de Interface Física da Camada 1 (l1.PhysIf) para que esta nova Política de Monitoramento possa ser aplicada ao canal de porta e também à porta física.
(Esta etapa 10 pode ser ignorada quando a política padrão é usada)
Taxa de pacotes de entrada descartados em l2IngrPktsAg
Há várias partes para isso.
Como a imagem acima descreve, l2IngrPktsAg é monitorado sob muitos objetos. A imagem acima mostra apenas alguns exemplos, mas não todos os objetos de l2IngrPktsAg. No entanto, o limite para estatísticas é configurado através da Política de Monitoramento, bem como eqptIngrDropPkts em l1PhysIf ou pcAggrIf.
Cada objeto ( EPG(fvAEPg), Domínio da ponte (fvBD), etc... ) pode receber sua própria Política de monitoramento, como mostrado na figura acima.
Por padrão, todos esses objetos em espaço usam a Política de monitoramento padrão em Espaço > comum > Políticas de monitoramento > padrão, a menos que configurado de outra forma.
A menos que seja necessário alterar limites por cada componente, a Política de monitoramento padrão em comum de espaço pode ser modificada diretamente para aplicar a alteração para todos os componentes relacionados.
O exemplo a seguir é para alterar os limites da Taxa de Pacotes de Entrada Derivada em l2IngrPktsAg15min no Domínio da Bridge.
1. Navegue até Espaço > (nome do espaço) > Políticas de monitoramento.
(o espaço precisa ser comum se a política de monitoramento padrão for usada ou se a nova política de monitoramento precisar ser aplicada aos usuários)
2. Clique com o botão direito do mouse e selecione "Criar política de monitoramento".
(Se a alteração de limite puder ser aplicada a todos os componentes, navegue para o padrão em vez de criar um novo)
3. Expanda a nova Política de Monitoramento ou o padrão e navegue para Políticas de Coleta de Estatísticas.
4. Clique no ícone do lápis para o Objeto de monitoramento no painel direito e selecione Domínio da ponte (fv.BD).
(Esta etapa 4 pode ser ignorada quando a política padrão é usada)
5. No menu suspenso Monitoring Object no painel direito, escolha Bridge Domain (fv.BD) e Stats Type, escolha Aggregated ingress packets.
6. Clique em + Próximo aos limites de configuração
7. Edite o Limite para Descarte de Encaminhamento
8. A recomendação é desabilitar os limites crescentes para a configuração de crítico, principal, secundário e aviso para taxa de queda de encaminhamento.
9. Aplique esta nova Política de Monitoramento ao Domínio da Bridge, que requer alteração de limite.
(Esta etapa 9 pode ser ignorada quando a política padrão é usada)
Histórico de revisões
| Revisão | Data de publicação | Comentários |
|---|---|---|
3.0 |
11-Oct-2021 |
Conteúdo atualizado na seção Erro. |
1.0 |
10-Apr-2017 |
Versão inicial |
FeedbackContate a Cisco
- Abrir um caso de suporte
- (É necessário um Contrato de Serviço da Cisco)