MP-BGP Reseau redondant – Part3/3

Posted by – May 13, 2014

Partie 1 : Mise en place de la configuration IP basique

Partie 2 : Configuration (i|e)BGP

Dans cette troisieme et derniere partie, je vais expliquer en detail les choix retenus pour l’architecture en terme de flux IP. On souhaite avoir un routage symetrique et robuste, mais comme un schema sera plus parlant:

 

Je vais egalement vous remontrer le schema des AS avec les routeurs se faisant face:

layer-bgp-easy3

 

Le principe des flux est simple.

En fonctionnement normal:

Depuis CEA1 dans la vrf PAIR, si je cherche a joindre la vrf IMPAIR de CEA1, mon flux va remonter vers FWA pour faire le routage, puis redescendre sur CEA1 dans la vrf IMPAIR (et vice et versa)

Depuis CEA1 dans la vrf PAIR si je cherche a joindre la vrf PAIR sur CEB1, mon flux va rester dans le core Network de la vrf PAIR, pour joindre directement CEB1

Depuis CEA1 dans la vrf PAIR, si je cherche a joindre la vrf IMPAIR dans CEB1, mon flux va remonter sur FWA, puis via la vrf CONNECT aller dans FWB, et enfin redescendre dans la vrf IMPAIR vers CEB1. Le flux retour suivra l’exact chemin inverse.

Depuis CEA1 pour joindre internet on passera par FWA puis InetA

Depuis CEB1 pour joindre internet on passera par FWB puis InetB

Illustre cela nous donne ca:

Par symetrie (par souci de lisibilite je ne l’ai pas precise sur ce schema) les flux en provenance de CEB1 suivront le meme schema.

 

Voyons maintenant comment configurer tout cela sur les routeurs. La partie reseau de management ne sera pas modifiee, elle restera telle que configuree dans la partie 2.

CEA1

Pour chacune des vrf on veut redistribuer uniquement la loopback correspondant a notre vrf

 

La configuration est identique sur CEB1.

Sur PE3 P4 et PE5 pas de changement a noter.

PE1

Plusieurs point importants pour PE1. Premierement on va placer un local_pref a 140 pour la connexion a PE3, tout simplement via un route-map

On va pour les 2 vrf PAIR et IMPAIR placer un weight a 32 000 pour les subnets appris depuis FWA via un route-map encore une fois.

On veut egalement reguler ce qu’on souhaite envoyer a FWA depuis les vrf PAIR et IMPAIR, on commencer par creer 2 prefix-list qui vont matcher les subnets venant de CEA1 et de CEB1

On va ensuite creer un route-map qu’on appliquera pour ces 2 vrf au neighbor sur FWA

Alors pourquoi appliquer un AS_Prepend?

Pour rappel on souhaite que les flux inter site(A et B) et inter vrf (PAIR et IMPAIR) repassent par les FW et transitent via la vrf CONNECT.

Si on se place sur CONNECT prenons l’exemple de 172.16.2.0/24 qui appartient a CEB1

Il va d’abord arriver dans la vrf PAIR, son AS_Path est donc a ce moment la

vrf PAIR : 172.16.2.0/24 {64501}

Ensuite ce subnet va etre appris par FWB et FWA ce qui donnera:

FWA

FWB

Puis ces 2 equipements enverrons cette route chacun dans la vrf CONNECT de l’AS 65300

vrf CONNECT (AS65300)

De FWA

De FWB

Avant toute chose on s’apercoit que dans l’AS_Path, l’AS 65300 est deja present (forcement vu notre architecture) on n’oubliera donc pas d’ajouter le parametre allow-as in au niveau de nos neighbor.

Ce qui veut dire que quand la route venant de FWB arrive finalement a FWA, son AS_Path est

FWA (depuis FWB via vrf CONNECT)

Or cette route il la connait deja, puisque la vrf PAIR lui a deja envoye avec comme AS_Path

Dans ce cas present notre paquet ne transitera jamais par la vrf CONNECT, puisqu’il connait un chemin avec un AS_Path plus court.

Donc quand on envoit nos routes de CEB1 vers FWA depuis PE1, on ajoute 3 fois l’AS 65300, on se retrouvera donc avec:

Sur FWA

Par ce biais on est sur de forcer notre traffic via la vrf CONNECT

Un resume des commandes a passer sur PE1 est donc

Sur FWA voyons ce que l’on recoit

 

Par symetrie, la configuration de PE2 sera

L’explication des AS_Path est egalement precisee dans le tout premier schema de cet article.

Maintenant regardons FWA.

Un des points important de FWA est la ‘reglementation’ de la redistribution, on souhaite envoyer dans vrf PAIR et IMPAIR de l’AS 65300 uniquement la route par defaut apprise de InetA et un supernet qui correspond au subnet regroupant CEA1 et CEB1, soit 172.16.0.0/22.

Pour ce faire on va devoir generer cette route que j’appelerai SUPERNET localement sur le routeur, tout simplement avec une route statique qui pointe vers l’interface null 0. On redistribue ensuite cette route connectee dans bgp.

Le tout sera gere par une route-map. On n’oubliera pas d’ajouter le allow-as in, qui ici sera utile dans le cas ou un probleme arriverait et qu’on doive utiliser vrf CONNECT pour joindre la vrf PAIR par exemple (dans le cas ou le lien vers la vrf PAIR tombe sur FWA, on pourra toujours joindre cette vrf via FWB en transitant par la vrf CONNECT.

Sur FWB

C’est parti pour les traceroutes maintenant

On voit donc que le chemin voulu est bien respecte.

Je vais vous faire grace de tous les memes tests depuis CEB1, mais le routage est parfaitement symetrique, par ex:

Donc ici depuis la vrf PAIR sur CEB1, quand je cherche a joindre la vrf IMPAIR de CEA1, je repasse bien par FWB, puis via la vrf CONNECT j’arrive sur FWA, qui me redirige ensuite vers la vrf IMPAIR sur PE1 puis PE3 et enfin CEA1

 

Important de noter que la seule route par defaut connue de FWA est celle apprise par InetA, la route par defaut venant de FWB n’est pas apprise.

En effet PE1 dans la vrf CONNECT connait lui les 2 routes par defaut, mais ne va pas envoyer celle apprise par FWB a FWA  tant que FWA lui envoie une route par defaut, il s’agit d’un mechanisme de protection de bgp (assez logique, pour eviter les boucles).

Ainsi quand FWA va perdre sa route par defaut pour quelle que raison que ce soit (InetA tombe par exemple), il va automatiquement et via la vrf CONNECT apprendre la 2eme route par defaut du reseau qui vient de FWB, et l’acces a internet sera preserve.

Ce qui est interessant avec cette architecture ce qu’a peu pres tous les cas de figure sont geres.

Exemple si je perds totalement FWA, via bgp je vais toujours pouvoir joindre CEB1 ou internet en passant directement par FWB

En fonctionnement normal voila ce que PE1 envoie a FWA, pour la vrf CONNECT:

A noter que l’AS prepend ne s’affiche pas a cet endroit, il faudrait regarder les received-route sur FWA (voir plus haut) 

Maintenant je vais couper la route par defaut qui vient de InetA

Je relance bgp et je regarde les routes envoyees a FWA a nouveau

Maintenant je connais toujours une route par defaut, mais cette fois elle vient de FWB !

Avant la coupure de InetA:

Apres la coupure de InetA:

Il peut etre interessant de noter que le flux de retour est totalement symetrique:

Ce qui donne schematiquement

 

Autre cas de figure.

Petit rappel du flux CEA1 IMPAIR vers CEB1 PAIR:

BigData-OK-CEA1

je perds la liaison de PE1 vers FWA dans la vrf IMPAIR 

mon chemin pour joindre disons la vrf PAIR de CEB1, depuis la vrf IMPAIR, passera directement par FWB

Schematise cela nous donne:

BigData-NOK-CEA1

Par contre depuis la vrf PAIR de CEA1 pour joindre la vrf IMPAIR de CEB1, tout reste inchange, on passe bien par FWA puis FWB

Article TREEEEEES (trop?) long, bravo si vous etes arrives au bout.

Vous pouvez trouver les config terminales juste en dessous, ainsi que le fichier .net gns3…

config-BigData

 

Edit: tout ce lab n’est pas un lab MP-BGP…

Quand je relis ce que j’ai écrit par le passe je me dis qu’on doit encore et toujours apprendre… 🙂

Pas de vpnv4 ici.

Bientot je posterai un vrai setup MP-BGP.

11 Comments on MP-BGP Reseau redondant – Part3/3

  1. […] suite dans la partie 3 – mp-bgp reseau redondant part3/3 – on va veritablement jouer avec les routes BGP pour avoir un routage symetrique et une […]

  2. […] Et dans MP-BGP Reseau Redondant – Part 3/3 […]

  3. Nicolas Michel says:

    Good job 🙂

    Nicolas

  4. Baptiste says:

    Merci pour tout ces articles très intéressant et pertinent !
    En espérant pouvoir en lire d’autres !! 🙂

  5. Florent says:

    C’est gentil !
    Je suis pas mal pris par mes revisions mais des que j’aurai un peu plus de temps je m’y remettrai, j’ai pas mal de notes de cotes.

  6. Baptiste says:

    Bonne nouvelle !!
    En toute indiscrétion, ou en es tu dans ton parcours ? Les sujets abordés ici ne sont même pas nécessairement présent dans une ccnp ^^
    Bon courage et bonne fêtes.

  7. Florent says:

    Je suis CCDA / CCNA secu /CCNP. J’ai passe l’ecrit pour la CCIE RS et je tente le lab l’annee prochaine. Je suis consultant reseau. Je fais egalement beaucoup de F5 (LTM et GTM) dernierement.
    Alex qui ecrit egalement sur ce site/blog a a peu pres le meme parcours que moi.

    Tu fais quoi toi ?

    Bonnes fetes !

  8. Baptiste says:

    Bonjour,

    Pardon pour le temps de réponse, période chargée et tête en l’air…

    Niveau parcours, je suis en fin de cycle d’étude bac +5, j’ai obtenu ma CCNA R&S et je me promène sur la toile pour approfondir différents sujets et espérer réussir à passer une CCNP R&S et une CCNA Secu maintenant il me reste du travail.
    Si tu as l’occasion de présenter par des articles un peu le fonctionnement des répartiteurs de charges, je suis preneur.

    Je profite de mon retard pour te souhaiter la bonne année !

  9. Baptiste says:

    Petit rajout : Félicitations pour la réussite de ces certifications et m***e pour lab de la CCIE.
    Des échos que j’avais eu sur la CCIE elle est extrémement compliquée, je suppose que les “révisions” prennent énormément de temps !

  10. Florent says:

    Merci !
    Pour les F5, j’ai prevu de me lancer dans la redaction d’articles apres en avoir termine avec Cisco, dans quelques mois j’espere.
    Pour les revisions oui, c’est TRES prenant.

Leave a Reply

Your email address will not be published. Required fields are marked *