Comprendre la relation entre le protocole BFD et le routage compatible avec les applications

Introduction

Ce document décrit la relation qui existe entre les paquets Hello BFD et les statistiques du tunnel de routage sensible aux applications.

Conditions préalables

Exigences

Cisco recommande que vous ayez une connaissance de ce sujet :

• Réseau étendu défini par logiciel (SD-WAN) Cisco Catalyst.
• Routage reconnaissant les applications.
• BFD.

Composants utilisés

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.

• Cisco Catalyst SD-WAN Manager.
• Périphériques SD-WAN du Catalyst Cisco IOS® XE.

Informations générales

Le protocole BFD (Bidirectional Forwarding Detection) s'exécute sur tous les tunnels de plan de données entre périphériques Cisco IOS-XE Catalyst SD-WAN. Ce protocole est utilisé pour surveiller les caractéristiques d'activité et de chemin des tunnels, telles que les performances de tunnel signalées comme Perte, Gigue et Latence.

Les périphériques de périphérie utilisent des sondes BFD Hello pour mesurer la perte de paquets, la gigue et la latence sur le tunnel. Ces statistiques sont calculées pour chaque sonde Hello BFD et sont prises sur une fenêtre glissante de temps appelée intervalle d'interrogation.

Ces statistiques de perte, de latence et de gigue sont utilisées par le routage sensible aux applications pour acheminer le trafic en fonction des exigences définies dans la stratégie, appelées classes SLA, dans lesquelles il détermine la perte, la gigue et la latence maximales autorisées dans le tunnel sélectionné pour acheminer les données.

Pour cette raison, il est très important de comprendre comment les mesures sont calculées et comment un changement dans les valeurs BFD peut affecter le calcul des performances du tunnel principalement la perte moyenne. Les paramètres BFD sont les suivants :

Paramètre	Valeur par défaut	Plage	Utilisation
intervalle Hello BFD	1 seconde	1 à 65535 secondes	Paquets permettant de détecter l'activité de la connexion du tunnel et les défaillances du tunnel.
Intervalle d'interrogation	10 minutes (600 000 millisecondes)	1 à 4 294 967 millisecondes	Fréquence à laquelle une mesure de groupement est calculée pour fournir des statistiques.
Multiplicateur	6	1 à 6	Valeur qui multiplie l'intervalle d'interrogation pour spécifier le temps de calcul de la perte moyenne, de la latence moyenne et de la gigue moyenne. Cette valeur détermine le nombre de compartiments.

Calcul des statistiques de performances du tunnel

Pour les paramètres BFD définis par défaut, le calcul des statistiques s'effectue comme suit :

Intervalle d'interrogation / Intervalle Hello BFD = 600 000 ms / 1 000 ms = 600 Hello BFD par compartiment.

Comme le multiplicateur est défini sur 6, cela signifie que 6 compartiments sont utilisés pour calculer la latence moyenne, la gigue et la perte. Avec les valeurs par défaut, cela équivaut à 1 heure. Ce temps total est également appelé intervalle app-route.

Intervalle App-route = Intervalle d'interrogation * multiplicateur = 600 000 ms x 6 = 3 600 000 ms égal à 1 heure.

Les calculs des statistiques de route d'application sont utilisés par le routage sensible aux applications pour déterminer les modifications dans le plan de données. Pour qu'un périphérique Edge puisse tirer parti des statistiques de routage d'application, les classes SLA doivent être spécifiées dans la politique AAR dans laquelle la gigue de paquet, la perte et la latence maximales acceptables sont définies. Ces classes SLA sont utilisées dans la politique AAR pour acheminer le trafic pour des applications spécifiées conformément aux SLA.  

Une fois configurées dans un périphérique Edge, les statistiques AAR sont utilisées pour les comparer à la perte moyenne, à la latence moyenne et à la gigue moyenne fournies par les statistiques calculées avec tous les compartiments (sur l'intervalle app-route entier). Il est également important de noter que les SLA sont mis à jour après chaque intervalle d'interrogation, toutes les dix minutes par défaut.

Pour obtenir la perte moyenne, la gigue moyenne et la latence moyenne, les équations utilisées sont les suivantes :

Perte moyenne = (perte totale pour tous les compartiments * 100) / Nombre total de paquets.

Latence moyenne = (perte totale pour tous les regroupements) / montant des regroupements.

Gigue moyenne = (gigue totale dans tous les compartiments) / quantité de compartiments.

Le calcul de ces valeurs avec la moyenne de chaque compartiment peut être revu dans l'interface de ligne de commande avec :

vEdge#show app-route stats

cEdge#show sdwan app-route stats

Dans l'interface utilisateur graphique, la perte moyenne, la latence moyenne et la gigue moyenne uniquement peuvent être examinées dans la section Monitor > Overview > Application-Aware Routing.

Vous pouvez également le consulter dans la section Monitor > Devices > Select Device > WAN > Tunnel.

Exemples de relation entre les valeurs BFD et les pertes

Comme les HELLO BFD sont des valeurs configurables, ils peuvent être modifiés en fonction des besoins ; cependant, il est important de les modifier après mûre réflexion, sinon des calculs biaisés ou des statistiques faussement positives peuvent être reçus puisque la précision du calcul de perte moyenne dépend des valeurs BFD. Par exemple, avec des valeurs par défaut de :

Paramètre	manquer à ses obligations
paquet Hello BFD	1 seconde
Intervalle d'interrogation	(600 000 millisecondes) 10 minutes
Multiplicateur	6

vEdge1# show app-route stats
app-route statistics 10.100.100.2 10.200.200.4 ipsec 12366 12346 
remote-system-ip 10.1.1.1 
local-color      private1 
remote-color     private1 
mean-loss        1 
mean-latency     110 
mean-jitter      51 
sla-class-index  0,2 
IPV6 TX  IPV6 RX 
TOTAL          AVERAGE  AVERAGE  TX DATA  RX DATA  DATA     DATA 
INDEX  PACKETS  LOSS  LATENCY  JITTER   PKTS     PKTS     PKTS     PKTS 
---------------------------------------------------------------------------- 
0     596       7     110      50        0        0        0        0 
1     596       5     111      50        0        1        0        0 
2     597      13     111      53        0        0        0        0 
3     594       4     111      53        0        0        0        0 
4     596       5     110      50        0        0        0        0 
5     594      12     111      50        0        2        0        0 

Perte moyenne = (7+5+13+4+5+12)100)/ (596+596+597+594+596+594)

          = 4 600/3 573

          = 1,28 ~ 1 %

Latence moyenne = (110+111+111+111+110+111)/6

             = 110,66 ~ 110 ms

Gigue moyenne = (50+50+53+53+50+50) / 6

            = 3 /6 = 51 ms

Remarque : pour chaque calcul effectué, seules les valeurs entières sont présentées. Même lorsque le résultat exact est décimal, les valeurs entières sont arrondies à l'entier inférieur le plus proche.

En règle générale, il est conseillé de modifier ces valeurs pour augmenter la fréquence des calculs, mais cela peut avoir un impact important. Par exemple, si au lieu des valeurs par défaut, l'intervalle d'interrogation est modifié pour :

Paramètre	manquer à ses obligations
paquet Hello BFD	1 seconde
Intervalle d'interrogation	(60 000 millisecondes) 1 mn
Multiplicateur	6

Ce changement signifie qu'il utilise 1 x 60 = 60 paquets par bucket au lieu de 600 par défaut. Le résultat de la perte moyenne est :

vEdge1# show app-route stats
app-route statistics 10.100.100.2 10.200.200.4 ipsec 12366 12346
remote-system-ip 10.1.1.1
local-color      private1
remote-color     private1
mean-loss        3
mean-latency     112 
mean-jitter      51 
sla-class-index  0,2 
IPV6 TX  IPV6 RX 
TOTAL          AVERAGE  AVERAGE  TX DATA  RX DATA  DATA     DATA 
INDEX  PACKETS  LOSS  LATENCY  JITTER   PKTS     PKTS     PKTS     PKTS 
---------------------------------------------------------------------------- 
0     59       1     113      53        0        0        0        0
1     60       3     111      52        0        1        0        0 
2     59       1     111      51        0        1        0        0 
3     60       3     111      50        0        1        0        0 
4     60       2     115      50        0        0        0        0 
5     59       1     111      50        0        2        0        0 

Perte moyenne = ((1+3+1+3+2+1)*100)/(59+60+59+60+60+59)

          = (1100)/ 357

          = 3,08 ~ 3 %

À ce stade, si, par exemple, la classe SLA est définie sur une perte maximale de 3, alors le tunnel est sous la limite de la violation du SLA. Toutefois, si l'intervalle d'interrogation est modifié pour :

Paramètre	manquer à ses obligations
paquet Hello BFD	1 seconde
Intervalle d'interrogation	(6 000 millisecondes) 1 seconde
Multiplicateur	6

Ce changement signifie qu'il utilise 1 x 6 = 6 paquets par bucket au lieu de 600 par défaut. Le résultat de la perte moyenne est :

vEdge1# show app-route stats
app-route statistics 10.100.100.2 10.200.200.4 ipsec 12366 12346 
remote-system-ip 10.1.1.1 
local-color      private1 
remote-color     private1 
mean-loss        17
mean-latency     110 
mean-jitter      0 
sla-class-index  None
IPV6 TX  IPV6 RX 
TOTAL          AVERAGE  AVERAGE  TX DATA  RX DATA  DATA     DATA 
INDEX  PACKETS  LOSS  LATENCY  JITTER   PKTS     PKTS     PKTS     PKTS 
---------------------------------------------------------------------------- 
0     5       1     113      2        0        0        0        0 
1     6       1     110      1        0        1        0        0 
2     6       1     111      2        0        0        0        0 
3     6       0     111      0        0        0        0        0 
4     6       1     111      0        0        0        0        0 
5     6       1     111      0        0        2        0        0 

Perte moyenne = (5)100)/(5+6+6+6+6)

          = (500)/29

          = 17,24 ~ 17 %

Si l'intervalle d'interrogation est réduit sans la validation correcte du nombre de paquets utilisés pour la mesure, cela peut affecter la perte moyenne, la même chose peut s'appliquer si l'intervalle Hello bfd est augmenté sans augmenter l'intervalle du pool.

Dans le dernier exemple, comme très peu de paquets sont utilisés pour effectuer le calcul, avec un seul paquet perdu, la perte moyenne peut être affectée de manière significative. Le résultat de ces calculs est un comportement de stratégie sensible aux applications avec des basculements multiples et très fréquents.

L'objectif de cette explication n'est pas d'éviter la modification de ces valeurs, au contraire, dans de nombreuses situations, ces sondes doivent être modifiées. Cela dépend entièrement des besoins du réseau, mais il est très important de vérifier dans quelle mesure ces paquets Hello peuvent être réduits.

La commande de configuration pour modifier globalement l'intervalle d'interrogation est :

vEdge(config)# bfd app-route poll-interval 600000