Cisco 300-410: BGP-Richtlinien, -Skalierbarkeit und -Pfadauswahl — Lernleitfaden

By Laurynas Brazys · 16 August 2026 · #cisco #300-410 #certification #exam-prep #study-guide

Teil des Cisco CCNP Enterprise 300-410 ENARSI — Lernleitfaden. Üben Sie mit verifizierten Antworten im Cisco-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Überblick

Das Border Gateway Protocol (BGP) steuert domänenübergreifende Routing-Richtlinien und die skalierbare Verteilung von Erreichbarkeitsinformationen. Das Design resilienter Sitzungen, das Verständnis des Next-Hop- und Update-Verhaltens und die Anwendung von Richtlinien unter voller Kenntnis des Best-Path-Algorithmus sind grundlegend. Im großen Maßstab stützt sich iBGP auf Route-Reflektoren oder Confederations, während fortgeschrittene Werkzeuge wie Conditional Advertisement, Default-Origination, Multipath und Dampening das Verhalten verfeinern. Dieser Abschnitt beschreibt die operative Mechanik, Design-Abwägungen und Ausfallszenarien, die Sie antizipieren müssen, und bietet einen systematischen Ansatz zur Fehlerbehebung sowohl für fehlende Präfixe als auch für unerwartete Pfadauswahl.

Sitzungsdesign und Neighbor-Aufbau

• eBGP- vs. iBGP-Adjazenz
  • eBGP-Peers befinden sich in unterschiedlichen ASNs und verwenden standardmäßig eine TTL von 1, was eine Single-Hop-Adjazenz erfordert, sofern nicht anders konfiguriert.
  • iBGP-Peers befinden sich im selben ASN und erfordern ein Full-Mesh oder eine Skalierungsalternative (Route-Reflektoren oder Confederations). iBGP verwendet eine TTL von 255, und Sitzungen nutzen häufig Loopback-Interfaces für mehr Stabilität.
• TCP-Erreichbarkeit und BGP FSM
  • BGP läuft über TCP-Port 179; der Sitzungsaufbau hängt von der allgemeinen IP/TCP-Erreichbarkeit und der BGP Finite State Machine (Idle → Connect/Active → OpenSent → OpenConfirm → Established) ab.
  • Häufige Blocker: ACLs/Firewalls auf TCP/179, Control-Plane Policing (CoPP), das BGP-Raten begrenzt, und asymmetrisches Routing, das TCP unterbricht.
  • Praktische Überprüfung:

undefined

; wenn die Sitzung instabil ist (flapping), überprüfen Sie

undefined

, um CoPP zu validieren. Setzen Sie während der Richtlinienvalidierung die Conform/Exceed-Aktionen auf „transmit“, um unbeabsichtigte Drops zu vermeiden.

• Authentifizierung und TTL-Härtung
  • MD5-Authentifizierung (

undefined

) schützt vor gefälschten Sitzungen; Nichtübereinstimmungen halten die Sitzung im Active-Zustand.

• GTSM/TTL-Security (

undefined

) mildert CPU-basierte Angriffe; kombinieren Sie dies nicht mit

undefined

für denselben Neighbor.

• Loopback-Peering, update-source und multihop

  • Loopback-zu-Loopback-Peering ist resilienter gegenüber Schnittstellenausfällen; es erfordert eine eindeutige Quelladressierung und eine TTL-Erweiterung:

undefined

-

undefined

• Stellen Sie die Unicast-Erreichbarkeit zu den Loopbacks über statische Routen oder ein IGP sicher. Eine fehlende Rekursion zum Loopback verhindert den Aufbau stillschweigend.
• Next-Hop-Verarbeitung und next-hop-self
  • eBGP setzt den Next-Hop standardmäßig auf den werbenden (advertising) Neighbor.

  • iBGP ändert den Next-Hop standardmäßig nicht; Edge-Router müssen bei iBGP next-hop-self setzen, um Third-Party-Next-Hop-Blackholes zu vermeiden.

undefined

undefined

Next-Hop-Verarbeitung und Best-Path-Auswahl

BGP-Best-Path-Auswahl auf Cisco-Plattformen (von hoher zu niedriger Signifikanz):

1. Weight (Cisco-spezifisch, lokal auf dem Router; höher ist besser). Standardwerte: 32768 für lokal injizierte Routen, ansonsten 0.
2. Local Preference (innerhalb des AS; höher ist besser). Standard 100; wird in iBGP propagiert.
3. Lokal erzeugte Routen (network/aggregate/redistribute) werden gegenüber gelernten Routen bevorzugt.
4. AS-Pfadlänge (kürzer ist besser). Prepending erhöht die wahrgenommene Entfernung.
5. Origin-Code (IGP < EGP < Incomplete).
6. MED (niedriger ist besser). Wird nur zwischen Pfaden aus demselben benachbarten AS verglichen, es sei denn,

undefined

ist aktiviert;

undefined

stellt einen konsistenten MED-Vergleich über Peers hinweg sicher. 7) eBGP wird gegenüber iBGP bevorzugt. 8) Niedrigste IGP-Metrik zum BGP-Next-Hop (Hot-Potato-Routing). 9) Älteste Route bevorzugen, um Churn zu reduzieren (falls aktiviert, abhängig von Dampening/Multipath). 10) Tie-Breaker: minimale Cluster-List-Länge, niedrigste Originator-ID, niedrigste BGP-Router-ID des Neighbors und schließlich niedrigste IP-Adresse des Neighbors.

Designhinweise und Fallstricke:

• Die Erreichbarkeit des Next-Hops ist fundamental. Ein Pfad kann in BGP gewinnen, aber dennoch bei der CEF-Rekursion fehlschlagen, wenn der Next-Hop nicht aufgelöst werden kann.
• Wenn Sie Routen, die von eBGP gelernt wurden, in iBGP weiterverteilen (advertisen), vergessen Sie nicht next-hop-self; andernfalls könnten iBGP-Router einen unerreichbaren eBGP-Next-Hop sehen und den Datenverkehr verwerfen.
• MED wird oft missverstanden; ohne

undefined

wird der MED-Wert nicht über verschiedene benachbarte ASes hinweg ausgewertet, was zu scheinbar „ignorierten“ Werten führt.

Richtlinien-Tools: Attribute, Communities und Filterung

• Local Preference, Weight, AS-path prepending, MED
  • Bevorzugen Sie einen ISP mit geringer Latenz, indem Sie die LOCAL_PREF für diese Routen erhöhen (z. B. set local-preference 200). Dies ändert die Auswahl des ausgehenden Datenverkehrs im gesamten AS, ohne die IP-Datenebene zu beeinflussen.
  • Weight ist nur lokal wirksam; verwenden Sie es für routerspezifische Präferenzen (neighbor 198.51.100.1 weight 50 oder über eine route-map mit set weight).
  • AS-path prepending (set as-path prepend 65000 65000 …) macht einen Pfad für eingehenden Verkehr zu Ihrem AS weniger attraktiv, indem die wahrgenommene Entfernung erhöht wird. Wenden Sie dies selektiv an; eine übermäßige Nutzung verringert die Erreichbarkeit.
  • MED (set metric) schlägt Ihrem Nachbarn einen Ausgangspunkt (Egress) in Ihr AS vor. Die Wirkung hängt von der Richtlinie des Nachbarn ab.
• Community-Richtlinien
  • Das Senden von Communities erfolgt nicht automatisch; aktivieren Sie es mit neighbor x send-community [both | extended].
  • Wohlbekannte (Well-known) Communities: no-export, no-advertise, internet, local-AS und no-export-subconfed (nützlich bei Konföderationen).
  • Standard-Communities sind 32-Bit-Werte (Format AA:NN mit ip bgp community new-format).
  • Erweiterte (Extended) Communities (64-Bit) tragen zusätzliche Semantik (z. B. route-targets in VPNv4).
  • Large Communities (96-Bit, A:B:C) bieten Skalierbarkeit und Klarheit bei 4-Byte-ASNs.
  • Beispiel: Community abgleichen und Attribute setzen
    • ip community-list standard PREFERED permit 65000:100
    • route-map INBOUND-POLICY permit 10 match community PREFERED set local-preference 200
• Präfix- und AS-Pfad-Filterung
  • ip prefix-list steuert die NLRI-Granularität; as-path access-list verwendet Regex, um AS-Pfade einzuschränken. Beide werden mit route-maps oder direkt mit neighbor … prefix-list/as-path access-group angehängt.
  • Eingehend vs. ausgehend:
    • Eingehende Filterung (Inbound) formt, was in Ihre BGP-Tabelle gelangt, und beeinflusst die Auswahl des besten Pfades.
    • Ausgehende Filterung (Outbound) steuert, was Sie ankündigen (advertisen); eine falsch angewendete ausgehende route-map kann unerwartet Attribute auf lokal erzeugten Routen ändern (z. B. führt das Voranstellen des lokalen AS bei allen Advertisements dazu, dass externe Nachbarn Ihr Präfix als zwei AS-Hops entfernt ansehen anstatt nur einem). Schränken Sie route-maps immer mit expliziten match-Anweisungen ein.
  • Minimale, zielgerichtete Richtlinien reduzieren Fluktuation (Churn) und vermeiden Blackholing. Fügen Sie in prefix-lists immer eine abschließende permit-Anweisung ein, um unbeabsichtigte Ablehnungen zu vermeiden.

Kurze, zielgerichtete Konfigurationsbeispiele:

• Erhöhen der Local Preference für Routen von ISP-A:
  • route-map SET-LP permit 10 set local-preference 200
  • neighbor 203.0.113.1 route-map SET-LP in
• AS-path prepend für ein spezifisches ausgehendes Advertisement:
  • ip prefix-list OUT-ONLY permit 192.0.2.0/24
  • route-map PREPEND permit 10 match ip address prefix-list OUT-ONLY set as-path prepend 65000 65000
  • neighbor 198.51.100.1 route-map PREPEND out

Skalierung von iBGP und erweiterte Verhaltensweisen

• Route Reflectors (RRs)
  • Ersetzen das iBGP-Full-Mesh durch die Benennung von RRs, die Routen zwischen Clients und Nicht-Clients reflektieren. Schleifen werden durch die Attribute Originator-ID und Cluster-List verhindert.
  • Die Cluster-ID ist standardmäßig die Router-ID des RR; wenn mehrere RRs existieren, verwenden Sie eindeutige Cluster-IDs, um persistente Schleifen zu verhindern und die Pfadvielfalt zu verbessern.
  • Nachteile: RRs können zu suboptimaler Pfadauswahl führen (Path Hiding). Dies kann durch die Platzierung von Clients, diverse Cluster, Add-Path und die Anpassung von Bestpath-Parametern gemindert werden.
• Confederations
  • Teilen ein großes AS in Sub-ASes auf, die intern eBGP sprechen, aber nach außen als ein einziges AS erscheinen.
  • Vorteile: reduziert das iBGP-Mesh und den „Blast-Radius“ von Richtlinien; Nachteile: betriebliche Komplexität und potenzielle Feinheiten bei MED/Next-Hop über Sub-AS-Grenzen hinweg.
• Bedingte Ankündigung und Standardrouten

  • Bedingte Ankündigung (Conditional Advertisement) ermöglicht es Ihnen, eine Route nur dann anzukündigen, wenn eine andere Route vorhanden/nicht vorhanden ist.

undefined

undefined

undefined

undefined

undefined

undefined

undefined

• Default-Origination:

undefined

kündigt 0.0.0.0/0 an, unabhängig davon, ob es in der RIB vorhanden ist (wobei RM die Bedingungen steuert). Alternativ erfordert

undefined

eine passende Route in der RIB.

• Multipath
  • Lastverteilung über mehrere BGP-Pfade mit gleichen Kosten mit

undefined

. Verwenden Sie

undefined

, um eBGP-Multipath über verschiedene AS-Pfade unter kontrollierten Bedingungen zu ermöglichen. In MPLS L3VPNs aktiviert

undefined

PE-zu-PE ECMP.

• Routenrekursion und RIB-Fehler
  • BGP installiert einen Pfad nur, wenn der Next-Hop zu einem gültigen Forwarding-Eintrag rekursiv aufgelöst werden kann und keine Route mit einer niedrigeren Administrative Distance (AD) das Präfix bereits beansprucht.
  • Häufige Ursachen für RIB-Fehler:
    • Es existiert eine Route mit besserer AD (connected/static/IGP).
    • Next-Hop nicht auflösbar (keine IGP/statische Route zum Next-Hop).
    • Eine längere, spezifischere Route ist vorhanden (der Verkehr passt zur spezifischeren Route).
  • Nützliche Überprüfungen:

undefined

,

undefined

,

undefined

und CEF-Lookups zur Validierung der Rekursion.

• Dampening

undefined

bestraft „flappende“ (instabile) Präfixe und unterdrückt sie, bis sie stabil sind. Parameter: half-life, reuse, suppress, max-suppress-time.

• Nachteile: kann legitime Wiederherstellungen verbergen und die Konvergenz verlangsamen. Nur gezielt auf instabile Edge-Bereiche anwenden und das Dampening der Core-Erreichbarkeit oder kundenkritischer Adressbereiche vermeiden.

Systematische Fehlerbehebung (fehlende Präfixe und falsche Pfade):

1. Zustand der BGP-Sitzung überprüfen:

undefined

; bei Instabilität (Flapping) CoPP und die Erreichbarkeit von TCP/179 prüfen. 2) Annahme durch Richtlinien bestätigen:

undefined

; bei Bedarf Soft-Reconfiguration oder Route-Refresh sicherstellen. 3) Next-Hop validieren:

undefined

und

undefined

; IGP/Rekursion korrigieren, bevor Attribute angepasst werden. 4) Filter prüfen: Prefix-Lists, AS-Path Access-Lists und Communities;

undefined

bestätigen. 5) Attribute prüfen: Weight/Local-Pref/AS-Path/Origin/MED; gegebenenfalls

undefined

aktivieren. 6) RIB-Fehler und Spezifität untersuchen: Eine Connected/Static/IGP-Route mit niedrigerer AD oder eine spezifischere Route hat Vorrang vor BGP. 7) Skalierungsmechanismen bestätigen: Bei RRs auf Path Hiding und Cluster-List-Schleifen achten; bei Confederations die Verwendung von

undefined

validieren.

Praktisches Problemszenario

Acme Manufacturing betreibt das AS 65010 mit zwei ISPs: ISP-A (niedrige Latenz) und ISP-B (Backup). Acme betreibt iBGP über drei Core-Router mit zwei Route Reflectors und kündigt 203.0.113.0/24 an. Nach dem Hinzufügen einer ausgehenden Route-Map am Edge zu ISP-B melden entfernte Standorte eine erhöhte Latenz, und einige Pfade bevorzugen unerwartet ISP-B.

Vorgehensweise:

1. Sitzungs- und Richtlinienzustand bestätigen

undefined

und

undefined

, um sicherzustellen, dass es keine BGP-Flaps aufgrund von CoPP gibt. Begründung: Eine instabile Control Plane erzeugt Fluktuation (Churn), die die Auswirkungen von Richtlinien verschleiert.

2. Erreichbarkeit des Next-Hop überprüfen

undefined

und

undefined

. Begründung: Die Next-Hop-Rekursion muss erfolgreich sein, bevor Attribute eine Rolle spielen.

3. Ausgehende Richtlinie bei ISP-B prüfen

undefined

;

undefined

überprüfen. Begründung: Weit gefasste Route-Maps können unbeabsichtigt alle angekündigten Präfixe ändern, einschließlich der lokal erzeugten.

4. AS-Path Prepending auf gezielte NLRI beschränken

undefined

undefined

undefined

undefined

undefined

undefined

Begründung: Spezifisches Matching beschränkt das Prepending auf das beabsichtigte Präfix und vermeidet die Änderung von Attributen anderer Ankündigungen. Das explizite

undefined

stellt sicher, dass nicht übereinstimmende Routen nicht verworfen werden.

5. ISP-A global für ausgehenden Verkehr bevorzugen

undefined

undefined

undefined

Begründung: LOCAL_PREF beeinflusst die Egress-Wahl im gesamten AS (höher ist besser) und ist der sauberste Hebel, um den ISP mit niedriger Latenz zu bevorzugen.

6. Sicherstellen, dass Communities das beabsichtigte Verhalten propagieren

undefined

undefined

undefined

undefined

undefined

Begründung: Tagging ermöglicht nachgelagerte Richtlinienentscheidungen (z. B. RR-basierte Präferenz) und erfordert

undefined

zur Weitergabe.

7. RR-Verhalten validieren und Path Hiding vermeiden
   • Auf beiden RRs eindeutige Cluster-IDs und Client-Zuweisungen bestätigen; wo unterstützt,

undefined

aktivieren. Begründung: In einer Umgebung mit mehreren Ausgängen (Multi-Exit) können RRs einen besseren Pfad verbergen. Additional-Paths oder eine sorgfältige Client-Topologie reduzieren die Suboptimalität.

8. Ergebnisse und Installationsstatus überprüfen

undefined

, um Weight/Local-Pref/AS-Path/MED zu bestätigen; die Auswahl von eBGP vor iBGP und die IGP-Metrik zum Next-Hop überprüfen.

undefined

, um sicherzustellen, dass der gewählte Pfad in der RIB installiert wird. Begründung: Bestätigt, dass sowohl die Control Plane als auch die Data Plane das beabsichtigte Design widerspiegeln.

Diese Abfolge korrigiert die unbeabsichtigten AS-Path-Änderungen (wodurch sichergestellt wird, dass externe ASes Acmes Präfix mit der gewünschten Distanz sehen), erzwingt die Präferenz für ISP-A über LOCAL_PREF, erhält die Sichtbarkeit der Richtlinien durch Communities und validiert den Next-Hop sowie die Installation, sodass das endgültige Forwarding dem Design entspricht.

← EIGRP-Design · Alle Domänen · Routenumverteilung und richtlinienbasiertes Routing →

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →