MED richtig nutzen: Grenzen, Fallstricke und Provider-Realität

MED (Multi-Exit Discriminator) ist eines der am meisten missverstandenen BGP-Attribute. In der Theorie ist MED ein eleganter Hinweis an den Nachbar-AS: „Wenn du mehrere Übergänge zu mir hast, nimm bitte diesen hier bevorzugt.“ In der Praxis scheitert MED oft an drei Realitäten: Es wirkt nur in sehr bestimmten Topologien (meist gleicher Nachbar-AS), es kann durch Provider-Policy ignoriert oder überschrieben werden, und es erzeugt schnell unerwartete Pfade, wenn du es als „Inbound-Traffic-Steuerung für das ganze Internet“ missbrauchst. Dieses Tutorial zeigt, wann MED wirklich hilft, welche Grenzen du akzeptieren musst und wie du typische Fallstricke auf Cisco vermeidest.

Was MED ist (und was nicht)

MED ist ein „Hint“ an den Nachbarn, welchen Eingang er wählen soll, wenn er mehrere Möglichkeiten hat, dein AS zu erreichen. MED ist nicht dein primärer Hebel für globales Inbound-Traffic-Engineering. Dafür sind Provider-Communities und AS-Path Prepending meist relevanter.

• MED steuert primär: Inbound-Pfadwahl beim Nachbarn bei mehreren Links
• MED ist: ein Hinweis, keine Garantie
• MED ist nicht: globales Inbound-TE für das gesamte Internet

Merker

$\text{Low MED} \to \text{bevorzugter Eingang} \text{(beim Nachbarn)}$

Die wichtigste Grenze: MED wird meist nur innerhalb eines Nachbar-AS verglichen

Viele Router (und viele Provider-Policies) vergleichen MED standardmäßig nur zwischen Routen, die aus demselben Nachbar-AS gelernt wurden. Das bedeutet: MED ist typischerweise nur dann sinnvoll, wenn du mehrere Links zum gleichen Provider-AS hast (z. B. zwei Übergänge zum ISP A).

• Sinnvoll: 2× eBGP zum selben Provider-AS
• Meist sinnlos: MED zwischen zwei unterschiedlichen Providern (AS A vs. AS B)
• Konsequenz: Multi-Provider Inbound-TE → eher Communities/Prepending

Provider-Realität: Warum dein MED oft ignoriert wird

Provider nutzen MED häufig nur in bestimmten Produkten (z. B. Dual-Homing im selben AS) oder überschreiben es durch interne Policies (LocalPref, Traffic Engineering, Hot-Potato). Selbst wenn MED akzeptiert wird, kann er durch weitere Kriterien im Best-Path-Prozess „überstimmt“ werden.

• Provider setzt LocalPref nach eigenen Regeln → MED kommt später
• Provider überschreibt/normalisiert MED (z. B. fixed MED pro PoP)
• Hot-Potato Routing: Provider wählt den „nächsten“ Exit zu dir

Wann MED in Enterprise-Edges wirklich sinnvoll ist

MED lohnt sich, wenn du mit einem Provider zwei Übergänge hast und du den Inbound-Pfad innerhalb dieses Providers steuern willst – z. B. damit Traffic aus Norddeutschland in Hamburg reinkommt und nicht in München, oder um Last zwischen zwei PoPs zu verteilen.

• Dual-Homing zu einem ISP (gleiches ASN), zwei PoPs
• Lastverteilung zwischen zwei Übergängen (pro Prefix steuerbar)
• Geografische Optimierung (wenn Provider MED respektiert)

MED-Design: Wertebereiche und ein klares „Intent“-Modell

Wie bei LocalPref gilt: ohne Governance wird MED Chaos. Definiere daher einen kleinen Wertebereich und eine klare Bedeutung. MED ist „low wins“, also ist eine kleine Skala oft ausreichend.

• 0–50: sehr bevorzugt
• 100: neutral/Standard
• 200–500: weniger bevorzugt
• Best Practice: nicht „wild“ in tausender Schritten

MED setzen auf Cisco: Route-Map am Outbound

MED wird typischerweise outbound gesetzt, weil du dem Nachbarn damit einen Hinweis gibst. Du setzt MED per Route-Map auf die Prefixes, die du über diesen Link announcen möchtest.

Prefix-List + MED per Route-Map

ip prefix-list PL_APP_CRIT seq 10 permit 203.0.113.0/24
ip prefix-list PL_APP_BULK seq 10 permit 198.51.100.0/24
route-map RM_OUT_ISP_A permit 10

match ip address prefix-list PL_APP_CRIT

set metric 50
route-map RM_OUT_ISP_A permit 20

match ip address prefix-list PL_APP_BULK

set metric 200

Am Neighbor anwenden

router bgp 65000
 neighbor 192.0.2.1 remote-as 64500
 neighbor 192.0.2.1 route-map RM_OUT_ISP_A out

Fallstrick 1: MED wirkt nicht zwischen unterschiedlichen Providern

Wenn du zwei verschiedene Provider hast, ist MED als Inbound-TE meist wirkungslos. Selbst wenn beide Provider MED akzeptieren, vergleichen sie MED nicht gegeneinander, weil sie aus verschiedenen Neighbor-AS kommen. Für Multi-Provider nutzt du LocalPref (Outbound) und Communities/Prepending (Inbound).

• Outbound-TE: LocalPref in deinem AS
• Inbound-TE: Provider-Communities oder AS-Path Prepending
• MED: nur als Feinsteuerung innerhalb eines Providers

Fallstrick 2: MED wird „überschrieben“ oder normalisiert

Viele Provider setzen eigene MEDs, um interne Traffic-Engineering-Modelle durchzusetzen. Dann siehst du zwar lokal deine MED-Werte, aber sie haben beim Provider keinen Effekt. Du erkennst das nur durch Messung von extern (Looking Glass/Traceroutes).

• Symptom: du änderst MED, Traffic bleibt gleich
• Ursache: Provider ignoriert/normalisiert MED
• Lösung: Provider-Community-Guide nutzen oder Produkt anpassen

Fallstrick 3: MED + Hot-Potato: Erwartung vs. Realität

Hot-Potato bedeutet: Provider liefert Traffic zum nächstgelegenen Exit zu dir. Das kann MED-Effekte überlagern, besonders wenn der Provider sein IGP/TE so gebaut hat, dass bestimmte PoPs immer „näher“ sind. MED ist dann nur eine weiche Feinsteuerung.

Fallstrick 4: Inkonsequente MED-Policy erzeugt Instabilität

Wenn du MED pro Prefix ständig änderst oder unterschiedliche Teams unterschiedliche Werte setzen, entsteht Route-Churn. Das kann sich wie „BGP flapt“ anfühlen, obwohl nur Attributwerte wechseln. Governance und Change-Disziplin sind daher Pflicht.

• MED-Änderungen als Change mit Messfenster behandeln
• Wertebereiche standardisieren
• Nur wenige Prefix-Klassen (kritisch, normal, bulk)

Verifikation: Wirkt MED wirklich?

Du musst drei Dinge prüfen: (1) MED wird outbound gesendet, (2) der Provider akzeptiert es, (3) der Traffic folgt dem erwarteten Eingang. Punkt (3) erfordert externe Sicht.

Outbound MED auf dem Router prüfen

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

Externe Validierung (Praxis)

• Provider Looking Glass: welcher Ingress wird gewählt?
• Traceroutes von externen Standorten
• NetFlow/Traffic-Graphs: Inbound-Volumen pro Link

Best Practices: MED als „Feinwerkzeug“ einsetzen

MED ist kein Ersatz für sauberes Multi-Homing-Design. Nutze MED als Feinsteuerung innerhalb eines Providers, und setze für grobes Inbound-TE eher Communities/Prepending ein. Damit bleibt dein Design robust.

• MED nur bei mehreren Links zum gleichen Provider-AS
• Kleine, dokumentierte Wertebereiche
• Immer mit Outbound Whitelist und Max-Prefix kombinieren
• Erfolg nur durch Messung belegen (extern)

Quick-Runbook: MED Troubleshooting in 5 Minuten

Diese Kommandos zeigen dir, ob du MED korrekt sendest und ob lokale Policies es überschreiben. Für die Provider-Wirkung brauchst du externe Messung.

show ip bgp summary
show ip bgp 203.0.113.0/24
show ip bgp neighbors 192.0.2.1 advertised-routes
show route-map RM_OUT_ISP_A
show ip prefix-list PL_APP_CRIT

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.