Sommario

Introduzione

Prerequisiti

Requisiti

Componenti usati

Premesse

Attributo del percorso peso BGP impostato nelle route originate localmente

Modificare l'attributo del percorso peso BGP

Scenario reale

Introduzione

In questo documento viene descritta l'importanza dell'attributo Weight path del protocollo BGP (Border Gateway Protocol) negli scenari di failover di rete.

Prerequisiti

Requisiti

Cisco raccomanda la conoscenza dei seguenti argomenti:

- Border Gateway Protocol (BGP)

- Ridistribuzione dei protocolli di routing

- Router Cisco con Cisco IOS®

Componenti usati

Per questo documento, è stato usato un router Cisco con Cisco IOS versione 15.6(2)

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.

Premesse

Il protocollo BGP viene comunemente utilizzato per annunciare i prefissi di rete alla rete WAN (WAN) ricevuta tramite un protocollo IGP (Interior Gateway Protocol) dalla rete LAN (Lan Area Network) e viceversa. Senza la corretta configurazione, BGP può non riuscire a ripristinare il percorso di routing originale sulla WAN dopo che la rete è stata ripristinata da un errore di collegamento.

I router distribuiti in scenari di failover possono avere route bloccate che possono causare il reindirizzamento del traffico sul percorso di backup dopo un evento di rete di errore e ripristino. Ciò può verificarsi a causa della natura dell'attributo del percorso del peso BGP.

In caso di guasto della rete (generalmente con il collegamento WAN), la rete può convergere e utilizzare il percorso di backup disponibile ricevuto tramite IGP.

Tuttavia, dopo il ripristino del percorso principale, il router può ancora utilizzare il percorso di backup e non ripristinare il percorso originale sul collegamento WAN.

Si possono osservare conseguenze quali percorsi di routing asimmetrici e non ottimali.

Negli scenari di ridondanza con due router WAN, questi possono eseguire BGP per scambiare i prefissi di rete con la WAN. Il protocollo EIGRP (Enhanced Interior Gateway Routing Protocol) può essere utilizzato per scambiare prefissi di rete con dispositivi di rete LAN. La ridistribuzione reciproca tra questi protocolli è in genere necessaria per ottenere la connettività di rete completa.

Nota: nel documento vengono usati indifferentemente i termini prefisso e instradamento.

Il design di alto livello di questo argomento è illustrato nella topologia successiva:

Attributo del percorso peso BGP impostato nelle route originate localmente

Nello scenario successivo viene descritto il comportamento dell'attributo Percorso peso BGP nei casi di failover.

Passaggio 1. La route viene ricevuta tramite BGP.

Come mostrato nell'immagine, il router denominato WAN RTR riceve la rete 192.168.1.0/24 tramite BGP.

Se la distanza amministrativa (AD) è pari a 20, il percorso viene installato nella tabella di routing.

Tabella BGP:

WAN_RTR

WAN_RTR#show ip bgp

<snip>

Network          Next Hop            Metric LocPrf Weight Path

*>  192.168.1.0      10.1.2.2                 0             0 2 i

La tabella di routing mostra la route installata da BGP:

WAN_RTR

WAN_RTR#show ip route

<snip>

B     192.168.1.0/24 [20/0] via 10.1.2.2, 00:00:42

Passaggio 2. Il percorso viene ricevuto tramite EIGRP.

La sessione BGP diventa inattiva a causa di un errore di collegamento. Per convergenza di rete, lo stesso percorso 192.168.1.0/24 è ora ricevuto tramite EIGRP.

Il punto chiave è che BGP può annunciare o ridistribuire le route EIGRP (con l'aiuto della successiva configurazione del router). In questo caso, la route EIGRP viene aggiunta alla tabella BGP.

Nota: per impostazione predefinita, l'attributo del percorso BGP Weight è impostato su 32768 quando il router genera localmente i prefissi di rete.

Configurazione BGP:

WAN_RTR

WAN_RTR#show running-config | begin router bgp

<snip>

router bgp 1

redistribute eigrp 1

neighbor 10.1.2.2 remote-as 2

!

Nota: la rete del comando BGP 192.168.1.0 mask 255.255.255.0 può restituire gli stessi risultati.

Tabella BGP:

WAN_RTR

WAN_RTR#show ip bgp

<snip>

Network          Next Hop            Metric LocPrf Weight Path

*>  192.168.1.0      10.1.3.3            156160         32768 ?

La tabella di routing mostra il percorso installato da EIGRP:

WAN_RTR

WAN_RTR#show ip route

<snip>

D     192.168.1.0/24 [90/156160] via 10.1.3.3, 00:00:02, FastEthernet0/1

WAN_RTR#

Passaggio 3. Route ricevuta di nuovo tramite BGP.

Con la route EIGRP ora ridistribuita in BGP e dopo aver ricevuto nuovamente la route originale tramite BGP, sono ora presenti 2 voci per la rete 192.168.1.0/24 nella tabella BGP.

Tabella BGP:

WAN_RTR

WAN_RTR#show ip bgp

<snip>

Network          Next Hop            Metric LocPrf Weight Path

*   192.168.1.0      10.1.2.2                 0             0 2 i

*>                   10.1.3.3            156160         32768 ?

Nella tabella BGP:

- La voce creata alla fase 2 dalla route EIGRP ridistribuita in BGP può ancora essere visualizzata.

- Il percorso originale viene riaggiunto tramite la sessione BGP ristabilita.

Dal punto di vista del miglior percorso BGP:

- Il valore dell'attributo Weight path della route EIGRP ridistribuita in BGP è impostato su 32768, in quanto ha origine locale nel router dal punto di vista BGP.

- Il valore dell'attributo Weight path della route originale ricevuto tramite la sessione BGP con la WAN è 0.

- La prima rotta ha il peso più alto e viene quindi scelta come migliore nella tabella BGP.

- In questo modo, la tabella di routing non converge allo stato originale e mantiene la voce del percorso EIGRP.

Nota: l'attributo BGP Weight Path è il primo attributo di percorso che BGP controlla per selezionare il percorso migliore nella tabella BGP sui router Cisco IOS. BGP preferisce il percorso della voce con il peso più alto. Il peso è un parametro specifico di Cisco ed è significativo solo localmente nel router in cui è configurato. Ulteriori informazioni tramite l'algoritmo di selezione del miglior percorso BGP.

Tabella di routing:

WAN_RTR

WAN_RTR#show ip route

<snip>

D     192.168.1.0/24 [90/156160] via 10.1.3.3, 00:08:55, FastEthernet0/1

Modificare l'attributo del percorso peso BGP

Il valore predefinito dell'attributo BGP Weight path può essere modificato nella configurazione per peer BGP con il comando weight o una route-map.

I comandi successivi impostano l'attributo Weight path su 40000 per tutte le route ricevute dal peer BGP.

Esempio 1

Uso del comando weight

router bgp 1

neighbor 10.1.2.2 weight 40000

Esempio 2

Uso del comando route-map per impostare l'attributo Weight Path

route-map FROM-WAN permit 10

set weight 40000

!

router bgp 1

neighbor 10.1.2.2 route-map FROM-WAN in

!

clear ip bgp * soft in

Esempio 3

Uso del comando route-map per impostare l'attributo Weight Path per determinate route

ip prefix-list NETWORKS permit 192.168.1.0/24

!

route-map FROM-WAN permit 10

match ip address prefix NETWORKS

set weight 40000

route-map FROM-WAN permit 100

!

router bgp 1

neighbor 10.1.2.2 route-map FROM-WAN in

!

clear ip bgp * soft in

Aumentando il valore dell'attributo Weight path, le route originali ricevute tramite BGP hanno la precedenza, come mostrato nel caso successivo:

Passaggio 1. La route viene ricevuta tramite BGP.

La tabella BGP mostra che le route ricevute tramite BGP hanno ora un valore Weight di 4000 anziché zero.

Tabella BGP:

WAN_RTR

WAN_RTR#show ip bgp

<snip>

Network          Next Hop            Metric LocPrf Weight Path

*>  192.168.1.0      10.1.2.2                 0         40000 2 i

WAN_RTR#

Tabella di routing:

WAN_RTR

WAN_RTR#show ip route

<snip>

B     192.168.1.0/24 [20/0] via 10.1.2.2, 00:09:53

Passaggio 2. Il percorso viene ricevuto tramite EIGRP.

Le route originate localmente hanno ancora un valore di 32768 nella tabella BGP.

Tabella BGP:

WAN_RTR

WAN_RTR#show ip bgp

<snip>

Network          Next Hop            Metric LocPrf Weight Path

*>  192.168.1.0      10.1.3.3            156160         32768 ?

Tabella di routing:

WAN_RTR

WAN_RTR#show ip route

<snip>

D     192.168.1.0/24 [90/156160] via 10.1.3.3, 00:01:41, FastEthernet0/1

Passaggio 3. Route ricevuta di nuovo tramite BGP.

Con Weight 40000, le rotte ricevute tramite BGP sono ora scelte su quelle di origine locale. In questo modo la rete tornerà correttamente allo stato originale.

Tabella BGP:

WAN_RTR

WAN_RTR#show ip bgp

<snip>

Network          Next Hop            Metric LocPrf Weight Path

*>  192.168.1.0      10.1.2.2                 0         40000 2 i

Tabella di routing:

WAN_RTR

WAN_RTR#show ip route

<snip>

B     192.168.1.0/24 [20/0] via 10.1.2.2, 00:00:25

Scenario reale

Prendete come esempio lo scenario successivo:

Passaggio 1. Stato originale della rete.

Lo switch CORE Layer 3 riceve il percorso 192.168.1.0/24 tramite EIGRP da WAN RTR A e WAN RTR B. Viene selezionato il percorso su WAN RTR A.

L'output successivo mostra come lo switch CORE mantiene un'adiacenza EIGRP con entrambi i router WAN e che WAN RTR A è selezionato per raggiungere la rete 192.168.1.0/24.

NUCLEO

CORE#show ip eigrp neighbors

EIGRP-IPv4 Neighbors for AS(1)

H   Address                 Interface              Hold Uptime   SRTT   RTO  Q  Seq

(sec)         (ms)       Cnt Num

0   10.1.2.2  (WAN_RTR_A)   Fa0/0                    10 00:05:15   79  1066  0  10

1   10.1.3.3  (WAN_RTR_B)   Fa0/1                    12 00:06:22   76   456  0  5

CORE#show ip route

<snip>

D EX  192.168.1.0/24 [170/28416] via 10.1.2.2, 00:00:32, FastEthernet0/0

CORE#show ip eigrp topology

EIGRP-IPv4 Topology Table for AS(1)/ID(10.10.10.10)

<snip>

P 192.168.1.0/24, 1 successors, FD is 28416, tag is 4

via 10.1.2.2 (28416/2816), FastEthernet0/0

via 10.1.3.3 (281856/2816), FastEthernet0/1

Passaggio 2. Errore del collegamento WAN primario.

In caso di errore di collegamento, lo switch CORE installa il percorso tramite il secondo miglior percorso EIGRP, ossia WAN RTR B.

NUCLEO

CORE#show ip route

<snip>

D EX  192.168.1.0/24 [170/281856] via 10.1.3.3, 00:00:05, FastEthernet0/1

CORE#show ip eigrp topology

EIGRP-IPv4 Topology Table for AS(1)/ID(10.10.10.10)

<snip>

P 192.168.1.0/24, 1 successors, FD is 28416, tag is 4

via 10.1.3.3 (281856/2816), FastEthernet0/1

Passaggio 3. Ripristino del collegamento WAN primario.

Il collegamento WAN principale è stato ripristinato. Tuttavia, lo switch CORE continua a instradare il percorso di backup come mostrato nell'output successivo:

NUCLEO

CORE#show ip route

<snip>

D EX  192.168.1.0/24 [170/281856] via 10.1.3.3, 00:06:09, FastEthernet0/1

CORE#show ip eigrp topology

EIGRP-IPv4 Topology Table for AS(1)/ID(10.10.10.10)

<snip>

P 192.168.1.0/24, 1 successors, FD is 28416, tag is 4

via 10.1.3.3 (281856/2816), FastEthernet0/1

La causa di questo comportamento risiede nell'attributo del percorso del peso BGP, come indicato in precedenza.

Nello stato corrente, il metodo WAN RTR A mostra il percorso nella tabella di routing tramite EIGRP e nella tabella BGP ridistribuita dal metodo EIGRP a causa del valore massimo dell'attributo del percorso Weight che prevale sul valore Weight del percorso ricevuto tramite BGP dal collegamento WAN ristabilito.

WAN_RTR_A

WAN_RTR_A#show ip bgp

<snip>

Network          Next Hop            Metric LocPrf Weight Path

*   192.168.1.0      10.2.4.4                 0             0 4 i

*>                   10.1.2.1            284416         32768 ?

WAN_RTR_A#show ip bgp summary

BGP router identifier 10.20.20.20, local AS number 2

<snip>

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd

10.2.4.4        4            4      12      12       16    0    0 00:03:54   (UP) 4

WAN_RTR_A#show ip route

<snip>

D EX  192.168.1.0/24 [170/284416] via 10.1.2.1, 00:08:22, FastEthernet0/0

Il comportamento descritto in questo documento è stato ampiamente osservato sul campo. Le topologie di rete e i sintomi iniziali possono differire dall'esempio trattato. Tuttavia, la causa principale può essere e viene spesso descritta in questo documento. È importante verificare se le configurazioni e lo scenario soddisfano le variabili relative a questa condizione che possono verificarsi nella distribuzione in rete.