Une tempête de paquets ARP peut-elle avoir un impact sur les sessions BFD sur la plate-forme Nexus 7000 ?

Introduction

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.

Q. Puisque Cisco NX-OS peut distribuer le fonctionnement de BFD aux modules compatibles prenant en charge BFD, une tempête de paquets ARP aurait-elle un impact sur les sessions BFD sur la plate-forme Nexus 7000 ?

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.

Détails de la configuration des travaux pratiques

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 :

• N7k-B est un homologue VPC, connecté à l'interface Ethernet 3/15
• ASR1k est un voisin de couche 3, connecté à l’interface Ethernet 3/14
• N7k-C est un voisin de couche 3, connecté à l'interface Ethernet 4/10
• Le générateur de trafic IXIA se trouve dans le VLAN 6, connecté à l'interface Ethernet 3/10, configurée comme port d'accès de couche 2

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#

Début de la tempête ARP

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.

La tempête ARP commence à affecter le plan de contrôle 

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# 

Que se passe-t-il lorsqu’une tempête de paquets ARP s’arrête ? 

 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.

1. Les entrées du cache ARP sont résolues sur N7k-A
2. Les sessions BFD sur le module dans le logement 3 sont rétablies
3. Les sessions OSPF sur le module dans le logement 3 sont rétablies

Conclusion

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.