Border Gateway Protocol

Les protocoles de routage peuvent être définis en 2 catégories: IGP et EGP
IGP (Interior Gateway Protocol) sont les protocoles de routage qui échangent des informations au sein d'un Autonomous System. Les principaux protocoles de type IGP sont: RIP, IGRP, EIGRP, OSPF.
EGP (Exteror Gateway Protocol) sont des protocoles de routage qui servent à conecter (échanger des information de routage entre) 2 AS.
BGP-4 est un EGP définit au travers de la RFC 1771.
Le rôle de BGP est d'annoncer les routes.
D'un point de vue de BGP, les AS apparaisssent aux autres AS comme possédant un plan d'adressage interne cohérant et qui se présente sous forme d'une entité qui peut être utilisée pour joindre d'autres destinations.
Le rôle de BGP n'est pas de jouer avec les métriques mais d'annoncer les routes et de s'assurer qu'il n'existe pas de boucles de routage entre les AS.
BGP est le successeur d'EGP. Il est utilisé par les ISPs entre eux ou dans certains cas pour connecter de gros clients aux ISPs.

Protocol

Interior or Exterioir

DV or LS

Hierarchy Required

Metric

OSPF

Interior

LS

Yes

Cost

EIGRP

Interior

Advanced DV

No

Composite

BGP

Exterior

Advanced DV

No

Path vectors or attributes

LS pour Link State
DV pour Distance Vector
OSPF utilise le cost basé su la bandwidth en tant que métrique.
EIGRP utilise un métrique composé basé essentiellement sur la bandwidth.
les routeurs qui utilkisent BGP s'échangent des informations d'accessibilité de réseau appelé path vector ou attributes, qui inclue une liste complète de path (BGP AS numbers).
BGP est plus approprié quand l'une des conditions suivantes existe:

BGP, s'il n'est pas contrôlé et filtré proprement, a le potentiel de permettre à un AS extérieur d'affecter les décisions de routage locales.
Un routeur BGP connecté à Internet dispose d'une table de routage supérieure à 30MB, décrit plus de 70000 routes et renseigne plus de 6500 ASs.

Il est des situations où BGP n'est pas approprié:

Dans ces cas il convient d'utiliser des routes statiques pour interconnecter les différents AS.
router(config)# ip route prefix mask {address |interface} [distance] -->crée une route statique,peut établir une route flotante.
Une route flotante est une route qui dispose d'une administrative distance plus grande que la route issue du protocole de routage. Ainsi ce type de route sera employée quand la route primaire tombe, on cré un "path of last resort".

exemples:
RIP:
    ip route 0.0.0.0 0.0.0.0 S0
    !
    router rip
        network 172.16.0.0

 OSPF: la configuration par défaut d'OSPF utilisant une route statique:
    ip route 0.0.0.0 0.0.0.0 S0
    !
    router spf 111
         network 172.16.0.0 0.0.255.255 area0
        default-information originate always

1.            Les caractéristiques de BGP

BGP est un rpotocole de type distance vector avec des améliorations:

Du fait que BGP utilise directement TCP, il n'a pas besoin de mécanisme de retranssmission d'erreurs en utilisant directemnt les mécanismes TCP. 2 routeurs qui utilisent BGP ouvrent une connexion TCP et échangent des messages d'ouverture et de confirmation de conexions. Ces 2 routeurs se nomment des peer routers ou neighbors.
Une fois la connexion établie, l'échange des tables de routage peut avoir lieu. L'échange des tables de rouage se fait sur base de mises à jour, updates incremetal. Les updates périodiques ne sont pas nécessaires sur une connexion établie et maintenue. Cependant des triggered updates sont utilisés qui sont à assimiler aux hellos packets envoyés par certains protocoles.
Les routeurs BGP s'échangent des informations d'accessibilité que l'on nomme path vectors formés à base de path attributes et qui incluse une liste complète de chemins de BGP As numbers qu'une route peut prendre pour se rendre à destination. Ces informations de path sont utilisées pour construire un graph d'autonomous systems sans boucles et surlesquels des policy de routage peuvent s'appliquer.
Les path sont loop-free parcq'un routeur ne peut accepter d'updates de routage qui iclue son propre AS.
Il est à noter que sous BGP le voisin n'est plus forcément le next hop, mais celui qui arrive à ouvrir une session TCP.

BGP comporte 2 tables:

Les informations peuvent être échangées entre les 2 tables
Quand les neighbors se trouvent dans le même AS , on parle d'internal BGP: IBGP
Quand les neighbors se trouvent dans des AS différents , on parle d'external BGP: EBGP

1.1.        Policy based routing

BGP permet aux administrateurs de définir des policies, ou des rôles quant à la façon que les datas peuvent traverser un AS.
BGP et les outils associés ne peut satisfaire toutes les polices (stratégies) de routage
BGP ne permet pas un AS d'envoyer du trafic à un AS voisin, à condition que le trafic prenne une route différente que celle que le trafic à utiliser à partir de l'AS voisin (maîtrise du chemin des datas).
Cependant, BGP supporte toutes les polices conformément au paradigm hop-by-hop routing applicable donc en tant qu'inter-As routing (on peut influencer les routeurs directement connectés)

1.2.        Les attributs BGP

Les BGP métriques BGP sont appelés attributs.
Les updates que les roueurs envoient à propos des réseaux de destination, incluent des attributs.
Un attribut peut être à la fois well-known ou optionnel, obligatoire ou discret, transitif ou intransitif et peut être aussi partiel.
Toutes les combinaisons  de formes d'attributs ne sont pas valides. En fait les attributs de path tombent dans 4 catégories séparées:

Seuls les attributs tarnsitifs peuvent être marqués comme partiels.

1.3.        Les attributs well-known

Les attributs well-known:
Ces attributs doivent être reconnus par toutes les implantations de BGP et sont propagés sur les voisins (neighbors).
Les attributs well-known mandatory:
Ils doivent être présents dans tous les messages.
Les attributs well-known discrets:
Ils peuvent être présents dans tous les messages.

1.4.        Les attributs optionnels

Les attributs optionels:
Ils sont reconnus par certaines implémentations et sont attendues pur ne pas être reconnus par l'ensemble des implémentations.
Les attributs optionels reconnus sont propagés aux autres neighbors sur base de laur signification.
Les attributs optionnels transitifs:
Si ils ne sont pas reconnus, ils sont marqués comme partiel et sont propagés aux autres neighbors.
Les attributs nontransitifs optionnels:
Ils sont détruits si ils ne sont pas reconnus.

2.            Les principaux attributs BGP

Les attributs BGP incluent des attributs Well-known mandatory:

Welll-known discretionary attributes:

Optional transitive attributes:

Optional nontransitive attribute:

2.1.        AS-Path

Attribut du type Well-known mandatory. Il s'agit de la liste des As à traverser pour atteindre la destination.
Dans l'exemple ci-dessus si on veut se rendre deouis le router B sur le routeur A il faut passer par le routeur C. D'un point de vue de BGP, il faut emprunter l'AS 65500 et l'AS 64520 depuis l'AS 65000.

2.2.        Next-Hop

Cet attribut est du type well-known mandatory et indique le next-hop address à utiliser pour joindre une destination.
Pour EBGP le next-hop est l'adresse IP du neighbor qui envoie les updates. DAns notre exemple ci-dessus Le routeur A avertira le routeur B que le réseau172.16.0.0 de l'AS 64520 est jpoignable par 10.10.10.3.

Pour IBGP le protocole assume que le next-hop avertit par EBGP doit être transporté dans IBGP. Du fait de ce rôle, le routeur B avertira 172.16.0.0 à son peer router IBGP qui n'est autre que C, avec un next hop égal à 10.10.10.3. Ainsi C connaît en next-hop pour la destination 172.16.0.O le routeur A d'adresse 10.10.10.3 et non pas 172.20.10.1 comme il se devrait.
Il est donc très important que le routeur C conaisse comment joindre le subnet 1.10.10.0 soit par un IGP soit par une route statique sosu peine  de voire ses paquets à cette destination purement droppés.

2.3.        Netx-Hop sur un réseau de type multiaccess

Sur un réseau de type, BGP va utilser l'adresse correcte en tant que next-hop pour éviter d'avoir à insérer des hops supplémentaires dans le path. Cette caractéristique se nomme "third-party next-hop".

2.4.        Next-Hop sur un réseau de type NBMA

Dans ce cas les complications apparaissent.

Dans notre figure, 3 routeurs sont interconnectés en FR. Le routeur B peut joindre le réseau 172.30.0.0 par 10.10.10.2.
Quand le routeur B envoie un update BGP au routeur A à propos de 172.30.0.0, il va utiliser 10.10.10.2 comme next-hop et non pas sa propre adresse (10.10.10.1).
Un problème va arriver quand les routeurs A et C ne savent pas directement communiquer entre eux autrement dit si les routeurs A et C n'ont pas de map entre eux. Le routeur A ne saura pas comment joindre la next-hop adresse du routeur C.
Ce souci peut être évité en configurant le routeur B pour qu'il s'avertisse lu même comme next-hop pour les routes envoyées au routeur A.

2.5.        Les attributs de local preference

Local preference est un attribut well-known de type discretionary qui donne donc une indication aux routeurs de l'AS sur le meilleur chemin à emprunter pour sortir de l'AS. Un path disposant de la locale preference la plus élevée sera préféré.
La valeur par défaut pour les routeurs Cisco est de 100. Cette valeur ne sera échangée qu'au sein des routeurs d'un AS.
Local preference équivaut donc à un métrique en interne.
!Dans BGP le plus gros est toujours le meilleur sauf pour le (club) MED
MED est équivalent à un métrique, le milleur est le plus bas.

2.6.        L'attribut MED, qui n'a rien à voir avec le club

MED est équivalent à un métrique en externe. Il est aussi connu en tant que Inter-AS attribute dans BGP-3.
Cet attribut est ddu type optionnel et nontransitif.

Cet attribut sert à selectionner une route entre 2 AS quand plusieurs choix existent. Cet attribut ne doit as être transmis en interne. Quand un update à destination d'un AS contient un MED, et que ce même update est passé à un autre AS, alors la valeur du MED passe à 0 en sortie du 2° AS.
Par défaut, un routeur ne va comparé le MED que sur les liens ou chemins entre les neighbors d'AS.
En utilisant le MED, BGP est le seul protocole qui peut affecter comment les routes sont transmises dans un AS.

2.7.        L'attribut origin

L'attribut origin est du type well-known mandatory et défini l'origine de l'information concernant un path.

L'attribut origin peut prendre une des 3 valeurs suivantes:

2.8.        L'attribut Community

Community=tag=nom. La community va servir à établir des règles de filtrage ou à établir des critères de sélection des routes.
Chaque routeur BGP peut tager des updatres de routes, entrants ou sortants ou lors d'une redistribution.
Chaque routeur BGP peut filtrer des routes sur les updates entrants ou sortants, ou selectionner des preferred routes basées sur les communautés (tag).
Par défaut, les communautés sont réparties dans les updates sortants.
Les communautés sont des attributs optionnels et transitifs. Si un routeur ne comprend pas les communautés, il les passera telles quel au routeur voisin. Par contre si le routeur comprend les communautés, il doit être configuré pour les propagér sinon elles seront détruites.

2.9.        L'attribut weight (Cisco)

Il s'agit d'un attribut Cisco quant à la sélectionde path. Le weight est confuguré localement sur un routeur et n'est propagé sur aucun autre. Le weight peut avoir une valeur de à à 65535. Les paths originaire du routeur ont un weight de 32768 par défaut, les autres paths ont un weight de 0 par défaut.

Les routeurs disposant d'un weight le plus haut sont préféres lors de la sélection d'une route vers la même destination, quand le choix existe.

Dans cet exemple on voit bien que le routeur A choisiera de passer par le routeur B pur aller en D, influencer qu'il est par le weight de 200, supérieur au weight de 150 qui l'aurait fait envoyer se ballader du côté de C.
Ce type de métrique est un métrique à la source, il n'est donc pas nécessaire de le forwarder ni en IBGP ni en EBGP.

3.            La synchronistaion

Il existe un rôle de synchronistaion: ne pas utiliser ou avertir à un neighbor externe, une route apprise par IBGP, tant qu'une route correspondante n'est pas apprise par un IGP (OSPF, EIGRP …)

Tant que l'ensemble des routeurs d'un AS ne connaissent pas une route apprise par IGP, celle-ci ne peut être transmise par BGP vers un AS externe.
Cette règle est là pour s'assuer de la consitance des informations au travers des AS.
De plus elle prévient la formation de trous (black holes) à l'intérieur même de l'AS.
Il est plus prudent de stopper la synchronistaion quand tous les routeurs d'un AS tournent BGP.

Dans cet exemple, si la synchronisation est on (défaut):

Si la synchronisatain est passée en off:

4.             Les opérations BGP

BGP définit les types de messages suivants:

Les peers vont initialement échanger la table de routage complète. Par la suite, seuls les updates seront envoyés sosu forme d'updates incrémentaux. Les paquets keepalives sont envoyés pour s'assurer de la connexion entre les 2 peers.
Après qu'une session TCP soit établie, le 1° message envoyé est un open. Si le message open est acepté, un message keepalive de confirmation de l'ouverture de a session est envoyé en retour. Une fois que le message open est accepté et que les updates et les keepalives sont établis, les messages de notifications peuvent être échangés.
Un open message inclut les informations suivantes:
hold-time, le temps max entre 2 keepalives ou entre 2 updates. Quand un routeur reçoit open message, le routeur calcule la valeur du hold-time timer en utilisant la plus petite des valeurs du hold time local et de celui reçu dans le message open.
BGP router ID, 32 bits. L'identifier BGP est un adresse IP assignée au routeur et déterminée au démarrage. L'ID BGP est sélectionnée de la même manière qu'OSPF, c'est l'adresse IP la plus haute des adresses actives, à moins qu'une adresses de loopback ne soit présente. Dans ce dernier cas c'est l'adresse IP la plus haute des interface loopback qui sera sélectionnée.
BGP n'utilise pas de protocole de transport spécifique pour les keepalives, mais utilise uniquement la mécanique TCP en envoyant des messages qui ne contiennent que le header.
Un update message ne contient que des informations à propos d'un path, de multiples paths nécessitent de multiples messages.
Tous les attributs du message concernent uniquement ce path et les réseau sont ceux qui peuvent être utilisé pour le joindre. U message update contient les champs suivants:
withdrawn routes, la liste des préfixes IP pour les routes qui sont withdrawn from service, if any.
path attributes, qui sont l'AS-path, original, local preference. Chaque path attribute inclus le type, la longeur et la valeur. Le type consiste du flag suivi du type code.
network layer reachability information, la liste des adresses IP qui peuvent être jointes par ce path
Un message de notification est envoyé quand une erreur est détectée, la connexion BGP est close immédiatement. Les messages de notification incluent le code erreur et le subcode erreur ainsi que les données relatives à cette erreur.

4.1.        Le process de sélection et de décision de routage

En considérant seulement des routes synchronisées sans boucles dans les AS et un next-hop valide, alors le choix se porte en priorité sur:

CIDR est un mécanisme pour faire face à la perte oppressive d'adresses IP ainsi qu'à l'augmentation de la taille des tables de routage.
L'idée est que des blocs d'adresses C peuvent être combinés ou agrégés afin de créer une plage plus large d'adresss IP.
Les anciennes versions de BGP ne supportaient pas CIDR. BGP-4 dispose d'un support de CIDR:

Il existe 2 attributs BGP relatifs à l'agrégation de routes:
le well-known discretionary attribute: atomic aggregate, qui informe l'AS voisin que le routeur d'origine a agréger les routes.
l'attribut optionel et transitif aggregator (le retour) spécifie le BGP router ID et l'AS number du routeur qui réalise l'agrégation de routes.

Par défaut, la route agrégée sera avertie comme provenant del 'AS d'où est réalisé l'agrégation et qui aura l'attribut atomic positionné. Les AS des routes non agrégées ne sont pas listés. Le routeur peut être configuré pour inclure la liste des AS contenus dans l'ensemble des paths qui sont summarizés.

Les communautés de BGP

Communauté

Description

Internet

Demande au routeur d'anoncer cette route à tous les IBGP et EBGP peers

Local-AS

Demande au routeur de ne pas anoncer cette route aux seuls IBGP peers

no-advertise

Indique au routeur de ne pas anoncer cette route à tout IBGP ou EBGP peer.

no-export

Indique au routeur de ne pas anoncer cette route à n'importe quel EBGP peer.

5.            La configurationde BGP

Les routeurs BGP sont souvent configurés à l'aide de la même update policy (les même filtres appliqués par ex.)
Sur des routeurs Cisco, les routeurs neighbors ces routeurs peuvent être regrupés en peer groups pour simplifier la configuration.
Les membres d'un groupes héritent des mêmes options de configuration. Les membres peuvent être configurés pour outrepasser ces options à condition que ces options n'affectent pas les updates en sortie (outbound).
Les updates ne sont générés qu'une seule fois pour le groupe.

router(config)# router bgp n°_autonomous-system --> autorise BGP

router(config-router)# neighbor {ip-address|peer-group-name} remote-as autonomous-system --> active une session BGP avec un nouveau routeur, utilisé à la fois avec IBGP et EBGP
router(config-router)# network network-number [mask network-mask] --> permet à BGP d'avertir une route IGP si elle figure toujours dans la table de routage. N'active pas le rpotocole sur une interface.

La commande network a une toute autre utilité que dans les commandes des autres protocoles. La commande network ne sert pas à indiquer sur quelle interface tourne le protocole, mais quel est le réseu qui doit être annnoncé ou injecté dans le nuage BGP.

5.1.        1° exemple

routerA(config)# router bgp 64520
routerA (config-router)# neighbor 10.1.1.1 remote-as 65000
routerA(config-router)# network 172.16.0.0

routerB(config)# router bgp 65000
routerB (config-router)# neighbor 10.1.1.2 remote-as 64520
routerB(config-router)# network 172.17.0.0

L'interface de la commande neighbor peut être une interface loopback.
Router(config-router)# neighbor {ip-address|peer-group-name} next-hop-self --> Force BGP à utiliser la propre adrese IP d'un neighbor en tant que next hop plutôt que de permettre au protocole de choisir l'adresse du next hop. On fixe l'adresse du next hop à un point donné. Cette commande permet au sein d'un AS géré par IBGP de modifier le next-hop, qui est en général le routeur externe.

Router(config-router)# no synchronisation --> Désactive la synchronisation de BGP afin que le routeur annonce les routes dans BGP avant de les apprendre par un IGP. Cette commande est utilisée quand un trafic provenant d'un autre AS ne doit pas passer au travers de l'AS propre, ou si tous les routeurs de l'AS tournent BGP.
La désactivation de la synchronisation permet de transporter moins de routes au travers de l'IGP et permet à BGP de converger plus rapidement.

Router(config-router)# aggregate-address ip-address mask [summary-only][as-set]        

Router(config-router)# clear ip bgp {*|address} [soft[in|out]] --> resette les connexions BGP, à utiliser après un changement de configuration  de BGP.

N Le reset de BGP va interrompre le routage. En effet pendant une ½ à 1 heure, le routeur ne va travailler qu'a a reconstruction de sa database et il ferme toutes les connexions tcp.
 ! clear ip route * va effacer la table de routage sans effacer la database
 ! clear ip bgp soft ne fait pas un reset complet de ses connexions TCP. Le routeur généère de nouvelles updates en entrée sans casser les sessions tcp. Cependant le routeur local conserve une copie de tous les updates sans modifications, sans même s'assurer que sa propre policy peut les accepter ou pas. Ce process consume énormément de mémoire et doit être éviter le plus possible. Outbound BGP soft n'est, quant à lui, pas consomateur d'un excédent de mémoire. Pour qu'une nouvelle policy prenne effet, il convient d'utiliser la commande outbound.

5.2.        2° exemple BGP

routerB(config)# router bgp 65000
routerB(config-router)# neighbor 10.1.1.2 remote-as 64520
routerB(config-router)# neighbor 192.168.1.50 remote-as 65000
routerB(config-router)# network 172.16.0.0 mask 255.255.255.0
routerB(config-router)# network 192.168.1.0 mask 255.255.255.0
routerB(config-router)# no synchronization
routerB(config-router)# neighbor 192.168.1.50 next-hop-self
routerB(config-router)# aggregate-address 172.16.0.0 255.255.0.0 summary-only

 

Les 2 premières commandes établissent BGP que le routeur B possède 2 voisins: routeur A dans AS 64520 et routeur C dans l'AS 65000.
Si le routeur C annonce 172.16.20.0 dans BGP, le routeur B recevra cette route mais ne la passera au routeur A jusqu'à ce que la commande no synchronisation ne soit rajoutée sur les 2 routeurs B et C, puisqu'il n'y a pas d'IGP qui tourne dans l'AS. Cette comande peut être employée dans ce cas puisque seul BGP tourne dans 'AS.
La commande clear ip bgp * devra être lancée sur les 2 routeurs B et C afin de resetter les connexions TCP après que la synchronisation ait été arrêtée.
Par défaut le routeur B passe les annonces au routeur C provenant du routeur A, à propos du réseau 192.168.2.0 avec l'adresse de next-hop à 10.1.1.2. Cependant, le routeur C ne connaît rien de l'adresse 10.1.1.2 et donc il n'installera pas la route dans sa table de routage. La commande neighbor 192.168.1.50 next-hop-self force le routeur B à envoyer des avertissements au routeur C avec sa propre adresse (routeur B) en tant que next-hop, ce qui permet au routeur C de joindre 192.168.2.0.
Le routeur A aprend les 2 subnets 172.16.0.0 ainsi que 172.16.20.0. Cependant une fois que la commande aggregate-adresse 172.16.0.0 255.255.0.0 summary-only n'est pas rajoutée au routeur B, celui-ci summarize les subnets et n'enverra uniquement 172.16.0.0/17 au routeur A.

5.3.        La vérification de BGP

router# show ip bgp [summary|neighbors]
show ip bgp summary      è affiche l'état des connexions bgp
show ip bgp summary      è affiche les informations à propos des connexions TCp et BGP des voisins
router# debug ip bgp

6.            BGP split horizon

Les routes apprises par IBGP ne sont jamais propagées sur d'autres peers IBGP. La conséquence est que IBGP doit être full-meshed, tous les routeurs doivent posséder une connexion TCP entre eux.
Le résultat est que dans un AS, si tous les routeurs possèdent une connexion TCp avec  chacun des autres routeurs on arrive à n(n-1)/2 connexions TCP. De plus le trafic que représente une connexion de chaque routeurs avec tous les routeurs du nuage de l'AS, est énorme. La soluton consiste à adopter des routes reflectors

7.            Les routes reflectors

Un route reflector est un routeur qui modifie le rôle de BGP split horizon en autorisant le routeur configuré en route reflector de propager les routes apprises par IBGP aux autres peers. Cette approche diminue le nombre de sessions TCP dans l'AS et réduit donc le trafic associé.

Les routess reflectors résolvent les problèmes liés à IBGP et le full-meshed, de ce fait est utilsé par les ISP quand le nombre de leurs routeurs internes est grand.
L'envoi des paquets n'en n'est pas affecté, on peut trouver plusieurs routes reflectors pour assurer la redondance. On peut aussi trouver plusieurs niveaux de route reflectors. Les peers normaux peuvent coexister et la migration est simple.

7.1.        La terminologie des routes reflectors:

7.2.        Le design des routes reflectors

Il convien t de diviser l'AS en plusieurs clusters, et disposer d'un route reflector et de peu de clients dans un cluster.
Les routes reflectors sont fully-meshed avec IBGP
Il convient d'utiliser plusieurs IGP pour transporter les informations de next-hop ainsi que les routes locales.
A l'implantation de routes reflectors il convient de se poser certaines questions:
quels sont les ruteurs qui vont devenir des routes reflectors ? Il faut suivre la topolgie physique ce qui garantiera que les paquets n'en seront pas affectés.
Il convient de configurer un route reflector à la fois, ce qui élimine la redondance de sessions IBGP et de placer un route reflector par cluster.

7.3.        Les opérations des routes reflectors

Les reflectors reçoivent des updates des clients et des nonclients.
Si l'update provient d'un client, elle sera refléchie aux client et nonclients à l'exception de l'originator.
Si l'update provient d'un nonclient, elle sera réfléchie aux seuls clients.
Si l'update provient d'un peer EBGP, elle sera réfléchie aux clients et nonclients.

7.4.        La configuration des routes reflectors

router(config-router)# neighbor ip-address route-reflector-client
La commande sert à configurer le routeur en tant que route reflector et cnfigure un neighbor spécifique en tant que client. En fait on ne dispose pas de commande spécifique pour dire que le routeur est route-reflector, mais uniquement d'une commande qui précise où se situent les clients du route reflector.

routerA(config)# router bgp 65000
routerA(config-router)# neighbor 172.16.12.1 remote-as 65000
routerA(config-router)# neighbor 172.16.12.1 route-reflector-client
routerA(config-router)# neighbor 172.16.12.2 remote-as 65000
routerA(config-router)# neighbor 172.16.12.2 route-reflector-client

La vérification de la configuration des route reflectors est particulière. En effet, on ne voit pas qu'un routeur et route reflector, mais uniquement qu'il possède des clients par la commande show ip bgp neighbors.
La redistribution :
Si des routes internes à un AS doivent être annoncées, la redistribution doit être configurée dans BGP. Dans ce cas il existe 3 méthodes de redistribution en utilisant la commande network :

8.            Policy control

Pour restreindre les informations de routage vers ou depuis les neighbors, on peut utilser:

8.1.        Prefix list

Le routeur A peut interdire aux updates 172.30.0.0 d'aller vers AS65000
Les prefix list peuvent être utilisée comme alternative aux access-list dans la plupart des commande de filtrage de BGP. Les avantages sont:

Le filtrage avec les prefix listes:

8.2.        Les options de redistribution

Les commandes distance et default-metric, permttent de s'assurer que la redistribution entre RIP et OSPF s'effectuera sans boucles. Ces commandes associées permettent de sélectioner un path sub-optimal.
Quand OSPF est redistribué au travers d'EIGRP, la commande default-metric permet de donner un métrique à une route dirctement connectée par un ASBR.
Quand un routeur récupère une route depuis un autre AS de nature différente, il lui affecte un seed metric.sera incrémenté au fur et à mesure de sa propagation au sein du nouvel AS. Cependanr quand les 2 routeurs tournent avec chacun un AS différent et un protocole de routage différent, le métrique ne pourra être affecté de manière automatique.
De plus si il existe déjà une route identique conne par le protocole de routage local, il est fortement conseillé d'affeter un métrique plus haut pour la route injectée de façon à éviter les boucles.

Publié le vendredi 10 novembre 2006
par Jack Mielcarek