Groupe de travail Réseau	D. McPherson, TCB
Request for Comments : 3345	V. Gill, AOL Time Warner, Inc.
Catégorie : Information	D. Walton, Cisco Systems, Inc.
Traduction Claude Brière de L'Isle	A. Retana, Cisco Systems, Inc.
	août 2002

Condition d'oscillation de chemin persistante pour le protocole de passerelle de bordure (BGP)

Statut de ce mémoire
Le présent mémoire apporte des informations pour la communauté de l'Internet. Le présent mémoire ne spécifie aucune sorte de norme de l'Internet. La distribution du présent mémoire n'est soumise à aucune restriction.

Notice de copyright
Copyright (C) The Internet Society (2002). Tous droits réservés.

Résumé
Dans des configurations particulières, les mécanismes d'adaptation de BGP définis dans "Réflexion de chemin BGP – une solution de remplacement au maillage complet IBGP" et "Confédérations de systèmes autonomes pour BGP" vont introduire une oscillation persistante de chemin BGP. Le présent document discute les deux types d'oscillation persistante de chemin qui ont été identifiées, décrit quand ces conditions vont se produire, et donne des lignes directrices de dessin de réseau pour éviter d'introduire de telles occurrences.
Table des matières
1. Introduction	1
2. Discussion de l'oscillation de type I	2
2.1 Réflexion de chemin et oscillation de type I	2
2.2 Confédérations d'AS et oscillation de type I	4
2.3 Contournements potentiels de l'oscillation de type I	6
3. Discussion de l'oscillation de type II	7
3.1 Confédérations d'AS et ascillation de type II	7
3.2 Contournements potentiels de l'oscillation de type II	10
4. Travaux futurs	10
5. Considérations sur la sécurité	10
6. Remerciements	10
7. Références	10
8. Adresse des auteurs	11
9. Déclaration complète de droits de reproduction	11

 	1.	Introduction

Le protocole de passerelle frontière (BGP, Border Gateway Protocol) est un protocole d'acheminement inter systèmes autonomes. La principale fonction d'un système à capacité BGP est d'échanger les informations d'accessibilité de réseau avec les autres systèmes BGP.

Dans des configurations particulières, les mécanismes d'adaptabilité de BGP [RFC1771] définis dans "Réflexion de chemin BGP – une solution de remplacement au maillage complet IBGP" [RFC2796] et dans "Confédérations de systèmes autonomes pour BGP" [RFC3065] vont introduire une oscillation persistante de chemin BGP.

Le problème est inhérent à la façon dont travaille BGP : les politiques d'acheminement définies en local peuvent entrer en conflit globalement, et certains types de conflits peuvent causer une oscillation persistante du protocole. Compte tenu des pratiques courantes, on voit le problème se manifester dans le contexte de MED + réflecteurs ou confédérations de chemins.

La spécification actuelle de BGP-4 [RFC4271] déclare que le MULTI_EXIT_DISC est seulement comparable entre les chemins appris du même AS voisin. Cette limitation est cohérente avec la description de l'attribut : "L'attribut MULTI_EXIT_DISC peut être utilisé sur des liaisons externes (inter AS) pour distinguer entre plusieurs points de sortie ou d'entrée au même AS voisin." [RFC1771], [RFC4271]

Dans un réseau iBGP à maillage complet, tous les routeurs internes ont une visibilité complète des points de sortie disponibles dans un AS voisin. La comparaison de MULTI_EXIT_DISC pour seulement certains chemins n'est pas un problème.

À cause des implications d'adaptabilité d'un réseau iBGP à maillage complet, deux solutions ont été normalisées : les réflecteurs de chemin [RFC2796] et les confédérations d'AS [RFC3065]. Les deux solutions décrivent des méthodes pour réaliser la distribution de chemin sans maillage iBGP complet dans un AS.

La solution du réflecteur de chemin définit la capacité de ré-annoncer (refléter) les chemins appris par iBGP aux autres homologues iBGP une fois que le meilleur chemin est choisi [RFC2796]. Les confédérations d'AS spécifient le fonctionnement d'une collection de systèmes autonomes sous une administration commune comme une seule entité (c'est-à-dire que vue de l'extérieur, la topologie interne et l'existence de systèmes autonomes séparés ne sont pas visibles). Dans les deux cas, la réduction du maillage complet iBGP résulte en le fait que tous les locuteurs BGP dans l'AS n'ont pas une visibilité complète des points de sortie disponibles dans un AS voisin. En fait, la visibilité peut être partielle et non cohérente selon la situation (et la fonction) du routeur dans l'AS.

Dans certaines topologies qui impliquent des réflecteurs de chemin ou des confédérations (dont la description détaillée est donnée plus loin) la visibilité partielle des points de sortie disponibles dans un AS voisin peut résulter en une décision de choix de meilleur chemin incohérente car les routeurs n'ont pas toutes les informations pertinentes. Si les incohérences s'étendent sur plus d'un routeur participant à l'échange de trafic, il peut en résulter une oscillation persistante de chemin. Les règles de choix du meilleur chemin appliquées dans ce document sont cohérentes avec celles de la spécification actuelle [RFC4271].

Le comportement d'oscillation persistante de chemin est déterministe et peut être évité en employant des principes rudimentaires de conception de réseau BGP jusqu'à ce que des améliorations du protocole résolvent le problème. Dans les sections suivantes, on présente une taxonomie des types d'oscillations et une description de l'ensemble des conditions qui vont déclencher les oscillations de chemin. On poursuit en donnant plusieurs solutions de remplacement pour la conception du réseau qui suppriment la possibilité que cela se produise.

L'intention des auteurs est que ce document serve à attirer l'attention des opérateurs sur le problème, ainsi qu'à déclencher la discussion et susciter des propositions d'améliorations potentielles du protocole qui suppriment la possibilité que cela se produise.

Les oscillations sont classées en type I et type II selon les critères documentés ci-dessous.

 	2.	Discussion de l'oscillation de type I

Dans les deux paragraphes qui suivent on donne les configurations dans lesquelles se produisent les oscillations de type I. On commence par une discussion du problème quand on utilise la réflexion de chemin, et on discute ensuite du problème comme il se pose avec les confédérations d'AS.

En général, l'oscillation de type I ne se produit que quand les DEUX conditions suivantes sont satisfaites :
1) un concept d'un seul niveau de réflexion de chemin ou de confédérations d'AS est utilisé dans le réseau ET
2) le réseau accepte l'attribut BGP MULTI_EXIT_DISC (MED) de deux AS ou plus pour un seul préfixe et les valeurs de MED sont uniques.

Il est aussi possible que l'ordre non déterministe des chemins cause le problème d'oscillation de chemin. La [RFC1771] ne spécifie pas que les chemins devraient être ordonnés d'après les MED mais il a été prouvé qu'un ordre non déterministe peut conduire à des boucles et des décisions d'acheminement incohérentes. La plupart des fabricants ont mis en œuvre un ordre déterministe comme comportement par défaut, ou fournissent un bouton qui permet à l'opérateur de configurer le routeur à ordonner les chemins d'une manière déterministe fondée sur les MED.

 	2.1	Réflexion de chemin et oscillation de type I
On discute maintenant de l'oscillation de type 1 qui se rapporte à la réflexion de chemin. Pour commencer, considérons la topologie décrite à la Figure 1 :

      ---------------------------------------------------------------
    /     --------------------               --------------------     \
   |    /                      \           /                      \    |
   |   |        Grappe 1        |         |       Grappe 2         |   |
   |   |                        |         |                        |   |
   |   |                        |   *1    |                        |   |
   |   |         Ra(RR) . . . . . . . . . . . . . . Rd(RR)         |   |
   |   |         .  .           |         |           .            |   |
   |   |       .*5    .*4       |         |           .*12         |   |
   |   |     .          .       |         |           .            |   |
   |   |   Rb(C)        Rc(C)   |         |         Re(C)          |   |
   |   |     .            .     |         |           .            |   |
   |    \    .            .    /           \          .           /    |
   |      ---.------------.---               ---------.----------      |
    \        .(10)        .(1)     AS1                .(0)            /
      -------.------------.---------------------------.--------------
             .            .                           .
          ------            .     ------------      .
        /        \            . /              \   .
        | AS10   |              |      AS6     |
        \        /              \              /
          ------                  ------------
                .                      .
                   .                   .
                      .       --------------
                         .  /                \
                            |      AS100     |- 10.0.0.0/8
                            \                /
                              --------------

Figure 1 : Exemple de topologie de réflexion de chemin

Dans la Figure 1, AS1 contient deux grappes de réflecteur de chemins, les grappes 1 et 2. Chaque grappe contient un réflecteur de chemin (RR, Route Reflector) (c'est-à-dire, Ra et Rd, respectivement). Un 'RR' associé entre parenthèses représente chaque RR. La grappe 1 contient deux RR clients (Rb et Rc), et la grappe 2 contient un RR client (Re). Un 'C' associé entre parenthèses indique l'état de RR client. Les lignes en pointillés sont utilisées pour représenter les sessions d'échange de trafic BGP.

Le nombre entre parenthèses sur les sessions d'échange de trafic EBGP de AS1 représente la valeur de MED annoncée par l'homologue à associer à l' annonce d'accessibilité du réseau 10.0.0.0/8.

Le nombre qui suit chaque '*' sur la session d'échange de trafic IBGP représente les métriques additives IGP qui sont à associer à l'attribut BGP NEXT_HOP pour le chemin concerné. Par exemple, la valeur Ra de métrique IGP associée à un NEXT_HOP appris via Rb serait 5 ; tandis que la valeur de métrique associée au NEXT_HOP appris via Re serait 13.

Le Tableau 1 décrit les attributs de chemin 10.0.0.0/8 tels que vus par les routeurs Rb, Rc et Re, respectivement. Noter que les métriques IGP dans la Figure 1 sont seulement concernées quand on annonce le chemin à un homologue IBGP.

Routeur	MED	AS_PATH
Rb	10	10 100
Rc	  1 	  6 100
Re	  0 	  6 100

Table 1 : Tableau d'attribut de chemin

Pour les étapes suivantes 1 à 5, le meilleur chemin va être marqué avec un '*'.

1) Ra a ce qui suit qui est installé dans son tableau BGP, avec le chemin appris via AS10 marqué comme le meilleur :

Prochain bond
AS_PATH	MED	Coût IGP
 6 100	 1	4
* 10 100	10	5

Le chemin '10 100' ne devrait pas être marqué comme le meilleur, bien que ceci ne soit pas la cause de l'oscillation persistante de chemin. Ra réalise qu'il a le mauvais chemin marqué comme le meilleur car le chemin '6 100' a une métrique IGP inférieure. À ce titre, Ra fait ce changement et annonce un message UPDATE à ses voisins pour leur faire savoir qu'il considère maintenant le chemin '6 100, 1, 4' comme le meilleur.

2) Rd reçoit le UPDATE de Ra, qui laisse Rd avec ce qui suit installé dans son tableau BGP :

Prochain bond
AS_PATH	MED	Coût IGP
* 6 100	0	12
   6 100	1	5

Rd marque alors le chemin '6 100, 0, 12' comme meilleur parce que il a un MED inférieur. Rd envoie un message UPDATE à ses voisins pour leur faire savoir que c'est le meilleur chemin.

3) Ra reçoit le message UPDATE de Rd et a maintenant dans son tableau BGP :

Prochain bond
AS_PATH	MED	Coût IGP
    6 100	 0	13
    6 100	 1	  4
* 10 100	10	  5

Le premier chemin (6 100, 0, 13) bat le second (6 100, 1, 4) à cause d'un MED inférieur. Ensuite le troisième chemin (10 100, 10, 5) bat le premier chemin à cause de sa métrique IGP inférieure pour le prochain bond. Ra envoie un message UPDATE à ses homologues les informant du nouveau meilleur chemin.

4) Rd reçoit le message UPDATE de Ra, qui laisse Rd avec le tableau BGP suivant :

Prochain bond
AS_PATH	MED	Coût IGP
     6 100	 0	12
* 10 100	10	  6

Rd choisit le chemin '10 100, 10, 6' comme meilleur à cause de la métrique IGP. Rd envoie un UPDATE/retrait à ses homologues pour leur faire savoir que c'est le meilleur chemin.

5) Ra reçoit le message UPDATE de Rd, qui laisse Ra avec le tableau BGP suivant :

Prochain bond
AS_PATH	MED	Coût IGP
     6 100	 1	4
* 10 100	10	5

Ra a reçu un UPDATE/retrait pour '6 100, 0, 13', qui change ce qui est considéré comme le meilleur chemin pour Ra. C'est pourquoi Ra a le chemin '10 100, 10, 5' choisi comme meilleur à l'étape 1, même si en fait '6 100, 1, 4' est le meilleur.

À ce point, on a fait un tour complet et on revient à l'étape 1. Le routeur réalise qu'il utilisé un meilleur chemin incorrect, et répète le cycle. C'est un exemple d'oscillation de type I quand on utilise la réflexion de chemin.

 	2.2	Confédérations d'AS et oscillation de type I
On donne maintenant un exemple d'oscillation de type I avec des confédérations d'AS. Pour commencer, considérons la topologie décrite dans la Figure 2 :

     ---------------------------------------------------------------
   /     --------------------               --------------------     \
  |    /                      \           /                      \    |
  |   |       Sous AS 65000    |         |      Sous AS 65001     |   |
  |   |                        |         |                        |   |
  |   |                        |   *1    |                        |   |
  |   |         Ra . . . . . . . . . . . . . . . . . Rd           |   |
  |   |         .  .           |         |           .            |   |
  |   |       .*3    .*2       |         |           .*6          |   |
  |   |     .          .       |         |           .            |   |
  |   |    Rb . . . . . Rc     |         |          Re            |   |
  |   |     .    *5      .     |         |           .            |   |
  |    \    .            .    /           \          .           /    |
  |      ---.------------.---               ---------.----------      |
   \        .(10)        .(1)     AS1                .(0)            /
     -------.------------.---------------------------.--------------
            .            .                           .
         ------            .     ------------      .
       /        \            . /              \  .
      |   AS10   |            |      AS6       |
       \        /              \              /
         ------                  ------------
               .                      .
                  .                   .
                     .       --------------
                        .  /                \
                          |      AS100       |- 10.0.0.0/8
                           \                /
                             --------------

Figure 2 : Exemple de topologie de confédérations d'AS

Le nombre entre parenthèses sur chaque session d'échange de trafic EBGP AS1 représente la valeur de MED annoncée par l'homologue à associer à l'annonce d'accessibilité du réseau 10.0.0.0/8.

Le nombre qui suit chaque '*' sur la session d'échange de trafic IBGP représente les métriques additives IGP qui sont à associer à l'attribut BGP Prochain bond pour le chemin concerné.

Par exemple, la valeur de métrique IGP Ra associée au prochain bond appris via Rb va être 3, tandis que la valeur de métrique associée au prochain bond appris via Re va être 6.

Le Tableau 2 décrit les attributs de chemin 10.0.0.0/8 tels que vus par les routeurs Rb, Rc et Re, respectivement. Noter que les métriques IGP dans la Figure 2 sont seulement concernées quand on annonce le chemin à un homologue IBGP.

Routeur	MED	AS_PATH
Rb	10	10 100
Rc	  1	  6 100
Re	  0	  6 100

Table 2 : Tableau d'attribut de chemin

Pour les étapes suivantes de 1 à 6 le meilleur chemin sera marqué par un '*'.

1) Ra a le tableau BGP suivant :

Prochain bond
AS_PATH	MED	Coût IGP
* 10 100	10	3
(65001) 6 100	0	7
              6 100	1	2

Le chemin '10 100' est choisi comme meilleur et est annoncé à Rd, bien que ceci ne soit pas la cause de l'oscillation persistante de chemin.

2) Rd a ce qui suit dans son tableau BGP :

Prochain bond
AS_PATH	MED	Coût IGP
         6 100	 0	6
* (65000) 10 100	10	4

Le chemin '(65000) 10 100' est choisi comme meilleur parce que il a la plus faible métrique IGP. Par suite, Rd envoie un UPDATE/retrait à Ra pour le chemin '6 100' qu'il avait annoncé précédemment.

3) Ra reçoit le retrait de Rd. Ra a maintenant ce qui suit dans son tableau BGP :

Prochain bond
AS_PATH	MED	Coût IGP
* 10 100	10	3
         6 100	1	2

Ra a reçu un retrait pour '(65001) 6 100', qui change ce qui est considéré le meilleur chemin pour Ra. Ra ne calcule pas le meilleur chemin pour un préfixe si son meilleur chemin n'a pas été retiré. C'est pourquoi Ra a le chemin '10 100, 10, 3' qui est choisi comme meilleur, bien que le chemin '6 100, 1, 2' soit meilleur.

4) L'examen périodique BGP de Ra fonctionne et réalise que le chemin '6 100' est meilleur à cause de la plus faible métrique IGP. Ra envoie un UPDATE/retrait à Rd pour le chemin '10 100' car Ra utilise maintenant le chemin '6 100' comme son meilleur chemin.

Le tableau BGP de Ra ressemble à :

Prochain bond
AS_PATH	MED	Coût IGP
10 100	10	3
  *  6 100	1	2

5) Rd reçoit le UPDATE de Ra et a maintenant dans son tableau BGP :

Prochain bond
AS_PATH	MED	Coût IGP
(65000) 6 100	1	3
          *  6 100	0	6

Rd choisit le chemin '6 100, 0, 6' comme meilleur à cause de la plus faible valeur de MED. Rd envoie un message UPDATE à Ra, rapportant que '6 100, 0, 6' est maintenant le meilleur chemin.

6) Ra reçoit le UPDATE de Rd. Ra a maintenant dans son tableau BGP :

Prochain bond
AS_PATH	MED	Coût IGP
     *    10 100	10	3
(65000) 6 100	 0	7
              6 100	1	2

À ce point, on a fait un cycle complet et on est de retour à l'étape 1. C'est un exemple d'oscillation de type I avec des confédérations d'AS.

 	2.3	Contournements potentiels de l'oscillation de type I
Un certain nombre de solutions de remplacement peuvent être employées pour éviter ce problème:

1)	Quand on utilise la réflexion de chemin, on s'assure que les liaisons inter grappes ont une métrique IGP supérieure à celle des liaisons intra grappe. C'est le choix préféré quand on utilise la réflexion de chemin. Si les métriques IGP inter grappes avaient été beaucoup plus grandes que les métriques IGP intra grappes, ceci ne se serait pas produit.

2)	Quand on utilise les confédérations d'AS, on s'assure que les liaisons inter sous-AS ont une métrique IGP supérieure à celle des liaisons intra sous-AS. C'est l'option préférée quand on utilise les confédérations d'AS. Si les métriques IGP inter sous-AS avaient été beaucoup plus grandes que les métriques IGP intra sous-AS, ceci ne se serait pas produit.

3)	Ne pas accepter des MED provenant des homologues (cette solution peut n'être pas faisable).

4)	Utiliser d'autres attributs BGP plus haut dans le processus de décision pour que l'algorithme de décision BGP n'atteigne jamais l'étape MED. Comme cela outrepasse complètement les MED, l'option 3 peut avoir plus de sens.

5)	Comparer toujours les MED BGP, sans considérer si ils ont été ou non obtenus d'un seul AS. C'est probablement une mauvaise idée car les MED peuvent être déduits de diverses façons, et le sont normalement selon la politique de l'opérateur. À ce titre, comparer les valeurs de MED pour un seul préfixe appris de plusieurs AS n'est pas conseillé. Bien sûr, ceci est tout à fait contraire à l'objet des MED, et à ce titre, l'option 3 peut être une alternative plus viable.

6)	Utiliser un maillage IBGP complet. Ce n'est pas une solution faisable pour les AS avec un grand nombre de locuteurs BGP.

 	3.	Discussion de l'oscillation de type II

Dans les paragraphes qui suivent, on donne des configurations dans lesquelles l'oscillation de type II va se produire quand on utilise des confédérations d'AS. Pour être bref, on évite la discussion similaire de l'occurrence de l'utilisation de la réflexion de chemin.

En général, l'oscillation de type II ne se produit que quand LES DEUX conditions suivantes sont satisfaites :
1) plus d'un étage de réflexion de chemin ou de sous-AS est utilisé dans le réseau ET
2) le réseau accepte l'attribut BGP MULTI_EXIT_DISC (MED) provenant de deux AS ou plus pour un seul préfixe et les valeurs de MED sont uniques.

 	3.1	Confédérations d'AS et oscillation de type II
Examinons maintenant l'occurrence d'oscillation de type II relative aux confédérations d'AS. La Figure 3 donne un exemple de topologie :

     ---------------------------------------------------------------
   /                     -------------------                          \
  |      AS 1          /     Sous-AS 65500   \                         |
  |                   |    Rc . . . . Rd      |                        |
  |                   |    .   *2      .      |                        |
  |                    \  .              .   /                         |
  |                      .-----------------.                           |
  |                     .*40                 .*40                      |
  |      --------------.-----                --.-----------------      |
  |    /              .        \           /     .                \    |
  |   |   Sous-AS    .          |         |        .      Sous-AS  |   |
  |   |    65501    .           |         |          .     65502   |   |
  |   |          Rb             |         |         Re             |   |
  |   |          .              |         |        . .             |   |
  |   |          .*10           |         |     *2.   .*3          |   |
  |   |          .              |         |      .     .           |   |
  |   |          Ra             |         |  . Rg . . . Rf         |   |
  |    \          .            /           .             .        /    |
  |      ----------.----------           .  -------------.-------      |
   \                .(0)               .(1)              .()          /
     ----------------.---------------.-------------------.----------
                     .            .                     .
                      ---------  .                  ---------
                      |AS 200 |                     |AS 300 |
                      ---------                     ---------
                              .                     .
                                .                 .
                                -------------------
                                |      AS 400     | - 10.0.0.0/8
                                -------------------

Figure 3 : Exemple de topologie de confédérations d'AS

Dans la Figure 3, AS 1 contient trois sous-AS, 65500, 65501 et 65502. Aucun RR n'est utilisé dans le sous-AS, et à ce titre, tous les routeurs au sein de chaque sous-AS sont pleinement maillés. Ra et Rb sont membres du sous-AS 65501. Rc et Rd sont membres du sous-AS 65500. Ra et Rg échangent du trafic EBGP avec l'AS 200, le routeur Rf a un échange de trafic EBGP avec l'AS 300. Les AS 200 et AS 300 fournissent le transit pour AS 400, et en particulier, le réseau 10/8. Les lignes en pointillés sont utilisées pour représenter les sessions d'échange de trafic BGP.

Le numéro qui suit chaque '*' sur les sessions d'échange de trafic BGP représente les métriques IGP additives qui sont à associer au prochain bond BGP. Le nombre contenu entre parenthèses sur chaque session d'échange de trafic EBGP AS 1 représente la valeur de MED annoncée par l'homologue à associer à l'annonce d'accessibilité du réseau (10.0.0.0/8).

Rc, Rd et Re sont les routeurs principaux impliqués dans l'oscillation, et à ce titre, vont être les seuls tableaux BGP qu'on va surveiller étape par étape.

Pour les étapes 1 à 8, le meilleur chemin de chaque routeur sera marqué par un '*'.

1) Re reçoit l'annonce de chemin d'AS 400 10.0.0.0/8 via l'AS 200 de Rg et l'AS 300 de Rf. Re choisit le chemin via Rg et AS 200 à cause de la métrique IGP (Re ne prend pas en compte le MED parce que les annonces ont été reçues d'AS différents).

Prochain bond
Routeur	AS_PATH	MED	Coût IGP
Re	* 200 400	1	2
	   300 400		3

Re envoie un message UPDATE à Rd annonçant son nouveau meilleur chemin '200 400, 1'.

2) Le chemin '200 400, 0' a été annoncé de Ra à Rb, et ensuite de Rb à Rc. Rd apprend le chemin '200 400, 1' de Re.

Prochain bond
Routeur	AS_PATH	MED	Coût IGP
Rc	* 200 400	0	50
Rd	* 200 400	1	42
Re	   300 400		  3
	* 200 400	1	2

3) Rc et Rd annoncent leurs meilleurs chemins l'un à l'autre ; Rd choisit '200 400, 0' à cause du MED.

Prochain bond
Routeur	AS_PATH	MED	Coût IGP
Rc	* 200 400	0	50
	200 400	1	44
Rd	* 200 400	0	50
	   200 400	1	42
Re	   300 400		  3
	* 200 400	1	2

Rd a un nouveau meilleur chemin de sorte qu'il envoie un UPDATE à Re, annonçant le nouveau chemin et un UPDATE/retrait pour '200 400, 1' à Rc.

4) Re choisit maintenant 300 400' (sans MED) parce que '200 400, 0' bat '200 400, 1' sur la base du MED et '300 400' bat '200 400, 0' à cause de la métrique IGP.

Prochain bond
Routeur	AS_PATH	MED	Coût IGP
Rc	* 200 400	0	50
Rd	* 200 400	0	52
	   200 400	1	42
Re	* 300 400		  3
	   200 400	0	92

Re a un nouveau meilleur chemin et envoie un UPDATE à Rd pour '300 400'.

5) Rd choisit le chemin '300 400' à cause de la métrique IGP.

Prochain bond
Routeur	AS_PATH	MED	Coût IGP
Rc	* 200 400	0	50
Rd	   200 400	0	52
	* 300 400	 	43
Re	* 300 400		   3
	* 200 400	0	92
	200 400	1	2

Rd a un nouveau meilleur chemin de sorte qu'il envoie un UPDATE à Rc et un UPDATE/retrait à Re pour '200 400, 0'.

6) Rc choisit '300 400' à cause de la métrique IGP. Re choisit '200 400, 1' à cause de la métrique IGP.

Prochain bond
Routeur	AS_PATH	MED	Coût IGP
Rc	  200 400	0	50
	* 300 400	 	45
Rd	  200 400	0	52
	* 300 400		43
Re	   300 400		  3
	* 200 400	1	2

Rc envoie un UPDATE/retrait pour '200 400, 0' à Rd. Re envoie un UPDATE pour '200 400, 1' à Rd.

7) Rd choisit '200 400, 1' comme son nouveau meilleur chemin sur la base de la métrique IGP.

Prochain bond
Routeur	AS_PATH	MED	Coût IGP
Rc	   200 400	0	50
	* 300 400		45
Rd	* 200 400	1	42
Re	   300 400		  3
	* 200 400	1	2

Rd envoie un UPDATE à Rc, annonçant '200 400, 1' et retirant implicitement '300 400'.

8) Rc choisit '200 400, 0'.

Prochain bond
Routeur	AS_PATH	MED	Coût IGP
Rc	* 200 400	0	50
	200 400	1	44
Rd	* 200 400	1	42
Re	   300 400		  3
	* 200 400	1	2

À ce point on est revenu à l'étape 2 et on est dans une boucle.

 	3.2	Contournements potentiels de l'oscillation de type II
1) Ne pas accepter de MED provenant des homologues (cette solution peut n'être pas faisable).

2)	Utiliser d'autres attributs BGP plus haut dans le processus de décision afin que l'algorithme de décision BGP choisisse un seul AS avant d'atteindre l'étape MED. Par exemple, si la préférence locale a été réglée sur la base de l'AS annonceur, on peut d'abord éliminer tous les chemins sauf ceux d'un seul AS. Dans l'exemple, le routeur Re prendrait X ou Y sur la base de la préférence locale et ne changerait jamais son choix.

Cela laisse deux simples contournements pour les deux types de problèmes.

Type I : faire la métrique de liaison inter grappe ou inter sous-AS supérieure à la métrique intra grappe ou intra sous-AS.

Type II : faire le choix de chemin sur la base de la préférence locale allouée à l'AS annonceur en premier et ensuite utiliser le coût IGP et le MED pour faire le choix entre les chemins provenant du même AS.

Noter que cela exige des politiques par préfixes, ainsi qu'une connaissance intime des autres réseaux de la part de l'opérateur de réseau. Les auteurs n'ont pas connaissance d'un [grand] fournisseur d'aujourd'hui qui effectue une politique par préfixes sur les chemins appris des homologues. Supprimer implicitement cette portion dynamique du choix de chemin ne paraît pas être une option viable dans les réseaux d'aujourd'hui. Le point principal est qu'une solution de contournement disponible en utilisant la préférence locale afin que deux AS n'annoncent pas un certain préfixe à la même préférence locale résout l'oscillation de type II.

3)	Toujours comparer les MED BGP, sans considérer si ils ont été ou non obtenus d'un seul AS. C'est probablement une mauvaise idée car les MED peuvent être déduits de plusieurs façons, et le sont normalement par une politique spécifique de l'opérateur et largement fonction de l'espace de métrique disponible fourni par l'IGP employé. À ce titre, comparer les valeurs de MED pour un seul préfixe appris de plusieurs AS est mal avisé. Cela va à l'encontre de l'objet des MED ; l'option 1 peut être une solution plus viable.

4) Ne pas utiliser plus d'un étage de réflexion de chemin ou de sous-AS dans le réseau. Le risque d'oscillation de chemin devrait être considéré quand on conçoit des réseaux qui pourraient utiliser une architecture d'isolation d'acheminement à plusieurs étages.

5)	Dans une topologie RR, mailler les clients. Pour les confédérations, mailler les routeurs bordures à chaque niveau de la hiérarchie. Dans la Figure 3, par exemple, si Rb et Re sont des homologues, il n'y a alors pas d'oscillation.

 	4.	Travaux futurs
Il doit être déclaré que les améliorations du protocole concernant ce problème doivent être poursuivies. Imposer des exigences de dessin de réseau, comme celles soulignées ci-dessus, est clairement une solution à long terme déraisonnable. Des problèmes comme celui-ci ne devraient pas se produire dans des configurations de protocole "par défaut".

 	5.	Considérations sur la sécurité
Cette discussion n'introduit pas de nouveaux soucis de sécurité pour BGP ou autre spécification référencée dans le présent document.

 	6.	Remerciements
Les auteurs remercient Curtis Villamizar, Tim Griffin, John Scudder, Ron Da Silva, Jeffrey Haas et Bill Fenner.

 	7.	Références
[RFC1771]	Y. Rekhter, T. Li , "Protocole de routeur frontière v. 4 (BGP-4)", mars 1995. (Obsolète, voir RFC4271) (D.S.)

[RFC2796]	T. Bates, R. Chandra, E. Chen, "Réflexion de chemin BGP - une alternative à IBGP à maillage complet", avril 2000. (Obsolète, voir RFC4456) (P.S.)

[RFC3065]	P. Traina, D. McPherson, J. Scudder, "Confédérations de systèmes autonomes pour BGP", février 2001. (Obsolète, voir RFC5065) (P.S.)

[RFC4271]	Y. Rekhter, T. Li et S. Hares, "Protocole de routeur frontière version 4 (BGP-4)", janvier 2006. (D.S.) (MàJ par RFC6608, RFC8212)

 	8.	Adresse des auteurs

Danny McPherson	Vijay Gill	Daniel Walton	Alvaro Retana	
TCB	AOL Time Warner, Inc.	Cisco Systems, Inc.	Cisco Systems, Inc.	
mél : danny@tcb.net 	12100 Sunrise Valley Drive	7025 Kit Creek Rd.	7025 Kit Creek Rd.	
	Reston, VA 20191	Research Triangle Park, NC 27709	Research Triangle Park, NC 27709	
	mél : vijay@umbc.edu 	mél : dwalton@cisco.com 	mél : aretana@cisco.com 	

 	9.	Déclaration complète de droits de reproduction

Copyright (C) The Internet Society (2002). Tous droits réservés.

Le présent document et ses traductions peuvent être copiés et fournis aux tiers, et les travaux dérivés qui les commentent ou les expliquent ou aident à leur mise en œuvre peuvent être préparés, copiés, publiés et distribués, en tout ou partie, sans restriction d’aucune sorte, pourvu que la déclaration de droits de reproduction ci-dessus et le présent paragraphe soient inclus dans toutes copies et travaux dérivés. Cependant, le présent document lui-même ne peut être modifié d’aucune façon, en particulier en retirant la notice de droits de reproduction ou les références à la Internet Society ou aux autres organisations Internet, excepté autant qu’il est nécessaire pour les besoins du développement des normes Internet, auquel cas les procédures de droits de reproduction définies dans les procédures des normes Internet doivent être suivies, ou pour les besoins de la traduction dans d’autres langues que l’anglais.

Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Internet Society ou ses successeurs ou ayant droits.

Le présent document et les informations contenues sont fournis sur une base "EN L’ÉTAT" et le contributeur, l’organisation qu’il ou elle représente ou qui le/la finance (s’il en est), la INTERNET SOCIETY et la INTERNET ENGINEERING TASK FORCE déclinent toutes garanties, exprimées ou implicites, y compris mais non limitées à toute garantie que l’utilisation des informations encloses ne viole aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

Le financement de la fonction d’édition des RFC est actuellement fourni par l’Internet Society.