Solução de problemas de gerenciamento da ACI e serviços principais - gerenciamento dentro e fora da banda
Solução de problemas de gerenciamento da ACI e serviços principais - gerenciamento dentro e fora da banda
Contents
Introduction Informações de Apoio
Gerenciamento dentro e fora da banda Preferências de conectividade do APIC
Cenário: Não é possível acessar a rede de gerenciamento Acesso de gerenciamento fora da banda
Verificação de configuração fora da banda
Verificação da GUI de endereços de gerenciamento de nó estático EPG fora da banda - padrão
Contrato fora da banda
Perfil de Instância de Rede de Gerenciamento Externo Configuração de gerenciamento em banda
Sub-rede de domínio de bridge que atuará como gateway de gerenciamento em banda Falha F0467 - inb EPG
EPG na banda
Perfil de instância de EPG externo Endereços de Gerenciamento de Nó Estático
Introduction
Este documento descreve as etapas para solucionar problemas de gerenciamento ACI fora da banda (OOB) e dentro da banda (INB).
Informações de Apoio
O material deste documento foi extraído do livro Troubleshooting Cisco Application Centric Infrastructure, Second Edition especificamente do capítulo Management and Core Services - In- band and out-of-band Management.
Gerenciamento dentro e fora da banda
Os nós de estrutura da ACI têm duas opções de conectividade de gerenciamento; out-of-band (OOB), que controla a porta de gerenciamento físico dedicada na parte traseira do dispositivo, ou in-band (INB), que é provisionada usando um EPG/BD/VRF específico no espaço de gerenciamento com um grau de parâmetros configuráveis. Há um EPG OOB presente no espaço de gerenciamento ('mgmt'), mas ele está lá por padrão e não pode ser modificado. Permite apenas a configuração de contratos OOB fornecidos. No APIC, a interface OOB é observada na
saída do comando 'ifconfig' como 'oobmgmt' e a interface in-band será representada pela interface 'bond.x', onde é a VLAN encap configurada para o EPG in-band.
apic1# ifconfig oobmgmt
oobmgmt: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.4.20 netmask 255.255.255.0 broadcast 192.168.4.255 inet6 fe80::7269:5aff:feca:2986 prefixlen 64 scopeid 0x20
ether 70:69:5a:ca:29:86 txqueuelen 1000 (Ethernet) RX packets 495815 bytes 852703636 (813.2 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 432927 bytes 110333594 (105.2 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
apic1# ifconfig bond0.300
bond0.300: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1496
inet 10.30.30.254 netmask 255.255.255.0 broadcast 10.30.30.255 inet6 fe80::25d:73ff:fec1:8d9e prefixlen 64 scopeid 0x20
ether 00:5d:73:c1:8d:9e txqueuelen 1000 (Ethernet) RX packets 000 xxxxx 00000 (24.7 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 6996 bytes 535314 (522.7 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Na folha, a interface OOB é vista como 'eth0' na saída do comando 'ifconfig' e o INB é visto como uma SVI dedicada. O usuário pode visualizar a interface com 'ifconfig' ou com 'show ip interface vrf mgmt:' onde é o nome selecionado para o VRF em banda.
leaf101# show interface mgmt 0
mgmt0 is up
admin state is up,
Hardware: GigabitEthernet, address: 00fc.baa8.2760 (bia 00fc.baa8.2760) Internet Address is 000.000.0.00/00
MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec reliability 255/255, txload 1/255, rxload 1/255 Encapsulation ARPA, medium is broadcast
Port mode is routed full-duplex, 1000 Mb/s Beacon is turned off
Auto-Negotiation is turned on
Input flow-control is off, output flow-control is off Auto-mdix is turned off
EtherType is 0x0000
30 seconds input rate 3664 bits/sec, 4 packets/sec
30 seconds output rate 4192 bits/sec, 4 packets/sec Rx
14114 input packets 8580 unicast packets 5058 multicast packets
476 broadcast packets 2494768 bytes
Tx
9701 output packets 9686 unicast packets 8 multicast packets
7 broadcast packets 1648081 bytes
leaf101# show ip interface vrf mgmt:inb
IP Interface Status for VRF "mgmt:inb-vrf"
vlan16, Interface status: protocol-up/link-up/admin-up, iod: 4, mode: pervasive IP address: 10.30.30.1, IP subnet: 00.00.00.0/00
secondary IP address: 10.30.30.3, IP subnet: 00.00.00.0/00 IP broadcast address: 255.255.255.255
IP primary address route-preference: 0, tag: 0
O 'show ip interface vrf mgmt:' mostrará o IP de sub-rede BD de gerenciamento em banda como o endereço IP secundário; esta é a saída esperada.
Em switches spine, o endereço IP de gerenciamento em banda é adicionado como uma interface de loopback dedicada no VRF 'mgmt:'. Essa implementação é, portanto, diferente da implementação IP de gerenciamento em banda em switches leaf. Observe a saída do comando 'show ip int vrf mgmt:' abaixo em um switch spine
spine201# show ip interface vrf mgmt:inb
IP Interface Status for VRF "mgmt:inb"
lo10, Interface status: protocol-up/link-up/admin-up, iod: 98, mode: pervasive IP address: 10.30.30.12, IP subnet: 00.00.00.00/00
IP broadcast address: 255.255.255.255
IP primary address route-preference: 0, tag: 0
Em Configurações do sistema, há uma configuração para selecionar a preferência de conectividade in-band ou out-of-band para os APICs.
Somente o tráfego enviado do APIC usará a preferência de gerenciamento selecionada em "Preferências de conectividade do APIC". O APIC ainda pode receber tráfego na banda ou fora da banda, supondo que qualquer um esteja configurado. O APIC usa a seguinte lógica de encaminhamento:
● Pacotes que entram em uma interface e saem pela mesma interface.
● Os pacotes originados no APIC, destinados a uma rede diretamente conectada, saem da interface diretamente conectada.
● Os pacotes originados no APIC, destinados a uma rede remota, preferem in-band ou out-of- band com base nas Preferências de conectividade do APIC.
Preferências de conectividade do APIC
Tabela de roteamento APIC com OOB selecionado. Observe o valor métrico de 16 para a interface oobmgmt que é inferior à métrica da interface de gerenciamento in-band bond0.300 de
32. Significando que a interface de gerenciamento out-of-band oobmgmt será usada para o tráfego de gerenciamento de saída.
apic1# bash admin@apic1:~> route -n Kernel IP routing table
Destination | Gateway | Genmask | Flags | Metric | Ref | Use | Iface |
0.0.0.0 | 192.168.4.1 | 0.0.0.0 | UG | 16 | 0 | 0 | oobmgmt |
0.0.0.0 | 10.30.30.1 | 0.0.0.0 | UG | 32 | 0 | 0 | bond0.300 |
Tabela de roteamento APIC com in-band selecionado. Observe a métrica da interface de gerenciamento in-band bond0.300 se 8, que agora é menor que a métrica da interface oobmgmt de 16. Significando que a interface de gerenciamento in-band bond0.300 será usada para o tráfego de gerenciamento de saída.
admin@apic1:~> route -n
Kernel IP routing table
Destination | Gateway | Genmask | Flags | Metric | Ref | Use | Iface |
0.0.0.0 | 10.30.30.1 | 0.0.0.0 | UG | 8 | 0 | 0 | bond0.300 |
0.0.0.0 | 192.168.4.1 | 0.0.0.0 | UG | 16 | 0 | 0 | oobmgmt |
As preferências de gerenciamento do nó de folha e coluna não são afetadas por essa configuração. Essas preferências de conectividade são selecionadas nas políticas de protocolo. Veja abaixo um exemplo de NTP.
Se in-band (em banda) for selecionado em APIC Connectivity Preferences (Preferências de conectividade do APIC), mas out-of-band (fora de banda) for selecionado no protocolo, qual interface com o pacote de protocolo será usada?
● A preferência de conectividade do APIC sempre terá precedência sobre a seleção de protocolo no APIC.
● Os nós folha são o oposto, eles só fazem referência à seleção sob o protocolo.
Cenário: Não é possível acessar a rede de gerenciamento
Se o usuário não puder acessar a rede de gerenciamento, isso pode ser devido a vários problemas diferentes, mas ele sempre pode usar a mesma metodologia para isolar o problema. A suposição neste cenário é que o usuário não pode acessar nenhum dispositivo na rede de gerenciamento por trás de sua L3Out.
● Verifique a preferência de conectividade do APIC. Isso é descrito na figura "Preferências de conectividade do APIC" e as opções são OOB ou in-band.
● Dependendo da preferência selecionada, verifique se a configuração está correta, se as interfaces estão ativas, se o gateway padrão pode ser acessado por meio da interface selecionada e se não há descartes no caminho do pacote.
Não se esqueça de verificar se há falhas em cada seção da configuração na GUI. No entanto, alguns erros de configuração podem se manifestar em estados inesperados, mas uma falha pode ser gerada em outra seção diferente daquela que o usuário consideraria inicialmente.
Acesso de gerenciamento fora da banda
Verificação de configuração fora da banda
Para a configuração fora de banda, há quatro pastas a serem verificadas em um espaço especial chamado 'mgmt':
● Endereços de Gerenciamento de Nó.
● EPGs de gerenciamento de nó.
● Contratos fora da banda (sob Contratos).
● Perfis de instância de rede externa.
Os endereços de gerenciamento de nó podem ser atribuídos estaticamente ou de um pool. Abaixo está um exemplo de atribuição de endereço estático. Verifique se o tipo de endereço IP fora de banda está atribuído e se o gateway padrão está correto.
Verificação da GUI de endereços de gerenciamento de nó estático
O EPG fora da banda deve estar presente na pasta Node Management EPGs.
EPG fora da banda - padrão
Os contratos que regem quais serviços de gerenciamento são fornecidos a partir do EPG fora da banda são contratos especiais configurados na pasta de contratos fora da banda.
Contrato fora da banda
Em seguida, verifique se o External Management Network Instance Profile foi criado e se o contrato out-of-band correto está configurado como o 'Consumed Out-Of-Band Contract'.
Perfil de Instância de Rede de Gerenciamento Externo
Os próximos itens a serem verificados são o estado da interface e o cabeamento e, em seguida, a conectividade com o gateway.
● Para verificar se a interface oobmgmt está ativa, digite 'ifconfig oobmgmt' na CLI do APIC.
Verifique se os sinalizadores da interface estão 'UP' e 'RUNNING', se o endereço IP correto está configurado e se os pacotes estão aumentando nos contadores RX e TX. Se alguma verificação estiver faltando, verifique se os cabos corretos estão sendo usados e se estão conectados às portas de gerenciamento físico corretas no APIC. As portas de gerenciamento serão rotuladas como Eth1-1 e Eth1-2 e o hardware recente terá adesivos de gerenciamento para indicar a interface fora da banda. Para obter mais informações sobre as portas de gerenciamento fora de banda físicas na parte traseira de um APIC, consulte a seção "Configuração inicial da estrutura" no capítulo "Descoberta de estrutura".
apic1# ifconfig oobmgmt
oobmgmt: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.4.20 netmask 255.255.255.0 broadcast 192.168.4.255 inet6 fe80::7269:5aff:feca:2986 prefixlen 64 scopeid 0x20
ether 70:69:5a:ca:29:86 txqueuelen 1000 (Ethernet) RX packets 295605 bytes 766226440 (730.7 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 253310 bytes 38954978 (37.1 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
● Para verificar a conectividade de rede através do OOB, use o ping para testar o caminho do pacote através da rede fora de banda.
apic1# ping 192.168.4.1
PING 192.168.4.1 (192.168.4.1) 56(84) bytes of data.
64 bytes from 000.000.0.0: icmp_seq=1 ttl=255 time=0.409 ms
64 bytes from 000.000.0.0: icmp_seq=2 ttl=255 time=0.393 ms
64 bytes from 000.000.0.0: icmp_seq=3 ttl=255 time=0.354 ms
Usando traceroute no shell bash no APIC, rastreie a conectividade para o usuário final. Se o traceroute estiver incompleto, faça login neste dispositivo (se acessível), faça ping na interface oobmgmt e faça ping no host. Dependendo da direção que falhar, solucione o problema como um problema de rede tradicional.
O Traceroute funciona enviando pacotes UDP com um TTL crescente, começando com 1. Se um roteador recebe o pacote com TTL 1 e precisa roteá-lo, ele descarta o quadro e envia de volta uma mensagem ICMP inalcançável ao remetente. Cada salto é enviado com 3 pacotes UDP no TTL atual, e os asteriscos representam tentativas onde um pacote ICMP inalcançável/TTL excedido não foi recebido. Esses 3 blocos de asterisco são esperados na maioria das redes, já que alguns dispositivos de roteamento têm mensagens ICMP inalcançável/TTL excedido desativadas. Assim, quando recebem pacotes TTL 1 que precisam rotear, eles simplesmente descartam o pacote e não enviam a mensagem de volta ao remetente.
apic1# bash
admin@apic1:~> traceroute 10.55.0.16
traceroute to 10.55.0.16 (10.55.0.16), 30 hops max, 60 byte packets
1 192.168.4.1 (192.168.4.1) 0.368 ms 0.355 ms 0.396 ms
2 * * *
3 * * *
4 10.0.255.221 (10.0.255.221) 6.419 ms 10.0.255.225 (10.0.255.225) 6.447 ms *
5 * * *
6 * * *
7 10.55.0.16 (10.55.0.16) 8.652 ms 8.676 ms 8.694 ms
Os switches leaf têm acesso ao comando tcpdump, que pode ser usado para verificar quais pacotes estão atravessando a interface oobmgmt. O exemplo abaixo captura em 'eth0', que é a interface obmgmt usada nos switches leaf e spine, e usa a opção '-n' para tcpdump para fornecer os endereços IP usados em vez dos nomes DNS e, em seguida, filtrar especificamente para pacotes NTP (porta UDP 123). Lembre-se de que no exemplo anterior a folha está fazendo polling no servidor NTP 172.18.108.14. Abaixo, o usuário pode verificar se os pacotes NTP estão sendo transmitidos através da interface fora de banda e também se a folha está recebendo uma resposta do servidor.
fab1-leaf101# tcpdump -n -i eth0 dst port 123
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 16:49:01.431624 IP 192.168.4.23.123 > 172.18.108.14.123: NTPv4, Client, length 48
16:49:01.440303 IP 172.18.108.14.123 > 192.168.4.23.123: NTPv4, Server, length 48
A configuração de gerenciamento em banda requer considerações específicas para implantações de Camada 2 ou Camada 3. Este exemplo cobrirá apenas a implantação e a solução de problemas da Camada 3.
Configuração de gerenciamento em banda
Verifique se há um BD no espaço de gerenciamento com uma sub-rede a partir da qual os
endereços de gerenciamento de nó em banda serão alocados para os nós de estrutura para conectividade em banda e certifique-se de que o L3Out esteja associado no BD de gerenciamento em banda.
Sub-rede de domínio de bridge que atuará como gateway de gerenciamento em banda
Verifique se um EPG de gerenciamento de nó in-band está presente. Como na captura de tela abaixo, os nomes EPG in-band são indicados na GUI com o prefixo 'inb-'. Verifique se a VLAN de encapsulamento EPG in-band está associada corretamente a um pool de VLANs.
A VLAN de encapsulamento configurada no EPG de gerenciamento em banda precisa ser permitida pelas Políticas de acesso: 'inb mgmt EPG encap VLAN > VLAN Pool > Domain > AEP > Interface Policy Group > Leaf Interface Profile > Switch Profile'. Se as políticas de acesso de suporte não estiverem configuradas, uma falha com o código F0467 será gerada conforme a captura de tela abaixo.
Falha F0467 - inb EPG
Verifique se o domínio de bridge é o mesmo que o criado acima para a sub-rede in-band. Por fim, verifique se há um Contrato fornecido configurado no EPG de gerenciamento em banda, que é consumido pelo EPG externo.
EPG na banda
Perfil de instância de EPG externo
Semelhante aos endereços IP de gerenciamento em banda de nós de estrutura fora da banda, os endereços IP de gerenciamento em banda podem ser atribuídos estaticamente ou dinamicamente a partir de um intervalo pré-selecionado. Verifique se os endereços aplicados para o tipo na banda correspondem à sub-rede BD anterior que foi configurada. Verifique também se o gateway padrão está correto.
Endereços de Gerenciamento de Nó Estático
Se tudo tiver sido configurado corretamente e não houver falhas em nenhuma seção mencionada acima, a próxima etapa será fazer ping entre os switches e/ou APICs para verificar se a conectividade em banda está funcionando corretamente dentro da ACI.
Os nós spine não responderão ao ping na banda, pois usam interfaces de loopback para conectividade que não respondem ao ARP.
A interface in-band usada nos switches leaf é kpm_inb. Usando uma captura tcpdump semelhante, verifique se o pacote está saindo da interface da CPU na banda.
fab2-leaf101# tcpdump -n -i kpm_inb dst port 123
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on kpm_inb, link-type EN10MB (Ethernet), capture size 65535 bytes 16:46:50.431647 IP 10.30.30.3.123 > 172.18.108.14.123: NTPv4, Client, length 48
16:47:19.431650 IP 10.30.30.3.123 > 172.18.108.15.123: NTPv4, Client, length 48
Verifique se o SVI usado para a banda é 'protocol-up/link-up/admin-up'.
fab1-leaf101# show ip interface vrf mgmt:inb-vrf
IP Interface Status for VRF "mgmt:inb-vrf"
vlan16, Interface status: protocol-up/link-up/admin-up, iod: 4, mode: pervasive IP address: 10.30.30.1, IP subnet: 00.00.00.0/00 secondary
IP address: 10.30.30.3, IP subnet: 00.00.00.0/00 IP broadcast address: 255.255.255.255
IP primary address route-preference: 0, tag: 0