BGP konfigurieren: Einstieg in Enterprise-Routing mit Cisco

Wer Enterprise-Netzwerke betreibt, mehrere Standorte verbindet oder eine stabile Anbindung an Provider, Cloud und Partnernetze benötigt, stößt früher oder später auf BGP. Das Protokoll ist die Grundlage des Internet-Routings und hat sich auch in Unternehmen etabliert, weil es sehr flexibel ist, klare Policy-Steuerung erlaubt und sich für Multi-Homing, WAN-Designs und kontrollierte Routenverteilung eignet. Wenn Sie BGP konfigurieren, steigen Sie in eine Routing-Welt ein, die weniger auf „automatisches Best-Path-Finding“ wie bei OSPF setzt, sondern auf bewusstes Entscheiden: Welche Präfixe sollen beworben werden? Welche sollen angenommen werden? Welche Pfade sind bevorzugt, welche nur Backup? Genau darin liegt die Stärke – und auch die typische Fehlerquelle für Einsteiger. Ein BGP-Setup funktioniert oft schon mit wenigen Zeilen, aber produktiv wird es erst mit Best Practices wie Prefix-Listen, Route-Maps, sauberem Next-Hop-Handling, sinnvollen Timern und einer konsequenten Filterstrategie. Dieser Einstieg zeigt Ihnen Schritt für Schritt, wie BGP in Cisco IOS/IOS XE grundsätzlich aufgebaut ist, wie eBGP (zum Provider) und iBGP (im internen Enterprise) sich unterscheiden, wie Sie Nachbarschaften (Peers) stabil zum Laufen bringen und wie Sie die wichtigsten Policies setzen, ohne sich in Details zu verlieren. Ziel ist ein Setup, das verständlich bleibt, sicherer ist als eine „Alles rein, alles raus“-Konfiguration und sich später sauber erweitern lässt.

BGP kurz erklärt: Was ist anders als bei OSPF oder EIGRP?

BGP (Border Gateway Protocol) ist ein Path-Vector-Protokoll. Anders als Link-State-Protokolle, die eine Topologie berechnen, tauscht BGP Pfadinformationen (AS-Pfade) und Attribute aus und wählt daraus den besten Pfad anhand einer Best-Path-Logik. Der wichtigste Praxisunterschied: BGP ist policy-getrieben. Sie kontrollieren sehr fein, welche Routen Sie annehmen, verändern und weitergeben.

• eBGP: BGP zwischen unterschiedlichen Autonomous Systems (z. B. Unternehmen ↔ ISP).
• iBGP: BGP innerhalb eines Autonomous Systems (z. B. zwischen Core-Routern im Unternehmen).
• Skalierung: BGP kann sehr große Routingtabellen verarbeiten, wenn Hardware und Policies passen.
• Kontrolle: Attribute wie Local Preference, AS-Path, MED oder Communities steuern Pfadwahl und Verteilung.

Für eine technische Standardreferenz eignet sich der Anchor-Text RFC 4271 (BGP-4). Cisco-spezifische Konfiguration und Befehlsdetails finden Sie über den Anchor-Text Cisco BGP Support & Dokumentation.

Typische Enterprise-Szenarien: Wann BGP sinnvoll ist

In vielen Unternehmen ist BGP nicht „das erste Routingprotokoll“, sondern kommt gezielt dort zum Einsatz, wo externe Routingdomänen oder komplexe Policy-Anforderungen existieren.

• Internet-Anbindung mit einem oder mehreren Providern: Default Route oder Full Table, Multi-Homing, Failover.
• MPLS-/Carrier-WAN: Provider liefert BGP für Site-to-Site-Routing oder VRFs.
• Cloud-Konnektivität: Private Connectivity (z. B. über Partner/Direct Connect/ExpressRoute-Äquivalente) nutzt häufig BGP.
• Partnernetze: kontrollierte Routenfreigabe, klare Segmentierung und Policy.
• Große interne Netze: iBGP als Policy-Layer über IGP, z. B. für zentrale Services oder Segment-Routing-Ansätze.

Grundbegriffe, die Sie für den Einstieg wirklich brauchen

• ASN (Autonomous System Number): Identität einer Routingdomäne. Für eBGP brauchen Sie Ihr ASN und das ASN des Nachbarn.
• Neighbor/Peer: BGP-Gegenstelle (IP-Adresse), mit der eine Session aufgebaut wird.
• NLRI/Prefix: Das Netzwerk, das beworben wird (z. B. 203.0.113.0/24).
• Next Hop: Die nächste IP, zu der Pakete gesendet werden sollen; muss im Routing erreichbar sein.
• RIB: Routing-Information-Base; BGP hat eine eigene BGP-Tabelle und installiert ausgewählte Routen in die IP-Routingtabelle.
• Policy: Filter- und Manipulationsregeln (Prefix-Lists, Route-Maps, Communities).

Vorbereitung: Was muss vor dem ersten BGP-Befehl stimmen?

Ein BGP-Neighbor kommt nur hoch, wenn die Basis stimmt. Für Einsteiger ist das der wichtigste Zeitgewinn: Erst Konnektivität und Port-Freigaben prüfen, dann BGP konfigurieren.

• IP-Erreichbarkeit: Der Neighbor muss pingbar sein (oder zumindest TCP-Verbindung möglich).
• TCP Port 179: BGP nutzt TCP/179. ACLs/Firewalls müssen die Session erlauben.
• Routing zum Neighbor: Der Router muss den Pfad zur Neighbor-IP kennen (connected oder via IGP/static).
• Uhrzeit/Logging: NTP und sinnvolles Logging helfen bei Diagnose, sind aber nicht zwingend.

Nützliche Basisbefehle:

show ip interface brief
show ip route
ping <NEIGHBOR-IP>

Beispiel-Setup: eBGP zum Provider mit Default Route und eigenem Prefix

Ein sehr typischer Einstieg ist die eBGP-Session zu einem ISP. In vielen kleinen Enterprise-Setups erhalten Sie vom Provider eine Default Route und announcen nur Ihr eigenes öffentliches Präfix (oder auch gar nichts, wenn es nur „Outbound“ ist). Für die Beispiele nutzen wir Platzhalter-IPs aus Dokumentationsbereichen.

• Ihr ASN: 65001
• Provider ASN: 65010
• Linknetz: 198.51.100.0/30 (Sie: 198.51.100.2, Provider: 198.51.100.1)
• Ihr öffentliches Prefix: 203.0.113.0/24

Schritt: BGP-Prozess starten und Neighbor anlegen

enable
configure terminal
router bgp 65001
bgp log-neighbor-changes
neighbor 198.51.100.1 remote-as 65010
end

Schritt: Eigenes Prefix announcen

Das klassische Muster ist: Sie announcen nur, was Sie auch tatsächlich im Routing haben. Daher stellen Sie sicher, dass das Prefix als Route existiert (connected, static oder via IGP). Häufig wird dafür eine Nullroute gesetzt, um das Prefix stabil zu „halten“.

configure terminal
ip route 203.0.113.0 255.255.255.0 Null0
router bgp 65001
network 203.0.113.0 mask 255.255.255.0
end

Best Practice: Nutzen Sie niemals „wildes“ Redistribution nach BGP, ohne Filter. Starten Sie mit klaren network-Statements oder sehr streng gefilterten Route-Maps.

Schritt: Eingehende Routen vom Provider begrenzen

Einsteigerfehler ist, unkontrolliert alle Routen anzunehmen. In vielen Enterprise-Setups reicht eine Default Route. Das lässt sich mit Prefix-Listen sauber begrenzen.

configure terminal
ip prefix-list ISP-IN seq 5 permit 0.0.0.0/0
router bgp 65001
neighbor 198.51.100.1 prefix-list ISP-IN in
end

Schritt: Ausgehende Routen begrenzen

Genauso wichtig: Nur das eigene Präfix (oder die eigenen Präfixe) dürfen raus. Das verhindern Sie mit einer Outbound-Prefix-List.

configure terminal
ip prefix-list ISP-OUT seq 5 permit 203.0.113.0/24
router bgp 65001
neighbor 198.51.100.1 prefix-list ISP-OUT out
end

Diese beiden Filter (in/out) gehören zu den wichtigsten Sicherheits- und Stabilitätsmaßnahmen im BGP-Betrieb. Allgemeine Sicherheits- und Härtungsprinzipien finden Sie über den Anchor-Text CIS Controls.

Verifikation: So prüfen Sie, ob BGP wirklich läuft

Bei BGP müssen Sie zwei Dinge prüfen: erstens, ob die TCP-Session/Neighbor up ist; zweitens, ob Routen tatsächlich empfangen/gesendet und in die Routingtabelle installiert werden.

• show ip bgp summary (Neighbor-Status, Up/Down, Prefix-Zähler)
• show ip bgp (BGP-Tabelle, Best Path)
• show ip route (installierte Routen)
• show ip bgp neighbors 198.51.100.1 advertised-routes (was senden wir?)
• show ip bgp neighbors 198.51.100.1 received-routes (was kommt rein? je nach Policy/IOS)

In show ip bgp summary ist der wichtigste Indikator für Einsteiger: Die Neighbor-Session sollte in einem etablierten Zustand sein, und der Prefix-Zähler sollte plausibel sein (z. B. 1, wenn Sie nur Default akzeptieren). Wenn dort 0 steht, prüfen Sie zuerst Filter, dann Next Hop, dann TCP/179.

iBGP im Enterprise: Warum man ein IGP trotzdem braucht

Ein häufiges Missverständnis: BGP kann alles routen, also brauche ich kein OSPF/EIGRP mehr. In der Praxis nutzen viele Enterprise-Netze ein IGP (OSPF oder IS-IS, manchmal EIGRP) für interne Erreichbarkeit und Konvergenz im Underlay. iBGP wird dann als Policy-Layer genutzt, um bestimmte Routen zu verteilen oder externe Routen kontrolliert ins Netz zu bringen.

• IGP: sorgt dafür, dass alle Router ihre Loopbacks und Transitnetze zuverlässig kennen.
• iBGP: verteilt ausgewählte Präfixe, arbeitet policy-basiert, skaliert in großen Netzen über Route Reflectors.
• Next Hop Erreichbarkeit: iBGP setzt voraus, dass Next Hops intern geroutet sind (meist über IGP).

iBGP Basics: Session über Loopbacks und „update-source“

In Enterprise-Designs bauen Sie iBGP häufig über Loopback-Adressen auf, weil diese stabiler sind als physische Interfaces. Dafür muss der Router die Loopback des Nachbarn erreichen (IGP oder statische Routen). Außerdem braucht Cisco meist update-source, damit die Session von der Loopback-IP aus initiiert wird.

Beispiel: R1 Loopback 10.255.255.1/32, R2 Loopback 10.255.255.2/32, beide im ASN 65001 (iBGP).

configure terminal
interface loopback0
ip address 10.255.255.1 255.255.255.255
router bgp 65001
neighbor 10.255.255.2 remote-as 65001
neighbor 10.255.255.2 update-source loopback0
end

Auf R2 analog. Zusätzlich müssen Sie sicherstellen, dass die Loopbacks gegenseitig erreichbar sind (z. B. via OSPF). Für Einsteiger ist entscheidend: Wenn iBGP über Loopbacks nicht hochkommt, liegt es sehr oft an fehlender Erreichbarkeit oder fehlendem update-source.

Route Reflector: iBGP skalieren, ohne Full Mesh

iBGP hat eine wichtige Regel: Ohne zusätzliche Mechanismen wird ein Full Mesh benötigt, weil iBGP gelernte Routen nicht automatisch an andere iBGP-Nachbarn weitergibt. In kleinen Netzen ist Full Mesh ok. In größeren Netzen nutzen Unternehmen Route Reflectors (RR), damit nicht jeder mit jedem peeren muss.

• Route Reflector: zentraler iBGP-Router, der iBGP-Routen reflektiert.
• RR-Clients: Peers, die ihre iBGP-Routen über den RR austauschen.
• Best Practice: mindestens zwei RRs für Redundanz, klare Cluster- und Policy-Dokumentation.

Beispiel (RR auf R2, Client R1):

configure terminal
router bgp 65001
neighbor 10.255.255.1 remote-as 65001
neighbor 10.255.255.1 route-reflector-client
end

Wichtige BGP-Attribute im Enterprise-Alltag

Sie müssen nicht sofort alle Attribute beherrschen, aber drei Konzepte sind besonders nützlich, wenn Sie Enterprise-Routing steuern:

• Local Preference: bevorzugter Ausgangspfad innerhalb eines AS (höher ist besser). Typisch für Multi-Homing-Policies.
• AS-Path: Weg durch ASNs. Kürzer ist tendenziell besser; kann durch Prepending beeinflusst werden.
• MED: Hinweis an ein externes AS, welcher Einstieg bevorzugt ist (niedriger ist besser), wirkt nur in bestimmten Szenarien zuverlässig.

Beispiel: Local Preference setzen (Inbound Policy)

Angenommen, Sie haben zwei Provider und wollen Provider A intern bevorzugen. Dann setzen Sie beim Empfang von Provider A eine höhere Local Preference per Route-Map. (Local Preference wirkt intern, nicht gegenüber dem Provider.)

configure terminal
route-map ISP-A-IN permit 10
set local-preference 200
router bgp 65001
neighbor 198.51.100.1 route-map ISP-A-IN in
end

Best Practice: Route-Maps sollten immer mit klaren Match-Kriterien (Prefix-List) kombiniert werden, damit Sie nicht versehentlich alle Routen gleich behandeln.

Multi-Homing-Strategie für Einsteiger: Zwei Provider, klare Policies

Ein typischer Enterprise-Einstieg ist Multi-Homing: zwei Internet-Uplinks, einer bevorzugt, einer Backup, oder beides aktiv mit Lastverteilung. Für Einsteiger ist ein „Primary/Backup“-Ansatz oft der sicherste Start, weil er leicht zu verifizieren ist.

• Inbound: Nur Default Route von beiden Providern annehmen (oder Default + wenige notwendige Routen).
• Outbound: Das eigene Präfix an beide Provider announcen, aber Pfadwahl steuern.
• Preferenzen: Local Preference für den bevorzugten Provider höher setzen.
• Prepending: Optional das eigene ASN gegenüber dem weniger bevorzugten Provider mehrfach anhängen, um eingehenden Traffic eher über den anderen Link zu ziehen (wirkt nicht immer deterministisch).

Häufige Fehler beim BGP-Setup und schnelle Fixes

Viele BGP-Probleme folgen sehr klaren Mustern. Wenn Sie diese kennen, sparen Sie bei der Fehlersuche enorm Zeit.

Neighbor bleibt in Idle/Active

• IP zum Neighbor nicht erreichbar oder falsche Neighbor-IP
• TCP/179 durch ACL/Firewall blockiert
• Falsches remote-as (ASN passt nicht)

Prüfen:

ping <NEIGHBOR-IP>
show ip bgp summary
show ip route

Session ist up, aber es kommen keine Routen

• Inbound Prefix-List blockiert alles (zu restriktiv oder falsch)
• Provider sendet keine Routen (Policy auf Provider-Seite)
• Address-Family/AFI-SAFI nicht korrekt (bei Plattformen, die AF erfordern)

Routen werden gelernt, aber nicht installiert

• Next Hop nicht erreichbar (häufig bei iBGP ohne IGP-Unterlay)
• Eine andere Route ist besser (Administrative Distance, spezifischere Route, Policy)

Prüfen:

show ip bgp
show ip route <PREFIX>

Ungewollte Routen-Leaks

• Keine Outbound-Filter gesetzt
• Redistribution ohne Filter
• Prefix-Listen zu breit

Fix: Immer Inbound- und Outbound-Filter einsetzen (Prefix-Lists/Route-Maps) und nur explizit erlauben, was wirklich benötigt wird.

Best Practices für den Einstieg: Sicher, stabil, erweiterbar

• Immer filtern: Prefix-Lists in/out sind Mindeststandard.
• Nur benötigte Routen annehmen: Für viele Enterprise-Edges reicht Default Route statt Full Table.
• Nur eigene Präfixe announcen: Keine unbeabsichtigten Ankündigungen.
• Nullroute für eigene Prefixe: Damit network stabil funktioniert.
• Logging aktivieren: bgp log-neighbor-changes erleichtert Diagnose.
• iBGP über Loopbacks: Stabilität, klare Underlay-Abhängigkeit.
• Redundanz planen: Zwei Provider, zwei RRs, klare Failover-Tests.
• Dokumentation: ASN, Peers, Prefix-Listen, Route-Maps, Policies, Verantwortlichkeiten.

Verifikation und Betrieb: Was Sie regelmäßig prüfen sollten

BGP ist kein „Set and forget“-Protokoll. Im Enterprise-Betrieb sind regelmäßige Kontrollen sinnvoll, um Ausfälle, Policy-Fehler oder unerwartete Prefix-Änderungen früh zu erkennen.

• show ip bgp summary (Session-Status, Prefix-Zähler)
• show ip bgp (Best Path, Attribute)
• show ip route (installierte Routen, Default Route)
• show logging (Session-Flaps, Policy-Hinweise)

In produktiven Umgebungen sollten Monitoring-Systeme auf BGP-Session-Down, Prefix-Count-Abweichungen und Link-Fehler alarmieren.

Konfiguration speichern und Änderungen absichern

Nach erfolgreicher Einrichtung und Verifikation sollten Sie die Konfiguration speichern, damit Ihr BGP-Setup nach einem Neustart erhalten bleibt:

copy running-config startup-config

Für weiterführende Details zu BGP-Funktion, Timern, Attributen und Session-Logik ist der Anchor-Text RFC 4271 eine solide Grundlage. Für Cisco-spezifische Konfigurationsoptionen, Plattformunterschiede und Best Practices nutzen Sie den Anchor-Text Cisco BGP Support & Dokumentation.

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.