Introduzione
In questo documento vengono descritte le funzionalità di prevenzione dei loop e i passaggi minimi di configurazione quando si esegue il protocollo di routing OSPF (Open Shortest Path First) tra router PE (Provider Edge) e CE (Customer Edge). Presenta uno scenario di rete che illustra l'utilizzo del bit verso il basso (DN), che è un'opzione in Link State Advertisement (LSA) e Domain Tag.
Prerequisiti
Requisiti
Cisco raccomanda la conoscenza di OSPF e di Multiprotocol Label Switching (MPLS) Layer 3 VPN.
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.
Premesse
Il provider di servizi (SP) e il router CE scambiano i percorsi con un protocollo di routing concordato tra l'SP e il Cliente. Scopo del presente documento è descrivere il meccanismo di prevenzione dei loop quando si utilizza OSPFv2.
Quando si utilizza OSPFv2 su un collegamento PE-CE che appartiene a un particolare VRF (Virtual Routing and Forwarding) o VPN, il router PE:
- Ridistribuisce le route ricevute tramite OSPF per tale VPN nel protocollo MP-BGP (Multiprotocol-Border Gateway Protocol) e le annuncia agli altri router PE.
- Ridistribuisce le route BGP installate nella VPN tramite MP-BGP nell'istanza OSPF per tale VPN e le annuncia ai router CE.
Configurazione
Esempio di rete
Prendere in considerazione questa topologia di rete per comprendere le tecniche di prevenzione dei loop.
In questa configurazione esiste la possibilità di un loop. Ad esempio, se CE1 annuncia la LSA OSPF di tipo 1 a PE1, che ridistribuisce la route in VPNv4 e la annuncia a PE2, PE2 a sua volta annuncia la LSA di riepilogo a CE2. Questa route ricevuta da CE2 potrebbe essere annunciata nuovamente a PE3. Il terzo router PE apprende la route OSPF, che è migliore della route BGP, e annuncia nuovamente la route in BGP come locale alla sede del cliente 2. PE3 non apprende mai che la route annunciata non è stata originata dalla sede del cliente 2.
Per risolvere questa situazione, quando le route vengono ridistribuite da MP-BGP in OSPF, vengono contrassegnate con un bit DN in LSA Tipo 3, 5 o 7 e hanno il tag di dominio per LSA Tipo 5 e 7.
Configurazioni
Di seguito è riportata la configurazione di esempio sui router PE. Questa configurazione include la configurazione VRF, il processo OSPF 2 in esecuzione tra i router PE-CE, il processo OSPF 1 in esecuzione come IGP (Interior Gateway Protocol) nel core MPLS e la configurazione MP-BGP.
Bit DN
Il bit non utilizzato in precedenza nel campo Opzioni LSA OSPF è detto bit DN. Questo bit viene impostato su LSA di tipo 3, 5 e 7 quando le route MP-BGP vengono ridistribuite in OSPF. Quando l'altro router PE riceve la LSA da un router CE di tipo 3, 5 o 7 con il bit DN impostato, le informazioni provenienti da tale LSA non vengono utilizzate nel calcolo della route OSPF.
In base alla topologia di rete, PE2 imposta il bit DN per la LSA ridistribuita e questa LSA non viene mai considerata per il calcolo della route nel processo OSPF 2 su PE3. Pertanto, PE3 non ridistribuisce mai la route in MP-BGP.
Di seguito è riportato un esempio dell'intestazione OSPF che mostra il set di bit DN, quando la route è stata annunciata dal router PE per LSA di tipo 3:
Open Shortest Path First
OSPF Header
Version: 2
Message Type: LS Update (4)
Packet Length: 56
Source OSPF Router: 10.10.23.3 (10.10.23.3)
Area ID: 0.0.0.0 (0.0.0.0) (Backbone)
Checksum: 0x4034 [correct]
Auth Type: Null (0)
Auth Data (none): 0000000000000000
LS Update Packet
Number of LSAs: 1
Summary-LSA (IP network)
.000 1110 0001 0000 = LS Age (seconds): 3600
0... .... .... .... = Do Not Age Flag: 0
Options: 0xa2 (DN, DC, E)
1... .... = DN: Set
.0.. .... = O: Not set
..1. .... = DC: Demand Circuits are supported
...0 .... = L: The packet does NOT contain LLS data block
.... 0... = NP: NSSA is NOT supported
.... .0.. = MC: NOT Multicast Capable
.... ..1. = E: External Routing Capability
.... ...0 = MT: NO Multi-Topology Routing
Tag dominio
Il tag di dominio è applicabile solo per l'LSA OSPF tipo 5 e tipo 7. Quando le route VPNv4 vengono ridistribuite da MP-BGP a OSPF su router PE, il tag di dominio viene impostato per le route esterne OSPF. È possibile impostare manualmente il tag con il comando domain-tag in Processo OSPF oppure generare automaticamente un valore a 32 bit:
In base alla topologia di rete, PE2 imposta il tag di dominio per LSA di tipo 5 e 7 quando ridistribuisce la route VPNv4 in OSPF. Questo LSA non viene mai preso in considerazione per il calcolo della route perché il bit DN è già impostato, ma ha anche il tag Domain impostato, quindi l'LSA viene ignorato perché il tag Domain corrisponde al tag VPN / VRF. Pertanto, la route non viene mai ridistribuita in OSPF.
Nell'esempio viene mostrato come LSA Type 5 viene ignorato quando viene ricevuto con Domain Tag Set uguale al tag di dominio VRF locale su PE3 da CE3:
*Jan 31 00:29:23.947: OSPF-2 EXTER: adv_rtr 10.10.57.5, age 3, seq 0x80000001,
metric 10, metric-type 2, fw-addr 0.0.0.0
*Jan 31 00:29:23.947: OSPF-2 EXTER: Tag equals to VPN Tag, ignoring the LSA
*Jan 31 00:29:23.947: OSPF-2 EXTER: Process partial nssa spf queue
PE3#show ip ospf database external 192.168.5.5
OSPF Router with ID (10.3.3.3) (Process ID 1)
OSPF Router with ID (10.10.68.6) (Process ID 2)
Type-5 AS External Link States
LS age: 38
Options: (No TOS-capability, DC)
LS Type: AS External Link
Link State ID: 192.168.5.5 (External Network Number )
Advertising Router: 10.10.57.5
LS Seq Number: 80000001
Checksum: 0x89A3
Length: 36
Network Mask: /32
Metric Type: 2 (Larger than any link state path)
MTID: 0
Metric: 10
Forward Address: 0.0.0.0
External Route Tag: 3489725928
Verifica
I comandi per verificare se il bit DN è impostato per LSA e il tag di dominio applicato sono gli stessi utilizzati per controllare il database LSA.
In questo output viene mostrato l'esempio di LSA OSPF tipo 3 e tipo 5 e vengono evidenziati il bit DN e il tag impostati quando le route VPNv4 vengono ridistribuite in OSPF su PE2:
Nota: MPLS VPN OSPF PE-CE include sempre il meccanismo di prevenzione del loop per la gestione dei problemi. Nelle versioni precedenti di Cisco IOS®, le licenze LSA di tipo 3 per IETF originali utilizzano il bit DN nelle licenze LSA e le licenze LSA di tipo 5 utilizzano un tag. La nuova RFC 4576 impone l'uso del bit DN per le associazioni di protezione locale di tipo 3 e 5.
Il commit è stato eseguito tramite l'ID bug Cisco CSCtw79182.
I router PE con immagini Cisco IOS con la correzione di questo problema generano LSA esterni di Tipo 5 con bit DN e un tag come meccanismi di prevenzione dei loop. Nelle versioni precedenti di Cisco IOS, l'unico tag pubblicizzato era a questo scopo per le route esterne.
La modifica è stata apportata perché è possibile riscrivere un tag (modificando l'ID di dominio VPN o tramite la mappa di route) ma il bit DN non è controllabile dall'utente. In alcune configurazioni di tipo corner-case, alcuni clienti potrebbero aver deliberatamente disattivato il meccanismo di prevenzione dei loop con una sovrascrittura delle etichette delle LSA esterne in modo che il router PE preferisca la route OSPF alla route BGP.
Nelle versioni più recenti di Cisco IOS, ciò non è possibile. La maggior parte dei clienti che utilizzano PE-CE OSPF in una configurazione di manuale non subirà alcuna modifica. I clienti che sostituiscono i tag potrebbero riscontrare un cambiamento nel comportamento.
Risoluzione dei problemi
Al momento non sono disponibili informazioni specifiche per la risoluzione dei problemi di questa configurazione.