Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.
Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.
Ce document décrit l'impact de la tempête de paquets ARP sur les protocoles du plan de contrôle tels que BFD, OSPF et d'autres, exécutés sur les commutateurs Nexus 7000.
Contribué par Nishad Mohiuddin, Nikolay Kartashev, ingénieurs du TAC Cisco.
A. En général, une tempête de paquets ARP peut avoir un impact négatif sur la stabilité des sessions BFD exécutées sur le commutateur Nexus 7000. Les symptômes exacts dépendent de la longévité et de la magnitude de l'événement ARP Packet Storm. Vous trouverez ci-dessous les résultats des tests effectués sur le réseau de TP du centre d'assistance technique de Cisco.
La configuration de TP suivante est conçue pour tester l'impact des volumes de trafic ARP sur le processeur du commutateur Nexus 7000.
Ici, N7k-A est utilisé comme périphérique sous test (DUT). DUT est un commutateur Nexus 7009 avec la configuration matérielle suivante
N7k-A# show module
Mod Ports Module-Type Model Status
--- ----- ----------------------------------- ------------------ ----------
1 0 Supervisor module-1X N7K-SUP1 active *
2 0 Supervisor module-1X N7K-SUP1 ha-standby
3 32 10 Gbps Ethernet Module N7K-M132XP-12 ok
4 32 10 Gbps Ethernet Module N7K-M132XP-12 ok
N7k-A#
Les périphériques suivants sont connectés à N7k-A :
DUT dispose de trois sessions BFD, une sur la carte de ligne dans le logement 4 vers N7k-C et deux sur la carte de ligne dans le logement 3 vers N7k-B et ASR1k
N7k-A# show bfd neighbors
OurAddr NeighAddr LD/RD RH/RS Holdown(mult) State Int
10.80.6.173 10.80.6.174 1090519061/4105 Up 4951(3) Up Eth3/14
10.80.1.162 10.80.1.161 1090519054/1090519044 Up 4203(3) Up Eth4/10
10.80.1.61 10.80.1.62 1090519060/1090519059 Up 5921(3) Up Vlan6
N7k-A#
DUT dispose également de trois sessions OSPF, une sur la carte de ligne dans le logement 4 en direction de N7k-C et deux sur la carte de ligne dans le logement 3, en direction de N7k-B et ASR1k.
N7k-A# show ip ospf neighbors
OSPF Process ID 1
Total number of neighbors: 3
Neighbor ID Pri State Up Time Address Interface
10.80.0.2 1 FULL/ - 00:13:26 10.80.1.62 Vlan6
10.80.4.25 1 FULL/DR 00:12:40 10.80.6.174 Eth3/14
10.80.0.3 1 FULL/DR 20:15:07 10.80.1.161 Eth4/10
N7k-A#
OSPF est enregistré avec BFD
router ospf 1
bfd
router-id 10.80.0.1
En outre, la table ARP sur N7k-A contient des entrées pour les trois voisins BFD/OSPF
N7k-A# show ip arp
Address Age MAC Address Interface
10.80.1.62 00:13:30 4055.390f.48c1 Vlan6
10.80.6.174 00:12:46 88f0.774b.0700 Ethernet3/14
10.80.1.161 00:15:13 6c9c.ed44.6841 Ethernet4/10
N7k-A#
Le générateur de trafic IXIA est utilisé pour simuler une partie instable du réseau, ce qui entraîne un volume élevé de trafic ARP envoyé à DUT, comme le montre le schéma ci-dessous
Le résultat suivant montre une augmentation du trafic d'entrée sur l'interface Ethernet 3/10, où le générateur de trafic IXIA est connecté. Il s’agit de paquets ARP de diffusion reçus dans le VLAN 6
N7k-A# show interface Ethernet3/10 | grep "30 seconds input rate"
30 seconds input rate 3102999976 bits/sec, 6062053 packets/sec
N7k-A#
Comme une copie de chaque paquet ARP de diffusion est envoyée au processeur sur N7k-A dans ce scénario, nous voyons une augmentation des octets violés sur le module 3 dans CoPP
N7k-A# show policy-map interface control-plane class copp-system-p-class-normal
Control Plane
service-policy input: copp-system-p-policy-strict
class-map copp-system-p-class-normal (match-any)
match access-group name copp-system-p-acl-mac-dot1x
match protocol arp
set cos 1
police cir 680 kbps , bc 250 ms
module 3 :
conformed 2295040 bytes; action: transmit
violated 20569190016 bytes; action: drop
module 4 :
conformed 128 bytes; action: transmit
violated 0 bytes; action: drop
N7k-A#
Note: Notez qu'il n'y a pas d'octets non violés sur le module dans le logement 4, car la source de la tempête ARP de diffusion est connectée à l'interface sur le module 3 uniquement
Au moment où commence la tempête ARP, les sorties ci-dessus sont généralement les premiers (et seuls) signes qui indiquent un problème sur le réseau. Dans la plupart des cas, ces signes passent inaperçus ou sont négligés par les opérateurs de réseau et évoluent rapidement vers une situation qui entraîne des problèmes de connectivité majeurs.
Par défaut, le délai d'attente ARP sur la plate-forme Nexus 7000 est configuré pour 25 minutes ou 1 500 secondes. Le commutateur Nexus doit actualiser périodiquement les entrées de cache ARP local afin de maintenir à jour la résolution IP/MAC de ses voisins de couche 3 de tronçon suivant.
Voici la sortie de la table de cache ARP sur DUT après l'expiration des entrées de cache ARP.
N7k-A# show ip arp
Address Age MAC Address Interface
10.80.1.62 00:00:06 INCOMPLETE Vlan6
10.80.6.174 00:00:10 INCOMPLETE Ethernet3/14
10.80.1.161 00:12:59 6c9c.ed44.6841 Ethernet4/10
N7k-A#
Notez que les entrées du cache ARP pour les périphériques connectés à la carte de ligne dans le logement 3 indiquent l'état INCOMPLET, tandis que l'entrée pour le commutateur N7k-C, connecté à la carte de ligne dans le logement 4, est actualisée comme prévu.
Les messages de journal DUT suivants indiquent l'impact sur le niveau du plan de contrôle
N7k-A# show logging log
...
2016 Nov 16 22:12:55 N7k-A %BFD-5-SESSION_STATE_DOWN: BFD session 1090519060 to neighbor 10.80.1.62 on interface Vlan6 has gone down. Reason: 0x3.
2016 Nov 16 22:12:55 N7k-A %OSPF-5-ADJCHANGE: ospf-1 [10600] Nbr 10.80.1.62 on Vlan6 went DOWN
2016 Nov 16 22:12:55 N7k-A %BFD-5-SESSION_REMOVED: BFD session to neighbor 10.80.1.62 on interface Vlan6 has been removed
2016 Nov 16 22:12:56 N7k-A %OSPF-5-ADJCHANGE: ospf-1 [10600] Nbr 10.80.1.62 on Vlan6 went EXSTART
2016 Nov 16 22:13:40 N7k-A %OSPF-5-ADJCHANGE: ospf-1 [10600] Nbr 10.80.6.174 on Ethernet3/14 went DOWN
2016 Nov 16 22:13:40 N7k-A %BFD-5-SESSION_STATE_DOWN: BFD session 1090519061 to neighbor 10.80.6.174 on interface Eth3/14 has gone down. Reason: 0x3.
2016 Nov 16 22:13:40 N7k-A %OSPF-5-ADJCHANGE: ospf-1 [10600] Nbr 10.80.6.174 on Ethernet3/14 went EXSTART
2016 Nov 16 22:13:46 N7k-A %BFD-5-SESSION_REMOVED: BFD session to neighbor 10.80.6.174 on interface Eth3/14 has been removed
2016 Nov 16 22:15:45 N7k-A %OSPF-5-ADJCHANGE: ospf-1 [10600] Nbr 10.80.6.174 on Ethernet3/14 went INIT
...
N7k-A#
Notez dans cette sortie que le protocole OSPF bascule entre l'état DOWN et EXSTART, puis revient à l'état INIT. Cela se produit parce qu'OSPF utilise la monodiffusion pour échanger des préfixes pendant l'état EXSTART. Comme la résolution ARP est incomplète sur le module dans le logement 3 au moment de la tempête de paquets ARP, l'échange de route ne se termine jamais et la contiguïté OSPF ne se forme pas.
Remarque:La résolution ARP vers IP vers MAC du saut suivant repose sur la monodiffusion, tout comme le fonctionnement de BFD. Étant donné que nous pouvons conclure que BFD exige que le protocole ARP soit résolu pour fonctionner correctement.
Les sorties suivantes confirment l'impact d'une tempête de paquets ARP sur les sessions BFD et OSPF sur le module du logement 3. Contrairement à cette ou ces sessions BFD et OSPF sur le module du logement 4 sont établies et restent stables.
N7k-A# show bfd neighbors
OurAddr NeighAddr LD/RD RH/RS Holdown(mult) State Int
10.80.1.162 10.80.1.161 1090519054/1090519044 Up 5764(3) Up Eth4/10
N7k-A#
N7k-A# show ip ospf neighbors
OSPF Process ID 1
Total number of neighbors: 3
Neighbor ID Pri State Up Time Address Interface
10.80.0.2 1 EXSTART/ - 00:02:54 10.80.1.62 Vlan6
10.80.4.25 1 INIT/DR 00:00:05 10.80.6.174 Eth3/14
10.80.0.3 1 FULL/DR 20:29:28 10.80.1.161 Eth4/10
N7k-A#
Lorsqu’une tempête de paquets ARP s’arrête, la récupération suivante se produit automatiquement et le réseau commence à converger et jouit de l’état stable qu’il avait avant la tempête de diffusion ARP.
Même si Cisco NX-OS peut distribuer le fonctionnement du BFD aux modules compatibles prenant en charge le BFD, des volumes élevés de trafic ARP qui touchent le CPU du commutateur pendant une période plus longue que le temps restant pour actualiser les entrées de cache ARP locales sur la plate-forme Nexus 7000 provoqueront une instabilité dans les sessions BFD et dans tous les protocoles clients enregistrés avec le BFD.
Ceci peut être attribué au fonctionnement BFD qui nécessite une résolution ARP du saut suivant qui est de monodiffusion. Si l'entrée du cache ARP pour le prochain saut n'est pas actualisée à temps, les sessions BFD échoueront.