On l'a vu, la configuration de BGP est extrêmement simple. En quelques lignes, on peut annoncer son réseau au monde entier. Mais peu d'opérateurs utilisent une configuration aussi simple. En effet, elle les exposerait à un gros risque : celui d'une erreur chez un voisin qui leur enverrait des routes que le voisin ne pourrait pas traiter. Par exemple, si un voisin BGP annonce la totalité des routes de l'Internet, et si en plus son AS path est erroné et très court, tout le trafic depuis votre réseau va lui être envoyé. Cela saturera probablement sa ligne. Pire, s'il ne route pas correctement ces préfixes, il aura créé un trou noir : il annonce qu'il route pour ces réseaux mais il ne le fait pas. De telles erreurs sont relativement courantes. Lorsqu'on a des dizaines de voisins, elles se produisent plusieurs fois par an.

Inutile de dire que la réciproque est vraie : si vous annoncez à tort des routes, vous allez perturber vos voisins et mettre en danger les bonnes relations que vous avez avec eux.

Pour s'en garder, on limite souvent le nombre de préfixes que le voisin peut envoyer. Par exemple, si on sait que le voisin est un tout petit opérateur, on peut :

neighbor 10.5.6.7 maximum-prefixes 10
      

On le limite ainsi à dix préfixes maximum. S'il dépasse ce nombre d'annonces, la session BGP est coupée automatiquement.

On ne peut pas toujours utiliser cette technique^[30]et, de toute façon, il vaut mieux mettre ceintures et bretelles : on va empêcher certaines annonces aberrantes de nous atteindre.

Première technique : on crée une liste de préfixes que l'on n'acceptera pas (syntaxe Quagga ou IOS) :

! Filtrage standard pour annonces entrantes Transit 
! Tout permettre sauf routes aberrantes et routes à nous (80.67.160.0/19)
ip prefix-list transit-in deny 80.67.160.0/18 ge 19
! Les annonces trop générales sont probablement des erreurs. Refuser
! ce qui a moins de 6 bits.
ip prefix-list transit-in deny 0.0.0.0/0 le 6
! Ensuite, on filtre le RFC 1918
ip prefix-list transit-in deny 192.168.0.0/15 ge 16
ip prefix-list transit-in deny 172.16.0.0/11 ge 12
ip prefix-list transit-in deny 10.0.0.0/7 ge 8
ip prefix-list transit-in deny 127.0.0.0/7 ge 8
! On accepte tout le reste
ip prefix-list transit-in permit any
	

	Quagga exige que la longueur maximale (ici 19) soit strictement supérieure à celle du préfixe. Ici, le vrai préfixe est 80.67.160.0/19. On n'acceptera aucune annonce de ce réseau avec un préfixe de longueur égale ou supérieure (ge) à 19.
	Si vous avez configuré debug bgp updates, vous verrez dans le journal de Quagga des choses comme 2003/03/03 15:17:02 BGP: 10.4.200.2 rcvd UPDATE about 10.0.0.0/8 -- DENIED due to: filter; si votre voisin tente d'envoyer des routes invalides. Prévenez-le gentiment.

Cette liste (que nous avons nommée transit-in) s'applique ensuite aux voisins :

neighbor 213.248.70.225 prefix-list transit-in in

Le "in" à la fin de la commande indique qu'on applique ce filtrage en entrée, aux annonces qui nous sont envoyées par 213.248.70.225.

Si le voisin n'est pas fournisseur de transit ou bien si on a au moins deux fournisseurs de transit, il est également prudent d'interdire l'annonce de la route par défaut.

ip prefix-list peer-in deny 80.67.160.0/18 ge 19
...
ip prefix-list peer-in deny 0.0.0.0/0
ip prefix-list peer-in permit any
	

En IPv6, un filtre recommandé est :

! Filtrage standard pour annonces entrantes Transit 
! Interdire routes aberrantes et routes à nous (2001:0910::/32)
! puis, contrairement à ce qui se fait pour IPv4, autoriser les allocations
! connues (6bone, RIR, etc) et interdire tout le reste.
! Filtres de Gert
ipv6 prefix-list transit-ip6-in deny 2001:0910::/31 ge 32
! Adresses privées
ipv6 prefix-list transit-ip6-in deny FEC0::/7 ge 8
ipv6 prefix-list transit-ip6-in deny ::/0 
ipv6 prefix-list transit-ip6-in permit 3ffe::/18 ge 24 le 24
ipv6 prefix-list transit-ip6-in permit 3ffe:4000::/18 ge 32 le 32
ipv6 prefix-list transit-ip6-in permit 3ffe:8000::/22 ge 28 le 28
ipv6 prefix-list transit-ip6-in permit 2001::/16 ge 28 le 35
! Lire le RFC 3056 "6to4 prefixes more specific than 2002::/16 must not be propagated
ipv6 prefix-list transit-ip6-in permit 2002::/16
ipv6 prefix-list transit-ip6-in deny any
	

Les listes de préfixe agissent sur les adresses IP des réseaux (préfixes) annoncés. Il existe aussi des filter-list pour filtrer sur les AS.

En sortie, on peut penser que rien n'est nécessaire, puisqu'on liste explicitement les réseaux annoncés avec network. Mais il ne faut pas oublier que votre routeur transmet aussi les annonces qu'il a reçu. Comme ce n'est pas toujours souhaité, on filtre :

ip prefix-list announce-out permit 80.67.160.0/19
ip prefix-list announce-out deny any
	

Ici, la liste announce-out ne permet qu'une seule annonce, 80.67.160.0/19. On l'applique à chaque voisin :

neighbor 213.248.70.225 prefix-list announce-out out
	

Pour être sûr de ne pas laisser échapper des routes vers d'autres AS, si on n'est pas soi-même opérateur de transit, on filtre aussi sur l'AS :

! N'annoncer que les routes nous ayant pour origine : AS path vide
ip as-path access-list 1 permit ^$
	

La syntaxe utilisée est celle des expression rationnelles. On applique ce filtre :

neighbor 213.248.70.225 filter-list 1 out
	

Si vous êtes un opérateur, vous pouvez filtrer les annonces de vos clients. Voici un exemple où le client (nommé ici "AS20766") annonce deux préfixes :

ip prefix-list AS20766 description Gitoyen 
ip prefix-list AS20766 permit 80.67.160.0/19 le 24
ip prefix-list AS20766 permit 217.24.80.0/20 le 24
	

Si on a plusieurs voisins, et que la même route est annoncée par certains d'entre eux, comment BGP choisit-il ? L'algorithme appliqué est bien décrit dans la documentation de Cisco. Pour le résumer (certains critères ont été omis), les critères suivants sont utilisés :

Voici un exemple de configuration de la préférence locale. On a deux voisins, 10.200.3.1 et 172.22.131.65, et on souhaite privilégier le premier, le second n'étant accessible que par un lien très lent, qu'on ne veut utiliser qu'en cas de panne du premier.

router bgp 300
 neighbor 172.22.131.65 route-map slowlink in

route-map slowlink permit 10
  set local-preference 1
  ! La préférence vaut 100 par défaut
	

Les routes annoncées par 172.22.131.65 seront alors gardées en réserve :

myrouter>  show ip bgp  17.228.3.1
BGP routing table entry for 17.228.3.0/24
Paths: (2 available, best #1, table Default-IP-Routing-Table)
  Advertised to non peer-group peers:
  172.22.131.65
  100 200
    10.200.3.1 from 10.200.3.1 (192.134.7.246)
      Origin IGP, localpref 100, valid, external, best
      Last update: Mon Mar  3 16:50:44 2003
                                           
  200
    172.22.131.65 from 172.22.131.65 (10.4.200.2)
      Origin IGP, localpref 1, valid, external
      Last update: Mon Mar  3 16:50:23 2003
	

Il est assez facile de contrôler le trafic sortant et de déterminer par où il sort. Avec le trafic entrant, c'est bien plus difficile^[31]. La décision est prise par un AS qui n'est pas le vôtre. La seule méthode générale est de jouer sur la longueur de l'AS path. Vous pouvez en effet ajouter votre propre numéro d'AS dans l'AS path pour décourager plus ou moins l'utilisation d'un lien.

Par exemple, si vous avez une connexion à un point d'échange local, dont l'utilisation est gratuite, et une autre à un fournisseur de transit cher, vous allez chercher à décourager l'utilisation du transit. Pour cela :

route-map expensive-transit-out permit 10
  ! Rallonger artificiellement l'AS_PATH pour défavoriser le transit, plus cher
  set as-path prepend 20766 
	

et vous appliquez cette route-map avec :

neighbor 2001:6c0:800:2000::2 route-map expensive-transit-out out
	

Vos annonces vont ainsi être allongées d'une unité (vérifiez-le avec un looking glass).

Vous n'avez pas forcément plusieurs fournisseurs de transit, car cela coûte cher. Mais vous aurez quand même besoin de BGP si vous vous connectez à un point d'échange. Un point d'échange est un endroit où les opérateurs Internet se connectent pour échanger du trafic. Physiquement, c'est en général un ou plusieurs commutateurs Ethernet, chaque opérateur se connectant à un port. Le point d'échange leur attribue des adresses IP et ils peuvent à partir de là se parler directement. Pour échanger du trafic, ils montent des sessions BGP entre eux. Par exemple, le FreeIX, le Pouix ou bien le Kixp sont des points d'échange.

À un point d'échange, les opérateurs sont des pairs : il n'y a plus de relation client-fournisseur. Il faut donc veiller à sa configuration.

Les points d'échange peuvent fournir d'autres services comme un route server, une machine qui établit des sessions BGP avec plusieurs opérateurs et redistribue les routes à chacun, évitant ainsi d'établir une session BGP par pair.

Jusqu'à présent, vous n'aviez qu'un seul routeur, éventuellement connecté à plusieurs fournisseurs. Mais dans la réalité, on a souvent plusieurs ASBR (Autonomous System Boundary Router) qui font du BGP avec l'extérieur. Soit parce qu'on répartit la charge et les risques^[32], soit parce que l'AS est géographiquement étendu et qu'on a un fournisseur à Rabat et un autre à Casablanca.

Dans ce cas, il faut synchroniser les routeurs BGP entre eux. Cela se fait typiquement en établissant des sessions BGP entre eux. Comme ces sessions se font à l'intérieur du même AS, on parle de iBGP (Internal BGP), les sessions BGP entre AS, que nous avons déjà utilisées, se nommant eBGP (External BGP). Dès que le numéro d'AS est le même aux deux bouts, le routeur BGP sait qu'il fait de l'iBGP.

Figure 2. iBGP dans l'AS

La configuration correspondant à ce schéma est la suivante :

! RTA
router bgp 100
  bgp router-id 192.169.23.5
  ! Session eBGP 
  neighbor 10.1.0.2 remote-as 200
  ! Session iBGP
  neighbor 192.169.23.6 remote-as 100
 

	Important
	En iBGP, le next hop (routeur suivant) n'est pas modifié, par défaut. Cela veut dire que les routeurs de vos fournisseurs ou pairs doivent être joignables de tout l'AS, via OSPF ou via une route statique. Si vous oubliez cela, vous aurez des routes non installées (voir l'exercice à ce sujet).

Important

Cela suppose que vos routeurs sont capables de suivre récursivement une route (avec IOS, cela nécessite no synchronization dans router bgp AS). Sinon, les routes seront bien apprises par iBGP mais pas installées dans la table de routage (si vous avez fait un debug ip bgp updates, vous verrez des BGP: nettable_walker 172.22.0.0/255.255.0.0 not synchronized). Vous devrez alors utiliser la technique next-hop-self décrite plus loin.

Si vous avez peu de routeurs iBGP, il peut être plus intéressant de changer le next hop. Dans ce cas, le routeur qui annonce sera celui qui route. Cela se fait avec :

  neighbor 192.169.23.6 next-hop-self
	

show ip bgp adresse-IP vous donnera le next hop pour cette adresse IP.

	Important
	Tous les routeurs iBGP d'un AS doivent avoir une session iBGP avec tous les autres, pour que l'AS soit complètement connecté.

Compte-tenu de la faible taille de certaines ressources, comme les numéros d'AS (16 bits seulement), il est parfois très difficile d'obtenir des numéros d'AS publics. On peut toutefois faire du BGP avec des numéros d'AS privés (de 64512 à 65535) mais cela nécessite du soin pour éviter que des AS path avec ces numéros se retrouvent dans la table de routage globale.

La solution la plus simple est de supprimer ces numéros privés lors des annonces extérieures :

neighbor fec0:1::2 remove-private-AS 
	

On trouvera tous les détails chez Cisco.

Pour l'instant, nous avons complètement séparé le routage externe avec BGP du routage interne avec OSPF. C'est la méthode recommandée. Mais il est parfois utile de mélanger partiellement les deux. Tous les routeurs permettent de redistribuer l'information acquise par OSPF dans BGP ou l'inverse.

	Avertissement
	Redistribuer l'information interne dans BGP est très dangereux : n'importe quelle oscillation ou panne de votre réseau sera visible à l'extérieur. C'est en outre inutile : vous avez typiquement beaucoup moins de routeurs externes que de routeurs internes et la topologie que vous faites connaitre à l'extérieur est donc plus simple.