Sommario

Introduzione

Prerequisiti

Requisiti

Componenti usati

Convenzioni

Attributo MED

Esempio

Il comando bgp deterministic-med

Esempi

Router BGP con bgp deterministic-med disabilitato

Router BGP con bgp deterministic-med abilitato

Informazioni correlate

Introduzione

Questo documento descrive bgp deterministic-med e spiega come influisce sulla selezione del percorso in base al discriminatore a più uscite (MED).

Prerequisiti

Requisiti

Nessun requisito specifico previsto per questo documento.

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, consultare il documento Cisco sulle convenzioni nei suggerimenti tecnici.

Attributo MED

MED è un attributo non transitivo facoltativo. MED è un suggerimento per i vicini esterni sul percorso preferito in un sistema autonomo (AS) che ha più punti di ingresso. Il MED è anche noto come metrica esterna di una route. Un valore MED inferiore è preferito rispetto a un valore superiore.

In questa sezione viene descritto un esempio di come utilizzare MED per influenzare la decisione di instradamento presa da un SA adiacente.

Topologia della rete

Topologia della rete

Esempio

In questo scenario, AS 65502 è un utente dell'ISP con AS 65501. R4 è collegato 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. In questa sezione vengono illustrate alcune delle configurazioni appropriate.

R4

!

version 12.3

!

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

!

version 12.3

!

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 configurazioni di R1 e R3 sono simili a R2. R3 dispone di un eBGP con peer R4 e di un iBGP con peer R1.

R1 ha un iBGP che esegue il peer di R2 e uno di R3. Osservare le tabelle BGP di R1, R2 e R3 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 come miglior percorso il 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, in conformità con la regola del miglior percorso BGP: selezionare il percorso con l'ID del router più basso. Poiché l'ID router R2 è 10.2.2.2 e l'ID router R3 è 10.3.3.3, viene scelto R2. 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.

Questa è la configurazione di R4 dopo aver applicato la configurazione necessaria:

R4

!

version 12.3

!

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 MED-R3 is applying a MED of 200 to the 10.4.0.0/16

!--- network and a MED of 100 to the 10.5.0.0/16 network.

!--- The route-map is being applied outbound towards R3. ! route-map setMED-R2 permit 10 match ip address 1 set metric 100 ! route-map setMED-R2 permit 20 match ip address 2 set metric 200 !--- The route-map MED-R2 is applying a MED of 100 to the 10.4.0.0/16

!--- network and a MED of 200 to the 10.5.0.0/16 network.

!--- The route-map is being applied outbound towards R2.  ! ! ! line con 0 exec-timeout 0 0 line aux 0 line vty 0 4 exec-timeout 0 0 login ! ! end

Nota: è necessario cancellare la sessione BGP con  clear ip bgp * soft out  ad esempio, per fare in modo che la configurazione esegua un'azione.

R1 ora vede il percorso su R2 come il miglior percorso per la rete 10.4.0.0/16 perché l'aggiornamento ricevuto da R2 ha un MED di 100 rispetto a un MED di 200, che è quello che R3 annuncia. Analogamente, R1 utilizza R3 e il collegamento R3 - R4 per accedere a 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#sh 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

Osservare il display 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

Il motivo per cui R2 visualizza un solo percorso per 10.4.0.0/16 è che R3 ritira (invia un aggiornamento con metrica irraggiungibile) l'aggiornamento per 10.4.0.0/16 quando rileva che R3 utilizza R2 per accedere a 10.4.0.0/16 (dopo l'esecuzione del percorso BGP ottimale su tutti i percorsi disponibili):

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 poiché non deve memorizzare queste informazioni inutili. In caso di errore della sessione BGP tra R2 e R4, R2 invierà un aggiornamento non raggiungibile a R3 per 10.4.0.0/16. Questo aggiornamento fa sì che R3 invii un aggiornamento con il percorso R3 per 10.4.0.0/16 tramite R4 a R2. R2 potrebbe iniziare a instradare attraverso R3.

Il comando bgp deterministic-med

Se si attiva  bgp deterministic-med    rimuove tutte le dipendenze temporali delle decisioni del miglior percorso basate su MED. Garantisce che venga effettuato un accurato confronto MED tra tutte le rotte ricevute dallo stesso sistema autonomo (AS).

Se si disattiva  bgp deterministic-med , l'ordine di ricezione delle route può 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:

entry1: ASPATH 1, MED 100, internal, IGP metric to NEXT_HOP 10

entry2: ASPATH 2, MED 150, internal, IGP metric to NEXT_HOP 5

entry3: ASPATH 1, MED 200, external

L'ordine in cui sono state ricevute le route BGP è voce3, voce2 e voce1 (voce3 è la voce meno recente della tabella BGP e voce1 è la voce più recente).

Router BGP con bgp deterministic-med disabilitato

Un router BGP con bgp deterministic-med disabled sceglie entry2 su entry1, a causa di una metrica IGP inferiore per raggiungere il valore NEXT_HOP (MED non è stato utilizzato in questa decisione perché entry1 e entry2 provengono da due AS diversi). Preferisce quindi entry3 rispetto a entry2 perché è esterno. Tuttavia, entry3 ha un MED maggiore di entry1. Per ulteriori informazioni sui criteri di selezione del percorso BGP, fare riferimento all'algoritmo di selezione del miglior percorso BGP.

Router BGP con bgp deterministic-med abilitato

In questo caso, le route provenienti dallo stesso AS vengono raggruppate e vengono confrontate le voci migliori di ogni gruppo. Nell'esempio specificato sono presenti due AS, AS 1 e AS 2.

Group 1:  entry1: ASPATH 1, MED 100, internal, IGP metric to NEXT_HOP 10

entry3: ASPATH 1, MED 200, external

Group 2:  entry2: ASPATH 2, MED 150, internal, IGP metric to NEXT_HOP 5

Nel gruppo 1, il miglior percorso è entry1 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. Quando si attiva  bgp always-compare-med   modifica questo comportamento predefinito). Ora, quando si confronta entry1 (il vincitore del Gruppo 1) e entry2 (il vincitore del Gruppo 2), entry2 può essere il vincitore in quanto ha la migliore metrica IGP per l'hop successivo.

Se bgp always-compare-med   è stato abilitato anche quando si confronta entry1 (il vincitore del Gruppo 1) e entry 2 (il vincitore del Gruppo 2), entry 1 può essere il vincitore a causa di MED inferiore.

Cisco consiglia di abilitare bgp always-compare-med  in tutte le nuove distribuzioni di rete. Inoltre, se  bgp always-compare-med  è abilitato, le decisioni BGP MED sono sempre deterministiche.

Per ulteriori informazioni sul bgp deterministic-med e bgp always-compare-med  fare riferimento aDifferenze 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 e download Cisco