BGP MED — Multi-Exit Discriminator

CCIE / ENARSI Best Path Critère #6 · lowest wins

Profil de l'attribut

Type Code BGP4
CatégorieOptional Non-Transitive
Critère Best Path#6 — lowest wins
Propagation iBGP✅ Oui
Propagation eBGP❌ S'arrête à la frontière AS
Valeur par défautNon envoyé (absent)
Plage de valeurs0 – 4 294 967 295 (32-bit)
DirectionInbound hint → AS voisin
Optional Non-Transitive Type code 4 Lowest wins Critère #6 Non propagé au-delà de l'AS voisin

Définition et rôle

Le MED (Multi-Exit Discriminator) est un hint envoyé à un AS voisin pour lui indiquer le point d'entrée préféré lorsqu'il existe plusieurs liens vers votre AS. Contrairement à LOCAL_PREF qui influence le trafic sortant, le MED influence le trafic entrant chez votre voisin.

C'est un attribut optionnel et non-transitif : si l'AS voisin le reçoit, il n'est pas propagé aux AS suivants. Il s'arrête à la frontière de l'AS qui le reçoit.

┌──────────────────────────────────┐ │ AS 65001 (vous) │ │ │ eBGP │ ┌──────────┐ │ ISP ──────────────┼──│ R1 │ MED=10 → ISP │ ← ISP préfère entrer via R1 (AS 100) link1 │ │ 10.1.1.1 │ │ │ └──────────┘ │ eBGP │ ┌──────────┐ │ ISP ──────────────┼──│ R2 │ MED=100 → ISP │ ← ISP évite R2 (MED élevé) (AS 100) link2 │ │ 10.1.1.2 │ │ │ └──────────┘ │ └──────────────────────────────────┘ MED=10 < MED=100 → ISP préfère envoyer le trafic via le lien R1

Optional Non-Transitive — conséquences pratiques

ComportementDétail
Optional Peut être absent d'un UPDATE. Un routeur qui ne comprend pas l'attribut l'ignore sans générer d'erreur.
Non-Transitive L'AS voisin qui reçoit le MED ne le propage pas aux AS suivants. Le MED est local à la relation bilatérale.
Absent = ? Si absent, traité comme 0 (best) par défaut, ou comme infini si bgp bestpath missing-as-worst est activé.
Comparaison restreinte Par défaut, le MED n'est comparé qu'entre routes venant du même AS voisin. Routes de 2 AS différents → MED ignoré.

Position dans le Best Path Algorithm

1 Weight
2 LOCAL_PREF
3 Locally Originated
4 AS-PATH
5 Origin
6 ★ MED
7 eBGP/iBGP
8 IGP metric
9 AIGP
10 Oldest
11 Router-ID
12 Cluster-list
13 Neighbor IP

Le MED est le premier critère qui représente un hint envoyé à l'extérieur de votre AS. Les critères #1–#5 agissent sur la sélection locale ou interne. Le MED agit sur la décision de l'AS voisin.

Le comportement du MED est contrôlé par deux commandes clés : always-compare-med et deterministic-med. Mal comprises, elles sont source d'erreurs au CCIE.

Règle par défaut — même AS voisin uniquement

Par défaut, le MED n'est comparé qu'entre routes annoncées par le même AS voisin (même premier AS dans le path). Si deux routes viennent de deux AS différents, le MED est ignoré et on passe au critère suivant.

! Routes dans la table BGP de R1 :
*  10.0.0.0/8   10.1.1.1   MED=50   via AS100  ← même AS voisin
*  10.0.0.0/8   10.1.1.2   MED=10   via AS100  ← même AS voisin → MED comparé → MED=10 gagne
*  10.0.0.0/8   10.2.2.1   MED=5    via AS200  ← AS différent → MED ignoré par défaut !

⚠ La route via AS200 (MED=5) n'est pas préférée automatiquement — MED n'est pas comparé entre AS100 et AS200 sans always-compare-med.

always-compare-med — comparer MED entre tous les AS

Active la comparaison du MED même entre routes venant d'AS voisins différents. Doit être configuré sur tous les routeurs de l'AS pour cohérence.

router bgp 65001
 bgp always-compare-med            ! comparer MED quelle que soit l'origine AS
!
! Avec cette config :
*  10.0.0.0/8   10.1.1.1   MED=50   via AS100
*  10.0.0.0/8   10.1.1.2   MED=10   via AS100
*> 10.0.0.0/8   10.2.2.1   MED=5    via AS200  ← MED=5 gagne maintenant

deterministic-med — résultats cohérents

Sans deterministic-med, le résultat du best path peut varier selon l'ordre d'arrivée des routes dans la table BGP. Cisco recommande d'activer les deux ensemble.

! ─── RÈGLE DE BASE (sans always-compare-med) ────────────────────────────────
! Par défaut, MED n'est comparé QU'entre routes reçues du MÊME AS voisin.
! Entre AS différents → MED est sauté, on passe aux critères suivants.
!
! ─── PROBLÈME sans deterministic-med ────────────────────────────────────────
! Trois routes pour le même préfixe :
!   Route A : AS100, MED=20   Route B : AS200, MED=5   Route C : AS100, MED=10
!
! BGP traite les routes en tournoi séquentiel (ordre d'arrivée) :
!
! CAS 1 — A arrive en 1er, puis B, puis C :
!   A vs B : AS100 vs AS200 → AS différents → MED sauté → critère #10 : A plus
!            ancienne → A gagne
!   A vs C : AS100 vs AS100 → même AS → MED comparé → 10 < 20 → C gagne
!   ✅ Résultat CAS 1 : C (AS100, MED=10)
!
! CAS 2 — B arrive en 1er, puis A, puis C :
!   B vs A : AS200 vs AS100 → AS différents → MED sauté → critère #10 : B plus
!            ancienne → B gagne
!   B vs C : AS200 vs AS100 → AS différents → MED sauté → B plus ancienne → B gagne
!   ❌ Résultat CAS 2 : B (AS200, MED=5)  ← résultat DIFFÉRENT du CAS 1 !
!
! → Le résultat change selon l'ordre d'arrivée = non déterministe
!
router bgp 65001
 bgp always-compare-med
 bgp deterministic-med
!
! ─── SOLUTION avec deterministic-med ────────────────────────────────────────
! Avant tout tournoi, BGP regroupe les routes par AS et élit un gagnant par AS :
!   Groupe AS100 : A(MED=20) vs C(MED=10) → C gagne (10 < 20)
!   Groupe AS200 : B(MED=5)  → B gagne par défaut (seul candidat)
! Puis compare les gagnants de chaque groupe :
!   C(AS100,MED=10) vs B(AS200,MED=5) → always-compare-med → 5 < 10 → B gagne
! ✅ Résultat : B (AS200, MED=5) — identique quel que soit l'ordre d'arrivée

missing-as-worst — traitement du MED absent

! Par défaut : MED absent = 0 (route FAVORISÉE)
! Avec missing-as-worst : MED absent = 4294967295 (route DÉFAVORISÉE)
!
router bgp 65001
 bgp bestpath missing-as-worst      ! MED absent = valeur maximale (défavorisé)
!
! Cas pratique : un peer n'envoie pas de MED, un autre envoie MED=100
! Sans missing-as-worst : peer sans MED gagne (MED=0 implicite)
! Avec missing-as-worst : peer avec MED=100 gagne (absent = infini)

Le MED peut être défini localement avant l'annonce (set metric), reçu d'un voisin, ou dérivé de la métrique IGP avec metric-type internal.

Méthode 1 — set metric dans une route-map (recommandé)

! Envoyer MED=10 pour le lien principal, MED=100 pour le backup
route-map SET-MED-PRIMARY permit 10
 set metric 10                      ! MED=10 sur le lien principal
!
route-map SET-MED-BACKUP permit 10
 set metric 100                     ! MED=100 sur le lien backup
!
router bgp 65001
 neighbor 10.1.1.1 route-map SET-MED-PRIMARY out
 neighbor 10.1.1.2 route-map SET-MED-BACKUP  out

Méthode 2 — bgp default metric (global)

! Applique un MED par défaut à toutes les routes redistribuées
router bgp 65001
 default-metric 50                  ! MED=50 pour toutes les routes redistribuées
 redistribute ospf 1
!
! ⚠ n'affecte que les routes redistribuées, pas les routes "network"

Méthode 3 — metric-type internal (MED = IGP metric)

Transmet la métrique IGP du routeur vers le prochain saut comme valeur MED. Permet à l'AS voisin de choisir le lien le plus proche topologiquement.

router bgp 65001
 neighbor 10.1.1.1 route-map MED-IGP out
!
route-map MED-IGP permit 10
 set metric-type internal           ! MED = coût IGP vers le next-hop BGP
!
! Résultat : MED varie dynamiquement avec la topologie IGP
! ⚠ Risque d'instabilité si la métrique IGP fluctue souvent

Modifier le MED reçu — inbound route-map

! Forcer un MED spécifique sur les routes reçues d'un voisin
route-map FORCE-MED-IN permit 10
 set metric 200                     ! écrase le MED reçu
!
router bgp 65001
 neighbor 10.2.2.1 route-map FORCE-MED-IN in
!
! Utile pour déprécier les routes reçues d'un lien backup
! en forçant un MED élevé localement avant sélection

Vérification

R1# show ip bgp
! La colonne Metric affiche le MED :
   Network       Next Hop     Metric  LocPrf  Weight  Path
*> 10.0.0.0/8   10.1.1.1        10            0  65100 i
*               10.1.1.2       100            0  65100 i

R1# show ip bgp 10.0.0.0/8
! Détail :
  65100
    10.1.1.1 from 10.1.1.1
      Origin IGP, metric 10, valid, external, best
  65100
    10.1.1.2 from 10.1.1.2
      Origin IGP, metric 100, valid, external

Scénario dual-link vers le même AS voisin. Le MED tranche au critère #6 après que Weight, LOCAL_PREF, Locally Originated, AS-PATH et Origin soient tous égaux.

Scénario — dual-link AS65001 → AS65100

! AS65001 (R1, R2) connecté à AS65100 via deux liens
! AS65100 envoie MED=10 via lien R1, MED=100 via lien R2
! Critères #1 à #5 tous égaux → MED tranche au critère #6

R1# show ip bgp
   Network          Next Hop     Metric  LocPrf  Weight  Path
*> 10.0.0.0/8       10.1.1.1        10       100      0  65100 i   ← MED=10 BEST ★
*                   10.1.1.2       100       100      0  65100 i   ← MED=100
!
! Même AS voisin (65100) → MED comparé → 10 < 100 → R1 gagne

Comparaison critère par critère

CritèreVia R1 (10.1.1.1)Via R2 (10.1.1.2)Résultat
#1 Weight00TIE
#2 LOCAL_PREF100100TIE
#3 Locally OriginatedNon (reçue)Non (reçue)TIE
#4 AS-PATH length1 (65100)1 (65100)TIE
#5 OriginiiTIE
#6 MED 10 ← lowest 100 ★ Via R1 GAGNE

Scénario — 2 AS différents, MED ignoré par défaut

R1# show ip bgp
   Network       Next Hop     Metric  LocPrf  Weight  Path
*> 10.0.0.0/8   10.1.1.1        50       100      0  65100 i   ← AS65100, MED=50
*               10.2.2.1         5       100      0  65200 i   ← AS65200, MED=5
!
! MED=5 < MED=50 mais AS différents → MED ignoré par défaut
! Critère #7 eBGP=eBGP TIE → critère #8 IGP → critère #11 Router-ID tranche
!
! Avec bgp always-compare-med :
*               10.1.1.1        50       100      0  65100 i
*> 10.0.0.0/8   10.2.2.1         5       100      0  65200 i   ← MED=5 gagne maintenant

MED et LOCAL_PREF sont souvent confondus car tous les deux influencent le choix du chemin. Mais ils agissent dans des directions opposées et ont des portées très différentes.

📊 MED
Type code4
CatégorieOptional Non-Transitive
Critère#6 — lowest wins
Direction traficEntrant (inbound)
Qui configureVous — envoyé au voisin
Qui décideL'AS voisin
Portée1 saut AS uniquement
Propagation❌ Non transitif
Valeur par défautAbsent (= 0 ou infini)
Commande cléset metric
📍 LOCAL_PREF
Type code5
CatégorieWell-known Discretionary
Critère#2 — highest wins
Direction traficSortant (outbound)
Qui configureVous — reçu du voisin
Qui décideVous (votre AS)
PortéeTout votre AS (iBGP)
Propagation✅ Via iBGP, pas eBGP
Valeur par défaut100
Commande cléset local-preference

Règle mnémotechnique

ObjectifAttribut à utiliserConfigured on
Je veux que mon AS sorte par un lien spécifique LOCAL_PREF (highest) Route-map in sur le lien préféré
Je veux que l'AS voisin entre par un lien spécifique MED (lowest) Route-map out sur le lien préféré

Scénario combiné — dual-ISP, contrôle complet

! AS65001 connecté à ISP1 (AS100) et ISP2 (AS200)
! Objectif : ISP1 = préféré dans les deux sens
!
! TRAFIC SORTANT → LOCAL_PREF (vous décidez)
route-map FROM-ISP1 permit 10
 set local-preference 200           ! préférer les routes ISP1
route-map FROM-ISP2 permit 10
 set local-preference 100           ! routes ISP2 moins préférées
!
! TRAFIC ENTRANT → MED (vous suggérez à ISP)
route-map TO-ISP1 permit 10
 set metric 10                     ! MED bas = entrée préférée via ISP1
route-map TO-ISP2 permit 10
 set metric 100                    ! MED élevé = entrée dépréciée via ISP2
!
router bgp 65001
 neighbor 10.1.1.1 route-map FROM-ISP1 in
 neighbor 10.2.2.1 route-map FROM-ISP2 in
 neighbor 10.1.1.1 route-map TO-ISP1   out
 neighbor 10.2.2.1 route-map TO-ISP2   out

⚡ Piège #1 — MED absent ≠ MED=0 (par défaut)

Sans bgp bestpath missing-as-worst, un MED absent est traité comme MED=0, ce qui le rend plus attractif qu'une route avec MED=10. Une route sans MED peut donc gagner sur une route avec MED=10. Activer missing-as-worst si vous voulez que l'absence de MED soit défavorisante.

! Route A : MED=10 (envoyé explicitement)
! Route B : MED absent → traité comme 0 → B GAGNE par défaut !
bgp bestpath missing-as-worst     ! MED absent = 4294967295 → défavorisé

⚡ Piège #2 — Routes de 2 AS différents : MED ignoré par défaut

Sans always-compare-med, le MED n'est comparé qu'entre routes du même AS voisin. Si ISP1 envoie MED=1000 et ISP2 envoie MED=1, le MED est ignoré et c'est le critère #7 (eBGP>iBGP) ou suivant qui tranche. À l'exam, toujours vérifier si always-compare-med est actif.

⚡ Piège #3 — always-compare-med sans deterministic-med → non déterministe

Activer always-compare-med seul peut produire des résultats qui changent selon l'ordre d'arrivée des routes dans la table. Toujours combiner avec bgp deterministic-med. Ces deux commandes nécessitent un clear ip bgp * soft pour prendre effet sans reset des sessions.

router bgp 65001
 bgp always-compare-med
 bgp deterministic-med   ! toujours ensemble

⚡ Piège #4 — metric-type internal crée de l'instabilité

Avec set metric-type internal, le MED annoncé suit la métrique IGP vers le next-hop. Tout changement de topologie IGP (flap de lien, modification de coût OSPF) modifie le MED annoncé au voisin → UPDATE BGP → recalcul best path chez le voisin. Dans un réseau à topologie instable, éviter cette méthode.

⚡ Piège #5 — MED non transitif : le voisin ne le propage pas

Le MED est optional non-transitive : l'AS qui le reçoit ne le reannonce pas aux AS suivants. Si AS65001 envoie MED=10 à AS65100, AS65100 ne transmettra pas ce MED à AS65200. Ne pas compter sur le MED pour influencer des AS au-delà du voisin direct.

⚡ Piège #6 — Confusion MED (inbound) vs LOCAL_PREF (outbound)

MED influence le trafic entrant chez votre voisin (vous configurez out). LOCAL_PREF influence le trafic sortant de votre AS (vous configurez in). La confusion fréquente à l'exam : utiliser MED pour contrôler le trafic sortant — ça n'a aucun effet direct sur le choix de sortie de votre propre AS.

✓ Bonne pratique — ordre de préférence des outils inbound

Pour influencer le trafic entrant, par ordre d'efficacité décroissante : LOCAL_PREF chez le voisin (si accord) > MED > AS-PATH prepending. Le MED est "polite" — le voisin peut l'ignorer ou utiliser always-compare-med différemment. L'AS-PATH prepending est plus brutal mais plus universellement respecté.

Cliquer sur une carte pour révéler la réponse.

Quel est le type code BGP du MED ?
Type code 4 — Optional Non-Transitive.
Cliquer pour révéler
MED lowest ou highest wins ?
Lowest wins — contrairement à Weight et LOCAL_PREF. MED=10 est préféré à MED=100.
Cliquer pour révéler
Par défaut, le MED est comparé entre routes de 2 AS différents ?
Non — comparé uniquement entre routes du même AS voisin. Activer bgp always-compare-med pour comparer entre AS différents.
Cliquer pour révéler
Que vaut un MED absent par défaut ?
0 (le plus attractif) par défaut. Avec bgp bestpath missing-as-worst : 4 294 967 295 (le moins attractif).
Cliquer pour révéler
MED influence le trafic entrant ou sortant ?
Entrant — vous envoyez un MED à votre voisin pour lui suggérer par quel lien entrer dans votre AS. Configuré out sur votre routeur.
Cliquer pour révéler
Pourquoi combiner always-compare-med avec deterministic-med ?
Sans deterministic-med, le résultat du best path peut varier selon l'ordre d'arrivée des routes. Les deux ensemble garantissent un résultat cohérent et reproductible.
Cliquer pour révéler
Le MED est-il propagé au-delà de l'AS voisin ?
Non — Optional Non-Transitive. L'AS qui reçoit le MED ne le propage pas aux AS suivants. Portée limitée à la relation bilatérale.
Cliquer pour révéler
Quelle commande transmet la métrique IGP comme valeur MED ?
set metric-type internal dans une route-map. ⚠ Risque d'instabilité si la métrique IGP fluctue.
Cliquer pour révéler