Route Reflector en environnement CISCO
Le réflecteur de routes permet à tous les locuteurs IBGP de votre réseau autonome de connaître les routes disponibles sans introduire de boucles. Il est utilisé dans les réseaux BGP pour simplifier la gestion des routes au sein d'un système autonome (AS). Il permet de réduire le nombre de sessions BGP requises en reflétant les routes entre les clients BGP sans avoir besoin que chaque routeur soit connecté directement à tous les autres routeurs (ce qui serait le cas dans une architecture BGP full-mesh).
Ci-dessus, nous avons un réseau avec six routeurs IBGP. En utilisant la formule de maillage complet, nous pouvons calculer le nombre de peerings IBGP :
N(N-1)/2 où N représente le nombre de routeurs
6(6-1)/2 = 15 peerings IBGP
Ce qui veut dire que nous devons faire 15 configurations BGP pour établir une connexion BGP full-mesh.
Lorsque nous utilisons un réflecteur d’itinéraire, notre réseau pourrait ressembler à ceci :
Nous avons toujours six routeurs, mais chaque routeur n'a qu'un peering IBGP avec le réflecteur de route au-dessus. Lorsqu'une de ces routes IBGP annonce une route au réflecteur de route, elle sera « reflétée » sur tous les autres routeurs IBGP :
Mise en œuvre
Architecture 1 : Sans RR
Une archi BGP à maillage complet devrait ressembler à ceci :
Architecture 2 : Avec RR
Après toutes les gymnastiques de configurations IP et et du IGP, les Loopback devraient normalement communiquer :
Avantages : Sans le RR, chaque routeur ou PE devrait monter une session BGP et MP-BGP avec l'ensemble de ses semblables au sein du backbone et inversement. Ce qui entrainerait des tables de routage kilométriques et des configurations à ne pas finir.
Avec le RR, il monte une session BGP et MP-BGP avec chaque routeur ou PE, et chacun de ces derniers monte à son tour une session BGP et MP-BGP avec ledit RR. Trop cool, 😉 n'est-ce pas ?
Dans une architecture avec du MPLS - VPN, nous aurons besoin de configurer du MP-BGP entre les PE et le RR. Nous n'allons donc pas nous en priver…
Note : Notre ASN est 65000
Configuration identique pour tous les PE
router bgp 65000
bgp log-neighbor-changes
neighbor 5.5.5.5 remote-as 65000
neighbor 5.5.5.5 update-source Loopback0
!
address-family vpnv4
neighbor 5.5.5.5 activate
neighbor 5.5.5.5 send-community extended
exit-address-family
!
Configurations BGP & MP-BGP sur le RR vers tous les PE
router bgp 65000
bgp log-neighbor-changes
neighbor 1.1.1.1 remote-as 65000
neighbor 1.1.1.1 route-reflector-client
neighbor 1.1.1.1 update-source Loopback0
!
neighbor 2.2.2.2 remote-as 65000
neighbor 2.2.2.2 route-reflector-client
neighbor 2.2.2.2 update-source Loopback0
!
neighbor 3.3.3.3 remote-as 65000
neighbor 3.3.3.3 route-reflector-client
neighbor 3.3.3.3 update-source Loopback0
!
neighbor 4.4.4.4 remote-as 65000
neighbor 4.4.4.4 route-reflector-client
neighbor 4.4.4.4 update-source Loopback0
!
address-family vpnv4 unicast
neighbor 1.1.1.1 activate
neighbor 1.1.1.1 route-reflector-client
neighbor 1.1.1.1 send-community extended
!
neighbor 2.2.2.2 activate
neighbor 2.2.2.2 route-reflector-client
neighbor 2.2.2.2 send-community extended
!
neighbor 3.3.3.3 activate
neighbor 3.3.3.3 route-reflector-client
neighbor 3.3.3.3 send-community extended
!
neighbor 4.4.4.4 activate
neighbor 4.4.4.4 route-reflector-client
neighbor 4.4.4.4 send-community extended
exit-address-family
!
Après avoir chargé les configs sur le RR
L'état BGP sur le RR
Test du réflecteur de routes
Nous allons annoncer un préfixe sur PE1 et voir si tous les autres PE recevront ce préfixe.
Sur le PE1, nous allons créer un préfixe et l'annoncer dans BGP
!
interface Loopback10
ip address 172.16.1.1 255.255.255.255
end
!
router bgp 65000
bgp log-neighbor-changes
network 172.16.1.1 mask 255.255.255.255
!
Voyons si le préfixe a été annoncé sur le PE2
Sur le PE3
Sur le PE4
Le RR ne va pas se priver de garder une copie de la route annoncée
Un aperçu des préfixes BGP annoncés et reçus
Ce dernier est accessible par tous les PE
Si nous annoncions des route via VPNv4, elles serait également visibles par tous les PE.
C'est inimaginable de déployer un réseau de transport IP/MPLS sans avoir au moins un RR opérationnel !!!