Local Preference Governance: Unternehmensweite Policy ohne Chaos

Local Preference (LocalPref) ist in Enterprise-BGP das zentrale Steuerinstrument für Outbound-Traffic: Der höchste LocalPref gewinnt und bestimmt, über welchen Exit dein AS das Internet oder ein WAN verlässt. Genau deshalb braucht LocalPref Governance. Ohne Standards entsteht „Policy-Chaos“: unterschiedliche Teams setzen Werte nach Bauchgefühl, Ausnahmen werden nie zurückgebaut, und ein harmloser Change kann global den Exit-Pfad umdrehen. Dieses Tutorial zeigt, wie du LocalPref als unternehmensweite Policy etablierst: mit klaren Wertbereichen, Community-basierter Steuerung, zentralen Policy-Punkten und verifizierbaren Betriebsprozessen.

Warum LocalPref Governance notwendig ist

LocalPref wirkt innerhalb deines AS. Ein einzelner falsch gesetzter Wert kann deshalb standortübergreifend Traffic verschieben. Im Alltag passiert das häufig durch „schnelle Fixes“ an einzelnen Edge-Routern oder durch inkonsistente Route-Maps.

• Globaler Impact: LocalPref verändert Exit-Entscheidungen im gesamten AS
• Unsichtbare Ausnahmen: alte Sonderregeln bleiben dauerhaft aktiv
• Troubleshooting-Hölle: „Warum geht Traffic über ISP B?“

LocalPref Basics: Die Regel, die wirklich zählt

LocalPref ist ein Best-Path-Kriterium, das vor vielen anderen Attributen greift. In der Praxis ist es der zuverlässigste Hebel für Outbound-Traffic Engineering.

Merker

$\text{Higher LocalPref} \to \text{bevorzugter Exit}$

• LocalPref wird nicht nach außen (eBGP) propagiert
• LocalPref muss konsistent im iBGP verteilt werden
• Fehlerquelle: unterschiedliche Defaults pro Router

Governance-Prinzip 1: Ein offizielles Wertschema (keine „freien Zahlen“)

Der wichtigste Schritt ist ein Wertschema mit reservierten Bereichen. Damit verhinderst du Wildwuchs und machst Policies lesbar. In Enterprise-Umgebungen ist ein dreistufiges Modell oft ausreichend: Primary, Secondary, Tertiary (Backup).

• 200: Primary Exit (Standard)
• 150: Secondary Exit (gleichwertig oder regional)
• 100: Backup Exit (nur Failover)
• 50: „Penalty“ (nur nutzen, wenn nichts anderes da ist)

Best Practice

• Wertbereiche dokumentieren (Wiki/Runbook)
• Keine ad-hoc Werte außerhalb der Bereiche
• Neue Ausnahmen nur über Change-Prozess

Governance-Prinzip 2: Communities als Steuer-Interface, LocalPref als Implementation

LocalPref direkt „hart“ in vielen Route-Maps zu setzen skaliert schlecht. Besser ist ein zweistufiges Modell: Teams taggen Routen mit internen Communities (Intent), und eine zentrale Policy setzt daraus LocalPref. So bleibt die Logik einheitlich.

• Teams setzen Communities: PRIMARY/SECONDARY/BACKUP
• Zentrale Policy mappt Community → LocalPref
• Vorteil: weniger Copy/Paste, mehr Auditierbarkeit

Interne Communities definieren

ip community-list standard CL_EXIT_PRIMARY   permit 65000:100
ip community-list standard CL_EXIT_SECONDARY permit 65000:150
ip community-list standard CL_EXIT_BACKUP    permit 65000:200

Zentrale Route-Map: Community → LocalPref

route-map RM_LP_GOVERN permit 10
 match community CL_EXIT_PRIMARY
 set local-preference 200
route-map RM_LP_GOVERN permit 20

match community CL_EXIT_SECONDARY

set local-preference 150
route-map RM_LP_GOVERN permit 30

match community CL_EXIT_BACKUP

set local-preference 100
route-map RM_LP_GOVERN permit 100

set local-preference 150

Governance-Prinzip 3: Ein zentraler Policy-Punkt pro Domäne

LocalPref sollte nicht an „irgendwelchen“ Stellen gesetzt werden. Lege fest, wo die Wahrheit entsteht: typischerweise an den Internet-Edges beim Inbound von eBGP, oder zentral an Route Reflectors (wenn bewusst als Policy-RR designt). Wichtig ist: nur ein Modell, nicht beides parallel.

• Pattern A (häufig): LocalPref inbound an eBGP Edges setzen
• Pattern B (seltener): Policy-RR setzt LocalPref zentral
• Anti-Pattern: Edges + RRs setzen beide LocalPref → Chaos

Empfehlung

• Edges setzen LocalPref inbound (klarer Ownership)
• RRs bleiben „transparent“ (nur reflektieren)

Baseline: Default LocalPref pro Provider und pro Standort

Eine Governance braucht Defaults, sonst entstehen Ausnahmen. Definiere daher pro Provider (und ggf. pro Region) Standardwerte. Ausnahmen werden über Communities gesteuert und dokumentiert.

Inbound Provider-Policy (Beispiel)

route-map RM_IN_ISP_A permit 10
 set local-preference 200
route-map RM_IN_ISP_B permit 10

set local-preference 150

Optional: Ausnahme über Community-Tagging

route-map RM_IN_ISP_A permit 5
 match community CL_EXIT_BACKUP
 set local-preference 100
route-map RM_IN_ISP_A permit 10

set local-preference 200

Ausnahmen ohne Chaos: Zeitliche Begrenzung und Owner

Die meisten LocalPref-Ausnahmen sind temporär (Provider-Probleme, Wartung, Incident). Governance heißt: Jede Ausnahme hat Owner, Grund und Ablaufdatum. Sonst wird aus „Fix“ dauerhaft Tech Debt.

• Jede Ausnahme im Ticket/Change dokumentieren
• Owner + Expiry Date (Reminder) festlegen
• Nach Ende: Rückbau verpflichtend

Failover und Tracking: LocalPref mit Realität koppeln

LocalPref allein erkennt keine Link-Degradation. Du kombinierst Governance mit Failover-Mechanismen: BFD, IP SLA Tracking oder Provider-State-Checks, damit der Primary Exit nicht „bevorzugt“ bleibt, wenn er kaputt ist.

• Hard Down: BFD/Interface/Session down → BGP withdraws
• Soft Failure: IP SLA Tracking kann Default/Policy beeinflussen
• Wichtig: nicht zu aggressiv, sonst Flapping

Verifikation: LocalPref Governance beweisen

Governance ist nur glaubwürdig, wenn du schnell nachweisen kannst, warum ein Prefix welchen Exit nimmt. Dafür brauchst du standardisierte Show-Checks und idealerweise zentrale Telemetrie (NetFlow/Streaming Telemetry).

Prefix prüfen

show ip bgp <prefix>
show ip bgp <prefix> | include localpref|best

Exit-Pfade prüfen

show ip bgp summary
show ip route <next-hop>
show ip cef <next-hop> detail

Policy-Audit

show route-map
show ip community-list

Typische Pitfalls (und wie Governance sie verhindert)

Die häufigsten Fehler sind konsistente Muster: doppelte Policy-Punkte, nicht dokumentierte Ausnahmen und inkonsistente Community-Interpretation. Governance setzt genau hier an.

• LocalPref wird an mehreren Stellen gesetzt → unvorhersehbare Pfade
• Teams nutzen eigene Werte → keine Vergleichbarkeit
• Communities werden nicht überall gesendet/weitergegeben → Policy greift nicht
• Legacy Route-Maps bleiben aktiv → „Shadow Policies“

Quick-Template: Unternehmensweite LocalPref Governance (Minimal)

Dieses Template ist ein Startpunkt: klare Default-Werte, Communities als Intent, zentraler Mapping-Block. Passe ASNs und Werte an dein Schema an.

ip community-list standard CL_EXIT_PRIMARY    permit 65000:100
ip community-list standard CL_EXIT_SECONDARY  permit 65000:150
ip community-list standard CL_EXIT_BACKUP     permit 65000:200
route-map RM_LP_GOVERN permit 10

match community CL_EXIT_PRIMARY

set local-preference 200

route-map RM_LP_GOVERN permit 20

match community CL_EXIT_SECONDARY

set local-preference 150

route-map RM_LP_GOVERN permit 30

match community CL_EXIT_BACKUP

set local-preference 100

route-map RM_LP_GOVERN permit 100

set local-preference 150
router bgp 65000

neighbor 203.0.113.1 remote-as 64500

neighbor 203.0.113.1 route-map RM_LP_GOVERN in

Konfiguration speichern

Router# copy running-config startup-config

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab (CCNA)

Hallo! Ich bin ein CCNA-Network Engineer und unterstütze Sie bei Cisco Router- und Switch-Konfigurationen – inklusive eines vollständigen Cisco Packet-Tracer-Labs (.pkt). Ideal für Lern-/Übungsszenarien, Validierung oder eine saubere Demo-Topologie.

Was ich (je nach Paket) umsetze

• Switching: VLANs, Trunking (802.1Q), Port-Zuweisung, STP-Basics (PortFast/BPDU Guard wo sinnvoll)

• Routing: Default/Static Routing oder OSPF, Inter-VLAN Routing (Router-on-a-Stick)

• Services: DHCP (Pools/Scopes), NAT/PAT für Internet-Simulation

• Optional Security: Basic ACLs und SSH-Hardening

• Test & Verifikation: Ping/Traceroute + wichtige Show-Commands (mit erwarteten Ergebnissen)

Sie erhalten

• ✅ Packet Tracer .pkt Datei

• ✅ Saubere Konfigurations-Notizen pro Gerät

• ✅ Verifikations-Checkliste + erwartete Outputs

• ✅ Kurze Dokumentation (wie die Topologie funktioniert)

Bitte schreiben Sie mir vor der Bestellung, damit wir Scope, Packet-Tracer-Version, Geräteanzahl und Deadline klären.

Konfiguriere Cisco Router & Switches | Cisco Packet-Tracer-Labs. Finden Sie mich auf Fiverr.