BGP et redistribution

Posted by – April 13, 2014

Ici on va mettre en place une topologie basee sur 3 reseaux interconnectes.

Un premier reseau fera de l’ospf, le second de l’eigrp et le dernier du RIP.

 

L’idee sera de jouer sur de la redistribution bgp / ospf principalement.

Chaque routeur aura une loopback de type 150.0.x.x avec x le numero du routeur.

A la fin de l’article sont presents le fichier .net pour gns3 et la configuration finale

 Voice le schema l2:

base-l2

 

 

La configuration de base ip est celle-ci:

base-l3

 

 

Voici les configurations de base L3

On peut regarder comment la redistribution des loopback est faite, sur R5:

Il s’agit donc d’une redistribution classique a ceci pres que je passe par une route-map REDISTRIBUTE-CONNECTED.

Dans ce cas precis cette route-map ne sert a rien, car il n’y a qu’une seule loopback et le reste est deja present dans eigrp via les network, mais il faut prendre l’habitude de vouloir tout maitriser, or si jamais j’ajoutais une seconde loopback je n’ai pas forcement envie de la redistribuer.

Donc je fais en sorte de maitriser ce que j’injecte dans EIGRP.

On peut regarder au niveau ospf, la configuration est sensiblement la meme.

Sur R1

Le permit 10 correspond a l’interface 150.0.1.1 et le set metric-type type-1 permettra d’afficher la route dans OSPF avec un E1. La metric est calcule avec la metric du reseau distant plus la metric pour joindre ce reseau. Ici ce n’est pas vraiment utile, c’est juste pour montrer qu’on peut le faire ainsi.

Les routes E1 sont preferees aux routes E2 car plus precises (la metric totale est refletee).

Le permit 20 correspond au subnet que je simule, 50.0.0.0/24

Et enfin pour RIP

Sur R10

A ce moment la j’ai pour chaque “reseau” (EIGRP, OSPF et RIP) un connectivite totale.

EIGRP sera comme un reseau de transit – dit dorsal – tout ce qu’il fera sera de faire transiter les routes bgp, qui seront principalement les 8 loopbacks de R10 et le subnet de R1.

Evidemment avec bgp, les liens iBGP doivent etre full mesh, il faudrait donc beaucoup de configuration pour chaque routeur du reseau dorsal, on va donc trouver une solution.

Le choix ici se porte sur l’utilisation de route reflectors (on aurait pu utiliser les confederations egalement).

Voila a quoi ressemble la configuration attendue

base-bgp

Commencons par regarder la configuration bgp sur R10

Le seul interet de RIP ici est de faire connaitre l’adresse loopback de R9 a R10.

La configuration – meme si BGP – est quasiment la meme que pour n’importe quel autre protocole qui fait de la redistribution.

Sur R9 on retrouve une configuration similaire avec une liaison eBGP supplementaire vers R6

Rien de bien complique. A ce niveau la on a connaissance des loopbacks de R10 via bgp

On voit devant chacune de nos routes un r qui correspond a un rib-failure, on peut en savoir plus via la commande

On regarde dans la table de routage ce qui est installe:

Les routes iBGP ont une distance administrative de 200 alors que les routes RIP ont une AD de 120.

C’est donc RIP qui est installe dans la table de routage, d’ou le rib-failure.

Ce n’est pas en soi un probleme mais on a mis en place une lisaison iBGP entre R9 et R10, ce serait donc mieux de voir la route BGP dans la table de routage plutot que la route RIP. De plus on n’a pas envie de redistribuer dans BGP le network 150.0.10.10.

Il suffit d’aller sur R10 et de supprimer la redistribution des loopback vers RIP

Sur R10

Mais au bout d’un moment la liaison bgp tombe

C’est tout simplement du au fait que les liaisons bgp sont montees via les interfaces loopback 0.

Or on vient de supprimer l’injection de toutes les loopback dans RIP, il suffit de laisser la loopback 0 dans l’injection vers RIP

On part donc de cette config sur R10

Que l’on modifie ainsi

On cree une deuxieme route-map

et on supprime le permit 20 de la premiere route-map

Puis on va modifier nos 2 protocoles et leur redistribution

 

Si on verifie maintenant sur R9

 

Voyons maintenant la configuration des routes reflector.

Ici on aura un routeur qui recevra toutes les connexions ibgp (ce sera le seul routeur connecte a tous les autres.) il s’agit de R7

Voila pour sa configuration:

On cree d’abord un peer-group (non obligatoire pour la configuration d’un RR) qui va nous permettre de faire moins de conf. Toutes les conf du peer-group seront repliquees a chaque membre du peer group.

Ce qui est important ici c’est

On va ensuite appliquer a chaque routeur iBGP qu’il est membre de ce peer-group, exemple pour R4

neighbor 150.0.4.4 peer-group RR-PeerGroup

Ensuite regardons la conf d’un des routeurs du reseau dorsal, R5 par exemple:

Il s’agit de la meme configuration qu’on retrouvera sur tous les routeurs du reseau dorsal (exception des routeurs avec des liaisons eBGP qui auront les neighbors eBGP en plus)

Rien de plus simple !

En production on preferera avoir 2 RR, il suffira de faire une lisaison iBGP classique entre eux 2, et d’ajouter une lisaison iBGP supplementaire sur tous les clients !

Il ne reste plus qu’a voir comment faire la redistribution BGP->OSPF sur R2 et R3 pour faire en sorte de sortir par R2 pour le reseau 30.0.0.0/8 et par R3 pour 40.0.0.0/8

De plus la seule liaison iBGP dans le reseau OSPF sera entre R2 et R3. R1 sera exclu de BGP, il ne parlera avec R2 et R3 que par OSPF

Voyons pour commencer la redistribution dans ospf (et vice versa pour le reseau 50.0.0.0/24)

La redistribution se fera sur 2 routeurs, R2 et R3.

Voyons R2

D’abord on va choisir les reseaux que l’on souhaite redistribuer dans OSPF.

On souhaite redistribuer les loopback en 30.0.0.0 et 40.0.0.0 provenant de R10.

On cree donc pour commencer 2 prefix-list pour matcher exactement ces network qui sont des /16

Ces 2 prefix-list signifie qu’on souhaite accepter pour la redistribution tous les network qui commencent par 30. et 40. (via 30.0.0.0/8 et 40.0.0.0/8)

Il est egalement preciser qu’outre le premier octet, on voudra des mask qui soient plus grand ou egaux a 16, et plus petits ou egaux a 16, en l’occurence on n’acceptera que les /16.

Maintenant on va placer ces prefix-list dans une route-map.

Je pourrais placer les match dans le meme permit (par exemple le 10) mais on modifiera tout a l’heure ces routes-map pour repondre a la problematique du depart qui veut que l’on passe par R2 ou R3 selon la destination. Sinon on refuse tous les autres subnets (150.0.x.x).

Maintenant on va redistribuer dans ospf bgp, via la route-map pour selectionner les network que l’on souhaite injecter.

On va faire la meme configuration sur R3, on obtient donc maintenant sur R1

 

A ce moment la nous n’avons aucune preference pour joindre les reseaux provenant de R10 depuis R1. La metric est de 1 pour tous les reseaux

Au moment de la redistribution sur R2 et R3 on va modifier la metric pour faire en sorte de passer par R2 pour joindre 30.0.0.0/8 et par R3 pour joindre 40.0.0.0/8

Sur R2

Sur R3

Ce qui donne

R2

 

R3

Si on verifie la table de routage de R1 maintenant

 

On utilise bien l’un ou l’autre des routeurs selon la destination.

Il ne reste plus qu’a redistribuer le subnet 50.0.0.0/24 dans bgp depuis R2 et R3 pour avoir une connectivite totale.

Sur R2 et R3

Maintenant sur R10 (ou sur n’importe quel autre routeur sur le chemin)

Si on test la connectivite

 

Un traceroute

La conf finale est baseBGP

Le fichier de conf GNS3 est filtrage-bgp.net

D’autres articles se basant sur cette configuration suivront…

2 Comments on BGP et redistribution

  1. […] Dans le post precedent je presentais une configuration. […]

  2. […] configuration de RR, on l’a vue dans l’article BGP et Redistribution Ce sera la meme chose 4 fois ! Pour la table de routage bgp globale, puis pour les 3 VRF PAIR, […]

Leave a Reply

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