Stabilit dans BGP

Ken Schumacher 1 LIRMM - Universit de Montpellier II - 2004 Encadrants : Jean-Claude Knig 2 et Ehoud Ahronovitz 3 Responsable Eurcom : Guillaume Urvoy-Keller

1. ken.schumacher@enst.fr 2. konig@lirmm.fr 3. aro@lirmm.fr

Rsum Le protocole BGP est le protocole le plus utilis actuellement dans Internet pour changer des informations de routages entre systmes autonomes, mais celui-ci soure dinstabilits. Nous tudierons tout dabord le protocole BGP et proposerons un modle. Ensuite nous prsenterons et essayerons de rsoudre un premier type dinstabilit qui intervient lintrieur mme des systmes autonomes avec lutilisation de lattribut MED. Finalement nous tudierons des instabilits entre systmes autonomes dues lutilisation du ltrage dannonce et proposerons un modle.

The BGP protocol is currently the most widely used protocol in the context of Internet when exchanging routing information between autonomous systems, but it tends to be unstable. We will rst study the BGP protocol, and will propose a model. We will then go on to present and attempt to solve a rst type of instability which occurs inside autonomous systems when using the MED attribute. We will then study instabilities occurring between autonomous systems, which are due to the use of announcement ltering, for which we will also propose a model.

Table des matires

1 Introduction 2 Le protocole BGP 2.1 Principes gnraux . . . . . . . . . . . . . . . . 2.2 Modle trs simple de BGP . . . . . . . . . . . 2.2.1 Interactions inter-AS . . . . . . . . . . . 2.2.2 Modle du routeur unique . . . . . . . . 2.2.3 Exemple de fonctionnement de BGP . . 2.2.4 Interaction Intra-AS . . . . . . . . . . . 2.3 BGP . . . . . . . . . . . . . . . . . . . . . . . . 2.3.1 Composition des annonceurs BGP . . . 2.3.2 Communication entre annonceurs BGP . 2.4 Evolutions du protocole . . . . . . . . . . . . . 2.5 Conclusion . . . . . . . . . . . . . . . . . . . . . 7 9 9 9 10 12 14 17 19 19 20 21 22 25 25 28 28 29 30 31 31 32 32 35 35 36 36 38 39 39 39 40

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

3 Oscillations interne lAS 3.1 Exemple doscillation . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Explication du problme . . . . . . . . . . . . . . . . . . . . . . . 3.3 Premires solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4 Utilit et limitation du MED . . . . . . . . . . . . . . . . . . . . 3.5 Solutions plus approfondies . . . . . . . . . . . . . . . . . . . . . 3.5.1 Modication du protocole pour que les annonces aient une porte plus grande . . . . . . . . . . . . . . . . . . . . . . 3.5.2 Dtecter les oscillations et les liminer . . . . . . . . . . . 3.5.3 Eviter les oscillations en modiant la topologie . . . . . . 3.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Oscillations entre AS 4.1 Modle SPVP (Stable Path Vector Protocol) . . 4.2 Quelques exemples simples dinstabilits inter-AS 4.3 Explication du problme . . . . . . . . . . . . . . 4.4 Un systme de pnalits "Route Flap Damping" 4.5 Le problme de stabilit de chemins . . . . . . . 4.5.1 Modle . . . . . . . . . . . . . . . . . . . 4.5.2 Graphe orient de conit . . . . . . . . . . 4.5.3 Limitations et conclusion . . . . . . . . . 3

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

5 Graphe des sous-tats 5.1 Graphe des sous-tats minimaux . . . . . . . 5.1.1 Dnitions . . . . . . . . . . . . . . . 5.1.2 Construction du graphe des sous-tats 5.1.3 Proprits . . . . . . . . . . . . . . . . 5.1.4 Recherche des solutions . . . . . . . . 5.2 Graphe des sous-tats gnraliss . . . . . . . 5.2.1 Les direntes rductions . . . . . . . 5.2.2 Construction . . . . . . . . . . . . . . 5.2.3 Proprits . . . . . . . . . . . . . . . . 5.3 conclusion . . . . . . . . . . . . . . . . . . . . 6 Conclusion et perspectives A Lexique

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

43 43 43 44 48 49 52 52 54 55 56 57 59

Table des gures

2.1 2.2 2.3 2.4 2.5 2.6 3.1 3.2 4.1 4.2 4.3 4.4 4.5 4.6 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9 5.10 5.11 5.12 5.13 5.14 5.15 Exemple dun rseau quelconque . . . . Modle BGP inter-AS . . . . . . . . . . Exemple de la propagation dun chemin Modle BGP intra-AS . . . . . . . . . . Tables et ltrages . . . . . . . . . . . . . Limitation du ltrage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 11 15 18 21 23

Rseau utilis pour ltude du MED . . . . . . . . . . . . . . . . 26 Utilit et limitation du MED . . . . . . . . . . . . . . . . . . . . 30 Le problme "Disagree" . . . . . . . . . . . . . . . . . . Le problme "Bad Gadget" . . . . . . . . . . . . . . . . Le problme "Bad Backup" . . . . . . . . . . . . . . . . Exemple de rseau avec son graphe de conit orient . . Exemple de graphe de conit avec cycle . . . . . . . . . Exemple dun rseau stable et son graphe de conit avec Exemple de rseau . . . . . . . . . . . . . . . . . . Les sous-tats minimaux du rseau . . . . . . . . . Les sous-tats incompatibles . . . . . . . . . . . . . Les sous-tats disjoints amis . . . . . . . . . . . . . Les autres sous-tats amis . . . . . . . . . . . . . . Le sous graphe de conit . . . . . . . . . . . . . . . Exemple dun rseau stable et son graphe de conit Recherche des puits dans le sous-graphe de conit . Supression des sous-tats superus . . . . . . . . . Recherche des sous-tats de plus fort poids . . . . . Exemples de rductions . . . . . . . . . . . . . . . Exemple dune rduction . . . . . . . . . . . . . . . Chemins lis . . . . . . . . . . . . . . . . . . . . . . Sous-tats gnraliss . . . . . . . . . . . . . . . . . Exemple de graphe des sous-tats gnraliss . . . . . . . . . . . . . . . . . . . . . avec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . cycle . . . . . . . . . . . . . . . . . . cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 37 38 40 40 41 45 45 46 46 47 48 50 51 51 52 53 54 55 55 56

Chapitre 1

Introduction
Le protocole BGP (Border Gateway Protocol) est le protocole actuellement utilis dans lInternet pour changer des informations de routage entre systmes autonomes. Mais il soure dincohrences et dinstabilits. Nous essayerons ici de les caractriser et de proposer des amliorations en vu de rendre BGP plus stable. Au fur et mesure de laccroissement dInternet, il a fallu adapter des algorithmes et protocoles de routage en tenant compte de lvolution du rseau. Le protocole GGP (Gateway to Gateway Protocol) utilisait de grandes tables de routage et normment de bande passante pour vhiculer les informations daccessibilit, une panne dans le rseau entranait un recalcul de toutes les distances et de toutes les routes. Dautre part, la vision centralise et unie ne permettait plus de grer convenablement le rseau, une modication dun protocole ou la recherche dune panne devenait un exercice prilleux. Il fallait dcouper et hirarchiser le rseau. Le protocole EGP (Exteral Gateway Protocol) [ECRI82, Mil84] a t conu dans le but de rsoudre ces problmes. La notion de systme autonome (AS) a t alors introduite, cest "un ensemble de routeurs et de rseaux sous une administration unique". Sous cette dnition se cache un concept bien vague, en fait un AS regroupe un ensemble de routeurs interconnects (deux routeurs dun mme AS peuvent communiquer sans traverser un autre AS). Une autre vision est que chaque AS est gr de manire indpendante et un protocole commun permet dinterconnecter, dchanger des informations de routage entre AS. EGP est donc le protocole commun qui va permettre dchanger ces informations. Son principe est trs simple : chaque routeur EGP va envoyer priodiquement ses voisins sa table de routage qui contient les destinations possibles ainsi que la "distance" qui le spare de chacune delle. Cette distance nest pas forcment calcule de la mme manire dun AS un autre comme elle lest dans RIP ou OSPF, car chaque AS est libre de choisir son protocole de routage interne et donc sa notion de distance ; cela permet plus de libert mais a pour inconvnient de crer des incohrences. Eectivement si un AS reoit une route, cest la meilleure suivant les critres de lAS qui a envoy la route mais pas forcment 7

la meilleure suivant les critres de cet AS. Lvolution rapide dInternet a oblig dpasser les limites dEGP. Tout dabord il est trop contraignant, la topologie du rseau doit tre en arbre pour viter la formation de boucles. Ensuite il na pas t conu pour supporter une telle augmentation du nombre de rseaux. Bien quune panne ait moins dincidences que dans GGP, il est toutefois ncessaire denvoyer la totalit des tables ce qui reprsente une lourde charge pour le rseau. Finalement il nest pas compatible avec les besoins actuels de notre socit o la bande passante est devenue un bien commercial. En dautres termes, il est dicile dans EGP dindiquer des prfrences suivant des choix conomiques ou de conance. Il tait donc ncessaire de crer un nouveau protocole de communication entre systmes autonomes tenant compte de ces choix conomiques et de conance, le protocole BGP (Border Gateway Protocol). Tout comme EGP, BGP permet dchanger les informations de routages entre AS. Mais ce nest plus un protocole vecteur de distances mais vecteur de chemins, cela pour dtecter plus facilement les boucles. Dautre part, la notion de politique a pris place pour que le "meilleur chemin" ne soit pas forcment le plus rapide ou celui qui traverse le moins de routeurs. Dans le chapitre 2, nous prsentons le protocole BGP et proposons un modle pour notre tude. Dans le chapitre 3, nous tudions un cas dinstabilit interne aux systmes autonomes (des oscillations entre plusieurs routes) et proposons des solutions simples. Dans le chapitre 4, nous voyons un autre type dinstabilit qui peut apparatre entre les AS. Finalement, dans le chapitre 5, nous proposons un modle pour tudier ces instabilits.

Chapitre 2

Le protocole BGP
2.1 Principes gnraux

Lobjectif principal de BGP est de pouvoir changer des informations de routage entre les dirents organismes indpendants appels systmes autonomes, cest--dire un ensemble de routeurs sous une mme entit administrative, nous avons introduit cette notion dans le chapitre prcdent avec EGP. Un annonceur BGP est un priphrique rseau qui utilise le protocole BGP, ce nest pas forcment un routeur, a peut tre par exemple un serveur de route. Il est compos de tables o sont stockes les informations de routage, dun mcanisme pour slectionner la "meilleure route" destination dun prxe, cest dire dun rseau, dun mcanisme pour ltrer les routes apprises et annonces (aussi appel politique dannonce) ainsi que dune mthode pour changer entre voisins les informations connues. La granularit du routage est le systme autonome, cest dire quun AS ne connat pas tous les routeurs traverss pour atteindre une destination, mais seulement le numro des AS traverss. Le "Border Gateway Protocol" (BGP) a t introduit pour la premire fois en 1989 dans le RFC 1105 [KL89] puis a subi plusieurs volutions ([KL90], [KL91]). Nous sommes actuellement la version 4 du protocole, dni dans [YR94] et corrig dans le RFC 1771 [YR95].

2.2

Modle trs simple de BGP

Nous allons commencer par donner un modle trs simple de BGP, nous approfondirons ensuite le fonctionnement de BGP entre systme autonomes, puis nous verrons le fonctionnement de BGP lintrieur mme dun AS. 9

2.2.1

Interactions inter-AS

Modlisation des AS Chaque systme autonome peut contenir beaucoup dannonceurs BGP, de routeurs non BGP. . . , mais dun point de vue extrieur, nous pouvons les considrer comme un et un seul routeur BGP possdant un grand nombre de ports car tous les annonceurs BGP appartenant un mme AS doivent apparatre comme identiques vue de lextrieur. Il est donc possible de modliser un rseau comme tant un graphe o chaque systme autonome est reprsent par un noeud et les artes modlisent les liens (physiques) de communication entre les AS. Comme il peut y avoir plusieurs artes entre deux noeuds, il sagir plutt dun multigraphe. Par exemple la gure 2.2 est la reprsentation du rseau gnral 2.1.

Fig. 2.1 Exemple dun rseau quelconque

Identication des AS Chaque systme autonome est identi par un numro unique et chaque AS connat le numro de tous ses voisins (information transmise louverture dune session BGP entre deux annonceurs BGP), ce numro est donn par des autorits, les mmes que celles qui sont en charge de la distribution des adresses IP (RIPE, APNIC, ARIN. . . ).

10

AS100 AS200

AS300 AS400

Fig. 2.2 Modle BGP inter-AS

Fonctionnement des annonces de routes Un rseau qui dsire se faire connatre, informe ses voisins BGP de son existence ; ceux-l peuvent ignorer linformation, ou la prendre en compte et la rannoncer tous ou une partie des voisins (sauf au routeur qui a envoy lannonce) ; si un AS annonce une route, il doit par la suite accepter le trac vers cette destination. Si un AS ne veut pas servir de rseau de transit, il ne doit pas rannoncer la route.

Attributs dune route Une annonce de route est compose dun NLRI (Network Layer Reachability Information) cest--dire la destination laquelle correspond lannonce de la route. Elle peut aussi contenir un ensemble de routes " oublier" dans le cas par exemple o un lien tombe en panne. Dautre part, BGP peut agrger des routes. Cest une technique permettant de rduire le nombre de lignes dans les tables de routage en compactant les prxes des rseaux. Par exemple, si un AS est en charge de tous les rseaux ayant les prxes 198.234.0 jusqu 198.234.255, il peut les agrger et annoncer seulement le prx 198.234. Une route est accompagne dinformations ou attributs. Nous y trouvons : ORIGIN indique lorigine de la route (interne lAS dorigine, apprise par le protocole EGP, ou inconnue) ce paramtre nest pratiquement plus utilis. AS_PATH indique la route suivant une liste ordonne dAS. Sil y a eu agrgation de route, tous les AS traverss par toutes les routes contenues dans lagrgation sont indiqus mais pas forcment dans lordre. NEXT_HOP indique lIP du prochain routeur BGP (utile dans le cas ou plusieurs annonceurs partagent le mme lien de communication, par exemple un BUS) ce paramtre nest pas utile dans notre modle. LOCAL_PREF (optionnel) est un attribut interne lAS, il nest jamais communiqu aux autres AS. Il pondre dans lAS la priorit donne aux routes en dautres termes il accorde un degr de prfrence chaque route. ATOMIC_AGGREGATE (optionnel) indique sil y a eu agrgation de routes. 11

AGGREGATOR (optionnel) indique lAS ainsi que lIP du routeur qui a eectu lagrgation. MULTI_EXIT_DISC (MED) (optionnel) permet que lorsque deux AS sont interconnects laide de plusieurs liens, den discriminer en associant chaque lien un degr de prfrence. Le premier AS propose une valeur de MED, le voisin calcul le sien et prend le plus petit des deux. Ce paramtre nest pas utile lorsque deux AS ne sont pas multi connects. Sa porte est limite lAS ainsi que lAS voisin avec qui un MED est ngoci ; il nest en aucun cas rannonc aux autres AS. La liste des attributs nest pas ge, elle est ouverte toute proposition, le RFC 2042 [Man97] propose certaines volutions.

Unicit des routes Si un rseau reoit deux routes vers une mme destination il nen slectionne quune, suivant des mtriques que nous verrons plus tard mais qui nest pas forcment le plus court chemin. Dautre part BGP a t conu pour viter les boucles, concrtement un AS qui reoit une route vrie quil nest pas dj dans le chemin ; sil lest il dtruit linformation.

Modles de communication entre AS En rsum pour notre modle nous devons savoir que chaque noeud contient une liste de chemins. Chacun tant identi par la liste des AS traverser pour atteindre la destination, dun degr de prfrence interne (LOCAL_PREF) et dune mtrique permettant de choisir un lien lorsque deux AS sont multi connects (MED). Ensuite lorsque quune destination d dsire se faire connatre, lAS en charge de cette destination envoie linformation ses AS voisins, puis linformation se transmet de proche en proche avec au nal un arbre recouvrant dont la racine est la destination d, les noeuds sont les AS qui peuvent communiquer avec celle-ci et les arcs reprsentent les routes empruntes par les paquets destination de d. Cette structure reste arborescente car pour qil y ait une route xy (x et y tant des noeuds), il faut quil y ait la route yd ; si yd venait disapraitre la route xy serait limine. Dautre part BGP limine automatiquement les cycles.

2.2.2

Modle du routeur unique

Nous avons vu prcdemment quun AS peut tre vu comme un seul routeur BGP, nous allons voir maintenant ce qui se passe lintrieur de ce routeur.

12

Tables BGP Un annonceur BGP est constitu de trois tables Adj-RIBs-In, Loc-RIB et Adj-RIBs-Out qui servent respectivement conserver les annonces entrantes, les meilleurs chemins et les informations annoncer. Pour simplier, dans notre modle nous nen utiliserons quune seule contenant la liste des routes (quivalante Adj-RIBs-In) et nous ajoutons un indicateur pour simuler la deuxime. Adj-RIBs-Out nest pas utilis car dans un premier temps nous rannonons toutes les routes slectionnes. Chaque ligne correspond une route et contient les informations suivantes : la destination (NLRI), un indicateur permettant de savoir si la route a t slectionne, le prochain routeur, la liste des AS traverser (AS_PATH), le MED, et le degr de prfrence interne lAS dune route (LOCAL_PREF).

Rception et annonce dune route Lorsquun routeur BGP reoit lannonce dune nouvelle route, il applique la politique de ltrage en entre. Celle-ci peut liminer le chemin ou modier la valeur du LOCAL_PREF. Dautre part si lAS auquel appartient le routeur est dj dans la liste des AS traverss, cest quil y a eu cration dune boucle, il limine donc immdiatement cette annonce. Sil a dcid de conserver cette route, il lajoute la table de routage. Attention il ny a quune ligne par couple {annonceur BGP voisin, destination}, en dautres termes, si un voisin a dj annonc une route, et quil en rannonce une pour la mme destination, mais avec dautres paramtres, il faut craser lancienne annonce et relancer le processus de dcision.

Processus de slection Nous allons introduire deux nouvelles notions : E-BGP et I-BGP. Ce sont deux parties du protocole BGP. E-BGP est charg des communications entre AS et I-BGP des communications interne lAS. Nous verrons plus tard les dirences entre ces deux protocoles. Le processus de dcision consiste slectionner la "meilleure route" parmi les chemins possibles suivant le schma ci-dessous ; il sarrte ds quil ny a plus quune seule route dans la liste des possibilits : 1. Choisir la route (ou les routes en cas dgalit) ayant le plus grand LOCAL_PREF 2. Choisir les routes avec le moins dAS dans lAS_PATH (les routes qui traversent le moins dAS) 3. Pour chaque voisin, slectionner les routes qui ont le plus petit MED 4. Sil reste au moins une route E-BGP, cest dire annonce par un AS voisin et non un routeur du mme AS, liminer toutes les routes qui passent au travers de lAS (route annonce en I-BGP) 13

5. Choisir les routes avec un cot IGP minimal (cela ne nous concerne pas pour le moment puisquun AS est reprsent par un noeud, il ny a donc pas de cot IGP) 6. Utiliser une information dterministe, par exemple, prendre la route qui a ladresse IP la plus grande dans lattribut NEXT_HOP. Si la route tait dj connue et quelle reste la meilleure, le routeur BGP ne fait rien. Si la nouvelle route est meilleure ou que la destination ntait pas connue, le routeur ajoute son numro dAS lAS_PATH, eace la valeur du MED et remplace le NEXT_HOP par son adresse IP. Ensuite il entame le processus de rannoncement qui consiste appliquer dautres politiques de ltrage pour slectionner les voisins quil informera de la prsence de cette route. Une route annonce un AS voisin entrane lobligation daccepter le trac provenant de ce voisin et destination de loriginaire de la route. Paralllement si lancienne route nest plus valable et que le routeur BGP ne dsire pas annoncer la nouvelle route un voisin, il lui envoie un message indiquant de supprimer lancienne route.

2.2.3

Exemple de fonctionnement de BGP

Lexemple 2.3 montre le fonctionnement de BGP lorsquun rseau (193.29.108.0/24 appartenant lAS100) dsire se faire connatre. Nous navons pas mis la colonne LOCAL_PREF car dans cet exemple nous supposons quaucune politique na t dnie. Notations : Un plus dans la colonne "Best_path" indique que cest un nouveau meilleur chemin donc quil faut le traiter. Un moins dans la colonne "Best_path" indique lancien meilleur chemin. Le MED est lattribut qui permet de discriminer un lien entre deux AS ; seuls Ra et Rd sont concerns puisque ce sont les seuls avoir plusieurs liens entre eux. Le MED est modlis sur le schma par les valeurs entre parenthses. NEXT_HOP est le routeur de dorigine de lannonce. NLRI est le prxe du rseau qui correspond lannonce (dans notre cas cest 193.29.108.0/24). AS_PATH est la liste des AS traverss. Nous avons spar Ra en Ra1 et Ra2 car il y a deux liens et donc deux interfaces, comme nous gardons les annonces apprises par chaque interface, il tait ncessaire de les direncier.

Etape a : situation initiale Au dbut de notre exemple toutes les tables sont vides et nous voulons propager linformation que le rseau 193.29.108.0/24 existe et appartient Ra 14

AS100

AS100
(7)

a)

Ra (5) Rd Re Rb Rc

b)
AS500

(7) Ra (5) Rd Re Rb Rc

AS500

AS200 AS300 AS400

AS200

AS300

AS400

AS100

AS100
(7)

c)

Ra (5) Rd Re Rb Rc

d)
AS500

(7) Ra (5) Rd Re Rb Rc

AS500

AS200 AS300 AS400

AS200

AS300

AS400

AS100

AS100
(7)

e)

Ra (5) Rd Re Rb Rc

f)
AS500

(7) Ra (5) Rd Re Rb Rc

AS500

AS200 AS300 AS400

AS200

AS300

AS400

Fig. 2.3 Exemple de la propagation dun chemin

Etape b : Ra annonce Rb et Rd le nouveau rseau Le routeur Ra voulant annoncer le rseau 193.29.108.0/24 envoie la nouvelle route (193.29.108.0/24 ; Ra ; 100) ses voisins Rb et Rd . Rb est dans ltat suivant : Routeur Rb NLRI 193.29.108.0/24 Best_path + 15 NEXT_HOP Ra AS_PATH 100 MED ()

Rd reoit lannonce en double puisquil est connect avec deux liens Ra mais il na pas la mme valeur de MED sur les deux chemins. Rd se trouve dans ltat suivant : Routeur Rd Rd NLRI 193.29.108.0/24 193.29.108.0/24 Best_path + NEXT_HOP Ra1 Ra2 AS_PATH 100 100 MED (5) (7)

Etape c : Rd fait suivre lannonce Rc Rd a slectionn lannonce de Ra1 car elle a un plus petit MED, il en averti Rc en envoyant une annonce pour la route (193.29.128.0/24 ; Rd ; 100,500). Rc la reoit, il la considre comme meilleur chemin (puisquil nen a pas dautre). A cette tape l, le routeur Rc est dans ltat : Routeur Rc NLRI 193.29.108.0/24 Best_path + NEXT_HOP Rd AS_PATH 100,500 MED ()

Etape d : Rc envoie lannonce Rb et Re Rc envoie une annonce de nouveau chemin Rb et Re contenant le chemin (193.29.128.0/24 ; Rc ; 100,500,400). Re est dans ltat : Routeur Re NLRI 193.29.108.0/24 Best_path + NEXT_HOP Rc AS_PATH 100,500,400 MED ()

Et Rb , qui a dj eectu son processus de dcision de ltape b mais na pas encore inform ses voisins, garde Ra comme meilleure route puisquelle traverse moins dAS : Routeur Rb Rb NLRI 193.29.108.0/24 193.29.108.0/24 Best_path NEXT_HOP Ra Rc AS_PATH 100 100,500,400 MED () ()

Rb va annoncer sa meilleure route non pas parce quil a reu une nouvelle annonce (car son choix nest pas modi) mais parce quil navait pas eu le temps de le faire jusqua prsent.

Etape e : Rb envoie sa premire slection Rc Donc Rc reoit lannonce et se retrouve dans ltat suivant : Routeur Rc Rc NLRI 193.29.108.0/24 193.29.108.0/24 Best_path + 16 NEXT_HOP Rd Rb AS_PATH 100,500 100,300 MED () ()

Rc compare la route par Rb et celle par Rd . Ayant eectu toutes les tapes de slection et nayant toujours que deux chemins, il choisit de manire dterministe Rb (car Rb a une IP plus grande, par exemple). Donc 100,300 devient sa meilleure route. Il en informe Rd et Re .

Etape f : Rc annonce le chemin par Rb Rd et Re Lannonce de Rc a pour eet de remplacer sans condition la seule route connue chez Re car on ne garde que la dernire annonce qui arrive dun routeur (plus prcisment dune interface dun routeur). Rd quant lui se retrouve dans ltat suivant : Routeur Rd Rd Rd NLRI 193.29.108.0/24 193.29.108.0/24 193.29.108.0/24 Best_path NEXT_HOP Ra1 Ra2 Rc AS_PATH 100 100 100,300,400 MED (5) (7) ()

Le nouveau chemin nest pas meilleur donc il reste dans ltat prcdent sans envoyer de message.

Etat nal Lannonce de la nouvelle destination possible est termine, nous avons construit un arbre sur lAS100 et chaque noeud (AS) est capable de communiquer avec le rseau 193.29.108.0/24.

2.2.4

Interaction Intra-AS

Nous avons vu prcdemment comment fonctionnait un AS vu de lextrieure, mais en ralit un AS est compos dune multitude de routeurs et dannonceurs BGP, ainsi que de routeurs non BGP. Dans la version de base du protocole, chaque annonceur BGP est directement reli avec tous les autres routeurs de lAS, en dautres termes, il y a une session BGP entre chaque paire dannonceurs. Le graphe des annonceurs est une clique. Cela ne veut pas pour autant dire quun lien physique entre eux soit ncessaire, il sut que le rseau soit connexe ce qui est la dnition de base dun AS. La gure 2.4 reprsente un AS quelconque avec son modle BGP.

Dirences entre E-BGP et I-BGP Le fonctionnement de BGP lintrieur dun AS (I-BGP) reste trs proche de son fonctionnement entre AS (E-BGP). Les dirences sont : Une annonce reue en I-BGP nest pas ranonce en I-BGP puisque le graphe des routeurs est plein, si un routeur a fait une annonce, tous les routeurs lont reue. 17

Fig. 2.4 Modle BGP intra-AS

Lattribut LOCAL_PREF nest pas annonc en E-BGP, cest dire quil ne transmet pas linformation un autre AS. Il nest pas ranonc sil est reu en E-BGP (ce qui ne devrait pas arriver) et nest pas modi sil est reu en I-BGP. Les annonces reues en I-BGP ne modient ni lAS_PATH ni le NEXT_HOP. Ces attributs ne sont modis que lorsque lannonce est reue en E-BGP. Le MED est rannonc en I-BGP lorsquil a t reu en I-BGP ; il ne doit pas sortir de lAS. Il est noter que seul le premier routeur de lAS qui reoit une annonce est autoris modier le NEXT_HOP, le LOCAL_PREF, le MED et lAS_PATH. Dautre part, il ny a pas de ltrage pour une annonce en I-BGP, cest dire quun routeur ne peut pas dcider dliminer une annonce ou de cacher une annonce reue dun autre routeur du mme AS, et ce pour garder une cohrence au sein de lAS vis--vis des autres AS.

Connexion deux deux des routeurs BGP dun mme AS Le choix du graphe plein des routeurs interne un AS a t fait pour que chaque routeur ait la totalit de linformation et donc que lAS ore une vue consistante aux autres AS. Nous verrons plus loin que laugmentation du nombre de routeurs a entran la ncessit dutiliser dautres techniques pour ne pas surcharger les routeurs.

Informations disponibles pour slectionner les routes BGP utilise des mtriques contenues dans les annonces de routes, mais se sert aussi dinformations obtenues par dautres moyen tel que par lIGP, le protocole de routage interne lAS qui lui soccupe de router les paquets au niveau 18

des liens physiques. Nous introduisons donc immdiatement lIGP_COST qui sera utile lors de la slection de routes qui nest autre que la somme des cots IGP (des distances IGP) pour atteindre le routeur BGP de bordure qui a fait cette annonce.

2.3

BGP

Nous avons propos dans la section prcdente un modle simple de BGP o nous avons tudi lannonceur BGP en tant que AS ou lment dun AS et la mise jour des informations de routage. Mais ce modle cache certains lments de BGP, dou la ncessit de prsenter plus en profondeur ses mcanismes.

2.3.1

Composition des annonceurs BGP

Comme nous lavons vu, un routeur BGP est compos de tables pour enregistrer les routes apprises, dune mthode pour ltrer les annonces et dune mthode pour slectionner les meilleurs chemins. Nous allons tudier plus en dtail la composition de ces tables et donner une vue plus complte des politiques. Les tables de BGP Le routeur BGP est compos en fait de trois tables appeles des RIB (Routing Information Base) : Adj-RIBs-In contient les informations de routages apprises par les annonceurs BGP voisins Loc-RIB contient les informations de routage que lannonceur BGP a slectionnes suivant des politiques locales parmi les informations contenues dans Adj-RIBs-In Adj-RIBs-Out contient les informations de routage qui peuvent tre communiques un autre annonceur BGP particulier. Il est important de rappeler quil ne peut pas y avoir deux routes apprises par le mme routeur partir de la mme interface dans ces tables, la deuxime annonce crase automatiquement la premire. La table Adj-RIBs-In contient donc les routes annonces par les voisins, certaines de ces routes seront considres comme meilleures pour une destination donne, ces routes seront enregistres dans Loc-RIB. Cest la table qui sert au routage des annonces BGP dun point de vue logique cest dire entre routeurs BGP qui ont une session BGP ouverte. Elle ne sert pas au routage des paquets au niveau physique, cest pourquoi les informations de routage BGP doivent tre transmises au protocole de routage locale (celle dIGP). Inversement cest la table de routage local qui va donner des informations prcieuses 19

BGP telles que les cots IGP. La dernire table, Adj-RIBs-Out, est un sous ensemble de Loc-RIB qui contient les routes ranoncer, celles-ci tant forcment des meilleurs chemins.

Politique de ltrage et slection des meilleurs routes Dans BGP, il y a trois points de ltrage. Le premier permet de slectionner les routes reues. Il nest pas question ici de dnir la meilleure route, mais seulement de modier la valeur du LOCAL_PREF ou de supprimer purement et simplement une annonce ; les routes ainsi ltres seront enregistres dans AdjRIBs-In. Par exemple un AS qui na absolument pas conance en un autre AS peut interdire les annonces des routes et donc ainsi empcher que des paquets circulent par cet AS. Ce ltrage nore pas une totale libert, par exemple nous ne pouvons pas interdire aux paquets dun AS x de transiter par un AS y et autoriser ceux des autres AS passer par y. La deuxime tape est un ltrage des routes contenues dans Adj-RIBs-In pour slectionner les meilleures et les enregistrer dans Loc-Rib. Nous avons vu ce processus prcdemment dans "Processus de slection", section 2.2.2. La dernire tape consiste ltrer les routes qui seront ranonces, puis enregistrer ces routes dans Loc-RIB-out. Attention, rappelons quune route annonce vers un AS implique lobligation daccepter le trac de ce rseau. Par exemple, si un AS ne veut pas servir dAS de transit, mais veut pouvoir router ses propres paquets, il peut accepter les annonces de ses voisins et en interdire la rediusion. Le schma 2.5, inspir de [Sac01] rsume lutilisation des tables et du ltrage. Les ches double sens soulignent linteraction entre IGP et BGP. Il est important de se souvenir que le protocole BGP ne dnit pas les dirents ltrages, chacun peut utiliser des informations extrieures direntes, ou tout simplement chacun peut avoir des politiques extrmement direntes.

2.3.2

Communication entre annonceurs BGP

Tout annonceur BGP qui dsire communiquer avec un autre, doit ouvrir une session BGP avec celui-ci. BGP sappuie sur TCP, ce pour ne pas avoir soccuper dans le protocole des problmes relevant de la transmission. Ensuite les annonceurs BGP communiquent laide de quatre types de messages : OPEN est le premier message envoy, il permet dinformer son voisin de la version BGP utilise, de son numro dAS, dun numro permettant didentier ce processus BGP et ngocier le temps entre deux KEEPALIVE. En retour le voisin BGP envoie un KEEPALIVE si il accepte la connexion et un NOTIFICATION si il la refuse. 20

Fig. 2.5 Tables et ltrages

KEEPALIVE est un message envoy rgulirement (gnralement toutes les 30 secondes) il permet dindiquer au voisin quil est toujours vivant. Le compteur associ au KEEPALIVE est rinitialis la rception dun KEEPALIVE ou dun UPDATE. Si le temps du compteur sest coul, lannonceur BGP envoie un message NOTIFICATION et ferme la session. NOTIFICATION est envoy en cas dincident dans BGP, comme la n du minuteur entre deux KEEPALIVE, un message erron. . . Ce message a pour action de fermer la session BGP et TCP entre lmetteur et le rcepteur du message et dindiquer un code derreur. Lors de la rception dun tel message, toutes les routes apprises par cet annonceur sont supprimes. UPDATE est le message principal du protocole BGP. Il permet dchanger les informations de routage entre voisins. Un message peut contenir les routes liminer et une nouvelle route avec ses attributs. Ce message est envoy uniquement si lannonceur BGP trouve un nouveau meilleur chemin.

2.4

Evolutions du protocole

Le protocole BGP a dj atteint ses limites, il a t ncessaire de le faire voluer. Par exemple : entirement connecter deux deux tous les routeurs dun AS a pour eet douvrir une multitude de sessions BGP et de faire accrotre signicativement les tables de routages. Il a donc t propos deux volutions : les confdrations et les recteurs de route.

21

Les confdrations Les confdrations[PT01] fonctionnent comme les AS, cest dire qu lintrieure dun AS, nous partageons les routeurs en sub-AS ; lintrieur dun sub-AS, les routeurs sont entirement connects deux deux et les sub-AS sont connects (pas forcment en clique) pour garder la connectivit de lAS. La dirence entre la notion de sub-AS et dAS est que entre les sub-AS tous les attributs de route comme le MED, le LOCAL_PREF,. . . sont transmis. Dautre part cest le premier routeur du premier sub-AS qui reoit une annonce, qui peut modier les paramtres de la route. Dun point de vue extrieur, un AS compos de sub-AS apparat toujours comme un unique AS.

Les recteurs de routes Les recteurs de route [TB00] permettent de diviser un AS en clusters (lquivalent des sub-AS dans les confdrations) chacun contenant au moins un recteur de route (RR). Les clients (les autres routeurs du cluster) sont connects uniquement au recteur de route. Les RR sont connects entre eux. Cela permet de rduire signicativement le nombre de sessions BGP[Sac01] : si il y a N routeurs dans un AS, nous aurons N (N 1)/2 sessions BGP sans RR et entre N R + R(R 1)/2 et N R R(R + 1)/2 sessions BGP si nous avons R recteurs de route. Il est intressant de noter que le minimum est atteint lorsquil ny a que deux recteurs de routes.

2.5

Conclusion

Nous avons donn dans cette partie une vue densemble de BGP. Cest un protocole simple qui permet de donner une certaine indpendance aux dirents systmes autonomes, et permet de contrler le trac. Mais les politiques norent pas encore assez de souplesse. Un exemple est donn par C. Huitema[Hui00] dans la gure 2.6 ci-dessous. Le problme est quil est possible dutiliser, pour transmettre des paquets, les trois AS de transit (1,2 et 3) de lAS 4 vers les clients de lAS 0 laide des politiques, mais tous les paquets des clients de lAS 0 sont obligs dutiliser un mme AS de transit (lAS 2 dans notre exemple) pour transmettre des paquets vers lAS 4. Un AS est appel AS de transit lorsquil ne fait que transmettre les paquets dun AS un autre. Dautre part il serait intressant dtudier les confdrations pour savoir quel est le meilleur dcoupage des routeurs dun AS en fonction de la rduction de sessions BGP et de la solidit du rseau que nous voulons obtenir.

22

Fig. 2.6 Limitation du ltrage

23

24

Chapitre 3

Oscillations interne lAS

BGP soure dune certaine instabilit entre plusieurs routes : un des premiers problmes mis en valeur est une oscillation permanente lintrieur mme dun AS face lutilisation de recteurs de route ou de confdrations et de lutilisation du MED. Avant dtudier ce problme nous allons donner un exemple doscillation.

3.1

Exemple doscillation

Cet exemple est directement issu du RFC 3345[DM02]. Nous allons donner ici ltat des routeurs pas pas pour joindre la destination 10.0.0.0/8 prsente dans lAS 100. Le rseau tudi est schmatis dans la gure 3.1. Il utilise la technique des rexions de routes pour rduire la taille des tables et du nombre de messages. Les valeurs entre parenthses reprsente le MED. Les tableaux qui suivent reprsentent ltat de Ra et Rd aprs chaque rception dune mise jour. Chaque ligne des tables correspond une route prsente dans les annonceurs BGP.

"Routeur" indique quel routeur appartiennent les informations. Un plus dans le champ "Best_path" indique que BGP vient de slectionner cette route (cette distinction nest pas faite dans le RFC). Un moins dans le champ "Best_path" indique que la route t slectionn prcdemment. "Annonc par" est un champ que nous avons ajout pour une meilleure comprhension, il correspond au routeur voisin qui a fait lannonce de la route. "AS_PATH" correspond aux dirents AS que traverse la route. Le "MED" correspond au MULTI_EXIT_DISCRIMINATOR Le "Cot IGP" correspond au poids IGP total de la route linterieur de lAS. 25

AS1 Clust1 Ra 5 Rb 4 Rc 1 Clust2 Rd 12 Re

(10)

(1)

(0)

AS10

AS6

AS100

Fig. 3.1 Rseau utilis pour ltude du MED

Etat 1 : tat initial Le tableau ci-dessous reprsente les routes connues par Ra et Rd ltat initial. Router Best_path Annonc par AS_PATH MED Cot IGP Ra - Rb 10 100 10 5 - Re 6 100 0 12 Rd Etat 2 : Rc informe Ra de son meilleur chemin Router Ra Rd Best_path + Annonc par Rc Rb Re AS_PATH 6 100 10 100 6 100 MED 1 10 0 Cot IGP 4 5 12

Ra dcouvre que le chemin appris par Rc est le meilleur car la mtrique IGP est plus faible donc meilleure, il en informe immdiatement Rd par un message UPDATE. 26

Etat 3 : Rd reoit lannonce de Ra pour le chemin (6 100) Router Ra Rd Best_path Annonc par Rc Rb Re Ra AS_PATH 6 100 10 100 6 100 6 100 MED 1 10 0 1 Cot IGP 4 5 12 5

Rd a deux chemins passant par le mme AS suivant, il applique donc le MED pour slectionner le meilleur ; il choisit donc la route apprise par Re car elle a le plus petit MED ; il envoie donc un UPDATE pour informer Ra de son choix.

Etat 4 : Rd informe Ra de son chemins Router Ra Best_path + Annonc par Rc Rb Rd Re Ra AS_PATH 6 100 10 100 6 100 6 100 6 100 MED 1 10 0 0 1 Cot IGP 4 5 13 12 5

Rd

Ra reoit lUPDATE de Rd . Il a deux chemins qui ont le mme NEXT_HOP, il slectionne celui qui a le plus petit MED, cest dire la route apprise par Rd , puis compare cette route celle apprise par Rb ; il slectionne cette deuxime car elle a un cot IGP moindre. Il en informe Rd de sa dcision.

Etat 5 : Ra envoie Rd un UPDATE pour la route par Rb Router Ra Best_path Rd + Annonc par Rc Rb Rd Re Ra AS_PATH 6 100 10 100 6 100 6 100 10 100 MED 1 10 0 0 10 Cot IGP 4 5 13 12 5

Lentre dans Rd correspondant aux annonces faites par Ra est remplace par la nouvelle annonce. Rd slectionne lannonce de Ra cause du plus faible cot IGP. Il est donc daccord avec lannonce faite par Ra et demande Ra doublier sa propre premire annonce, la route (6 100) passant par Re ; il envoie un UPDATE/withdraw.

27

Etat 6 : Rd demande Ra doublier sa prcdente annonce Router Ra Rd Best_path + + Annonc par Rc Rb Re Ra AS_PATH 6 100 10 100 6 100 10 100 MED 1 10 0 10 Cot IGP 4 5 12 5

Ra supprime lentre correspondant Rd et slectionne la route passant par Rc . Les deux routeurs se retrouvent dans ltat 3, il y a donc une boucle qui se traduit par une oscillation innie entre les tat 3, 4 et 5.

3.2

Explication du problme

Cette oscillation vient du fait que dune part toutes les informations ncessaires au choix ne sont pas toujours disponibles, dautre part que le classement des routes ne peut tre ordonn lexicalement, cest dire qutant donn les routes x et y, on ne peut garantir que x < y ou que y < x. En dautres termes, si le routeur Ra na connaissance que des routes X et Y (cf Fig. 3.1), X est meilleur. Si Ra na connaissance que des routes Y et Z, Y est meilleur. Par contre, si Ra a connaissance de X et Z (quil connaisse ou non Y , Z est meilleur. Nous avons donc X > Y > Z > X (en notant > pour "meilleur que"). Route X Y Z Annonc par Rc Rb Rd AS_PATH 6 100 10 100 6 100 MED 1 10 0 Cot IGP 4 5 13

Tab. 3.1 Exemple de tri non dterministe dans Ra Pour rsoudre ce problme on peut essayer de : changer la signication ou lutilisation du MED, modier le protocole pour dtecter les oscillations, modier le protocole pour que les informations ncessaires soient transmises tous les routeurs concerns, modier la topologie du rseau logique BGP.

3.3

Premires solutions

Nous allons tudier les solutions proposes dans le RFC 3345 [DM02]. Ces solutions sont les plus simples ; elles modient laction du MED. Certaines solutions nont aucun sens, le RFC ne les propose pas pour les adopter mais pour expliquer quelles existent. Elles consistent pouvoir trier les routes selon un ordre lexicographique an de choisir la meilleure. Les direntes propositions 28

sont :

Ne pas accepter de MED dun voisin, ce nest pas une bonne solution car lutilisation du MED permet entre autres de dnigrer les liaisons bas dbit. La gure 3.2 ore un exemple de lutilit du MED. Mais par extension de cette solution, nous pourrions proposer dintgrer le MED directement au calcul du LOCAL_PREF. Utiliser des attributs plus forts dans la dcision du meilleur chemin, pour ne pas avoir passer dans ltape du choix suivant le MED. Cette solution est proche de la premire. Toujours comparer le MED, mme sil provient de plusieurs AS. Cette solution retire toute la signication au MED, car chaque AS peut calculer le MED de direntes manires donc comparer des MED de dirents AS na aucun sens. Revenir une solution avec un graphe des annonceurs BGP plein. Cette solution nest pas possible du fait du grand nombre dannonceurs BGP au sein dun mme AS. Mettre un cot IGP plus grand entre les clusters (ou inter Sub-AS dans le cas des confdrations des AS) qu lintrieur. Cette solution un sens car nous pourrions considrer quun sous-AS regroupe des routeurs BGP physiquement proches et que les sous-AS sont gographiquement loigns (par exemple un sous-AS dans chaque pays), mais cette solution nest valable que dans certains cas bien prcis, elle ne rsoud pas entirement le problme. Dans le cas des recteurs de routes, relier tous les clients. Dans le cas des confdrations relier les routeurs de bord (les routeurs qui sont relis directement un autre AS ou sub-AS) chaque niveau. Cette solution est sans doute la moins contraignante mais elle nest pas forcment la meilleure, car cela ajoute un grand nombre de liens et donc accrot rapidement la taille des tables et le nombre de messages. Une solution similaire a t propose dans le cadre des recteurs de routes 1 o chaque RR envoie la totalit des routes et pas uniquement les meilleures aux autres RR. Cette solution retire lintrt des recteurs de routes, cest dire rduire les tables de BGP.

3.4

Utilit et limitation du MED

Avant dtudier plus en profondeur le problme du MED, il est important de comprendre pourquoi ce paramtre de route est important. La gure 3.2 prsente deux schmas. Le premier est un exemple dutilisation du MED. Le
1. Solution propose par A. Basu et al. dans "Route oscillation in I-BGP with Route Reection", ACM SIGCOMM 2002, cit dans [TK03]

29

routeur BGP Rd veut annoncer la prsence dun rseau dont il est en charge lAS 6. Le cot de la liaison entre Rd et Re tant trs important, il prfre que les communications se fassent via le routeur Rc , pour cela il a deux solutions :

soit il interdit lannonce de cette route par Re (politique dannonce interne lAS) mais dans ce cas, il ny a pas de lien de redondance, soit lannonce se fait par Rc et Re mais la liaison entre Re et Rb a un MED beaucoup plus important que sur la liaison Ra Rc , ce qui aura pour eet de forcer le trac circuler via Rc .

Le MED a quelques limitations : dans le deuxime schma, le MED nintervient plus puisque les AS ne sont pas multiconnects, or il serait agrable de pouvoir limiter le trac via Re . Cela pourrait tre possible en ajoutant une mtrique en paramtre dun chemin, qui serait incrmente chaque traverse dAS, mais cela poserait des problmes de conance, en dautres termes un AS est dpendant du fait que tous les AS aient un calcul similaire des incrmentations.

AS6 Ra 600 Rb Ra 600

AS6 Rb

Rc

Rd

400

AS100 Re

AS200

AS50

Rc

Rd

400

AS100 Re

Fig. 3.2 Utilit et limitation du MED

3.5

Solutions plus approfondies

Nous allons tudier et proposer dans cette section des solutions plus complexes qui permettent de conserver intgralement la signication du MED. Nous verrons trois types de solutions : permettre certaines annonces davoir une porte plus grande dtecter les oscillations dynamiquement viter les oscillations avant mme quelles ne se dclarent.

30

3.5.1

Modication du protocole pour que les annonces aient une porte plus grande

Nous proposons la solution suivante : ajouter un paramtre aux routes annonces qui proviennent dun routeur appartenant un AS multiconnect avec lAS qui reoit lannonce. En dautres termes si nous avons deux AS connects avec plusieurs liens, les annonces passant par un de ces liens verront ce paramtre activ. Ce pourrait tre juste un bit indiquant si oui ou non la valeur du MED est ncessaire aux choix du meilleur chemin. Un routeur interne lAS qui reoit une annonce avec cet indicateur activ rmet lannonce mme si ce nest pas son meilleur chemin en indiquant si lannonce a t transmise car cest un nouveau meilleur chemin ou parce quil a le bit activ. Cette technique aura pour eet de propager linformation ncessaire au bon droulement du processus de slection tous les routeurs de lAS. Si P est le nombre de prxes annonc par les AS avec qui nous avons plus dun lien physique, L le nombre de liens redondants entrants dans lAS, et N le nombre de liens BGP internes lAS, alors le nombre de messages supplmentaires est infrieur N P L et le nombre de lignes supplmentaires dans les tables est au total de L N . La contrepartie de cette solution est quil faut indiquer " la main" les routeurs susceptibles dtre concerns par le MED, ce qui entrane une certaine fragilit (erreur humaine). La solution pourrait consister ce que lorsquun routeur Ra apprend lexistence dun nouveau voisin E-BGP appartenant lAS x, il diuse linformation. Si un routeur Rb saperoit quil est directement reli au mme AS x, il enregistre quil faut activer lindicateur signalant limportance du MED et en informe en retour le routeur Ra initiateur de lannonce. La diusion consomme N paquets supplmentaires par nouvelle connexion BGP.

3.5.2

Dtecter les oscillations et les liminer

Pour dtecter les oscillations il est ncessaire de conserver un historique, gnralement gourmand en mmoire. T. Klockar propose une solution [TK03] base sur lutilisation dun historique et dans le cadre de lutilisation des recteurs de route. Le principe est fond sur le fait quil garde les anciennes annonces dans la table de routage mais en mode passif. Lorsquun routeur reoit une nouvelle route, il peut la comparer aux routes dites actives et aux anciennes dites passives mais son choix ne se fera que parmi les routes actives sinon il y aurait incohrence dans lAS. Cette technique lui permet de faire un meilleur choix car il a une meilleure vision des possibilits de chemins. Nous ajouterons que sil trouve une meilleure route, cest forcment parmi les chemins actifs (slectionns par les voisins) ; si 31

ce nest pas le cas alors il y a eu une panne dans le rseau. Cette stratgie semble intressante car elle nest pas trop gourmande en bande passante et en mmoire (seules les routes qui sont susceptibles dosciller sont enregistres). Mais elle nest applicable que dans le cadre des recteurs de route. En utilisant lexemple de rseau bas sur les confdrations de [DM02], on peut montrer que cette technique ne fonctionne pas dans le cas des confdrations.

3.5.3

Eviter les oscillations en modiant la topologie

Nous proposons de modier la topologie du rseau pour viter les oscillations dues au MED. Le problme vient du fait que les routeurs de bord nont pas assez dinformations pour prendre une "bonne dcision" parmi les chemins disponibles. Pour viter que ce cas narrive nous proposons de connecter deux deux les routeurs de bord qui sont connects aux mmes AS. Il est important de prciser que cette technique nimpose pas de modications physiques du rseau puisque nous intervenons sur la couche logique BGP. Les routeurs de bord connects au mme AS forment un graphe plein o chacun possde la mme information, donc chacun est en mesure de comparer les routes et tous les routeurs auront le mme meilleur chemin. Si une annonce provenant de lextrieur de cette clique ncessite une comparaison utilisant le MED, cest que lannonce provient obligatoirement dun autre routeur de cette clique. Comme ils ont tous le mme meilleur chemin, la nouvelle route est dj la meilleure. Ce qui entrane que la porte du MED est limite la clique. Donc si le MED est la seule source doscillation lintrieur dun AS, alors le rseau est stable. Nous proposons une deuxime solution inspire de la premire mais qui ncessite de modier lgrement le protocole puisque nous intgrons la notion de ltrage lintrieur de lAS. Le principe consiste ce que lorsquon ajoute un lien entre deux routeurs pour former une clique, on ltre les annonces pour que seules celles qui proviennent de lAS dont la clique est en charge circulent. Nous rduisons ainsi le nombre dentres dans les tables de BGP et limitons lutilisation excessive de la bande passante.

3.6

Conclusion

Nous avons prsent ici le premier cas doscillations dcouvert dans BGP. Ce problme peut tre rsolu par les direntes solutions proposes. Chacune delles a ses avantages et inconvnients : soit on consomme de la bande passante et de la mmoire, soit elles sont plus contraignantes vis vis des administrateurs et plus sensibles aux erreurs humaines. Il est ncessaire de faire un choix suivant les besoins rels.

32

Le problme du MED semble tre la seule source doscillation lintrieur dun AS, il serait intressant de le prouver mais pour cela il faut avant tout trouver un formalisme susant. Dautre part, la proposition faite par T. Klockar dans [TK03], base sur les historiques, semble intressante. Peut tre pouvons nous gnraliser cet algorithme toutes les topologies de rseaux et pas seulement aux recteurs de route.

33

34

Chapitre 4

Oscillations entre AS
Nous avons vu prcdemment des problmes dinstabilit internes aux systmes autonomes qui sont dus lutilisation du MED, mais BGP pourrait souffrir aussi dinstabilits entre les AS dues aux politiques dannonce des routes. Ces ltrages ne sont pas dnies dans le protocole BGP. Actuellement le rseau des AS reste trs hirarchique. Entre AS il peu y avoir deux types de relations, lune est de fournisseur client, lautre de pair pair. Un client paye un fournisseur pour faire transiter le trac, quant aux pairs ils schangent du trac gratuitement car ils ont un volume de donnes se transmettre peut prs quivalent. En rsum, BGP est form de plusieurs niveaux, chaque niveau le trac est chang librement. Si un AS X doit envoyer du trac un AS Y , ce trac remonte lAS Z, le plus proche parent dans la hirarchie de X et Y , et redescend Y . Le problme des oscillations entre AS na pas pour le moment t mis en vidence. Cela ne veut pas dire quil soit impossible ou inexistant. Mais si la taille de chacun des niveaux augmente signicativement, ou que le modle hirarchique disparat, ce problme pourrait apparatre comme une grave instabilit de BGP. Pour tudier ce problme, nous allons exposer quelques exemples dinstabilits donns par T. G. Grin qui a fait un travail important sur ce problme, ensuite nous donnerons la solution actuellement utilise dans Internet et nalement nous prsenterons lapproche de T. G. Grin pour tudier ce problme. Dans le chapitre suivant nous verrons notre modle pour ltude de ces oscillations.

4.1

Modle SPVP (Stable Path Vector Protocol)

Pour tudier le problme dinstabilit, T. G. Grin dnie le SPVP : chaque noeud reprsente un AS, et il leur associe la liste des chemins possibles suivant une prfrence dcroissante (les politiques ne sont pas indiques, seul le rsultat 35

lest). Tous les chemins indiqus ne sont pas forcment dans la table de routage ; par exemple si la route 230 est indique dans les chemins possibles, mais que 3 na pas pu annoncer 30, alors ce chemin nest pas utilis bien quil soit indiqu. LAS 0 est toujours le premier annonceur dune route, les ches nindiquent pas la direction des annonces mais la route choisie pour mettre des paquets vers un rseau se situant dans lAS 0. Ce modle est utilisable car lensemble des chemins possible peut tre concsidr comme stable. En eet les ltres dannonce permettant de slectionner les chemins est une conguration statique modi par un oprateur. On ne dcide pas dannoncer x plutt que y parce que y commence tre charg, sinon le rseau ne pourrait jamais converger vers un tat stable puisque la modication dune route peut avoir un impact important sur lensemble des AS.

4.2

Quelques exemples simples dinstabilits inter-AS

Pour commencer nous allons donner quelques exemples dinstabilit prsents par T. G. Grin dans [TGG02a]. Ces exemples sont bass sur son modle : Le premier exemple (g. 4.1) prsente un rseau dAS et les deux solutions possibles dassignation des routes. Ce nest pas proprement parler un problme dinstabilit, mais T.G. Grin le considre comme tel car pour lui un routage cohrent est un routage qui a une solution unique. Le deuxime exemple (g. 4.2) est plus intressant : il nexiste pas de solution ce problme. Cela se traduit dans la ralit par une oscillation constante entre trois tats : les routes {210, 10, 30}, les routes {130, 30, 20} et les routes {320, 20, 10}. Dautres solutions peuvent apparatre comme stables et devenir totalement instables si le rseau est trs lgrement modi. Cest le cas du Bad Backup prsent dans la gure 4.3. Il y a une solution unique (deuxime schma) mais si le lien 40 vient disparatre (une panne), la conguration revient celle du Bad Gadget prsent dans la gure 4.2.

4.3

Explication du problme

Ce problme dinstabilit entre AS vient du fait que des politiques dannonce peuvent ne pas tre en conit localement, mais ltre globalement. En dautres termes un mauvais choix dans les politiques peut tre indtectable par les AS, mais crer des conits entre plusieurs AS. Ces instabilits sont diciles rsoudre, tout dabord parce quil ny a pas ou peu de recommandations faites sur les politiques dannonce. Ensuite parce 36

Fig. 4.1 Le problme "Disagree"

Fig. 4.2 Le problme "Bad Gadget"

quil est dicile (du fait de la libert sur les politiques) dorir une formalisation et tudier les interactions entre elles. Finalement parce que la recherche dune mauvaise conguration dans le rseau est un problme NP-Complet. T. G. Grin a prsent dans [TGG00] une rduction 3-Sat de ce problme. 37

Fig. 4.3 Le problme "Bad Backup"

4.4

Un systme de pnalits "Route Flap Damping"

La solution utilise actuellement dans Internet, est le "Route Flap Damping" prsente dans le RFC 2439[CV98] et rsume dans[Sac01]. Elle consiste mettre des pnalits :

Lorsquune route est retire (parce quil y a un meilleur chemin) nous ajoutons un nombre de points de pnalit (P = P + X). Si la route a une pnalit suprieure une limite (P > L1), la route est masque et ne peut plus tre annonce. Si la pnalit retombe en dessous dune certaine limite (P < L2) la route est rtablie. Si la route descend en dessous dune troisime limite (P < L3), on oublie la pnalit. Si la route na pas oscill pendant un certain temps on enlve des points de pnalit (P = P/2).

Cette solution simple nest pas une bonne solution car elle ne fait que rduire la vitesse des oscillations et non les liminer. Dautre part elle ralentit considrablement la convergence du rseau. Faute de mieux, cest toujours celle utilise dans BGP. Il est noter que cette solution na pas t propos pour le problme du MED car elle entranerait des inconsistances au sein dun AS, cest dire quun AS ne serait plus vu de lextrieur comme un routeur unique. Finalement elle pourrait introduire des boucles. Donc seul les annonces E-BGP peuvent tre pnalises.

38

4.5

Le problme de stabilit de chemins

Nous allons prsenter dans cette section lapproche de T. G. Grin [TGG02b] qui a fait un travail important dans ltude des oscillations entre AS.

4.5.1

Modle

Une solution du "Stable Paths Problem" (SPP), est lassignation dun chemin permis tous les noeuds tel que : Lassignation dun chemin au noeud u est soit nulle, soit de la forme uwP et il existe un noeud voisin w tel que le chemin assign w soit wP . A chaque noeud est associ le meilleur chemin parmi ceux qui sont autoriss, dans le respect de la condition prcdente.

4.5.2

Graphe orient de conit

Lauteur propose deux approches similaires. Dans [TGG02b] il propose une mthode pour calculer les solutions au SPP. Sil y a zro ou plusieurs solutions, il considre le rseau comme instable. Sa deuxime approche prsente dans [TGG00] est de calculer un graphe de conit des assignements de chemins.

Construction du graphe de conit Chaque noeud du graphe de conit reprsente un chemin possible dans le rseau. Soit Q un chemin admis au noeud v et P un chemin admis au noeud u ayant pour premier noeud travers v (P = (u,v)P [v,0]). Ils existent deux types darcs entre les dirents chemins :

des arcs de transmission (not en pointill) des arcs de conit (not en trait plein) Il y a un arc de transmission de vP vers (u,v)P si u et v sont voisins. En dautre terme si au noeud u on a la route 130 et au noeud v la route 30, alors on met un arc de transmission de 30 vers 130. Il y a un arc de conit de Q vers P si le noeud v peut augmenter le rang de son meilleur chemin en abandonnant P[v,0] au prot de Q ce qui a pour eet de forcer u a abandonner P . En dautres termes, il y a conit si un chemin au noeud v peut forcer labandon dun chemin au noeud voisin u.

39

120 10

5120

10

20

30

230 20

410 430

410

120

230

430

5120

3
30

Fig. 4.4 Exemple de rseau avec son graphe de conit orient

La proprit principale de ce graphe est que sil ny a pas de cycle dans le graphe de conit, alors le rseau est stable. La gure 4.4 prsente un rseau et son graphe de conit, celui-ci ne contient pas de cycle, le rseau est donc stable. Cette proprit nest pas une condition ncessaire, linverse nest pas vrai. La gure 4.6 prsente un tel cas : le graphe de conit contient un cycle alors que le rseau est stable, en slectionnant les chemins 40, 140, 240 et 340. Cette gure est une extension de la gure 4.5 qui reprsente le cas dun rseau qui oscille.
130 10

1
10 210 20 20 30

210

320

130

3
320 30

Fig. 4.5 Exemple de graphe de conit avec cycle

4.5.3

Limitations et conclusion

Nous avons prsent cette solution car elle est la plus aboutie. Mais elle prsente nanmoins quelques dfauts : 40

140 130 10

10

20

30

40

240 210 20

210

320

130

140

240

340

40

3
340 320 30

Fig. 4.6 Exemple dun rseau stable et son graphe de conit avec cycle

Cette mthode ore des faux positifs, cest dire que certains rseaux sont considrs comme instables et non robustes alors quils le sont. le nombre de chemins possibles peut tre trs important et le graphe de conit contient autant de noeuds que de chemins donc il peut devenir rapidement incomprhensible et ingrable. Cette approche nore pas de mthode donnant les solutions possibles des assignations de chemins. Dans le chapitre suivant nous proposerons un modle pour palier ces limitations.

41

42

Chapitre 5

Graphe des sous-tats

Nous allons dans ce chapitre prsenter notre modle : "le graphe de soustats" (GSE). Cette approche permet, en se basant sur la modlisation SPVP de T. G. Grin, dorir une nouveau graphe de conit plus intuitif et surtout qui possde plus de proprits. Nous verrons deux types de graphes, lun utilise la notion de sous-tats minimaux, lautre de sous tats gnraliss.

5.1

Graphe des sous-tats minimaux

Ce graphe de conits dit graphe des sous-tats minimaux nest pas bas sur les conits entre chemins mais entre des tats du rseau. Par tat nous entendons un ensemble de chemin cohrent entre eux.

5.1.1

Dnitions

Nous allons commenc par une srie de dnitions utiles la construction du GSE. Dnition 1 (Sous-tat minimal) Un sous-tat minimal du rseau est un ensemble E de chemins inclus dans lensemble de chemins possibles du rseau U tel que x,y E, on ait x y et y x et z U \ E, tel que z x. avec indiquant lobligation de choisir le chemin. La dnition 1 revient dire que deux chemins x et y compatibles avec les politiques dannonce, sont dans le mme sous-tat du rseau si le fait de choisir le chemin x entrane lobligation de choisir y et vis versa. Dnition 2 (Sous-tats disjoints) Deux ensembles de sous-tats sont disjoints si lensemble des noeuds travers par les chemins de chacun des deux ensembles sont disjoints.

43

Dnition 3 (Sous-tats incompatibles) Deux sous-tats E1 et E2 sont dit incompatibles ssi x E1 et y E2 tel que x et y sont deux chemins possibles appartenant au mme noeud du rseau. La dnition 3 revient dire que deux chemins sont dit incompatibles si ils ne peuvent tre choisis simultanment car ils correspondent deux chemins possibles au mme noeud du rseau. Si deux chemins sont incompatibles, la dnition 1 implique que les deux sous-tats sont incompatibles entre eux. Dnition 4 (Sous-tats amis) Deux sous-tats E1 et E2 sont dit amis, ssi x E1 et y E2 , x et y peuvent tre choisi simultanment. La dnition 4 revient dire que deux sous-tats E1 et E2 sont amis si le fait de choisir les chemins de E1 ne perturbe pas la slection des chemins de E2 . Par exemple, E1 et E2 sont amis si lensemble des chemins de E1 passe par des noeuds dirents de lensemble des noeuds utiliss par les chemins de E2 . Dnition 5 (Sous-tats en conits) Deux sous-tats E1 et E2 sont dit en conits ssi x E1 tel que x peut interdire le choix dun chemin de y E2 . Proprit 1 Deux sous-tats minimaux E1 et E2 qui ne sont ni amis ni incompatibles sont forcment en conits. Dmonstration Dmonstration par labsurde : Soient deux sous-tats E1 et E2 . Si ils ne sont pas amis, alors il existe un chemin x appartenant E1 et y appartenant E2 tel que x et y aient un noeud en commun. Si ces deux sous-tats ne sont pas en conit alors quil ont un noeud en commun, cela veut dire que x et y sont slectionnable simultanment. Or un tel cas rentre dans la dnition des sous-tats amis.

5.1.2

Construction du graphe des sous-tats

Nous allons donner dans cette section la mthode de construction du sousgraphe des tats. La gure 5.1 reprsente le rseau sur lequel nous allons construire notre graphe de conit entre sous-tats.

Ecriture des sous-tats minimaux En utilisant la dnition 1, nous construisons les quatre sous-tats correspondant au rseau reprsent la gure 5.1. Ces sous-tats sont donn dans la gure 5.2.

44

120 10

5120

230 20

410 430

3
30
Fig. 5.1 Exemple de rseau

10 410

20 120 5120

30 230

430

Fig. 5.2 Les sous-tats minimaux du rseau

Par exemple les chemins 20, 120 et 5120 ont t regroups au sein du mme sous-tat car dune part le fait davoir le chemin 5120 implique que 120 et donc 20 aient t slectionns et dautre part si 20 est slectionn, 120 lest aussi puisque cest le meilleur chemin que puisse avoir le nud 1. Si on a 120, on a obligatoirement 5120 car le noeud 5 na pas dautres alternatives. Nous navons pas mis le chemin 430 dans le sous-tat {30, 230} car il est possible de slectionner 30 et ne pas choisir 430 car le nud 4 peut prfrer le chemin 410.

45

Recherche des sous-tats incompatibles Ltape suivante consiste indiquer les sous-tats incompatibles suivant la dnition 3. Par exemple les sous-tats {10, 410} et {430} sont incompatibles puisque le nud 4 ne peut choisir simultanment les chemins 410 et 430. Nous indiquons sur le graphe des sous-tats cette incompatibilit (gure 5.3) par une che en pointi (tiret) du sous-tat qui possde le chemin de prfrence plus faible vers celui de prfrence plus lev.

10 410

20 120 5120

30 230

430

Fig. 5.3 Les sous-tats incompatibles

Recherche des sous-tats disjoints amis Tous sous-tats disjoints sont par dnitions amis. Nous indiquons donc les sous-tat disjoints par une ligne en pointill (point). Dans notre exemple, les sous-tats {20, 120, 5120} et {430} utilisent respectivement les nuds {1, 2, 5} et {3, 4} ; ils sont disjoints donc amis. Il en est de mme avec {10, 410} et {30, 230}. La gure 5.4 prsente le rsultat de cette opration.

10 410

20 120 5120

30 230

430

Fig. 5.4 Les sous-tats disjoints amis

46

Recherche des sous-tats amis non disjoints Dautres sous-tats sont amis car le choix de lun ne perturbe pas ceux de lautre. Cest le cas entre {30, 230} et {430} (gure 5.5), en dautre terme il est possible de slectionner simultanment les chemins 30, 230 et 430.

10 410

20 120 5120

30 230

430

Fig. 5.5 Les autres sous-tats amis

Construction du sous graphe de conit Suivant la proprit 1, tous sous-tats qui ne sont ni amis ni incompatibles sont en conits. Nous ajoutons donc autant dartes que ncessaire pour obtenir un graphe plein. Ces artes correspondent aux conits. Nous orientons ensuite ces artes du sous-tat qui peut disparatre vers celui qui en prote. Certains tats incompatibles peuvent tre aussi en conits. Cette dernire proprit tant plus forte nous remplaons tous les tats incompatibles qui sont en conits par un conit. Nous lindiquons par une che allant du sous-tat qui peut disparatre vers celui qui en prote. Par exemple si les chemins 10 et 410 ont t choisi, si le nud 2 slectionne 20, alors le nud 1 slectionne 120 car cest un meilleur chemin. 120 a donc masqu 410, nous indiquons cette priorit par une che du sous-tat qui contient 410 vers le celui qui contient 120. La gure 5.6 prsente le graphe des sous-tats minimaux la n de sa construction. Le graphe modlis par les ches pleines est proprement parl le graphe de conit. Ce graphe peut non connexe.

47

10 410

20 120 5120

30 230

430

Fig. 5.6 Le sous graphe de conit

5.1.3

Proprits

Proprits immdiates Proprit 2 Soit deux sous-tats minimaux E1 et E2 . Si un chemin x E1 est en conit avec un chemin y E2 , alors tous les chemins de E1 sont en conit avec y.

Dmonstration Si le chemin x est en conit avec y, cela veut dire que x ne peut etre choisi si le chemin y a t slectionn. Or daprs la dnition 1 dun sous-tat minimal, si x E1 on a x x. Cela entrane que si x ne peut tre choisi x ne le peut pas non plus, donc x est aussi en conit avec y. Stabilit et solidit Thorme 1 (CS la stabilit) Soit G le graphe des sous-tats, G G le sous graphe des tats en conit. Si G ne contient pas de cycle, le rseau est stable.

Dmonstration Ide de dmonstration : Le graphe de conit indique lvolution du choix des chemins. Si le graphe des conits G ne contient pas de cycle, alors le sous-tat slectionn tendra vers un des puits du rseau. Ce sous tat donne un ensemble de chemin compatible. Thorme 2 Soit G le graphe des tats, G G le sous graphe des tats en conit, si G ne contient pas de cycle, la suppression de chemins dans G nintroduit pas de cycle dans G .

48

Dmonstration Prenons les cas un par un : Soit E1 et E2 deux sous-tats incompatibles. Si E1 et E2 sont amis, cela veut dire que pour tous chemins x appartenant E1 et y appartenant E2 , x et y sont amis, si on supprime un chemin lun des deux sous-tats, tous les chemins de E1 et E2 seront toujours amis. Donc les sous-tats E1 et E2 seront toujours amis. Si E1 et E2 sont incompatibles, et que lon supprime un chemin x de E1 ; si x tait en incompatibles avec un chemin y de E2 et quil ny avait pas dautres incompatibilits les sous-tats deviennent amis. Si x ntait pas en conit ou si il y avait plusieurs conits, E1 et E2 reste en conit. Il nest donc pas possible dajouter des conits en supprimant des chemins. Donc si le garphe de conit initial ne contenait pas de cycle, le fait de supprimer un chemin ne peut crer un cycle. Il est a not que si E1 et E2 sont deux sous-tats en conit, la suppression dun chemin peut laisser E1 et E2 en ltat ou le transformer en sous-tats incompatibles ou amis. Le thorme 2 introduit la sret dun rseau. Eectivement un rseau stable peut devenir instable en prsence de panes. Labsence de cycle dans le graphe entrane une grande rsistance au panne pour ce problmes des oscillatiions.

Cas des rseaux stables dont le graphe des conits possde un cycle La gure 5.7 prsente le cas dun rseau possdant un cycle ainsi que son graphe des sous-tats minimaux ou nous avons indiqu que les conits. Bien que le graphe des sous-tats contienne un cycle, ce rseau est stable si il ny a pas de pannes. En fait tout rseau possdant un cycle est stable en labsence de panes si il est possible de sortir du cycle. Dans notre exemple si on prend le sous-tat {210}, on prfrera aller au sous-tat {40, 140, 240, 340} plutt quau sous-tat {130} car le noeud 1 prfre le chemin 140 au chemin 130.

5.1.4

Recherche des solutions

Lintrt principal de cette modlisation est dorir directement les solutions possibles de lassignation des chemins dans le rseau. La solution nale doit contenir au plus un chemin par par noeud.

Recherche des puits dans le sous-graphe de conit Nous dcoupons le graphe des conits G (modlis par les ches) en sous graphes connexes G1 ,G2 ,...,Gn sans casser darc de conit. En dautres 49

140 130 10

210

320

130

240 210 20

40

40 140 240 340

3
340 320 30

10

20

30

Fig. 5.7 Exemple dun rseau stable et son graphe de conit avec cycle

termes si notre graphe de conit contenait deux sous-graphes non connects entre eux, nous obtiendrons deux graphe connexe. Un tat qui na pas de conit avec dautres tats est un graphe de conit avec un seul noeud. Nous recherchons les puits dans chaque graphe Gi ; un graphe avec un seul noeud est un puit. Lensemble des chemins contenus dans ces puits font parti de la solution.

La gure 5.8 donne le GSE du rseau prsent dans la gure 5.1. Il ny quun seul sous graphe de conit qui ne contient quun seul puit, nous lavons indiqu en gras. A ce stade lassignation des chemins est : Noeud 1: 2: 3: 4: chemin 230 30

Supression des sous-tats superus Ensuite nous gardons les tats amis des puits et supprimons les autres. Ces tats superus ne contiennent pas de chemin appartenant la solution, sinon ils auraient t amis de lun des puits. Dans la gure 5.9 nous supprimons ltat {20, 120, 5120}.

50

10 410

20 120 5120

30 230

430

Fig. 5.8 Recherche des puits dans le sous-graphe de conit

10 410

30 230

430

Fig. 5.9 Supression des sous-tats superus

Recherche des sous-tats de plus fort poids Le reste des chemins est chercher dans les sous-tats amis, mais nous pouvons y trouver plusieurs chemins pour un mme noeud. La solution consiste a rechercher les puits dans le graphe des incompatibilits. Nous utilisons les chemins pour continuer completer le tableau des assignations. Dans notre exemple il y a puit dans le graphe des incompatibilits, not en gras dans la gure 5.10. Notre table dassignation devient : Noeud chemin 1: 10 2: 230 3: 30 4: 410 Notre table est complete, elle reprsente une solution lassignation des chemins dans notre rseau.

51

10 410

30 230

430

Fig. 5.10 Recherche des sous-tats de plus fort poids

Recherche des solutions suivantes Si nous navons pas obtenu tous les chemins ncessaire, il faut supprimer les puits traits dans le graphe des incompatibilits et rechercher les nouveaux puits. Et ainsi de suite jusqu ce que la table des assignations de chemins soit complete. Si elle nest pas complete alors que nous avons parcouru tout le graphe, alors un noeud ne pourra pas joindre le noeud 0 ; ce nest pas un dfaut du modle mais une incohrence de BGP.

5.2

Graphe des sous-tats gnraliss

Le graphe des sous-tats minimaux prsente des proprits intressantes, mais ce graphe peut devenir trs vite immense. Nous allons donc proposer une solution pour rduire signicativement la taille de se graphe : le graphe des soustats gnraliss. Le principe consiste regrouper certains sous-tats similaires. Par exemple dans la gure 5.7 il serait intressant de regrouper {10} et {210}, {20} et {320}, {30} et {130}.

5.2.1

Les direntes rductions

La gure 5.11 prsente certaines rductions possibles. x, y, z reprsente des sous-tats, les liens sont les amis, incompatibilits et conits vu prcdemment et xy reprsente un seul sous tat contenant les chemins de x et de y. x est le noeud que nous cherchons intgrer. On suppose aussi que y contient un chemin obligatoire par lun des chemins de x, par exemple pour {10} et {410}, le chemin 10 est obligatoire pour avoir 410.

52

(1)

x z

xy

(2) x z (3) x z (4) x z (5) x y y y y

xy

xy

xy

xy
Fig. 5.11 Exemples de rductions

Ci-dessous une explication de chaque cas : Cas (1) si x est un puit donc une solution, y sera aussi selectionn donc il peuvent appartenir au mme sous tat. Cas (2) si z est incompatible avec y , comme y est obligatoire pour avoir x, x est incompatible avec z, donc x peut tre intgr y sans tre intgr z. Cas (3) est un extension du cas numro 1. Cas (4) est un cas similaire du cas 2. Si y et z sont en conit, x et z lz sont aussi. Cas (5) cest la mme cas que prcdemment. Exemples de rduction Nous allons donner un exemple de rduction bas sur le rseau et son graphe des sous-tats prsents dans la gure 5.7. Dans la gure 5.12 nous avons agrger les tats {10} et {210} car ils sont amis (cas 1), mais nous navons pas ajout 10 dans les tats : {20}, {320}, {30} et {130} car : {10} et {30} sont amis donc si {10, 210} est slectionn, {30} le sera aussi (cas 3). {210} et {20} taient incompatibles donc le chemin 10 est incompatible avec {20} (cas 3). {210} et {130} taient en conit donc le chemin 10 est en conit avec {130} (cas 4). 53

 {210} et {320} taient en conit donc le chemin 10 est en conit avec {320} (cas 5).

10 210

320

130

40 140 240 340

20

30

Fig. 5.12 Exemple dune rduction

5.2.2

Construction

Il est possible de crer directement le graphe des sous-tats gnraliss sans utiliser le GSE. Le principe de construction est exactement le mme que pour le graphe des sous-tats minimaux, seul change la construction des sous-tats.

Construction des sous-tats gnraliss Nous allons construire tape par tape le graphe de conit gnraliss pour le rseau prsent la gure 5.7. La premire tape consiste construire le noeud du graphe : les sous-tats gnraliss :

Il faut tout dabords regrouper les chemins qui sont lis. En dautres termes, si le chemin x est inclu dans le chemin y, ils appartiennent au mme sous-tat. Dans notre exemple 10 et 210 sont lis, on le met dans le mme tat. Lensemble des sous-tats est donn la gure 5.13. Si un des chemins dun sous-tat peut tre en conit avec un autre du rseau, nous le supprimons et le mettons dans un sous-tat part. nous agrgeons les tats E1 et E2 si le fait de slectionner ltat E1 entraine lobligation de slectionner ltat E2 et vice versa. Cette agrgation est similaire la construction des sous-tats minimaux. Dans notre exemple le fait de slectionner 40, contenu dans le sous-tat {40, 140} entrane lobligation davoir les chemins 240 et 340, nous agrgeons donc ces trois tats (gure 5.14). 54

 Nous verions que pour chaque tat et chaque chemin, on trouve aussi les sous-chemins dans cet tat. Par exemple si nous avions le chemin 5230 dans un tat, il faut vrier la prsence dans cet tat des chemins 230 et 30.

10 210

20 320

30 130

40 240

40 140

40 340

Fig. 5.13 Chemins lis

10 210

20 320

30 130

40 140 240 340

Fig. 5.14 Sous-tats gnraliss

Sous-tats amis, incompatibles et en conits Ensuite nous construisons le graphe des incompatibilits, des conits et des amis de faon identique la mthode utilise dans les graphe de sous-tats minimaux. La gure 5.15 reprsente le graphe nale des sous tats gnralis.

Rduction Le graphe que nous avons obtenu est minimal, il nest pas possible de le rduire, mais ce nest pas toujours le cas, mais il est toujours possible dappliquer les rgles de rduction sur ce graphe.

5.2.3

Proprits

Dans ce nouveau graphe nous conservons la proprit des cycles. En eet en agrgeant des sous-tats, nous navons ni supprim, ni ajout de liens de conits. 55

10 210

20 320

30 130

40 140 240 340

Fig. 5.15 Exemple de graphe des sous-tats gnraliss

Par contre nous perdons la possibilit de trouver simplement les direntes solutions de lassignation du rseau car en utilisant lagrgation de sous-tats nous avons ajout des chemins potentiellement incompatibles. Par exemple si nous avions x, y et y, z qui taient nous aurions agrg x et y, on aurait dont les deux tats xy et z. Dans le graphe des sous-tats minimaux, la slection de z nentranait pas la slection de x. Dans ce nouveau graphe, x et y ayant t agrg, la slection de z entane la slection de y.

Recherche de solutions Pour rechercher les solutions, nous slectionnons les puits dans le graphe de conit ainsi que les sous-tats amis. Nous obtenons un ensemble de chemin. Nous comparons deux deux les chemins pour un mme noeud (ie les chemins qui ont les mme premier noeud, par exemple, 530 et 560) et supprimons celui qui a la prfrence la moins leve.

5.3

conclusion

Nous avons propos deux modles pour tudier les instabilits entre AS. Ces reprsentations ont lavantage, par rapport celle propos par T. G. Grin, dtre plus intuitives et surtout de proposer dautres proprits telles que la recherche dune solution ou ltude de la stabilit dans le cas de graphe contenant un cycle.

56

Chapitre 6

Conclusion et perspectives
Aprs avoir expos les caractristiques de BGP, nous avons vu que des oscillations innies pouvaient apparatre lintrieur dun systme autonome et des instabilits entre AS. Ensuite nous avons propos un modle pour tudier ce dernier cas dinstabilit. Les oscillations internes lAS sont lies lutilisation de lattribut de route MULTI-EXIT-DISCRIMINATOR et lutilisation dun graphe non plein des annonceurs BGP dans un mme AS. Elles viennent du fait que dune part toutes les informations ncessaires la slection de la meilleure route ne sont pas toujours disponibles, dautre part que le classement des routes nest pas ordonn lexicalement. Nous avons aussi vu que des instabilits (dont des oscillations) pouvaient apparatre entre les AS sans lutilisation du MED. Ce problme vient du fait que des politiques dannonce qui localement ne sont pas en conit, peuvent ltre globalement. Dans le cadre des oscillations dues lutilisation du MED, nous proposons deux solutions : La premire consiste ajouter un attribut de route indiquant la porte dune annonce lintrieur dun AS. En dautres termes si une route risque dtre slectionne suivant le MED, lannonce de la route doit se propager dans la totalit de lAS et dans ce cas un indicateur est activ. Chaque routeur qui reoit une annonce avec cet indicateur activ, renvoie, sil ne la pas dj fait, lannonce tous ses voisins de lAS. Cette solution a lavantage de consommer le minimum de bande passante et de mmoire supplmentaire. La deuxime solution que nous proposons consiste modier la topologie logique du rseau BGP lintrieur dun AS pour que deux routeurs appartenant un mme AS et qui ont un lien E-BGP vers le mme AS voisin, soient directement connects (ont une session BGP ouverte) entre eux. Cela revient crer un graphe plein entre les routeurs concerns par le MED et donc chacun a toutes les informations ncessaires pour faire un bon choix. Cette technique a lavantage de ne pas modier le protocole BGP. Pour limiter la bande passante et la mmoire supplmentaire, nous 57

proposons une volution de cette technique qui consiste introduire le ltrage dannonce lintrieur dun AS tel que sil est ncessaire dajouter un lien BGP entre deux routeurs, seules les annonces concernes par le MED soient mises sur ce lien. Ces deux solutions ont lavantage dtre moins gourmandes en bande passante et mmoire que les algorithmes bass sur des historiques, mais en contrepartie elles sont plus sensibles aux erreurs de conguration (erreur humaine). Les perspectives immdiates relvent des oscillations internes aux AS et des instabilits entre AS. Pour les oscillations internes lAS, il faudrait approfondir lalgorithme de T. Klockar bas sur des historiques pour prendre en compte des topologies de rseaux quelconques. En eet cet algorithme est peu gourmand en nombre de messages et mmoire utilise car il ne conserve que trs peu dinformations dans son historique mais il ne sapplique quaux recteurs de routes ; il ne fonctionne pas sur des topologies comme celles utilises dans les confdrations. Pour les instabilits entre AS, le modle que nous proposons ore une base leurs tudes. Les perspectives immdiates interviennent directement sur le modle : Dans le cadre des sous-tats gnraliss, il faudrait approfondir la notion de rduction admissible pour essayer de trouver un cas gnral. Toujours dans les graphes des sous-tats gnraliss, il faudrait approfondir la recherche de solutions, par exemple en colorant le graphe. Il serait intressant de trouver un formalisme qui permet de dtecter immdiatement si en prsence dun cycle nous avons une chance ou non de sortir de ce cycle. Les perspectives plus long terme : Le modle des sous-tats permet dtudier la solidit dun rseau, cest dire quest ce quil faut enlever pour que le rseau devienne instable. Il serait intressant dintgrer directement au modle les politiques dannonce, ceux pour tudier les conits entre politiques et proposer des conditions sur les politiques les moins contraignantes possibles pour ne pas avoir de conit.

58

Annexe A

Lexique
AS cf. Systme autonome. Cot IGP cf. IGP EGP est le prdcesseur de BGP. Cest un protocole vecteur de distances permettant dchanger des informations de routage entre AS. E-BGP nom donn au protocole BGP lorsquil sagit dchanges de messages entre AS. I-BGP nom donn au protocole BGP lorsquil sagit dchanges de messages interne un AS. IGP nom gnrique donn aux protocoles internes un AS permettant de router au niveau des liens physiques. Ces protocoles sont gnralement bass sur une notion de distance appele cot IGP qui peut reprsenter le temps mis pour aller dun routeur un autre ou le nombre de routeurs traverss. MED (MULTI-EXIT-DISCRIMINATOR) est un attribut de route BGP permettant de discriminer un ou plusieurs liens lorsque deux AS sont multiconnects Systme autonome ensemble de routeurs sous une mme entit administrative.

59

60

Bibliographie
[CV98] R. Govindan C. Villamizar, R. Chandra. Bgp route ap damping. RFC, (2439), Novembre 1998. [DM02] D. Walton A. Retana D. McPherson, V. Gill. Border gateway protocol (bgp) persistent route oscillation condition. RFC, (3345), Aot 2002. [ECRI82] Bolt Beranek Eric C. Rosen and Newman Inc. Exterior gatway protocol (egp). RFC, (827), Octobre 1982. [Hui00] C. Huitema. Routing in the Internet. Prentice Hall, second edition, 2000. [KL89] Y. Rekhter K. Lougheed. Border gateway protocol (bgp). RFC, (1105), Juin 1989. [KL90] Y. Rekhter K. Lougheed. Border gateway protocol (bgp). RFC, (1163), Juin 1990. [KL91] Y. Rekhter K. Lougheed. Border gateway protocol 3 (bgp-3). RFC, (1267), Octobre 1991. [Man97] B. Manning. Registering new bgp attribute types. RFC, (2042), Janvier 1997. [Mil84] D.L. Mills. Exterior gateway protocol formal specication. RFC, (904), Avril 1984. [PT01] J. Scudder P. Traina, D. McPherson. Autonomous system confederations for bgp. RFC, (3065), Fvrier 2001. [Sac01] Luc Saccavini. Le routage bgp-4 - prsentation du protocole. Mars 2001. [TB00] E.Chen T. Bates, R. Chandra. Bgp route reection - an alternative to full mesh ibgp. RFC, (2796), Avril 2000. [TGG00] G. Wilfong T. G. Grin, F. B. Shepherd. The stable paths problem as a model of bgp routing. Septembre 2000. [TGG02a] G. Wilfong T. G. Grin. Analysis of the med oscillation problem in bgp. 2002. [TGG02b] G. Wilfong T. G. Grin, F. B. Shepherd. The stable paths problem and interdomain routing. IEE/ACM Transactions on Networking, 10, 2002. [TK03] L. Carr-Motychova T. Klockar. Preventing oscillation in i-bgp with route reectors. Dcembre 2003. 61

[YR94] [YR95]

Eds Y. Rekhter, T. Li. Border gateway protocol 4 (bgp-4). RFC, (1654), Juillet 1994. T. Li Y. Rekhter. Border gateway protocol 4 (bgp-4). RFC, (1771), Mars 1995.

62