BGP

Border Gateway Protocol

AS de Transit BGP - Schéma de la Maquette réalisée

Deux opérateurs, responsable des AS 64000 et 65000, veulent assurer une communication entre les réseaux 1.1.1.0/24 et 2.2.2.0/24, ressources publiques disponibles dans leurs AS respectifs.

Pour permettre aux échanges de fonctionner, il sera nécessaire de passer par un AS de transit, l’AS 65500. Nous allons réaliser cette Architecture sur simulateur (Gns3 =>http://www.gns3.com/).

La liaison entre les AS 64000 et 65500 se fera via un simple lien WAN, en encapsulation PPP (tous nos liens WAN utiliseront d’ailleurs le même protocole d’encapsulation).

La liaison entre les AS 65000 et 65500 se fera via deux liens WAN qui opèreront en secours réciproque, et en répartition de charge.

L’AS 65500 (AS de Transit) sera représentée par un groupe de routeurs qui utilisent un IGP (Ospf). Toutes les interfaces utilisant cet IGP seront affectées à l’aire 0

Dans le projet, nous utiliserons les sous réseaux IP suivants :

- - 10.10.10.16/30 entre R1 et R2
  - 10.10.10.12/30 entre R2 et R4
  - 10.10.10.4/30 entre R1 et R3
  - 10.10.10.8/30 entre R3 et R4
  - 9.2.2.2/32 pour l’adresse de bouclage de R1
  - 9.2.2.3/32 pour l’adresse de bouclage de R2
  - 9.2.2.4/32 pour l’adresse de bouclage de R3
  - 9.2.2.5/32 pour l’adresse de bouclage de R4
  - 8.8.8.8/32 pour l’adresse de bouclage de R6
  - 192.168.0.4/30, 192.168.0.8/30 et 192.168.0.12/30 pour les liens inter AS
  - 1.1.1.0/24 pour les ressources de l’AS 64000
  - 2.2.2.0/24 pour les ressources de l’AS 65000

Mise en oeuvre pas-à-pas - Le coeur de l’AS 65500 – mise en place de l’IGP

Le plan d’adressage IP du coeur de l’AS 65500, pour les liaisons inter-routeurs est de type 10.10.10.x/30 (optimisé pour les liaisons point à point). Quatre sous-réseaux (subnets) interconnectent nos quatre routeurs :

- 10.10.10.16/30 entre R1 et R2
- 10.10.10.12/30 entre R2 et R4
- 10.10.10.4/30 entre R1 et R3
- 10.10.10.8/30 entre R3 et R4

L’IGP choisi par l’instance administrative de cet AS est Osfp. Nous ne reviendrons pas sur la configuration de cet IGP et ses principes de fonctionnement. Nous allons juste effectuer sa mise en oeuvre. A noter que toutes les interfaces sur lesquelles nous allons activer Osfp seront dans l’Aire (Area) 0.

R1 – Activation Ospf et paramétrage des interfaces

router ospf 10

network 10.10.10.4 0.0.0.3 area 0

network 10.10.10.16 0.0.0.3 area 0

interface Serial1/0

ip address 10.10.10.17 255.255.255.252

encapsulation ppp

serial restart-delay 0

interface Serial1/1

ip address 10.10.10.5 255.255.255.252

encapsulation ppp

serial restart-delay 0

R2 – Activation Ospf et paramétrage des interfaces

router ospf 10

network 10.10.10.12 0.0.0.3 area 0

network 10.10.10.16 0.0.0.3 area 0

interface Serial1/0

ip address 10.10.10.18 255.255.255.252

encapsulation ppp

serial restart-delay 0

interface Serial1/2

ip address 10.10.10.14 255.255.255.252

encapsulation ppp

serial restart-delay 0

R3 – Activation Ospf et paramétrage des interfaces

router ospf 10

network 10.10.10.4 0.0.0.3 area 0

network 10.10.10.8 0.0.0.3 area 0

interface Serial1/0

ip address 10.10.10.9 255.255.255.252

encapsulation ppp

serial restart-delay 0

interface Serial1/1

ip address 10.10.10.6 255.255.255.252

encapsulation ppp

serial restart-delay 0

R4 – Activation Ospf et paramétrage des interfaces

router ospf 10

network 10.10.10.8 0.0.0.3 area 0

network 10.10.10.12 0.0.0.3 area 0

interface Serial1/0

ip address 10.10.10.10 255.255.255.252

encapsulation ppp

serial restart-delay 0

interface Serial1/2

ip address 10.10.10.13 255.255.255.252

encapsulation ppp

serial restart-delay 0

Une fois cette configuration effectuée, il ne reste plus qu’à passer la commande « no shut » sur toutes les interfaces Serials configurées. Au fur et à mesure, ce type de message devrait apparaitre sur vos consoles :

*Mar 1 00:00:04.819: %LINK-3-UPDOWN: Interface Serial1/0, changed state to up

*Mar 1 00:00:04.831: %LINK-3-UPDOWN: Interface Serial1/2, changed state to up

! les serials ont un status opérationnel.

*Mar 1 00:00:05.823: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1/0,

changed state to up

*Mar 1 00:00:05.831: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1/2,

changed state to up

! le protocole sur les serials est opértionnel (ppp dans notre cas)

*Mar 1 00:00:15.863: %OSPF-5-ADJCHG: Process 10, Nbr 9.9.9.3 on Serial1/2 from LOADING

to FULL, Loading Done

R4#

*Mar 1 00:00:18.303: %OSPF-5-ADJCHG: Process 10, Nbr 9.9.9.4 on Serial1/0 from LOADING

to FULL, Loading Done

! Ospf a convergé. Les tables de routage sont stables

Notez que les adresses IP qui apparaissent sur les messages de log Ospf précedente (9.9.9.3 et 9.9.9.4) n’en sont pas. Ce sont des Id Ospf de routeurs.

Remarque sur l’affectation des Id Ospf : Comme aucun Id n’a été précisé dans notre configuration, le routeur s’identifie de manière unique, en tant que noeud Ospf, en lui associant en priorité l’adresse de bouclage du routeur, si elle existe (ce sera le cas dans notre projet), ou alors la plus grande adresse IP active sur une interface de sa configuration locale (La codification d’un Id Ospf étant sur 32 bits, et devant être unique, le fait de récupérer une adresse IP comme id Ospf est une facilité, mais il y a bien deux notions qui n’ont rien en commun : id ospf et adresse IP).

Dans notre projet, d’où vient cette adresse IP ?

Elle n’est pas encore configurée sur nos routeurs… nous verrons plus tard que c’est une loopback que nous avons créée dans un but bien précis.

Retournons à notre projet… Il nous reste à vérifier que les tables de routage sont bien alimentées, avec la commande « sh ip route » sur R3, par exemple :

R3#sh ip route

10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks

C 10.10.10.10/32 is directly connected, Serial1/0

C 10.10.10.8/30 is directly connected, Serial1/0

O 10.10.10.12/30 [110/128] via 10.10.10.10, 00:15:08, Serial1/0

C 10.10.10.4/30 is directly connected, Serial1/1

C 10.10.10.5/32 is directly connected, Serial1/1

O 10.10.10.16/30 [110/128] via 10.10.10.5, 01:09:32, Serial1/1

R3#

L’IGP est donc en place, et opérationnel.

Mise en place des liaisons eBgp (External BGP) - Interconnexion BGP entre l’AS 65000 et l’AS 64000

Nous avons un lien direct entre les routeurs R1, dans l’AS 65500, et le routeur R5 dans l’AS 64000. C’est sur ce lien que nous allons réaliser notre liaison BGP. Rappelez vous, L’AS 65500, par rapport aux AS 65000 et 64000 est un AS de transit. Cela veut dire que nous allons faire de l’eBgp entre R5 et R1 (routeurs dans deux AS différents), et de l’iBgp entre R1 et les autres routeurs de l’AS 65500 (routeurs dans le même AS… nous paramètrerons cela plus tard)

Pour résumer, il y a trois pré-requis pour faire de l’eBgp entre deux routeurs :

1 - En terme d’accessibilité : le voisinage s’effectue généralement entre des noeuds « directly connected ».

2 - Les numéros d’AS doivent être différents.

3 - Il doit y avoir établissement d’une session Tcp entre les deux routeurs avant tout échange Bgp.

Nous verrons plus tard qu’il est possible (même obligatoire dans certains cas) d’utiliser une interface de loopback des routeurs, plutôt que de monter une relation de voisinage sur l’adresse IP du sous réseau commun. Pour l’instant, sur notre maquette, le lien s’effectuera entre l’adresse IP 192.168.0.13 de R5 et l’adresse IP

192.168.0.14 de R1.

C’est ce que nous allons mettre en oeuvre, et sans autres contraintes, cela va très bien fonctionner

Configuration eBgp de R5

router bgp 64000

network 1.1.1.0 mask 255.255.255.0

neighbor 192.168.0.14 remote-as 65500

no auto-summary

Configuration eBgp de R1

router bgp 65500

neighbor 192.168.0.13 remote-as 64000

no auto-summary

Si tout se passe correctement, vous devriez voir apparaitre sur les consoles des routeurs, un message d’établissement de la session TCP. Ci-dessous, l’exemple pour R5 :

R5#

*Mar 1 04:29:59.114: %BGP-5-ADJCHANGE: neighbor 192.168.0.14 Up

R5#

Remarque sur la commande Network, la table Bgp, la table de routage

Avec notre table de routage (celle que le routeur consulte pour commuter les paquets), va cohabiter maintenant une table BGP de réseaux échangés via ce protocole. Nous allons observer ces tables. Commençons par vérifier l’existence du voisinage Bgp entre R5 et R1 .

Dans notre exemple, nous passons la commande sur R5 :

Résumé des voisinages Bgp

R5#sh ip bgp summary

BGP router identifier 192.168.0.13, local AS number 64000

BGP table version is 5, main routing table version 5

2 network entries using 240 bytes of memory

2 path entries using 104 bytes of memory

3/2 BGP path/bestpath attribute entries using 372 bytes of memory

1 BGP AS-PATH entries using 24 bytes of memory

0 BGP route-map cache entries using 0 bytes of memory

0 BGP filter-list cache entries using 0 bytes of memory

Bitfield cache entries: current 1 (at peak 1) using 32 bytes of memory

BGP using 772 total bytes of memory

BGP activity 3/1 prefixes, 3/1 paths, scan interval 60 secs

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd

192.168.0.14 4 65500 272 270 5 0 0 04:26:39 1

R5#

Cette commande nous permet de vérifier l’existence de la sessions Tcp entre R5 et R1, ainsi que l’existence de traffic échangé.

Table Bgp de R5

R5#sh ip bgp

BGP table version is 5, local router ID is 192.168.0.13

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

r RIB-failure, S Stale

Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

*> 1.1.1.0/24 0.0.0.0 0 32768 i

R5#

Cette commande permet de visualiser les réseaux connus dans les tables BGP. Ils sont issus des commandes network de différents routeurs. Notez que la commande network de Bgp est différente de celle d’un IGP, dans le sens ou vous n’avez pas besoin d’avoir des adresses IP actives sur les interfaces d’un routeur pour annoncer un réseau. Il est simplement nécessaire qu’il soit connu localement dans la table de routage IP (connected, null/static, ou appris par un protocole de routage).

Cette commande vos permettra aussi de dire à Bgp comment redistribuer au mieux des réseaux (subnetting ou supernetting).

Table de routage de R5

R5#sh ip route

1.0.0.0/24 is subnetted, 1 subnets

C 1.1.1.0 is directly connected, FastEthernet0/0

192.168.0.0/24 is variably subnetted, 2 subnets, 2 masks

C 192.168.0.14/32 is directly connected, Serial1/0

C 192.168.0.0/24 is directly connected, Serial1/0

R5#

Cette dernière commande, sh ip route, va vous permettre de visualiser le contenu de la table de routage de votre routeur.

Interconnexion BGP entre l’AS 65000 et l’AS 65500

Nous allons maintenant effectuer une autre liaison Bgp, de type eBgp, entre deux AS différents. Cette liaison est particulière car elle est dite « Dual-Homed ». Dans cette situation, nous avons deux liens, que nous allons utiliser en secours l’un de l’autre, et en répartition de charge (deux liens opérationnels en fonctionnement nominal).

Si l’on reprend la même technique que nous avons utilisée entre R1 et R5, c’est-à-dire en déclarant un voisinage (session Tcp) basé sur les adresses IP des interfaces, on va rapidement rencontrer des problèmes.

En effet, si on réalise ce voisinage sur un des deux liens (192.168.0.5 vers 192.168.0.6 ou 192.168.0.9 vers 192.168.0.10), et que ce lien tombe, la session Tcp Bgp tombera également, entraînant des conséquences lourdes sur le routage… Quant à la répartition de charge, sur un seul lien, elle est sans objet.

Pour pallier à ce problème, tout en conservant le principe d’établissement d’un voisinage sur les adresses IP des interfaces, il faudrait établir deux sessions Tcp de R4 à R6 (192.168.0.5 vers 192.168.0.6 et 192.168.0.9 vers 192.168.0.10). Mais là encore, le principe est loin d’être parfait. On va ainsi multiplier par deux les update Bgp. De plus, généralement, sur ce type de topologie, Bgp choisi un de deux liens pour ses échanges, et fait donc fi de la répartition de charge….

Nous allons donc introduire pour cette liaison, la notion d’adresses de bouclage (loopback). Nous allons créer une loopback sur R4 (9.9.9.5/32), et une loopback sur R6 (8.8.8.8/32). Avec cette technique, chacun des routeurs pourra être joint sur une adresse unique, quel que soit le lien emprunté.

Configuration de l’adresse de bouclage de R4

interface Loopback0

ip address 9.9.9.5 255.255.255.255

Configuration de l’adresse de bouclage de R6

interface Loopback0

ip address 8.8.8.8 255.255.255.255

Configuration de Bgp sur R6

router bgp 65000

network 2.2.2.0 mask 255.255.255.0

neighbor 9.9.9.5 remote-as 65500

neighbor 9.9.9.5 ebgp-multihop 2

neighbor 9.9.9.5 update-source Loopback0

ip route 9.9.9.5 255.255.255.255 192.168.0.5

ip route 9.9.9.5 255.255.255.255 192.168.0.9

Configuration de Bgp sur R4

router bgp 65500

neighbor 8.8.8.8 remote-as 65000

neighbor 8.8.8.8 ebgp-multihop 2

neighbor 8.8.8.8 update-source Loopback0

ip route 8.8.8.8 255.255.255.255 192.168.0.6

ip route 8.8.8.8 255.255.255.255 192.168.0.10

Des routes statiques pour joindre R4 et R6 sur leur loopback ? Oui, car il n’y a aucun protocole de routage en place entre R4 et R6. Les seuls réseaux communs et connus entre ces deux routeurs sont 19.168.0.4/30 et 192.168.0.8/30. L’adresse 9.9.9.5 n’est donc pas dans la table de routage de R6 (ni 8.8.8.8 dans celle de R4), ce qui rend impossible la connectivité, donc un établissement de session, entre les adresses 9.9.9.5 et 8.8.8.8. La mise en place de routes statiques va pallier à ce problème. Vérifions la table de routage de R6 pour s’en convaincre :

R6#sh ip route

2.0.0.0/24 is subnetted, 1 subnets

C 2.2.2.0 is directly connected, FastEthernet0/0

8.0.0.0/32 is subnetted, 1 subnets

C 8.8.8.8 is directly connected, Loopback0

9.0.0.0/32 is subnetted, 1 subnets

S 9.9.9.5 [1/0] via 192.168.0.9

[1/0] via 192.168.0.5

192.168.0.0/24 is variably subnetted, 4 subnets, 2 masks

C 192.168.0.8/30 is directly connected, Serial1/3

C 192.168.0.9/32 is directly connected, Serial1/3

C 192.168.0.4/30 is directly connected, Serial1/1

C 192.168.0.5/32 is directly connected, Serial1/1

R6#

Notons au passage que l’adresse 9.9.9.5 est joignable par deux liens de même poids. Que fera le routeur dans un tel cas. Il enverra des paquets sur les deux interfaces. La répartition de charge est donc bien opérationnelle.

Les commandes ebgp-multihop et update-source

Ebgp-multihop

Pour éviter les boucles IP, par défaut, une annonce eBgp est encapsulée dans un paquet IP dont le TTL est égal à 1. Cela signifie que le paquet n’a droit qu’à un saut, puisqu’en arrivant sur le routeur d’en face (192.168.0.5, par exemple) on va le décrémenter de 1. Avec un TTL à zéro, le paquet ne sera donc pas commuté plus loin…

Hors, l’adresse de bouclage de R4 (9.9.9.5) est située 1 saut derrière l’adresse IP de l’interface 192.168.0.5 ou .9, ce qui représente deux sauts. Sans cette commande, le paquet n’atteindrait donc jamais l’adresse de bouclage.

Cette commande agit directement sur la valeur de TTL des paquets… dans notre cas, passage à la valeur 2.

Update-source

Si notre routeur R6 sait maintenant comment joindre le routeur R4, il va falloir que ce dernier puisse répondre à R6 pour établir la session Tcp. Regardons d’abord la configuration Bgp de R4 :

router bgp 65500

neighbor 8.8.8.8 remote-as 65000

neighbor 8.8.8.8 ebgp-multihop 2

neighbor 8.8.8.8 update-source Loopback0

ip route 8.8.8.8 255.255.255.255 192.168.0.6

ip route 8.8.8.8 255.255.255.255 192.168.0.10

De la même manière que R6 va joindre R4 sur son adressage de bouclage (9.9.9.5), R4 va essayer de joindre R6 sur son adresse de bouclage (8.8.8.8)… mais, par défaut, si on observe le premier paquet qui sort de R6, l’entête IP aura comme IP de destination 9.9.9.5 et comme IP source l’adresse IP de l’interface par laquelle il est sorti (soit 192.168.0.6 ou .10).

La liaison tentera donc de se faire entre une adresse de bouclage et l’adresse IP d’une interface, ce qui invalide tout ce que nous désirons mettre en place, à savoir, une session Tcp entre 8.8.8.8 et 9.9.9.5 La solution consiste donc à écraser l’adresse IP source par défaut, par l’adresse de bouclage de l’émetteur… c’est ce que réalise la commande Update-source.

On peut aisément le vérifier avec une capture de trames....

Mise en place d’ iBgp (Internal BGP)

Notre AS 65500 est un AS de transit entre les AS 65000 et 64000. Il va donc falloir propager les routes de ces deux AS (dans notre exemple 1.1.1.0/24 et 2.2.2.0/24) entre R1 et R4…. Une solution (c’est ce qui se faisait dans les débuts de l’Internet), consisterai à utiliser l’IGP (Ospf) pour propager ces routes à l’intérieur de l’AS 65500, en faisant une redistribution de Bgp vers Ospf (et réciproquement)…. C’est-à-dire, à ce jour, près de 500 000 réseaux !

Un IGP n’a pas capacité à gérer un tel volume et le réseau de l’opérateur de transit serait vite saturé. Nous allons donc utiliser une autre méthode, en établissant une liaison Bgp entre R1 et R4. Pour cela, nous avons une contrainte : l’AS 65500 étant une aire de transit, tous les routeurs situés sur le chemin entre R1 et R4 doivent exécuter Bgp (iBgp), et les sessions entre les routeurs devront être « fully meshed ».

La mise en oeuvre de sessions Bgp doit suivre les règles suivantes :

1 - Définition des voisinages : une session TCP doit être établie entre chaque routeur avant toute mise à jour de table.

2 - Connectivité : Chaque Peer (ou routeur) doit être joignable par le speaker (le routeur émetteur) via l’IGP de l’AS de transit.

3 - Les routeurs doivent être localisés dans le même AS.

Notons qu’avec iBgp, deux routeurs n’ont pas besoin d’être « directly connected » pour établir une session Tcp. C’est d’ailleurs pour cela qu’ils ont besoin d’utiliser l’IGP de l’AS de transit ; pour pouvoir joindre le peer distant.

Notons également qu’une aire de transit possède de multiples chemins pour relier un point A à un point B. Pour les mêmes raisons (utilisation de l’adresse IP de l’interface de sortie) qui nous ont poussées à le faire lors d’une liaison eBgp, dans le cas d’un lien « Dual-Homed », nous allons utiliser des adresses de bouclage. Et comme nous avons dit précédemment que chaque peer sur le chemin de transit doit être joignable, il faudra par conséquent, diffuser ces adresses de bouclage, via l’IGP.

Nous allons donc modifier le routage Ospf sur R1, R2, R3 et R4 de la manière suivante (exemple ci-dessous pour R1) :

router ospf 10

log-adjacency-changes

/routage de toutes les interfaces ayant une adresse en 9.9.9.x/

network 9.9.9.0 0.0.0.255 area 0

network 10.10.10.4 0.0.0.3 area 0

network 10.10.10.16 0.0.0.3 area 0

Revenons à iBgp. Dans notre exemple, nous allons faire de l’iBgp (en montant des sessions Tcp) entre :

R1 vers R2, R3, R4
R2 vers R1,R4
R3 vers R1, R4
R1 vers R1, R2, R3

Préface de la configuration Bgp de R1

Voici la configuration iBgp, tel que nous pourrions la paramétrer sur R1. Ce n’est pas exactement ce que nous allons faire, mais cela va nous permettre de présenter la notion de peer-group :

router bgp 65500

neighbor 9.9.9.3 remote-as 65500

neighbor 9.9.9.3 update-source Loopback0

neighbor 9.9.9.3 next-hop-self

neighbor 9.9.9.4 remote-as 65500

neighbor 9.9.9.4 update-source Loopback0

neighbor 9.9.9.4 next-hop-self

neighbor 9.9.9.5 remote-as 65500

neighbor 9.9.9.5 update-source Loopback0

neighbor 9.9.9.5 next-hop-self

neighbor 192.168.0.13 remote-as 64000

no auto-summary

L’utilisation de la commande peer-group

Vous avez surement remarqué la redondance d’informations que l’on retrouve à chaque mise en place d’une session Tcp entre chaque routeur (même remote-as, même update-source, même next-hop-self…). Dans notre exemple nous allons utiliser une facilité de configuration, en créant un peer –group, qui va nous permettre de définir, une fois pour toute, les commandes nécessaires à la montée de session Tcp iBgp, puis, nous rattacherons la commande de mise en relation vers le peer distant, à ce peer-group.

A retenir : Un peer-group possède un nom ; il se nomme « IBGP » dans notre exemple. Retenez que cette notion de peer-group est locale au routeur. Il n'est pas nécessaire de l'implémenter sur tous les routeurs Bgp de l'AS. Cela se fera en fonction du gain que l'on estime rentable dans la complexité de la configuration Bgp de chaque noeud.

Vous pouvez rapidement constater qu’en termes de lisibilité, et surtout de facilité à modifier les caractéristiques des peers, c’est sans appel...

La commande next-hop-self

Dans une table de routage alimenté par un IGP, à chaque saut, le next hop d’un réseau annoncé est écrasé par l’adresse IP de l’interface du routeur qui a fait cette annonce. Quand on utilise iBgp dans une aire de transit, le routeur d’entrée de l’AS (R1) reçoit comme next hop des réseaux externes annoncés, l’adresse IP de l’interface du peer eBgp (ou sa loopback, R5 dans notre exemple). iBgp ne réécrase pas un next hop annoncé. Lors de la propagation au routeur suivant (R2), c’est donc ce next hop qui sera propagé ; cependant, R2 ne connait pas ce next hop ! Il ne connait que ce qui l’alimente via l’IGP de l’AS, et ce dernier ne connait pas cette adresse externe….

A noter que, pour qu’un réseau annoncé via Bgp, alimente la table de routage du routeur, il faut que le next hop de la table Bgp de ce réseau soit connu de la table de routage. Vous pouvez ainsi avoir des réseaux connus dans la table Bgp, mais qui ne sont pas dans la table de routage, et ces routeurs ne pourront donc pas jouer leur rôle de commutateur de paquets, dans l’AS de transit…

L’idée va donc être de remplacer sur R1, avant annonce des réseaux via l’IGP, un next hop connu des peers internes à l’AS : son adresse de bouclage (que nous diffusons via Ospf). Bien entendu, ce principe est le même pour la configuration de l’iBgp sur R4…. Voyons l’impact de la suppression de la commande next-hop-self :

Avec next-hop-self

R1#sh ip bgp

BGP table version is 3, local router ID is 9.9.9.2

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

r RIB-failure, S Stale

Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

*> 1.1.1.0/24 192.168.0.13 0 0 64000 i

*>i2.2.2.0/24 9.9.9.5 0 100 0 65000 i

R1#

R2#sh ip bgp

BGP table version is 3, local router ID is 9.9.9.3

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

r RIB-failure, S Stale

Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

*>i1.1.1.0/24 9.9.9.2 0 100 0 64000 i

*>i2.2.2.0/24 9.9.9.5 0 100 0 65000 i

R2#

R2#sh ip route

1.0.0.0/24 is subnetted, 1 subnets

B 1.1.1.0 [200/0] via 9.9.9.2, 00:00:25

2.0.0.0/24 is subnetted, 1 subnets

B 2.2.2.0 [200/0] via 9.9.9.5, 00:00:25

9.0.0.0/32 is subnetted, 4 subnets

C 9.9.9.3 is directly connected, Loopback0

O 9.9.9.2 [110/65] via 10.10.10.17, 00:01:48, Serial1/0

O 9.9.9.5 [110/65] via 10.10.10.13, 00:01:48, Serial1/2

O 9.9.9.4 [110/129] via 10.10.10.17, 00:01:48, Serial1/0

[110/129] via 10.10.10.13, 00:01:48, Serial1/2

10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks

O 10.10.10.8/30 [110/128] via 10.10.10.13, 00:01:50, Serial1/2

C 10.10.10.12/30 is directly connected, Serial1/2

C 10.10.10.13/32 is directly connected, Serial1/2

O 10.10.10.4/30 [110/128] via 10.10.10.17, 00:01:52, Serial1/0

C 10.10.10.16/30 is directly connected, Serial1/0

C 10.10.10.17/32 is directly connected, Serial1/0

R2#

Le next hop 9.9.9.2 est bien dans la table de routage. Conséquence : 1.1.1.0/24 est bien dans la table de routage. Le routeur pourra commuter vers ce réseau.

Sans next-hop-self

R1#sh ip bgp

BGP table version is 3, local router ID is 9.9.9.2

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

r RIB-failure, S Stale

Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

*> 1.1.1.0/24 192.168.0.13 0 0 64000 i

*>i2.2.2.0/24 9.9.9.5 0 100 0 65000 i

R1#

R2#sh ip bgp

BGP table version is 4, local router ID is 9.9.9.3

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

r RIB-failure, S Stale

Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

* i1.1.1.0/24 192.168.0.13 0 100 0 64000 i

*>i2.2.2.0/24 9.9.9.5 0 100 0 65000 i

R2#

A noter : Le symbole « > », absent de la ligne surlignée précédente, montre que le réseau 1.1.1.0/24 est bien dans la table Bgp…

R2#sh ip route

2.0.0.0/24 is subnetted, 1 subnets

B 2.2.2.0 [200/0] via 9.9.9.5, 00:09:47

9.0.0.0/32 is subnetted, 4 subnets

C 9.9.9.3 is directly connected, Loopback0

O 9.9.9.2 [110/65] via 10.10.10.17, 00:11:09, Serial1/0

O 9.9.9.5 [110/65] via 10.10.10.13, 00:11:09, Serial1/2

O 9.9.9.4 [110/129] via 10.10.10.17, 00:11:09, Serial1/0

[110/129] via 10.10.10.13, 00:11:09, Serial1/2

10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks

O 10.10.10.8/30 [110/128] via 10.10.10.13, 00:11:11, Serial1/2

C 10.10.10.12/30 is directly connected, Serial1/2

C 10.10.10.13/32 is directly connected, Serial1/2

O 10.10.10.4/30 [110/128] via 10.10.10.17, 00:11:11, Serial1/0

C 10.10.10.16/30 is directly connected, Serial1/0

C 10.10.10.17/32 is directly connected, Serial1/0

R2#

…mais on observe aussi que le réseau 1.1.1.0/24 n’est pas dans la table de routage, C’est la conséquence de l’absence de la connaissance du réseau 192.168.0.12/30 par R2.

Configuration des routeurs R1, R2, R3 et R4

Reprenons maintenant nos différents routeurs rattachés à l’ AS 65500. Nous allons mettre en évidence sur R1 et R4 (qui possèdent déjà une partie de la configuration) les commandes propres à iBgp, et nous allons les créer sur R2 et R3 :

Configuration de R1

router ospf 10

/ajout du routage des loopback dans l’AS de transit/

network 9.9.9.0 0.0.0.255 area 0

network 10.10.10.4 0.0.0.3 area 0

network 10.10.10.16 0.0.0.3 area 0

router bgp 65500

/configuration iBgp/

neighbor IBGP peer-group

neighbor IBGP remote-as 65500

neighbor IBGP update-source Loopback0

neighbor IBGP next-hop-self

neighbor 9.9.9.3 peer-group IBGP

neighbor 9.9.9.4 peer-group IBGP

neighbor 9.9.9.5 peer-group IBGP

/configuration eBgp/

neighbor 192.168.0.13 remote-as 64000

no auto-summary

Configuration de R4

router ospf 10

/ajout du routage des loopback dans l’AS de transit/

network 9.9.9.0 0.0.0.255 area 0

network 10.10.10.8 0.0.0.3 area 0

network 10.10.10.12 0.0.0.3 area 0

router bgp 65500

neighbor IBGP peer-group

neighbor IBGP remote-as 65500

neighbor IBGP update-source Loopback0

neighbor IBGP next-hop-self

/configuration eBgp/

neighbor 8.8.8.8 remote-as 65000

neighbor 8.8.8.8 ebgp-multihop 2

neighbor 8.8.8.8 update-source Loopback0

/configuration eBgp/

neighbor 9.9.9.2 peer-group IBGP

neighbor 9.9.9.3 peer-group IBGP

neighbor 9.9.9.4 peer-group IBGP

Configuration de R2

router ospf 10

/ajout du routage des loopback dans l’AS de transit/

network 9.9.9.0 0.0.0.255 area 0

network 10.10.10.12 0.0.0.3 area 0

network 10.10.10.16 0.0.0.3 area 0

router bgp 65500

/configuration eBgp/

neighbor IBGP peer-group

neighbor IBGP remote-as 65500

neighbor IBGP update-source Loopback0

neighbor 9.9.9.2 peer-group IBGP

neighbor 9.9.9.5 peer-group IBGP

Configuration de R3

router ospf 10

/ajout du routage des loopback dans l’AS de transit/

network 9.9.9.0 0.0.0.255 area 0

network 10.10.10.4 0.0.0.3 area 0

network 10.10.10.8 0.0.0.3 area 0

router bgp 65500

/configuration eBgp/

neighbor IBGP peer-group

neighbor IBGP remote-as 65500

neighbor IBGP update-source Loopback0

neighbor 9.9.9.2 peer-group IBGP

neighbor 9.9.9.5 peer-group IBGP

Pour finir, regardons mieux nos différentes tables (bgp et routage), et pour commencer, celles des deux routeurs dans les AS 64000 et AS 65000. Comme vous le constaterez, il n’y a que des sous réseaux directly connected, et des sous réseaux (1.1.1.0/24 – 2.2.2.0/24), mais aucune trace d’éléments propres à l’ AS de transit (65500). C’est un des buts recherchés (AS de transit transparent)…

Table Bgp et de routage de R5

R5#sh ip bgp

BGP table version is 3, local router ID is 192.168.0.13

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

r RIB-failure, S Stale

Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

*> 1.1.1.0/24 0.0.0.0 0 32768 i

*> 2.2.2.0/24 192.168.0.14 0 65500 65000 i

R5#sh ip route

1.0.0.0/24 is subnetted, 1 subnets

C 1.1.1.0 is directly connected, FastEthernet0/0

2.0.0.0/24 is subnetted, 1 subnets

B 2.2.2.0 [20/0] via 192.168.0.14, 00:34:27

192.168.0.0/24 is variably subnetted, 2 subnets, 2 masks

C 192.168.0.14/32 is directly connected, Serial1/0

C 192.168.0.0/24 is directly connected, Serial1/0

R5#

Tables Bgp et de Routage de R6

R6#sh ip bgp

BGP table version is 3, local router ID is 8.8.8.8

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

r RIB-failure, S Stale

Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

*> 1.1.1.0/24 9.9.9.5 0 65500 64000 i

*> 2.2.2.0/24 0.0.0.0 0 32768 i

R6#sh ip route

1.0.0.0/24 is subnetted, 1 subnets

B 1.1.1.0 [20/0] via 9.9.9.5, 00:36:24

2.0.0.0/24 is subnetted, 1 subnets

C 2.2.2.0 is directly connected, FastEthernet0/0

8.0.0.0/32 is subnetted, 1 subnets

C 8.8.8.8 is directly connected, Loopback0

9.0.0.0/32 is subnetted, 1 subnets

S 9.9.9.5 [1/0] via 192.168.0.9

[1/0] via 192.168.0.5

192.168.0.0/24 is variably subnetted, 4 subnets, 2 masks

C 192.168.0.8/30 is directly connected, Serial1/3

C 192.168.0.9/32 is directly connected, Serial1/3

C 192.168.0.4/30 is directly connected, Serial1/1

C 192.168.0.5/32 is directly connected, Serial1/1

R6#

Regardons maintenant les tables de R1 et R4 (les borders), puis enfin celles de R3 et R2 (les internals). Toutes les loopback sont connues, donc tous les peers à l’intérieur de l’AS 65500 sont joignables (un pré-requis iBgp). Les sous réseaux 1.1.1.0/24 et 2.2.2.0/24 sont connus dans la table de routage (un pré-requis au transit de données entre R5 et R6).

Une question revient souvent à ce stade : Mais pourquoi finalement ne pas avoir redistribué directement ces réseaux dans Ospf ? Parce que Ospf ne l’aurait pas supporté…. Ce que nous faisons, c’est alimenter la table de routage via des tables Bgp et non par Ospf.

Tables Bgp et de Routage de R1

R1#sh ip bgp

BGP table version is 3, local router ID is 9.9.9.2

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

r RIB-failure, S Stale

Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

*> 1.1.1.0/24 192.168.0.13 0 0 64000 i

*>i2.2.2.0/24 9.9.9.5 0 100 0 65000 i

R1#sh ip route

1.0.0.0/24 is subnetted, 1 subnets

B 1.1.1.0 [20/0] via 192.168.0.13, 00:55:42

2.0.0.0/24 is subnetted, 1 subnets

B 2.2.2.0 [200/0] via 9.9.9.5, 00:55:42

9.0.0.0/32 is subnetted, 4 subnets

O 9.9.9.3 [110/65] via 10.10.10.18, 00:57:02, Serial1/0

C 9.9.9.2 is directly connected, Loopback0

O 9.9.9.5 [110/129] via 10.10.10.18, 00:57:02, Serial1/0

[110/129] via 10.10.10.6, 00:57:02, Serial1/1

O 9.9.9.4 [110/65] via 10.10.10.6, 00:57:02, Serial1/1

10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks

O 10.10.10.8/30 [110/128] via 10.10.10.6, 00:57:04, Serial1/1

O 10.10.10.12/30 [110/128] via 10.10.10.18, 00:57:04, Serial1/0

C 10.10.10.6/32 is directly connected, Serial1/1

C 10.10.10.4/30 is directly connected, Serial1/1

C 10.10.10.18/32 is directly connected, Serial1/0

C 10.10.10.16/30 is directly connected, Serial1/0

192.168.0.0/24 is variably subnetted, 2 subnets, 2 masks

C 192.168.0.12/30 is directly connected, Serial1/2

C 192.168.0.13/32 is directly connected, Serial1/2

R1#

Tables Bgp et de Routage de R4

Même constat et mêmes remarques que pour R1, si ce n’est un peu plus d’éléments directly connected, puisque nous avons une liaison de type « Dual-homed » (2 liens). Il y a juste une petite différence. Comme ce lien est de type Dual-homed, R4 va tenter de joindre R6 non pas par l’adresse IP de l’interface d’en face, mais par sa loopback… et celle-ci est inconnue de R4. Nous avons précédemment due saisir une route statique pour joindre 8.8.8.8, nous allons donc la retrouver dans cette table de routage, mais ATTENTION ! Cette route n’est en aucun cas diffusée par l’IGP de R4 !

R4#sh ip bgp

BGP table version is 3, local router ID is 9.9.9.5

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

r RIB-failure, S Stale

Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

*>i1.1.1.0/24 9.9.9.2 0 100 0 64000 i

*> 2.2.2.0/24 8.8.8.8 0 0 65000 i

R4#sh ip route

1.0.0.0/24 is subnetted, 1 subnets

B 1.1.1.0 [200/0] via 9.9.9.2, 01:06:03

2.0.0.0/24 is subnetted, 1 subnets

B 2.2.2.0 [20/0] via 8.8.8.8, 01:06:05

8.0.0.0/32 is subnetted, 1 subnets

S 8.8.8.8 [1/0] via 192.168.0.10

[1/0] via 192.168.0.6

9.0.0.0/32 is subnetted, 4 subnets

O 9.9.9.3 [110/65] via 10.10.10.14, 01:07:24, Serial1/2

O 9.9.9.2 [110/129] via 10.10.10.14, 01:07:24, Serial1/2

[110/129] via 10.10.10.9, 01:07:24, Serial1/0

C 9.9.9.5 is directly connected, Loopback0

O 9.9.9.4 [110/65] via 10.10.10.9, 01:07:25, Serial1/0

10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks

C 10.10.10.8/30 is directly connected, Serial1/0

C 10.10.10.9/32 is directly connected, Serial1/0

C 10.10.10.14/32 is directly connected, Serial1/2

C 10.10.10.12/30 is directly connected, Serial1/2

O 10.10.10.4/30 [110/128] via 10.10.10.9, 01:07:26, Serial1/0

O 10.10.10.16/30 [110/128] via 10.10.10.14, 01:07:26, Serial1/2

192.168.0.0/24 is variably subnetted, 4 subnets, 2 masks

C 192.168.0.8/30 is directly connected, Serial1/3

C 192.168.0.10/32 is directly connected, Serial1/3

C 192.168.0.4/30 is directly connected, Serial1/1

C 192.168.0.6/32 is directly connected, Serial1/1

R4#

Tables Bgp et de Routage de R2

Ces routeurs sont full iBgp (dans le sens ou il n’y a pas de session eBgp). On retrouve donc nos réseaux transmis via la table Bgp, et les loopbacks de nos Peers…

R2#sh ip bgp

BGP table version is 3, local router ID is 9.9.9.3

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

r RIB-failure, S Stale

Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

*>i1.1.1.0/24 9.9.9.2 0 100 0 64000 i

*>i2.2.2.0/24 9.9.9.5 0 100 0 65000 i

R2#sh ip route

1.0.0.0/24 is subnetted, 1 subnets

B 1.1.1.0 [200/0] via 9.9.9.2, 01:15:25

2.0.0.0/24 is subnetted, 1 subnets

B 2.2.2.0 [200/0] via 9.9.9.5, 01:15:27

9.0.0.0/32 is subnetted, 4 subnets

C 9.9.9.3 is directly connected, Loopback0

O 9.9.9.2 [110/65] via 10.10.10.17, 01:16:46, Serial1/0

O 9.9.9.5 [110/65] via 10.10.10.13, 01:16:46, Serial1/2

O 9.9.9.4 [110/129] via 10.10.10.17, 01:16:46, Serial1/0

[110/129] via 10.10.10.13, 01:16:46, Serial1/2

10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks

O 10.10.10.8/30 [110/128] via 10.10.10.13, 01:16:48, Serial1/2

C 10.10.10.12/30 is directly connected, Serial1/2

C 10.10.10.13/32 is directly connected, Serial1/2

O 10.10.10.4/30 [110/128] via 10.10.10.17, 01:16:48, Serial1/0

C 10.10.10.16/30 is directly connected, Serial1/0

C 10.10.10.17/32 is directly connected, Serial1/0

R2#

Tables Bgp et de Routage de R3

R3#sh ip bgp

BGP table version is 3, local router ID is 9.9.9.4

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

r RIB-failure, S Stale

Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

*>i1.1.1.0/24 9.9.9.2 0 100 0 64000 i

*>i2.2.2.0/24 9.9.9.5 0 100 0 65000 i

R3#sh ip route

1.0.0.0/24 is subnetted, 1 subnets

B 1.1.1.0 [200/0] via 9.9.9.2, 01:18:16

2.0.0.0/24 is subnetted, 1 subnets

B 2.2.2.0 [200/0] via 9.9.9.5, 01:18:18

9.0.0.0/32 is subnetted, 4 subnets

O 9.9.9.3 [110/129] via 10.10.10.10, 01:19:36, Serial1/0

[110/129] via 10.10.10.5, 01:19:36, Serial1/1

O 9.9.9.2 [110/65] via 10.10.10.5, 01:19:36, Serial1/1

O 9.9.9.5 [110/65] via 10.10.10.10, 01:19:36, Serial1/0

C 9.9.9.4 is directly connected, Loopback0

10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks

C 10.10.10.10/32 is directly connected, Serial1/0

C 10.10.10.8/30 is directly connected, Serial1/0

O 10.10.10.12/30 [110/128] via 10.10.10.10, 01:19:39, Serial1/0

C 10.10.10.4/30 is directly connected, Serial1/1

C 10.10.10.5/32 is directly connected, Serial1/1

O 10.10.10.16/30 [110/128] via 10.10.10.5, 01:19:39, Serial1/1

R3#

Une validation finale ? Essayons de faire un ping de notre PC1 (1.1.1.1) vers notre PC2 (2.2.2.2). Moyennant la perte du premier paquet, (le processus Arp prend du temps…) tout marche bien.

-ooOoo

Page updated

Google Sites

Report abuse