Esempio di configurazione del routing OSPF/routing subottimale tra Cisco IOS e NXOS per percorsi esterni

Opzioni per il download

  • PDF     (181.3 KB)
    Visualizza con Adobe Reader su diversi dispositivi
  • ePub     (134.7 KB)
    Visualizza in diverse app su iPhone, iPad, Android, Sony Reader o Windows Phone
  • Mobi (Kindle)     (125.5 KB)
    Visualizza su dispositivo Kindle o tramite app Kindle su più dispositivi
Aggiornato:2 luglio 2014
ID documento:117824

Linguaggio senza pregiudizi

La documentazione per questo prodotto è stata redatta cercando di utilizzare un linguaggio senza pregiudizi. Ai fini di questa documentazione, per linguaggio senza di pregiudizi si intende un linguaggio che non implica discriminazioni basate su età, disabilità, genere, identità razziale, identità etnica, orientamento sessuale, status socioeconomico e intersezionalità. Le eventuali eccezioni possono dipendere dal linguaggio codificato nelle interfacce utente del software del prodotto, dal linguaggio utilizzato nella documentazione RFP o dal linguaggio utilizzato in prodotti di terze parti a cui si fa riferimento. Scopri di più sul modo in cui Cisco utilizza il linguaggio inclusivo.

Informazioni su questa traduzione

Cisco ha tradotto questo documento utilizzando una combinazione di tecnologie automatiche e umane per offrire ai nostri utenti in tutto il mondo contenuti di supporto nella propria lingua. Si noti che anche la migliore traduzione automatica non sarà mai accurata come quella fornita da un traduttore professionista. Cisco Systems, Inc. non si assume alcuna responsabilità per l’accuratezza di queste traduzioni e consiglia di consultare sempre il documento originale in inglese (disponibile al link fornito).

Introduzione

In questo documento viene descritto come il protocollo OSPF (Open Shortest Path First) tra Nexus e la funzionalità Cisco IOS® viene implementato in Cisco IOS e Nexus Operating System (NXOS).

Prerequisiti

Requisiti

Cisco raccomanda la conoscenza del protocollo OSPF.

Componenti usati

Le informazioni fornite in questo documento si basano sulle seguenti versioni software e hardware:

  • NXOS versione 6.2(6a)
  • Cisco IOS versione 15.1(4)M1

Premesse

I dispositivi Cisco IOS supportano la RFC 1583. Tuttavia, NXOS supporta la RFC 2328 e in alcuni progetti questa differenza può creare loop di routing nella rete quando vi sono route OSPF esterne nella rete.

Informazioni importanti

In questa sezione viene illustrata la differenza tra la RFC 1583 e la RFC 2328 per quanto riguarda la scelta della route migliore tra più route esterne.

Riassunto della RFC 1583, sezione 16.4.6

Per confrontare i percorsi esterni di tipo 1, considerare la somma della distanza dall'indirizzo di inoltro e della metrica di tipo 1 annunciata (X+Y).  Per confrontare i percorsi esterni di tipo 2, osservare le metriche di tipo 2 annunciate e, se necessario, la distanza dagli indirizzi di inoltro.

Se il nuovo percorso è più breve, sostituisce i percorsi presenti nella voce della tabella di routing.  Se il nuovo percorso ha lo stesso costo, viene aggiunto all'elenco di percorsi della voce della tabella di routing.

Nota: Se l'indirizzo di inoltro ha costo zero, viene utilizzato il router ASBR (Autonomous System Boundary Router) per scegliere il percorso migliore.

Riassunto della RFC 2328, sezione 16.4.1

I percorsi interni che utilizzano aree non backbone sono sempre i più preferiti. Gli altri tracciati, quelli della backbone intra area e quelli tra aree, hanno la stessa preferenza.

Configurazione

Scenario 1

Esempio di rete

R3 e R4 ridistribuiscono la stessa rete 172.16.1.0/24 con la stessa metrica della route E2 di tipo esterno OSPF. R6 preferisce la route annunciata da R3 perché la metrica di inoltro all'ASBR R3 è inferiore a R4 e l'hop successivo per 172.16.1.0/24 è R1. (In base a RFC 1583, la selezione del percorso si basa esclusivamente sul costo.)

R6#sh ip ospf border-routers

OSPF Router with ID (192.168.6.6) (Process ID 1)

Base Topology (MTID 0)

Internal Router Routing Table
Codes: i - Intra-area route, I - Inter-area route

i 192.168.4.4 [51] via 192.168.56.5, GigabitEthernet0/0, ASBR, Area 2, SPF 17 
 >>>> Cost is 51 to reach R4 ASBR.
i 192.168.1.1 [1] via 192.168.16.1, GigabitEthernet0/1, ABR, Area 2, SPF 17
I 192.168.3.3 [42] via 192.168.16.1, GigabitEthernet0/1, ASBR, Area 2, SPF 17
 >>>> Cost is 42 to reach R3 ASBR

R6#sh ip route 172.16.1.0
Routing entry for 172.16.1.0/24
Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 42
Last update from 192.168.16.1 on GigabitEthernet0/1, 00:02:13 ago
Routing Descriptor Blocks:
* 192.168.16.1, from 192.168.3.3, 00:02:13 ago, via GigabitEthernet0/1
Route metric is 20, traffic share count is 1

R1 preferisce il percorso pubblicizzato da R4 nonostante il costo più elevato, in quanto si tratta di un percorso intra-area verso ASBR. Il percorso non passa attraverso l'area della backbone e l'hop successivo è R6 (come da RFC 2328).

R1-NXOS# sh ip ospf border-routers
OSPF Process ID 1 VRF default, Internal Routing Table
Codes: i - Intra-area route, I - Inter-area route

intra 192.168.2.2 [40], ABR, Area 0.0.0.0, SPF 18
via 192.168.12.2, Eth4/43
inter 192.168.3.3 [41], ASBR, Area 0.0.0.0, SPF 18 >>>> Cost is 41
via 192.168.12.2, Eth4/43
intra 192.168.4.4 [91], ASBR, Area 0.0.0.2, SPF 18 >>>> Cost is 91
via 192.168.16.6, Eth4/44

switch-R1-NXOS# sh ip route 172.16.1.0
IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%' in via output denotes VRF 

172.16.1.0/24, ubest/mbest: 1/0
*via 192.168.16.6, Eth4/44, [110/20], 00:10:41, ospf-1, type-2

Ciò provoca un loop nella rete in quanto R6 invia i pacchetti a R1 e R1 li invia nuovamente a R6.

R5#traceroute 172.16.1.1 numeric
 Type escape sequence to abort.
Tracing the route to 172.16.1.1
VRF info: (vrf in name/id, vrf out name/id)
1 192.168.56.6 4 msec 0 msec 0 msec
2 192.168.16.1 4 msec 0 msec 4 msec
3 192.168.16.6 0 msec 4 msec 0 msec
4 192.168.16.1 4 msec 0 msec 4 msec
5 192.168.16.6 0 msec 4 msec 0 msec

Come si può vedere, il pacchetto esegue un loop tra R1 e R6. Per risolvere questo problema, è necessario modificare la compatibilità RFC su NXOS.

R1-NXOS(config)# router ospf 1
R1-NXOS(config-router)# rfc1583compatibility

switch-R1-NXOS# sh ip route 172.16.1.0
IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%' in via output denotes VRF 

172.16.1.0/24, ubest/mbest: 1/0
*via 192.168.12.2, Eth4/43, [110/20], 00:00:40, ospf-1, type-2

Ora R1 lo punta correttamente a R2 e il loop viene rimosso dalla rete.

R5#traceroute 172.16.1.1 numeric
Type escape sequence to abort.
Tracing the route to 172.16.1.1
VRF info: (vrf in name/id, vrf out name/id)
1 192.168.56.6 0 msec 4 msec 0 msec
2 192.168.16.1 0 msec 0 msec 0 msec
3 192.168.12.2 4 msec 0 msec 0 msec
4 192.168.23.3 4 msec 0 msec 4 msec
5 192.168.23.3 4 msec 0 msec 4 msec

Scenario 2

Esempio di rete

R1 riceve una route NSSA-esterna (tipo 7) da R6 e una route esterna (tipo 5) da R2 per lo stesso prefisso 172.16.1.0/24. R1 preferisce il tipo 7, anche se normalmente in OSPF il tipo 5 è preferito al tipo 7.

R1-NXOS# sh ip ospf database nssa-external 172.16.1.0 detail
OSPF Router with ID (192.168.1.1) (Process ID 1 VRF default)

Type-7 AS External Link States (Area 0.0.0.2)

   LS age: 914
   Options: 0x28 (No TOS-capability, Type 7/5 translation, DC)
   LS Type: Type-7 AS-External
   Link State ID: 172.16.1.0 (Network address)
   Advertising Router: 192.168.4.4                 >>>>> Type 7 originated by R4
 and installed in the RIB.
   LS Seq Number: 0x80000001
   Checksum: 0x3696
   Length: 36
   Network Mask: /24
         Metric Type: 2 (Larger than any link state path)
         TOS: 0
         Metric: 20
         Forward Address: 192.168.45.4
         External Route Tag: 0>


R1-NXOS# sh ip ospf database external 172.16.1.0 detail
 OSPF Router with ID (192.168.1.1) (Process ID 1 VRF default)


Type-5 AS External Link States

    LS age: 853
   Options: 0x2 (No TOS-capability, No DC)
   LS Type: Type-5 AS-External
   Link State ID: 172.16.1.0 (Network address)
   Advertising Router: 192.168.1.1         >>>>> Since Type 7 is installed
 in the RIB, it was converted to type 5
   LS Seq Number: 0x80000001
   Checksum: 0xb545
   Length: 36
   Network Mask: /24
         Metric Type: 2 (Larger than any link state path)
         TOS: 0<
         Metric: 20
         Forward Address: 192.168.45.4
         External Route Tag: 0<

   LS age: 596
   Options: 0x20 (No TOS-capability, DC)
   LS Type: Type-5 AS-External
   Link State ID: 172.16.1.0 (Network address)
   Advertising Router: 192.168.3.3              >>>>>>  Type 5 is also received from R3
   LS Seq Number: 0x80000002
   Checksum: 0x2250
   Length: 36
   Network Mask: /24
         Metric Type: 2 (Larger than any link state path)>
         TOS: 0
         Metric: 20<>
         Forward Address: 0.0.0.0
         External Route Tag: 0


R1-NXOS# sh ip route 172.16.1.0
IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

172.16.1.0/24, ubest/mbest: 1/0
    *via 192.168.16.6, Eth4/44, [110/20], 00:16:54, ospf-1, nssa type-2     >>>> Type 7
 route is installed in RIB.

Poiché R1 non dispone del comando di compatibilità rfc1583 configurato nel processo del router OSPF e l'ID adv-router della route LSA (Link State Advertisement) di tipo 5 è raggiungibile nell'area 0 (router backbone), OSPF sceglie sempre il percorso per la route tramite l'area non backbone. In questo caso, l'hop successivo viene scelto nell'area 2 (in base alla RFC 2328).

R1-NXOS(config)# router ospf 1
R1-NXOS(config-router)# rfc1583compatibility

R1-NXOS# sh ip route 172.16.1.0
IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

172.16.1.0/24, ubest/mbest: 1/0
    *via 192.168.12.2, Eth4/43, [110/20], 00:00:04, ospf-1, type-2     >>>> Type 5
 route is installed in RIB.

Suggerimento

In altri scenari di progettazione o di rete, questo problema di compatibilità può causare loop o routing non ottimale nella rete se la rete dispone di NXOS e Cisco IOS che vengono eseguiti insieme a OSPFv2.

Cisco consiglia di utilizzare il comando di compatibilità RFC 1583 nella modalità di configurazione del router OSPF NXOS se la rete include dispositivi che supportano solo RFC 1583, ossia Cisco IOS.

Verifica

Attualmente non è disponibile una procedura di verifica per questa configurazione.

Risoluzione dei problemi

Al momento non sono disponibili informazioni specifiche per la risoluzione dei problemi di questa configurazione.

Informazioni correlate

TAC Authored

Contributo dei tecnici Cisco

  • Sumit Kothiyal and Vinod Sharma
    Cisco TAC Engineers.

Questo documento ti è stato utile?

FeedbackFeedback

Contattaci

Questo documento si applica a questi prodotti