Border Gateway Protocol (BGP) est l’épine dorsale des grands réseaux d’entreprise et des liaisons vers les providers. Dans cet article, je montre de manière pratique comment exploiter de façon stable BGP pour l’entreprise : depuis l’établissement de voisinages sécurisés jusqu’aux filtres de routes propres et aux politiques AS‑Path. L’objectif n’est pas seulement une configuration fonctionnelle, mais une exploitation reproductible avec chemins de vérification, diagnostic et stratégie de repli.
Fondamentaux BGP et prérequis nécessaires
BGP est un protocole de routage vectoriel de chemin. En bref : les routeurs échangent des routes sous forme de chemins, chaque chemin étant marqué par une AS‑Sequence (AS‑Path). Dans les entreprises, vous aurez souvent deux scénarios BGP : eBGP (peering externe avec d’autres Autonomous Systems, AS) et iBGP (peering interne au sein de votre AS). Avant de commencer, vérifiez :
- Numéros AS et plans d’adressage : disposez‑vous d’un numéro AS public ou utilisez‑vous un numéro AS privé (uniquement dans le cadre d’un MPLS/VPN) ?
- Plans IP/loopbacks pour le peering : utilisez‑vous des réseaux point‑à‑point en /31 ou /30, ou des loopbacks avec multihop pour l’iBGP ?
- Règles de pare‑feu et ACL : le port TCP 179 doit être autorisé entre les peers ; pour les pare‑feu stateful des exceptions sont nécessaires.
- Accès opérationnel : accès console/SSH, monitoring (SNMP/télémétrie) et journalisation doivent être prévus.
Sans ces prérequis, le dépannage et le rollback sont nettement plus difficiles.
BGP pour l’entreprise : établir des voisinages sécurisés
Le « voisinage » (Neighbor/Peer) désigne une session BGP entre deux instances de routeur. Aspects importants :
eBGP vs. iBGP : différences et règles pratiques
Les peers eBGP traversent les frontières d’AS ; le TTL pour eBGP est par défaut 1. Les peers iBGP sont au sein du même AS et obéissent à des règles spécifiques : iBGP n’annonce que les routes qu’il a apprises via eBGP ou qui lui ont été reflétées par un route‑reflector. Pratique typique :
- Utilisez eBGP pour le peering avec les providers et iBGP à l’intérieur de votre AS (déployer des route‑reflectors dans les déploiements de grande taille).
- Pour l’iBGP avec loopbacks, activez le multihop ou utilisez des liens directs sur un backbone L2.
Authentification, TTL‑Security et BFD
La sécurité et la stabilité sont essentielles. TCP‑MD5 ou TCP‑AUTH (sur les plateformes récentes) protège la session BGP contre le spoofing. La TTL‑Security (ebgp‑multihop ou ip ttl‑security) réduit le risque de spoofing IP entre équipements voisins, et BFD (Bidirectional Forwarding Detection) permet une détection rapide des pannes de lien.
Exemple : TCP‑MD5 sur Cisco IOS (selon la plateforme) :
router bgp 65000
neighbor 203.0.113.2 remote-as 65001
neighbor 203.0.113.2 password 0 geheimesPasswort
!Pourquoi cela fonctionne : le hash TCP‑MD5 lie la session à un secret partagé, de sorte que les paquets sans hash correct sont rejetés. Quand cela échoue : en cas de hashes différents, d’incohérences MTU ou si des pare‑feu intermédiaires altèrent les paquets TCP‑MD5.
Liste de contrôle pratique pour les nouveaux peers
- Ping vers l’IP du peer (ou vers le loopback en cas de multihop iBGP) : vérifier IPv4/IPv6.
- Vérifier la connectivité TCP : telnet peer 179 ou nc -vz peer 179.
- Synchroniser la configuration : numéro AS, remote‑as, password, update‑source (pour multihop loopback).
- Activer BFD si disponible, et tester le comportement de défaillance et de rétablissement.
- Configurer max‑prefix pour empêcher qu’une mauvaise configuration n’inonde le plan de contrôle.
Filtres de routes : protection contre les routes erronées ou indésirables
Les filtres de route déterminent quelles routes vous acceptez, transmettez ou modifiez. Principaux mécanismes : Prefix‑Lists/Route‑Filters (décrivent des préfixes), AS‑Path‑Access‑Lists (filtrent selon les séquences d’AS), Communities (métadonnées), et Route‑Maps/Policy‑Statements (combinent des opérations match et set).
Pourquoi les filtres sont importants
Le BGP non filtré peut provoquer des fuites de routage, par exemple la diffusion erronée de préfixes globaux sur Internet. Les filtres limitent les dégâts, protègent contre les Next‑Hops incorrects et empêchent que des routes externes dominent votre réseau interne.
Modèles de filtrage concrets
Structure recommandée pour le peering fournisseur :
- Inbound : n’accepter que vos préfixes (prefix‑list contenant vos IP) et des AS‑Path‑Filter qui acceptent les AS du fournisseur ou du client.
- Outbound : uniquement les préfixes que vous souhaitez réellement annoncer — pas d’agrégats sans accord.
- max‑prefix : protège contre l’annonce d’un trop grand nombre de routes ; en cas de dépassement : réduire la session ou la réinitialiser.
Exemple : Prefix‑List et Route‑Map au format Cisco :
ip prefix-list MY_PREFIXES seq 5 permit 198.51.100.0/24
ip prefix-list MY_PREFIXES seq 10 permit 203.0.113.0/24
!
route-map OUT-TO-ISP permit 10
match ip address prefix-list MY_PREFIXES
set community 65000:100 additive
!
router bgp 65000
neighbor 198.51.100.1 remote-as 65010
neighbor 198.51.100.1 route-map OUT-TO-ISP out
neighbor 198.51.100.1 maximum-prefix 50
!Explication : la Prefix‑List limite ce que vous annoncez. La Route‑Map définit des communautés que les fournisseurs peuvent utiliser pour leurs politiques de transit. max‑prefix protège contre une inondation accidentelle.
RPKI et ROA comme validation supplémentaire
Resource Public Key Infrastructure (RPKI) vérifie si une AS est autorisée à annoncer un préfixe. L’intégration de RPKI dans votre politique de routage réduit le risque de détournements (hijacks). Aspect opérationnel : maintenez vos ROA à jour, car un ROA mal configuré peut marquer des routes légitimes comme invalides et entraîner leur rejet.
Application pratique des AS‑Path‑Policies
Les AS‑Path‑Policies influencent la manière dont les routes sont sélectionnées ou redistribuées. Deux cas d’usage principaux : contrôle de préférence (p. ex. Prepend pour le Traffic Engineering) et protection (p. ex. AS‑Path‑Filter contre certaines séquences d’AS).
Filtres AS‑Path et Access‑Lists
Les filtres AS‑Path utilisent des expressions régulières sur la séquence d’AS. Exemple : rejeter les routes qui contiennent un AS particulier dans la séquence :
ip as-path access-list 10 deny _65530_
ip as-path access-list 10 permit .*
!
route-map IN-FILTER permit 10
match as-path 10
!Explication : _65530_ (les underscores servent de délimiteurs de mot) détecte l’AS 65530 dans la route. Cette technique empêche que des routes passent par des AS connus pour poser problème.
AS‑Prepending pour le Traffic Engineering
En insérant plusieurs fois votre propre AS dans le chemin AS (Prepend), vous rendez une route moins attractive pour les AS distants. Cela est utile si vous souhaitez imposer des préférences différentes pour le trafic sortant via plusieurs fournisseurs.
route-map PREPEND-TO-ISP permit 10
set as-path prepend 65000 65000 65000
!
neighbor 198.51.100.1 route-map PREPEND-TO-ISP out
Attention : un Prepend excessif peut générer des chemins inattendus et compliquer le dépannage. Testez par étapes et documentez les modifications.
Aspects pare‑feu et BGP : pratique, dépannage, bonnes pratiques
BGP est actif sur le plan de contrôle ; les pare‑feu opèrent toutefois souvent sur le plan de données. Assurez‑vous que les pare‑feu ne filtrent pas involontairement le BGP‑TCP (port 179) ni les paquets BFD. Sur les pare‑feu stateful, les connexions BGP entrantes doivent être reconnues comme ‚established‘. De plus : les limites d’état de Conntrack et les timeouts peuvent interrompre des sessions de manière inattendue.
Konkrete Firewall‑Regeln (nftables Beispiel)
Wenn Sie Linux‑Border‑Router mit nftables betreiben, hier ein Mindestsatz — inklusive Loopback‑Multihop‑Zulassung:
table inet filter {
chain input {
type filter hook input priority 0;
ct state established,related accept
# Erlaube BGP-Neuaufbau (Port 179)
tcp dport 179 ct state new accept
# Falls iBGP über Loopbacks multihop läuft: quell- und ziel-ip explizit erlauben
ip saddr 10.0.0.0/24 ip daddr 10.0.0.1 tcp dport 179 accept
# BFD (UDP 3784/3785) für schnelle Link-Detektion
udp dport {3784,3785} ct state new accept
icmp type echo-request accept
drop
}
}
Erklärung: Die Regel ct state established,related schützt gegen unnötige Blockierungen bestehender Verbindungen. Spezielle Regeln für Loopback‑IPs sind nötig, wenn Multihop genutzt wird — sonst werden neu aufgebaute Sessions geblockt.
Conntrack und Timeouts
Stateful Firewalls verwenden Conntrack‑Timeouts. BGP‑Keepalives sind selten sehr häufig, aber wenn ein Firewall‑Timeout kürzer ist als Ihr Keepalive/hold‑Timer, wird die Session unnötig abgebaut. Prüfen und setzen Sie Conntrack‑Timeouts passend:
# Conntrack-Timeouts prüfen (Linux)
cat /proc/sys/net/netfilter/nf_conntrack_tcp_timeout_established
Passen Sie ggf. an, oder erstellen Sie explizite stateless Regeln nur für BGP‑Peers, um Conntrack zu umgehen.
Prüf‑ und Troubleshooting‑Schritte
Ein strukturiertes Troubleshooting vermeidet kostspielige Fehler. Folgen Sie dieser erweiterten Prüfsequenz, die datengetriebene Diagnosen ermöglicht:
- Physische und L2‑Verbindung prüfen: Link‑Status, SFPs, Duplex/Mismatch, Fehlerzähler.
- IP‑Konnektivität: Ping und traceroute zu Peer‑IP und Loopbacks; prüfen Sie asymmetrische Pfade.
- TCP‑Handshakes: telnet/nc zu Port 179 prüfen und bei Bedarf tcpdump‑Capture zur Analyse anfertigen.
- Router‑Logs und BGP‑Show‑Befehle auswerten (BGP‑Summary, Neighbor‑Detail, RIB‑Status).
- ACLs/Firewalls prüfen: Logs auf verwehrte Verbindungen oder NAT/Rewrites durchsuchen.
- Wenn Session instabil: MD5/Passwort, MTU, BFD‑Timers, CPU‑Load, Interrupt‑Queues prüfen.
Packet‑Capture ist in vielen Fällen entscheidend. Beispiel für tcpdump auf einem Linux‑Bordergerät:
# BGP-Traffic aufzeichnen (inkl. Keepalives und Open-Pakete)
tcpdump -i eth0 -s 0 tcp port 179 -w /tmp/bgp-179.pcap
# Live-Ausgabe für schnelle Prüfung
tcpdump -i eth0 -n -vvv tcp port 179
Interpretation: In einem Capture sehen Sie Open‑/Keepalive‑/Update‑Pakete. Open‑Fehler deuten häufig auf Auth/Version/Capability‑Mismatch, Update‑Anomalien auf Filter‑Probleme.
Wichtige Router‑Befehle
# Cisco IOS
show ip bgp summary
show ip bgp neighbors 203.0.113.2
show ip bgp regexp _65530_
show logging | include BGP
# Junos
show bgp summary
show bgp neighbor 203.0.113.2 detail
show route protocol bgp
show log messages | match bgp
Diese Befehle geben State, empfangene/gesendete Prefix‑Counts, Timer und Fehlerursachen aus. Bei Flaps prüfen Sie Interface/CPU/MTU‑Fehler; bei fehlenden Routen prüfen Sie Filter, next‑hop Erreichbarkeit und RPKI‑Status.
Automatisierung, Backup und kontrollierte Änderungen
Les modifications de BGP doivent être reproductibles et réversibles. Versionnez les configurations, automatisez les sauvegardes et appliquez les modifications via orchestration. Exemple : extrait d’Ansible‑Playbook qui sauvegarde une running-config (exemple simplifié) :
- name: Backup Router Config
hosts: routers
gather_facts: no
tasks:
- name: Fetch running-config
ios_command:
commands: show running-config
register: running_cfg
- name: Save to file
copy:
content: "{{ running_cfg.stdout[0] }}"
dest: "/var/backups/router-{{ inventory_hostname }}-{{ ansible_date_time.date }}.cfg"
Pourquoi c’est utile : les sauvegardes versionnées accélèrent les rollbacks et les audits. Associées à des pipelines CI/CD, vous pouvez insérer des vérifications de configuration (linting) avant le déploiement.
Change‑Management, Canary‑Rollouts und Rückfallstrategien
Pour les changements à risque, utilisez des Canary‑rollouts : d’abord un seul peer ou un POP non critique, observez, puis étendez par paliers. Définissez des critères d’arrêt clairs (p. ex. augmentation du nombre de préfixes, flaps, latence). Exemple de script de rollback (bash) pour désactiver rapidement une route‑map :
#!/bin/bash
# rollback-bgp.sh - entfernt kürzlich angewendete route-map an einem Neighbor
ROUTER=198.51.100.1
SSH_USER=admin
ssh ${SSH_USER}@${ROUTER} /bin/bash <<'EOS'
configure terminal
router bgp 65000
no neighbor 198.51.100.1 route-map OUT-TO-ISP out
end
write memory
EOS
Remarque : testez les scripts dans un environnement de laboratoire avant de les déployer en production. Assurez-vous que l’accès en cas d’urgence est également possible via Out‑of‑Band.
Zusatztools und Monitoring‑Integration
Utilisez des outils d’observabilité BGP externes (p. ex. Looking Glass, RIB/Route‑Servers) et en interne des validateurs RPKI. Vérifications de monitoring utiles :
- État de la session BGP avec contexte (CPU, interface, dernière modification).
- Nombre de préfixes et écarts par rapport à la baseline.
- Alertes d’état de validation RPKI (invalid/unknown).
- Événements BFD‑Down avec mapping des liens.
Des logs structurés (JSON) facilitent l’analyse automatique dans des pipelines SRE et des systèmes SIEM.
Typische Stolperfallen und wie Sie sie vermeiden
- Indisponibilité du next‑hop : les routes iBGP ont souvent un next‑hop défini ; si celui‑ci n’est pas atteignable, la route n’est pas installée.
- Route‑maps imprudentes : des opérations de set comme set local‑preference ou set community peuvent rediriger le trafic de manière involontaire.
- Max‑prefix trop strict : une limite trop basse peut faire chuter des annonces légitimes lors d’un changement de fournisseur.
- Politique RPKI trop agressive : en strict mode, des annonces légitimes de fournisseurs peuvent être rejetées si les ROAs font défaut.
- Firewalls stateful sans règles explicites pour BGP : des sessions refusées sont une cause fréquente.
Rollback‑und Notfallstrategie
Avant chaque changement, créez un script de backout testé et communiquez la fenêtre de maintenance. Mesures concrètes :
- Sauvegardez la configuration actuelle du routeur (copy running-config / save to git/backup).
- Changement par étapes : test sur un peer/routeur de secours, période d’observation (p. ex. 30 minutes).
- Réinitialisation automatique : pour les changements critiques, paramétrez timers et max‑prefix de façon qu’une anomalie protège la session au lieu de mettre le réseau en danger.
- Préparez la commande de rollback, par ex. restaurer la route‑map standard ou effectuer un Neighbor‑Shutdown.
Exemple : désactivation rapide d’un peer (Cisco) :
configure terminal
router bgp 65000
no neighbor 198.51.100.1
end
write memory
Ou moins disruptif : neighbor shutdown :
configure terminal
router bgp 65000
neighbor 198.51.100.1 shutdown
end
Ces options peuvent être vérifiées dans des fenêtres de debug et déployées de manière contrôlée via l’automatisation (Ansible, GitOps).
Règles d’exploitation, monitoring et vérifications régulières
Une exploitation BGP stable nécessite une supervision, un système d’alerte et une documentation :
- Surveiller le nombre de routes par peer (les augmentations soudaines sont des signaux d’alerte).
- Détecter les flaps de session BGP et générer des alertes avec contexte (CPU, interface, changements d’ACL).
- Vérifier le statut ROA/RPKI et fournir des alertes en cas d’incohérences.
- Réunions de revue régulières avec les providers : documenter les filtres, les community policies, les modifications planifiées.
Conseil de logging : activez les selective BGP‑events (neighbor up/down, prefix changes) avec une sortie de log structurée pour les pipelines SRE et la corrélation SIEM.
Conclusion : planifier, vérifier, automatiser
BGP pour l’entreprise est maîtrisable si vous construisez les voisinages de façon méthodique, concevez des filtres de routes cohérents et appliquez les AS‑Path‑Policies avec discernement. Protégez le Control Plane avec des règles de pare‑feu et CoPP, utilisez RPKI pour la sécurisation, mais conservez des chemins de vérification et des scénarios de repli. L’automatisation et le monitoring rendent les changements prévisibles et maîtrisables — n’oubliez pas la base simple : plans d’adressage IP propres, politiques documentées et accords coordonnés avec les providers.
Utilisez les checklists de cet article comme point de départ et élaborez à partir de celles‑ci des runbooks concrets pour votre infrastructure : environnement de test, déploiement canari et un plan de backout documenté sont indispensables.
Le Bgp Peering et le filtrage de routes sont également importants dans ce contexte. Cet article replace ces aspects de façon claire et montre ce qui compte au quotidien.