Si les choses ne marchent pas comme attendu, il faut procéder avec méthode. Si vous envisagez de demander sur une liste de diffusion [33], il va falloir pouvoir donner toute l'information issue de ce processus de déboguage.
D'abord, il va falloir tester la connectivité de base de vos routeurs. Si deux routeurs ne peuvent pas se pinguer, BGP ne marchera certainement pas[34]
Si ping échoue (naturellement, vous testez ping avec une adresse IP comme argument, pas un nom, pour ne pas dépendre du DNS), entamez la procédure de déboguage classique en cas de routage statique.
Une fois que ping entre routeurs voisins fonctionne, vous pouvez regarder la table de routage. traceroute vous montrera le chemin pris par les paquets[35]. Les commandes route -n sur Linux, route -n show sur NetBSD ou encore show ip route sur IOS vous montreront la table de routage (FIB, Forwarding Information Base) utilisée par le routeur.
La première chose à tester est l'établissement de la session BGP. BGP tourne au dessus de TCP et une session BGP nécessite une session TCP. Une fois celle-ci établie, les deux routeurs se synchronisent et s'envoient des préfixes.
myrouter> show ip bgp summary BGP router identifier 80.67.168.1, local AS number 20766 22155 BGP AS-PATH entries 73 BGP community entries NeighborV AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 213.228.3.217 4 21502 0 0 0 0 0 00:01:33 Active
213.228.3.218 4 15703 141649 141414 0 0 0 03w6d06h
17
...
| | C'est l'adresse IP du voisin qui est indiquée, pas son router ID. |
| | Active signifie que la session n'a pas encore pu être établie. Toute valeur autre qu'un chiffre indique un problème. |
| | Les sessions BGP peuvent durer très longtemps (ici, plus de trois semaines). |
| | Quant la session est établie, le nombre de préfixes reçu est affiché ici. |
L'examen du journal de Quagga[36] nous donne des informations supplémentaires par exemple :
2003/02/17 14:19:48 BGP: MAXPFXEXCEED: No. of prefix received from 10.228.3.227 (afi 1): 100 exceed limit 100
(un voisin BGP a dépassé la valeur du paramètre maximum-prefixes : la session BGP devra être redémarrée manuellement avec clear bgp addresse-IP).
Outre les mécanismes de déboguage des routeurs (journal de Quagga, commandes debug ? d'IOS), les traditionnels outils de déboguage réseau comme tcpdump et ethereal sont souvent très précieux. tcpdump est disponible partout et permet de voir facilement si des paquets BGP circulent :
% sudo tcpdump -i eth1 -n port bgp 11:09:54.874825 194.68.129.170.179 > 194.68.129.186.58511: P 889028570:889028589(19) ack 3950494887 win 16384 <nop,nop,timestamp 1501324534 725821804>: BGP (KEEPALIVE) [tos 0xc0] 11:09:54.874893 194.68.129.186.58511 > 194.68.129.170.179: . ack 19 win 63066 <nop,nop,timestamp 725824481 1501324534> (DF) [ttl 1]
On peut aussi recueillir des informations avec la section intitulée « SNMP ». RFC 1657 décrit la MIB associée à BGP. Ici, on interroge un routeur Unix+Quagga [37](15 est le point de départ de la MIB BGP, voir le RFC ci-dessus) :
%snmpwalk -m /usr/share/mibs/BGP4-MIB.txt 80.67.160.1 password 15
...
bgp.bgpPeerTable.bgpPeerEntry.bgpPeerState.194.68.129.224 = established(6)
bgp.bgpPeerTable.bgpPeerEntry.bgpPeerState.194.68.129.225 = established(6)
ce qui permet de voir, entre outres, que les session BGP avec nos voisins sont dans un état normal[38] .
Un looking glass est un système public permettant d'obtenir des informations BGP. C'est un outil indispensable pour voir les tables BGP d'un autre point de vue. Par exemple, le looking glass va vous permettre de voir si vos annonces sont bien propagées.
L'interface d'un looking glass peut être en ligne de commande ou bien via le Web. On trouve les adresses de beaucoup de looking glass sur traceroute.org.
Prenons un exemple, le looking glass de Netlantis, qui a des sessions BGP avec de très nombreux routeurs en Europe :
% telnet 62.220.128.140 zebra>show ip bgp 192.134.7.250 BGP routing table entry for 192.134.4.0/22 Paths: (28 available, best #28, table Default-IP-Routing-Table) ... 3303 2200 2485 164.128.32.11 from 164.128.32.11 (164.128.32.11) Origin IGP, localpref 100, valid, external, best Last update: Mon Feb 24 12:04:57 2003
On voit ici que le réseau est bien annoncé, 192.134.4.0/22 est reçu via de nombreuses voies. Toutes les annonces se font via l'AS 2200 (à l'heure où j'écris, c'est en effet uniquement via ce fournisseur que ce réseau est annoncé).
Le looking glass de Swinog est neutre au sens où il ne dépend pas d'un opérateur particulier, il tient ses données des sessions BGP qu'il établit avec de nombreux opérateurs. Si maintenant nous sommes intéressés par l'état de nos annonces chez un opérateur particulier, ici Tiscali :
% telnet route-server.ip.tiscali.net route-server.ip.tiscali.net>show ip bgp 192.134.7.250 BGP routing table entry for 192.134.4.0/22, version 7626472 Paths: (1 available, best #1) Not advertised to any peer 3257 5511 2200 2485 213.200.64.93 from 213.200.64.93 (213.200.87.18) Origin IGP, metric 110, localpref 100, valid, external, best Community: 3257:4130 3257:5033
On voit que Tiscali a bien reçu notre annonce.
D'autres looking glass sont accessibles via le Web, en remplissant un formulaire.
traceroute.org permet également de faire un traceroute inverse, c'est-à-dire de voir le chemin qu'empruntent les paquets pour venir chez vous[39].
Certains traceroute, comme celui d'IOS lorsque le routeur est un routeur BGP, ou bien lft sur Unix, permettent d'afficher la liste des AS parcourus. Ici, un exemple avec lft :
% lft -A www.afnog.org
Tracing ___________________________________________!_!_!!__!___!_!___!___.
TTL LFT trace to wawa.eahd.or.ug (216.129.132.164):80/tcp
1 [AS20766] meowth.gitoyen.net (80.67.160.1) 0.5ms
2 [AS20766] voltaire-gw.gitoyen.net (80.67.160.34) 1.1ms
3 [AS6461] 132.ge3-0.er1a.cdg2.fr.mfnx.net (62.4.73.26) 1.4ms
4 [AS6461] pos0-3.cr1.cdg2.fr.mfnx.net (208.184.231.206) 1.6ms
5 [AS6461] so-5-0-0.cr1.lhr3.uk.mfnx.net (64.125.31.154) 11.4ms
6 [AS6461] so-0-0-0.cr2.lhr3.uk.mfnx.net (208.184.231.146) 11.4ms
7 [AS6461] so-7-0-0.cr2.lga1.us.mfnx.net (64.125.31.182) 83.0ms
8 [AS6461] so-0-0-0.cr2.lga2.us.mfnx.net (208.184.232.198) 82.9ms
9 [AS6461] pos1-0.pr1.lga2.us.mfnx.net (216.200.127.170) 82.8ms
10 [AS6461] uunet-abovenet-oc12.lga2.above.net (208.184.231.246) 83.8ms
11 [AS701] 526.at-5-1-0.XR2.NYC8.ALTER.NET (152.63.23.78) 84.0ms
12 [AS701] 282.ATM7-0.XR2.TTN1.ALTER.NET (152.63.30.98) 88.4ms
13 [AS701] POS11-0-0.SR1.TTN1.ALTER.NET (152.63.15.213) 88.3ms
14 [AS701] darkom-gw.customer.alter.net (157.130.222.162) 87.8ms
15 [AS11908] host-66-133-0-46.verestar.net (66.133.0.46) 87.9ms
16 [AS11908] lci-gw10-s0-230.lightband.net (216.129.151.114) 97.9ms
17 [AS11908] afsat-gw.lightband.com (216.129.134.226) 98.6ms
18 [ASN?] 192.168.200.2 746.5ms
19 [AS11908] [target] wawa.eahd.or.ug (216.129.132.164):80 930.6ms
On note que le routeur 18 a une adresse privée (RFC 1918) et que son AS ne peut donc pas être trouvé.
Les exemples de cette section sont présentés sous une forme de questions à une liste de diffusion, avec les informations nécessaires puis les réponses[40].
| Q : | Ma session BGP ne s'établit pas et je ne vois même pas les paquets avec tcpdump J'ai la configuration suivante : +-----------------------+ +------------+ +---------+ |Routeur du fournisseur | Ligne spécialisée | Routeur |---| Routeur | |d'accès |---------------------| d'entrée | | BGP | +-----------------------+ +------------+ +---------+ Je ne peux pas utiliser le routeur BGP comme routeur d'entrée car il n'a pas la bonne carte pour se connecter à la ligne spécialisée. Et je ne peux pas utiliser le routeur d'entrée comme routeur BGP car il n'a pas assez de mémoire. La session entre les deux routeurs BGP ne s'établit pas. Sur mon routeur BGP, un tcpdump ne montre pas de paquets BGP entrants, juste les demandes de mon routeur. Pourtant, les deux routeurs peuvent se pinguer et je peux faire un telnet routeur-FAI bgp depuis mon routeur BGP : la connexion TCP s'établit bien. | ||||
| R : | C'est normal : par défaut, eBGP est mono-saut ce qui veut dire qu'il n'accepte pas de routeurs intermédiaires. En outre, votre routeur met la durée de vie des paquets (TTL) à 1[41]. Si vous ne pouvez pas convaincre le routeur d'entrée de fonctionner en simple pont (couche 2), la seule solution est de passer en eBGP multihop avec neighbor routeur-FAI ebgp-multihop 2 (2 étant le nombre de sauts, que vous pouvez vérifier avec traceroute).
| ||||
| Q : | La session BGP ne s'établit pas, les voisins restent dans l'état Active/Idle. Mes deux routeurs BGP (des PC/Unix avec Quagga) ne peuvent pas établir une session. Ils sont sur le même Ethernet et peuvent se pinguer. show ip bgp summary montre : BGP router identifier 192.134.7.245, local AS number 65432 1 BGP AS-PATH entries 0 BGP community entries Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 192.134.7.241 4 200 6 6 0 0 0 00:00:02 Idle Voici la configuration de 192.134.7.245 : router bgp 65432 bgp router-id 192.134.7.245 network 172.17.1.0/23 neighbor 192.134.7.241 remote-as 200 et de 192.134.7.241 : router bgp 200 bgp router-id 192.134.7.241 network 10.1.0.0/16 neighbor 192.134.7.245 remote-as 100
| ||||
| R : | 192.134.7.241 pense que l'AS de 192.134.7.245 est 100 alors que 192.134.7.245 a déclaré son AS comme étant 65432. Je ne crois pas que Quagga signale cette erreur dans son journal ou dans la sortie de show ip bgp neighbors. Mais un tcpdump ou bien un ethereal vous aurait montré le problème (ici, avec tcpdump) :
192.134.7.241.179 > 192.134.7.245.46151: P 1:24(23) ack 46 win 17520:\
BGP (NOTIFICATION: error OPEN Message Error, subcode Bad Peer AS) [ttl 1]
| ||||
| Q : | La session BGP est établie mais aucune route n'est envoyée. show ip bgp summary montre zéro préfixe :
requin> show ip bgp summary
BGP router identifier 192.134.7.245, local AS number 100
1 BGP AS-PATH entries
0 BGP community entries
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
192.134.7.241 4 200 6 10 0 0 0 00:00:01 0
La configuration de 192.134.7.241 (un PC/NetBSD avec Zebra) est : router bgp 200 bgp router-id 192.134.7.241 neighbor 192.134.7.245 remote-as 100 et j'ai comme routes :
% route -n show
Routing tables
Internet:
Destination Gateway Flags
default 192.134.7.254 UG
10.4.200.0 192.134.7.245 UG
192.134.7.240 link#1 U
172.17.0.0 link#2 U
Pourquoi ne sont-elles pas annoncées en BGP ? | ||||
| R : | Par défaut, BGP n'annonce aucune route, pour des raisons de sécurité. Vous devez mettre des directives network dans votre fichier de configuration pour avoir des annonces. Faites ensuite un show ip bgp neighbour 192.134.7.245 advertised-routes sur le routeur censé faire les annonces. Vous devriez voir quelque chose du genre : BGP table version is 0, local router ID is 192.134.7.241 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 *> 172.17.0.0 192.134.7.241 0 32768 i Total number of prefixes 1 | ||||
| Q : | Mes routes apprises en iBGP ne se retrouvent pas dans la table de routage. Un routeur iBGP (un PC/Linux avec Zebra) reçoit bien une route en iBGP mais elle n'est pas installé dans le noyau (je ne la vois pas avec route -n) : laperouse> show ip bgp 10.30.0.0 BGP routing table entry for 10.30.0.0/16 Paths: (1 available, no best path) Not advertised to any peer 300 192.134.7.246 (inaccessible) from 172.22.131.64 (192.134.7.241) Origin IGP, metric 0, localpref 100, valid, internal Last update: Wed Feb 26 14:02:40 2003 Pourquoi ? Est-ce parce que le next hop est marqué inaccessible ? | ||||
| R : | Oui. Le routeur 192.134.7.246 (le next hop) n'est pas accessible via une entrée de la table de routage. Ajoutez une route statique ou bien configurez OSPF pour annoncer cette route ou encore passez en next-hop-self. | ||||
[33] Une très bonne idée : je suis toujours stupéfait que tant de responsables réseau passent des semaines à chercher seuls alors que la compétence de dizaines d'autres ingénieurs expérimentés est à leur disposition gratuitement.
Une raison probable est que demander de l'aide à des égaux (pas à un enseignant ou à un consultant payé pour cela) sur une liste publique ou même semi-publique est une compétence nécessaire et qui ne s'apprend pas dans les écoles, malheureusement.
[34] Il y a une exception : en présence de filtres (comme les ACL d'IOS ou bien le Netfilter de Linux), certains protocoles marchent et d'autres pas. Compte tenu de la complexité supplémentaire que cela entraine, je recommande de faire vos premiers essais BGP sur une machine sans filtres.
[35] Rappelez-vous toujours que traceroute ne montre que le chemin aller. Si vous avez plusieurs routes possibles, rien ne garantit que le chemin retour soit identique.
[36] L'endroit exact où se trouve ce journal dépend de votre configuration. C'est souvent /var/log/zebra/bgpd.log. Je rappelle que tail -f est la façon la plus pratique de lire un fichier journal.
[37] L'option -m est nécessaire si les MIB ne sont pas installées là où SNMP les attend.
[38] On peut ensuite développer d'utiles applications. Par exemple, Marc Hauswirth a écrit un script de surveillance des sessions BGP pour le logiciel de contrôle mon, script qui utilise SNMP et qui permet d'être automatiquement prévenu si une session BGP tombe.
[39] Rappelez-vous que le chemin n'est pas forcément symétrique.
[40] Cela n'a rien à voir avec BGP mais je regrette l'abondance, sur les listes de diffusion techniques, de messages mal écrits, avec insuffisamment d'informations. J'essaie donc de montrer le bon exemple.
[41] telnet ne le fait pas et c'est pour cela que telnet marche.
![[Warning]](images/warning.png)