ccnp_cch 1 BGP - Etude de BGP

ccnp_cch 2 Sommaire - Introduction - BGP Etude partie 1 - Comment BGP fonctionne-t-il? - eBGP et iBGP - Validation du routage BGP - Création de voisins BGP - BGP et le interfaces Loopback - eBGP Multihop - eBGP Multihop (Equilibrage de charge) - Route Maps - Commandes de configuration set et match - Commande network - Redistribution - Routes Statiques et Redistribution - iBGP - L'algorithme de décision de BGP - BGP Etude partie 2 - L'attribut AS_PATH - L'attribut Origin - L'attribut BGP Next Hop - BGP Backdoor - Synchronisation - L'attribut Weight - L'attribut Local Preference - L'attribut Metric - L'attribut Community - BGP Etude Partie 3 - Filtrage BGP - Expression régulière AS - Voisin BGP et Route Maps - BGP Etude partie 4 - CIDR et routes agrégées - Confédération BGP - Route Reflectors - Route "Flap Dampening" - Comment BGP sélectionne un chemin

ccnp_cch 3 - BGP Etude partie 5 - Exemple pratique de conception

ccnp_cch 4 Introduction Ce document contient cinq études de cas avec BGP. Il n'y a pas de prérequis spécifiques pour utiliser ce document. Il n'y a pas de restrictions liées à un matériel ou à un logiciel particulier ou à une version de celui-ci. BGP Etude partie 1 BGP (Border Gateway Protocol), défini par le RFC1771, vous permet de réaliser un routage inter-domaines sans boucle entre systèmes autonomes (AS). Un AS (Autonomous System) est un ensemble de routeurs gérés par une seule entité administrative. Les routeurs dans un AS peuvent utiliser plusieurs protocoles de routa- ge interne pour échanger des informations de routage dans l'AS et un protocole de routage externe pour router les paquets hors de l'AS. Comment BGP fonctionne-t-il? BGP utilise TCP comme protocole de transport (Port 179). Deux routeurs BGP etablis- sent une connexion TCP entre eux (peer routers) et échangent des messages pour ouvrir et confirmer les paramètres de la connexion. Les routeurs BGP échangent des informations d'accessibilité de réseau. Cette informa- tion représente pricipalement une indication du chemin complet (numéros d'AS BGP) qu'une route doit utiliser pour joindre le réseau destination. Cette information aide à la construction d'un graphe des AS sans boucle et où les politiques de routage peuvent être appliquées dans le but de renforcer quelques restrictions sur le comportement du routage. Les deux routeurs qui ont formé une connexion TCP pour échanger des informations de routage BGP sont appelés peers ou voisins. Les voisins BGP échangent initialement leurs tables de routage BGP dans leur totalité. Après cet échange, des mises à jour incrémentales sont transmises lors de changements dans les tables de routage. BGP garde un numéro de version de la table BGP qui doit être le même pour les routeurs BGP voisins. Le numéro de version change chaque fois que BGP met à jour la table de routage. Des paquets "Keepalive" sont transmis pour s'assurer que la connexion est toujours opérationnelle entre les voisins BGP et des paquets de notification sont trans- mis en cas d'erreur ou dans des cas spécifiques. eBGP et iBGP Si un AS a plusieurs routeurs BGP, il peut être utilisé comme AS de transit pour d'autres AS. Comme vous pouvez le constater dans la figure.1 ci-dessous, l'AS200 sert d'AS de transit pour l'AS100 et l'AS300. Il nécessaire de s'assurer de l'accessibilité des réseaux dans l'AS avant de transmettre l'information aux AS externes. Ceci est réalisé par une combinaison de voisinage BGP interne (iBGP) entre routeurs dans un AS et redistribuant l'information BGP aux proto- coles de routage internes (Interior Gateway Protocol) opérant dans l'AS. Dans tout ce document, quand BGP opère entre deux routeurs appartenant à deux AS différents, nous utilisons le terme eBGP (exterior BGP).

ccnp_cch 5 Quand BGP opère entre deux routeurs situés dans le même AS, nous utilisons le terme iBGP (interior BGP). iBGP eBGP AS200 AS100 AS300 Validation du routage BGP Exécutez les étapes suivantes pour valider et configurer BGP. Supposons que nous avons deux routeurs RTA et RTB qui utilisent BGP. Dans le pre- mier exemple les routeurs RTA et RTB sont dans deux AS différents et dans le second exemple,ils sont dans le même AS. Nous commençons par définir le processus BGP et le numéro d'AS auquel le routeur appartient. Utilisez la commande suivante pour valider BGP sur un routeur. RTA(config)#router bgp 100 RTB(config)#router bgp 200 L'étape suivante dans le processus de configuration est la définition des voisins BGP pour indiquer quels sont les routeurs qui doivent se connecter pour échanger des in- formations BGP. Création des voisins BGP Deux routeurs BGP deviennent voisins une fois qu'ils ont établi une connexion TCP entre eux. La connexion TCP est obligatoire pour que les deux routeurs voisins BGP commencent à échanger des mises à jour de routage. Une fois que la connexion TCP est établie, les routeurs transmettent des messages d'ouverture pour échanger des valeurs telles que le numéro d'AS, la version BGP utilisée, le BGP router ID et la durée de validité des "keepalive". Une fois que ces valeurs sont acceptées et confirmées, la connexion avec le voisin est établie. Tout information autre que "established" montre que les deux routeurs ne sont pas devenus voisins et que les mises à jour BGP ne seront pas échangées

ccnp_cch 6 Utilisez cette commande pour établir la connexion TCP: Router(config-router)# neighbor ip-address remote-as number Le remote-as number est numéro d'AS du routeur avec lquel nous voulons nous con- necter pour utiliser BGP. Le paramètre ip-address est l'adresse IP du prochain saut directement connecté pour eBGP et toute autre adresse IP pour sur l'autre routeur pour iBGP. Il est essentiel que les deux adresse IP utilisées dans la commande neighbor sur les routeurs voisins soient accessibles. Le moyen le plus sur pour vérifier l'accessibilité est d'utiliser une commande ping étendue entre les deux adresses IP. La commande ping étendue force le routeur émetteur à utiliser l'adresse source spécifiée dans la commande et correspondant à celle spécifiée dans la commande neighbor. Il est important de remettre à zéro les connexions dans le cas d'un changement de con- figuration afin que les nouveau paramètres soient pris en compte. clear ip bgp address (address est l'adresse du voisin) clear ip bgp * (efface toutes les connexions avec les voisins) Par défaut les sessions BGP commencent par l'utilisation de la version 4 et il a ensuite négociation pour des versions antérieures si nécessaire. Pour éviter les négociations et forcer la version BGP utilisée pour communiquer avec un voisin, utilisez la commande suivante en mode de configuration router: neighbor {ip-address|peer-group-name} version value Exemple de commande de configuration neighbor. iBGP eBGP AS200 AS100 AS300 RTA RTD RTB RTC

ccnp_cch 7 RTA(config)#router bgp 100 RTA(config-router)#neighbor remote-as 200 RTB(config)#router bgp 200 RTB(config-router)#neighbor remote-as 100 RTB(config-router)#neighbor remote-as 200 RTC(config)#router bgp 200 RTA(config-router)#neighbor remote-as 200 Dans l'exemple ci-dessus, RTA et RTB utilisent eBGP. RTB et RTC utilisent iBGP. La différence entre eBGP et iBGP se manifeste par le remote-as number pointant sur un numéro d'AS externe ou interne. Les voisins eBGP sont directemnt connectés tandis que les voisins iBGP ne le sont pas. Les voisins iBGP n'ont pas besoin d'être directe- ment connectés tant qu'il y a un IGP opérant qui permet aux deux voisins iBGP de communiquer. La sortie suivante est un exemple d'information affichée par la commande show ip bgp neighbors. Focalisez votre attention sur l'état BGP car tout état autre que "established" indique que les voisins ne sont pas connectés. Vous noterez également que la version BGP est égale à 4, le remote router ID (adresse IP la plus élevée sur le routeur ou interface loopback la plus élevée sur le routeur si elle existe ) et la version de la table (c'est l'état de la table, chaque fois qu'une nouvelle information est entrée, la version de la table est incrémentée. Une version qui s'incré- mente en permanence indique qu'une route est instable et occasionne des mises à jour continuelles. RTA#show ip bgp neighbors BGP neighbor is , remote AS 200, external link BGP version 4, remote router ID BGP state = Established, table version = 3, up for 00:10:59 Last read 00:00:29, hold time is 180, keepalive interval is 60 seconds Minimum time between advertisement runs is 30 seconds Received 2828 messages, 0 notifications, 0 in queue Sent 2826 messages, 0 notifications, 0 in queue Connections established 11; dropped 10 BGP et les interfaces Loopback L'utilisation d'une interface Loopback pour définir les voisins est commune avec iBGP mais pas avec eBGP. Normalement l'interface loopback est utilisée pour être sur que l'adresse IP du voisin reste accessible et indépendante du fonctionnement du matériel. Dans le cas de eBGP, les voisins sont directement connectés et l'interface loopback n'est pas utilisée. Si vous utilisez l'adresse IP d'une interface loopback dans la commande neighbor, vous aurez besoin d'une configuration supplémentaire sur le routeur voisin. Le routeur voisin a besoin d'indiquer à BGP qu'il utilise une interface loopback au lieu d'une interface physique pour la connexion TCP avec le voisin BGP. La commande utilisée pour indiquer qu'une interface loopback est utilisée est: neighbor ip-address update-source interface

ccnp_cch 8 L'exemple suivant illustre l'utilisation de cette commande: RTA(config)#router bgp 100 RTA(config-router)#neighbor remote-as 100 RTA(config-router)#neighbor update-source loopback 1 RTB(config)#router bgp 100 RTB(config-router)#neighbor remote-as 100 Dans l'exemple ci-dessus, RTA et RTB utilisent iBGP dans l'AS100. RTB utilise dans la commande neighbor l'interface loopback de RTA ( ); dans ce cas BGP doit forcer l'adresse IP de l'interface loopback comme adresse source pour la connexion TCP du voisin. RTA réalise cela avec la commande neignbor update-source loopback 1. Cette commande force BGP à utiliser l'adresse IP de l'interface Loopback lorsqu'il communique avec le voisin Notez que RTA a utilisé l'adresse IP de l'interface physique ( ) de RTB comme un voisin, c'est pour cela que RTB n'a pas besoin de configuration spécifique. eBGP Multihop Dans certains cas un routeur Cisco peut utiliser eBGP avec un routeur tierce ce qui ne permet pas aux deux voisins externes d'être directement connectés. Pour réaliser ceci, vous pouvez utiliser eBGP Multihop qui permet à la connexion entre voisins d'être éta- blie entre deux voisins externes non-directement connectés. Le Multihop est utilisé uniquement avec eBGP. L'exemple suivant illustre eBGP Multihop RTBRTA Interface Loopback AS RTB RTA AS AS300

ccnp_cch 9 RTA(config)#router bgp 100 RTA(config-router)#neighbor remote-as 300 RTA(config_router)#neighbor ebgp-multihop RTB(config)#router bgp 300 RTB(config-router)#neighbor remote-as 100 RTA indique qu'un voisin externe n'est pas directement connecté. RTA a besoin d'indi- quer qu'il utilise eBGP Multihop. D'autre part RTB indique un voisin directement connecté ( ), c'est pour cela qu'il n'a pas besoin de ebgp-multihop. Vous devez également configurer un IGP ou une route statique pour permettre aux voisins non-directement connectés de communiquer entre eux. L'exemple suivant montre comment utiliser l'équiblibrage de charge avec BGP dans le cas de liaisons redondantes avec eBGP. eBGP Multihop (Equilibrage de charge) RTB RTA AS AS200 RTA(config)#interface Loopback 0 RTA(config-if)#ip address RTA(config)#router bgp 100 RTA(config-router)#neighbor remote-as 200 RTA(config-router)#neighbor ebgp-multihop RTA(config-router)#neighbor update-source loopback 0 RTA(config-router)#network RTA(config)#ip route RTA(config)#ip route RTB(config)#interface Loopback 0 RTB(config-if)#ip address RTB(config)#router bgp 200 RTB(config-router)#neighbor remote-as 100 RTA(config-router)#neighbor ebgp-multihop RTA(config-router)#neighbor update-source loopback 0 RTA(config-router)#network RTB(config)#ip route RTB(config)#ip route L'exemple ci-dessus illustre l'utilisation des interfaces loopback, de update-source et de eBGP Multihop Loopback Loopback

ccnp_cch 10 C'est un façon de réaliser l'équilibrage de charge entre deux routeurs eBGP utilisant des liaisons Serial en parallèles. Dans des situations classiques, BGP prend une des liaisons pour transmettre les paquets et l'équilibrage de charge n'est pas effectué. En introduisant les interfaces loopback, le le prochain saut pour eBGP est l'interface loopback. Nous utilisons également des routes statiques (on peut également utiliser un IGP) pour introduire deux chemins de coûts égaux pour joindre la destination. RTA a deux choix pour atteindre le prochain saut ; un via et l'autre via et de même pour RTB. Route Maps Les Route Map sont très largement utilisés avec BGP. Dans le contexte BGP, le Route Map est une méthode utilisée pour contrôler et modifier l'information de routage. Ceci est en définissant des conditions pour la redistribution des routes d'un protocole de routage vers un autre ou en contrôlant l'information de routage qui entre ou qui sort de BGP. Le format de la commande est le suivant: route-map map-tag [ [permit|deny] | [ sequence-number ] ] Le map-tag est seulement un nom que vous donnez à la route-map. Plusieurs instan- ces de la même route-map (même map-tag) peuvent être définies. Le numéro de sé- quence est la position que la nouvelle route-map doit avoir dans la liste de route-map configurées avec le même nom. Par exemple, s'il y a deux instances de route-map définies, appelées MYMAP, la pre- mière instance aura le numéro de séquence 10 et la seconde aura un numéro de séquence égal à 20. route-map MYMAP permit 10 (premier ensemble de conditions) route-map MYMAP permit 20 (second ensemble de conditions) Quand la route-map MYMAP est appliquée aux routes en entrée ou en sortie, le premier ensemble de conditions sera appliqué via l'instance 10. Si le premier ensemble de conditions n'est pas satisfait, il sera procédé avec l'instance supérieure de la route- map. Commandes de configuration set et match Chaque route-map est constituée d'une liste commandes de configuration set et match. Le mot-clé match spécifie un critère de correspondance et le mot-clé set spécifie une action si le critère de correspondance fixé par la commande match est trouvé. Par exemple, vous pourrez définir une route-map qui vérifie les mises à jour émises et s'il y a une correspondance pour l'adresse IP , la métrique pour cette mise à jour sera fixée à 5. Ceci peut être illustré par les commandes suivantes: match ip address set metric 5

ccnp_cch 11 Maintenant si le critère de correspondance est trouvé et le mot-clé permit est spécifié, les routes seront redistribuées ou controlées comme spécifié par la commande set et la liste sera terminée. Si le critère de correspondance est trouvé et le mot-clé deny est spécifié, la routes ne sera pas redistribuée ou controlée et la liste sera terminée. Si les critères de correspondance ne sont pas trouvés et que les mot-clés deny ou permit sont spécifiés, l'instance suivante de la route-map (instance 20 par exemple) sera véri- fiée et ainsi jusqu'à la sortie d'une liste ou jusqu'à la fin de toutes les instances d'une route-map. Si une liste est terminée sans aucune correspondance trouvée, la route que nous vérifions ne sera ni acceptée ni acheminée. Les commandes match sont les suivantes: match as-path match community match clns match interface match ip address match ip next-hop match ip source-route match metric match route-type match tag Les commandes set sont les suivantes: set as-pathset clns set automatic-tagset community set interfaceset default interface set ip default next-hopset level set local-preferenceset mtric set metric-typeset next-hop set originset tag set weight

ccnp_cch 12 Etudions quelques exemples de route-map: RTA RTB AS 300 AS RTC Exemple 1: Supposons que RTA et RTB utilisent RIP; RTA et RTC utilisent BGP. RTA reçoit des mises à jour via BGP et les redistribue dans RIP. Si RTA veut redistribuer les routes vers RTB avec une métrique de 2 et toutes les autres routes avec une métri- que de 5, nous devons utiliser la configuration suivante: RTA(config)#router rip RTA(config-router)#network RTA(config-router)#network RTA(config-router)#network RTA(config-router)#passive-interface Serial0 RTA(config-router)#redistribute bgp 100 route-map SETMETRIC RTA(config)#router bgp 100 RTA(config-router)#neighbor remote-as 300 RTA(config-router)#network RTA(config)#route-map SETMETRIC permit 10 RTA(config-route-map)#match ip-address 1 RTA(config-route-map)#set metric 2 RTA(config)#route-map SETMETRIC permit 20 RTA(config-route-map)#set metric 5 RTA(config)#access-list 1 permit Dans l'exemple ci-dessus, si une route correspond à l'adresse IP elle aura une métrique de 2 et ensuite la liste de la route-map sera terminée. S'il n'y a pas de correspondance, la suite de la liste est explorée avec avec le numéro de séquence sui- vant (20) dont l'instruction est : positionner la métrique à 5. Il est toujours très impor- tant de se poser la question: qu'arrive-t-il aux routes pour lesquelles aucune corres- pondance n'est trouvée? Par défaut elles sont rejetées.

ccnp_cch 13 Exemple 2: Supposons que par rapport à l'exemple précédent, nous ne voulons pas que l'AS 100 accepte les mises à jour pour le réseau Comme les route-map ne peuvent pas être appliquées en entrée quand la correspondance est basée sur l'adresse IP, nous devons utiliser une route-map en sortie sur RTC. que de 5, nous devons utiliser la configuration suivante: RTC(config)#router bgp 300 RTC(config-router)#neighbor remote-as 100 RTC(config-router)#neighbor route-map STOPUPDATES out RTA(config-router)#network RTC(config)#route-map STOPUPDATES permit 10 RTC(config-route-map)#match ip-address 1 RTC(config)#access-list 1 deny RTC(config)#access-list 1 permit Maintenant que vous êtes familiarisés avec l'activation de BGP et la définition des voisins, regardons comment activer l'échange d'informations au sujet des réseaux. Il y a plusieurs façons de transmettre des informations de réseau avec BGP. Les sections suivantes les décrivent une à une. Commande Network Le format de la commande network est le suivant: network network-number [mask network-mask] La commande network indique quels sont les réseaux issus de ce routeur. C'est un concept différent de celui utilisé pour RIP et IGRP. Avec cette commande nous n'es- sayons pas d'activer BGP sur une interface mais nous indiquons à BGP quels sont les réseaux dont l'origine est ce routeur. La partie masque est utilisée car BGP version 4 (BGP 4) peut gérer les sous-réseaux et les super-réseaux (agrégation). Un maximum de 200 entrées pour la commande network est accepté. La commande network fonctionnera si le réseau que vous annoncez est connu du routeur, soit il est directement connecté soit c'est une route statique ou ce réseau a été appris dynamiquement. Voici un exemple de commande network: RTA(config)#router bgp 1 RTA(config-router)#network mask RTA(config)#ip route null 0 L'exemple ci-dessus indique que le routeur A génèrera une entrée pour le réseau /16. Le /16 indique que nous utilisons un super-réseau de classe C et que le super-réseau est codé sur les deux premiers octets. Notez que la route statique permet de générer une entrée dans la table de routage.

ccnp_cch 14 Redistribution La commande network est un moyen utilisé pour annoncer des réseaux via BGP. Un autre moyen est la redistribution de votre IGP (IGRP, OSPF, RIP, EIGRP,..) dans BGP. Cela paraît insensé car vous allez introduire toutes vos routes internes dans BGP, certaines ayant été apprises par BGP. Un filtrage précis doit etre appliqué pur être sur que vous envoyez sur Internet uniquement les routes que vous voulez diffuser et uni- quement celles-ci. Regardons l'exemple ci-dessous. RTA annonce et RTC annonce Regardons la configuration de RTC RTA AS 200 AS 100 RTB RTC RTD AS Si vous utilisez la commande network, vous aurez: RTC(config)#router eigrp 10 RTC(config-router)#network RTC(config-router)#redistribute bgp 200 RTC(config-router)#default-metric RTC(config)#router bgp 200 RTC(config-router)#neighbor remote-as 300 RTC(config-router)#network mask !-- Ceci limitera les réseaux issus de votre AS au réseau Si vous utilisez la redistribution, vous aurez: RTC(config)#router eigrp 10 RTC(config-router)#network RTC(config-router)#redistribute bgp 200 RTC(config-router)#default-metric RTC(config)#router bgp 200 RTC(config-router)#neighbor remote-as 300 RTC(config-router)#redistribute eigrp 10

ccnp_cch 15 Ceci entraine que est considéré comme issu de votre AS. Ceci est une mau- vaise affirmation car vous n'êtes pas la source de mais l'AS 100 oui. Aussi vous devez utiliser des filtres pour éviter que ce réseau soit considéré comme issu de votre AS. La configuration correcte est: RTC(config)#router eigrp 10 RTC(config-router)#network RTC(config-router)#redistribute bgp 200 RTC(config-router)#default-metric RTC(config)#router bgp 200 RTC(config-router)#neighbor remote-as 300 RTC(config-router)#neighbor distribute-list 1 out RTC(config-router)#redistribute eigrp 10 RTC(config)#access-list 1 permit La commande access-list est utilisée pour controler quels sont les réseaux qui sont issus de l'AS 200. Routes statiques et Redistribution Vous pouvez toujours utiliser des routes statiques pour donner une origine à un réseau ou à un sous-réseau. La seule différence est que BGP considèrera ces routes avec une origine inconnue. L'exemple précédent peut être réalisé de la manière suivante: RTC(config)#router eigrp 10 RTC(config-router)#network RTC(config-router)#redistribute bgp 200 RTC(config-router)#default-metric RTC(config)#router bgp 200 RTC(config-router)#neighbor remote-as 300 RTC(config-router)#redistribute static RTC(config)#ip route null0 L'interface null0 signifie éliminer le paquet. Aussi, si le routeur reçoit un paquet et qu'il y a une correspondance plus spécifique que (laquelle existe bien sur), le routeur transmettra ce paquet grâce à la correspondance spécifique sinon le paquet sera éliminé. C'est une manière très élégante d'annoncer un super-réseau. Nous avons montré comment utiliser différentes méthodes pour indiquer que des routes sont issus de notre système autonome. Rappelez-vous que ces routes sont générées en plus des autres routes BGP que BGP a appris par ses voisins (internes ou externes). BGP passe les informations apprises d'un voisin aux autres voisins. La différence est que les routes statiques, les routes générées par la commande network et la redistribution indiquerons votre AS comme origine pour ces réseaux. L'Injection des routes BGP dans un IGP est toujours réalisée avec la redistribution.

ccnp_cch 16 Exemple: RTA AS 100 RTB AS300 AS 200 RTC RTA(config)#router bgp 100 RTA(config-router)#neighbor remote-as 300 RTA(config-router)#network RTB(config)#router bgp 200 RTB(config-router)#neighbor remote-as 300 RTB(config-router)#network RTC(config)#router bgp 300 RTC(config-router)#neighbor remote-as 100 RTC(config-router)#neighbor remote-as 200 RTC(config-router)#network Notez que vous n'avez pas besoin des commandes network et netwotk sur RTC à moins que vous vouliez que ces réseaux soient annoncés comme étant issus des AS 100 et AS 200. La différence est que la commande network ajoutera une annonce pour ces mêmes réseaux indiquant qu'ils sont aussi issus de l'AS 300. Un point important à se rappeler est que BGP n'acceptera pas de mises à jour dont l'origine est sa propre AS. Ceci pour s'assurer d'une topologie inter-domaine sans boucle de routage. Par exmple, supposons que l'AS 200 ci-dessus ait une connexion BGP directe dans l'AS 100. Le routeur RTA génèrera la route et la transmet à l'AS 300, ensuite RTC passera cette route vers l'AS 200 avec comme origine l'AS 100. RTB va passer la route à l'AS 100 avec AS 100 comme origine. Le routeur RTA va remarquer que cette mise à jour est issue de son propre AS et l'ignorera.

ccnp_cch 17 iBGP iBGP est utilisé si un AS doit agir comme un système de transit pour d'autres AS. Vous pourriez vous poser la question: pourquoi ne pouvons nous pas faire la même chose en apprenant les routes via eBGP et en les redistribuant dans un IGP puis de nouveau dans un autre AS? C'est faisable, mais iBGP offe plus de souplesse et des méthodes plus efficaces pour échanger les informations dans un AS; par exemple iBGP fournit des moyens pour controler quel est le meilleur point de sortie de l'AS en utili- sant l'attribut "local preference". AS300 RTE AS AS400 RTC RTA AS RTB RTD iBGP RTA(config)#router bgp 100 RTA(config-router)#neighbor remote-as 100 RTA(config-router)#neighbor remote-as 300 RTA(config-router)#network RTB(config)#router bgp 100 RTB(config-router)#neighbor remote-as 100 RTB(config-router)#neighbor remote-as 400 RTB(config-router)#network RTC(config)#router bgp 400 RTC(config-router)#neighbor remote-as 100 RTC(config-router)#network Note: Un point important à se rappeler est que lorsqu'un émetteur BGP reçoit une mise à jour d'un autre émetteur dans son propre AS (iBGP), l'émetteur BGP qui reçoit ne re- distribuera pas cette informations aux autres émetteurs BGP dans son propre AS. L'émetteur BGP recevant la mise à jour redistribuera cette information aux autres emetteurs BGP en dehors de son AS. C'est pourquoi il est important de maintenir un maillage total entre les émetteurs iBGP dans un AS. Dans le schéma ci-dessus, les routeurs RTA, RTB et RTD utilisent iBGP. Les mises à jour BGP venant de RTB et allant à RTA seront transmises à RTE (Hors de l'AS) et non à RTD (dans l'AS). C'est pourquoi un voisinage iBGP doit être établi entre RTB et RTD pour ne pas couper le flux de mises à jour.

ccnp_cch 18 L'algorithme de décision de BGP Une fois que BGP a reçu des mises à jour au sujet des différentes destinations dans différents AS, le protocole doit décider quel chemin choisir pour atteindre une desti- nation donnée. BGP choisira un seul chemin pour atteindre une destination donnée. Le processus de décision est basé sur les attributs tels que next-hop, administrtive weights, local preference, route origin, path length, origin code, metric,…. BGP propagera toujours le meilleur chemin vers ses voisins.

ccnp_cch 19 BGP Etude partie 2 L'attribut AS_PATH AS 200 RTB RTA AS AS 300 RTC Chaque fois qu'une mise à jour de route traverse un AS, le numéro d'AS est ajouté à cette mise à jour. L'attribut AS_PATH est une liste des numéros d'AS qu'une route traverse pour atteindre une destination. Un AS_SET est un ensemble ordonné de tous les AS qui ont été traversés. Dans l'exemple ci-dessus, le réseau est annoncé par RTB dans l'AS200. Quand la mise à jour traverse l'AS 300, le routeur RTC ajoute son numéro d'AS à la mise à jour. Quand la mise à jour atteint RTA, le réseau a deux numéros d'AS attachés (AS 200 et AS 300). Aussi le chemin popur atteindre le réseau est : AS 300, AS 200. Le même raisonnement s'applique aux réseaux et Le routeur RTB doit prendre le chemin AS 300, AS 100 pour atteindre le réseau Le routeur RTC doit prendre un chemin qui traverse l'AS 200 pour joindre le réseau et un chemin qui traverse l'AS 100 pour joindre le réseau L'attribut Origin L'attribut Origin est un attribut obligatoire qui définit l'origine de l'information de chemin. L'attribut Origin peut prendre trois valeurs. IGP : Le NLRI (Network Layer Reachability Information) est interne à l'AS d'origine. Ceci se produit quand on utilise la commande bgp network ou quand l'IGP est redis- tribué dans BGP. L'origine de l'information de chemin sera IGP. Ceci est indiqué par la lettre "i" dans la table de routage BGP.

ccnp_cch 20 EGP : Le NLRI est appris via EGP (Exterior Gateway Protocol). Ceci est indiqué par la "e" dans la table de routage BGP. INCOMPLETE : Le NLRI est inconnu ou appris par d'autres moyens. Ceci se produit quand on redistribue une route statique dans BGP. Ceci est indiqué par un "?" dans la table de routage BGP. RTA AS RTB iBGP RTE AS RTA(config)#router bgp 100 RTA(config-router)#neighbor remote-as 100 RTA(config-router)#neighbor remote-as 300 RTA(config-router)#network RTA(config-router)#redistribute static RTA(config)#ip route null0 RTB(config)#router bgp 100 RTB(config-router)#neighbor remote-as 100 RTB(config-router)#network RTB(config)#router bgp 300 RTB(config-router)#neighbor remote-as 100 RTB(config-router)#network Le routeur RTA atteindra le réseau via: AS300 i (ce qui signifie que le prochain AS est le 300 et l'origine de la route est un IGP). Le routeur RTA atteindra également le réseau via: AS100 i (ce qui signifie que la route est dans le même AS et que l'origine de la route est un IGP). Le routeur RTE atteindra le réseau via: AS100 i (ce qui signifie que le prochain AS est le 100 et l'origine de la route est un IGP). RTE atteindra également le réseau via: AS100? (ce qui signifie que le prochain AS est le 100 et que l'origine est incomplète, c'est une route statique).

ccnp_cch 21 L'attribut BGP Next Hop RTA AS RTB iBGP RTC AS L'attribut BGP Next Hop est l'adresse IP du prochain saut qui va être utilisé pour joindre une destination donnée. Pour eBGP, le prochain saut est toujours l'adresse IP du voisin spécifiée dans la commande neighbor. Dans l'exemple ci-dessus, le routeur RTC annoncera le réseau vers RTA avec un prochain saut égal à et RTA annoncera vers RTC avec un prochain saut égal à Pour iBGP, le protocole spécifie que le prochain saut annoncé par eBGP doit être transporté dans iBGP. A cause de cette règle, le routeur RTA annoncera à son voisin iBGP RTB avec comme prochain saut Ainsi pour RTB, le prochain saut pour atteindre est et Vous devez être sur que RTB peut atteindre via un IGP sinon RTB éliminera les paquets destinés à si le prochain saut est inaccessible. Par exemple, si RTB utilise IGRP, vous devrez aussi activer IGRP sur le réseau de RTA. Vous devrez rendre IGRP passif sur la liaison entre RTA et RTC ainsi seuls les paquets BGP seront échangés. RTA# router bgp 100 neighbor remote-as 300 neighbor remote-as 100 network RTB# router bgp 100 neighbor remote-as 100 network RTC# router bgp 300 neighbor remote-as 100 network *RTC annoncera vers RTA avec le prochain saut = *RTA annoncera vers RTB avec le prochain saut = ( le prochain saut externe via eBGP est transmis via iBGP)

ccnp_cch 22 L'attribut BGP Next Hop - Réseau Multi-accès RTA AS RTB RTC AS RTD Cet exemple montre comment le prochain saut se comporte sur un réseau multi-accès tel Ethernet. Supposons que RTC et RTD dans l'AS 300 utilisent OSPF. RTC utilise BGP avec RTA. RTC peut atteindre le réseau via Quand RTC transmet une mise à jour BGP à RTA concernant le réseau , il utilisera comme prochain saut et non sa propre adresse ( ). C'est parce que le réseau entre RTA, RTC et RTD est un réseau Multi-accès et que cela a plus de sens pour RTA d'utiliser RTD comme prochain saut pour atteindre plutot que d'utiliser un saut supplémentaire via RTC. RTC annoncera vers RTA avec le prochain saut

ccnp_cch 23 L'attribut BGP Next Hop - Réseau NBMA RTA AS RTB RTC AS RTD AS 400 FR Si le support commun est un réseau frame-relay ou tout autre réseau NBMA, le com- portement réel sera le même que celui d'un réseau Multi-accès comme Ethernet. RTC annoncera le réseau vers RTA avec le prochain saut Le problème est que RTA n'a pas de PVC direct vers RTD et ne peut pas atteindre le prochain saut. Dans ce cas le routage échouera. Dans le but de remédier à cette situation une commande next-hop-self a été créee. Commande next-hop-self A cause de certains contextes et du prochain saut comme nous l'avons vu dans les exemples précédents, une commande next-hop-self a été créee. La syntaxe est la suivante: neighbor { ip-address|peer-group-name} next-hop-self La commande next-hop-self permet de forcer BGP à utiliser une addresse IP spécifiée comme prochain saut au lieu de laisser le protocole choisir le prochain saut. Dans l'exemple précédent, la configuration suivante résoud notre problème. RTC# router bgp 300 neighbor remote-as 100 neighbor next-hop-self RTC annonce avec le prochain saut =

ccnp_cch 24 BGP Backdoor RTA AS 100 RTB RTC AS AS IGP Considérons le schéma ci-dessus. RTA et RTC utilsent eBGP, RTB et RTC utilisent eBGP. RTA et RTB utilisent un IGP (RIP, IGRP,..). Par définition les lises à jour eBGP ont une distance administrative de 20 qui est plus faible que celle des IGPs. La dis- tance administrative de RIP est de 120 par défaut, celle d'IGRP de 100, 110 pour OSPF et 90 pour EIGRP. RTA va recevoir des mises à jour au sujet du réseau via deux protocoles de routage: eBGP avec une distance administrative de 20 et IGP avec une distance administrative supérieure à 20. Par défaut BGP a les distances suivantes que l'on peut changer par la commande distance. distance bgp external-distance internal-distance local-distance extranal-distance : 20 internal-distance : 200 local-distance : 200 RTA prendra eBGP via RTC car la distance est plus faible. Si nous voulons que RTA apprenne le réseau via RTB (IGP) nous avons deux options: Changer la distance externe eBGP ou la distance de l'IGP. Utiliser BGP backdoor

ccnp_cch 25 BGP backdoor permet à la route apprise avec l'IGP de devenir la route préférée. Utilisez la commande network address backdoor Le réseau configuré est celui que nous voulons atteindre via l'IGP. Pour BGP ce réseau sera traité comme un réseau affecté localement mais il ne sera pas annoncé dans les mises à jour BGP. RTA# router eigrp 10 network router bgp 100 neighbor remote-as 300 network backdoor Le réseau est traité comme une entrée locale, mais il n'est pas annoncé comme une entrée normale de réseau. RTA apprend le réseau de RTB via EIGRP avec une distance administrative de 90 et l'apprend égalemnt de RTC via eBGP avec une distance administrative de 20. Normalement BGP serait préféré mais la commande "backdoor" permet à EIGRP d'être préféré. Synchronisation RTA AS 100 RTB RTC AS AS iBGP RTD RTE a-t-il été propagé avec un IGP? Avant de décrire la synchronisation, étudions le schéma ci-dessus. Le routeur RTC de l'AS 300 transmet des mises à jour pour le réseau RTA et RTB utilisent iBGP aussi RTB va prendre la mise à jour et pourra atteindre le réseau par le prochain saut (rappelons que le prochain saut est transporté via iBGP). pour pouvoir joindre le prochain saut, RTB doit transmettre le trafic vers RTE

ccnp_cch 26 Supposons que le routeur RTA n'a pas n'a pas distribué le réseau dans l'IGP ce qui fait que le routeur RTE n'a pas idée de l'existence du réseau Si le routeur RTB commence à annoncer à l'AS400 qu'il peut joindre le réseau , le trafic venant de RTD et dirigé vers RTB avec la destination va être acheminé et sera rejeté par le routeur RTE. La synchronisation stipule que : Si votre système autonome achemine du trafic pour un AS vers un autre AS, BGP ne doit pas annoncer une route tant que tous les rou- teurs de votre AS n'ont pas appris cette route via IGP. BGP doit attendre que l'IGP ait propagé la route dans l'AS et ensuite il pourra l'annoncer aux noeuds externes. Ceci est appelé synchronisation. Dans l'exemple ci-dessus, le routeur RTB attendra d'avoir reçu l'annonce du réseau via l'IGP avant de transmettre les mises à jour vers RTD. Nous pouvons forcer RTB à penser que la route a été propagée en créeant une route statique dans RTB pointant sur le réseau Il faut être sur que les autres routeurs peu- vent atteindre le réseau autrement il pourra y avoir des problèmes pour atteindre ce réseau. Dévalider la synchronisation Dans certains cas vous n'avez pas besoin de synchronisation. Si votre AS ne passe pas de trafic pour un autre AS ou si tous les routeurs de votre AS utilisent BGP, vous pouvez dévalider la synchronisation. En dévalidant cette fonction vous aurez moins de routes dans votre IGP et BGP convergera plus vite. La dévalidation de la synchronisation, si tous les routeurs de l'AS utilisent BGP et que vous n'utiliserez pas d'IGP, le routeur n'a pas moyen de connaître cela, et le routeur attendra éternellement une mise à jour pour certaines routes avant de l'envoyer aux routeurs externes. Vous devez dévalider la synchronisation manuelle- ment dans ce cas pour que le routage fonctionne normalement : router bgp 100 no synchronisation

ccnp_cch 27 ( Assurez-vous d'avoir exécuter la commande clear ip bgp address pour réinitialser la session à zéro ) RTB# router bgp 100 network neighbor remote-as 400 neighbor remote-as 100 no synchronization !-- RTB inscrit le réseau dans sa table de routage et !-- l'annonce à RTD même s'il n'a pas de chemin avec un IGP pour le !-- réseau RTD# router bgp 400 network neighbor remote-as 100 RTA# router bgp 100 network neighbor remote-as 100 RTA AS 100 RTB RTC AS AS iBGP RTD RTE a-t-il été propagé avec un IGP?

ccnp_cch 28 Attribut Weight RTA AS 100 RTB RTC AS 300 ( ) RTC w=100 AS AS 4 ( ) w=200 L'attribut weight est un attribut défini par Cisco. Le poids ou Weight est utilisé par un processus de sélection du meilleur chemin. Le poids est affecté localement au routeur. C'est une valeur qui n'a de sens que pour le routeur et n'est pas propagée ou transportée dans les mises à jour de routage. Le poids peut être un nombre de 0 à Les chemins qui ont le routeur pour origine ont un poids de par défaut et les autres chemins ont un poids égal à zéro. Les routes qui ont les poids les plus élevés sont préférées quand plusieurs routes existent la même destination. Etudions l'exemple ci-dessus. Le routeur RTA a appris le réseau de l'AS 4 et va propager la mise à jour vers RTC. RTB à également appris le réseau de l'AS 4 et va le propager vers RTC. Le routeur RTC a maintenant deux chemins pour joindre le réseau et doit décider quel chemin prendre. Si sur le routeur RTC nous pouvons fixer un poids plus élevé pour les mises à jour venant de RTA par rapport à celles venant de RTB, cela forcera le routeur RTC à utiliser le routeur RTA comme prochain saut pour atteindre le réseau

ccnp_cch 29 Ceci peit être réalisé avec plusieurs méthodes: En utilisant la commande neighbor neighbor {ip-address|peer-group} weight weight En utilisant les listes d'accès AS_PATH ip as-path access-list access-list-number {permit|deny} as-regular-expression ip-address filter-list access-list-number weight weight En utilisant des route-map RTC# router bgp 300 neighbor remote-as 100 neighbor weight 200 !-- La route vers issue de RTA a le poids 200 neighbor remote-as 200 neighbor weight 100 !-- La route vers issue de RTB aura le poids 100 Les routes avec le poids le plus élevé sont préférées quand plusieurs routes existent vers la même destination. RTA est préféré comme prochain saut. Le même résultat peut être obtenu en utilisant les listes de contrôle d'accès IP AS_PATH et les filtres. RTC# router bgp 300 neighbor remote-as 100 neighbor filter-list 5 weight 200 neighbor remote-as 200 neighbor filter-list 6 weight ip as-path access-list 5 permit ^100$ !-- Ceci autorise uniquement l'AS 100 ip as-path access-list 6 permit ^200$

ccnp_cch 30 Le même résultat peut être obtenu en utilisant les listes de controle d'accès IP AS_PATH et les filtres. RTC# router bgp 300 neighbor remote-as 100 neighbor route-map setweightin in neighbor remote-as 200 neighbor route-map setweightin in... ip as-path access-list 5 permit ^100$... route-map setweightin permit 10 match as-path 5 set weight 200 !-- Tous les paquets de l'AS100 auront le poids 200 route-map setweightin permit 20 set weight 100 !-- Toutes les autres routes auront le poids 100

ccnp_cch 31 Attribut Local preference RTA AS 100 RTB RTC iBGP RTE AS RTCRTD AS 256 AS set local pref 200 local pref = 150 local pref = Local preference est une indication pour l'AS sur le chemin préféré pour sortir de l'AS afin d'atteindre un réseau. Un chemin avec la préférence locale la plus élevée est pré- féré aux autres. La valeur par de la préférence locale est 100. Au contraire de l'attribut "weight" qui est propre au routeur local, local preference est un attribut échangé entre routeurs dans la même AS. Local preference est fixé via la commande bgp default local-preference value fixera la préférence locale dans les mises à jour émises par le routeur vers les autres routeurs voisins de la même AS. Dans le schéma ci-dessus, l'AS256 reçoit des mises à jour pour le réseau depuis deux endroits de l'organisation. La préférence locale va aider à déterminer quel chemin utiliser pour sortir de l'AS256 pour joindre ce réseau. Supposons que RTD est le point de sortie préféré. La configuration suivante va fixer la préférence locale pour les mises venant des AS300 vers l'AS200 et celles des mises à jour venant de l'AS100 à 150. RTC# router bgp 256 neighbor remote-as 100 neighbor remote-as 256 bgp default local-preference 150 RTD# router bgp 256 neighbor remote-as 300 neighbor remote-as 256 bgp default local-preference 200

ccnp_cch 32 Dans la configuration ci-dessus RTC fixera la préférence locale pour toutes les mises à jour à 150. Le routeur RTD fixera la préférence locale à 200 dans toutes les mises à jour. Comme la préférence locale est échangée dans l'AS256, lesrouteurs RTC et RTD vont réaliser que le réseau a une préférence locale plus elevée quand elle provient de l'AS300. Tout le trafic dans l'AS256 pour le réseau sera ache- miné vers le routeur RTD utilisé comme point de sortie. Les route-maps permettent une plus grande flexibilité. Dans l'exemple ci-dessus, toutes les mises à jour reçues par RTD seront marquées avec la préference locale 200 quand elles atteignent ce routeur. Cela signifie que les mises à jour venant de l'AS34 seront également marquées avec une préférence locale 200. Ceci n'est pas vraiment nécessaire. C'est pourquoi on peut utiliser les route-maps pour indiquer quelles sont les mises à jour devant être marquées avec une préférence locale spécifique comme c'est le cas ci-dessous. RTD# router bgp 256 neighbor remote-as 300 neighbor route-map setlocalin in neighbor remote-as ip as-path access-list 7 permit ^300$... route-map setlocalin permit 10 match as-path 7 set local-preference 200 route-map setlocalin permit 20 set local-preference 150 Avec cette configuration, toute mise à jour venant de l'AS300 sera marquée avec une préférence locale de 200. Toutes les autres mises à jour comme celles venant de l'AS34 seront marquées avec une valeur de 150.

ccnp_cch 33 Attribut MED MULTI_EXIT_DISC (INTER_AS) RTA AS 100 RTB RTC AS 400 RTCRTD AS set metric set metric 50 metric=0 set metric L'attribut Metric qui est aussi appelé Multi_EXIT_DISCRIMINATOR, MED (BGP4) ou INTER_AS (BGP3) est une indication pour les voisins externes au sujet du chemin préféré dans un AS. C'est une méthode dynamique utilisée pour influencer un AS sur le chemin à choisir pour une route sachant qu'il y a plusieurs points d'entrée pour cet AS. La valeur la plus basse est celle qui est préférée. Contrairement à la préférence locale, l'attribut Metric est échangé entre AS voisins uniquement. Quand une mise à jour entre dans l'AS avec une certaine métrique, cette métrique est utilisée pour les décisions de routage dans l'AS. Quand la mise à jour est passée à une troisième AS, l'attribut Metric est remis à 0 comme le montre le schéma ci-dessus. La valeur par défaut de l'attribut Metric est 0. A moins que cela ne soit spécifié autement, un routeur comparera les métriques des différents chemins venant des voisins dans le même AS. Pour que le routeur puisse comparer les métriques issues des voisins des différents AS la commande de configu- ration spéciale bgp always-compare-med doit être exécutée sur le routeur. Dans le schéma ci-dessus, l'AS100 prend des informations au sujet du réseau de trois routeurs différents : RTC, RTD et RTB. RTC et RTD sont dans l'AS300 et RTB dans l'AS400. Supposons que nous avons fixé la métrique venant de RTC à 120, la métrique venant de RTD à 200 et la métrique venant de RTB à 50. Cela étant fait, un routeur compare les métriques venant des voisins du même AS, RTA peut seulement comparer la métrique venant de RTC à la métrique venant de RTD et prendra RTC comme prochain saut car la métrique 120 est plus faible que 200. Quand RTA récupère une mise à jour de RTB avec la métrique 50, il ne peut pas la comparer à 120 parce que RTC et RTB sont dans des AS différents (RTA fera son choix d'après d'autres attributs).

ccnp_cch 34 Dans le but de forcer RTA à comparer les métriques nous devons ajouter bgp always-- compare à RTA. Ceci est illustré par les configurations ci-dessous: RTA# router bgp 100 neighbor remote-as 300 neighbor remote-as 300 neighbor remote-as RTC# router bgp 300 neighbor remote-as 100 neighbor route-map setmetricout out neighbor remote-as route-map setmetricout permit 10 set metric 120 RTD# router bgp 300 neighbor remote-as 100 neighbor setmetricout out neighbor remote-as route-map setmetricout permit 10 set metric 200 RTB# router bgp 400 neighbor remote-as 100 neighbor route-map setmetricout out.... route-map setmetricout permit 10 set metric 50 Avec les configurations ci-dessus, RTA prendra RTC comme prochain saut si nous considérons que tous les autres attributs sont les mêmes. Dans le but d'avoir RTB inclus dans la comparaison des métriques, nous devons configurer RTA comme suit: RTA# router bgp 100 neighbor remote-as 300 neighbor remote-as 300 neighbor remote-as 400 bgp always-compre-med Dans ce cas RTA prendra RTB comme prochain saut pour joindre le réseau

ccnp_cch 35 La métrique peut aussi être fixée pendant la redistribution des routes dans BGP en utilisant la commande default-metric number. Supposons que dans l'exemple ci-dessus RTB injecte un réseau via une route statique dans l'AS100: RTB# router bgp 400 redistibute static default-metric 50 ip route null 0 !-- Oblige RTB à annoncer le réseau avec une métrique de 50 L'attribut Community (Communauté) L'attribut Community est un attribut optionnel dont la valeur est comprise entre 0 et L'attribut Community est une façon de grouper des destinations dans une communauté et d'appliquer des décisions de routage à cette communauté. On peut utiliser les route-map pour paramétrer les attributs de communauté. La commande set de route map a la syntaxe suivante : set community community-number [additive] Les communautés prédéfinies sont : no-export ( Ne pas annoncer les voisins eBGP, garder cette route dans l'AS) no-advertise (Ne pas annoncer cette route en interne ou vers l'extérieur) internet (Annoncer cette route vers la communauté Internet, tout routeur appartenant à celle-ci) local-AS ( Utiliser les scénarios de confédérations pour éviter de transmetttre les paquets hors de l'AS local) Un exemple de route-map avec la communauté configurée: route-map communitymap match ip address 1 set community no-advertise ou route-map communitymap match ip address 1 set community 200 additive Si le mot-clé additive n'est pas configuré, 200 remplace toute communauté existante. Si on utilise le mot-clé additive, 200 sera ajouté à la communauté.

ccnp_cch 36 Même si on configure l'attribut communauté, cet attribut n'est pas transmis aux voisins par défaut. Pour transmettre cet attribut aux voisins, nous devons utiliser la commande : neighbor { ip-address|peer-group-name } send-community Voici un exemple : RTA# router bgp 100 neighbor remote-as 300 neighbor send-community neighbor route-map setcommunity out Dans l'IOS Cisco release 12.0 et suivantes, on peut configurer les communautés dans trois formats : décimal, hexadécimel et AA:NN. Par défaut l'IOS utilise le format décimal. Pour configurer et afficher dans le format AA:NN où AA représente l'AS et NN une valeur codée sur deux octets, utilisez la commande ip bgp-community new-format en mode configuration global. Voici un exemple : Sans la commande ip bgp-community new-format, la commande show ip bgp affiche la valeur de l'attribut community au format décimal. Router#show ip bgp BGP routing table entry for /8, version 7 Paths: (1 available, best #1, table Default-IP-Routing) Not advertised to any peer from ( ) Origin IGP, metric 0, localpref 100, valid, external, best Commnunity: Exécutons la commande ip bgp-community new-format en mode de configuration global. Router#conf t Enter confuguration commands, one per line, End with CNTL/Z. Router(config)#ip bgp-community new-format Router(config)#exit Avec la commande ip bgp-community new-format, la valeur de la communauté est affichée au format AA:NN(100:20) dans la sortie de la commande show ip bgp Router#show ip bgp BGP routing table entry for /8, version 9 Paths: (1 available, best #1, table Default-IP-Routing) Not advertised to any peer from ( ) Origin IGP, metric 0, localpref 100, valid, external, best Commnunity: 100:20

ccnp_cch 37 BGP Etude Partie 3 Filtrage BGP L'émission et le réception de mises à jour BGP peuvent être contrôlées en utilisant différentes méthodes de filtrage. Les mises à jour BGP peuvent être filtrées d'après l'information de route, l'information de chemin ou les communautés. Toutes les méthodes mènent aux mêmes résultats, choisir l'une ou l'autre des méthodes dépend de la configuration du réseau. Filtrage de route RTA AS 100 RTB AS 200 RTC AS Dans le but de restreindre les informations de routage que le routeur annonce ou apprend, vous pouvez filtrer BGP d'après les mises à jour de routage venant ou à destination d'un voisin particulier. Pour réaliser cela, une liste de contrôle d'accès est définie et appliquée aux mises à jour venant ou à destination d'un voisin parti- culier. Utiliser la commande suivante en mode de configuration routeu: neighbor {ip-address/peer-group-name} distribute-list access-list-number {in|out} Dans l'exemple suivant, RTB est à l'origine du réseau et l'annonce à RTC. Si RTC veut stopper ces mises à jour pour qu'elles ne se propagent pas vers l'AS 100, nous devrons créer une liste d'accès pour filtrer ces mises à jour et l'appliquer quand RTA fait ses annonces vers RTA. RTC# router bgp 300 network neighbor remote-as 200 neighbor remote-as 100 neighbor distribute-list 1 out access-list 1 deny access-list 1 permit !-- Filtre toutes les mises à jour pour x.x

ccnp_cch 38 L'utilisation de liste de controle d'accès est un peu plus compliquée quand on utilise des super-réseaux. Supposons dans l'exemple page précédente que RTB a des sous- réseaux avec x.x et votre but est de filtrer les mises à jour et d'annoncer uniquement /8 (Cette notation signifie que nous utilisons un masque de 8 bits equivalent à ). La commande access-list 1 permit permet les réseaux /8, /9 et ainsi de suite. Dans le but de restreindre les mises à jour au réseau /8 nous devons utiliser une liste de controle d'accès étendue avec le format suivant: access-list 101 permit ip Cette liste de controle d'accès permet uniquement le réseau /8. Une autre type de filtrage est le filtrage de chemin lequel est décrit dans la section suivante Filtrage de chemin (Path Filtering) RTA AS AS 200 RTC AS Vous pouvez spécifier une liste de controle d'accès sur les mises à jour entrantes et sortantes basée sur les informations de chemin du système autonome BGP. Dans la figure ci-dessus nous pouvons bloquer les mises à jour pour le réseau pour qu'elles n'atteignent pas l'AS 100 en définissant une liste d'accès sur le routeur RTC. Ceci évite à toute mise à jour dont l'origine est l'AS 200 d'être envoyée à l'AS 100. Pour réaliser cela, utilisez les commandes suivantes: ip as-path access-list access-list-number {permit|deny} as-reguler-expression neighbor {ip-address|peer-group-name} filter-list access-list-number {in|out} AS 400 RTB

ccnp_cch 39 L'exemple suivant empêche RTC de transmrttre des mises à jour à RTA pour le réseau RTC# router bgp 300 neighbor remote-as 200 neighbor remote-as 100 neighbor filter-list 1 out ip as-path access-list 1 deny ^200$ ip as-path access-list 1 permit.* Dans l'exemple ci-dessus, la liste d'accès 1 dit: refuser toute mise à jour avec une information de chemin qui débute par 200 (^) et se termine par 200 ($). L'expression ^200$ est une expression régulière avec ^signifiant "débute par" et $ signifiant "se termine par". Comme RTB transmet des mises à jour au sujet du réseau avec une information de chemin débutant avec 200 et se termi- nant par 200, cette mise à jour est en correspondance avec la liste d'accès, elle sera donc refusée. Le symbole.* est une autre expression régulière avec le point signifiant "tout carac- tère" et l'astérisque signifiant "répétition de ce caractère". Ainsi.* signifie "n'importe quelle information de chemin". Ceci est nécessaire pour permettre à toutes les autres mises àjour d'être émises. Que ce serait-il passé si au lieu d'utiliser ^200$ nous avions utilisé ^200? Si nous avions un AS 400 (voir schéma), les mises à jour issues de l'AS 400 auraient eu une infrmation de chemin de la forme (200, 400) avec 200 en tête et 400 en der- nier. Ces mises à jour auraient été en correspondance avec la liste de controle daccès car elles commencent par 200 et le ? indique un test sur 200 uniquement. Elles n'auraient pas été émises vers RTA, ce qui n'est pas le fonctionnement recherché. Une bonne méthode pour vérifier si vous avez implémenté l'expression régulière correcte est d'utiliser la commande show ip bgp regexp regular-expression. Cetre commande montre tous les chemins qui correspondent à l'expression régulière.

ccnp_cch 40 Expression régulière AS Une expression régulière est un motif auquel doit correspondre une chaine de carac- tère entrée. En construisant une expression régulière nous spécifions une chaine de caractères à laquelle doit correspondre une entrée donnée. Dans l'exemple précédent nous avons spécifié ^200$ et nous voulons que les informa- tions de mises à jour entrantes correspondent à ce motif afin de pouvoir prendre une décision. Les expressions régulières sont constituées par: Range (intervalle) Un intervalle est une séquence de caractères encadrée par [ ]. Exemple : [abcd] Atom Un atome est un caratère unique tel que:. (correspondance avec tout caractère) ^ (correspondance avec le début de la chaine entrée) $ (correspondance avec la fin de la chaine entrée) \ (correspondance avec le caractère) _ (correspondance avec une virgule (,), accolade gauche ({), accolade droite (}), début de la chaine d'entrée, fin de la chaine d'entrée, ou espace) Piece Une pièce est un atome suivi par un des symboles suivants: * (Correspond 0 ou plusieurs séquences de l'atome) + (Correspond à au moins 1 ou plusieurs séquences de l'atome) ? (Correspond à l'atome ou au caractère null) Branch Une branche est égale à 0 ou plsieurs pièces chainées Exemples d'expressions régulières: a* ( toute occurence de la lette "a", inclus aucune) a+ ( au moins une occurence de la lettre "a") ab?a ( correspondance avec "aa" ou "aba" _100_ (Via AS 100) ^100$ (origine AS 100) ^100.* (Venant de l'AS100) ^$ (venant de cet AS)

ccnp_cch 41 Filtrage de communauté (Communty filtering) Nous avons déjà vu le filtrage de route et le filtrage as-path. Une autre méthode de filtrage est le filtrage de communauté. Le principe de communauté à déjà été vu et ici nous aurons quelques exemples pur montrer comment l'utiliser. RTA AS 100 RTB AS 200 RTC AS Nous voudrions que RTB positionne l'attribut communauté (community) dans les routes BGP qu'il annonce de telle sorte que RTC ne propage pas ces routes vers ses voisins BGP. L'attribut no-export community est utilisé: RTB# router bgp 200 network neighbor remote-as 300 neighbor send-community neighbor route-map setcommunity out route-map setcommunity match ip address 1 set community no-export access-list 1 permit Notez que nous avons utilisé la commande route-map setcommunity dans le but de marquer la communauté à no-export. Notez également que nous avons du utiliser la commande neighbor send-community pour trasmettre cet attribut dans les mises à jour vers RTC. Quand RTC prend les mises à jour avec l'attribut no-export, il ne les propagera pas vers son voisin BGP externe RTA.

ccnp_cch 42 Dans l'exemple ci-dessous RTB a marqué l'attribut communauté à additive. La valeur sera sera ajoutée à toute valeur de communauté existante devant être transmise vers RTC. RTB# router bgp 200 network neighbor remote-as 300 neighbor send-community out neighbor route-map setcommunity out route-map setcommunity match ip address 2 set community additive access-list 2 permit Une liste de communauté est un groupe de communautés que nous utilisons dans la clause match d'une route-map qui nous permet de filtrer ou de modifier des attributs d'après la liste des numéros de communautés. ip community-list community-list-number {permit|deny} community-number Par exemple nous pouvons définir la route-map match-on-community: route-map match-on-community match community 10 !-- 10 est le numéro de community-list set weight 20 ip community-list 10 permit ! est le numéro de communauté

ccnp_cch 43 Nous pouvons utiliser la configuration de la page précédente pour filtrer ou fixer certains paramètres comme le poids (weight) et la métrique (metric) d'après la valeur de communauté dans certaines mises à jour. Dans l'exemple ci-dessus, RTB transmet des mises à jour vers RTC avec la communauté Si RTC veut fixer le poids (weight) d'après ces valeurs, nous pouvons le faire comme suit: RTC# router bgp 300 neighbor remote-as 200 neighbor route-map check-commuity in route-map check-community permit 10 match community 1 set weight 20 route-map check-community permit 20 match community 2 exact set weight 10 route-map check-community permit 30 match community 3 ip community-list 1 permit 100 ip community-list 2 permit 200 ip community-list 3 permit internet Dans l'exemple ci-dessus, toute route qui a 100 dans son attribut communauté correspondra à la liste 1 et aura un poids fixé à 20. Toute route qui a l'attribut communauté à 200 uniquement correspondra à la liste 2 et aura le poids fixé à 10. Le mot-clé exact statue que la communauté doit être 200 et uniquement 200. La dernière liste de communauté est ici pour s'assurer que les mises à jour ne seront pas éliminées. Rappelez-vous que tout ce qui ne correspond pas sera éliminé par défaut. Le mot-clé internet signifie toutes les routes car toutes les routes sont membres de la communauté internet.

ccnp_cch 44 Voisins BGP et Routes Maps AS AS 200 RTC AS AS 600 RTB AS 400 RTA La commande neighbor peut être utilisée en combinaison avec des route maps pour effectuer du filtrage ou du paramétrage sur des mises à jour de routage entrantes ou sortantes. Les route maps associées avec la commande neighbor non pas d'effet sur les mises à jour entrantes quand la correspondance est basée sur l'adresse IP. neighbor ip-address route-map route-map-name Supposons que dans le schéma ci-dessus nous voulons que le routeur RTC apprenne à partir de l'AS 200 les réseaux situés dans l'AS 200 et rien de plus. Nous voulons également fier le poids des routes acceptées égal à 20. Nous pouvaons réaliser cela avec une combinaison de la commande neighbor et de la liste d'accès as-path. RTC# router bgp 300 network neighbor remote-as 200 neighbor route-map stamp in route-map stamp match as-path 1 set weight 20 ip as-path access-list 1 permit ^200$ Toutes les mises à jour issues de l'AS 200 ont une information de chemin qui débute avec 200 et se termine par 200 seront autorisées. Toutes les autres mises à jour seront éliminées

ccnp_cch 45 Supposons que nous voulons que: Les mises à jour issues de l'AS 200 soient acceptées avec un poids de 20 Les mises à jour issues de l'AS 400 soient rejetées Les autres mises à jour auront un poids de 10 RTC# router bgp 300 network neighbor remote-as 200 neighbor route-map stamp in route-map stamp permit 10 match as-path 1 set weight 20 route-map stamp permit 10 match as-path 2 set weight 10 ip as-path access-list 1 permit ^200$ ip as-path access-list 2 permit ^ * La commande route-map ci-dessus fixera un poids de 20 pour les mises à jour qui sont issues de l'AS 200, fixera un poids de 20 pour toutes les autres mises à jour exceptées celles qui seront issues de l'AS 400. Utilisation de la commande as-path prepend Dans quelques situations, nous sommes obligés de manipuler l'information de chemin pour influencer le processus de décision de BGP. La commande qui est utilisée avec une route map est: set as-path prepend Supposons que dans le schéma précédent, RTC annonce son propre réseau à deux AS fifférents: AS 100 et AS 200. Quand l'information est propagée vers l'AS 600, les routeurs dans l'AS 600 auront une information d'accessibilité pour les réseaux via deux routes différentes, la premières route via AS 100 avec PATH (100, 300) et la seconde via AS 400 avec PATH (400, 200, 300). Supposons que tous les autres attributs sont identiques, l'AS 600 prendra le chemin le plus court et choisira la route via l'AS 100.

ccnp_cch 46 L'AS 300 recevra tout le trafic qui lui est destiné via l'AS 100. Si nous voulons influ- encer la décision de choix de chemin depuis l'AS 300, nous pouvons faire en sorte que le chemin (PATH) au travers de l'AS 100 paraisse plus long que le chemin au travers de l'AS 400. Nous pouvons réaliser cela en ajoutant des numéros d'AS à la fin de l'information de chemin annoncée vers l'AS 100. Une pratique commune est de répéter son propre numéro d'AS en utilisant la commande suivante: RTC# router bgp 300 network neighbor remote-as 100 neighbor route-map SETPATH out route-map SETPATH set as-path prepend A cause de la configuration ci-dessus, l'AS 600 recevra des mises à jour au sujet du réseau via l'AS 100 avec une information PATH égale à: (100, 300, 300, 300) qui est un chemin plus long que (400, 200, 300) reçue de l'AS 400. Les Peer Group BGP AS AS 200 AS RTB RTA RTH RTA RTE RTF RTG RTC Un peer group BGP est un groupe de voisins BGP avec les mêmes politiques de mise à jour. Les politiques de mise à jour sont usuellement fixées par des routes maps, des distribute-list ou des filter-list, Au lieu de définir les mêmes politiques de mises à séparément sur chaque voisin, nous définissons un nom de "Peer Group" et nous affectons ces politiques de mise à jour au "Peer Group". Les membres du "Peer Group" héritent de toutes les options de configuration du Peer-Group. Les membres peuvent être aussi configurés de manière à supplanter ces options si celles-ci n'affectent pas les mises à jour sortantes; vous pouvez supplanter uniquement les options configurées pour les mises à jour entrantes.

ccnp_cch 47 Pour définir un "Peer Group", il faut utiliser la commande suivante: neighbor peer-group-name peer-group Dans l'exemple suivant nous verrons comment les Peer groups sont appliqués aux voisins BGP internes et externes. RTC# router bgp 300 neighbor internalmap peer-group neighbor internalmap remote-as 300 neighbor internalmap route-map SETMETRIC out neighbor internalmap filter-list 1 out neighbor internalmap filter-list 2 in neighbor peer-group internalmap neighbor peer-group internalmap neighbor peer-group internalmap neighbor filter-list 3 in Dans la configuration ci-dessus, nous avons défini un peer-group nommé internalmap et nous avons défini des politiques pour ce groupe, telle une route map SETMETRIC pour fixer la métrique à 5 et deux listes de filtres (list 1 et list 2). Nous avons appliqué le peer-group à tous les voisins internes RTE, RTF et RTG. Nous avons défini une filter-list 3 pour le voisin RTE qui remplace la filter-list 2 dans le peer-group. Notez que l'on peut supplanter uniquement les options qui affectent les mises à jour entrantes. Maintenant regardons comment on peut utiliser les peer-group avec des voisins exter- nes. Dans le même schéma, nous allons configurer RTC avec un peer-group appelé externalmap et nous l'appliquerons aux voisins externes. RTC# router bgp 300 neighbor externalmap peer-group neighbor externalmap route-map SETMETRIC neighbor externalmap filter-list 1 out neighbor externalmap filter-list 2 in neighbor remote-as 100 neighbor peer-group externalmap neighbor remote-as 600 neighbor peer-group externalmap neighbor remote-as 200 neighbor peer-group internalmap neighbor filter-list 3 in Notez que dans la configuration ci-dessus, nous avons défini les commandes neighbor avec remote-as hors du peer-group car il y a plusieurs AS externes. Aussi nous effec- tuerons un remplacement pour les mises à jour entrantes du voisin en affectant la filter-list 3.

ccnp_cch 48 BGP Etude Partie 4 CIDR et Adresses Agrégées AS AS 200 RTC AS RTB RTA Une des améliorations principales de BGP4 par rapport à BGP3 est le CIDR (Classless Inter-Domain Routing) ou super-réseau. Il n'y a plus de notion de classes A, B,C. Par exemple le réseau qui n'est pas une adresse légale de réseau de classe B est maintenant un super-réseau légal représenté par /16 où 16 représente le nombre de bits du masque de réseau. Cela est équivalent à Les agrégations sont utilisées pour minimiser la taille des tables de routage. L'agréga- tion est un processus de combinaison des caractéristiques de plusieurs routes différen- tes de telle manière qu'une seule route soit annoncée. Dans l'exemple ci-dessous, RTB génère une route pour le réseau Nous allons configurer RTB pour qu'il pro- page un super-réseau pour la route vers RTA. RTB# router bgp 200 neighbor remote-as 300 network RTC# router bgp 300 neighbor remote-as 200 neighbor remote-as 100 network aggregate-address RTC va propager l'adresse agrégée vers RTA.

ccnp_cch 49 Commandes aggregate Il y a une grande variété de commandes aggregate. Il est important de comprendre com- ment chacune d'elles fonctionne afin d'obtenir la bonne agrégation. La première com- mande est celle utilisée dans l'exemple précédent. aggregate-address address mask Ceci permettra d'annoncer le préfixe de route et tous les autres préfixes de routes spéci- fiques. La commande aggregate-address propagera un réseau mais n'empêchera pas d'être aussi propagé vers RTA. Le résultat de ceci est que les deux routes et seront propagées vers RTA. C'est cela que nous appelons annoncer le préfixe de route et les préfixes de routes plus spécifiques. Notez que vous ne pouvez pas agéger une adresse si vous n'avez pas de route plus spé- cifique pour cette adresse dans la table de routage BGP. Par exemple RTB ne peut pas générer une agrégationpour s'il n'a pas d'entrée plus spécifique pour dans sa table de routage BGP. La route plus spécifique peut aussi avoir été injectée dans la table de routage BGP via des mises à jour entran- tes venant d'autres AS, d'une redistribution de routes venant d'un IGP, d'une route statique dans BGP ou via la commande network Dans le cas où nous voudrions que RTC propage le réseau uniquement et pas la route spécifique, nous devrions utiliser la commande suivante: aggregate-address address mask summary-only Cette commande fera que seul le préfixe sera annoncé, toutes les routes plus spécifi- ques ne le seront pas. La commande aggregate summary-only propagera le réseau et supprimera la route plus spécifique Notez que si nous agrégeons un réseau qui est injecté dans BGP via la commande network (network sur RTB) alors l'entrée pour ce réseau sera toujours pré- sente dans les mises à jour BGP bien que nous utilisions la commande "aggregate summary-only". L'exemple CIDR à venir traite cette situation. aggregate-address address mask as-set Cette commande annonce le préfixe et les routes plus spécifiques mais inclut l'informa- tion as-set dans l'information de chemin des mises à jour de routage. aggregate as-set Cette commande sera vue dans un exemple des sections qui suivent. Dans le cas où nous voudrions supprimer des routes plus spécifiques lorsque l'on fait l'agrégation, on peut définir une route map et l'appliquer aux agrégations. Ceci nous permettra d'être plus sélectif sur les routes spécifiques à supprimer dans les annonces.

ccnp_cch 50 aggregate-address address mask suppress-map map-name Ceci permet d'annoncer le préfixe et les routes plus spécifiques mais supprime les an- nonces d'après le contenu de la route map. Dans le schéma précédent, si nous voulons agréger le préfixe et supprimer la route plus spécifique et auto- riser à êtee propagée, nous pouvons utiliser la commande suivante: route-map CHECK permit 10 match ip address 1 access-list 1 permit access-list 1 deny Par définition la suppres-map fait que tous les paquets permis par la liste d'accès seront supprimés des mises à jour. Ensuite la route-map est appliquée à la commande aggregate. RTC# router bgp 300 neighbor remote-as 200 neighbor remote-as 100 network aggregate-address suppress-map CHECK Une autre variante est : aggregate-address address mask attribute-map map-name Cette commande permet de fixer les attributs tels que la métrique lorsque les agréga- tions sont transmises. La route map suivante lorsqu'elle est appliquée avec la com- mande aggregate attribute-map fixera l'origine des agrégations comme venant d'un IGP. route-map SETORIGIN set origin igp aggregate-address attribute-map SETORIGIN

ccnp_cch 51 CIDR exemple 1: AS AS 200 RTC AS RTB RTA Objectif: Permettre à RTB d'annoncer le préfixe et de supprimer toutes les routes plus spécifiques. Le problème est que le réseau est local à l'AS200, ce qui signifie que l'AS200 est l'orogine du réseau Vous ne pouvez pas avoir RTB générant un préfixe sans générer une entrée pour même si vous utilisez la commande aggregate summary-only car RTB est l'origine du réseau Il y a deux solutions à ce problème. La première solution est d'utiliser une route statique et de la redistribuer dans BGP. Le résultat est que RTB annoncera l'agrégation avec une origine incomplète(?). RTB# router bgp 200 neighbor remote-as 300 redistribute static !-- Ceci génère une mise à jour pour !-- avec une origine "incomplète" ip route null0 La seconde solution, en plus d'une route statique, ajoute une entrée avec la commande network. Cela a le même effet sauf que l'origine de la mise à jour sera fixée à IGP. RTB# router bgp 200 network mask neighbor remote-as 300 !-- Ceci marque la mise à jour avec origine IGP redistribute static ip route null0

ccnp_cch 52 CIDR exemple 2: Les AS-SETS sont utilisés dans l'agrégation pour réduire la taille de l'information de chemin en marquant le numéro d'AS une seule fois sans tenir compte du nombre de fois où ce numéro d'AS est apparu dans les chemins qui ont été agrégés. La commande as-set aggregate est utilisée dans les situations où l'agrégation entraine la perte d'infor- mation concernant l'attribut path. Dans l'exemple suivant, RTC prend les mises à jour au sujet du réseau de RTA et celles pour le réseau de RTB. Supposons que RTC veut agréger le réseau /8 et le transmet à RTD. RTD ne connaîtra pas l'origine de cette route. En ajoutant la commande aggregate as-set nous forçons RTC à générer une information de chemin sous la forme d'un ensemble { }. Toute l'information de chemin est incluse dans cet ensemble sans tenir compte de l'ordre des AS. AS AS 200 RTC AS RTB RTA RTD AS RTB# router bgp 200 network neighbor remote-as 300 RTA# router bgp 100 network neighbor remote-as 300

ccnp_cch 53 Cas N°1: RTC n'utilise pas la commande as-set. RTC transmettra une mise à jour /8 à RTD avec l'information de chemin (300) comme si la route était issue de l'AS300. RTC# router bgp 300 neighbor remote-as 200 neighbor remote-as 100 neighbor remote-as 400 aggregate summary-only !-- Ceci fait que RTC transmet des mises à jour vers RTD au sujet !-- du réseau /8 avec aucune indication disant que ! est issu de deux systèmes autonomes différents. !-- Ceci peut créer des boucles dans RTA avait une entrée dans !-- l'AS100. Cas N°2: RTC# router bgp 300 neighbor remote-as 200 neighbor remote-as 100 neighbor remote-as 400 aggregate summary-only aggregate as-set !-- Ceci fait que RTC transmet des mises à jour vers RTD au sujet !-- du réseau /8 avec une indication disant que ! appartient à l'ensemble { }. Les deux sujets suivants, confédération et route reflectors, sont conçus pour les ISP qui voudraient rapidement controler l'explosion de voisinage iBGP dans leurs systèmes autonomes.

ccnp_cch 54 Confédération BGP La confédération BGP est implémentée dans le but de réduire le maillage iBGP à l'inté- rieur de l'AS. L'astuce est de diviser l'AS en de multiples AS et d'affecter le groupe entier à une seule confédération. Chaque AS aura de l'iBGP totalement maillé et des connexions avec les autres AS à l'intérieur de la confédération. Bien que ces AS aient des voisins eBGP avec d'autres AS dans la confédération, elles échangent des informa- de routage comme s'ils utilisaient de l'iBGP; les informations next hop, metric et local preference sont préservées. Pour le monde extérieur, la confédération (groupe d'AS) est vue comme un seul AS. Pour configurer la confédération BGP, utilisez la commande suivante: bgp confederation identifier autonomous-system L'identificateur de confédération sera le numéro d'AS de la confédération. Le groupe d'AS apparait pour le monde extérieur comme un seul AS avec un numéro d'AS corres- pondant à l'dentificateur de confédération. Le voisinage dans la confédération entre les multiples AS est fait avec la commande suivante: bgp confederation peers autonomous-system [autonomous-system] Le schéma suivant représente une confédération: AS AS RTA RTC AS RTD AS AS 50 AS RTD

ccnp_cch 55 Supposons que vous avez un système autonome 500 constitué de neufs annonceurs BGP (d'autres annonceurs non-BGP existent également) mais seuls nous intéressent les annonceurs BGP qui ont des connexions eBGP avec les autres AS). Si vous voulez un maillage iBGP total dans l'AS 500 vous aurez besoin de neuf connexions de voisi- nage pour chaque routeur, 8 voisins iBGP et un voisin eBGP avec les AS externes. En utilisant la confédération nous pouvons diviser l'AS 500 en de multiples AS: AS 50, AS 60 et AS 70. Nous donnons un identificateur de confédération égal à 500 pour l'AS. Le monde externe ne verra que l'AS 500. Pour les AS 50, AS60 et AS 70 nous définis- sons un maillage total de voisins iBGP et nous définissons également une liste de voi- sins de la confédération en utilisant la commande bgp confederation peers. Examinons un exemple de configuration des routeurs RTC, RTD et RTA. Notez que RTA n'a pas connaissance des AS 50, 60 et 70. RTA connait uniquement l'AS 500. RTC# router bgp 50 bgp confederation identifier 500 bgp confederation peers neighbor remote-as 50 (connexion iBGP dans l'AS50) neighbor remote-as 50 (connexion iBGP dans l'AS50) neighbor remote-as 60 (confederation peer AS60) neighbor remote-as 70 (confederation peer AS70) neighbor remote-as 100 (connexion AS externe AS100) RTD# router bgp 60 bgp confederation identifier 500 bgp confederation peers neighbor remote-as 50 (confederation peer AS50) neighbor remote-as 60 (connexion iBGP dans l'AS60) neighbor remote-as 70 (confederation peer AS70) neighbor remote-as 600 (connexion AS externe AS600) RTA# router bgp 100 neighbor remote-as 500 (connexion avec confederation AS500)

ccnp_cch 56 Routes Reflectors Une autre solution pour limiter l'explosion du voisinage iBGP dans un système autono- me est d'utiliser les "Routes Reflectors" (RR). Comme cela a été demontré dans la sec- tion Internal BGP, un annonceur BGP n'annoncera de route apprise via un autre an- nonceur iBGP vers un troisième annonceur iBGP. En assouplissant un peu cette res- triction et en fournissant un contrôle additionnel, nous pouvons autoriser un routeur à annoncer ( refléter-reflect) des routes iBGP apprises vers d'autres annonceurs iBGP. Ceci réduira le nombre de voisins iBGP dans l'AS. RTC AS 100 RTB RTA (RR) Dans les cas normaux, un maillage total iBGP doit être maintenu entre RTA, RTB et RTC dans l'AS 100. En utilisant le concept de réflecteurs de routes, RTC pourra être élu RR (Route Reflector) et avoir un voisinage iBGP partiel avec RTA et RTB. Le voisi- nage entre RTA et RTB n'est pas nécessaire car RTC est un reflecteur de routes pour les mises à jour venant de RTA et de RTB. neighbor route-reflector-client Le routeur avec la commande ci-dessus serait le "Route Reflector" et les voisins qui pointent sur RTC sont les clients de ce RR. Dans notre exemple, RTC serait configuré avec la commande neighbor route-reflector-client pointant sur les adresses IP de RTA et RTB. La combinaison du RR et de ses clients est appelée un cluster. RTA, RTB et RTC formeront un cluster avec un seul RR dans l'AS100. D'autres voisins iBGP du RR qui ne sont pas clients sont appelés non-clients.

ccnp_cch 57 Un système autonome peut avoir plus d'un RR (Route Reflector); un RR traitera les au- tres RR comme tout autre annonceur iBGP. Les autres RR peuvent appartenir au même cluster ou à d'autres clusters. Dans une configuration simple, un AS peut être divisé en de multiples clusters, chaque RR sear configuré comme voisin non-client avec les autres RR dans une topologie totalement maillée. Les clients ne devront pas être voisins avec des annonceurs iBGP hors de leur cluster. Examinons le schéma ci-dessus. RTA, RTB et RTC forment un cluster avec RTC comme RR. D'après RTC, RTA et RTB sont clients il n'a pas de non-client. Rappelez-vous que les clients sont pointés par les RR en utilisant la commande neighbor route-reflector- client. De même RTD est le RR pour les clients RTE et RTF, RTG est un RR dans un troisième cluster. Noterz que RTD, RTC et RTG sont totalement maillés mais que les routeurs dans les clusters ne le sont pas. Quand une route est reçue par un RR, il fera les opérations suivantes: 1. Route d'un voisin non-client: annonce à tous les clients dans le cluster. 2. Route d'un voisin client: annonce à tous les voisins clients et non-clients. 3. Route d'un voisin eBGP: transmet la mise à jour à tous les voisins clients et non-clients AS RTD AS RTE RTF RTG RTC RTA RTB AS (RR) (RR)

ccnp_cch 58 Ci dessous se trouve la configuration relative à la configuration BGP des routeurs RTC, RTD et RTB. RTC# router bgp 100 neighbor remote-as 100 neighbor route-reflector-client neighbor remote-as 100 neighbor route-reflector-client neighbor remote-as 100 neighbor remote-as 100 neighbor remote-as 200 RTB# router bgp 100 neighbor remote-as 100 neighbor remote-as 300 RTD# router bgp 100 neighbor remote-as 100 neighbor route-reflector-client neighbor remote-as 100 neighbor route-reflector-client neighbor remote-as 100 neighbor remote-as 100 Comme les routes iBGP apprises sont reflétées (annoncées), il est possible d'avoir une boucle de routage. Le système "Route Reflector" a quelques méthodes pour éviter cela. Originator-id : C'est un attribut BGP optionnel, non-transitif, qui est crée par le RR et codé sur quatre octets. Cet attribut transportera le routeur-id (RID) du générateur de la route dans l'AS local. Ainsi, si à cause d'une mauvaise configuration l'informa- tion de routage revient au générateur de la route, elle sera ignorée. Cluster-list : Cette information va être traitée dans la section suivante

ccnp_cch 59 Plusieurs RR dans un cluster AS RTD AS RTE RTF RTG RTC RTA RTB AS (RR) (RR) AS 300 AS RTH (RR) Usuellement, un cluster de clients aura un seul RR. Dans ce cas, le cluster sera iden- tifié par le routeur ID du RR. Dans le but d'augmenter la redondance et éviter les points de blocage, un cluster pourra avoir plus d'un RR. Tous les RR d'un même cluster doi- vent être configurés avec un cluster-id codé sur quatre octets ainsi un RR peut recon- naitre les mises à jour venant de RR dans un même cluster. Une cluster-list est une séquence de Cluster-ID que la route a emprunté. Quand un RR annonce une route de ses clients vers des non-clients hors du cluster, il ajoutera le Cluster-ID à la Cluster-list. Si cette mise à jour a une Cluster-list vide, le RR en créera une. En utilisant cet attribut, un RR peut identifier si l'information de routage est re- bouclée vers le même cluster à cause d'une mauvaise configuration. Si le Cluster-ID local est trouvé dans la liste alors l'annonce est ignorée. Dans le schéma ci-dessus, RTD, RTE, RTF et RTH appartiennent à un cluster avec RTD et RTH comme RRs pour me même cluster. Notez la redondance dans ce cas. RTH a un voisinage totalement maillé avec les RRs. Dans le cas où RTD est défaillant, RTH pren- dra sa place.

ccnp_cch 60 Ci-dessous se trouvent les configurations de RTH, RTD, RTf et RTC RTH# router bgp 100 neighbor remote-as 100 neighbor remote-as 100 neighbor route-reflector-client neighbor remote-as 100 neighbor route-reflector-client neighbor remote-as 100 neighbor remote-as 100 neighbor remote-as 300 bgp cluster-id 10 RTD# router bgp 100 neighbor remote-as 100 neighbor remote-as 100 neighbor route-reflector-client neighbor remote-as 100 neighbor route-reflector-client neighbor remote-as 100 neighbor remote-as 100 neighbor remote-as 400 bgp cluster-id 10 RTF# router bgp 100 neighbor remote-as 100 neighbor remote-as 100 neighbor remote-as 500 RTC# router bgp 100 neighbor remote-as 100 neighbor route-reflector-client neighbor remote-as 100 neighbor route-reflector-client neighbor remote-as 100 neighbor remote-as 100 neighbor remote-as 100 neighbor remote-as 200 Notez que l'on pas besoin de la commande cluster pour RTC car un seul RR existe dans ce cluster.

ccnp_cch 61 Une chose importante à noter est que les peer groups n'étaient pas utilisés dans cette configuration. Si les clients dans un cluster ne doivent pas avoir de voisinage iBGP direct entre eux et qu'ils n'échangent pas de mises à jour au travers du RR alors les Peer Groups ne doivent pas être utilisés. Si des Peer Group avaient été configurés, le retrait potentiel de la source d'une route sur le RR serait transmis à tous les clients dans le cluster et pourrait poser des problèmes. La sous-commande bgp client-to-client reflection est validée par défaut sur le RR. Si la réflexion BGP client à client n'était pas validée sur le RR et qu'une redondance de voisinage BGP était fai entre les clients alors l'utilisation des Peer Groups serait correcte. Routes Reflector et annonceurs BGP conventionnels Il est normal dans AS d'avoir des annonceurs BGP qui ne comprennent pas le concept de réflecteurs de routes. Nous appellerons ces routeurs des annonceurs BGP conven- tionnels. Le principe de "Route Reflector" va permettre la coexistence des annonceurs BGP conventionnels. Ces routeurs pouvant être membre d'un groupe client ou d'un groupe non-client. Ceci va permettre la migration aisée et graduelle du modèle iBGP courant vers le modèle "Route Reflector". On pourrait commencer par la création de clients en configurant un seul routeur comme RR et en laissant les autres RR et leurs clients comme des voisins iBGP classiques. Ensuite d'autres clusters pourraient être crées progressivement. AS RTD AS RTE RTF RG RTC RTA RTB (RR) AS AS

ccnp_cch 62 Dans le schéma de la page précédente, RTD, RTE et RTF ont le concept de réflexion de route. RTC, RTA et RTB sont ce que nous appelons des routeurs conventionnels et ne peuvent pas être configurés comme RR. Un maillage iBGP normal pourrait être fait entre ces routeurs et RTD. Plus tard, lorsque l'on sera prêt à migrer, RTC pourra être configuré comme RR avec RTA et RTB comme clients. Les clients n'ont pas besoin de comprendre le principe de réflexion de route. Seuls les RR auront besoin d'être mis à jour. Les configurations de RTD et RTC sont les suivantes: RTD# router bgp 100 neighbor remote-as 100 neighbor route-reflector-client neighbor remote-as 100 neighbor route-reflector-client neighbor remote-as 100 neighbor remote-as 100 neighbor remote-as 100 neighbor remote-as 300 RTH# router bgp 100 neighbor remote-as 100 neighbor remote-as 100 neighbor remote-as 100 neighbor remote-as 400 Quand nous serons prêts à mettre à jour RTC et de faire de lui un RR, nous retirerons le maillage iBGP total et nous aurons RTA et RTB comme clients de RTC. Eviter le bouclage des informations de routage Nous avons mentionné précédenment deux attributs utilisés pour éviter une boucle de routage potentielle: originator-id et cluster-list. Un autre moyen pour contrôler les boucles est de mettre plus de restrictions sur la clause set des route map en sortie. La clause set pour une route map en sortie n'af- fecte pas les routes reflétées par les voisins iBGP. Des restrictions supplémenaires sont également mises sur l'attribut next-hop-self qui est une option de configuration par voisin. Quand cette option est utilisée sur les RR elle affectera le prochain saut des routes eBGP apprises car le prochain saut des routes reflétées ne doit pas être changé.

ccnp_cch 63 Suppression temporaire de route La suppression temporaire de route (Introduction dans la version 11.0 de l'IOS Cisco) est un mécanisme utilisé pour minimiser l'instabilité causée par le basculement perma- nent de route et l'instabilité introduite dans le réseau. Pour réaliser cela, des critères sont définis pour identifier avec un comportement instable. Une route instable prend une pénalité pour chaque basculement (1000). Dès que le cumul des pénalités atteint un seuil appelé "suppress-limit", l'annonce de la route est supprimée. La pénalité va être diminuée exponentionnellement après un délai appelé "half-time". Lorsque la péna- lité décroît en-dessous d'un seuil appelé "reuse-limit", l'annonce de la route sera revali- dée. Les routes, externes à un AS, apprises via iBGP ne seront pas gérées par cette fonction. Ceci a pour but d'éviter que les voisins iBGP aient des pénalités élevées à cause des routes externes à l'AS. La pénalité sera diminuée par pas de 5 secondes et les routes seront revalidées avec un pas de 10 secondes. L'information de suppression est gardée tant que la pénalité en dessous de la moitié de la valeur "reuse-limit". A l'initialisation la suppression temporaire n'est pas validée par défaut. Ceci peut être changé si cela est nécessaire. Voici la liste des commandes utilisées pour controler la suppression temporaire de route. bgp dampening - (valide la fonction) no bgp dampening - (dévalide la fonction) bgp dampening half-life-time ( change la valeur half-life) Commande qui permet de changer tous les paramètres en une seule fois: bgp dampening half-time reuse suppress maximum-suppress-time half-life-time ( mn, 15 min par défaut) reuse-value (1 à 20000, 750 par défaut) suppress-value (1 à 20000, 2000 par défaut) max-suppress-time (durée maximum de suppression, 1 à 255, 4 fois half-life-time par défaut)

ccnp_cch 64 RTD AS 100 AS 300 RTB S S1 S L0 RTB est configuré pour la suppression temporaire de route avec les paramètres par défaut. En supposant que la liaison vers RTD est, la table de routage de RTB est la suivante: RTB#show ip bgp BGP table version is 24, local router ID is Status codes: s suppressed, d damped, h history, * valid > best, i - internal Origin codes: i - IGP, e -EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> i *> i Pour simuler une route instable, utilisez la commande clear ip bgp sur RTD. La table BGP de RTB ressemblera à cela: RTB#show ip bgp BGP table version is 24, local router ID is Status codes: s suppressed, d damped, h history, * valid > best, i - internal Origin codes: i - IGP, e -EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path h i *> i

ccnp_cch 65 L'entrée BGP pour le réseau a été mise dans l'état "history". Ceci signifie que nous n'avons pas un bon chemin mais l'information au sujet de la route instable existe toujours. RTB#show ip bgp BGP routing table entry for , version 25 Paths: (1 available, no best path) 300 (history entry) from ( ) Origin IGP, metric 0, external Dampinfo: penalty 910, flapped 1 times in 0:02:03 La route a eu une pénalité mais celle-ci est toujours en dessous de "suppress-limit" (la valeur par défaut est 2000). La route n'est pas encore supprimée. Si la route bas- cule encore quelques fois nous obtiendrons ceci: RTB#show ip bgp BGP table version is 24, local router ID is Status codes: s suppressed, d damped, h history, * valid > best, i - internal Origin codes: i - IGP, e -EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *d i *> i RTB#show ip bgp BGP routing table entry for , version 25 Paths: (1 available, no best path) 300, (suppressed due to dampening) from ( ) Origin IGP, metric 0, external Dampinfo: penalty 2615, flapped 3 times in 0:05:18, reuse in à:27:00 La route a été supprimée. La route sera réutilisée lorsque la pénalité atteindra la valeur "reuse-value", 750 dans notre cas (défaut). L'information de suppression sera validée lorsque la pénalité sera inférieure à la moitié de la valeur "reuse-limit", dans notre cas cela sera 750/2 = 375. Les commandes suivantes sont utilisées pour afficher et effacer les statistiques sur la statibiliré des routes: show ip bgp flap-statistics ( Affiche les statistiques de stabilité pour tous les chemins) show ip bgp flap-statistics regexp regexp (Affiche les statistiques de stabilité pour tous les chemins qui correspondent à regexp) show ip bgp flap-statistics filter-list list (Affiche les statistiques de stabilité pour tous les chemins qui passent le filtre) show ip bgp flap-statistics A.B.C.D m.m.m.m longer-prefixes (Affiche les statisti- ques de statibilité pour des entrées spécifiques).

ccnp_cch 66 show ip bgp neighbor [dampened-routes] | [flap-statistics] (Affiche les statisti- ques de statibilité pour tous les chemins d'un voisin). clear ip bgp flap-statistics (Efface les statistiques de stabilité pour toutes les routes). clear ip bgp flap-statistics regexp regexp (Efface les statistiques de stabilité pour tous les chemins correspondants à regexp). clear ip bgp flap-statistics filter-list list (Efface les statistiques de stabilité pour tous les chemins qui passent le filtre). clear ip bgp flap-statistics A.B.C.D m.m.m.m (Efface les statistiques de stabilité pour une seule entrée). clear ip bgp A.B.C.D flap-statistics (Efface les statistiques de stabilité pour tous les chemins d'un voisin). Comment BGP sélectionne un chemin Maintenant que nous avons étudié les attributs et la terminologie, reférez-vous à l'algorithme de sélection du meilleur chemin BGP vu dans l'etude de BGP partie 1. La section suivante contient un exemple de configuration qui montre les tables de routage telles qu'elles apparaissent dans les routeurs Cisco.

ccnp_cch 67 BGP Etude Partie 5 Exemple de conception pratique RTD AS X.X RTG RTC S AS 300 RTF IBGP RTA RTB S S E E L X.X S0/ S0/ L AS 500 S X.X L AS X.X S2/ L RTE S AS X.X L S S2/ S Nous allons construire la configuration ci-dessus pas à pas et voir ce qui peut être inexact durant la configuration. Même si vous avez un AS connecté à deux ISP via eBGP, il est toujours bon d'avoir iBGP dans votre AS piur avoir un meilleur controle de vos routes. Dans cet exemple, nous utilisons iBGP dans l'AS 100 entre RTA et RTB, OSPF est utilisé comme IGP. Supposons que nous sommes connectés à deux ISP, AS 200 et AS 300, ce qui suit est la première configuration pour tous les routeurs. Ce ne sont pas les configurations finales.

ccnp_cch 68 RTA# hostname RTA ! ip subnet-zero ! interface Loopback0 ip address ! interface Ethernet0 ip address ! interface Serial0 ip address ! router ospf 10 network area 0 ! router bgp 100 network network neighbor remote-as 200 neighbor remote-as 100 neighbor update-source Loopback0 RTF# hostname RTF ! ip subnet-zero ! interface Ethernet0 ip address ! interface Serial1 ip address ! router ospf 10 network area 0

ccnp_cch 69 RTB# hostname RTB ! ip subnet-zero ! interface Serial0 ip address ! interface Serial1 ip address ! router ospf 10 network area 0 ! router bgp 100 network neighbor remote-as 300 neighbor remote-as 100 RTC# hostname RTC ! ip subnet-zero ! interface Loopback0 ip address ! interface Serial2/0 ip address ! interface Serial2/1 ip address ! router bgp 200 network neighbor remote-as 100 neighbor remote-as 400

ccnp_cch 70 RTD# hostname RTD ! ip subnet-zero ! interface Loopback0 ip address ! interface Serial0/0 ip address ! interface Serial0/1 ip address ! router bgp 300 network neighbor remote-as 500 neighbor remote-as 100 RTE# hostname RTE ! ip subnet-zero ! interface Loopback0 ip address ! interface Serial0 ip address ! interface Serial2/1 ip address clockrate ! router bgp 400 network neighbor remote-as 200 neighbor remote-as 500

ccnp_cch 71 RTG# hostname RTG ! ip subnet-zero ! interface Loopback0 ip address ! interface Serial0 ip address ! interface Serial2/1 ip address ! router bgp 500 network neighbor remote-as 300 neighbor remote-as 400 Il est toujours préférable d'utiliser la commande network ou de redistribuer les routes statiques dans BGP pour annoncer les réseaux plutot que de redistribuer IGP dans BGP. C'est pour cela que dans cet exemple on utilise la commande network pour injecter les réseaux dans BGP. Commençons avec l'interface Serial1(S1) de RTB à l'état "down" comme si la liaison entre RTB et RTD n'existait pas. Voici la table de routage de RTB. RTB#show ip bgp Table version is 4, local router ID is Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *i i *i i *i i *i i *>i i *>i i *> Regardons les indications de base contenues dans cette table. Le "i" au début de la li- gne signifie que cette entrée a été apprise via un voisin iBGP. Le "i" à la fin de la ligne indique que l'origine de l'information de chemin est un IGP. L'information de chemin peut être déduite de manière intuitive. Par exemple le réseau est appris via le chemin 200 avec un prochain saut de Notez que toute entrée géné- rée localement, telle que a un prochain saut égal à

ccnp_cch 72 Le symbole > indique que BGP a choisi la meilleure route basée sur l'algorithme de sélection du meilleur chemin. BGP prend le meilleur chemin pour atteindre une desti- nation, l'installe dans la table de routage et l'annonce aux voisins BGP. Notez l'attribut prochain saut. RTB connait le réseau via un prochain saut qui est le prochain saut eBGP transporté dans iBGP. Examinons la table de routage IP. RTB#show ip route Codes: C - connected, S - Static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF inter area E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default Gateway of last resort is not set is subnetted, 1 subnets O [110/75] via , 02:50:45, Serial is subnetted, 1 subnets C is directly connected, Serial0 O [110/74] via , 02:50:46, Serial0 Il semble que BGP n'a crée aucune entrée dans cette table de routage. Il y a deux pro- blèmes que nous allons examiner chacun à leur tour. Le premier problème est le pro- chain saut pour ces entrées, est inaccessible. Ceci est vrai car nous n'avons aucun moyen pour joindre ce prochain saut via IGP(OSPF). RTB n'a pas appris le réseau via OSPF. Nous pouvons activer OSPF sur l'interface Serial0 de RTA, la rendre passive et de cette manière RTB pourra connaitre comment atteindre le prochain saut Après cela, la configuration de RTA sera la suivante. On pourrait changer le prochain saut en utilisant la commande bgp nexthopself entre RTA et RTB. hostname RTA ! ip subnet-zero ! interface Loopback0 ip address ! interface Ethernet0 ip address ! interface Serial0 ip address ! (suite page suivante)

ccnp_cch 73 router ospf 10 passive-interface serial0 network area 0 network area 0 ! router bgp 100 network mask network neighbor remote-as 200 neighbor remote-as 100 neighbor update-source Loopback0 La nouvelle table BGP sur RTB ressemble à cela: RTB#show ip bgp Table version is 4, local router ID is Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *>i i *>i i *>i i *>i i *>i i *>i i *> i Notez que toutes les entrées sont précédées du symbole >, ce qui signifie que BGP peut atteindre le prochain saut. Examinons la table de routage RTB#show ip route Codes: C - connected, S - Static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF inter area E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default Gateway of last resort is not set is subnetted, 1 subnets O [110/75] via , 02:50:45, Serial is subnetted, 1 subnets C is directly connected, Serial0 O [110/74] via , 02:50:46, Serial is subnetted, 1 subnets O [110/138] via , 00:04:47, Serial0 Le second problème est que nous ne voyons toujours pas d'entrée BGP dans la table de routage.

ccnp_cch 74 La seule différence est que est maintenant accessible via OSPF. C'est un problème de synchronisation. BGP ne met pas ses entrées dans la table de routage et ne les enverra pas dans les mises à jour iBGP parcqu'il n'est pas synchronisé avec l'IGP. Notez que RTF n'a pas connaissance des réseaux et car nous n'avons pas encore redistribué BGP dans OSPF. Dans ce scénario si nous dévalidons la synchronisation, les routes apparaissent dans la table de routage mais la connectivité n'est toujours pas établie. Si nous dévalidons la synchronisation sur RTB, voila ce qui arrive: RTB#show ip route Codes: C - connected, S - Static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF inter area E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default Gateway of last resort is not set B [200/0] via , 00:01:07 B [200/0] via , 00:01:07 B [200/0] via , 00:01: is variably subnetted, 2 subnets, 2 masks O [110/75] via , 00:12:37, Serial0 B [200/0] via , 00:01: is subnetted, 1 subnets C is directly connected, Serial0 O [110/74] via , 02:50:46, Serial is variably subnetted, 2 subnets, 2 masks B [200/0] via , 00:01:08 O [110/138] via , 00:12:37, Serial0 La table de routage parait correcte, mail n'est pas possible de joindre ces réseaux car RTF dans le réseau ne sait pas comment les joindre. RTF#show ip route Codes: C - connected, S - Static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF inter area E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default Gateway of last resort is not set is subnetted, I subnets O [110/11] via , 00:14:15, Ethernet is subnetted, 1 subnets C is directly connected, Serial1 C is directly connected, Ethernet is subnetted, 1 subnets O [110/74] via , 00:14:15, Ethernet0

ccnp_cch 75 Ainsi dévalider la synchronisation dans cette situation n'aide pas mais nous en aurons besoin pour résoudre d'autres problèmes plus tard. Redistribuons BGP dans OSPF sur RTA avec une métrique de hostname RTA ! ip subnet-zero ! interface Loopback0 ip address ! interface Ethernet0 ip address ! interface Serial0 ip address ! router ospf 10 redistribute bgp 100 metric 2000 subnets passive-interface serial0 network area 0 network area 0 ! router bgp 100 network mask network neighbor remote-as 200 neighbor remote-as 100 neighbor update-source Loopback0

ccnp_cch 76 La table de routage de RTB ressemble à ceci: RTB#show ip route Codes: C - connected, S - Static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF inter area E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default Gateway of last resort is not set O E [110/2000] via , 00:00:14 O E [110/2000] via , 00:00:14 O E [110/2000] via , 00:00: is variably subnetted, 2 subnets, 2 masks O [110/75] via , 00:00:15, Serial0 O E [110/2000] via , 00:00:15, Serial is subnetted, 2 subnets C is directly connected, Loopback1 C is directly connected, Serial0 O [110/74] via , 00:00:15, Serial is variably subnetted, 2 subnets, 2 masks O E [110/2000] via , 00:00:15, Serial0 O [110/138] via , 00:00:16, Serial0 Les entrées BGP ont disparu car OSPF a une meilleure distance administrative (100) que iBGP (200). De même stoppons la synchronisation sur RTA pour que celui-ci annonce le réseau car il ne pourra pas se synchroniser avec OSPF à cause ee la différence des masques. Nous garderons la synchronisation désactivée sur RTB pour que celui-ci annonce le réseau pour les mêmes raisons que RTA. Passons l'interface Serial1 de RTB à l'état "up" pour voir quelles sont les routes et vali- dons OSPF sur l'interface Serial1 de RTB pour qu'elle soit passive et que RTA puisse connaitre le prochain saut via IGP. Si nous n'exécutons pas cette étape, des boucles de routage peuvent apparaitre car pour obtenir le prochain saut ,, nous devrions passer par un autre chemin via eBGP. Les configurations modifiées de RTA et RTB sont les suivantes: hostname RTA ! ip subnet-zero ! interface Loopback0 ip address ! interface Ethernet0 ip address !

ccnp_cch 77 interface Serial0 ip address ! router ospf 10 redistribute bgp 100 metric 2000 subnets passive-interface Serial0 network area 0 network area 0 ! router bgp 100 no synchronization network network neighbor remote-as 200 neighbor remote-as 100 neighbor update-source Loopback0 RTB# hostname RTB ! ip subnet-zero ! interface Serial0 ip address ! interface Serial1 ip address ! router ospf 10 redistribute bgp 100 metric 2000 subnets passive-interface Serial1 network area 0 network area 0 ! router bgp 100 no synchronization network neighbor remote-as 300 neighbor remote-as 100

ccnp_cch 78 Les tables BGP ressemblent à ceci: RTA#show ip bgp Table version is 117, local router ID is Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> i *>i i *>i i * i *>i i *> i *> i *>i i RTB#show ip bgp Table version is 4, local router ID is Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *>i i * i *> i *> i *>i i * i *>i i *>i i *> i Il y a de multiples façons de concevoir notre réseau pour comuniquer avec deux ISP différents (AS 200 et AS 300). Une de ces façons est d'avoir un ISP principal et un ISP de secours. On peut apprendre les routes partielles de l'un et les par défaut des deux. Dans cet exemple nous recevons les routes partielles de l'AS 200 et les routes locales uniquement de l'AS 300. Les routeurs RTA et RTB génèrent les routes par défaut dans OSPF avec RTB préféré (métrique plus faible). De cette façon, on peut équilibrer le trafic vers les deux ISP. Une asymétrie potentielle peut se produire si le trafic sortant de RTA revient vers RTB. Ceci peut se produire si vous utilisez le même pool d'adresses IP (même réseau princi- pal) lorsque l'on communique avec les deux ISP. A cause de l'agrégation d'adresse, votre AS dans sa totalité peut apparaitre comme une seule entité pour le monde extérieur et les points d'entrée pour votre réseau peuvent être RTA ou RTB. Vous pouvez constater que tout le trafic entrant dans votre AS vient d'un seul point bien que vous ayez plusieurs points d'accès Internet.

ccnp_cch 79 Dans notre exemple, nous avons deux réseaux principaux différents quand on commu- nique avec les deux ISP. Une autre raison de cette asymétrie est la longueur du chemin annoncé pour atteindre votre AS. Un des ISP peut êtrte plus proche d'une destination que d'une autre. Dans notre exemple, le trafic de l'AS 400 destiné à votre réseau entre toujours par RTA car c'est le chemin le plus court. Vous pourriez essayer d'affecter cette décision en ajoutant les iméros de chemins dans vos mises à jour pour que le chemin paraisse plus long (set as-path prepend). mais si l'AS400 a son point de sortie fixé pour être l'AS 200 d'après les attributs tels que local preference, metric ou weight alors vous ne pouvez rien y changer. Ceci est la configuration finale de tous les routeurs: RTA# hostname RTA ! ip subnet-zero ! interface Loopback0 ip address ! interface Ethernet0 ip address ! interface Serial0 ip address ! router ospf 10 redistribute bgp 100 metric 2000 subnets passive-interface Serial0 network area 0 network area 0 default-information originate 2000 ! router bgp 100 no synchronization network network neighbor remote-as 200 neighbor route-map setlocalpref in neighbor remote-as 100 neighbor update-source Loopback0 ip classless ip default-network route-map setlocalpref permit 10 set local-preference 200

ccnp_cch 80 Sur RTA la préférence locale pour les routes venant de l'AS 200 est fixée à 200. Nous avons aussi pris le réseau pour être le réseau par défaut (candidate default) en utilisant la commande ip default-network. Nous avons utilisé la commande default information-originate avec OSPF pour injec- ter la route par defaut dans le domaine OSPF. Nous utilisons également cette commande avec IS-IS et BGP. Pour RIP, est automatiquement redistribuée dans RIP sans configuration additionnelle. Pour IGRP et EIGRP, la route par défaut est injectée dans le domaine IGP après avoir redistribué BGP dans IGRP ou EIGRP. Ainsi avec IGRP et EIGRP on peut redistribuer une route statique dans le domaine IGP. RTF# hostname RTF ! ip subnet-zero ! interface Ethernet0 ip address ! interface Serial1 ip address ! router ospf 10 network area 0 ! ip classles RTB# hostname RTB ! ip subnet-zero ! interface Loopback1 ip address ! interface Serial0 ip address ! interface Serial1 ip address ! router ospf 10 redistribute bgp 100 metric 2000 subnets passive-interface Serial1 network area 0 network area 0 default information-originate metric 1000 !

ccnp_cch 81 router bgp 100 no synchronization network neighbor remote-as 300 neighbor route-map localonly in neighbor remote-as 100 ! ip classless ip default-network ip as-path access-list 1 permit ^300$ ! route-map localonly permit 10 match as-path 1 set local-preference 300 Pour RTB, la préférence locale pour les mises à jour venant de l'AS 300 est fixée à 300, ce qui supérieur à celle des mises à jour iBGP venant de RTA. De cette manière l'AS100 prend RTB pour les route locales AS300. Toutes les autres routes sur RTB (si elles existent) sont transmises en interne avec une préférence locale de 100 ce qui plus faible que celle venant de RTA ainsi RTA sera préféré. Notez que nous annonçons seulement que les routes locales de l'AS 300. Toute information de chemin qui ne correspond pas avec ^300$ sera éliminée. Si vous voulez annoncer les routes locales et les routes des voisins (clients des ISP) vous pouvez utiliser la syntaxe suivante: ^300_[0-9]*. Ceci est la sortie pour l'expresson régulière indiquant les routes locales de l'AS300. RTB#show ip bgp regexp ^300$ BGP table version is 4, local router ID is 203; Status codes: s - suppressed, d - damped, h - history,* - valid > - best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> RTC# hostname RTC ! ip subnet-zero ! interface Loopback0 ip address ! interface Serial2/0 ip address ! interface Serial2/1 ip address !

ccnp_cch 82 router bgp 200 network neighbor remote-as 100 neighbor distribute-list 1 out neighbor remote-as 100 ! ip classless access-list 1 deny access-list 1 permit any Sur RTC, nous avons agrégé /16 et indiqué les routes spécifiques devant être injectées dans l'AS 100. Si votre ISP refuse de faire cette tache, vous devez filtrer sur l'extrémité entrante de l'AS 100. RTD# hostname RTD ! ip subnet-zero ! interface Loopback0 ip address ! interface Serial0/0 ip address ! interface Serial0/1 ip address ! router bgp 300 network neighbor remote-as 500 neighbor remote-as 100 RTG# hostname RTG ! ip subnet-zero ! interface Loopback0 ip address ! interface Serial0 ip address ! interface Serial1 ip address !

ccnp_cch 83 router bgp 500 network aggregate-address summary-only neighbor remote-as 300 neighbor send-community neighbor route-map setcommunity out neighbor remote-as 400 ! ip classless access-list 1 permit access-list 2 permit any route-map setcommunity permit 20 match ip address 2 ! route-map setcommunity permit 10 match ip address 1 set community no-export Sur RTG, nous démontrons l'utilisation du filtrage de communauté en ajoutant une communauté no-export au mises à jour vers RTD. De cette façon RTD n'exportera pas cette route vers RTB. Ce nest pas important dans votre cas car RTB n'accepte pas ces routes. RTE# hostname RTE ! ip subnet-zero ! interface Loopback0 ip address ! interface Serial0 ip address ! interface Serial1 ip address ! router bgp 400 network aggregate-address summary-only neighbor remote-as 200 neighbor remote-as 500 ! ip classles

ccnp_cch 84 RTE agrège l'adresse /16. Voici les tables finales BGP et de routage pour RTA, RTF et RTB. RTA#show ip bgp Table version is 117, local router ID is Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> i *>i i *> i *> i *> i *>i i RTA#show ip route Codes: C - connected, S - Static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF inter area E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default Gateway of last resort is to network is variably subnetted, 2 subnets, 2 masks O E [110/1000] via , 00:41:25, Ethernet0 O [110/138] via , 00:41:25, Ethernet0 C is directly connected, Loopback is variably subnetted, 3 subnets, 3 masks O [110/75] via , 00:41:25, Ethernet0 O [110/74] via , 00:41:25, Ethernet0 B [200/0] via , 00:41:25 C is directly connected, Ethernet is variably subnetted, 2 subnets, 2 masks B [20/0] via , 00:41:26 C is directly connected,Serial0 O*E /0 [110/1000] via , Ethernet0/0 B* [20/0] via , 00:02:38

ccnp_cch 85 RTE agrège l'adresse /16. Voici les tables finales BGP et de routage pour RTA, RTF et RTB. RTF#show ip route Codes: C - connected, S - Static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF inter area E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default Gateway of last resort is to network is variably subnetted, 2 subnets, 2 masks O E [110/1000] via , 00:48:50, Serial1 O [110/128] via , 01:12:09, Serial is variably subnetted, 2 subnets, 2 masks O [110/11] via , 01:12:09, Ethernet0 O E [110/2000] via , 01:12:09, Ethernet is variably subnetted, 2 subnets, 2 masks O [110/65] via , 01:12:09, Serial1 C is directly connected, Serial1 C is directly connected, Ethernet is variably subnetted, 2 subnets, 2 masks O E [110/2000] via , 00:45:01, Ethernet [110/74]via , 01:12:11, Ethernet0 O E [110/2000] via , 00:03:47, Ethernet0 O*E [110/1000] via , 00:03:33, Serial1 Notez que la table de routage de RTF indique que les réseaux de l'AS 300 tel le seront atteint au travers de RTB. Les autres réseaux connus tel seront atteints au travers de RTA. La passerelle par défaut est RTB. Si Un problème apparait entre RTB et RTD, La route par défaut annoncée par RTA est activée avec une métrique de 2000.

ccnp_cch 86 RTB#show ip bgp Table version is 4, local router ID is Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *>i i *> i *>i / i *>i i *>i i *> i RTB#show ip route Codes: C - connected, S - Static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF inter area E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default Gateway of last resort is to network * is variably subnetted, 2 subnets, 2 masks B* [20/0] via , 00:50:46 C is directly connected Serial is variably subnetted, 2 subnetted, 2 subnets, 2 masks O [110/75] via , 01:20:33, Serial0 O E [110/2000] via , 01:15:40, Serial is subnetted, 2 subnets C is directly connected, Loopback1 C is directly connected, Serial0 O [110/74] via , 01:20:33, Serial is variably subnetted, 2 subnets, 2 masks O E [110/2000] via , 01:20:34, Serial0 O [110/138] via , 01:20:34, Serial0 O E [110/2000] via , 00:05:42, Serial0 O*E /0 [110/2000] via , 00:08:33, Serial0