Utilizzare Multi-Exit Discriminator per selezionare il miglior percorso per il router BGP

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.

!
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

!
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:

!
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 eseguire un'azione su queste configurazioni.

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 relative al 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 Cisco e download