BGP Inbound Traffic Engineering gehört zu den anspruchsvollsten Themen im Enterprise- und Service-Provider-Umfeld. Während Outbound Traffic vollständig kontrolliert werden kann, ist die Steuerung von eingehendem Traffic stark von externen Faktoren abhängig, wie dem Routing-Verhalten der Upstream-ISPs, Präferenzregeln in deren BGP-Policies und den globalen Internetpfaden. Dieser Leitfaden zeigt, welche Steuerungsmöglichkeiten realistisch sind und welche Erwartungen man nicht überschreiten sollte.
Grundlagen des Inbound Traffic Engineering
Im Gegensatz zu Outbound Traffic, bei dem man eigene Entscheidungen trifft, bestimmt beim Inbound Traffic der Remote-Peer, welchen Pfad die Pakete nutzen. Enterprise-Router können nur indirekt Einfluss nehmen. Die wichtigsten Mechanismen sind:
- AS-Path Prepending
- Community-Basing Policy bei Partnern
- MED (Multi-Exit Discriminator) Ankündigungen
Diese Techniken wirken sich auf die Präferenzen des Nachbarn aus, beeinflussen aber nicht garantiert den eingehenden Pfad.
Realistische Steuerungsmöglichkeiten
AS-Path Prepending
Durch Hinzufügen eigener AS-Nummern in der Route kann man die Attraktivität eines Pfads verringern:
- Längere AS-Pfade werden in der Regel von den meisten BGP-Implementierungen als weniger attraktiv gewertet
- Nur wirksam, wenn der Nachbar das AS-Path Attribut in seiner Path-Selection berücksichtigt
- Keine absolute Garantie, da globale Policies andere Präferenzen setzen können
route-map INBOUND_PREPEND permit 10
set as-path prepend 65000 65000
MED (Multi-Exit Discriminator)
MED wird eingesetzt, um unterschiedliche Exit-Punkte zu priorisieren:
- Wirkt nur, wenn der Nachbar die MED-Werte beachtet und mehrere Verbindungen zum selben AS existieren
- Kein Einfluss auf Routen durch andere Upstreams
route-map SET_MED permit 10
set metric 50
Communities für Partner
Viele ISPs erlauben über Communities gezielte Präferenzen für Inbound Traffic:
- Setzt voraus, dass man die Community-Richtlinien des Providers kennt
- Kann z.B. bevorzugte POPs für Traffic steuern
- Nur in Absprache mit dem Provider effektiv
route-map INBOUND_COMM permit 10
set community 65001:100
Begrenzungen und Risiken
Enterprise-Administratoren sollten verstehen, dass:
- Absolute Kontrolle über Inbound Traffic unmöglich ist
- Globale BGP-Entscheidungen anderer ASes Pfade über eigene Änderungen priorisieren können
- Übermäßiges Prepending oder komplexe MED-Policies zu unvorhersehbaren Pfadänderungen führen können
Dies kann zu asymmetrischem Routing oder unerwartetem Failover führen.
Strategien für robustes Inbound Engineering
Redundante Peering-Punkte
Mehrere Upstream-Provider oder POPs erhöhen die Flexibilität:
- AS-Path Prepending für einzelne Provider gezielt einsetzen
- MED-Variationen für lokale Präferenzen an verschiedenen Standorten
- Backup-Peers für Failover vorbereiten
Monitoring und KPI-Messung
Um die Effektivität der Maßnahmen zu beurteilen, ist Observability entscheidend:
- Traffic-Volumen pro Link überwachen
- Path-Changes via BGP Monitoring beobachten
- Alerting bei unerwartetem Pfadwechsel oder Paketverlust
show ip bgp neighbors
show bgp ipv4 unicast summary
show ip route
Koordination mit Upstream-Provider
Der effektivste Hebel für Inbound Traffic ist die Abstimmung mit dem Provider:
- Abstimmung von Community-Attributen
- Verständnis der lokalen Routing-Policies des Providers
- Definierte SLAs für Traffic-Engineering-Abstimmungen
Operational Best Practices
- Änderungen inkrementell testen und beobachten
- Dokumentation aller Prepend- und Community-Policies
- Fallback-Mechanismen definieren, falls unerwartetes Routing auftritt
- Langfristig auf Redundanz und mehrere Peering-Punkte setzen
Fazit
BGP Inbound Traffic Engineering ist ein Balanceakt zwischen realistischen Steuerungsmöglichkeiten und den Erwartungen an die Kontrolle. AS-Path Prepending, MED und Community-Attribute bieten wirksame Hebel, garantieren aber keinen festen Pfad. Durch strategische Peering-Auswahl, kontinuierliches Monitoring und enge Abstimmung mit Upstream-Providern lassen sich jedoch die gewünschten Traffic-Flows mit hoher Wahrscheinlichkeit erreichen, ohne die Stabilität des Netzes zu gefährden.
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.