Inhalt

Einführung

Voraussetzungen

Anforderungen

Verwendete Komponenten

Hintergrundinformationen

Wichtige Informationen

Übersicht von RFC 1583, Abschnitt 16.4.6

Übersicht von RFC 2328, Abschnitt 16.4.1

Konfigurieren

Szenario 1

Netzwerkdiagramm

Szenario 2

Netzwerkdiagramm

Empfehlung

Überprüfen

Fehlerbehebung

Zugehörige Informationen

Einführung

Dieses Dokument beschreibt, wie das OSPF-Protokoll (Open Shortest Path First) zwischen Nexus und der Cisco IOS®-Funktion in Cisco IOS und Nexus Operating System (NXOS) implementiert wird.

Voraussetzungen

Anforderungen

Cisco empfiehlt, das OSPF-Protokoll zu kennen.

Verwendete Komponenten

Die Informationen in diesem Dokument basieren auf den folgenden Software- und Hardwareversionen:

- NXOS Version 6.2(6a)

- Cisco IOS Version 15.1(4)M1

Hintergrundinformationen

Cisco IOS-Geräte unterstützen RFC 1583. NXOS unterstützt jedoch RFC 2328. Es gibt Designs, bei denen dieser Unterschied Routing-Schleifen im Netzwerk erstellen kann, wenn externe OSPF-Routen im Netzwerk vorhanden sind.

Wichtige Informationen

Der Unterschied zwischen RFC 1583 und RFC 2328 hinsichtlich der Auswahl der besten Route zwischen mehreren externen Routen wird in diesem Abschnitt erläutert.

Übersicht von RFC 1583, Abschnitt 16.4.6

Um externe Pfade vom Typ 1 zu vergleichen, überprüfen Sie die Summe der Entfernung zur Weiterleitungsadresse und die angegebene Metrik vom Typ 1 (X+Y).  Wenn Sie externe Pfade vom Typ 2 vergleichen möchten, achten Sie auf die angegebenen Type 2-Metriken und ggf. auf den Abstand zu den Weiterleitungsadressen.

Wenn der neue Pfad kürzer ist, ersetzt er die aktuellen Pfade im Eintrag für die Routing-Tabelle.  Wenn der neue Pfad die gleichen Kosten aufweist, wird er der Pfaderliste des Routing-Tabelleneintrags hinzugefügt.

Hinweis: Wenn die Weiterleitungsadresse vollständig Null ist, wird der Autonomous System Boundary Router (ASBR) verwendet, um die beste Route auszuwählen.

Übersicht von RFC 2328, Abschnitt 16.4.1

Interregionale Pfade, die nicht-Backbone-Bereiche verwenden, sind immer die bevorzugte Methode. Die anderen Pfade, die Pfade im Backbone-Bereich und die Pfade zwischen den Zonen, haben dieselbe Präferenz.

Konfigurieren

Szenario 1

Netzwerkdiagramm

R3 und R4 verteilen dasselbe Netzwerk 172.16.1.0/24 mit derselben Metrik wie die externe OSPF-E2-Route. R6 bevorzugt die von R3 angegebene Route, da die Weiterleitungsmetrik zum ASBR3 niedriger ist als R4 und der Next-Hop für 172.16.1.0/24 R1 ist. (Gemäß RFC 1583 basiert die Pfadauswahl ausschließlich auf Kosten.)

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 bevorzugt die von R4 angekündigte Route trotz der höheren Kosten, da es sich um eine intra-Area-Route zum ASBR handelt. Die Route verläuft nicht durch den Backbone-Bereich, und der Next-Hop ist R6 (gemäß 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

Dies führt zu einer Schleife im Netzwerk, da R6 die Pakete an R1 und R1 zurück an R6 sendet.

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

Wie Sie sehen, verläuft das Paket zwischen R1 und R6. Um dieses Problem zu beheben, müssen Sie die RFC-Kompatibilität für NXOS ändern.

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

R1 zeigt sie nun korrekt auf R2 und die Schleife wird aus dem Netzwerk entfernt.

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

Szenario 2

Netzwerkdiagramm

R1 empfängt eine NSSA-External (Typ 7) Route von R6 und eine externe Route (Typ 5) von R2 für dasselbe Präfix 172.16.1.0/24. R1 bevorzugt Typ 7, in der Regel wird jedoch in OSPF Typ 5 gegenüber Typ 7 bevorzugt.

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.

Da für R1 der RFC1583-Kompatibilitätsbefehl nicht im OSPF-Routerprozess konfiguriert ist und die LSAs (Type 5 Link State Advertisement’s) adv-router-id in Bereich 0 (Backbone-Router) erreichbar ist, übernimmt OSPF immer den Pfad für die Route über den Non-Backbone-Bereich. In diesem Fall wird der Next-Hop in Bereich 2 ausgewählt (gemäß 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.

Empfehlung

Es gibt andere Design- oder Netzwerkszenarien, bei denen dieses Kompatibilitätsproblem Schleifen oder suboptimales Routing im Netzwerk verursachen kann, wenn das Netzwerk über NXOS und Cisco IOS verfügt, die zusammen mit OSPFv2 ausgeführt werden.

Cisco empfiehlt, den RFC 1583-Kompatibilitätsbefehl im NXOS OSPF-Router-Konfigurationsmodus zu verwenden, wenn das Netzwerk Geräte enthält, die nur RFC 1583 (Cisco IOS) unterstützen.

Überprüfen

Für diese Konfiguration ist derzeit kein Überprüfungsverfahren verfügbar.

Fehlerbehebung

Für diese Konfiguration sind derzeit keine spezifischen Informationen zur Fehlerbehebung verfügbar.

Zugehörige Informationen

- RFC 1583

- RFC 2328

- Technischer Support und Dokumentation - Cisco Systems