Usa discriminatore MultiExit per influenzare la selezione del miglior percorso BGP
Introduzione
In questo documento viene descritto il comando bgp deterministic-med e il suo effetto sulla selezione del percorso in base al discriminatore multiexit (MED).
Prerequisiti
Requisiti
Cisco raccomanda la conoscenza dei seguenti argomenti:
- Routing IP di base
- Border Gateway Protocol (BGP)
Componenti usati
Il documento può essere consultato per tutte le versioni software o hardware.
Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.
Convenzioni
Per ulteriori informazioni sulle convenzioni usate da Cisco, consultare il documento Cisco sulle convenzioni nei suggerimenti tecnici.
Attributo MED
MED è un attributo BGP opzionale non transitivo che fornisce un suggerimento ai vicini esterni sul percorso preferito in un sistema autonomo (AS) con più punti di ingresso. MED è anche noto come metrica esterna di una route e un valore MED inferiore è preferito rispetto a un valore superiore. Per impostazione predefinita, BGP confronta i valori MED solo tra i percorsi ricevuti dallo stesso AS adiacente.
Nota: Per impostazione predefinita, BGP confronta i valori MED solo per i percorsi ricevuti dallo stesso AS adiacente, a meno che non sia configurato bgp always-compare-med. per ulteriori informazioni, vedere Differenze tra il comando bgp deterministic-med e il comando bgp always-compare-med.
Topologia della rete
Topologia della rete
Esempio
In questo scenario, AS 65502 è un utente dell'ISP con AS 65501. R4 è connesso a due router diversi sul lato ISP per scopi di ridondanza e annuncia due reti all'ISP: 10.4.0.0/16 e 10.5.0.0/16. Parte della configurazione rilevante è mostrata in questa sezione.
| R4 |
|---|
! hostname r4 ! ip cef ! ! interface Loopback10 ip address 10.4.0.1 255.255.0.0 ! interface Loopback11 ip address 10.5.0.1 255.255.0.0 ! interface Serial0/0 ip address 192.168.20.4 255.255.255.0 ! interface Serial1/0 ip address 192.168.30.4 255.255.255.0 ! router bgp 65502 no synchronization bgp log-neighbor-changes network 10.4.0.0 mask 255.255.0.0 network 10.5.0.0 mask 255.255.0.0 neighbor 192.168.20.2 remote-as 65501 neighbor 192.168.30.3 remote-as 65501 no auto-summary ! ip classless ! ! line con 0 exec-timeout 0 0 line aux 0 line vty 0 4 exec-timeout 0 0 login ! ! end |
| R2 |
|---|
! hostname r2 ! ip cef ! ! interface Loopback0 ip address 10.2.2.2 255.255.255.255 ! interface Ethernet0/0 ip address 172.16.0.2 255.255.255.0 ! interface Serial1/0 ip address 192.168.1.2 255.255.255.0 serial restart-delay 0 ! interface Serial2/0 ip address 192.168.20.2 255.255.255.0 serial restart-delay 0 ! router ospf 1 log-adjacency-changes redistribute connected passive-interface Serial2/0 network 10.2.2.2 0.0.0.0 area 0 network 172.16.0.2 0.0.0.0 area 0 network 192.168.1.2 0.0.0.0 area 0 network 192.168.20.2 0.0.0.0 area 0 ! router bgp 65501 no synchronization bgp log-neighbor-changes neighbor 10.1.1.1 remote-as 65501 neighbor 10.1.1.1 update-source Loopback0 neighbor 10.3.3.3 remote-as 65501 neighbor 10.3.3.3 update-source Loopback0 neighbor 192.168.20.4 remote-as 65502 no auto-summary ! ip classless ! ! line con 0 exec-timeout 0 0 transport preferred all transport output all line aux 0 transport preferred all transport output all line vty 0 4 exec-timeout 0 0 login transport preferred all transport input all transport output all ! end |
Le relative configurazioni R1 e R3 utilizzano lo stesso design di R2. R1, R2 e R3 hanno la raggiungibilità iBGP attraverso le interfacce di loopback e l'IGP fornisce la raggiungibilità agli hop successivi BGP. R3 dispone di una sessione eBGP con sessioni R4 e iBGP con R1 e R2.
R1 dispone di un iBGP che esegue il peer di R2 e uno di R3. Osservare le tabelle R1, R2 e R3 BGP visualizzate per le due reti pubblicizzate da R4:
r2#show ip bgp 10.4.0.1
BGP routing table entry for 10.4.0.0/16, version 7
Paths: (2 available, best #1, table Default-IP-Routing-Table)
Advertised to non peer-group peers:
10.1.1.1 10.3.3.3
65502
192.168.20.4 from 192.168.20.4 (10.4.4.4)
Origin IGP, metric 0, localpref 100, valid, external, best
65502
192.168.30.4 (metric 74) from 10.3.3.3 (10.3.3.3)
Origin IGP, metric 0, localpref 100, valid, internal
r2#show ip bgp 10.5.0.1
BGP routing table entry for 10.5.0.0/16, version 6
Paths: (2 available, best #2, table Default-IP-Routing-Table)
Advertised to non peer-group peers:
10.1.1.1 10.3.3.3
65502
192.168.30.4 (metric 74) from 10.3.3.3 (10.3.3.3)
Origin IGP, metric 0, localpref 100, valid, internal
65502
192.168.20.4 from 192.168.20.4 (10.4.4.4)
Origin IGP, metric 0, localpref 100, valid, external, best
r3#show ip bgp 10.4.0.1
BGP routing table entry for 10.4.0.0/16, version 8
Paths: (2 available, best #2, table Default-IP-Routing-Table)
Advertised to non peer-group peers:
10.1.1.1 10.2.2.2
65502
192.168.20.4 (metric 74) from 10.2.2.2 (10.2.2.2)
Origin IGP, metric 0, localpref 100, valid, internal
65502
192.168.30.4 from 192.168.30.4 (10.4.4.4)
Origin IGP, metric 0, localpref 100, valid, external, best
r3#show ip bgp 10.5.0.1
BGP routing table entry for 10.5.0.0/16, version 10
Paths: (2 available, best #1, table Default-IP-Routing-Table)
Advertised to non peer-group peers:
10.1.1.1 10.2.2.2
65502
192.168.30.4 from 192.168.30.4 (10.4.4.4)
Origin IGP, metric 0, localpref 100, valid, external, best
65502
192.168.20.4 (metric 74) from 10.2.2.2 (10.2.2.2)
Origin IGP, metric 0, localpref 100, valid, internal
r1#show ip bgp 10.4.0.1
BGP routing table entry for 10.4.0.0/16, version 11
Paths: (2 available, best #1, table Default-IP-Routing-Table)
Not advertised to any peer
65502
192.168.20.4 (metric 128) from 10.2.2.2 (10.2.2.2)
Origin IGP, metric 0, localpref 100, valid, internal, best
65502
192.168.30.4 (metric 128) from 10.3.3.3 (10.3.3.3)
Origin IGP, metric 0, localpref 100, valid, internal
r1#show ip bgp 10.5.0.1
BGP routing table entry for 10.5.0.0/16, version 10
Paths: (2 available, best #2, table Default-IP-Routing-Table)
Not advertised to any peer
65502
192.168.30.4 (metric 128) from 10.3.3.3 (10.3.3.3)
Origin IGP, metric 0, localpref 100, valid, internal
65502
192.168.20.4 (metric 128) from 10.2.2.2 (10.2.2.2)
Origin IGP, metric 0, localpref 100, valid, internal, best
Sia R2 che R3 scelgono il miglior percorso come percorso esterno da R4, che è previsto in base all'algoritmo di selezione del miglior percorso BGP. Per ulteriori informazioni, fare riferimento a Algoritmo di selezione del miglior percorso BGP.
Analogamente, R1 sceglie R2 per accedere alle due reti perché gli attributi del miglior percorso BGP precedenti sono correlati e l'ID del router BGP più basso è utilizzato come parametro per l'interruzione dei tempi. R2 ha l'ID router 10.2.2.2 e R3 ha l'ID router 10.3.3.3. Poiché l'ID router R2s è 10.2.2.2 e l'ID router R3s è 10.3.3.3, R2 viene scelto. In questa configurazione di base, per impostazione predefinita, tutto il traffico diretto alle due reti in AS 65502 passa da R1 a R2 e quindi a R4. Si supponga ora che R4 desideri bilanciare il carico del traffico ricevuto da AS 65501. A tale scopo, senza apportare modifiche all'ISP R4, è possibile configurare R4 in modo che utilizzi MED per forzare il traffico di una rete in un percorso e il traffico dell'altra rete in un altro percorso.
Nota: Si noti che l'esempio di configurazione MED descritto fornisce una progettazione del traffico per prefisso e non un vero bilanciamento del carico a costo uguale.
Questa è la configurazione di R4 dopo aver applicato la configurazione necessaria:
| R4 |
|---|
! hostname r4 ! ip cef ! ! ! interface Loopback10 ip address 10.4.0.1 255.255.0.0 ! interface Loopback11 ip address 10.5.0.1 255.255.0.0 ! interface Serial0/0 ip address 192.168.20.4 255.255.255.0 ! interface Serial1/0 ip address 192.168.30.4 255.255.255.0 ! router bgp 65502 no synchronization bgp log-neighbor-changes network 10.4.0.0 mask 255.255.0.0 network 10.5.0.0 mask 255.255.0.0 neighbor 192.168.20.2 remote-as 65501 neighbor 192.168.20.2 route-map setMED-R2 out neighbor 192.168.30.3 remote-as 65501 neighbor 192.168.30.3 route-map setMED-R3 out no auto-summary ! ip classless no ip http server ! ! access-list 1 permit 10.4.0.0 0.0.255.255 access-list 2 permit 10.5.0.0 0.0.255.255 ! route-map setMED-R3 permit 10 match ip address 1 set metric 200 ! route-map setMED-R3 permit 20 match ip address 2 set metric 100 !--- The route-map setMED-R3 is applying a MED of 200 to the 10.4.0.0/16 |
Nota: in questo esempio, vengono pubblicizzati solo 10.4.0.0/16 e 10.5.0.0/16. Se vengono annunciati prefissi aggiuntivi per lo stesso router adiacente, aggiungerli all'elenco degli accessi o alla sequenza di route-map appropriata. Aggiungere una sequenza di autorizzazioni finale se i prefissi non corrispondenti devono essere annunciati senza essere filtrati dalla mappa route in uscita.
Dopo l'applicazione di MED, R2 seleziona il percorso/collegamento da R2 a R4 come migliore per 10.4.0.0/16, mentre R3 seleziona il percorso/collegamento da R3 a R4 come migliore per 10.5.0.0/16. Nello stato di convergenza indicato, R1 riceve il miglior annuncio iBGP ammesso per ogni prefisso e utilizza R2 per 10.4.0.0/16 e R3 per 10.5.0.0/16:
r1#show ip bgp 10.4.0.1
BGP routing table entry for 10.4.0.0/16, version 14
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x800
Not advertised to any peer
65502
192.168.20.4 (metric 128) from 10.2.2.2 (10.2.2.2)
Origin IGP, metric 100, localpref 100, valid, internal, best
r1#show ip bgp 10.5.0.1
BGP routing table entry for 10.5.0.0/16, version 13
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x800
Not advertised to any peer
65502
192.168.30.4 (metric 128) from 10.3.3.3 (10.3.3.3)
Origin IGP, metric 100, localpref 100, valid, internal, best
Vedere l'esempio successivo per la visualizzazione R2:
r2#show ip bgp 10.4.0.1
BGP routing table entry for 10.4.0.0/16, version 10
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Advertised to non peer-group peers:
10.1.1.1 10.3.3.3
65502
192.168.20.4 from 192.168.20.4 (10.4.4.4)
Origin IGP, metric 100, localpref 100, valid, external, best
r2#show ip bgp 10.5.0.1
BGP routing table entry for 10.5.0.0/16, version 11
Paths: (2 available, best #1, table Default-IP-Routing-Table)
Advertised to non peer-group peers:
192.168.20.4
65502
192.168.30.4 (metric 74) from 10.3.3.3 (10.3.3.3)
Origin IGP, metric 100, localpref 100, valid, internal, best
65502
192.168.20.4 from 192.168.20.4 (10.4.4.4)
Origin IGP, metric 200, localpref 100, valid, external
R2 mostra un percorso per 10.4.0.0/16 perché R3 non annuncia più il percorso appreso da R4 dopo che R3 ha selezionato il percorso appreso da iBGP attraverso R2 come migliore. R3 ritira l'aggiornamento (invia un ritiro della route BGP, questo aggiornamento contiene una metrica irraggiungibile) per 10.4.0.0/16 quando rileva che R3 utilizza R2 per accedere a 10.4.0.0/16. Le regole di pubblicità iBGP standard impediscono a R3 di annunciare il percorso iBGP a un altro peer iBGP nella topologia seguente:
r3#show ip bgp 10.4.0.0
BGP routing table entry for 10.4.0.0/16, version 20
Paths: (2 available, best #1, table Default-IP-Routing-Table)
Advertised to non peer-group peers:
192.168.30.4
65502
192.168.20.4 (metric 74) from 10.2.2.2 (10.2.2.2)
Origin IGP, metric 100, localpref 100, valid, internal, best
65502
192.168.30.4 from 192.168.30.4 (10.4.4.4)
Origin IGP, metric 200, localpref 100, valid, external
Ciò consente a R2 di risparmiare una certa quantità di memoria in quanto non deve memorizzare queste informazioni inutili. Nel caso in cui la sessione BGP tra R2 e R4 fallisca, R2 invierà un aggiornamento irraggiungibile a R3 per 10.4.0.0/16. Questo aggiornamento spingerà R3 a inviare un aggiornamento con la route R3 per 10.4.0.0/16 via R4 a R2. R2 può iniziare a indirizzare via R3.
Comando MED
Per abilitare il confronto deterministico MED, configurare il comando bgp deterministic-med nella modalità di configurazione del router BGP. Quando è abilitato, bgp deterministic-med rimuove la dipendenza temporale dalle decisioni del percorso migliore basate su MED raggruppando i percorsi dallo stesso AS prima del confronto. In questo modo viene garantito un confronto preciso MED tra tutte le route ricevute dallo stesso sistema autonomo (AS).
Se si disabilita bgp deterministic-med, le route degli ordini ricevute possono influire sulle decisioni relative al miglior percorso basate su MED. Questa condizione si può verificare quando la stessa route viene ricevuta da più AS o sub-AS di confederazione, con la stessa lunghezza del percorso ma con MED diversi.
Esempi
Si considerino ad esempio le route successive:
| Ingresso | Percorso AS | MED | Preferenza locale | Lunghezza percorso AS | Origine |
|---|---|---|---|---|---|
| voce1 |
AS 65001 |
100 |
100 |
1 |
IGP |
| voce2 |
AS 65002 |
50 |
100 |
1 |
IGP |
| voce 3 |
AS 65001 |
20 |
100 |
1 |
IGP |
Router BGP con MED disabilitato
Esempio di ordine di arrivo 1
L'ordine in cui sono state ricevute le route BGP è (voce1 è la voce meno recente nella tabella BGP e voce3 è la voce più recente):
- voce1
- voce2
- voce 3
Inizialmente esiste una sola route, quindi entry1 diventa il percorso migliore. quando si confronta entry2 da AS65002 con entry1 da AS65001, MED viene ignorato perché le route provengono da SA adiacenti diversi; poiché tutti gli attributi rimanenti sono uguali, il router mantiene il percorso migliore corrente, entry1.
Quando si confronta la voce 3 da AS65001 con MED 20 con la voce 1 da AS65001 con MED 100, MED viene valutato perché entrambe le route provengono dalla stessa AS adiacente. Poiché 20 è inferiore a 100, entry3 diventa il miglior percorso finale.
Esempio di ordine di arrivo 2
Si supponga ora che le stesse route arrivino in un ordine diverso:
- voce2
- voce 3
- voce1
Inizialmente, voce2 viene selezionato come miglior percorso. se si confronta la voce 3 di AS65001 con la voce 2 di AS65002, MED non viene valutato perché le rotte provengono da diverse AS vicine; poiché tutti gli attributi rimanenti sono uguali, il router mantiene il percorso migliore corrente, entry2.
Quando si confronta entry1 da AS65001 con entry2 da AS65002, MED viene di nuovo ignorato perché le route provengono da AS adiacenti diversi. Di conseguenza, il router conserva il valore entry2 come miglior percorso finale.
Se MED è disabilitato, l'ordine di arrivo delle route influisce sulla sequenza di confronto. Si noti che le tre route ricevute sono esattamente le stesse, ma sono stati selezionati percorsi migliori diversi perché le route sono arrivate in un ordine diverso. Questa è la dipendenza temporale che bgp deterministic-med è progettato per eliminare.
Nota: Per ulteriori informazioni sui criteri di selezione del percorso BGP, fare riferimento all'algoritmo di selezione del miglior percorso BGP.
Router BGP con MED abilitato
Se il protocollo MED è abilitato, il router raggruppa i percorsi in base al protocollo AS adiacente prima di prendere qualsiasi decisione basata sul protocollo MED. In questo caso, le route provenienti dallo stesso AS vengono raggruppate e vengono confrontate le voci migliori di ogni gruppo. Nell'esempio riportato sono presenti due AS, AS 65001 e AS 65002.
| Group | Percorso AS | Ingresso | Route selezionata | Motivo |
|---|---|---|---|---|
| Gruppo 1 |
AS 65001 |
entry1 (MED 100), entry3 (MED 20) |
voce 3 |
MED inferiore (20 < 100) |
| Gruppo 2 |
AS 65002 |
voce 2 (MED 50) |
voce2 |
Solo candidato |
Nel gruppo 1, il miglior percorso è entry3 a causa del MED inferiore (in questa decisione viene utilizzato MED poiché i percorsi provengono dallo stesso AS). Nel Gruppo 2 è presente una sola voce (voce2). Il miglior percorso viene quindi determinato con un confronto dei vincitori di ogni gruppo, MED non viene utilizzato in questo confronto per impostazione predefinita perché i vincitori di ogni gruppo provengono da AS diversi.
A questo punto, MED non è più preso in considerazione, in quanto le rotte rimanenti hanno origine da diverse AS vicine. L'algoritmo per il miglior percorso BGP prosegue con gli attributi successivi (ad esempio eBGP vs. iBGP, metrica IGP all'hop successivo, percorso meno recente, ID router e così via, a seconda degli attributi differenti).
Il vantaggio principale è che questo processo è indipendente dalle rotte ricevute. Se il router apprende i percorsi come:
- voce1 → voce2 → voce3
- voce2 → voce3 → voce1
- voce3 → voce1 → voce2
Di conseguenza, gli ordini di arrivo producono lo stesso risultato in quanto la decisione si basa sugli attributi del ciclo di lavorazione anziché sull'ordine in cui sono stati ricevuti gli aggiornamenti.
Nota: Se anche bgp always-compare-med è stato abilitato quando si confrontano la voce 3 (il vincitore del Gruppo 1) e la voce 2 (il vincitore del Gruppo 2); la 3 è la vincitrice a causa del MED inferiore.
Nota: L'attivazione del comando bgp deterministic-med garantisce il confronto della variabile MED nella scelta delle route annunciate da peer diversi nello stesso AS. L'attivazione del comando bgp always-compare-med garantisce il confronto del MED per i percorsi provenienti da computer adiacenti in diverse appliance ASA.
L'esempio presuppone che tutti gli attributi BGP con priorità più alta (come Weight, Local Preference, AS Path Length, Origin e altri) siano identici. Lo scopo è quello di isolare l'effetto di MED e illustrare perché disabilitare bgp deterministic-med può garantire che la decisione del miglior percorso dipenda dall'ordine di arrivo della route.
Cisco consiglia di abilitare bgp always-compare-med in tutte le nuove implementazioni di rete. Inoltre, se bgp always-compare-med è abilitato, le decisioni BGP MED sono sempre deterministiche.
Per ulteriori informazioni sui comandi bgp deterministic-med e bgp always-compare-med, consultare il documento sulla differenza tra il comando bgp deterministic-med e il comando bgp always-compare-med.
Informazioni correlate
- Esempio di configurazione del BGP con due provider di servizi diversi (multihoming)
- Supporto IP/BGP
- Case study del protocollo BGP
- Supporto tecnico Cisco e download
Cronologia delle revisioni
| Revisione | Data di pubblicazione | Commenti |
|---|---|---|
3.0 |
30-Jul-2026
|
Titolo aggiornato, introduzione, ortografia, grammatica, inserimento di righe orizzontali per separare le sezioni/leggibilità. |
2.0 |
26-Jan-2024
|
SEO e formattazione aggiornati. |
1.0 |
10-Dec-2001
|
Versione iniziale |
Feedback