El conjunto de documentos para este producto aspira al uso de un lenguaje no discriminatorio. A los fines de esta documentación, "no discriminatorio" se refiere al lenguaje que no implica discriminación por motivos de edad, discapacidad, género, identidad de raza, identidad étnica, orientación sexual, nivel socioeconómico e interseccionalidad. Puede haber excepciones en la documentación debido al lenguaje que se encuentra ya en las interfaces de usuario del software del producto, el lenguaje utilizado en función de la documentación de la RFP o el lenguaje utilizado por un producto de terceros al que se hace referencia. Obtenga más información sobre cómo Cisco utiliza el lenguaje inclusivo.
Cisco ha traducido este documento combinando la traducción automática y los recursos humanos a fin de ofrecer a nuestros usuarios en todo el mundo contenido en su propio idioma. Tenga en cuenta que incluso la mejor traducción automática podría no ser tan precisa como la proporcionada por un traductor profesional. Cisco Systems, Inc. no asume ninguna responsabilidad por la precisión de estas traducciones y recomienda remitirse siempre al documento original escrito en inglés (insertar vínculo URL).
Este documento describe los pasos para comprender y resolver problemas de ACI Multi-pod Discovery.
El material de este documento se ha extraído de la Solución de problemas de Cisco Application Centric Infrastructure, segunda edición , en concreto el Fabric Discovery, Detección de varios grupos de dispositivos capítulo.
ACI Multi-Pod permite la implementación de un solo clúster APIC para gestionar varias redes ACI interconectadas. Estas redes ACI independientes se denominan "grupos de dispositivos" y cada grupo de dispositivos es una topología de columna y hoja de dos o tres niveles. Un solo clúster APIC puede administrar varios grupos de dispositivos.
Un diseño de varios grupos de dispositivos también permite la extensión de las políticas de fabric de ACI entre grupos de dispositivos que pueden existir físicamente en varias salas o incluso en ubicaciones de Data Centers remotos. En un diseño de varios dispositivos, cualquier política definida en el clúster de controladores APIC se pone automáticamente a disposición de todos los dispositivos.
Por último, un diseño de varios dispositivos aumenta el aislamiento de los dominios con fallos. De hecho, cada POD ejecuta su propia instancia de COOP, protocolo MP-BGP e IS-IS, por lo que los fallos y los problemas con cualquiera de estos protocolos se incluyen en ese POD y no se pueden extender a otros POD.
Consulte el documento "ACI Multi-Pod White Paper" en cisco.com para obtener más información sobre el diseño de varios dispositivos y las prácticas recomendadas.
Los elementos principales de un fabric de ACI multigrupo son los switches de columna y de hoja, los controladores APIC y los dispositivos IPN.
En este ejemplo se analiza el flujo de trabajo de solución de problemas relacionados con la configuración de un fabric de varios dispositivos de ACI. La topología de referencia utilizada para esta sección se muestra en la siguiente imagen:
Políticas de acceso
Multi-Pod utiliza un L3Out para conectar Pods a través del arrendatario 'infra'. Esto significa que el conjunto estándar de políticas de acceso debe estar en su lugar para activar la encapsulación L3Out de varios dispositivos (VLAN-4) necesaria en los puertos de columna orientados hacia el IPN.
Las políticas de acceso se pueden configurar a través del asistente "Agregar grupo de dispositivos", que se debe utilizar para implementar varios grupos de dispositivos. Después de utilizar el asistente, la política implementada se puede verificar desde la GUI de APIC. Si las políticas no están configuradas correctamente, aparecerá un fallo en el infra tenant y es posible que la conectividad desde las columnas al IPN no funcione como se esperaba.
Se puede hacer referencia a los siguientes esquemas al verificar la definición de la política de acceso para las interfaces de cara a IPN en los nodos de columna:
Columna201
Columna202
Columna401
Columna402
En el arrendatario infra, el L3Out del Multi-Pod debe configurarse según el siguiente esquema:
L3Out de varios paquetes en infra tenant
A continuación se muestra una captura de referencia de la configuración del perfil de interfaz lógica de salida L3 de varios dispositivos. Las definiciones de subinterfaz del router deben ser similares a las de la imagen siguiente para la columna 201
Perfil de interfaz lógica en infra L3Out
Para cada grupo de dispositivos, debe haber un grupo de TEP definido como se muestra en la siguiente imagen. Tenga en cuenta que el conjunto TEP se utilizará desde el controlador APIC para proporcionar las direcciones IP de los nodos para el VRF de superposición 1.
Política de configuración de Pod Fabric
Directiva de conexión externa de fabric predeterminada
Verifique que en el infra tenant el objeto 'Fabric Ext Policy default' esté definido y configurado apropiadamente. En las figuras siguientes se muestra un ejemplo de esta configuración.
Directiva de conexión externa de fabric predeterminada
TEP del plano de datos
Subredes de perfil de routing externo de fabric
El perfil de routing externo de fabric permite al usuario verificar si todas las subredes enrutadas del IPN definido se encuentran en él.
Los dispositivos multiPOD se basan en una red entre dispositivos (IPN) que proporcionará conectividad POD a POD. Es crucial verificar que la configuración para el IPN esté correctamente implementada. A menudo, la configuración defectuosa o faltante es el origen de un comportamiento inesperado o de la caída del tráfico en caso de escenarios de error. La configuración del IPN se describirá detalladamente en esta sección.
Para la siguiente sección, consulte la siguiente topología de IPN:
Conectividad de subinterfaces de columna a IPN dot1q VLAN-4
La conectividad punto a punto de la columna a la red IP se logra con subinterfaces en VLAN-4. La primera validación de esta conectividad es probar la disponibilidad de IP entre las columnas y los dispositivos de red IP.
Para ello, determine la interfaz correcta y verifique que se muestre como activa.
S1P1-Spine201# show ip int brief vrf overlay-1 | grep 172.16.101.2
eth1/29.29 172.16.101.2/30 protocol-up/link-up/admin-up
S1P1-Spine201# show ip interface eth1/29.29
IP Interface Status for VRF "overlay-1"
eth1/29.29, Interface status: protocol-up/link-up/admin-up, iod: 67, mode: external
IP address: 172.16.101.2, IP subnet: 172.16.101.0/30
IP broadcast address: 255.255.255.255
IP primary address route-preference: 0, tag: 0
S1P1-Spine201# show system internal ethpm info interface Eth1/29.29
Ethernet1/29.29 - if_index: 0x1A01C01D
Router MAC address: 00:22:bd:f8:19:ff
Admin Config Information:
state(up), mtu(9150), delay(1), vlan(4), cfg-status(valid)
medium(broadcast)
Operational (Runtime) Information:
state(up), mtu(9150), Local IOD(0x43), Global IOD(0x43), vrf(enabled)
reason(None)
bd_id(29)
Information from SDB Query (IM call)
admin state(up), runtime state(up), mtu(9150),
delay(1), bandwidth(40000000), vlan(4), layer(L3),
medium(broadcast)
sub-interface(0x1a01c01d) from parent port(0x1a01c000)/Vlan(4)
Operational Bits:
User config flags: 0x1
admin_router_mac(1)
Sub-interface FSM state(3)
No errors on sub-interface
Information from GLDB Query:
Router MAC address: 00:22:bd:f8:19:ff
Después de verificar que la interfaz está activa, ahora pruebe la conectividad IP punto a punto:
S1P1-Spine201# iping -V overlay-1 172.16.101.1
PING 172.16.101.1 (172.16.101.1) from 172.16.101.2: 56 data bytes
64 bytes from 172.16.101.1: icmp_seq=0 ttl=255 time=0.839 ms
64 bytes from 172.16.101.1: icmp_seq=1 ttl=255 time=0.719 ms
^C
--- 172.16.101.1 ping statistics ---
2 packets transmitted, 2 packets received, 0.00% packet loss
round-trip min/avg/max = 0.719/0.779/0.839 ms
Si hay algún problema de conectividad, verifique el cableado y la configuración en el IPN remoto (IPN1).
IPN1# show ip interface brief | grep 172.16.101.1
Eth1/33 172.16.101.101 protocol-up/link-up/admin-up
Eth1/35 172.16.101.105 protocol-up/link-up/admin-up
Eth1/53.4 172.16.101.1 protocol-up/link-up/admin-up
IPN1# show run int Eth1/53.4
interface Ethernet1/53.4
description to spine 1pod1
mtu 9150
encapsulation dot1q 4
ip address 172.16.101.1/30
ip ospf cost 100
ip ospf network point-to-point
ip router ospf 1 area 0.0.0.0
ip pim sparse-mode
ip dhcp relay address 10.0.0.3
no shutdown
configuración OSPF
OSPF se utiliza como protocolo de ruteo para conectar Pod1 y Pod2 dentro de ACI VRF 'overlay-1'. Se puede hacer referencia a lo siguiente como un flujo genérico para validar si OSPF está apareciendo entre la columna y el dispositivo IPN.
S1P1-Spine201# show ip ospf neighbors vrf overlay-1
OSPF Process ID default VRF overlay-1
Total number of neighbors: 2
Neighbor ID Pri State Up Time Address Interface
172.16.101.201 1 FULL/ - 08:39:35 172.16.101.1 Eth1/29.29
172.16.101.202 1 FULL/ - 08:39:34 172.16.101.9 Eth1/30.30
S1P1-Spine201# show ip ospf interface vrf overlay-1
Ethernet1/29.29 is up, line protocol is up
IP address 172.16.101.2/30, Process ID default VRF overlay-1, area backbone
Enabled by interface configuration
State P2P, Network type P2P, cost 1
Index 67, Transmit delay 1 sec
1 Neighbors, flooding to 1, adjacent with 1
Timer intervals: Hello 10, Dead 40, Wait 40, Retransmit 5
Hello timer due in 00:00:10
No authentication
Number of opaque link LSAs: 0, checksum sum 0
loopback0 is up, line protocol is up
IP address 10.0.200.66/32, Process ID default VRF overlay-1, area backbone
Enabled by interface configuration
State LOOPBACK, Network type LOOPBACK, cost 1
loopback14 is up, line protocol is up
IP address 172.16.1.4/32, Process ID default VRF overlay-1, area backbone
Enabled by interface configuration
State LOOPBACK, Network type LOOPBACK, cost 1
Ethernet1/30.30 is up, line protocol is up
IP address 172.16.101.10/30, Process ID default VRF overlay-1, area backbone
Enabled by interface configuration
State P2P, Network type P2P, cost 1
Index 68, Transmit delay 1 sec
1 Neighbors, flooding to 1, adjacent with 1
Timer intervals: Hello 10, Dead 40, Wait 40, Retransmit 5
Hello timer due in 00:00:09
No authentication
Number of opaque link LSAs: 0, checksum sum 0
IPN1# show ip ospf neighbors
OSPF Process ID 1 VRF default
Total number of neighbors: 5
Neighbor ID Pri State Up Time Address Interface
172.16.101.203 1 FULL/ - 4d12h 172.16.101.102 Eth1/33
172.16.101.202 1 FULL/ - 4d12h 172.16.101.106 Eth1/35
172.16.110.201 1 FULL/ - 4d12h 172.16.110.2 Eth1/48
172.16.1.4 1 FULL/ - 08:43:39 172.16.101.2 Eth1/53.4
172.16.1.6 1 FULL/ - 08:43:38 172.16.101.6 Eth1/54.4
Cuando OSPF está activo entre todas las columnas y dispositivos IPN, todos los agrupamientos Pod TEP se pueden ver dentro de las tablas de ruteo IPN.
IPN1# show ip ospf database 10.0.0.0 detail
OSPF Router with ID (172.16.101.201) (Process ID 1 VRF default)
Type-5 AS External Link States
LS age: 183
Options: 0x2 (No TOS-capability, No DC)
LS Type: Type-5 AS-External
Link State ID: 10.0.0.0 (Network address)
Advertising Router: 172.16.1.4
LS Seq Number: 0x80000026
Checksum: 0x2da0
Length: 36
Network Mask: /16
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 20
Forward Address: 0.0.0.0
External Route Tag: 0
LS age: 183
Options: 0x2 (No TOS-capability, No DC)
LS Type: Type-5 AS-External
Link State ID: 10.0.0.0 (Network address)
Advertising Router: 172.16.1.6
LS Seq Number: 0x80000026
Checksum: 0x21aa
Length: 36
Network Mask: /16
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 20
Forward Address: 0.0.0.0
External Route Tag: 0
IPN1# show ip ospf database 10.1.0.0 detail
OSPF Router with ID (172.16.101.201) (Process ID 1 VRF default)
Type-5 AS External Link States
LS age: 1779
Options: 0x2 (No TOS-capability, No DC)
LS Type: Type-5 AS-External
Link State ID: 10.1.0.0 (Network address)
Advertising Router: 172.16.2.4
LS Seq Number: 0x80000022
Checksum: 0x22ad
Length: 36
Network Mask: /16
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 20
Forward Address: 0.0.0.0
External Route Tag: 0
LS age: 1780
Options: 0x2 (No TOS-capability, No DC)
LS Type: Type-5 AS-External
Link State ID: 10.1.0.0 (Network address)
Advertising Router: 172.16.2.6
LS Seq Number: 0x80000022
Checksum: 0x16b7
Length: 36
Network Mask: /16
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 20
Forward Address: 0.0.0.0
External Route Tag: 0
IPN1# show ip route 10.0.0.0
IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>
10.0.0.0/16, ubest/mbest: 2/0
*via 172.16.101.2, Eth1/53.4, [110/20], 08:39:17, ospf-1, type-2
*via 172.16.101.6, Eth1/54.4, [110/20], 08:39:17, ospf-1, type-2
IPN1# show ip route 10.1.0.0
IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>
10.1.0.0/16, ubest/mbest: 1/0
*via 172.16.101.102, Eth1/33, [110/20], 08:35:25, ospf-1, type-2
Observe que en IPN1 para el Pod remoto (Pod2), solo se muestra la ruta más óptima en el comando 'show ip route'.
configuración de retransmisión DHCP
Los nodos del switch reciben su dirección TEP infra utilizando DHCP hacia los APIC. Normalmente, todos los APIC recibirán la detección, pero es el primer APIC que recibe la detección y presenta una oferta que asignará la dirección TEP. Para tener en cuenta esto en un escenario de varios grupos de dispositivos, configure el relé DHCP en el IPN para recibir estas detecciones y unidifusión hacia los APIC. Por lo general, configure todas las interfaces IPN de cara a la columna con ayudantes IP que apunten a todos los APIC. Esto asegurará la configuración de IPN en el futuro si APIC se mueve debido a un nuevo cableado, un APIC en espera falla o cualquier otro escenario que implique que un APIC se mueva a un nuevo Pod.
En esta situación, eso significa configurar IPN1 Eth1/53.4 y Eth1/54.4 con ayudantes IP que apuntan a todos los APIC:
interface Ethernet1/53.4
description to spine 1pod1
mtu 9150
encapsulation dot1q 4
ip address 172.16.101.1/30
ip ospf cost 100
ip ospf network point-to-point
ip router ospf 1 area 0.0.0.0
ip pim sparse-mode
ip dhcp relay address 10.0.0.1
ip dhcp relay address 10.0.0.2
ip dhcp relay address 10.0.0.3
no shutdown
interface Ethernet1/54.4
description to spine 2pod1
mtu 9150
encapsulation dot1q 4
ip address 172.16.101.5/30
ip ospf cost 100
ip ospf network point-to-point
ip router ospf 1 area 0.0.0.0
ip pim sparse-mode
ip dhcp relay address 10.0.0.1
ip dhcp relay address 10.0.0.2
ip dhcp relay address 10.0.0.3
no shutdown
Desde IPN3:
interface Ethernet1/53.4
description to spine 1pod2
mtu 9150
encapsulation dot1q 4
ip address 172.16.101.17/30
ip ospf cost 100
ip ospf network point-to-point
ip router ospf 1 area 0.0.0.0
ip pim sparse-mode
ip dhcp relay address 10.0.0.1
ip dhcp relay address 10.0.0.2
ip dhcp relay address 10.0.0.3
no shutdown
interface Ethernet1/54.4
description to spine 2pod2
mtu 9150
encapsulation dot1q 4
ip address 172.16.101.21/30
ip ospf cost 100
ip ospf network point-to-point
ip router ospf 1 area 0.0.0.0
ip pim sparse-mode
ip dhcp relay address 10.0.0.1
ip dhcp relay address 10.0.0.2
ip dhcp relay address 10.0.0.3
no shutdown
MTU (unidad de transmisión básica)
Si OSPF no está apareciendo (EXCHANGE o EXSTART) entre la columna y el dispositivo IPN, asegúrese de validar que MTU coincide entre los dispositivos.
configuración RP
Con PIM BiDir, el punto de encuentro (RP) no forma parte de la ruta de datos. Para la multidifusión funcional, cada dispositivo IPN sólo necesita tener una ruta a la dirección RP. La redundancia se puede lograr mediante una configuración de RP fantasma. En este caso, el RP de difusión ilimitada no es un método de redundancia válido debido a que no tiene un origen para intercambiar a través del protocolo de transmisión de fuente multidifusión (MSDP).
En un diseño de RP fantasma, el RP es una dirección inexistente en una subred alcanzable. En la siguiente configuración, se asume que el rango de multidifusión configurado en la configuración inicial de APIC es el valor predeterminado 225.0.0.0/15. Si se cambió en la configuración inicial de APIC, las configuraciones de IPN deben estar alineadas.
El loopback1 a continuación es el loopback phantom-rp. Se debe inyectar en OSPF; sin embargo, no se puede utilizar como ID de router OPSF. Para ello se debe utilizar un bucle invertido (loopback0) independiente.
Configuración IPN1:
interface loopback1
description IPN1-RP-Loopback
ip address 172.16.101.221/30
ip ospf network point-to-point
ip router ospf 1 area 0.0.0.0
ip pim sparse-mode
ip pim rp-address 172.16.101.222 group-list 225.0.0.0/15 bidir
ip pim rp-address 172.16.101.222 group-list 239.255.255.240/32 bidir
Configuración IPN2:
ip pim rp-address 172.16.101.222 group-list 225.0.0.0/15 bidir
ip pim rp-address 172.16.101.222 group-list 239.255.255.240/32 bidir
Configuración IPN3:
interface loopback1
description IPN3-RP-Loopback
ip address 172.16.101.221/29
ip ospf network point-to-point
ip router ospf 1 area 0.0.0.0
ip pim sparse-mode
ip pim rp-address 172.16.101.222 group-list 225.0.0.0/15 bidir
ip pim rp-address 172.16.101.222 group-list 239.255.255.240/32 bidir
Configuración de IPN4:
ip pim rp-address 172.16.101.222 group-list 225.0.0.0/15 bidir
ip pim rp-address 172.16.101.222 group-list 239.255.255.240/32 bidir
La máscara de subred en el loopback no puede ser /32. Para utilizar IPN1 como el dispositivo principal en el diseño de RP fantasma, utilice una máscara de subred /30 para aprovechar la ruta más específica que se prefiere en la topología OSPF. IPN3 será el dispositivo secundario en el diseño de RP fantasma, así que utilice una máscara de subred /29 para convertirlo en una ruta menos específica. El /29 sólo se utilizará si ocurre algo que detenga el /30 del existente y subsecuentemente existente dentro de la topología OSPF.
Los siguientes pasos describen el proceso que debe seguir el primer grupo de dispositivos remotos para unirse al fabric:
Desde el APIC, valide si la IP L3Out está configurada correctamente para ofrecerse: (nuestro Spine 401 tiene la serie FDO22472FCV)
bdsol-aci37-apic1# moquery -c dhcpExtIf
# dhcp.ExtIf
ifId : eth1/30
childAction :
dn : client-[FDO22472FCV]/if-[eth1/30]
ip : 172.16.101.26/30
lcOwn : local
modTs : 2019-10-01T09:51:29.966+00:00
name :
nameAlias :
relayIp : 0.0.0.0
rn : if-[eth1/30]
status :
subIfId : unspecified
# dhcp.ExtIf
ifId : eth1/29
childAction :
dn : client-[FDO22472FCV]/if-[eth1/29]
ip : 172.16.101.18/30
lcOwn : local
modTs : 2019-10-01T09:51:29.966+00:00
name :
nameAlias :
relayIp : 0.0.0.0
rn : if-[eth1/29]
status :
subIfId : unspecified
Valide si la interfaz orientada a IPN recibió la dirección IP esperada que coincide con la configuración L3Out realizada en el arrendatario infra.
S1P2-Spine401# show ip interface brief | grep eth1/29
eth1/29 unassigned protocol-up/link-up/admin-up
eth1/29.29 172.16.101.18/30 protocol-up/link-up/admin-up
Ahora se ha establecido la conectividad IP desde la columna al APIC y se puede verificar la conectividad mediante ping:
S1P2-Spine401# iping -V overlay-1 10.0.0.1
PING 10.0.0.1 (10.0.0.1) from 172.16.101.18: 56 data bytes
64 bytes from 10.0.0.1: icmp_seq=0 ttl=60 time=0.345 ms
64 bytes from 10.0.0.1: icmp_seq=1 ttl=60 time=0.294 ms
^C
--- 10.0.0.1 ping statistics ---
2 packets transmitted, 2 packets received, 0.00% packet loss
round-trip min/avg/max = 0.294/0.319/0.345 ms
La columna ahora traerá el OSPF al IPN y configurará un loopback para el ID del router:
S1P2-Spine401# show ip ospf neighbors vrf overlay-1
OSPF Process ID default VRF overlay-1
Total number of neighbors: 2
Neighbor ID Pri State Up Time Address Interface
172.16.101.204 1 FULL/ - 00:04:16 172.16.101.25 Eth1/30.30
172.16.101.203 1 FULL/ - 00:04:16 172.16.101.17 Eth1/29.29
S1P2-Spine401# show ip ospf interface vrf overlay-1
loopback8 is up, line protocol is up
IP address 172.16.2.4/32, Process ID default VRF overlay-1, area backbone
Enabled by interface configuration
State LOOPBACK, Network type LOOPBACK, cost 1
Ethernet1/30.30 is up, line protocol is up
IP address 172.16.101.26/30, Process ID default VRF overlay-1, area backbone
Enabled by interface configuration
State P2P, Network type P2P, cost 1
Index 68, Transmit delay 1 sec
1 Neighbors, flooding to 1, adjacent with 1
Timer intervals: Hello 10, Dead 40, Wait 40, Retransmit 5
Hello timer due in 00:00:07
No authentication
Number of opaque link LSAs: 0, checksum sum 0
Ethernet1/29.29 is up, line protocol is up
IP address 172.16.101.18/30, Process ID default VRF overlay-1, area backbone
Enabled by interface configuration
State P2P, Network type P2P, cost 1
Index 67, Transmit delay 1 sec
1 Neighbors, flooding to 1, adjacent with 1
Timer intervals: Hello 10, Dead 40, Wait 40, Retransmit 5
Hello timer due in 00:00:04
No authentication
Number of opaque link LSAs: 0, checksum sum 0
La columna ahora recibirá su PTEP a través de DHCP:
S1P2-Spine401# show ip interface vrf overlay-1 | egrep -A 1 status
lo0, Interface status: protocol-up/link-up/admin-up, iod: 4, mode: ptep
IP address: 10.1.88.67, IP subnet: 10.1.88.67/32
El conmutador central pasará de Detectar a Activo y se descubrirá por completo:
bdsol-aci37-apic1# acidiag fnvread
ID Pod ID Name Serial Number IP Address Role State LastUpdMsgId
--------------------------------------------------------------------------------------------------------------
101 1 S1P1-Leaf101 FDO224702JA 10.0.160.64/32 leaf active 0
102 1 S1P1-Leaf102 FDO223007G7 10.0.160.67/32 leaf active 0
201 1 S1P1-Spine201 FDO22491705 10.0.160.65/32 spine active 0
202 1 S1P1-Spine202 FDO224926Q9 10.0.160.66/32 spine active 0
401 2 S1P2-Spine401 FDO22472FCV 10.1.88.67/32 spine active 0
Tenga en cuenta que solo podemos detectar una columna remota cuando tiene al menos 1 switch de hoja conectado a ella.
El resto del POD se descubre ahora según el procedimiento normal de activación del POD, como se describe en la sección "Configuración inicial del fabric".
Para detectar el 3er APIC, se sigue el siguiente proceso:
Para confirmar, utilice las siguientes comprobaciones:
El Leaf301 crea una ruta estática al APIC (APIC3) conectado directamente basado en LLDP (igual que en el caso de un único grupo de dispositivos)
S1P2-Leaf301# show ip route 10.0.0.3 vrf overlay-1
IP Route Table for VRF "overlay-1"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>
10.0.0.3/32, ubest/mbest: 2/0
*via 10.1.88.64, eth1/50.14, [115/12], 00:07:21, isis-isis_infra, isis-l1-ext
*via 10.1.88.67, eth1/49.13, [115/12], 00:07:15, isis-isis_infra, isis-l1-ext
via 10.0.0.3, vlan9, [225/0], 07:31:04, static
Leaf301 anuncia esta ruta usando IS-IS a Spine401 y Spine402 (igual que un solo caso Pod)
Spine401 y Spine402 filtran esta ruta en OSPF hacia IPN
S1P2-Spine401# show ip route 10.0.0.3 vrf overlay-1
IP Route Table for VRF "overlay-1"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>
10.0.0.3/32, ubest/mbest: 1/0
*via 10.1.88.65, eth1/2.35, [115/11], 00:17:38, isis-isis_infra, isis-l1-ext S1P2-Spine401#
IPN3# show ip route 10.0.0.3
IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>
10.0.0.3/32, ubest/mbest: 2/0
*via 172.16.101.18, Eth1/53.4, [110/20], 00:08:05, ospf-1, type-2
*via 172.16.101.22, Eth1/54.4, [110/20], 00:08:05, ospf-1, type-2
S1P1-Spine201# show ip route vrf overlay-1 10.0.0.3
IP Route Table for VRF "overlay-1"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>
10.0.0.3/32, ubest/mbest: 2/0
*via 172.16.101.1, eth1/29.29, [110/20], 00:08:59, ospf-default, type-2
*via 172.16.101.9, eth1/30.30, [110/20], 00:08:59, ospf-default, type-2
via 10.0.160.64, eth1/1.36, [115/12], 00:18:19, isis-isis_infra, isis-l1-ext
via 10.0.160.67, eth1/2.35, [115/12], 00:18:19, isis-isis_infra, isis-l1-ext
Ahora se establece la conectividad entre APIC3, APIC1 y APIC2
Ahora APIC3 puede unirse al clúster
apic1# show controller
Fabric Name : POD37
Operational Size : 3
Cluster Size : 3
Time Difference : 133
Fabric Security Mode : PERMISSIVE
ID Pod Address In-Band IPv4 In-Band IPv6 OOB IPv4 OOB IPv6 Version Flags Serial Number Health
---- ---- --------------- --------------- ------------------------- --------------- ------------------------------ ------------------ ----- ---------------- ------------------
1* 1 10.0.0.1 0.0.0.0 fc00::1 10.48.176.57 fe80::d6c9:3cff:fe51:cb82 4.2(1i) crva- WZP22450H82 fully-fit
2 1 10.0.0.2 0.0.0.0 fc00::1 10.48.176.58 fe80::d6c9:3cff:fe51:ae22 4.2(1i) crva- WZP22441AZ2 fully-fit
3 2 10.0.0.3 0.0.0.0 fc00::1 10.48.176.59 fe80::d6c9:3cff:fe51:a30a 4.2(1i) crva- WZP22441B0T fully-fit
Flags - c:Commissioned | r:Registered | v:Valid Certificate | a:Approved | f/s:Failover fail/success
(*)Current (~)Standby (+)AS
Haga ping desde APIC1 a un dispositivo remoto en Pod2 para validar la conectividad mediante el siguiente ping: (asegúrese de obtener de la interfaz local, en el caso APIC1 10.0.0.1)
apic1# ping 10.0.0.3 -I 10.0.0.1
PING 10.0.0.3 (10.0.0.3) from 10.0.0.1 : 56(84) bytes of data.
64 bytes from 10.0.0.3: icmp_seq=1 ttl=58 time=0.132 ms
64 bytes from 10.0.0.3: icmp_seq=2 ttl=58 time=0.236 ms
64 bytes from 10.0.0.3: icmp_seq=3 ttl=58 time=0.183 ms
^C
--- 10.0.0.3 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2048ms
rtt min/avg/max/mdev = 0.132/0.183/0.236/0.045 ms
Esto se debe probablemente a:
Consulte "Flujo de trabajo de solución de problemas" en este capítulo y revise:
Esto se debe probablemente a:
Consulte "Flujo de trabajo de solución de problemas" en este capítulo y revise:
Asegúrese de validar que hay al menos 1 hoja conectada a la columna remota y que la columna tiene una adyacencia LLDP con esta hoja.
Esto se debe normalmente a un error en el cuadro de diálogo de configuración inicial de APIC, suponiendo que los switches de columna y de hoja de POD remotos pudieron unirse correctamente al fabric. En una configuración correcta, espere la siguiente salida 'avread' (escenario de unión APIC3 en funcionamiento):
apic1# avread
Cluster:
-------------------------------------------------------------------------
fabricDomainName POD37
discoveryMode PERMISSIVE
clusterSize 3
version 4.2(1i)
drrMode OFF
operSize 3
APICs:
-------------------------------------------------------------------------
APIC 1 APIC 2 APIC 3
version 4.2(1i) 4.2(1i) 4.2(1i)
address 10.0.0.1 10.0.0.2 10.0.0.3
oobAddress 10.48.176.57/24 10.48.176.58/24 10.48.176.59/24
routableAddress 0.0.0.0 0.0.0.0 0.0.0.0
tepAddress 10.0.0.0/16 10.0.0.0/16 10.0.0.0/16
podId 1 1 2
chassisId 7e34872e-.-d3052cda 84debc98-.-e207df70 89b73e48-.-f6948b98
cntrlSbst_serial (APPROVED,WZP22450H82) (APPROVED,WZP22441AZ2) (APPROVED,WZP22441B0T)
active YES YES YES
flags cra- cra- cra-
health 255 255 255
Observe que APIC3 (en el grupo de dispositivos remoto) está configurado con podId 2 y la tepAddress del grupo de dispositivos Pod1.
Verifique los parámetros de configuración del APIC3 original mediante el siguiente comando:
apic3# cat /data/data_admin/sam_exported.config
Setup for Active and Standby APIC
fabricDomain = POD37
fabricID = 1
systemName =bdsol-aci37-apic3
controllerID = 3
tepPool = 10.0.0.0/16
infraVlan = 3937
clusterSize = 3
standbyApic = NO
enableIPv4 = Y
enableIPv6 = N
firmwareVersion = 4.2(1i)
ifcIpAddr = 10.0.0.3
apicX = NO
podId = 2
oobIpAddr = 10.48.176.59/24
Si se produce un error, inicie sesión en APIC3 y ejecute 'acidiag touch setup' y 'acidiag reboot'.
Esto se debe probablemente a:
Consulte "Flujo de trabajo de solución de problemas" en este capítulo y revise:
Asegúrese también de que uno de los dispositivos RP de IPN esté en línea.
Tal como se describe en Validación de IPN en el flujo de trabajo de solución de problemas, utilice un RP fantasma para garantizar que cuando el RP principal deje de funcionar hay un RP secundario disponible. Asegúrese de revisar la sección "Validación de IPN" y verificar la validación correcta.
Esto se debe probablemente a un error de configuración en la configuración de varios dispositivos. Asegúrese de validar el flujo de trabajo de solución de problemas y verifique todo el flujo. Si esto parece correcto, consulte la sección "Reenvío de varios dispositivos" en el capítulo "Reenvío dentro de la estructura" para solucionar este problema.
Revisión | Fecha de publicación | Comentarios |
---|---|---|
1.0 |
08-Aug-2022 |
Versión inicial |