Contents

Introdução

Topologia

Resumo do processo

Identificar a regra de contrato/zoneamento usada

Verificar a programação do hardware

Solucionar problemas de programação de hardware

Comandos úteis para solução de problemas

Dicas para Troubleshooting

Derivar Nome do Contrato da ID da Regra

Introdução

Este documento descreve como verificar se os contratos estão configurados e se comportam corretamente na estrutura da Application Centric Infrastructure (ACI).

Topologia

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:

Resumo do processo

Esta é a interação e o fluxo da política para contratos e regras:

1. O Policy Manager no Application Policy Infrastructure Controller (APIC) se comunica com o Policy Element Manager no switch.

2. O Policy Element Manager no switch programa o Object Store no switch.

3. O Policy Manager no switch se comunica com o cliente de Qualidade de Serviço (ACLQOS) da Lista de Controle de Acesso no switch.

4. O cliente ACLQOS programa o hardware.

Identificar a regra de contrato/zoneamento usada

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

Verificar a programação do hardware

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.

Solucionar problemas de programação de hardware

Esta seção fornece alguns comandos e dicas úteis para a solução de problemas.

Comandos úteis para 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

Dicas para Troubleshooting

Aqui estão algumas dicas úteis para a solução de problemas:

- Se você tiver problemas de esgotamento de TCAM, verifique se há falhas na interface do usuário ou na CLI associadas à regra em questão. Esta falha pode ser relatada:

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.

- Quando há várias correspondências, a pesquisa de TCAM retorna o índice de hw mais baixo. Para verificar o índice, insira este comando:

show system internal aclqos zoning-rule
Ao 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.

- As pcTags podem ter um escopo local ou global:

PcTag Reservado do Sistema - Este pcTag é usado para regras internas do sistema (1-15).

PcTag de escopo global - Este pcTag é usado para serviço compartilhado (16-16385).

PcTag com escopo local - Este pcTag é usado localmente por VRF (intervalo de 16386 a 65535).

Ao solucionar problemas, uma visão rápida do comprimento do valor indica seu escopo.

Derivar Nome do Contrato da ID da Regra

Muitas vezes, quando se trata de um caso de solução de problemas, um engenheiro examina as regras de zoneamento. Em alguns casos, um EPG/pcTag tem muitos contratos e pode ser incômodo solucionar problemas. Esta seção aborda 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, consulte o objeto concreto de contrato/regra actrlRule, se desejar, restrinja a pesquisa por propriedade: id valor: rule-d

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.