Contenido

Introducción

Antecedentes

Descripción general de políticas Pod

Políticas Pod

Política de fecha y hora

Troubleshooting de Flujo

política BGP Route Reflector

Troubleshooting de Flujo

SNMP (Protocolo de administración de red simple)

Troubleshooting de Flujo

Introducción

Este documento describe los pasos para comprender y resolver problemas de las políticas de POD de ACI.

Antecedentes

El material de este documento se ha extraído de la Solución de problemas de Cisco Application Centric Infrastructure, segunda edición , concretamente los servicios de gestión y principales, Políticas de POD: BGP RR/ Date&Time / SNMP capítulo.

Descripción general de políticas Pod

Los servicios de administración como RR BGP, Fecha y hora y SNMP se aplican en el sistema mediante un grupo de políticas de grupo de dispositivos. Un grupo de políticas de grupo controla un grupo de políticas de grupo relacionadas con las funciones esenciales de un fabric de ACI. Estas políticas de grupo de dispositivos están relacionadas con los siguientes componentes, muchos de los cuales se aprovisionan de forma predeterminada en un fabric de ACI.

Políticas Pod

Política Pod

Requiere configuración manual

Fecha y hora

Yes

Reflector de ruta BGP

Yes

SNMP (protocolo de administración de redes de servidores)

Yes

ISIS

No

COOP

No

Acceso de administración

No

MAC Sec

Yes

Incluso en un único fabric ACI, es necesario configurar el grupo de políticas y el perfil de grupo de dispositivos. Esto no es específico de un Multi-Pod o incluso de una implementación Multi-Site. Este requisito se aplica a todos los tipos de implementación de ACI.

Este capítulo se centra en estas políticas de POD esenciales y en cómo comprobar que se aplican correctamente.

Política de fecha y hora

La sincronización horaria desempeña un papel fundamental en el fabric de ACI. Desde la validación de certificados hasta el mantenimiento uniforme de las marcas de tiempo de registro en APIC y switches, se recomienda sincronizar los nodos del fabric de ACI con una o varias fuentes de tiempo fiables mediante NTP.

Para que los nodos estén sincronizados correctamente con un proveedor de servidor NTP, existe una dependencia para asignar nodos con direcciones de administración. Esto se puede realizar en el arrendatario de administración mediante Direcciones de administración de nodos estáticos o Grupos de conectividad de nodos de administración.

Troubleshooting de Flujo

1. Compruebe si las direcciones de administración de nodos están asignadas a todos los nodos

Arrendatario de administración: direcciones de administración de nodos

2. Compruebe si un servidor NTP se ha configurado como proveedor NTP

Si hay varios proveedores de NTP, marque al menos uno de ellos como la fuente de tiempo preferida usando la casilla de verificación 'Preferido' según la figura a continuación.

Proveedor/servidor NTP bajo Política de Pod de Fecha y Hora

3. Compruebe el formato de fecha y hora en Configuración del sistema

La siguiente figura muestra un ejemplo en el que el formato de fecha y hora se ha establecido en UTC.

Configuración de fecha y hora en Configuración del sistema

4. Verifique el estado de sincronización operacional del proveedor NTP para todos los nodos

Como se muestra en la siguiente figura, la columna Estado de sincronización debe mostrar 'Sincronizado con servidor NTP remoto'. Tenga en cuenta que el estado de sincronización puede tardar varios minutos en converger correctamente con el servidor NTP .Synced remoto. estado.

Estado de sincronización del proveedor/servidor NTP

Alternativamente, los métodos CLI se pueden utilizar en los APIC y los switches para verificar la sincronización horaria correcta contra el servidor NTP.

APIC: NX-OS CLI

La columna 'refId' que aparece a continuación muestra el origen de la próxima vez de los servidores NTP en función del estrato.

apic1# show ntpq

nodeid     remote                          refid                       st        t   when      poll      reach     auth  delay     offset    jitter

------  -  ------------------------------  --------------------------  --------  --  --------  --------  --------  ----  --------  --------  --------

1       *  10.48.37.151                    192.168.1.115               2         u   25        64        377       none  0.214     -0.118    0.025

2       *  10.48.37.151                    192.168.1.115               2         u   62        64        377       none  0.207     -0.085    0.043

3       *  10.48.37.151                    192.168.1.115               2         u   43        64        377       none  0.109     -0.072    0.030

apic1# show clock

Time : 17:38:05.814 UTC Wed Oct 02 2019

APIC - Bash

apic1# bash

admin@apic1:~> date

Wed Oct  2 17:38:45 UTC 2019

Switch

Utilice el comando 'show ntp peers' para asegurarse de que la configuración del proveedor NTP se ha enviado correctamente al switch.

leaf1# show ntp peers

-----------------------------------------------------------------------------

Peer IP Address                         Serv/Peer Prefer KeyId   Vrf

-----------------------------------------------------------------------------

10.48.37.151                            Server    yes    None    management

leaf1# show ntp peer-status

Total peers : 1

* - selected for sync, + - peer mode(active),

- - peer mode(passive), = - polled in client mode

remote                               local           st poll reach delay vrf

--------------------------------------------------------------------------------

*10.48.37.151                            0.0.0.0         2  64   377   0.000  management

El carácter '*' es esencial aquí, ya que controla si el servidor NTP se está utilizando realmente para la sincronización.

Verifique el número de paquetes enviados/recibidos en el siguiente comando para asegurarse de que los nodos ACI tengan disponibilidad para el servidor NTP.

leaf1# show ntp statistics peer ipaddr 10.48.37.151

...

packets sent:         256

packets received:     256

...

política BGP Route Reflector

Un fabric ACI utiliza BGP multiprotocolo (MP-BGP) y, más concretamente, VPNv4 iBGP entre nodos de columna y de hojas para intercambiar rutas de arrendatario recibidas de routers externos (conectados en L3Outs). Para evitar una topología de peer iBGP de malla completa, los nodos de columna reflejan los prefijos VPNv4 recibidos de una hoja a otros nodos de hoja del fabric.

Sin la política BGP Route Reflector (BGP RR), no se creará ninguna instancia de BGP en los switches y no se establecerán las sesiones BGP VPNv4. En una implementación de varios dispositivos, cada dispositivo requiere al menos un conmutador central configurado como RR BGP y, básicamente, más de uno para redundancia.

Como resultado, la política BGP RR es una pieza esencial de configuración en cada fabric ACI. La política BGP RR también contiene el ASN que el fabric ACI utiliza para el proceso BGP en cada switch.

Troubleshooting de Flujo

1. Verifique si la política BGP RR tiene un ASN y al menos una columna configurada

El siguiente ejemplo hace referencia a una implementación de POD única.

Política de Reflector de Rutas BGP en Configuración del Sistema

2. Verifique si la política BGP RR se aplica bajo el grupo de políticas Pod

Aplique una política BGP RR predeterminada en el grupo de políticas Pod. Incluso si la entrada está en blanco, la política BGP RR predeterminada se aplicará como parte del grupo de políticas Pod.

Política de Reflector de Rutas BGP aplicada en el Grupo de Políticas de Pod

3. Compruebe si el grupo de políticas de grupo se aplica en el perfil de grupo

Grupo de políticas de grupo de dispositivos aplicado en el perfil de grupo de dispositivos

4. Inicie sesión en una columna y verifique si el proceso BGP se está ejecutando con sesiones de peer VPN4 establecidas

spine1# show bgp process vrf overlay-1

BGP Process Information

BGP Process ID                 : 26660

BGP Protocol Started, reason:  : configuration

BGP Protocol Tag               : 65001

BGP Protocol State             : Running

BGP Memory State               : OK

BGP asformat                   : asplain

Fabric SOO                     : SOO:65001:33554415

Multisite SOO                  : SOO:65001:16777199

Pod SOO                        : SOO:1:1

...

Information for address family VPNv4 Unicast in VRF overlay-1

Table Id                   : 4

Table state                : UP

Table refcount             : 9

Peers      Active-peers    Routes     Paths      Networks   Aggregates

7          6               0          0          0          0

Redistribution

None

Wait for IGP convergence is not configured

Additional Paths Selection route-map interleak_rtmap_golf_rtmap_path_advertise_all

Is a Route-reflector

Nexthop trigger-delay

critical 500 ms

non-critical 5000 ms

Information for address family VPNv6 Unicast in VRF overlay-1

Table Id                   : 80000004

Table state                : UP

Table refcount             : 9

Peers      Active-peers    Routes     Paths      Networks   Aggregates

7          6               0          0          0          0

Redistribution

None

Wait for IGP convergence is not configured

Additional Paths Selection route-map interleak_rtmap_golf_rtmap_path_advertise_all

Is a Route-reflector

Nexthop trigger-delay

critical 500 ms

non-critical 5000 ms

...

Wait for IGP convergence is not configured

Is a Route-reflector

Nexthop trigger-delay

critical 500 ms

non-critical 5000 ms

Como se muestra anteriormente, MP-BGP entre los nodos de columna y de hoja transporta únicamente familias de direcciones VPNv4 y VPNv6. La familia de direcciones IPv4 se utiliza en MP-BGP sólo en los nodos de hoja.

Las sesiones BGP VPNv4 y VPNv6 entre los nodos de columna y hoja también se pueden observar fácilmente mediante el siguiente comando.

spine1# show bgp vpnv4 unicast summary vrf overlay-1

BGP summary information for VRF overlay-1, address family VPNv4 Unicast

BGP router identifier 10.0.136.65, local AS number 65001

BGP table version is 15, VPNv4 Unicast config peers 7, capable peers 6

0 network entries and 0 paths using 0 bytes of memory

BGP attribute entries [0/0], BGP AS path entries [0/0]

BGP community entries [0/0], BGP clusterlist entries [0/0]

Neighbor        V      AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd

10.0.136.64     4   65001     162     156       15    0    0 02:26:00 0

10.0.136.67     4   65001     154     154       15    0    0 02:26:01 0

10.0.136.68     4   65001     152     154       15    0    0 02:26:00 0

10.0.136.69     4   65001     154     154       15    0    0 02:26:01 0

10.0.136.70     4   65001     154     154       15    0    0 02:26:00 0

10.0.136.71     4   65001     154     154       15    0    0 02:26:01 0

spine1# show bgp vpnv6 unicast summary vrf overlay-1

BGP summary information for VRF overlay-1, address family VPNv6 Unicast

BGP router identifier 10.0.136.65, local AS number 65001

BGP table version is 15, VPNv6 Unicast config peers 7, capable peers 6

0 network entries and 0 paths using 0 bytes of memory

BGP attribute entries [0/0], BGP AS path entries [0/0]

BGP community entries [0/0], BGP clusterlist entries [0/0]

Neighbor        V      AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd

10.0.136.64     4   65001     162     156       15    0    0 02:26:11 0

10.0.136.67     4   65001     155     155       15    0    0 02:26:12 0

10.0.136.68     4   65001     153     155       15    0    0 02:26:11 0

10.0.136.69     4   65001     155     155       15    0    0 02:26:12 0

10.0.136.70     4   65001     155     155       15    0    0 02:26:11 0

10.0.136.71     4   65001     155     155       15    0    0 02:26:12 0

Observe la columna 'Arriba/Abajo' de la salida anterior. Debería enumerar un tiempo de duración que denota el tiempo que se ha establecido la sesión BGP. Tenga en cuenta también que en el ejemplo la columna 'PfxRcd' muestra 0 para cada par VPNv4/VPNv6 BGP, ya que este fabric ACI aún no tiene L3Outs configurados y, por lo tanto, ninguna ruta/prefijo externo es un intercambio entre nodos de columna y de hoja.

5. Inicie sesión en una hoja y verifique si el proceso BGP se está ejecutando con sesiones de peer VPN4 establecidas

leaf1# show bgp process vrf overlay-1

BGP Process Information

BGP Process ID                 : 43242

BGP Protocol Started, reason:  : configuration

BGP Protocol Tag               : 65001

BGP Protocol State             : Running

...

leaf1#  show bgp vpnv4 unicast summary vrf overlay-1

BGP summary information for VRF overlay-1, address family VPNv4 Unicast

BGP router identifier 10.0.136.64, local AS number 65001

BGP table version is 7, VPNv4 Unicast config peers 2, capable peers 2

0 network entries and 0 paths using 0 bytes of memory

BGP attribute entries [0/0], BGP AS path entries [0/0]

BGP community entries [0/0], BGP clusterlist entries [0/0]

Neighbor        V      AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd

10.0.136.65     4   65001     165     171        7    0    0 02:35:52 0

10.0.136.66     4   65001     167     171        7    0    0 02:35:53 0

Los resultados del comando anterior muestran una cantidad de sesiones VPNv4 BGP igual al número de nodos de columna presentes en el fabric ACI. Esto difiere de los nodos de columna porque establecen sesiones para cada hoja y los otros nodos de columna reflectores de ruta.

SNMP (Protocolo de administración de red simple)

Es importante aclarar desde el principio qué subconjunto específico de funciones SNMP cubre esta sección. Las funciones SNMP de un fabric ACI están relacionadas con la función SNMP Walk o la función SNMP Trap. La distinción importante aquí es que SNMP Walk controla los flujos de tráfico ingress SNMP en el puerto UDP 161 mientras que SNMP Trap controla los flujos de tráfico outgoing SNMP con un servidor SNMP Trap que escucha en el puerto UDP 162.

El tráfico de gestión de entrada en los nodos de ACI requiere que los EPG de gestión de nodos (en banda o fuera de banda) proporcionen los contratos necesarios para permitir el flujo del tráfico. Esto también se aplica a los flujos de tráfico SNMP de entrada.

En esta sección se tratan los flujos de tráfico SNMP de entrada (SNMP Walks) en los nodos ACI (APIC y switches). No cubrirá los flujos de tráfico SNMP de salida (trampas SNMP), ya que esto ampliaría el alcance de esta sección en Políticas de supervisión y dependencias de políticas de supervisión (es decir, alcance de la política de supervisión, paquetes de supervisión, etc.).

Esta sección tampoco cubre qué MIB de SNMP admite ACI. Esta información está disponible en el sitio web de Cisco CCO en el siguiente enlace: https://www.cisco.com/c/dam/en/us/td/docs/switches/datacenter/aci/apic/sw/1-x/mib/list/mib-support.html

Troubleshooting de Flujo

1. Directiva de grupo SNMP: verifique si se ha configurado una directiva de grupo de clientes

Asegúrese de que al menos un cliente SNMP esté configurado como parte de la política de grupo de clientes, como se muestra en las capturas de pantalla siguientes.

Políticas de grupo de clientes — Política SNMP — Políticas de grupo de clientes

Políticas de grupo de clientes — Política SNMP — Políticas de grupo de clientes

2. Política de Pod SNMP: verifique si al menos una política de comunidad está configurada

Políticas de grupo de dispositivos — Política SNMP — Políticas comunitarias

3. Política de Pod SNMP: verifique si el estado del administrador está configurado en 'Habilitado'

4. Arrendatario de administración: verifique si el EPG OOB proporciona un contrato OOB que permite el puerto UDP 161

El EPG OOB controla la conectividad en el APIC y los puertos de gestión OOB del switch. Como tal, afecta a todos los flujos de tráfico que ingresan a los puertos OOB.

Asegúrese de que el contrato que se proporciona aquí incluye todos los servicios de gestión necesarios en lugar de solo SNMP. Por ejemplo: también debe incluir al menos SSH (puerto TCP 22). Sin esto no es posible iniciar sesión en los switches usando SSH. Tenga en cuenta que esto no se aplica a los APIC, ya que disponen de un mecanismo que permite SSH, HTTP y HTTPS para evitar que los usuarios se bloqueen completamente.

5. Arrendatario de administración: verifique si el Contrato OOB está presente y tiene un filtro que permite el puerto UDP 161

Arrendatario de gestión — EPG OOB — Contrato OOB proporcionado

En la siguiente figura, no es obligatorio permitir solamente el puerto UDP 161. Un contrato que tiene un filtro que permite el puerto UDP 161 de cualquier manera es correcto. Puede ser incluso un asunto de contrato con el filtro predeterminado del arrendatario común. En nuestro ejemplo, por motivos de claridad, se configuró un filtro específico sólo para el puerto UDP 161.

6. Arrendatario de gestión: verifique si hay un perfil de instancia de red de gestión externa con una subred válida que consume el contrato OOB.

El perfil de instancia de red de administración externa (ExtMgmtNetInstP) representa los orígenes externos definidos por las "subredes" que se encuentran en el sitio y que necesitan consumir servicios accesibles a través de la EPG OOB. Por lo tanto, ExtMgmtNetInstP utiliza el mismo contrato OOB que proporciona el EPG OOB. Este es el contrato que permite el puerto UDP 161. Además, ExtMgmtNetInstP también especifica los rangos de subred permitidos que pueden consumir los servicios proporcionados por el EPG OOB.

Arrendatario de administración: ExtMgmtNetInstP con contrato OOB y subred consumidos

Como se muestra en la figura anterior, se requiere una notación de subred basada en CIDR. La figura muestra una subred /24 específica. El requisito es que las entradas de subred cubran las entradas de cliente SNMP configuradas en la directiva de grupo SNMP (consulte la figura Directivas de grupo — Directiva SNMP — Directivas de grupo de clientes).

Como se ha mencionado anteriormente, tenga cuidado de incluir todas las subredes externas necesarias para evitar que se bloqueen otros servicios de gestión necesarios.

7. Inicie sesión en un switch y realice un tcpdump para observar si se observan los paquetes SNMP Walk, el puerto UDP 161

Si los paquetes SNMP Walk ingresan a un switch a través del puerto OOB, esto significa que todas las políticas/parámetros necesarios basados en SNMP y OOB se han configurado correctamente. Por lo tanto, es un método de verificación adecuado.

Tcpdump en los nodos de hoja aprovecha su shell Linux y los netdevices Linux. Por lo tanto, es necesario capturar los paquetes en la interfaz 'eth0' según el siguiente ejemplo. En el ejemplo, un cliente SNMP está realizando una solicitud Get SNMP contra OID .1.0.8802.1.1.2.1.1.1.0.

leaf1# ip addr show eth0

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000

link/ether f4:cf:e2:28:fc:ac brd ff:ff:ff:ff:ff:ff

inet 10.48.22.77/24 brd 10.48.22.255 scope global eth0

valid_lft forever preferred_lft forever

inet6 fe80::f6cf:e2ff:fe28:fcac/64 scope link

valid_lft forever preferred_lft forever

leaf1# tcpdump -i eth0 udp port 161

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes

22:18:10.204011 IP 10.155.0.153.63392 > 10.48.22.77.snmp:  C=my-snmp-community GetNextRequest(28)  .iso.0.8802.1.1.2.1.1.1.0

22:18:10.204558 IP 10.48.22.77.snmp > 10.155.0.153.63392:  C=my-snmp-community GetResponse(29)  .iso.0.8802.1.1.2.1.1.2.0=4