OSPF-routing tussen Loop/Sub-optimale routing tussen Cisco IOS en NXOS voor configuratievoorbeeld voor externe routers

Downloadopties

  • PDF     (181.3 KB)
    Met Adobe Reader op diverse apparaten bekijken
  • ePub     (137.1 KB)
    Bekijken in diverse apps op iPhone, iPad, Android, Sony Reader of Windows Phone
  • Mobi (Kindle)     (128.2 KB)
    Op Kindle-apparaat of via Kindle-app op meerdere apparaten bekijken
Bijgewerkt:2 juli 2014
Document-id:117824

Inclusief taalgebruik

De documentatie van dit product is waar mogelijk geschreven met inclusief taalgebruik. Inclusief taalgebruik wordt in deze documentatie gedefinieerd als taal die geen discriminatie op basis van leeftijd, handicap, gender, etniciteit, seksuele oriëntatie, sociaaleconomische status of combinaties hiervan weerspiegelt. In deze documentatie kunnen uitzonderingen voorkomen vanwege bewoordingen die in de gebruikersinterfaces van de productsoftware zijn gecodeerd, die op het taalgebruik in de RFP-documentatie zijn gebaseerd of die worden gebruikt in een product van een externe partij waarnaar wordt verwezen. Lees meer over hoe Cisco gebruikmaakt van inclusief taalgebruik.

Over deze vertaling

Cisco heeft dit document vertaald via een combinatie van machine- en menselijke technologie om onze gebruikers wereldwijd ondersteuningscontent te bieden in hun eigen taal. Houd er rekening mee dat zelfs de beste machinevertaling niet net zo nauwkeurig is als die van een professionele vertaler. Cisco Systems, Inc. is niet aansprakelijk voor de nauwkeurigheid van deze vertalingen en raadt aan altijd het oorspronkelijke Engelstalige document (link) te raadplegen.

Inleiding

Dit document beschrijft hoe het Open Shortest Path First (OSPF)-protocol tussen Nexus en Cisco IOS®-functie wordt geïmplementeerd in Cisco IOS en Nexus Operating System (NXOS).

Voorwaarden

Vereisten

Cisco raadt aan dat u kennis hebt van het OSPF-protocol.

Gebruikte componenten

De informatie in dit document is gebaseerd op de volgende software- en hardware-versies:

  • NXOS versie 6.2(6a)
  • Cisco IOS-softwarerelease 15.1(4)M1

Achtergrondinformatie

Cisco IOS-apparaten ondersteunen RFC 1583. Maar NXOS ondersteunt RFC 2328 en er zijn ontwerpen waar dit verschil routinglijnen in het netwerk kan maken wanneer er externe OSPF-routes in het netwerk zijn.

Belangrijke informatie

Het verschil tussen RFC 1583 en RFC 2328, wat betreft de manier waarop de beste route tussen meerdere externe routes moet worden gekozen, wordt in deze paragraaf besproken.

Abstract aan RFC 1583 Sectie 16.4.6

Om type 1 externe paden te vergelijken, kijk naar de som van de afstand aan het verzendadres en de geadverteerde metriek van Type 1 (X+Y).  Om type 2 externe paden te vergelijken, bekijk de geadverteerde Type 2 metriek, en indien nodig de afstand tot de verzendingsadressen.

Als het nieuwe pad korter is, vervangt het de huidige paden in de routing tabel.  Als het nieuwe pad dezelfde kosten heeft, wordt het toegevoegd aan de lijst met paden in de routingtabel.

Opmerking: Als het verzendadres alle nul kosten is, wordt de Autonome System Boundary Router (ASBR) gebruikt om de beste route te kiezen.

Abstract aan RFC 2328 Sectie 16.4.1

Intra-gebiedspaden die niet-backbone-gebieden gebruiken, worden altijd de voorkeur gegeven. De andere paden, backbone trajecten binnen het gebied en paden tussen gebieden, zijn van gelijke voorkeur.

Configureren

Scenario 1

Netwerkdiagram

R3 en R4 herverdelen het zelfde netwerk 172.16.1.0/24 met de zelfde metriek als de OSPF externe E2 route van het type. R6 geeft de voorkeur aan de door R3 geadverteerde route, omdat de metriek vooruit naar ASBR3 lager is dan naar R4 en de volgende-hop voor 172.16.1.0/24 R1 is. (Volgens RFC 1583 is de selectie van de route uitsluitend gebaseerd op 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 geeft de voorkeur aan de door R4 geadverteerde route, ondanks de hogere kosten, omdat het een route binnen het gebied naar ASBR is. De route gaat niet door het backbone gebied en de volgende hop is R6 (volgens 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

Dit veroorzaakt een lus in het netwerk aangezien R6 de pakketten naar R1 en R1 terugstuurt naar 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

Zoals u ziet, de pakketlijnen tussen R1 en R6. Om dit probleem op te lossen, moet u de RFC-compatibiliteit op de NXOS wijzigen.

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 wijst het op de juiste manier op R2 en de lus wordt uit het netwerk verwijderd.

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

Netwerkdiagram

R1 ontvangt een NSSA-externe (Type 7) route van R6 en een externe (Type 5) route van R2 voor hetzelfde voorvoegsel 172.16.1.0/24. R1 geeft de voorkeur aan type 7, hoewel in OSPF type 5 gewoonlijk de voorkeur boven type 7 wordt gegeven.

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.

Aangezien R1 niet de RFC1583Compatibiliteitsopdracht heeft die onder het OSPF-routerproces is geconfigureerd en ADV-router-id (LSA) van de Link State Advertisement (LSA) in gebied 0 (backbone router) altijd op het pad via het niet-backbone gebied kan worden gevonden. In dit geval wordt de volgende-hop geselecteerd in gebied 2 (volgens 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.

Aanbeveling

Er zijn andere ontwerp of netwerkscenario's waar deze compacte kwestie lijnen of suboptimale routing in het netwerk kan veroorzaken als het netwerk NXOS en Cisco IOS heeft die samen met OSPFv2 lopen.

Cisco raadt aan de RFC 1583-compatibiliteitsopdracht in de modus NXOS OSPF-routerconfiguratie te gebruiken als het netwerk apparaten bevat die alleen RFC1583 ondersteunen, dat wil zeggen Cisco IOS.

Verifiëren

Er is momenteel geen verificatieprocedure beschikbaar voor deze configuratie.

Problemen oplossen

Er is momenteel geen specifieke troubleshooting-informatie beschikbaar voor deze configuratie.

Gerelateerde informatie

TAC Authored

Bijgedragen door Cisco-engineers

  • Sumit Kothiyal and Vinod Sharma
    Cisco TAC Engineers.

Was dit document nuttig?

FeedbackFeedback

Contact Cisco

Dit document is van toepassing op deze producten