O conjunto de documentação deste produto faz o possível para usar uma linguagem imparcial. Para os fins deste conjunto de documentação, a imparcialidade é definida como uma linguagem que não implica em discriminação baseada em idade, deficiência, gênero, identidade racial, identidade étnica, orientação sexual, status socioeconômico e interseccionalidade. Pode haver exceções na documentação devido à linguagem codificada nas interfaces de usuário do software do produto, linguagem usada com base na documentação de RFP ou linguagem usada por um produto de terceiros referenciado. Saiba mais sobre como a Cisco está usando a linguagem inclusiva.
A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização. Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional. A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.
Este documento descreve como verificar se os contratos estão configurados e se comportam corretamente na estrutura da Application Centric Infrastructure (ACI).
No exemplo usado neste documento, a máquina virtual A (VM) é anexada à Leaf1, e um contrato está em vigor permitindo que ela se comunique com a VM-B, que é anexada à Leaf2. O contrato permite o Internet Control Message Protocol (ICMP) e o HTTP.
Esta imagem ilustra a topologia:
Esta é a interação e o fluxo da política para contratos e regras:
Aqui está um exemplo da saída do comando show zoning-rule do leaf, antes que o contrato seja adicionado para os dois grupos de endpoint (EPGs).
fab1_leaf1# show zoning-rule
Rule ID SrcEPG DstEPG FilterID operSt Scope Action
======= ====== ====== ======== ====== ===== ======
4096 0 0 implicit enabled 16777200 deny,log
4097 0 0 implicit enabled 3080192 deny,log
4098 0 0 implicit enabled 2686976 deny,log
4099 0 49154 implicit enabled 2686976 permit
4102 0 0 implicit enabled 2097152 deny,log
4103 0 32771 implicit enabled 2097152 permit
4117 16387 16386 12 enabled 2097152 permit
4116 16386 16387 13 enabled 2097152 permit
4100 16386 49154 default enabled 2097152 permit
4101 49154 16386 default enabled 2097152 permit
4104 0 32770 implicit enabled 2097152 permit
4105 49155 16387 13 enabled 2097152 permit
4112 16387 49155 13 enabled 2097152 permit
4113 49155 16387 12 enabled 2097152 permit
4114 16387 49155 12 enabled 2097152 permit
[snip]
Esta é a mesma saída de comando depois que o contrato é adicionado para que os dois EPGs possam se comunicar um com o outro:
fab1_leaf1# show zoning-rule
Rule ID SrcEPG DstEPG FilterID operSt Scope Action
======= ====== ====== ======== ====== ======== ========
4096 0 0 implicit enabled 16777200 deny,log
4097 0 0 implicit enabled 3080192 deny,log
4098 0 0 implicit enabled 2686976 deny,log
4099 0 49154 implicit enabled 2686976 permit
4131 49155 32771 7 enabled 2686976 permit
4132 32771 49155 6 enabled 2686976 permit
4102 0 0 implicit enabled 2097152 deny,log
4103 0 32771 implicit enabled 2097152 permit
4117 16387 16386 12 enabled 2097152 permit
4116 16386 16387 13 enabled 2097152 permit
4100 16386 49154 default enabled 2097152 permit
4101 49154 16386 default enabled 2097152 permit
4104 0 32770 implicit enabled 2097152 permit
4105 49155 16387 13 enabled 2097152 permit
4112 16387 49155 13 enabled 2097152 permit
4113 49155 16387 12 enabled 2097152 permit
4114 16387 49155 12 enabled 2097152 permit
[snip]
Observação: observe as novas IDs de regra (4131 e 4132) que foram adicionadas, as IDs de filtro de 7 e 6 e o escopo de 2686976.
Cuidado: essa saída de comando permite que você localize facilmente as regras que devem ser examinadas em um sistema de laboratório; no entanto, isso pode ser incômodo em um ambiente de produção com as alterações dinâmicas que ocorrem.
Outro método que você pode empregar para localizar as regras de interesse é usar o Visore. Pesquise o MO (Objeto Gerenciado) de contexto para fvCtx. Em seguida, você pode pesquisar nessa tela por seu contexto específico Distinguished Name (DN), como mostrado aqui:
Anote o escopo para esse contexto. Você pode usar isso para mapear para a saída do comando show-zoning-rule para que possa localizar as regras que você deve consultar:
Você também pode identificar o ID/escopo do segmento para o contexto a partir da Interface do Usuário (UI), como mostrado aqui:
Este escopo corresponde ao mostrado na saída do comando show zoning-rules:
Depois de ter as informações de ID de escopo e identificar a regra e os IDs de filtro, você pode usar o próximo comando para verificar se atingiu os novos filtros (e não as mensagens de negação implícita entre os EPGs). A mensagem de negação implícita é incluída para que, por padrão, os EPGs não possam se comunicar.
Observe nesta saída de comando que Leaf1, Filter-6 (f-6) está incrementando:
fab1_leaf1# show system internal policy-mgr stats | grep 2686976
Rule (4098) DN (sys/actrl/scope-2686976/rule-2686976-s-any-d-any-f-implicit)
Ingress: 0, Egress: 81553
Rule (4099) DN (sys/actrl/scope-2686976/rule-2686976-s-any-d-49154-f-implicit)
Ingress: 0, Egress: 0
Rule (4131) DN (sys/actrl/scope-2686976/rule-2686976-s-49155-d-32771-f-7)
Ingress: 0, Egress: 0
Rule (4132) DN (sys/actrl/scope-2686976/rule-2686976-s-32771-d-49155-f-6)
Ingress: 1440, Egress: 0
fab1_leaf1# show system internal policy-mgr stats | grep 2686976
Rule (4098) DN (sys/actrl/scope-2686976/rule-2686976-s-any-d-any-f-implicit)
Ingress: 0, Egress: 81553
Rule (4099) DN (sys/actrl/scope-2686976/rule-2686976-s-any-d-49154-f-implicit)
Ingress: 0, Egress: 0
Rule (4131) DN (sys/actrl/scope-2686976/rule-2686976-s-49155-d-32771-f-7)
Ingress: 0, Egress: 0
Rule (4132) DN (sys/actrl/scope-2686976/rule-2686976-s-32771-d-49155-f-6)
Ingress: 1470, Egress: 0
Observe nesta saída de comando que Leaf2, Filter-7 (f-7) está incrementando:
fab1_leaf2# show system internal policy-mgr stats | grep 268697
Rule (4098) DN (sys/actrl/scope-2686976/rule-2686976-s-any-d-any-f-implicit)
Ingress: 0, Egress: 80257
Rule (4099) DN (sys/actrl/scope-2686976/rule-2686976-s-any-d-49153-f-implicit)
Ingress: 0, Egress: 0
Rule (4117) DN (sys/actrl/scope-2686976/rule-2686976-s-32771-d-49155-f-6)
Ingress: 0, Egress: 0
Rule (4118) DN (sys/actrl/scope-2686976/rule-2686976-s-49155-d-32771-f-7)
Ingress: 2481, Egress: 0
fab1_leaf2# show system internal policy-mgr stats | grep 268697
Rule (4098) DN (sys/actrl/scope-2686976/rule-2686976-s-any-d-any-f-implicit)
Ingress: 0, Egress: 80257
Rule (4099) DN (sys/actrl/scope-2686976/rule-2686976-s-any-d-49153-f-implicit)
Ingress: 0, Egress: 0
Rule (4117) DN (sys/actrl/scope-2686976/rule-2686976-s-32771-d-49155-f-6)
Ingress: 0, Egress: 0
Rule (4118) DN (sys/actrl/scope-2686976/rule-2686976-s-49155-d-32771-f-7)
Ingress: 2511, Egress: 0
Dica: o conhecimento do escopo, da ID da regra, do destino, dos pcTags de origem e do filtro é importante nas tentativas de solucionar esse problema ainda mais. Também é útil ter conhecimento dos EPGs entre os quais o ID de regra existe.
Você pode executar uma pesquisa no MO com o nome DN fvAEPg e grep para o pcTag específico através do comando moquery, como mostrado aqui:
admin@RTP_Apic1:~> moquery -c fvAEPg | grep 49155 -B 5
dn : uni/tn-Prod/ap-commerceworkspace/epg-Web
lcOwn : local
matchT : AtleastOne
modTs : 2014-10-16T01:27:35.355-04:00
monPolDn : uni/tn-common/monepg-default
pcTag : 49155
Você também pode usar a opção filter com o comando moquery, como mostrado aqui:
admin@RTP_Apic1:~> moquery -c fvAEPg -f 'fv.AEPg.pcTag=="49155"'
Total Objects shown: 1
# fv.AEPg
name : Web
childAction :
configIssues :
configSt : applied
descr :
dn : uni/tn-Prod/ap-commerceworkspace/epg-Web
lcOwn : local
matchT : AtleastOne
modTs : 2014-10-16T01:27:35.355-04:00
monPolDn : uni/tn-common/monepg-default
pcTag : 49155
prio : unspecified
rn : epg-Web
scope : 2523136
status :
triggerSt : triggerable
uid : 15374
Agora você pode verificar a entrada de hardware para a regra. Para visualizar as informações de hardware, insira o comando show platform internal ns table mth_lux_slvz_DHS_SecurityGroupStatTable_memif_data ingress (esse é um comando vsh_lc):
Neste exemplo, a entrada de hardware 41 (ENTRY [000041]) está aumentando.
Observação: o comando anterior mostrado é usado para o ASIC Northstar. O comando usado para Donner ou Donner+ é show platform internal ns table mth_luxh_DHS_SecurityGroupStatTable_memif_data.
Observação: o uso desse comando não é prático em um ambiente de produção, mas você pode usar os outros comandos descritos nesta seção.
Lembre-se da regra (4132) e do escopo (268976).
Insira este comando para determinar o ID da regra para o mapeamento de entrada de índice de hardware TCAM (memória de conteúdo endereçável ternária) e filtre com base no ID da regra e/ou ID do filtro:
module-1# show system internal aclqos zoning-rules
[snip]
===========================================
Rule ID: 4131 Scope 4 Src EPG: 49155 Dst EPG: 32771 Filter 7
Curr TCAM resource:
=============================
unit_id: 0
=== Region priority: 771 (rule prio: 3 entry: 3)===
sw_index = 62 | hw_index = 40
=== Region priority: 772 (rule prio: 3 entry: 4)===
sw_index = 63 | hw_index = 45
===========================================
Rule ID: 4132 Scope 4 Src EPG: 32771 Dst EPG: 49155 Filter 6
Curr TCAM resource:
=============================
unit_id: 0
=== Region priority: 771 (rule prio: 3 entry: 3)===
sw_index = 66 | hw_index = 41
=== Region priority: 771 (rule prio: 3 entry: 3)===
sw_index = 67 | hw_index = 42
[snip]
Para este exemplo, a combinação de interesse do EPG origem e destino é 32771=0x8003, 49155=0xC003. Portanto, você pode considerar todas as entradas de TCAM para essas classes de origem e destino que correspondem aos IDs de regra (4131 e 4132) e IDs de filtro (6 e 7).
Neste exemplo, algumas dessas entradas TCAM são despejadas. Para referência, aqui está a configuração do contrato que permite pings e tráfego da Web para esses EPGs:
module-1# show platform internal ns table mth_lux_slvz_DHS_SecurityGroupKeyTable0
_memif_data 41
=======================================================================
TABLE INSTANCE : 0
=======================================================================
ENTRY[000041] =
sg_label=0x4
sclass=0x8003
dclass=0xc003
prot=0x1 (IP Protocol 0x01 = ICMP)
Observação: o comando anterior mostrado é usado para o ASIC Northstar. O comando usado para Donner ou Donner+ é show platform internal ns table mth_luxh_slvq_DHS_SecurityGroupKeyTable0_memif_data.
sup_tx_mask=0x1
src_policy_incomplete_mask=0x1
dst_policy_incomplete_mask=0x1
class_eq_mask=0x1
aclass_mask=0x1ff
port_dir_mask=0x1
dport_mask=0xffff
sport_mask=0xffff
tcpflags_mask=0xff
ip_opt_mask=0x1
ipv6_route_mask=0x1
ip_fragment_mask=0x1
ip_frag_offset0_mask=0x1
ip_frag_offset1_mask=0x1
ip_mf_mask=0x1
l4_partial_mask=0x1
dst_local_mask=0x1
routeable_mask=0x1
spare_mask=0x7ff
v4addr_key_mask=0x1
v6addr_key_mask=0x1
valid=0x1
module-1# show platform internal ns table mth_lux_slvz_DHS_SecurityGroupKeyTable0
_memif_data 42
=======================================================================
TABLE INSTANCE : 0
=======================================================================
ENTRY[000042] =
sg_label=0x4
sclass=0x8003
dclass=0xc003
prot=0x6 <--
dport=0x50 <--
sup_tx_mask=0x1
src_policy_incomplete_mask=0x1
dst_policy_incomplete_mask=0x1
class_eq_mask=0x1
aclass_mask=0x1ff
port_dir_mask=0x1
sport_mask=0xffff
tcpflags_mask=0xff
ip_opt_mask=0x1
ipv6_route_mask=0x1
ip_fragment_mask=0x1
ip_frag_offset0_mask=0x1
ip_frag_offset1_mask=0x1
ip_mf_mask=0x1
l4_partial_mask=0x1
dst_local_mask=0x1
Dica: você pode verificar cada uma das entradas de TCAM com o mesmo método.
Esta seção fornece alguns comandos e dicas úteis para a solução de problemas.
Aqui estão alguns comandos úteis que você pode usar para localizar os erros do Gerenciador de política de folha quando problemas são encontrados:
fab1_leaf1# show system internal policy-mgr event-history errors
1) Event:E_DEBUG, length:84, at 6132 usecs after Mon Sep 8 13:15:56 2014
[103] policy_mgr_handle_ctx_mrules(779): ERROR: Failed to process prio(1537):
(null)
2) Event:E_DEBUG, length:141, at 6105 usecs after Mon Sep 8 13:15:56 2014
[103] policy_mgr_process_mrule_prio_aces(646): ERROR: Failed to insert iptables
rule for rule(4120) , fentry(5_0) with priority(1537): (null)
[snip]
fab1_leaf1# show system internal policy-mgr event-histor trace
[1409945922.23737] policy_mgr_ppf_hdl_close_state:562: Got close state callback
[1409945922.23696] policy_mgr_ppf_rdy_ntf_fun:239: StatStoreEnd returned: 0x0(SU
CCESS)
[1409945922.23502] policy_mgr_ppf_rdy_ntf_fun:208: ppf ready notification: sess_
id: (0xFF0104B400005B51)
[1409945922.23475] policy_mgr_ppf_rdy_ntf_fun:205: Got ready notification callba
ck with statustype (4)
[1409945921.983476] policy_mgr_gwrap_handler:992: Dropped...now purging it...
[1409945921.982882] policy_mgr_ppf_goto_state_fun:481: Sess id (0xFF0104B400005B
[snip]
module-1# show system internal aclqos event-history trace
T [Fri Sep 5 13:18:24.863283] ============= Session End ============
T [Fri Sep 5 13:18:24.862924] Commit phase: Time taken 0.62 ms, usr 0.00 ms,
sys 0.00 ms
T [Fri Sep 5 13:18:24.862302] ppf session [0xff0104b410000087] commit ... npi
nst 1
T [Fri Sep 5 13:18:24.861421] Verify phase: Time taken 0.77 ms, usr 0.00 ms,
sys 0.00 ms
T [Fri Sep 5 13:18:24.860615] ============= Session Begin ============
T [Fri Sep 5 13:18:24.830472] ============= Session End ============
T [Fri Sep 5 13:18:24.830062] Commit phase: Time taken 0.98 ms, usr 0.00 ms,
sys 0.00 ms
T [Fri Sep 5 13:18:24.829085] ppf session [0xff0104b410000086] commit ... npi
nst 1
T [Fri Sep 5 13:18:24.827685] Verify phase: Time taken 2.04 ms, usr 0.00 ms,
sys 0.00 ms
T [Fri Sep 5 13:18:24.825388] ============= Session Begin ============
T [Fri Sep 5 12:32:51.364225] ============= Session End ============
T [Fri Sep 5 12:32:51.363748] Commit phase: Time taken 0.64 ms, usr 0.00 ms,
[snip]
Dica: alguns dos arquivos são grandes, por isso é mais fácil enviá-los para o flash de inicialização e examiná-los em um editor.
module-1# show system internal aclqos ?
asic Asic information
brcm Broadcam information
database Database
event-history Show various event logs of ACLQOS
mem-stats Show memory allocation statistics of ACLQOS
prefix External EPG prefixes
qos QoS related information
range-resource Zoning rules L4 destination port range resources
regions Security TCAM priority regions
span SPAN related information
zoning-rules Show zoning rules
module-1# show system internal aclqos event-history ?
errors Show error logs of ACLQOS
msgs Show various message logs of ACLQOS
ppf Show ppf logs of ACLQOS
ppf-parse Show ppf-parse logs of ACLQOS
prefix Show prefix logs of ACLQOS
qos Show qos logs of ACLQOS
qos-detail Show detailed qos logs of ACLQOS
span Show span logs of ACLQOS
span-detail Show detailed span logs of ACLQOS
trace Show trace logs of ACLQOS
trace-detail Show detailed trace logs of ACLQOS
zoning-rules Show detailed logs of ACLQOS
Aqui estão algumas dicas úteis para a solução de problemas:
Fault F1203 - Rule failed due to hardware programming error.Uma regra pode ter mais de uma entrada de TCAM no Circuito integrado específico da aplicação (ASIC). Para visualizar o número de entradas no ASIC, insira estes comandos:
fab1-leaf1# vsh_lc
module-1# show platform internal ns table-health
VLAN STATE curr usage: 0 - size: 4096
QQ curr usage: 0 - size: 16384
SEG STATE curr usage: 0 - size: 4096
SRC TEP curr usage: 0 - size: 4096
POLICY KEY curr usage: 0 - size: 1
SRC VP curr usage: 0 - size: 4096
SEC GRP curr usage: 43 - size: 4096
Observação: neste exemplo, há 43 entradas presentes. Esse uso também é relatado ao APIC na classe eqptCapacity.
show system internal aclqos zoning-ruleAo Troubleshoot, você pode observar a queda causada pela regra any-any-implicit. Essa regra está sempre na parte inferior, o que significa que o pacote é descartado porque não existe uma regra. Isso ocorre devido a um erro de configuração ou o Policy Element Manager não o programa conforme esperado.
Frequentemente, em um caso de solução de problemas, um engenheiro está examinando as regras de zoneamento. Em alguns casos, um EPG/pcTag tem muitos contratos e pode ser incômodo solucionar problemas. Esta seção descreve uma forma de determinar o nome do contrato que está sendo usado entre os EPGs/pcTags a partir do ID de regra visto na CLI do switch.
Para começar:
1. Consulte o objeto concreto de contrato/regra actrlRule, se desejar, restrinja a pesquisa por propriedade: id valor: rule-d
2. Quando a regra correta for encontrada, clique na seta verde no DN para exibir os objetos filho de actrlRule. As crianças é onde está a nossa resposta.
O objeto filho aqui é actrlRsToEpgConn. Normalmente pode haver dois, um para cada EPG. O DN deste objeto mostra os dois EPGs entre os quais o contrato é aplicado, bem como a direção (provedor ou consumidor) e, mais importante, o nome do objeto do contrato.
Como destacado, o nome do contrato nesse caso é brc-dpita-ssh.
Se necessário, consulte o vzBrCP para encontrar o contrato certo.
Revisão | Data de publicação | Comentários |
---|---|---|
3.0 |
03-Sep-2024 |
Atualizar lista de colaboradores. Formatação. |
2.0 |
03-Aug-2023 |
Texto Alt adicionado.
Tradução automática atualizada, requisitos de estilo, ortografia, gramática e formatação. |
1.0 |
29-Jun-2015 |
Versão inicial |