AS-Path Prepend: Dos & Don’ts im echten Internet

AS-Path Prepending ist das bekannteste Werkzeug für Inbound-Traffic-Engineering bei Multi-Homing: Du machst einen Pfad „unattraktiver“, indem du dein eigenes AS mehrfach an den AS-PATH anhängst. Viele Netzbetreiber wählen bei ansonsten gleichen Bedingungen den kürzeren AS-PATH – aber genau hier liegen die Praxisfallen: Prepending ist ein grober Hebel, wirkt nicht deterministisch, kann durch Provider-Policies übersteuert werden und führt bei falschem Einsatz zu schlechterer Resilienz. Dieses Tutorial zeigt die Dos & Don’ts im echten Internet und gibt dir ein robustes Vorgehen für Cisco Routern.

Was Prepending wirklich macht (und was nicht)

Prepending beeinflusst primär die Inbound-Pfadwahl anderer ASes, weil der AS-PATH länger aussieht. Es ist kein „Routing-Garant“ und ersetzt keine Provider-Communities oder gutes Design.

• Wirkt: macht einen Pfad weniger attraktiv (AS-PATH länger)
• Wirkt nicht sicher: wenn LocalPref/Communities beim Provider dominieren
• Kein Ersatz: für Outbound-Steuerung (LocalPref) und Filter-Governance

Denkmodell

$\text{Mehr Prepend} \to \text{längerer AS-PATH} \to \text{geringere Wahrscheinlichkeit als Best Path}$

Dos: Wann Prepending in der Praxis gut funktioniert

Prepending funktioniert am besten als Backup-Mechanismus: Du willst, dass ISP B nur im Failover genutzt wird, während ISP A der Standard-Ingress bleibt. Das ist ein typisches Enterprise-Muster und relativ robust, solange beide Provider deine Prefixes global announcen und keine Sonderpolicies dagegen wirken.

• Active/Backup Multi-Homing (Backup-ISP soll selten ziehen)
• Feinsteuerung pro Prefix (kritische Prefixes weniger oder gar nicht prependen)
• Als Ergänzung zu Provider-Communities (wenn verfügbar)

Don’ts: Wann Prepending im Internet oft scheitert

Viele erwarten, dass Prepending „den Traffic umleitet“. In der Realität können Remote-ASes andere Kriterien höher gewichten: LocalPref, Peering-Policy, Hot-Potato, RPKI/Filters, oder einfach eigene Business-Regeln. Dann bleibt Traffic trotz Prepending „wie er will“.

• „Load Balancing“ über zwei Provider nur mit Prepending ist selten stabil
• Prepending zwischen zwei Links zum gleichen Provider ist oft schlechter als Communities/MED
• Zu aggressives Prepending kann Resilienz verschlechtern (Failover wird unattraktiv)

Provider-Realität: Warum Prepending nicht deterministisch ist

Prepending wirkt außerhalb deines Netzes. Damit gibst du Kontrolle ab. Viele Provider setzen Local Preference intern so, dass bestimmte Wege bevorzugt werden – unabhängig vom AS-PATH. Zusätzlich wird häufig Hot-Potato geroutet (so schnell wie möglich aus dem eigenen Netz raus), was Prepend-Effekte verändert.

• LocalPref beim Provider schlägt AS-PATH in vielen Policies
• Hot-Potato: Remote-AS wählt den nächstgelegenen Exit, nicht den „kürzesten“
• Peering-Politik: bestimmte Pfade werden aus Business-Gründen bevorzugt

Wie viel Prepending ist „genug“?

In der Praxis reichen meist 1–3 zusätzliche AS-Hops. Mehr ist selten besser: Ab einem Punkt gewinnst du kaum zusätzliche Wirkung, riskierst aber, dass dein Backup-Pfad in mehr Fällen komplett ignoriert wird (auch wenn du ihn brauchst).

• Start: 1× prepend (ein zusätzlicher Hop)
• Typisch: 2–3× prepend für Backup
• Vermeiden: 5+ ohne messbaren Nutzen

Heuristik

$\text{PrependCount}\in \{1,2,3\} \text{für die meisten Enterprise-Fälle}$

Prepending richtig bauen: pro Prefix, nicht „alles auf einmal“

Die beste Praxis ist, Prepending selektiv pro Prefix-Klasse zu steuern. Kritische Dienste (z. B. VPN-Gateways, Public APIs) willst du oft möglichst stabil und vorhersehbar halten. Bulk-Traffic kann eher über Backup laufen.

• Kritische Prefixes: kein oder wenig Prepending
• Standard Prefixes: moderates Prepending auf Backup
• Bulk Prefixes: stärkeres Prepending möglich

Prefix-Listen als Klassen

ip prefix-list PL_CRIT seq 10 permit 203.0.113.0/24
ip prefix-list PL_BULK seq 10 permit 198.51.100.0/24

Cisco Konfiguration: AS-Path Prepend per Route-Map

Prepending setzt du outbound auf dem Provider-Neighbor. Achte darauf, dass dein Outbound-Filter (Whitelist) weiterhin greift, damit du nicht aus Versehen fremde Prefixes beeinflusst oder leakst.

Prepend auf Backup-ISP (Beispiel)

route-map RM_OUT_ISP_B permit 10
 match ip address prefix-list PL_CRIT
 set as-path prepend 65000
route-map RM_OUT_ISP_B permit 20

match ip address prefix-list PL_BULK

set as-path prepend 65000 65000 65000

Outbound Whitelist + Anwendung

ip prefix-list PL_OWNED seq 10 permit 203.0.113.0/24
ip prefix-list PL_OWNED seq 20 permit 198.51.100.0/24
ip prefix-list PL_ANY seq 5 permit 0.0.0.0/0 le 32
route-map RM_OUT_ISP_B deny 5

match ip address prefix-list PL_ANY
route-map RM_OUT_ISP_B permit 10

match ip address prefix-list PL_OWNED

set as-path prepend 65000 65000 65000
router bgp 65000

neighbor 198.51.100.1 remote-as 64501

neighbor 198.51.100.1 route-map RM_OUT_ISP_B out

Dos: Prepending mit Communities kombinieren (wenn Provider es unterstützt)

Viele Provider bieten Communities an, um Prepending im Provider-Netz selbst auszulösen (z. B. „prepend 2x to all peers“). Das ist oft effektiver als reines Customer-Prepending, weil es an strategischen Punkten im Provider angewendet wird. Du kombinierst dann: interne Intent-Community → Provider-Prepend-Community.

• Provider-Prepend-Community kann konsistenter wirken als eigener AS-PATH-Trick
• Dokumentiere pro Provider die Community-Werte (unterschiedlich!)
• Immer: send-community setzen

send-community Beispiel

router bgp 65000
 neighbor 198.51.100.1 send-community

Don’ts: Prepending als Ersatz für LocalPref Governance

Prepending steuert Inbound. Wenn du Outbound-Probleme lösen willst (z. B. falscher ISP als Exit), ist LocalPref das richtige Werkzeug. Prepending als Workaround erzeugt nur schwer nachvollziehbare Effekte und verschiebt die Kontrolle nach außen.

Messung und Verifikation: Nur wer misst, gewinnt

Prepending ist ohne Messung reine Hoffnung. Du musst prüfen, ob du das Prepend wirklich advertisest und ob externe Sicht den gewünschten Ingress zeigt. Dafür brauchst du Router-Checks plus externe Messpunkte.

Auf dem Router prüfen

show ip bgp neighbors 198.51.100.1 advertised-routes
show ip bgp 203.0.113.0/24

Extern prüfen (Praxis)

• Looking Glass: AS-PATH und Ingress aus verschiedenen Regionen
• Traceroute von externen Standorten
• Traffic-Analyse: NetFlow/Provider-Port-Stats

Typische Pitfalls im echten Betrieb

Viele Prepending-Probleme sind Copy/Paste- oder Erwartungsfehler. Diese Punkte solltest du vor jedem Change aktiv gegenprüfen.

• Outbound Filter fehlt → Route Leak möglich
• Route-Map Reihenfolge falsch → Prepend greift nicht oder greift zu breit
• Prefix nicht advertised → Prepend ist irrelevant
• Zu starkes Prepend → Backup wird auch im Failover unattraktiv

Quick-Runbook: Prepending Change sicher ausrollen

Diese Sequenz reduziert Risiko: erst Sicht prüfen, dann Change, dann soft out, dann extern verifizieren.

! Pre
show ip bgp summary
show ip bgp neighbors 198.51.100.1 advertised-routes
show route-map RM_OUT_ISP_B
show ip prefix-list
! Change: Route-Map anpassen
! Apply ohne Reset

clear ip bgp 198.51.100.1 soft out
! Post

show ip bgp 203.0.113.0/24

show ip bgp neighbors 198.51.100.1 advertised-routes

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.