Route Reflector en environnement CISCO

BORY DIALLO

04 sept. 2024

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 n'établisse une session iBGP avec l'ensemble des routeurs de l'AS (ce qui serait le cas dans une architecture BGP full-mesh).

Ci-dessus, nous avons un AS composé de 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 logiquement à 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 routeurs annonce une route au réflecteur de route, elle sera « refléchie » sur tous les autres routeurs iBGP :

Un article similaire est disponible ici, mais environnement Huawei

Mise en œuvre

Architecture 1 : Sans RR

Une archi BGP à maillage complet devrait ressembler à ceci :

Chacun établirait une session BGP full-mesh avec l'ensemble des routeurs de l'AS

Architecture 2 : Avec RR

Après toutes les gymnastiques de configurations IP et du IGP, les Loopback devraient normalement communiquer :

Rappel : 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.

En présence du RR, ce dernier monte une session BGP et MP-BGP full-mesh avec chaque routeur ou PE, et chacun de ces derniers fait de même. 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
!