P24 - BGP de A à Z

Objectif

Tout savoir sur BGP (Border Gateway Protocol), le protocole qui fait tenir Internet : vocabulaire, fonctionnement, attributs, choix du meilleur chemin, configuration Cisco et Linux (FRRouting), filtrage, multihoming, sécurité (RPKI) et dépannage. Fiche de référence complète, à lire dans l’ordre la première fois.

Sources et prérequis

Cours de lidstah : cours de lidstah.

Vue d’ensemble plus courte : P11 - Routage avancé (BGP, EIGRP, MPLS).

Prérequis : R03 - Adressage IPv4 et classes (CIDR), R04 - Sous-réseaux et VLSM, P02 - Routage dynamique (RIP, OSPF) (routage dynamique, OSPF), P03 - ACL et NAT sur Cisco (ACL, wildcard).

Sommaire

1. BGP en une image
2. Le vocabulaire indispensable
3. Les principes de fonctionnement
4. La session BGP (états, messages, minuteries)
5. Les trois tables de BGP
6. Les attributs de chemin
7. Le choix du meilleur chemin
8. Labo Cisco complet pas à pas
9. Filtrer ce qu’on reçoit et ce qu’on annonce
10. Agrégation et communautés
11. Influencer le trafic (multihoming)
12. iBGP à grande échelle (route reflectors)
13. BGP et IPv6 (MP-BGP)
14. Sécurité de BGP
15. BGP sous Linux avec FRRouting
16. BGP ailleurs qu’entre opérateurs
17. Outils pour observer Internet
18. Aide-mémoire des commandes
Exercices
Erreurs fréquentes / dépannage

1. BGP en une image

Internet n’est pas un réseau : c’est l’interconnexion de plus de 75 000 réseaux indépendants (opérateurs, hébergeurs, universités, grandes entreprises). Chacun est un système autonome (AS). BGP est la langue qu’ils parlent pour se dire « moi, je sais joindre ces adresses ».

flowchart LR
  subgraph AS64500["AS 64500 — ton entreprise"]
    E["Routeur de bordure"]
  end
  subgraph AS174["AS 174 — Cogent (transitaire)"]
    C1["Routeur"] --- C2["Routeur"]
  end
  subgraph AS3215["AS 3215 — Orange"]
    O["Routeur"]
  end
  subgraph AS15169["AS 15169 — Google"]
    G["Routeur"]
  end
  E ---|"eBGP<br/>« je possède 203.0.113.0/24 »"| C1
  C2 ---|"eBGP"| O
  C2 ---|"eBGP"| G
  O ---|"eBGP (peering)"| G

   Ce que BGP transporte : des « annonces »

   « Le réseau 203.0.113.0/24 est joignable par moi.
     Pour y aller, le chemin d'AS est : 174 64500 »
                                         │    └── l'AS d'origine (le propriétaire)
                                         └─────── l'AS qui relaie l'annonce

La phrase à retenir

BGP ne route pas les paquets, il annonce des routes. Les paquets sont transmis par la table de routage classique ; BGP se contente de la remplir avec les meilleurs chemins appris de ses voisins.

2. Le vocabulaire indispensable

Systèmes autonomes

Terme	Signification
AS (Autonomous System)	Ensemble de réseaux IP publics sous une politique de routage, géré par une organisation
ASN	Numéro d’AS. 16 bits à l’origine (1 à 65535), 32 bits depuis 2007 (jusqu’à 4 294 967 295)
Préfixe	Un bloc d’adresses annoncé, en notation CIDR : `203.0.113.0/24`
Voisin / peer	Routeur avec qui on a une session BGP (configurée à la main)
Speaker / routeur de bordure	Routeur qui parle BGP avec l’extérieur
eBGP	Session entre deux AS différents
iBGP	Session entre deux routeurs du même AS
IGP	Routage interne à l’AS (OSPF, IS-IS)
EGP	Routage entre AS : en pratique, BGP version 4 (RFC 4271)

Exemples réels : AS 174 = Cogent, AS 3215 = Orange, AS 12322 = Free, AS 15169 = Google, AS 16276 = OVH (ton hébergeur), AS 203432 = FAImaison (association nantaise, citée par lidstah).

Numéros d’AS réservés

Plage	Usage
0	Réservé, interdit
23456	AS_TRANS : sert de remplaçant pour les vieux routeurs qui ne comprennent pas les ASN 32 bits
64496 – 64511 et 65536 – 65551	Documentation et exemples (comme 192.0.2.0/24 pour les IP)
64512 – 65534	Privés 16 bits : labos, réseaux internes, datacenters (comme le RFC 1918 pour les IP)
4 200 000 000 – 4 294 967 294	Privés 32 bits
65535, 4 294 967 295	Réservés

Un AS privé ne doit jamais apparaître sur Internet

Comme une adresse 192.168.x.x. Un opérateur supprime les ASN privés avant de relayer une route (neighbor X remove-private-as chez Cisco).

Qui distribue les numéros ?

IANA (mondial)
 └── RIR (un par continent)
      ├── RIPE NCC   → Europe, Moyen-Orient, Russie (siège : Amsterdam)
      ├── ARIN       → Amérique du Nord
      ├── APNIC      → Asie-Pacifique
      ├── LACNIC     → Amérique latine
      └── AFRINIC    → Afrique
           └── LIR (membres du RIR : opérateurs, associations…)
                └── les organisations qui reçoivent ASN et blocs d'IP

Pour obtenir un ASN, il faut être multihomé (relié à au moins deux autres AS) ou avoir une politique de routage propre, et passer par un LIR. Les blocs IPv4 sont devenus rares (on justifie chaque besoin) ; en IPv6 un LIR fournit typiquement un /32, une organisation un /48.

Transit, peering, IXP

Terme	Explication
Transit	Un opérateur te vend l’accès à tout Internet. Facturé au débit, en général au 95ᵉ centile (on retire les 5 % de pics du mois)
Peering	Deux AS échangent leur trafic mutuel, souvent gratuitement si les volumes sont équilibrés (au-delà d’un ratio d’environ 2,5 il devient souvent payant)
IXP (Internet eXchange Point)	Lieu physique où des dizaines d’AS se branchent sur un même switch pour faire du peering : France-IX, Equinix Paris, Ouest-IX (Nantes/Rennes), LyonIX…
Route server	Serveur BGP d’un IXP : on monte une session avec lui au lieu de cent sessions avec tous les membres
Tier 1	Opérateur qui n’achète jamais de transit (Cogent, Lumen, NTT, Orange OpenTransit…)
Tier 2	Achète du transit et en revend
Tier 3	Achète tout (petit FAI, entreprise)
Full view	La table BGP complète d’Internet : environ un million de préfixes IPv4 et plus de 200 000 en IPv6 en 2026. Il faut plusieurs Go de RAM sur le routeur
Route par défaut	Alternative à la full view : le transitaire n’envoie que `0.0.0.0/0` (suffisant pour un petit AS)

flowchart TB
  T1a["Tier 1 A"] <-->|"peering gratuit"| T1b["Tier 1 B"]
  T2["Tier 2<br/>(FAI régional)"] -->|"achète du transit"| T1a
  T3["Tier 3<br/>(petit FAI, entreprise)"] -->|"achète du transit"| T2
  T2 <-->|"peering à l'IXP"| T2b["Autre Tier 2"]

3. Les principes de fonctionnement

Caractéristique	Détail
Transport	TCP port 179 : la fiabilité est assurée par TCP, pas par BGP
Type	Vecteur de chemin (path vector) : chaque route porte la liste des AS traversés
Voisins	Déclarés à la main des deux côtés (aucune découverte automatique, contrairement à OSPF)
Mises à jour	Incrémentales : on n’envoie que ce qui change (pas de rafraîchissement périodique de toute la table)
Métrique	Pas de « coût » unique : une liste d’attributs comparés dans un ordre précis (§ 7)
Philosophie	Politique avant performance : on choisit selon des règles commerciales (« je préfère mon lien gratuit »), pas selon le débit
Convergence	Lente (dizaines de secondes à minutes) : la stabilité est privilégiée
Distance administrative (Cisco)	eBGP = 20 (plus fiable qu’OSPF 110) · iBGP = 200 (moins fiable que l’IGP)

Les deux règles anti-boucle

Règle eBGP : « Si je vois MON numéro d'AS dans l'AS_PATH, je refuse la route. »

   AS100 ──► AS200 ──► AS300 ──► AS100 ?
   AS_PATH reçu par AS100 : "300 200 100"  → contient 100 → REJETÉE

Règle iBGP (split horizon) : « Une route apprise d'un voisin iBGP
                              n'est JAMAIS renvoyée à un autre voisin iBGP. »

Conséquence de la règle iBGP : dans un AS, tous les routeurs BGP doivent être reliés entre eux en iBGP (full mesh : n × (n − 1) / 2 sessions, soit 45 sessions pour 10 routeurs !) ou utiliser des route reflectors (§ 12).

eBGP vs iBGP

	eBGP	iBGP
Entre	AS différents	Même AS
`remote-as`	≠ son propre AS	= son propre AS
TTL des paquets	1 (voisin directement connecté, sinon `ebgp-multihop`)	255 (peut traverser l’AS)
NEXT_HOP	Remplacé par l’IP du routeur qui annonce	Conservé tel quel (d’où `next-hop-self`)
AS_PATH	On ajoute son ASN en tête	Inchangé
LOCAL_PREF	Pas transmis	Transmis
Distance administrative	20	200
Session montée sur	L’IP de l’interface d’interconnexion	En général les loopbacks (plus stables)

4. La session BGP (états, messages, minuteries)

Les 6 états (machine à états finis)

stateDiagram-v2
  [*] --> Idle
  Idle --> Connect: démarrage, ouverture TCP vers le port 179
  Connect --> OpenSent: TCP établi, envoi d'OPEN
  Connect --> Active: échec TCP, nouvelle tentative
  Active --> OpenSent: TCP établi
  Active --> Idle: échec répété
  OpenSent --> OpenConfirm: OPEN du voisin reçu et accepté
  OpenConfirm --> Established: KEEPALIVE reçu
  Established --> Idle: NOTIFICATION ou hold timer expiré

État	Ce qui se passe	Si on reste bloqué ici
Idle	Rien, en attente	Voisin désactivé (`shutdown`), pas de route vers lui
Connect	Tentative de connexion TCP	Paquets perdus, pare-feu
Active	Nouvelle tentative après un échec TCP	Le plus courant : IP du voisin fausse, TCP/179 bloqué, mauvaise IP source (`update-source`), eBGP non direct (`ebgp-multihop`)
OpenSent	OPEN envoyé, on attend celui du voisin
OpenConfirm	OPEN reçu, on attend un KEEPALIVE	Mauvais ASN, mot de passe MD5 différent, router-id identiques
Established	✅ Les routes s’échangent	-

Piège de vocabulaire

Active ne veut pas dire « actif = ça marche » : c’est un état d’échec ! Dans show ip bgp summary, une session qui fonctionne affiche un nombre (les préfixes reçus) dans la colonne State/PfxRcd, pas un mot.

Les messages

Message	Contenu	Quand
OPEN	Version (4), ASN, hold time, router-id, capacités (IPv6, ASN 32 bits, route refresh…)	À l’ouverture
KEEPALIVE	Vide (19 octets)	Toutes les 60 s par défaut chez Cisco
UPDATE	Nouvelles routes (préfixes + attributs) et/ou routes retirées (withdrawn)	À chaque changement
NOTIFICATION	Code d’erreur	Juste avant de couper la session
ROUTE-REFRESH	« Renvoie-moi toutes tes routes »	Après un changement de filtre (`clear ip bgp X soft in`)

Minuteries

Minuterie	Cisco	Juniper / FRR	Rôle
Keepalive	60 s	30 s / 60 s	Fréquence des KEEPALIVE
Hold time	180 s	90 s / 180 s	Sans nouvelles du voisin pendant ce temps → session coupée

Les deux voisins retiennent le plus petit hold time proposé. Pour détecter une panne plus vite, on ne baisse pas trop ces minuteries : on ajoute BFD (Bidirectional Forwarding Detection, détection en moins d’une seconde).

router bgp 64500
 ! keepalive 10 s, hold 30 s (labo)
 neighbor 10.0.12.2 timers 10 30
 ! si BFD est configuré sur l'interface
 neighbor 10.0.12.2 fall-over bfd

5. Les trois tables de BGP

flowchart LR
  V["Voisins"] -->|"UPDATE"| IN["Adj-RIB-In<br/>tout ce qui est reçu<br/>(avant filtre)"]
  IN -->|"filtres en entrée<br/>(prefix-list, route-map in)"| LOC["Loc-RIB = table BGP<br/>show ip bgp<br/>meilleur chemin marqué >"]
  LOC -->|"meilleurs chemins"| RIB["Table de routage<br/>show ip route bgp<br/>(B)"]
  LOC -->|"filtres en sortie<br/>(route-map out)"| OUT["Adj-RIB-Out<br/>ce qu'on annonce"]
  OUT -->|"UPDATE"| V2["Voisins"]

Table	Commande Cisco	Contenu
Voisins	`show ip bgp summary`	Liste des peers, état, nombre de préfixes reçus
Table BGP	`show ip bgp`	Toutes les routes reçues, de tous les voisins, avec leurs attributs
Table de routage	`show ip route bgp`	Seulement les meilleures, effectivement utilisées

Lire `show ip bgp`

BGP table version is 7, local router ID is 1.1.1.1
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
 *>  10.10.0.0/24     0.0.0.0              0         32768 i
 *>  172.16.1.0/24    10.0.12.2            0             0 64501 i
 *   172.16.2.0/24    10.0.13.3                          0 64502 64503 i
 *>                   10.0.12.2                          0 64501 64503 i
 *>i 192.168.50.0/24  2.2.2.2              0    100      0 64504 i

Colonne / symbole	Signification
`*`	Route valide (next hop joignable)
`>`	Meilleur chemin, installé dans la table de routage
`i` (à gauche)	Apprise en iBGP
`r`	RIB-failure : une meilleure route existe déjà par un autre protocole (ex. statique)
`s` / `d`	Supprimée (agrégation) / pénalisée (dampening, route qui « clignote »)
Next Hop `0.0.0.0`	Route créée par ce routeur (commande `network`)
Metric	Le MED
LocPrf	La LOCAL_PREF (100 par défaut, vide pour les routes eBGP)
Weight	32768 pour ses propres routes, 0 sinon
Path + lettre finale	AS_PATH, puis l’ORIGIN : `i` (IGP / `network`), `e` (EGP, historique), `?` (incomplete / `redistribute`)

Sur la ligne 172.16.2.0/24, deux chemins existent : le second (via 64501) est préféré bien que les deux AS_PATH fassent la même longueur, à cause d’un critère plus bas dans la liste (§ 7).

6. Les attributs de chemin

Chaque route BGP transporte des attributs. Ce sont eux que BGP compare pour choisir.

Catégorie	Signification	Attributs
Bien connu obligatoire	Tous les routeurs le comprennent, présent dans chaque UPDATE	ORIGIN, AS_PATH, NEXT_HOP
Bien connu discrétionnaire	Tous le comprennent, présence facultative	LOCAL_PREF, ATOMIC_AGGREGATE
Optionnel transitif	Peut être inconnu, mais est relayé quand même	COMMUNITY, AGGREGATOR, LARGE_COMMUNITY
Optionnel non transitif	Peut être inconnu, pas relayé au-delà du voisin	MED, ORIGINATOR_ID, CLUSTER_LIST
Propre à Cisco	N’est jamais transmis, local au routeur	WEIGHT

Attribut	Rôle	Qui préfère quoi	Portée
WEIGHT (Cisco)	Préférer un voisin sur ce routeur	Le plus haut	Ce routeur seulement
LOCAL_PREF	Choisir la sortie de l’AS	Le plus haut (défaut 100)	Tout l’AS (iBGP)
AS_PATH	Liste des AS traversés, anti-boucle	Le plus court	Partout
ORIGIN	Comment la route est née	`i` < `e` < `?`	Partout
MED (Multi-Exit Discriminator)	Suggérer au voisin par quelle entrée venir	Le plus bas	AS voisin seulement
NEXT_HOP	IP à qui envoyer le paquet	Doit être joignable	-
COMMUNITY	Étiquette pour appliquer des politiques (`64500:100`)	-	Relayé

7. Le choix du meilleur chemin

Quand un routeur reçoit plusieurs chemins vers le même préfixe, il les compare critère par critère et s’arrête au premier qui départage (ordre Cisco) :

#	Critère	On préfère
0	NEXT_HOP joignable ?	Sinon la route est ignorée
1	WEIGHT	Le plus haut
2	LOCAL_PREF	Le plus haut
3	Route créée localement (`network`, `aggregate`)	Locale
4	AS_PATH	Le plus court
5	ORIGIN	IGP (`i`) < EGP (`e`) < incomplete (`?`)
6	MED	Le plus bas (comparé seulement entre routes du même AS voisin)
7	eBGP plutôt qu’iBGP	eBGP
8	Coût IGP jusqu’au next hop	Le plus bas (hot potato : on fait sortir le trafic au plus vite)
9	Multipath ?	Plusieurs routes égales installées si `maximum-paths`
10	Route eBGP la plus ancienne	La plus stable
11	Router-id du voisin	Le plus bas
12	Longueur de CLUSTER_LIST	La plus courte
13	Adresse IP du voisin	La plus basse

Moyen mnémotechnique

« We Love Oranges AS Oranges Mean Pure Refreshment » : Weight, Local pref, Originated localement, AS path, Origin, MED, Paths externes (eBGP), Router-id.

Ce critère passe AVANT tout BGP

Le routeur choisit d’abord la route la plus précise (préfixe le plus long) dans la table de routage, quel que soit le protocole. Si quelqu’un annonce 203.0.113.0/25 alors que tu annonces 203.0.113.0/24, la moitié de ton trafic part chez lui, même avec un AS_PATH plus long. C’est le principe des détournements (§ 14).

8. Labo Cisco complet pas à pas

Topologie

                       AS 64501                                AS 64502
                   ┌──────────────┐                        ┌──────────────┐
                   │     ISP1     │                        │     ISP2     │
                   │ Lo0 8.8.1.1  │                        │ Lo0 9.9.2.2  │
                   └──────┬───────┘                        └──────┬───────┘
                .1  10.0.11.0/30  eBGP                 eBGP  10.0.22.0/30  .1
                          │ .2                                 .2 │
   AS 64500    ┌──────────┴───────┐      10.0.12.0/30     ┌───────┴──────────┐
               │        R1        ├───────────────────────┤        R2        │
               │ Lo0 1.1.1.1/32   │ .1                 .2 │ Lo0 2.2.2.2/32   │
               └──────────┬───────┘   (OSPF aire 0 +      └───────┬──────────┘
                     .1   │          iBGP entre loopbacks)        │ .1
                10.0.13.0/30                                 10.0.23.0/30
                     .2   │                                       │ .2
               ┌──────────┴───────────────────────────────────────┴──┐
               │                         R3                          │
               │  Lo0 3.3.3.3/32   LAN 192.168.10.0/24 (.1)          │
               └─────────────────────────────────────────────────────┘
   Bloc public de l'entreprise annoncé à Internet : 203.0.113.0/24

Objectifs : AS 64500 (ton entreprise) est multihomé vers deux opérateurs, annonce son bloc 203.0.113.0/24, reçoit les routes des opérateurs, et ne devient pas transitaire entre eux.

Étape 1 - IGP interne (OSPF) pour joindre les loopbacks

iBGP a besoin que les loopbacks soient joignables : c’est le rôle de l’IGP.

! R1 (même principe sur R2 et R3 avec leurs réseaux)
interface Loopback0
 ip address 1.1.1.1 255.255.255.255
router ospf 1
 router-id 1.1.1.1
 network 1.1.1.1 0.0.0.0 area 0
 network 10.0.12.0 0.0.0.3 area 0
 network 10.0.13.0 0.0.0.3 area 0
 ! interface vers ISP1 : pas d'OSPF avec l'opérateur
 passive-interface GigabitEthernet0/0

Vérifier : show ip route ospf doit montrer 2.2.2.2/32 et 3.3.3.3/32 sur R1.

Étape 2 - eBGP vers les opérateurs

! R1
router bgp 64500
 bgp router-id 1.1.1.1
 bgp log-neighbor-changes
 neighbor 10.0.11.1 remote-as 64501
 neighbor 10.0.11.1 description ISP1-transit
 ! MD5, identique des deux côtés
 neighbor 10.0.11.1 password Labo-BGP-1
 
! ISP1
router bgp 64501
 neighbor 10.0.11.2 remote-as 64500
 neighbor 10.0.11.2 password Labo-BGP-1
 network 8.8.1.1 mask 255.255.255.255

(R2 ↔ ISP2 : même chose avec 10.0.22.0/30 et AS 64502.)

show ip bgp summary sur R1 : le voisin 10.0.11.1 doit afficher un nombre de préfixes.

Étape 3 - Annoncer son bloc avec `network`

La commande network de BGP n’active rien sur les interfaces (contrairement à OSPF) : elle annonce un préfixe s’il existe exactement (même masque) dans la table de routage. Astuce classique : une route statique vers Null0 qui « ancre » le bloc.

! R1 et R2
! le bloc existe toujours, même si un sous-réseau tombe
ip route 203.0.113.0 255.255.255.0 Null0
router bgp 64500
 ! ici c'est un MASQUE, pas un wildcard
 network 203.0.113.0 mask 255.255.255.0

network ou redistribute ?

network = liste précise, ORIGIN i, recommandé. redistribute connected|static|ospf = automatique mais risqué (on peut annoncer à Internet des réseaux privés), ORIGIN ? ; toujours avec une route-map de filtrage.

Étape 4 - iBGP entre loopbacks

! R1
router bgp 64500
 ! même AS = iBGP
 neighbor 2.2.2.2 remote-as 64500
 ! sinon la session part avec l'IP de l'interface
 neighbor 2.2.2.2 update-source Loopback0
 ! sinon R2 reçoit le next hop 10.0.11.1 qu'il ne connaît pas
 neighbor 2.2.2.2 next-hop-self
 neighbor 3.3.3.3 remote-as 64500
 neighbor 3.3.3.3 update-source Loopback0
 neighbor 3.3.3.3 next-hop-self

(Faire de même sur R2 vers 1.1.1.1 et 3.3.3.3, et sur R3 vers 1.1.1.1 et 2.2.2.2 : full mesh des 3 routeurs.)

Pourquoi next-hop-self ?

ISP1 annonce 8.8.1.1/32, next hop = 10.0.11.1 (son IP)
R1 relaie à R2 en iBGP SANS changer le next hop → R2 lit « next hop 10.0.11.1 »
R2 ne connaît pas 10.0.11.0/30 (pas dans OSPF) → route invalide (pas de *)
Avec next-hop-self : R1 écrit « next hop 1.1.1.1 » → R2 le joint par OSPF ✅

Étape 5 - Ne pas devenir transitaire

Sans filtre, R1 réannoncerait à ISP1 les routes apprises d’ISP2 : ton petit lien entreprise transporterait le trafic entre deux opérateurs. On n’annonce que ses propres préfixes :

! ^$ = AS_PATH vide = routes nées dans MON AS
ip as-path access-list 1 permit ^$
ip prefix-list MES-PREFIXES seq 5 permit 203.0.113.0/24
route-map VERS-OPERATEURS permit 10
 match ip address prefix-list MES-PREFIXES
 match as-path 1
router bgp 64500
 neighbor 10.0.11.1 route-map VERS-OPERATEURS out

Étape 6 - Vérifier

show ip bgp summary
show ip bgp
! tous les chemins vers ce préfixe et pourquoi le meilleur
show ip bgp 8.8.1.1
! ce qu'on annonce à ISP1
show ip bgp neighbors 10.0.11.1 advertised-routes
! ce qu'on a accepté d'ISP1
show ip bgp neighbors 10.0.11.1 routes
show ip route bgp
! depuis R3
ping 8.8.1.1 source 192.168.10.1

Faire ce labo

Packet Tracer gère un BGP simplifié (sessions eBGP de base). Pour iBGP, route-maps, communautés, il faut GNS3 ou EVE-NG avec des images Cisco, ou plus simplement FRRouting sur des VM Debian du cluster Proxmox (§ 15).

9. Filtrer ce qu’on reçoit et ce qu’on annonce

Les listes de préfixes (`prefix-list`)

ip prefix-list NOM seq N permit|deny RÉSEAU/LONGUEUR [ge MIN] [le MAX]

Écriture	Ce qui correspond
`10.0.0.0/8`	Exactement 10.0.0.0/8, rien d’autre
`10.0.0.0/8 le 24`	Tout préfixe contenu dans 10/8 de longueur 8 à 24
`10.0.0.0/8 ge 16 le 24`	Contenu dans 10/8, longueur 16 à 24
`0.0.0.0/0`	Seulement la route par défaut
`0.0.0.0/0 le 32`	Tout (= `permit any`)
`0.0.0.0/0 ge 25`	Tout préfixe plus petit qu’un /24 (trop précis pour Internet)

Une prefix-list se termine par un deny implicite (comme une ACL). Les numéros de séquence permettent d’insérer des lignes plus tard (5, 10, 15…).

Filtre d’entrée type face à un transitaire (bogons)

On refuse ce qui n’a rien à faire sur Internet (liste inspirée du cours de lidstah) :

! « ce réseau »
ip prefix-list DEPUIS-TRANSIT seq 5  deny 0.0.0.0/8 le 32
! RFC 1918
ip prefix-list DEPUIS-TRANSIT seq 10 deny 10.0.0.0/8 le 32
! CGNAT
ip prefix-list DEPUIS-TRANSIT seq 15 deny 100.64.0.0/10 le 32
! bouclage
ip prefix-list DEPUIS-TRANSIT seq 20 deny 127.0.0.0/8 le 32
! APIPA
ip prefix-list DEPUIS-TRANSIT seq 25 deny 169.254.0.0/16 le 32
! RFC 1918
ip prefix-list DEPUIS-TRANSIT seq 30 deny 172.16.0.0/12 le 32
! protocoles IETF
ip prefix-list DEPUIS-TRANSIT seq 35 deny 192.0.0.0/24 le 32
! documentation
ip prefix-list DEPUIS-TRANSIT seq 40 deny 192.0.2.0/24 le 32
! RFC 1918
ip prefix-list DEPUIS-TRANSIT seq 45 deny 192.168.0.0/16 le 32
! tests de performance
ip prefix-list DEPUIS-TRANSIT seq 50 deny 198.18.0.0/15 le 32
! documentation
ip prefix-list DEPUIS-TRANSIT seq 55 deny 198.51.100.0/24 le 32
! documentation
ip prefix-list DEPUIS-TRANSIT seq 60 deny 203.0.113.0/24 le 32
! multicast
ip prefix-list DEPUIS-TRANSIT seq 65 deny 224.0.0.0/4 le 32
! réservé
ip prefix-list DEPUIS-TRANSIT seq 70 deny 240.0.0.0/4 le 32
! plus précis qu'un /24
ip prefix-list DEPUIS-TRANSIT seq 75 deny 0.0.0.0/0 ge 25
! la route par défaut (si on prend la full view)
ip prefix-list DEPUIS-TRANSIT seq 80 deny 0.0.0.0/0
! tout le reste
ip prefix-list DEPUIS-TRANSIT seq 100 permit 0.0.0.0/0 le 24
router bgp 64500
 neighbor 10.0.11.1 prefix-list DEPUIS-TRANSIT in
 ! sécurité si le voisin envoie n'importe quoi
 neighbor 10.0.11.1 maximum-prefix 1100000 90 restart 30

Le labo utilise 203.0.113.0/24

C’est un bloc de documentation : sur le vrai Internet il serait filtré par la ligne 60. Dans ton labo, retire cette ligne.

Règle d’usage sur Internet : on n’accepte pas plus précis qu’un /24 en IPv4 ni qu’un /48 en IPv6.

`route-map` : filtrer et modifier

route-map NOM permit|deny SÉQUENCE
 ! condition (prefix-list, as-path, community)
 match ...
 ! action (local-preference, metric, as-path prepend, community)
 set ...

Une route qui ne correspond à aucune séquence est refusée (deny implicite).
Pour « modifier certaines routes et laisser passer les autres », terminer par une séquence permit vide.

Filtrer sur le chemin d’AS (`as-path access-list`, expressions régulières)

Expression	Signification
`^$`	AS_PATH vide : mes propres routes
`^64501$`	Routes nées chez mon voisin 64501 (pas plus loin)
`^64501_`	Routes apprises de 64501
`_64503_`	Routes qui passent par 64503
`_64503$`	Routes nées dans 64503
`.*`	Tout

(_ remplace un séparateur : espace, début ou fin.)

Appliquer un changement de filtre sans couper la session

! redemande les routes (ROUTE-REFRESH)
clear ip bgp 10.0.11.1 soft in
! renvoie nos annonces
clear ip bgp 10.0.11.1 soft out
! JAMAIS « clear ip bgp * » en production : coupe toutes les sessions

10. Agrégation et communautés

Agrégation (résumé de routes)

router bgp 64500
 network 203.0.113.0 mask 255.255.255.128
 network 203.0.113.128 mask 255.255.255.128
 ! n'annonce QUE le /24
 aggregate-address 203.0.113.0 255.255.255.0 summary-only

summary-only supprime les sous-réseaux (marqués s dans la table). Sans lui, on annonce le /24 et les deux /25.

Les communautés : des étiquettes sur les routes

Une communauté est un nombre ASN:valeur collé à une route. Les opérateurs publient la liste des communautés qu’ils comprennent (« si tu mets 174:3001, je n’annonce pas ta route en Europe »).

Communauté	Valeur	Effet
NO_EXPORT	65535:65281	Ne pas annoncer hors de l’AS qui la reçoit
NO_ADVERTISE	65535:65282	Ne l’annoncer à aucun voisin
BLACKHOLE	65535:666	Demander à l’opérateur de jeter le trafic vers ce préfixe (contre un DDoS : RTBH)
Large community	`64500:1:20`	Format à 3 nombres, pour les ASN 32 bits

! afficher sous forme ASN:valeur
ip bgp-community new-format
route-map MARQUER permit 10
 set community 64500:100
router bgp 64500
 ! les communautés ne sont PAS envoyées par défaut chez Cisco
 neighbor 2.2.2.2 send-community
 neighbor 2.2.2.2 route-map MARQUER out

11. Influencer le trafic (multihoming)

Configuration	Description
Single-homed	Un seul lien, un seul opérateur : une route statique suffit, pas besoin de BGP
Dual-homed	Deux liens vers le même opérateur
Multihomed	Liens vers plusieurs opérateurs : redondance + choix des chemins → BGP obligatoire

On contrôle facilement le trafic sortant (c’est nous qui choisissons), beaucoup moins le trafic entrant (ce sont les autres AS qui choisissent : on ne peut que les influencer).

But	Outil	Comment
Sortir de préférence par ISP1	LOCAL_PREF	Mettre 200 sur les routes reçues d’ISP1 (défaut 100)
Ce routeur seul préfère un voisin	WEIGHT	`neighbor X weight 100` (Cisco, local)
Faire entrer le trafic par ISP1	AS-path prepend	Rallonger artificiellement le chemin annoncé à ISP2
Entrée : choisir entre 2 liens vers le même opérateur	MED	MED bas sur le lien préféré
Entrée, méthode forte	Préfixes plus précis	Annoncer 2 × /25… impossible sur Internet (filtré) : annoncer le /24 partout + des /24 séparés si on a un /23
Entrée, finesse	Communautés de l’opérateur	Selon la documentation de l’opérateur

ISP1 = lien principal, ISP2 = secours

! Sortie : préférer ISP1 (sur R1, routes reçues d'ISP1 → local-pref 200, propagée à tout l'AS en iBGP)
route-map DEPUIS-ISP1 permit 10
 set local-preference 200
router bgp 64500
 neighbor 10.0.11.1 route-map DEPUIS-ISP1 in
 
! Entrée : décourager ISP2 (sur R2, notre bloc annoncé à ISP2 avec 3 fois notre ASN)
! (elle remplace VERS-OPERATEURS sur R2 : un voisin n'a qu'UNE route-map « out », donc on garde les mêmes « match »)
route-map VERS-ISP2 permit 10
 match ip address prefix-list MES-PREFIXES
 match as-path 1
 set as-path prepend 64500 64500 64500
router bgp 64500
 neighbor 10.0.22.1 route-map VERS-ISP2 out

Vu de l'extérieur après le prepend :
   via ISP1 : AS_PATH = 64501 64500                       (2 AS)
   via ISP2 : AS_PATH = 64502 64500 64500 64500 64500     (5 AS)
   → le reste d'Internet préfère passer par ISP1 ; ISP2 ne sert que si ISP1 tombe

12. iBGP à grande échelle (route reflectors)

Le full mesh devient ingérable : 50 routeurs = 1 225 sessions. Solution : le route reflector (RR), autorisé à réfléchir les routes iBGP vers ses clients.

flowchart TB
  RR1["Route reflector 1"] <--> RR2["Route reflector 2<br/>(redondance)"]
  RR1 --> C1["Client"] & C2["Client"] & C3["Client"]
  RR2 --> C1 & C2 & C3

! sur le route reflector uniquement
router bgp 64500
 neighbor 10.255.0.11 remote-as 64500
 neighbor 10.255.0.11 update-source Loopback0
 neighbor 10.255.0.11 route-reflector-client

Les clients n’ont qu’une session (deux pour la redondance) vers les RR. Les attributs ORIGINATOR_ID et CLUSTER_LIST empêchent les boucles entre réflecteurs. Autre solution, plus rare : les confédérations (découper l’AS en sous-AS privés).

13. BGP et IPv6 (MP-BGP)

BGP « multiprotocole » (RFC 4760) transporte d’autres familles d’adresses dans la même session : IPv6, VPN MPLS (VPNv4, voir P11 - Routage avancé (BGP, EIGRP, MPLS)), EVPN (datacenters).

! activer le routage IPv6 sur le routeur (désactivé par défaut)
ipv6 unicast-routing
router bgp 64500
 neighbor 2001:db8:11::1 remote-as 64501
 address-family ipv6 unicast
  ! obligatoire : une famille n'est active qu'à la demande
  neighbor 2001:db8:11::1 activate
  network 2001:db8:500::/48
 exit-address-family
! ancre, comme en IPv4
ipv6 route 2001:db8:500::/48 Null0
! vérifier (« do » permet une commande show depuis le mode configuration)
do show bgp ipv6 unicast summary
do show bgp ipv6 unicast

Préfixes à refuser en IPv6 (extrait) : ::/8, 2001:db8::/32 (documentation), fc00::/7 (adresses privées ULA), fe80::/10 (lien local), ff00::/8 (multicast), et tout ce qui est plus précis qu’un /48. Le cours de lidstah donne une liste complète prête à l’emploi : cours de lidstah.

14. Sécurité de BGP

BGP a été conçu en 1989 sur la confiance : par défaut, un routeur croit ce que ses voisins lui annoncent. D’où des incidents célèbres :

Date	Incident	Cause
Février 2008	YouTube inaccessible dans le monde pendant environ deux heures	Pakistan Telecom, chargé de bloquer YouTube dans le pays, annonce par erreur à l’extérieur un préfixe plus précis que celui de YouTube (détournement, hijack)
Avril 2018	Vol de cryptomonnaie (MyEtherWallet)	Détournement volontaire de préfixes d’Amazon Route 53 pour répondre de faux DNS
Juin 2019	Une partie d’Internet (Cloudflare, etc.) dégradée	Fuite de routes (route leak) : un petit AS réannonce les routes d’un fournisseur à un autre, sans filtre
Octobre 2021	Facebook, Instagram et WhatsApp hors ligne pendant environ six heures	Une erreur de configuration retire les annonces BGP vers leurs propres serveurs DNS

Type de problème	Description
Détournement (hijack)	Annoncer un préfixe qui ne nous appartient pas (souvent plus précis)
Fuite (route leak)	Réannoncer des routes à qui on ne devrait pas (devenir transitaire par erreur)
Usurpation de session	Injecter de faux messages dans une session TCP

Les protections

Protection	Rôle	Configuration
Filtrage par préfixes	N’accepter de ses clients que leurs préfixes, n’annoncer que les siens	`prefix-list` (§ 9)
maximum-prefix	Couper la session si le voisin envoie trop de routes	`neighbor X maximum-prefix N`
Mot de passe MD5	Signer les segments TCP de la session	`neighbor X password ...` (successeur moderne : TCP-AO)
GTSM (sécurité TTL)	N’accepter que des paquets ayant un TTL de 254 ou plus : un attaquant éloigné ne peut pas l’atteindre	`neighbor X ttl-security hops 1`
IRR	Bases publiques (RIPE DB, RADB) où chacun déclare quels préfixes son AS a le droit d’annoncer (objets `route`)	Les opérateurs génèrent leurs filtres avec `bgpq4`
RPKI / ROA	Certificats cryptographiques : le titulaire d’un bloc signe une ROA « ce préfixe peut être annoncé par tel AS, jusqu’à telle longueur »	Créée dans le portail du RIR (RIPE)
ROV (Route Origin Validation)	Chaque routeur vérifie l’AS d’origine contre les ROA : valid, invalid (rejetée), not-found	Un validateur (Routinator, rpki-client) + `rpki` sur le routeur
ASPA	Extension en cours de déploiement : vérifier aussi les relations client/fournisseur dans l’AS_PATH	Encore récent
MANRS	Engagement public des opérateurs à appliquer ces bonnes pratiques	-

flowchart LR
  T["Titulaire du bloc<br/>203.0.113.0/24"] -->|"signe une ROA :<br/>origine AS 64500, max /24"| RIPE["RIPE NCC<br/>(dépôt RPKI)"]
  RIPE --> V["Validateur RPKI<br/>(Routinator)"]
  V -->|"liste valide"| R["Routeur BGP"]
  A["Attaquant AS 666<br/>annonce 203.0.113.0/25"] -->|"UPDATE"| R
  R -->|"origine 666 ≠ 64500<br/>et /25 > max /24"| X["❌ INVALID, rejetée"]

15. BGP sous Linux avec FRRouting

FRRouting (FRR) est la suite de routage libre la plus utilisée (successeur de Quagga cité par lidstah). Sa console vtysh a une syntaxe très proche de Cisco. Elle fait tourner le réseau de Proxmox SDN (EVPN), de nombreux datacenters et de petits opérateurs. Autre logiciel courant : BIRD (route servers des IXP).

Labo : deux VM Debian, deux AS

   VM « as65001 »                          VM « as65002 »
   LAN fictif 10.1.0.0/24 (dummy0)         LAN fictif 10.2.0.0/24 (dummy0)
   ens19 : 172.31.12.1/30  ─────────────── ens19 : 172.31.12.2/30

Sur les deux VM :

sudo apt install frr
# activer le démon BGP
sudo sed -i 's/^bgpd=no/bgpd=yes/' /etc/frr/daemons
sudo systemctl restart frr
# activer le routage IP
echo "net.ipv4.ip_forward=1" | sudo tee /etc/sysctl.d/90-routage.conf && sudo sysctl --system
# un « LAN » fictif à annoncer (sur as65002 : 10.2.0.1/24)
sudo ip link add dummy0 type dummy && sudo ip addr add 10.1.0.1/24 dev dummy0 && sudo ip link set dummy0 up
sudo vtysh

Dans vtysh sur as65001 :

configure terminal
router bgp 65001
 bgp router-id 10.1.0.1
 neighbor 172.31.12.2 remote-as 65002
 address-family ipv4 unicast
  network 10.1.0.0/24
  neighbor 172.31.12.2 route-map TOUT in
  neighbor 172.31.12.2 route-map MES-RESEAUX out
 exit-address-family
exit
ip prefix-list MES-RESEAUX seq 5 permit 10.1.0.0/24
route-map MES-RESEAUX permit 10
 match ip address prefix-list MES-RESEAUX
exit
route-map TOUT permit 10
exit
end
write memory

(Sur as65002 : mêmes commandes avec 65002, 172.31.12.1 et 10.2.0.0/24.)

Le piège n°1 de FRR : la RFC 8212

Depuis FRR 7.x, une session eBGP sans route-map en entrée et en sortie n’échange aucune route (sécurité par défaut). La session est Established mais affiche (Policy) et 0 préfixe. Solution : des route-maps comme ci-dessus, ou en labo seulement no bgp ebgp-requires-policy.

Vérifier :

sudo vtysh -c "show bgp summary"
sudo vtysh -c "show bgp ipv4 unicast"
sudo vtysh -c "show ip route bgp"
ip route | grep bgp              # la route est installée dans le noyau Linux
ping -I 10.1.0.1 10.2.0.1        # de LAN à LAN

16. BGP ailleurs qu’entre opérateurs

Usage	Exemple
Datacenters	Chaque switch a son ASN privé, BGP remplace OSPF (BGP unnumbered, RFC 7938), EVPN-VXLAN pour étendre des réseaux de niveau 2
Proxmox SDN	Les zones EVPN utilisent FRR et BGP entre les nœuds du cluster (V06 - Proxmox VE)
Kubernetes	MetalLB (mode BGP) annonce les IP des services au routeur ; Calico et Cilium routent les pods en BGP (P19 - Kubernetes)
Anycast	La même IP annoncée depuis plusieurs lieux : le trafic va au plus proche (serveurs DNS racine, 1.1.1.1, 8.8.8.8)
VPN MPLS	MP-BGP transporte les routes des clients (VPNv4) chez les opérateurs (P11 - Routage avancé (BGP, EIGRP, MPLS))
SD-WAN	Beaucoup de solutions s’appuient sur BGP avec des ASN privés (P12 - SD-WAN (OpenZiti))
Anti-DDoS	RTBH (communauté BLACKHOLE) et FlowSpec (BGP diffuse des règles de filtrage)

17. Outils pour observer Internet

Outil	Ce qu’on y trouve
bgp.he.net (Hurricane Electric)	Fiche de chaque AS : préfixes, voisins, IXP
bgp.tools	Même chose, très à jour, graphes de voisinage
RIPEstat (stat.ripe.net)	Historique des annonces, visibilité, statut RPKI
PeeringDB	Où chaque réseau est présent (IXP, datacenters), politique de peering
Looking glass	Interfaces web pour lancer `show ip bgp` sur les routeurs d’un opérateur
isbgpsafeyet.com	Teste si ton FAI rejette les routes RPKI invalides
`whois`	Infos d’un AS ou d’un bloc

whois AS16276                        # OVH
whois -h whois.radb.net AS203432     # objets IRR de FAImaison
whois 51.38.0.0                      # à qui appartient ce bloc
curl -s 'https://stat.ripe.net/data/prefix-overview/data.json?resource=8.8.8.8' | python3 -m json.tool | head -30   # qui annonce cette IP

18. Aide-mémoire des commandes

Action	Cisco IOS	FRR (`vtysh`)
Démarrer BGP	`router bgp ASN`	`router bgp ASN`
Identifiant	`bgp router-id X.X.X.X`	idem
Déclarer un voisin	`neighbor IP remote-as ASN`	idem
Source loopback (iBGP)	`neighbor IP update-source Loopback0`	`neighbor IP update-source lo`
eBGP non direct	`neighbor IP ebgp-multihop 2`	idem
Next hop	`neighbor IP next-hop-self`	idem (dans l’address-family)
Annoncer	`network A.B.C.D mask M.M.M.M`	`network A.B.C.D/LL` (dans l’address-family)
Agréger	`aggregate-address A.B.C.D M.M.M.M summary-only`	`aggregate-address A.B.C.D/LL summary-only`
Filtrer	`neighbor IP prefix-list NOM in/out`	idem
Politique	`neighbor IP route-map NOM in/out`	idem
MD5	`neighbor IP password MDP`	idem
Limite	`neighbor IP maximum-prefix N`	idem
Couper un voisin	`neighbor IP shutdown`	idem
Résumé	`show ip bgp summary`	`show bgp summary`
Table BGP	`show ip bgp`	`show bgp ipv4 unicast`
Un préfixe en détail	`show ip bgp A.B.C.D`	`show bgp ipv4 unicast A.B.C.D`
Ce qu’on annonce	`show ip bgp neighbors IP advertised-routes`	`show bgp neighbors IP advertised-routes`
Ce qu’on reçoit (après filtre)	`show ip bgp neighbors IP routes`	`show bgp neighbors IP routes`
Routes installées	`show ip route bgp`	`show ip route bgp`
Recharger sans couper	`clear ip bgp IP soft in`	`clear bgp IP soft in`
Journaux	`debug ip bgp updates` (labo uniquement)	`debug bgp updates`

Exercices

1. Ton routeur reçoit 198.51.100.0/24 par deux voisins eBGP. Chemin A : AS_PATH 64501 64510, LOCAL_PREF 100. Chemin B : AS_PATH 64502 64520 64510, LOCAL_PREF 150. Lequel est choisi ?

2. Que correspond à ip prefix-list X permit 172.16.0.0/12 ge 20 le 24 ? Les préfixes 172.16.0.0/12, 172.20.8.0/22, 172.31.5.0/24 et 172.16.1.128/25 passent-ils ?

3. Ta session iBGP entre loopbacks reste en état Active alors que ping 2.2.2.2 fonctionne. Cause la plus probable ?

4. R2 reçoit en iBGP la route 8.8.1.1/32 avec le next hop 10.0.11.1, sans étoile * devant. Pourquoi, et comment corriger ?

5. Tu as deux opérateurs. Tu veux que le trafic entrant arrive par ISP1, et ISP2 seulement en secours. Quel outil, sur quel routeur, dans quel sens ?

6. Pourquoi un AS d’entreprise multihomé doit-il filtrer ses annonces en sortie, même s’il n’annonce « rien de spécial » ?

7. Quelle est la différence entre un détournement de préfixe et une fuite de routes ? Quel mécanisme protège contre le premier ?

8. Sous FRR, la session eBGP est Established, mais show bgp summary affiche (Policy) et 0 préfixe. Que se passe-t-il ?

Correction

1. Le chemin B : la LOCAL_PREF (critère 2) est comparée avant la longueur de l’AS_PATH (critère 4). 150 > 100, donc B gagne malgré un chemin plus long.

2. Les préfixes contenus dans 172.16.0.0/12 et de longueur 20 à 24.

172.16.0.0/12 → longueur 12 : ❌

172.20.8.0/22 → dans le /12, longueur 22 : ✅

172.31.5.0/24 → dans le /12 (172.16 à 172.31), longueur 24 : ✅

172.16.1.128/25 → longueur 25 : ❌

3. Il manque neighbor 2.2.2.2 update-source Loopback0 (d’un côté ou des deux) : la connexion TCP part avec l’IP de l’interface physique, que le voisin n’attend pas, donc il la refuse.

4. Le next hop 10.0.11.1 (l’IP de l’opérateur) n’est pas connu de R2 : la route est invalide. En iBGP le next hop n’est pas modifié. Corriger avec neighbor 2.2.2.2 next-hop-self sur R1, ou annoncer le réseau d’interconnexion dans l’IGP.

5. AS-path prepend sur R2 (le routeur relié à ISP2), dans une route-map appliquée en sortie (out) vers ISP2 : le chemin vers ton bloc paraît plus long par ISP2, donc Internet préfère ISP1.

6. Sans filtre, il réannoncerait à ISP1 les routes reçues d’ISP2 (et inversement) : son lien deviendrait un transit gratuit entre les deux opérateurs (fuite de routes), au risque de saturer son lien et de perturber Internet. On filtre avec as-path ^$ et une prefix-list de ses propres blocs.

7. Détournement : quelqu’un annonce comme origine un préfixe qui ne lui appartient pas. Fuite : un AS relaie des routes légitimes à des voisins à qui il ne devrait pas. Le RPKI (ROA + ROV) protège contre les détournements d’origine ; contre les fuites : filtres, communautés, et à terme ASPA.

8. C’est la RFC 8212 appliquée par FRR : sans route-map en entrée et en sortie, aucune route n’est acceptée ni envoyée en eBGP. Ajouter les route-maps (ou no bgp ebgp-requires-policy en labo).

Erreurs fréquentes / dépannage

flowchart TD
  A["show ip bgp summary"] --> B{"Session Established ?<br/>(un nombre dans State/PfxRcd)"}
  B -->|"Idle / Active / Connect"| C["Problème de session :<br/>ping de l'IP voisine, TCP 179,<br/>remote-as, update-source,<br/>ebgp-multihop, mot de passe"]
  B -->|"Oui, 0 préfixe reçu"| D["Le voisin n'annonce rien<br/>ou mon filtre « in » bloque :<br/>show ip bgp neighbors X routes"]
  B -->|"Oui, préfixes reçus"| E{"La route est-elle<br/>dans show ip bgp avec * > ?"}
  E -->|"pas de *"| F["Next hop injoignable :<br/>next-hop-self / IGP"]
  E -->|"r (RIB-failure)"| G["Une route statique ou OSPF<br/>plus fiable existe déjà"]
  E -->|"* > oui"| H["Vérifier show ip route,<br/>puis le chemin retour<br/>chez l'autre AS"]

Symptôme	Cause probable	Correction
Voisin en Idle	`neighbor shutdown`, pas de route vers le voisin, `maximum-prefix` dépassé	`show ip bgp neighbors IP`, lire « Last reset »
Voisin en Active en boucle	Mauvaise IP, TCP 179 filtré, `update-source` manquant, eBGP entre loopbacks sans `ebgp-multihop`	Corriger, puis `clear ip bgp IP`
Message « BGP notification: … bad AS »	`remote-as` faux d’un côté	Vérifier les ASN des deux côtés
« MD5 authentication failed » dans les logs	Mot de passe différent	Retaper le même des deux côtés
Mon réseau n’est pas annoncé	`network` avec un masque différent de la table de routage	Route `Null0` exacte, ou corriger le masque
Routes iBGP non propagées à un 3ᵉ routeur	Règle de split horizon iBGP	Full mesh ou route reflector
Route reçue mais pas installée	Next hop injoignable, ou RIB-failure	`next-hop-self`, vérifier les autres routes
Asymétrie : ça part mais ça ne revient pas	L’autre AS ne connaît pas ton préfixe (filtre chez lui, IRR/ROA absents)	`show ip bgp neighbors X advertised-routes`, looking glass
Changement de filtre sans effet	Filtre appliqué mais routes pas redemandées	`clear ip bgp IP soft in`
FRR : `(Policy)`	RFC 8212	Ajouter des route-maps in/out

Voir aussi

P11 - Routage avancé (BGP, EIGRP, MPLS) · P02 - Routage dynamique (RIP, OSPF) · P03 - ACL et NAT sur Cisco · P05 - IPv6 · R09 - Cisco IOS - aide-mémoire · R10 - Méthode de dépannage réseau
P12 - SD-WAN (OpenZiti) · P18 - Haute disponibilité (stockage, BDD, réseau) · P19 - Kubernetes · M07 - Graphes et plus court chemin
Cours complet : cours de lidstah · cours de lidstah · cours de lidstah · cours de lidstah · cours de lidstah
Retour : P00 - Programme pas encore vu

Documentation technique

Explorateur

P24 - BGP de A à Z

P24 - BGP de A à Z

Sommaire

1. BGP en une image

2. Le vocabulaire indispensable

Systèmes autonomes

Numéros d’AS réservés

Qui distribue les numéros ?

Transit, peering, IXP

3. Les principes de fonctionnement

Les deux règles anti-boucle

eBGP vs iBGP

4. La session BGP (états, messages, minuteries)

Les 6 états (machine à états finis)

Les messages

Minuteries

5. Les trois tables de BGP

Lire show ip bgp

6. Les attributs de chemin

7. Le choix du meilleur chemin

8. Labo Cisco complet pas à pas

Topologie

Étape 1 - IGP interne (OSPF) pour joindre les loopbacks

Étape 2 - eBGP vers les opérateurs

Étape 3 - Annoncer son bloc avec network

Étape 4 - iBGP entre loopbacks

Étape 5 - Ne pas devenir transitaire

Étape 6 - Vérifier

9. Filtrer ce qu’on reçoit et ce qu’on annonce

Les listes de préfixes (prefix-list)

Filtre d’entrée type face à un transitaire (bogons)

route-map : filtrer et modifier

Filtrer sur le chemin d’AS (as-path access-list, expressions régulières)

Appliquer un changement de filtre sans couper la session

10. Agrégation et communautés

Agrégation (résumé de routes)

Les communautés : des étiquettes sur les routes

11. Influencer le trafic (multihoming)

ISP1 = lien principal, ISP2 = secours

12. iBGP à grande échelle (route reflectors)

13. BGP et IPv6 (MP-BGP)

14. Sécurité de BGP

Les protections

15. BGP sous Linux avec FRRouting

Labo : deux VM Debian, deux AS

16. BGP ailleurs qu’entre opérateurs

17. Outils pour observer Internet

18. Aide-mémoire des commandes

Exercices

Erreurs fréquentes / dépannage

Voir aussi

Vue Graphique

Table des Matières

Liens retour

Lire `show ip bgp`

Étape 3 - Annoncer son bloc avec `network`

Les listes de préfixes (`prefix-list`)

`route-map` : filtrer et modifier

Filtrer sur le chemin d’AS (`as-path access-list`, expressions régulières)