BGP - Etude de BGP ccnp_cch ccnp_cch

Sommaire - Introduction - BGP Etude partie 1 - BGP Etude partie 2 - 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

- BGP Etude partie 5 - Exemple pratique de conception ccnp_cch

ccnp_cch 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

Quand BGP opère entre deux routeurs situés dans le même AS, nous utilisons le terme iBGP (interior BGP). AS300 AS100 eBGP iBGP AS200 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

ccnp_cch 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. AS100 AS300 RTA RTD eBGP 129.213.1.2 iBGP 129.213.1.1 AS200 RTB RTC 175.220.212.1 175.220.1.2 ccnp_cch

RTA(config)#router bgp 100 RTA(config-router)#neighbor 129.213.1.1 remote-as 200 RTB(config)#router bgp 200 RTB(config-router)#neighbor 129.213.1.2 remote-as 100 RTB(config-router)#neighbor 175.220.1.2 remote-as 200 RTC(config)#router bgp 200 RTA(config-router)#neighbor 175.220.212.1 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 129.213.1.1, remote AS 200, external link BGP version 4, remote router ID 175.220.12.1 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

ccnp_cch L'exemple suivant illustre l'utilisation de cette commande: 190.225.11.1 RTB RTA Interface Loopback 1 150.212.1.1 AS100 RTA(config)#router bgp 100 RTA(config-router)#neighbor 190.225.11.1 remote-as 100 RTA(config-router)#neighbor 190.225.11.1 update-source loopback 1 RTB(config)#router bgp 100 RTB(config-router)#neighbor 150.212.1.1 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 (10.212.1.1); 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 190.225.11.1 update-source loopback 1. Cette commande force BGP à utiliser l'adresse IP de l'interface Loopback lorsqu'il communique avec le voisin 190.225.11.1. Notez que RTA a utilisé l'adresse IP de l'interface physique (190.225.11.1) 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. 180.225.11.1 RTB RTA AS100 129.213.1.3 129.213.1.2 AS300 ccnp_cch

RTA(config)#router bgp 100 RTA(config-router)#neighbor 180.225.11.1 remote-as 300 RTA(config_router)#neighbor 180.225.11.1 ebgp-multihop RTB(config)#router bgp 300 RTB(config-router)#neighbor 129.213.1.2 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é (129.213.1.2), 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) 150.10.1.1 160.10.0.0 1.1.1.1 1.1.1.2 RTA RTB 2.2.2.1 2.2.2.2 Loopback 150.10.1.1 Loopback 160.10.1.1 AS100 AS200 RTA(config)#interface Loopback 0 RTA(config-if)#ip address 150.10.1.1 255.255.255.0 RTA(config)#router bgp 100 RTA(config-router)#neighbor 160.10.1.1 remote-as 200 RTA(config-router)#neighbor 160.10.1.1 ebgp-multihop RTA(config-router)#neighbor 160.10.1.1 update-source loopback 0 RTA(config-router)#network 150.10.0.0 RTA(config)#ip route 160.10.0.0 255.255.0.0 1.1.1.2 RTA(config)#ip route 160.10.0.0 255.255.0.0 2.2.2.2 RTB(config)#interface Loopback 0 RTB(config-if)#ip address 160.10.1.1 255.255.255.0 RTB(config)#router bgp 200 RTB(config-router)#neighbor 150.10.1.1 remote-as 100 RTA(config-router)#neighbor 150.10.1.1 ebgp-multihop RTA(config-router)#neighbor 150.10.1.1 update-source loopback 0 RTA(config-router)#network 160.10.0.0 RTB(config)#ip route 150.10.0.0 255.255.0.0 1.1.1.2 RTB(config)#ip route 150.10.0.0 255.255.0.0 2.2.2.2 L'exemple ci-dessus illustre l'utilisation des interfaces loopback, de update-source et de eBGP Multihop. ccnp_cch

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 160.10.1.1; un via 1.1.1.2 et l'autre via 2.2.2.2 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 1.1.1.1, la métrique pour cette mise à jour sera fixée à 5. Ceci peut être illustré par les commandes suivantes: match ip address 1.1.1.1 set metric 5 ccnp_cch

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-path set clns set automatic-tag set community set interface set default interface set ip default next-hop set level set local-preference set mtric set metric-type set next-hop set origin set tag set weight ccnp_cch

ccnp_cch Etudions quelques exemples de route-map: RTA RTB RTC 150.10.0.0 3.3.3.3 3.3.3.4 RTA RTB 2.2.2.2 AS 100 2.2.2.3 RTC 170.10.0.0 AS 300 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 170.10.0.0 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 3.0.0.0 RTA(config-router)#network 2.0.0.0 RTA(config-router)#network 150.10.0.0 RTA(config-router)#passive-interface Serial0 RTA(config-router)#redistribute bgp 100 route-map SETMETRIC RTA(config)#router bgp 100 RTA(config-router)#neighbor 2.2.2.3 remote-as 300 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 170.10.0.0 0.0.255.255 Dans l'exemple ci-dessus, si une route correspond à l'adresse IP 170.10.0.0 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

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 170.10.0.0. 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 2.2.2.2 remote-as 100 RTC(config-router)#neighbor 2.2.2.2 route-map STOPUPDATES out RTA(config-router)#network 170.10.0.0 RTC(config)#route-map STOPUPDATES permit 10 RTC(config-route-map)#match ip-address 1 RTC(config)#access-list 1 deny 170.10.0.0 0.0.255.255 RTC(config)#access-list 1 permit 0.0.0.0 255.255.255.255 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 192.213.0.0 mask 255.255.0.0 RTA(config)#ip route 192.213.0.0 255.255.0.0 null 0 L'exemple ci-dessus indique que le routeur A génèrera une entrée pour le réseau 192.213.0.0/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

ccnp_cch 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 129.213.1.0 et RTC annonce 175.220.0.0. Regardons la configuration de RTC. 129.213.1.0 RTA AS 200 AS 100 RTB RTC 1.1.1.2 RTD 1.1.1.1 AS300 175.222.0.0 Si vous utilisez la commande network, vous aurez: RTC(config)#router eigrp 10 RTC(config-router)#network 175.220.0.0 RTC(config-router)#redistribute bgp 200 RTC(config-router)#default-metric 1000 100 250 100 1500 RTC(config)#router bgp 200 RTC(config-router)#neighbor 1.1.1.1 remote-as 300 RTC(config-router)#network 175.220.0.0 mask 255.255..0.0 !-- Ceci limitera les réseaux issus de votre AS au réseau 175.220.0.0 Si vous utilisez la redistribution, vous aurez: RTC(config-router)#redistribute eigrp 10 ccnp_cch

Ceci entraine que 129. 213. 1. 0 est considéré comme issu de votre AS Ceci entraine que 129.213.1.0 est considéré comme issu de votre AS. Ceci est une mau- vaise affirmation car vous n'êtes pas la source de 129.213.1 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 175.220.0.0 RTC(config-router)#redistribute bgp 200 RTC(config-router)#default-metric 1000 100 250 100 1500 RTC(config)#router bgp 200 RTC(config-router)#neighbor 1.1.1.1 remote-as 300 RTC(config-router)#neighbor 1.1.1.1 distribute-list 1 out RTC(config-router)#redistribute eigrp 10 RTC(config)#access-list 1 permit 175.220.0.0 0.0.255.255 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)#redistribute static RTC(config)#ip route 175.220.0.0 255.255.255.0 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 175.220.0.0 (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

ccnp_cch Exemple: RTA RTB RTC 150.10.0.0 RTA AS 100 RTB AS300 AS 200 RTC 160.10.20.2 170.10.0.0 150.10.20.1 150.10.20.2 160.10.20.1 160.10.0.0 RTA(config)#router bgp 100 RTA(config-router)#neighbor 150.10.20.2 remote-as 300 RTA(config-router)#network 150.10.0.0 RTB(config)#router bgp 200 RTB(config-router)#neighbor 160.10.20.2 remote-as 300 RTB(config-router)#network 160.10.0.0 RTC(config)#router bgp 300 RTC(config-router)#neighbor 150.10.20.1 remote-as 100 RTC(config-router)#neighbor 160.10.20.1 remote-as 200 RTC(config-router)#network 170.10.0.0 Notez que vous n'avez pas besoin des commandes network 150.10.0.0 et netwotk 160. 10.0.0 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 150.10.0.0 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 150.10.0.0 à 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

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". RTA AS 100 150.10.30.1 170.10.20.1 175.10.40.2 RTB 190.10.50.1 RTD iBGP AS500 AS300 RTE 170.10.20.2 170.10.0.0 175.10.40.1 RTC 175.10.0.0 AS400 RTA(config)#router bgp 100 RTA(config-router)#neighbor 190.10.50.1 remote-as 100 RTA(config-router)#neighbor 170.10.20.2 remote-as 300 RTA(config-router)#network 150.10.0.0 RTB(config)#router bgp 100 RTB(config-router)#neighbor 150.10.30.1 remote-as 100 RTB(config-router)#neighbor 175.10.40.1 remote-as 400 RTB(config-router)#network 190.10.50.0 RTC(config)#router bgp 400 RTC(config-router)#neighbor 175.10.40.2 remote-as 100 RTC(config-router)#network 175.10.0.0 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

ccnp_cch 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

ccnp_cch BGP Etude partie 2 L'attribut AS_PATH RTA RTB RTC 100 200 300 170.10.0.0 190.10.0.0 RTB AS 200 180.10.0.0 AS 300 RTC 100 200 300 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éseau190.10.0.0 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 190.10.0.0 a deux numéros d'AS attachés (AS 200 et AS 300). Aussi le chemin popur atteindre le réseau 190.10.0.0 est : AS 300, AS 200. Le même raisonnement s'applique aux réseaux 170.10.0.0 et 180.10.0.0. Le routeur RTB doit prendre le chemin AS 300, AS 100 pour atteindre le réseau 170.10.0.0. Le routeur RTC doit prendre un chemin qui traverse l'AS 200 pour joindre le réseau 190.10.0.0 et un chemin qui traverse l'AS 100 pour joindre le réseau 170.10.0.0. 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

EGP: Le NLRI est appris via EGP (Exterior Gateway Protocol) 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 100 150.10.30.1 170.10.20.1 175.10.40.2 RTB 190.10.50.1 iBGP RTE AS 300 170.10.0.0 170.10.20.2 RTA(config)#router bgp 100 RTA(config-router)#neighbor 190.10.50.1 remote-as 100 RTA(config-router)#neighbor 170.10.20.2 remote-as 300 RTA(config-router)#network 150.10.0.0 RTA(config-router)#redistribute static RTA(config)#ip route 190.10.0.0 255.255.0.0 null0 RTB(config)#router bgp 100 RTB(config-router)#neighbor 150.10.30.1 remote-as 100 RTB(config-router)#network 190.10.50.0 RTB(config)#router bgp 300 RTB(config-router)#neighbor 170.20.10.1 remote-as 100 RTB(config-router)#network 170.10.0.0 Le routeur RTA atteindra le réseau 170.10.0.0 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 190.10.50.0 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 150.10.0.0 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 190.10.0.0 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

ccnp_cch L'attribut BGP Next Hop RTA iBGP RTB RTC AS 100 150.10.30.1 170.10.20.1 RTB 150.10.50.1 iBGP RTC AS 300 170.10.0.0 170.10.20.2 150.10.0.0 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 170.10.0.0 vers RTA avec un prochain saut égal à 170.10.20.2 et RTA annoncera 150.10.0.0 vers RTC avec un prochain saut égal à 170.10.20.1. 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 170.10.0.0 à son voisin iBGP RTB avec comme prochain saut 170.10.20.2. Ainsi pour RTB, le prochain saut pour atteindre 170.10.0.0 est 10.10.20.2 et 150.10.30.1. Vous devez être sur que RTB peut atteindre 170.10.20.2 via un IGP sinon RTB éliminera les paquets destinés à 170.10.0.0 si le prochain saut est inaccessible. Par exemple, si RTB utilise IGRP, vous devrez aussi activer IGRP sur le réseau 170.10.0.0 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 170.10.20.2 remote-as 300 neighbor 150.10.50.1 remote-as 100 network 150.10.0.0 RTB# router bgp 100 neighbor 150.10.30.1 remote-as 100 network 150.10.0.0 RTC# router bgp 300 neighbor 170.10.20.1 remote-as 100 network 170.10.0.0 *RTC annoncera 170.10.0.0 vers RTA avec le prochain saut = 170.10.20.2 *RTA annoncera 170.10.0.0 vers RTB avec le prochain saut = 170.10.20.2 ( le prochain saut externe via eBGP est transmis via iBGP) ccnp_cch

ccnp_cch L'attribut BGP Next Hop - Réseau Multi-accès RTA RTB RTC RTD AS 100 150.10.30.1 170.10.20.1 RTB 150.10.50.1 150.10.0.0 RTC AS 300 170.10.20.2 RTD 170.10.20.3 180.20.0.0 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 180.20.0.0 via 170.10.20.3. Quand RTC transmet une mise à jour BGP à RTA concernant le réseau 180.20.0.0, il utilisera 170.10.20.3 comme prochain saut et non sa propre adresse (170.10.20.2). 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 180.20.0.0 plutot que d'utiliser un saut supplémentaire via RTC. • RTC annoncera 180.20.0.0 vers RTA avec le prochain saut 170.10.20.3 ccnp_cch

ccnp_cch L'attribut BGP Next Hop - Réseau NBMA RTA RTB FR RTC RTD AS 100 150.10.30.1 170.10.20.1 RTB 150.10.50.1 150.10.0.0 RTC AS 300 170.10.20.2 RTD 170.10.20.3 180.20.0.0 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 180.20.0.0 vers RTA avec le prochain saut 170.10.20.3. 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 170.10.20.1 remote-as 100 neighbor 170.10.20.1 next-hop-self RTC annonce 180.20.0.0 avec le prochain saut = 170.10.20.2 ccnp_cch

ccnp_cch BGP Backdoor IGP RTA RTB RTC AS 100 RTB 160.10.0.0 150.10.0.0 RTC AS 300 170.10.0.0 AS 200 2.2.2.2 2.2.2.1 3.3.3.1 3.3.3.3 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 160.10.0.0 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 160.10.0.0 via RTB (IGP) nous avons deux options: • Changer la distance externe eBGP ou la distance de l'IGP. • Utiliser BGP backdoor ccnp_cch

170.10.0.0 a-t-il été propagé avec un IGP? 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 160.10.0.0 router bgp 100 neighbor 2.2.2.1 remote-as 300 network 160.10.0.0 backdoor Le réseau 160.10.0.0 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 160.10.0.0 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 150.10.0.0 RTE 170.10.0.0 a-t-il été propagé avec un IGP? RTA iBGP 3.3.3.4 RTB 2.2.2.2 1.1.1.1 AS 100 170.10.0.0 170.10.0.0 2.2.2.1 1.1.1.2 RTC RTD AS 300 170.10.0.0 AS 400 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 170.10.0.0. RTA et RTB utilisent iBGP aussi RTB va prendre la mise à jour et pourra atteindre le réseau 170.10.0.0 par le prochain saut 2.2.2.1 (rappelons que le prochain saut est transporté via iBGP). pour pouvoir joindre le prochain saut, RTB doit transmettre le trafic vers RTE. ccnp_cch

Supposons que le routeur RTA n'a pas n'a pas distribué le réseau 170 Supposons que le routeur RTA n'a pas n'a pas distribué le réseau 170.10.0.0 dans l'IGP ce qui fait que le routeur RTE n'a pas idée de l'existence du réseau 170.10.0.0. Si le routeur RTB commence à annoncer à l'AS400 qu'il peut joindre le réseau 170.10.0.0, le trafic venant de RTD et dirigé vers RTB avec la destination 170.10.0.0 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 170.10.0.0 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 170.10.0.0. Il faut être sur que les autres routeurs peu- vent atteindre le réseau 170.10.0.0 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

170.10.0.0 a-t-il été propagé avec un IGP? ( Assurez-vous d'avoir exécuter la commande clear ip bgp address pour réinitialser la session à zéro ) RTA AS 100 RTB 150.10.0.0 RTC AS 300 170.10.0.0 AS 400 2.2.2.2 2.2.2.1 iBGP RTD RTE 170.10.0.0 a-t-il été propagé avec un IGP? 3.3.3.3 3.3.3.4 1.1.1.1 1.1.1.2 RTB# router bgp 100 network 150.10.0.0 neighbor 1.1.1.2 remote-as 400 neighbor 3.3.3.3 remote-as 100 no synchronization !-- RTB inscrit le réseau 170.10.0.0 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 170.10.0.0 RTD# router bgp 400 network 175.10.0.0 neighbor 1.1.1.1 remote-as 100 RTA# router bgp 100 network 150.10.0.0 neighbor 3.3.3.4 remote-as 100 ccnp_cch

ccnp_cch Attribut Weight RTA RTB RTC RTC 175.10.0.0 170.10.0.0 190.10.0.0 AS 200 AS 4 RTA RTB 1.1.1.1 2.2.2.2 AS 100 (175.10.0.0) (175.10.0.0) w=200 RTC RTC w=100 AS 300 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 à 65535. Les chemins qui ont le routeur pour origine ont un poids de 32768 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 175.10.0.0 de l'AS 4 et va propager la mise à jour vers RTC. RTB à également appris le réseau 175.10.0.0 de l'AS 4 et va le propager vers RTC. Le routeur RTC a maintenant deux chemins pour joindre le réseau 174.10.0.0 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 175.10.0.0. ccnp_cch

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 1.1.1.1 remote-as 100 neighbor 1.1.1.1 weight 200 !-- La route vers 175.10.0.0 issue de RTA a le poids 200 neighbor 2.2.2.2 remote-as 200 neighbor 3.3.3.3 weight 100 !-- La route vers 175.10.0.0 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 1.1.1.1 remote-as 100 neighbor 1.1.1.1 filter-list 5 weight 200 neighbor 2.2.2.2 remote-as 200 neighbor 2.2.2.2 filter-list 6 weight 200 ... ip as-path access-list 5 permit ^100$ !-- Ceci autorise uniquement l'AS 100 ip as-path access-list 6 permit ^200$ ccnp_cch

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 1.1.1.1 remote-as 100 neighbor 1.1.1.1 route-map setweightin in neighbor 2.2.2.2 remote-as 200 neighbor 2.2.2.2 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

ccnp_cch Attribut Local preference RTE RTB RTA RTC RTD AS 100 RTB RTC iBGP 1.1.1.1 3.3.3.4 RTE AS 300 170.10.0.0 RTD AS 256 AS 34 1.1.1.2 3.3.3.3 set local pref 200 local pref = 150 local pref = 200 128.213.11.1 128.213.11.2 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 170.10.0.0 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 1.1.1.1 remote-as 100 neighbor 128.213.11.2 remote-as 256 bgp default local-preference 150 RTD# router bgp 256 neighbor 3.3.3.4 remote-as 300 neighbor 128.213.11.1 remote-as 256 bgp default local-preference 200 ccnp_cch

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 170.10.0.0 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 170.10.0.0 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 3.3.3.4 remote-as 300 neighbor 3.3.3.4 route-map setlocalin in neighbor 128.213.11.1 remote-as 256 ... 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

ccnp_cch Attribut MED RTA RTB RTC RTD MULTI_EXIT_DISC (INTER_AS) RTA AS 100 RTB RTC 4.4.4.4 3.3.3.2 AS 400 RTD AS 300 2.2.2.1 3.3.3.3 set metric 120 1.1.1.1 1.1.1.2 4.4.4.3 180.10.0.0 set metric 50 metric=0 set metric 200 170.10.0.0 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 180.10.0.0 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

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 2.2.2.1 remote-as 300 neighbor 3.3.3.3 remote-as 300 neighbor 4.4.4.3 remote-as 400 .... RTC# router bgp 300 neighbor 2.2.2.2 remote-as 100 neighbor 2.2.2.2 route-map setmetricout out neighbor 1.1.1.2 remote-as 300 .... route-map setmetricout permit 10 set metric 120 RTD# router bgp 300 neighbor 3.3.3.2 remote-as 100 neighbor 3.3.3.2 setmetricout out neighbor 1.1.1.1 remote-as 300 .... route-map setmetricout permit 10 set metric 200 RTB# router bgp 400 neighbor 4.4.4.4 remote-as 100 neighbor 4.4.4.4 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 2.2.2.1 remote-as 300 neighbor 3.3.3.3 remote-as 300 neighbor 4.4.4.3 remote-as 400 bgp always-compre-med Dans ce cas RTA prendra RTB comme prochain saut pour joindre le réseau 180.10.0.0. ccnp_cch

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 180.10.0.0 255.255.0 null 0 !-- Oblige RTB à annoncer le réseau 180.10.0.0 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 4294967200. 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

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 3.3.3.3 remote-as 300 neighbor 3.3.3.3 send-community neighbor 3.3.3.3 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 6.0.0.0 affiche la valeur de l'attribut community au format décimal. Router#show ip bgp 6.0.0.0 BGP routing table entry for 6.0.0.0/8, version 7 Paths: (1 available, best #1, table Default-IP-Routing) Not advertised to any peer 1 10.10.10.1 from 10.10.10.1 (200.200.200.1) Origin IGP, metric 0, localpref 100, valid, external, best Commnunity: 6553620 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 6.0.0.0. Router#show ip bgp 6.0.0.0 BGP routing table entry for 6.0.0.0/8, version 9 Paths: (1 available, best #1, table Default-IP-Routing) Not advertised to any peer 1 10.10.10.1 from 10.10.10.1 (200.200.200.1) Origin IGP, metric 0, localpref 100, valid, external, best Commnunity: 100:20 ccnp_cch

BGP Etude Partie 3 ccnp_cch 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 2.2.2.2 AS 200 RTC AS 300 2.2.2.1 3.3.3.3 3.3.3.1 160.10.0.0 150.10.0.0 170.10.0.0 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 160.10.0.0 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 170.10.0.0 neighbor 3.3.3.3 remote-as 200 neighbor 2.2.2.2 remote-as 100 neighbor 2.2.2.2 distribute-list 1 out access-list 1 deny 160.10.0.0 0.0.255.255 access-list 1 permit 0.0.0.0 255.255.255.255 !-- Filtre toutes les mises à jour pour 160.10.x.x ccnp_cch

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 160.10.x.x et votre but est de filtrer les mises à jour et d'annoncer uniquement 160.0.0.0/8 (Cette notation signifie que nous utilisons un masque de 8 bits equivalent à 255.0.0.0). La commande access-list 1 permit 160.0.0.0 0.255.255.255 permet les réseaux 160.0.0.0/8, 160.0.0.0/9 et ainsi de suite. Dans le but de restreindre les mises à jour au réseau 160.0.0.0/8 nous devons utiliser une liste de controle d'accès étendue avec le format suivant: access-list 101 permit ip 160.0.0.0 0.255.255.255 0.0.0.0. Cette liste de controle d'accès permet uniquement le réseau 160.0.0.0/8. Une autre type de filtrage est le filtrage de chemin lequel est décrit dans la section suivante Filtrage de chemin (Path Filtering) AS 400 150.10.0.0 160.10.0.0 RTA RTB 2.2.2.2 3.3.3.3 AS 100 AS 200 3.3.3.1 2.2.2.1 RTC AS 300 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 160.10.0.0 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} ccnp_cch

L'exemple suivant empêche RTC de transmrttre des mises à jour à RTA pour le réseau 160.10.0.0. RTC# router bgp 300 neighbor 3.3.3.3 remote-as 200 neighbor 2.2.2.2 remote-as 100 neighbor 2.2.2.2 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 160.10.0.0 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

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

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 2.2.2.2 AS 200 RTC AS 300 2.2.2.1 3.3.3.3 3.3.3.1 160.10.0.0 150.10.0.0 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 160.10.0.0 neighbor remote-as 300 neighbor 3.3.3.1 send-community neighbor 3.3.3.1 route-map setcommunity out route-map setcommunity match ip address 1 set community no-export access-list 1 permit 0.0.0.0 255.255.255.255 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

Dans l'exemple ci-dessous RTB a marqué l'attribut communauté à 100 200 additive. La valeur 100 200 sera sera ajoutée à toute valeur de communauté existante devant être transmise vers RTC. RTB# router bgp 200 network 160.10.0.0 neighbor 3.3.3.1 remote-as 300 neighbor 3.3.3.1 send-community out neighbor 3.3.3.1 route-map setcommunity out route-map setcommunity match ip address 2 set community 100 200 additive access-list 2 permit 0.0.0.0 255.255.255.255 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 200 300 !-- 200 300 est le numéro de communauté ccnp_cch

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é 100 200. Si RTC veut fixer le poids (weight) d'après ces valeurs, nous pouvons le faire comme suit: RTC# router bgp 300 neighbor 3.3.3.3 remote-as 200 neighbor 3.3.3.3 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

ccnp_cch Voisins BGP et Routes Maps RTA RTB RTC AS 100 2.2.2.2 AS 200 RTC AS 300 2.2.2.1 3.3.3.3 3.3.3.1 160.10.0.0 150.10.0.0 190.10.10.0 AS 600 RTB AS 400 RTA 170.10.0.0 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 170.10.0.0 neighbor 3.3.3.3 remote-as 200 neighbor 3.3.3.3 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

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 170.10.0.0 neighbor 3.3.3.3 remote-as 200 neighbor 3.3.3.3 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 ^200 600.* 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 <as-path#><as-path#>........ Supposons que dans le schéma précédent, RTC annonce son propre réseau 170.10.0.0 à 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 150.10.0.0 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

L'AS 300 recevra tout le trafic qui lui est destiné via l'AS 100 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 170.10.0.0 neighbor 2.2.2.2 remote-as 100 neighbor 2.2.2.2 route-map SETPATH out route-map SETPATH set as-path prepend 300 300 A cause de la configuration ci-dessus, l'AS 600 recevra des mises à jour au sujet du réseau 170.10.0.0 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 100 2.2.2.2 AS 200 AS 300 2.2.2.1 1.1.1.2 3.3.3.2 150.10.0.0 RTB RTA RTH 4.4.4.2 RTE RTF RTG RTC 5.5.5.2 5.5.5.1 1.1.1.1 5.6.6.1 5.6.6.2 170.10.0.0 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

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 5.5.5.2 peer-group internalmap neighbor 5.6.6.2 peer-group internalmap neighbor 3.3.3.2 peer-group internalmap neighbor 3.3.3.2 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 2.2.2.2 remote-as 100 neighbor 2.2.2.2 peer-group externalmap neighbor 4.4.4.2 remote-as 600 neighbor 4.4.4.2 peer-group externalmap neighbor 1.1.1.2 remote-as 200 neighbor 1.1.1.2 peer-group internalmap neighbor 1.1.1.2 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 1.1.1.2 en affectant la filter-list 3. ccnp_cch

BGP Etude Partie 4 ccnp_cch CIDR et Adresses Agrégées RTA RTB RTC AS 100 2.2.2.2 AS 200 RTC AS 300 2.2.2.1 3.3.3.3 3.3.3.1 160.10.0.0 150.10.0.0 RTB RTA 170.10.0.0 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 192.213.0.0 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 192.213.0.0/16 où 16 représente le nombre de bits du masque de réseau. Cela est équivalent à 192.213.0.0 255.255.0.0. 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 160.10.0.0. Nous allons configurer RTB pour qu'il pro- page un super-réseau pour la route 160.0.0.0 vers RTA. RTB# router bgp 200 neighbor 3.3.3.1 remote-as 300 network 160.10.0.0 RTC# router bgp 300 neighbor 3.3.3.3 remote-as 200 neighbor 2.2.2.2 remote-as 100 network 170.10.0.0 aggregate-address 160.0.0.0 255.0.0.0 RTC va propager l'adresse agrégée 160.0.0.0 vers RTA. ccnp_cch

Commandes aggregate Il y a une grande variété de commandes aggregate 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 160.0.0.0 propagera un réseau 160.0.0.0 mais n'empêchera pas 160.10.0.0 d'être aussi propagé vers RTA. Le résultat de ceci est que les deux routes 160.0.0.0 et 160.10.0.0 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 160.0.0.0 s'il n'a pas d'entrée plus spécifique pour 160.0.0.0 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 160.10.0.0. Dans le cas où nous voudrions que RTC propage le réseau 160.0.0.0 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 160.0.0.0 255.0.0.0 summary-only propagera le réseau 160.0.0.0 et supprimera la route plus spécifique 160.10.0.0. Notez que si nous agrégeons un réseau qui est injecté dans BGP via la commande network (network 160.10.0.0 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 129.0.0.0 255.0.0.0 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

ccnp_cch 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 160.0.0.0 et supprimer la route plus spécifique 162.20.0.0 et auto- riser 160.10.0.0 à êtee propagée, nous pouvons utiliser la commande suivante: route-map CHECK permit 10 match ip address 1 access-list 1 permit 160.20.0.0 0.0.255.255 access-list 1 deny 0.0.0.0 255.255.255.255 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 3.3.3.3 remote-as 200 neighbor 2.2.2.2 remote-as 100 network 170.10.0.0 aggregate-address 160.0.0.0 255.0.0.0 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 160.0.0.0 255.0.0.0 attribute-map SETORIGIN ccnp_cch

ccnp_cch CIDR exemple 1: RTA RTB RTC AS 100 2.2.2.2 AS 200 RTC AS 300 2.2.2.1 3.3.3.3 3.3.3.1 160.10.0.0 150.10.0.0 RTB RTA 170.10.0.0 Objectif: Permettre à RTB d'annoncer le préfixe 160.0.0.0 et de supprimer toutes les routes plus spécifiques. Le problème est que le réseau 160.10.0.0 est local à l'AS200, ce qui signifie que l'AS200 est l'orogine du réseau 160.10.0.0. Vous ne pouvez pas avoir RTB générant un préfixe 160.0.0.0 sans générer une entrée pour 160.10.0.0 même si vous utilisez la commande aggregate summary-only car RTB est l'origine du réseau 160.10.0.0. 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 3.3.3.1 remote-as 300 redistribute static !-- Ceci génère une mise à jour pour 160.0.0.0 !-- avec une origine "incomplète" ip route 160.0.0.0 255.0.0.0 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 160.0.0.0 mask 255.0.0.0 neighbor 3.3.3.1 remote-as 300 !-- Ceci marque la mise à jour avec origine IGP redistribute static ip route 160.0.0.0 255.0.0.0 null0 ccnp_cch

ccnp_cch 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 160.20.0.0 de RTA et celles pour le réseau 160.10.0.0 de RTB. Supposons que RTC veut agréger le réseau 160.0.0.0/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 100 2.2.2.2 AS 200 RTC AS 300 2.2.2.1 3.3.3.3 3.3.3.1 160.10.0.0 160.20.0.0 RTB RTA 170.10.0.0 RTD AS 400 4.4.4.1 4.4.4.4 RTB# router bgp 200 network 160.10.0.0 neighbor 3.3.3.1 remote-as 300 RTA# router bgp 100 network 160.20.0.0 neighbor 2.2.2.1 remote-as 300 ccnp_cch

Cas N°1: RTC n'utilise pas la commande as-set Cas N°1: RTC n'utilise pas la commande as-set. RTC transmettra une mise à jour 160.0.0.0/8 à RTD avec l'information de chemin (300) comme si la route était issue de l'AS300. RTC# router bgp 300 neighbor 3.3.3.3 remote-as 200 neighbor 2.2.2.2 remote-as 100 neighbor 4.4.4.4 remote-as 400 aggregate 160.0.0.0 255.0.0.0 summary-only !-- Ceci fait que RTC transmet des mises à jour vers RTD au sujet !-- du réseau 160.0.0.0/8 avec aucune indication disant que !-- 160.0.0.0 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 3.3.3.3 remote-as 200 neighbor 2.2.2.2 remote-as 100 neighbor 4.4.4.4 remote-as 400 aggregate 160.0.0.0 255.0.0.0 summary-only aggregate 160.0.0.0 255.0.0.0 as-set !-- Ceci fait que RTC transmet des mises à jour vers RTD au sujet !-- du réseau 160.0.0.0/8 avec une indication disant que !-- 160.0.0.0 appartient à l'ensemble {100 200}. 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

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 600 6.6.6.6 AS 100 5.5.5.5 RTA RTC AS 500 128.213.30.1 RTD AS 60 135.212.14.1 AS 50 AS 70 5.5.5.4 129.210.11.1 129.210.30.2 128.213.10.1 128.213.20.1 ccnp_cch

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 60 70 neighbor 128.213.10.1 remote-as 50 (connexion iBGP dans l'AS50) neighbor 128.213.20.1 remote-as 50 (connexion iBGP dans l'AS50) neighbor 129.210.11.1 remote-as 60 (confederation peer AS60) neighbor 135.212.14.1 remote-as 70 (confederation peer AS70) neighbor 5.5.5.5 remote-as 100 (connexion AS externe AS100) RTD# router bgp 60 bgp confederation identifier 500 bgp confederation peers 50 70 neighbor 128.213.30.1 remote-as 50 (confederation peer AS50) neighbor 129.210.30.2 remote-as 60 (connexion iBGP dans l'AS60) neighbor 6.6.6.6 remote-as 600 (connexion AS externe AS600) RTA# router bgp 100 neighbor 5.5.5.4 remote-as 500 (connexion avec confederation AS500) ccnp_cch

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

ccnp_cch AS 200 (RR) AS 100 RTG (RR) RTD (RR) RTC RTE RTF RTA RTB 8.8.8.8 (RR) AS 100 7.7.7.7 RTG (RR) 4.4.4.4 RTD 3.3.3.3 (RR) RTC 128.213.30.1 6.6.6.6 2.2.2.2 1.1.1.1 5.5.5.5 RTE RTF RTA RTB 12.12.12.12 AS300 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 ccnp_cch

Ci dessous se trouve la configuration relative à la configuration BGP des routeurs RTC, RTD et RTB. RTC# router bgp 100 neighbor 2.2.2.2 remote-as 100 neighbor 2.2.2.2 route-reflector-client neighbor 1.1.1.1 remote-as 100 neighbor 1.1.1.1 route-reflector-client neighbor 7.7.7.7 remote-as 100 neighbor 4.4.4.4 remote-as 100 neighbor 8.8.8.8 remote-as 200 RTB# router bgp 100 neighbor 3.3.3.3 remote-as 100 neighbor 12.12.12.12 remote-as 300 RTD# router bgp 100 neighbor 6.6.6.6 remote-as 100 neighbor 6.6.6.6 route-reflector-client neighbor 5.5.5.5 remote-as 100 neighbor 5.5.5.5 route-reflector-client neighbor 7.7.7.7 remote-as 100 neighbor 3.3.3.3 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

ccnp_cch Plusieurs RR dans un cluster AS 400 AS 300 AS 200 AS 100 (RR) 8.8.8.8 RTD AS 100 5.5.5.5 7.7.7.7 RTE RTF RTG RTC RTA RTB AS500 13.13.13.13 (RR) 3.3.3.3 1.1.1.1 2.2.2.2 4.4.4.4 6.6.6.6 AS 300 AS 400 9.9.9.9 11.11.11.11 10.10.10.10 RTH 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

Ci-dessous se trouvent les configurations de RTH, RTD, RTf et RTC RTH# router bgp 100 neighbor 4.4.4.4 remote-as 100 neighbor 5.5.5.5 remote-as 100 neighbor 5.5.5.5 route-reflector-client neighbor 6.6.6.6 remote-as 100 neighbor 6.6.6.6 route-reflector-client neighbor 7.7.7.7 remote-as 100 neighbor 3.3.3.3 remote-as 100 neighbor 9.9.9.9 remote-as 300 bgp cluster-id 10 RTD# router bgp 100 neighbor 10.10.10.10 remote-as 100 neighbor 5.5.5.5 remote-as 100 neighbor 5.5.5.5 route-reflector-client neighbor 6.6.6.6 remote-as 100 neighbor 6.6.6.6 route-reflector-client neighbor 7.7.7.7 remote-as 100 neighbor 3.3.3.3 remote-as 100 neighbor 11.11.11.11 remote-as 400 bgp cluster-id 10 RTF# router bgp 100 neighbor 10.10.10.10 remote-as 100 neighbor 4.4.4.4 remote-as 100 neighbor 13.13.13.13 remote-as 500 RTC# router bgp 100 neighbor 1.1.1.1 remote-as 100 neighbor 1.1.1.1 route-reflector-client neighbor 2.2.2.2 remote-as 100 neighbor 2.2.2.2 route-reflector-client neighbor 7.7.7.7 remote-as 100 neighbor 4.4.4.4 remote-as 100 neighbor 10.10.10.10 remote-as 100 neighbor 8.8.8.8 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

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 200 AS 300 13.13.13.13 8.8.8.8 AS 100 RG (RR) 4.4.4.4 RTD 3.3.3.3 (RR) RTC 6.6.6.6 1.1.1.1 5.5.5.5 2.2.2.2 RTB RTE RTA RTF AS 400 14.14.14.14 ccnp_cch

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 6.6.6.6 remote-as 100 neighbor 6.6.6.6 route-reflector-client neighbor 5.5.5.5 remote-as 100 neighbor 5.5.5.5 route-reflector-client neighbor 1.1.1.1 remote-as 100 neighbor 2.2.2.2 remote-as 100 neighbor 3.3.3.3 remote-as 100 neighbor 13.13.13.13 remote-as 300 RTH# router bgp 100 neighbor 4.4.4.4 remote-as 100 neighbor 2.2.2.2 remote-as 100 neighbor 14.14.14.14 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

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 (1 - 45 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

RTD AS 100 AS 300 RTB S0 203.250.15.2 192.208.10.6 S1 192.208.10.5 192.208.10.174 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 203.250.15.2 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 *> 192.208.10.0 192.208.10.5 0 0 300 i *> 203.250.15.0 0.0.0.0 0 32768 i Pour simuler une route instable, utilisez la commande clear ip bgp 192.208.10.6 sur RTD. La table BGP de RTB ressemblera à cela: RTB#show ip bgp BGP table version is 24, local router ID is 203.250.15.2 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 192.208.10.0 192.208.10.5 0 0 300 i *> 203.250.15.0 0.0.0.0 0 32768 i ccnp_cch

L'entrée BGP pour le réseau 192. 208. 10 L'entrée BGP pour le réseau 192.208.10.0 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 192.208.10.0 BGP routing table entry for 192.208.10.0 255.255.255.0, version 25 Paths: (1 available, no best path) 300 (history entry) 192.208.10.5 from 192.208.10.5 (192.208.10.174) 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 203.250.15.2 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 192.208.10.0 192.208.10.5 0 0 300 i *> 203.250.15.0 0.0.0.0 0 32768 i RTB#show ip bgp 192.208.10.0 BGP routing table entry for 192.208.10.0 255.255.255.0, version 25 Paths: (1 available, no best path) 300, (suppressed due to dampening) 192.208.10.5 from 192.208.10.5 (192.208.10.174) 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

• 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

BGP Etude Partie 5 ccnp_cch Exemple de conception pratique 203.250.X.X S1 203.250.15.1 RTF L0 203.250.13.41 S0 203.250.15.1 IBGP E0 203.250.14.1 RTA RTB AS 100 S1 192.208.10.6 192.208.X.X S0/0 192.208.10.6 L0 192.208.10.174 AS 200 128.213.X.X RTD S2/1 128.213.63.2 S0/1 192.208.10.2 RTC S2/2 128.213.63.5 L0 128.213.63.130 AS 300 192.211.X.X AS 500 S0 192.208.10.1 RTG L0 195.211.10.174 S1 195.211.10.1 200.200.X.X S1 128.213.63.6 RTE S0 195.211.10.2 L0 200.200.10.1 AS 400 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

RTA# hostname RTA. ip subnet-zero. interface Loopback0 ip address 203 interface Ethernet0 ip address 203.250.14.1 255.255.255.0 ! interface Serial0 ip address 128.213.63.1 255.255.255.252 ! router ospf 10 network 203.250.0.0 0.0.255.255 area 0 ! router bgp 100 network 203.250.13.0 network 203.250.14.0 neighbor 128.213.63.2 remote-as 200 neighbor 203.250.15.2 remote-as 100 neighbor 203.250.15.2 update-source Loopback0 RTF# hostname RTF ! ip subnet-zero ! interface Ethernet0 ip address 203.250.14.2 255.255.255.0 ! interface Serial1 ip address 203.250.15.1 255.255.255.252 ! router ospf 10 network 203.250.0.0 0.0.255.255 area 0 ccnp_cch

ccnp_cch RTB# hostname RTB ! ip subnet-zero ! interface Serial0 ip address 203.250.15.2 255.255.255.252 ! interface Serial1 ip address 192.208.10.6 255.255.255.252 ! router ospf 10 network 203.250.0.0 0.0.255.255 area 0 ! router bgp 100 network 203.250.15.0 neighbor 192.208.10.5 remote-as 300 neighbor 203.250.13.41 remote-as 100 RTC# hostname RTC ! ip subnet-zero ! interface Loopback0 ip address 128.213.63.130 255.255.255.192 ! interface Serial2/0 ip address 128.213.63.5 255.255.255.252 ! interface Serial2/1 ip address 128.213.63.2 255.255.255.252 ! router bgp 200 network 128.213.0.0 neighbor 128.213.63.1 remote-as 100 neighbor 128.213.63.6 remote-as 400 ccnp_cch

ccnp_cch RTD# hostname RTD ! ip subnet-zero ! interface Loopback0 ip address 192.208.10.174 255.255.255.192 ! interface Serial0/0 ip address 192.208.10.5 255.255.255.252 ! interface Serial0/1 ip address 192.208.10.2 255.255.255.252 ! router bgp 300 network 192.208.10.0 neighbor 192.208.10.1 remote-as 500 neighbor 192.208.10.6 remote-as 100 RTE# hostname RTE ! ip subnet-zero ! interface Loopback0 ip address 200.200.10.1 255.255.255.0 ! interface Serial0 ip address 195.211.10.2 255.255.255.252 ! interface Serial2/1 ip address 128.213.63.6 255.255.255.252 clockrate 1000000 ! router bgp 400 network 200.200.10.0 neighbor 128.213.63.5 remote-as 200 neighbor 195.211.10.1 remote-as 500 ccnp_cch

ccnp_cch RTG# hostname RTG ! ip subnet-zero ! interface Loopback0 ip address 195.211.10.174 255.255.255.192 ! interface Serial0 ip address 192.208.10.1 255.255.255.252 ! interface Serial2/1 ip address 195.211.10.1 255.255.255.252 ! router bgp 500 network 195.211.10.0 neighbor 192.208.10.2 remote-as 300 neighbor 195.211.10.2 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 203.250.15.2 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 *i128.213.0.0 128.213.63.2 0 100 0 200 i *i192.208.10.0 128.213.63.2 100 0 200 400 500 300 i *i195.211.10.0 128.213.63.2 100 0 200 400 500 i *i200.200.10.0 128.213.63.2 100 0 200 400 i *>i203.250.13.0 203.250.13.41 0 100 0 i *>i203.250.14.0 203.250.13.41 0 100 0 i *>203.250.15.0 0.0.0.0 0 32768 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 128.213.0.0 est appris via le chemin 200 avec un prochain saut de 128.213.63.2. Notez que toute entrée géné- rée localement, telle que 203.250.15.0 a un prochain saut égal à 0.0.0.0. ccnp_cch

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 128.213.0.0 via un prochain saut 128.213.63.2 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 203.250.13.0 255.255.255.255 is subnetted, 1 subnets O 203.250.13.41 [110/75] via 203.250.15.1, 02:50:45, Serial0 203.250.15.0 255.255.255.252 is subnetted, 1 subnets C 203.250.15.0 is directly connected, Serial0 O 203.250.14.0 [110/74] via 203.250.15.1, 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, 128.213.63.2 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 128.213.63.0 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 128.213.63.2. 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 203.250.13.41 255.255.255.0 ! interface Ethernet0 ip address 203.250.14.1 255.255.255.0 ! interface Serial0 ip address 128.213.63.1 255.255.255.252 ! (suite page suivante) ccnp_cch

router ospf 10 passive-interface serial0 network 203. 250. 0 0. 255 router ospf 10 passive-interface serial0 network 203.250.0.0 0.0.255.255 area 0 network 128.213.0.0 0.0.255.255 area 0 ! router bgp 100 network 203.250.13.0 mask 255.255.0.0 network 203.250.14.0 neighbor 128.213.63.2 remote-as 200 neighbor 203.250.15.2 remote-as 100 neighbor 203.250.15.2 update-source Loopback0 La nouvelle table BGP sur RTB ressemble à cela: RTB#show ip bgp Table version is 4, local router ID is 203.250.15.2 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 *>i128.213.0.0 128.213.63.2 0 100 0 200 i *>i192.208.10.0 128.213.63.2 100 0 200 400 500 300 i *>i195.211.10.0 128.213.63.2 100 0 200 400 500 i *>i200.200.10.0 128.213.63.2 100 0 200 400 i *>i203.250.13.0 203.250.13.41 0 100 0 i *>i203.250.14.0 203.250.13.41 0 100 0 i *>203.250.15.0 0.0.0.0 0 32768 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 203.250.13.0 255.255.255.255 is subnetted, 1 subnets O 203.250.13.41 [110/75] via 203.250.15.1, 02:50:45, Serial0 203.250.15.0 255.255.255.252 is subnetted, 1 subnets C 203.250.15.0 is directly connected, Serial0 O 203.250.14.0 [110/74] via 203.250.15.1, 02:50:46, Serial0 128.213.0.0 255.255.255.252 is subnetted, 1 subnets O 128.213.63.0 [110/138] via 203.250.15.1, 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

La seule différence est que 128. 213. 63 La seule différence est que 128.213.63.0 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 192.208.10.0 et 195.211.10.0 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.200.10.0 [200/0] via 128.213.63.2, 00:01:07 B 195.211.10.0 [200/0] via 128.213.63.2, 00:01:07 B 192.208.10.0 [200/0] via 128.213.63.2, 00:01:07 203.250.13.0 is variably subnetted, 2 subnets, 2 masks O 203.250.13.41 255.255.255.255 [110/75] via 203.250.15.1, 00:12:37, Serial0 B 203.250.13.0 255.255.255.0 [200/0] via 203.250.13.41, 00:01:08 203.250.15.0 255.255.255.252 is subnetted, 1 subnets C 203.250.15.0 is directly connected, Serial0 O 203.250.14.0 [110/74] via 203.250.15.1, 02:50:46, Serial0 128.213.0.0 is variably subnetted , 2 subnets, 2 masks B 128.213.0.0 255.255.0.0 [200/0] via 128.213.63.2, 00:01:08 O 128.213.63.0 255.255.255.252 [110/138] via 203.250.15.1, 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 203.250.13.0 255.255.255.255 is subnetted, I subnets O 203.250.13.41 [110/11] via 203.250.14.1, 00:14:15, Ethernet0 203.250.15.0 255.255.255.252 is subnetted, 1 subnets C 203.250.15.0 is directly connected, Serial1 C 203.250.14.0 is directly connected, Ethernet0 128.213.0.0 255.255.255.252 is subnetted, 1 subnets O 128.213.63.0 [110/74] via 203.250.14.1, 00:14:15, Ethernet0 ccnp_cch

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 2000. hostname RTA ! ip subnet-zero ! interface Loopback0 ip address 203.250.13.41 255.255.255.0 ! interface Ethernet0 ip address 203.250.14.1 255.255.255.0 ! interface Serial0 ip address 128.213.63.1 255.255.255.252 ! router ospf 10 redistribute bgp 100 metric 2000 subnets passive-interface serial0 network 203.250.0.0 0.0.255.255 area 0 network 128.213.0.0 0.0.255.255 area 0 ! router bgp 100 network 203.250.13.0 mask 255.255.0.0 network 203.250.14.0 neighbor 128.213.63.2 remote-as 200 neighbor 203.250.15.2 remote-as 100 neighbor 203.250.15.2 update-source Loopback0 ccnp_cch

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 E2 200.200.10.0 [110/2000] via 128.213.63.2, 00:00:14 O E2 195.211.10.0 [110/2000] via 128.213.63.2, 00:00:14 O E2 192.208.10.0 [110/2000] via 128.213.63.2, 00:00:14 203.250.13.0 is variably subnetted, 2 subnets, 2 masks O 203.250.13.41 255.255.255.255 [110/75] via 203.250.15.1, 00:00:15, Serial0 O E2 203.250.13.0 255.255.255.0 [110/2000] via 203.250.15.1, 00:00:15, Serial0 203.250.15.0 255.255.255.252 is subnetted, 2 subnets C 203.250.15.8 is directly connected, Loopback1 C 203.250.15.0 is directly connected, Serial0 O 203.250.14.0 [110/74] via 203.250.15.1, 00:00:15, Serial0 128.213.0.0 is variably subnetted , 2 subnets, 2 masks O E2 128.213.0.0 255.255.0.0 [110/2000] via 203.250.15.1, 00:00:15, Serial0 O 128.213.63.0 255.255.255.252 [110/138] via 203.250.15.1, 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 203.250.15.0 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 203.250.13.0 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 192.208.10.5 via IGP. Si nous n'exécutons pas cette étape, des boucles de routage peuvent apparaitre car pour obtenir le prochain saut 192.208.10.5,, 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 203.250.13.41 255.255.255.0 ! interface Ethernet0 ip address 203.250.14.1 255.255.255.0 ! ccnp_cch

interface Serial0 ip address 128. 213. 63. 1 255. 255. 255. 252 interface Serial0 ip address 128.213.63.1 255.255.255.252 ! router ospf 10 redistribute bgp 100 metric 2000 subnets passive-interface Serial0 network 203.250.0.0 0.0.255.255 area 0 network 128.213.0.0 0.0.255.255 area 0 ! router bgp 100 no synchronization network 203.250.13.0 network 203.250.14.0 neighbor 128.213.63.2 remote-as 200 neighbor 203.250.15.2 remote-as 100 neighbor 203.250.15.2 update-source Loopback0 RTB# hostname RTB ! ip subnet-zero ! interface Serial0 ip address 203.250.15.2 255.255.255.252 ! interface Serial1 ip address 192.208.10.6 255.255.255.252 ! router ospf 10 redistribute bgp 100 metric 2000 subnets passive-interface Serial1 network 203.250.0.0 0.0.255.255 area 0 network 192.208.0.0 0.0.255.255 area 0 ! router bgp 100 no synchronization network 203.250.15.0 neighbor 192.208.10.5 remote-as 300 neighbor 203.250.13.41 remote-as 100 ccnp_cch

Les tables BGP ressemblent à ceci: RTA#show ip bgp Table version is 117, local router ID is 203.250.13.41 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 *>128.213.0.0 128.213.63.2 0 0 200 i *>i192.208.10.0 192.208.10.5 0 100 0 300 i *>i195.211.10.0 192.208.10.5 100 0 300 500 i * 128.213.63.2 0 200 400 500 i *>i200.200.10.0 128.213.63.2 0 200 400 i *>203.250.13.0 0.0.0.0 0 32768 i *>203.250.14.0 0.0.0.0 0 32768 i *>i203.250.15.0 203.250.15.2 0 100 0 i RTB#show ip bgp Table version is 4, local router ID is 203.250.15.2 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 *>i128.213.0.0 128.213.63.2 0 100 0 200 i * 192.208.10.5 0 300 500 400 200 i *>192.208.10.0 192.208.10.5 0 0 300 i *>195.211.10.0 192.208.10.5 0 300 500 i *>i200.200.10.0 128.213.63.2 100 0 200 400 i * 192.208.10.5 0 300 500 400 i *>i203.250.13.0 203.250.13.41 0 100 0 i *>i203.250.14.0 203.250.13.41 0 100 0 i *>203.250.15.0 0.0.0.0 0 32768 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

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 203.250.13.41 255.255.255.0 ! interface Ethernet0 ip address 203.250.14.1 255.255.255.0 ! interface Serial0 ip address 128.213.63.1 255.255.255.252 ! router ospf 10 redistribute bgp 100 metric 2000 subnets passive-interface Serial0 network 203.250.0.0 0.0.255.255 area 0 network 128.213.0.0 0.0.255.255 area 0 default-information originate 2000 ! router bgp 100 no synchronization network 203.250.13.0 network 203.250.14.0 neighbor 128.213.63.2 remote-as 200 neighbor 128.213.63.2 route-map setlocalpref in neighbor 203.250.15.2 remote-as 100 neighbor 203.250.15.2 update-source Loopback0 ip classless ip default-network 200.200.0.0 route-map setlocalpref permit 10 set local-preference 200 ccnp_cch

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 200.200.0.0 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, 0.0.0.0 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 0.0.0.0 dans le domaine IGP. RTF# hostname RTF ! ip subnet-zero ! interface Ethernet0 ip address 203.250.14.2 255.255.255.0 ! interface Serial1 ip address 203.250.15.1 255.255.255.252 ! router ospf 10 network 203.250.0.0 0.0.255.255 area 0 ! ip classles RTB# hostname RTB ! ip subnet-zero ! interface Loopback1 ip address 203.250.15.10 255.255.255.252 ! interface Serial0 ip address 203.250.15.2 255.255.255.252 ! interface Serial1 ip address 192.208.10.6 255.255.255.252 ! router ospf 10 redistribute bgp 100 metric 2000 subnets passive-interface Serial1 network 203.250.0.0 0.0.255.255 area 0 network 192.208.0.0 0.0.255.255 area 0 default information-originate metric 1000 ! ccnp_cch

ccnp_cch router bgp 100 no synchronization network 203.250.15.0 neighbor 192.208.10.5 remote-as 300 neighbor 192.208.10.5 route-map localonly in neighbor 203.250.13.41 remote-as 100 ! ip classless ip default-network 192.208.10.0 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;250.15.0 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 *> 192.208.10.0 192.208.10.5 0 300 0 300 RTC# hostname RTC ! ip subnet-zero ! interface Loopback0 ip address 128.213.63.130 255.255.255.192 ! interface Serial2/0 ip address 128.213.63.5 255.255.255.252 ! interface Serial2/1 ip address 128.213.63.2 255.255.255.252 ! ccnp_cch

router bgp 200 network 128.213.0.0 neighbor 128.213.63.1 remote-as 100 neighbor 128.213.63.1 distribute-list 1 out neighbor 128.213.63.6 remote-as 100 ! ip classless access-list 1 deny 195.211.0.0 0.0.255.255 access-list 1 permit any Sur RTC, nous avons agrégé 128.213.0.0/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 192.208.10.174 255.255.255.192 ! interface Serial0/0 ip address 192.208.10.5 255.255.255.252 ! interface Serial0/1 ip address 192.208.10.2 255.255.255.252 ! router bgp 300 network 192.208.10.0 neighbor 192.208.10.1 remote-as 500 neighbor 192.208.10.6 remote-as 100 RTG# hostname RTG ! ip subnet-zero ! interface Loopback0 ip address 195.211.10.174 255.255.255.192 ! interface Serial0 ip address 192.208.10.1 255.255.255.252 ! interface Serial1 ip address 192.211.10.1 255.255.255.252 ! ccnp_cch

ccnp_cch router bgp 500 network 195.211.10.0 aggregate-address 195.211.0.0 255.255.0.0 summary-only neighbor 192.208.10.2 remote-as 300 neighbor 192.208.10.2 send-community neighbor 192.208.10.2 route-map setcommunity out neighbor 195.211.10.2 remote-as 400 ! ip classless access-list 1 permit 195.211.0.0 0.0.255.255 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 195.211.0.0 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 200.200.10.1 255.255.255.0 ! interface Serial0 ip address 195.211.10.2 255.255.255.252 ! interface Serial1 ip address 195.213.63.6 255.255.255.252 ! router bgp 400 network 200.200.10.0 aggregate-address 200.200.0.0 255.255.0.0 summary-only neighbor 128.213.63.5 remote-as 200 neighbor 195.211.10.1 remote-as 500 ! ip classles ccnp_cch

RTE agrège l'adresse 200.200.0.0/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 203.250.13.41 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 *> 128.213.0.0 128.213.63.2 0 200 0 200 i *>i192.208.10.0 192.208.10.5 0 300 0 300 i *> 200.200.10.0 128.213.63.2 200 0 200 400 i *> 203.250.13.0 0.0.0.0 0 32768 i *> 203.250.14.0 0.0.0.0 0 32768 i *>i203.250.15.0 203.250.15.2 0 100 0 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 128.213.63.2 to network 200.200.0.0 192.208.10.0 is variably subnetted, 2 subnets, 2 masks O E2 192.208.10.0 255.255.255.0 [110/1000] via 203.250.14.2, 00:41:25, Ethernet0 O 192.208.10.4 255.255.255.252 [110/138] via 203.250.14.2, 00:41:25, Ethernet0 C 203.250.13.0 is directly connected, Loopback0 203.250.15.0 is variably subnetted, 3 subnets, 3 masks O 203.250.15.10 255.255.255.255 [110/75] via 203.250.14.2, 00:41:25, Ethernet0 O 203.250.15.0 255.255.255.252 [110/74] via 203.250.14.2, 00:41:25, Ethernet0 B 203.250.15.0 255.255.255.255.0 [200/0] via 203.250.15.2, 00:41:25 C 203.250.14.0 is directly connected, Ethernet0 128.213.0.0 is variably subnetted, 2 subnets, 2 masks B 128.213.0.0 255.255.0.0 [20/0] via 128.213.63.2, 00:41:26 C 128.213.0.0 255.255.255.252 is directly connected ,Serial0 O*E2 0.0.0.0/0 [110/1000] via 203.250.14.2, Ethernet0/0 B* 200.200.0.0 255.255.0.0 [20/0] via 128.213.63.2, 00:02:38 ccnp_cch

RTE agrège l'adresse 200.200.0.0/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 203.250.15.2 to network 0.0.0.0 192.208.10.0 is variably subnetted, 2 subnets, 2 masks O E2 192.208.10.0 255.255.255.0 [110/1000] via 203.250.15.2, 00:48:50, Serial1 O 192.208.10.4 255.255.255.252 [110/128] via 203.250.15.2, 01:12:09, Serial1 203.250.13.0 is variably subnetted, 2 subnets, 2 masks O 203.250.13.41 255.255.255.255 [110/11] via 203.250.14.1, 01:12:09, Ethernet0 O E2 203.250.13.0 255.255.255.0 [110/2000] via 203.250.14.1, 01:12:09, Ethernet0 203.250.15.0 is variably subnetted, 2 subnets, 2 masks O 203.250.15.10 255.255.255.255.255 [110/65] via 203.250.15.2, 01:12:09, Serial1 C 203.250.15.0 255.255.255.252 is directly connected, Serial1 C 203.250.14.0 is directly connected, Ethernet0 128.213.0.0 is variably subnetted, 2 subnets, 2 masks O E2 128.213.0.0 255.255.0.0 [110/2000] via 203.250.14.1, 00:45:01, Ethernet0 0 128.213.63.0 255.255.255.252 [110/74]via 203.250.14.1, 01:12:11, Ethernet0 O E2 200.200.0.0 255.255.0.0 [110/2000] via 203.250.14.1, 00:03:47, Ethernet0 O*E2 0.0.0.0 0.0.0.0 [110/1000] via 203.250.15.2, 00:03:33, Serial1 Notez que la table de routage de RTF indique que les réseaux de l'AS 300 tel le 192.208. 10.0 seront atteint au travers de RTB. Les autres réseaux connus tel 200.200.0.0 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

RTB#show ip bgp Table version is 4, local router ID is 203. 250. 15 RTB#show ip bgp Table version is 4, local router ID is 203.250.15.2 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 *>i128.213.0.0 128.213.63.2 0 200 0 200 i *> 192.208.10.0 192.208.10.5 0 300 0 300 i *>i200.200.10.0/16 128.213.63.2 200 0 200 400 i *>i203.250.13.0 203.250.13.41 0 100 0 i *>i203.250.14.0 203.250.13.41 0 100 0 i *>203.250.15.0 0.0.0.0 0 32768 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 192.208.10.5 to network 192.208.10.0 * 192.208.10.0 is variably subnetted, 2 subnets, 2 masks B* 192.208.10.0 255.255.255.0 [20/0] via 192.208.10.5, 00:50:46 C 192.208.10.4 255.255.255.252 is directly connected Serial1 203.250.13.0 is variably subnetted, 2 subnetted, 2 subnets, 2 masks O 203.250.13.41 255.255.255.255 [110/75] via 203.250.15.1, 01:20:33, Serial0 O E2 203.250.13.0 255.255.255.0 [110/2000] via 203.250.15.1, 01:15:40, Serial0 203.250.15.0 255.255.255.252 is subnetted, 2 subnets C 203.250.15.8 is directly connected, Loopback1 C 203.250.15.0 is directly connected, Serial0 O 203.250.14.0 [110/74] via 203.250.15.1, 01:20:33, Serial0 128.213.0.0 is variably subnetted, 2 subnets, 2 masks O E2 128.213.0.0 255.255.0.0 [110/2000] via 203.250.15.1, 01:20:34, Serial0 O 128.213.63.0 255.255.255.252 [110/138] via 203.250.15.1, 01:20:34, Serial0 O E2 200.200.0.0 255.255.0.0 [110/2000] via 203.250.15.1, 00:05:42, Serial0 O*E2 0.0.0.0/0 [110/2000] via 203.250.15.1, 00:08:33, Serial0 ccnp_cch