Dépannage du SLA IP sur le PBR multipod

Introduction

Ce document décrit les étapes d'identification et de dépannage d'un périphérique suivi IP SLA sur un POD distant à l'aide de l'environnement multipod PBR ACI.

Conditions préalables

Exigences

Cisco vous recommande de prendre connaissance des rubriques suivantes :

• Solution Multipod
• Graphiques de service avec PBR

Remarque : pour plus d'informations sur la configuration ACI IP SLA, reportez-vous au guide PBR and Tracking Service Nodes.

Composants utilisés

Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :

• Cisco ACI version 4.2(7l)
• Commutateur leaf Cisco N9K-C93180YC-EX
• Commutateur Cisco Spine N9K-C936PQ
• Nexus 7k version 8.2(2)

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

Topologie du réseau

Topologie

Informations générales

À l'aide d'un graphique de services, l'infrastructure Cisco ACI peut rediriger le trafic entre les zones de sécurité vers un pare-feu ou un équilibreur de charge, sans que le pare-feu ou l'équilibreur de charge soit la passerelle par défaut pour les serveurs.

La fonctionnalité IP SLA de la configuration PBR permet au fabric ACI de surveiller ce noeud de service (périphérique L4-L7) dans votre environnement et permet au fabric de ne pas rediriger le trafic entre la source et la destination vers un noeud de service inactif s'il est inaccessible.

Remarque : l'IPSLA ACI dépend du système de fabric GIPO (adresse de multidiffusion 239.255.255.240/28) pour envoyer les sondes et distribuer l'état de suivi.

Scénario

Dans cet exemple, la connectivité est-ouest ne peut pas être établie entre le point d'extrémité source 192.168.150.1 sur POD-1 et le serveur de destination 192.168.151.1 sur POD-2. Le trafic est redirigé vers le noeud PBR 172.16.1.1 à partir de la feuille de service 103 sur POD-1. PBR utilise la surveillance IP SLA et les stratégies Redirect Health Group.

Étapes de dépannage

Étape 1. Identifier l’état IP SLA

1. Dans l'interface utilisateur APIC, accédez à Tenants > Your_Tenant > Faults.
2. Recherchez les défauts F2911, F2833, F2992.

Erreurs IP SLA


Étape 2. Identifier l'ID de noeud avec le groupe d'intégrité à l'état Down

1. Sur l'interface de ligne de commande APIC, exécutez la commande moquery en utilisant l'une des erreurs F2911, F2833, F2992.
2. Vous pouvez voir que le groupe d'intégrité lb1::lb-healthGrp est désactivé pour Leaf 202 dans POD-2.

MXS2-AP002# moquery -c faultInst -f 'fault.Inst.code == "F2911"'
# fault.Inst
code : F2911
ack : no
alert : no
annotation : 
cause : svcredir-healthgrp-down
changeSet : operSt (New: disabled), operStQual (New: healthgrp-service-down)
childAction : 
created : 2024-01-31T19:07:31.505-06:00
delegated : yes
descr : PBR service health grp lb1::lb-healthGrp on nodeid 202 fabric hostname MXS2-LF202 is in failed state, reason Health grp service is down.
dn : topology/pod-2/node-202/sys/svcredir/inst/healthgrp-lb1::lb-healthGrp/fault-F2911 <<<
domain : infra
extMngdBy : undefined
highestSeverity : major

Étape 3. Valider le périphérique PBR en tant que point d'extrémité et accessible à partir de la feuille de service

MXS2-LF103# show system internal epm endpoint ip 172.16.1.1

MAC : 40ce.2490.5743 ::: Num IPs : 1
IP# 0 : 172.16.1.1 ::: IP# 0 flags : ::: l3-sw-hit: No
Vlan id : 22 ::: Vlan vnid : 13192 ::: VRF name : lb1:vrf1
BD vnid : 15958043 ::: VRF vnid : 2162693
Phy If : 0x1a00b000 ::: Tunnel If : 0
Interface : Ethernet1/12
Flags : 0x80004c04 ::: sclass : 16391 ::: Ref count : 5
EP Create Timestamp : 02/01/2024 00:36:23.229262
EP Update Timestamp : 02/02/2024 01:43:38.767306
EP Flags : local|IP|MAC|sclass|timer|

MXS2-LF103# iping 172.16.1.1 -V lb1:vrf1
PING 172.16.1.1 (172.16.1.1) from 172.16.1.254: 56 data bytes
64 bytes from 172.16.1.1: icmp_seq=0 ttl=255 time=1.046 ms
64 bytes from 172.16.1.1: icmp_seq=1 ttl=255 time=1.074 ms
64 bytes from 172.16.1.1: icmp_seq=2 ttl=255 time=1.024 ms
64 bytes from 172.16.1.1: icmp_seq=3 ttl=255 time=0.842 ms
64 bytes from 172.16.1.1: icmp_seq=4 ttl=255 time=1.189 ms

--- 172.16.1.1 ping statistics ---
5 packets transmitted, 5 packets received, 0.00% packet loss
round-trip min/avg/max = 0.842/1.034/1.189 ms

Étape 4. Vérifier le groupe d'intégrité PBR dans POD local et POD distant

Remarque : considérez Local POD comme celui qui obtient le périphérique PBR configuré.

Leaf 103 est le Leaf de service sur POD-1. Par conséquent, nous considérons POD-1 comme POD local et POD-2 comme POD distant.

Le groupe d'intégrité est uniquement programmé sur les commutateurs Leaf où les EPG source et de destination demandent son déploiement.

1. L’EPG source est situé sur le noeud leaf 102 POD-1. Vous pouvez voir que le périphérique PBR est suivi comme étant UP à partir de Service Leaf 103 POD-1.

MXS2-LF102# show service redir info health-group lb1::lb-healthGrp 
=======================================================================================================================================
LEGEND
TL: Threshold(Low) | TH: Threshold(High) | HP: HashProfile | HG: HealthGrp | BAC: Backup-Dest | TRA: Tracking | RES: Resiliency
=======================================================================================================================================
HG-Name HG-OperSt HG-Dest HG-Dest-OperSt
======= ========= ======= ==============
lb1::lb-healthGrp enabled dest-[172.16.1.1]-[vxlan-2162693]] up

2. L’EPG de destination se trouve sur le noeud leaf 202 POD-2. Vous pouvez voir que le périphérique PBR est suivi comme étant HORS service à partir de la fiche de service 103 POD-1.

MXS2-LF202# show service redir info health-group lb1::lb-healthGrp
=======================================================================================================================================
LEGEND
TL: Threshold(Low) | TH: Threshold(High) | HP: HashProfile | HG: HealthGrp | BAC: Backup-Dest | TRA: Tracking | RES: Resiliency
=======================================================================================================================================
HG-Name HG-OperSt HG-Dest HG-Dest-OperSt
======= ========= ======= ==============
lb1::lb-healthGrp disabled dest-[172.16.1.1]-[vxlan-2162693]] down <<<<< Health Group is down. 

Étape 5. Capture des sondes IP SLA avec l'outil ELAM

Remarque : vous pouvez utiliser Embedded Logic Analyzer Module (ELAM), un outil de capture intégré, pour capturer le paquet entrant. La syntaxe ELAM dépend du type de matériel. Une autre approche consiste à utiliser l'application ELAM Assistant.

Pour capturer les sondes IP SLA, vous devez utiliser ces valeurs sur la syntaxe ELAM pour comprendre où le paquet atteint ou est abandonné.

En-tête L2 interne ELAM

MAC source = 00-00-00-00-00-01

MAC de destination = 01-00-00-00-00-00

Remarque : les adresses MAC source et de destination (illustrées précédemment) sont des valeurs fixes sur l'en-tête interne pour les paquets IP SLA.

En-tête L3 externe ELAM

IP source = TEP de votre leaf de service (leaf 103 TEP dans le TP = 172.30.200.64)


Adresse IP de destination = 239.255.255.240 ( Le GIPO du système de fabric doit toujours être identique )


trigger reset 
trigger init in-select 14 out-select 0
set inner l2 dst_mac 01-00-00-00-00-00 src_mac 00-00-00-00-00-01
set outer ipv4 src_ip 172.30.200.64 dst_ip 239.255.255.240
start
stat
ereport

...

------------------------------------------------------------------------------------------------------------------------------------------------------
Inner L2 Header
------------------------------------------------------------------------------------------------------------------------------------------------------
Inner Destination MAC : 0100.0000.0000 
Source MAC : 0000.0000.0001 
802.1Q tag is valid : no 
CoS : 0 
Access Encap VLAN : 0 

------------------------------------------------------------------------------------------------------------------------------------------------------
Outer L3 Header
------------------------------------------------------------------------------------------------------------------------------------------------------
L3 Type : IPv4 
DSCP : 0 
Don't Fragment Bit : 0x0 
TTL : 27 
IP Protocol Number : UDP 
Destination IP : 239.255.255.240 
Source IP : 172.30.200.64

Étape 6. Vérifier que le système de fabric GIPO ( 239.255.255.240 ) est programmé sur les spines locaux et distants

Remarque : pour chaque GIPO, un seul noeud spine de chaque POD est choisi comme périphérique faisant autorité pour transférer des trames de multidiffusion et envoyer des jointures IGMP vers l'IPN.

1. Spine 1001 POD-1 est le commutateur faisant autorité pour transférer des trames de multidiffusion et envoyer des jointures IGMP vers l'IPN.

L’interface Eth1/3 est orientée vers le réseau IP N7K.

MXS2-SP1001# show isis internal mcast routes gipo | more 
IS-IS process: isis_infra
VRF : default 

GIPo Routes
====================================
System GIPo - Configured: 0.0.0.0
Operational: 239.255.255.240
====================================

<OUTPUT CUT> ...

GIPo: 239.255.255.240 [LOCAL]
OIF List:
Ethernet1/35.36
Ethernet1/3.3(External)     <<< Interface must point out to IPN on elected Spine
Ethernet1/16.40
Ethernet1/17.45
Ethernet1/2.37
Ethernet1/36.42
Ethernet1/1.43


MXS2-SP1001# show ip igmp gipo joins | grep 239.255.255.240
239.255.255.240 0.0.0.0 Join Eth1/3.3 43 Enabled

2. Spine 2001 POD-2 est le commutateur faisant autorité pour transférer des trames de multidiffusion et envoyer des jointures IGMP vers l'IPN.

L’interface Eth1/36 est orientée vers le réseau IP N7K.

MXS2-SP2001# show isis internal mcast routes gipo | more
IS-IS process: isis_infra
VRF : default 

GIPo Routes
====================================
System GIPo - Configured: 0.0.0.0
Operational: 239.255.255.240
====================================

<OUTPUT CUT> ...

GIPo: 239.255.255.240 [LOCAL]
OIF List:
Ethernet1/2.40
Ethernet1/1.44
Ethernet1/36.36(External)     <<< Interface must point out to IPN on elected Spine


MXS2-SP2001# show ip igmp gipo joins | grep 239.255.255.240
239.255.255.240 0.0.0.0 Join Eth1/36.36 76 Enabled

3. Assurez-vous que le gipo outgoing-interface-list n'est pas vide dans VSH pour les deux spines.

MXS2-SP1001# vsh
MXS2-SP1001# show forwarding distribution multicast outgoing-interface-list gipo | more
....
Outgoing Interface List Index: 1
Reference Count: 1 
Number of Outgoing Interfaces: 5 
Ethernet1/35.36 
Ethernet1/3.3 
Ethernet1/2.37 
Ethernet1/36.42 
Ethernet1/1.43 
External GIPO OIFList
Ext OIFL: 8001
Ref Count: 393 
No OIFs: 1 
Ethernet1/3.3

Étape 7. Valider GIPO ( 239.255.255.240 ) est configuré sur l'IPN

1. GIPO 239.255.255.240 est manquant dans la configuration IPN.

N7K-ACI_ADMIN-VDC-ACI-IPN-MPOD# show run pim
  ...
  ip pim rp-address 192.168.100.2 group-list 225.0.0.0/15 bidir
  ip pim ssm range 232.0.0.0/8

N7K-ACI_ADMIN-VDC-ACI-IPN-MPOD# show ip mroute 239.255.255.240
IP Multicast Routing Table for VRF "default"

(*, 239.255.255.240/32), uptime: 1d01h, igmp ip pim 
Incoming interface: Null, RPF nbr: 0.0.0.0     <<< Incoming interface and RPF are MISSING
Outgoing interface list: (count: 2)
Ethernet3/3.4, uptime: 1d01h, igmp
Ethernet3/1.4, uptime: 1d01h, igmp

2. GIPO 239.255.255.240 est désormais configuré sur IPN.

N7K-ACI_ADMIN-VDC-ACI-IPN-MPOD# show run pim
  ...
  ip pim rp-address 192.168.100.2 group-list 225.0.0.0/15 bidir
  ip pim rp-address 192.168.100.2 group-list 239.255.255.240/28 bidir     <<< GIPO is configured
  ip pim ssm range 232.0.0.0/8

N7K-ACI_ADMIN-VDC-ACI-IPN-MPOD# show ip mroute 225.0.42.16
IP Multicast Routing Table for VRF "default"

(*, 225.0.42.16/32), bidir, uptime: 1w6d, ip pim igmp 
Incoming interface: loopback1, RPF nbr: 192.168.100.2
Outgoing interface list: (count: 2)
Ethernet3/1.4, uptime: 1d02h, igmp
loopback1, uptime: 1d03h, pim, (RPF)

Étape 8. Confirmer que le suivi IP SLA est ACTIF sur le POD distant

MXS2-LF202# show service redir info health-group lb1::lb-healthGrp
=======================================================================================================================================
LEGEND
TL: Threshold(Low) | TH: Threshold(High) | HP: HashProfile | HG: HealthGrp | BAC: Backup-Dest | TRA: Tracking | RES: Resiliency
=======================================================================================================================================
HG-Name HG-OperSt HG-Dest HG-Dest-OperSt
======= ========= ======= ==============
lb1::lb-healthGrp enabled dest-[172.16.1.1]-[vxlan-2162693]] up 

Informations connexes

ID de débogage Cisco	Titre du bogue	Corriger la version
ID de bogue Cisco CSCwi75331	Le rechargement répété de FM et LC dans le châssis peut entraîner une erreur de programmation de la liste GIPO IP OIFlist.	Pas de version fixe. Utilisez la solution.