Exemplo de configuração de loop/sub-ideal de roteamento OSPF entre o Cisco IOS e o NXOS para rotas externas

Opções de download

  • PDF     (214.3 KB)
    Ver no Adobe Reader em vários dispositivos
  • ePub     (135.4 KB)
    Ver em vários aplicativos no iPhone, iPad, Android, Sony Reader ou Windows Phone
  • Mobi (Kindle)     (126.3 KB)
    Ver no dispositivo Kindle ou no aplicativo Kindle em vários dispositivos
Atualizado:2 de julho de 2014
ID do documento:117824

Linguagem imparcial

O conjunto de documentação deste produto faz o possível para usar uma linguagem imparcial. Para os fins deste conjunto de documentação, a imparcialidade é definida como uma linguagem que não implica em discriminação baseada em idade, deficiência, gênero, identidade racial, identidade étnica, orientação sexual, status socioeconômico e interseccionalidade. Pode haver exceções na documentação devido à linguagem codificada nas interfaces de usuário do software do produto, linguagem usada com base na documentação de RFP ou linguagem usada por um produto de terceiros referenciado. Saiba mais sobre como a Cisco está usando a linguagem inclusiva.

Sobre esta tradução

A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização. Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional. A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.

Introduction

Este documento descreve como o protocolo OSPF (Open Shortest Path First) entre o Nexus e o recurso Cisco IOS® é implementado no Cisco IOS e no Nexus Operating System (NXOS).

Prerequisites

Requirements

A Cisco recomenda que você tenha conhecimento do protocolo OSPF.

Componentes Utilizados

As informações neste documento são baseadas nestas versões de software e hardware:

  • NXOS versão 6.2(6a)
  • Cisco IOS versão 15.1(4)M1

Informações de Apoio

Os dispositivos Cisco IOS suportam RFC 1583. No entanto, o NXOS suporta RFC 2328 e há designs em que essa diferença pode criar loops de roteamento na rede quando há rotas OSPF externas na rede.

Informações importantes

A diferença entre RFC 1583 e RFC 2328, em relação a como escolher a melhor rota entre várias rotas externas, é discutida nesta seção.

Resumo do RFC 1583 Seção 16.4.6

Para comparar os caminhos externos do Tipo 1, examine a soma da distância para o endereço de encaminhamento e a métrica do Tipo 1 anunciada (X+Y).  Para comparar os caminhos externos do Tipo 2, examine as métricas do Tipo 2 anunciadas e, se necessário, a distância até os endereços de encaminhamento.

Se o novo caminho for menor, ele substituirá os caminhos atuais na entrada da tabela de roteamento.  Se o novo caminho tiver o mesmo custo, ele será adicionado à lista de caminhos da entrada da tabela de roteamento.

Note: Se o endereço de encaminhamento tiver custo zero, o roteador de limite de sistema autônomo (ASBR) será usado para escolher a melhor rota.

Resumo do RFC 2328 Seção 16.4.1

Os caminhos intra-área que usam áreas não backbone são sempre os mais preferenciais. Os outros caminhos, os caminhos de backbone intra-área e os caminhos entre áreas, são de igual preferência.

Configurar

Cenário 1

Diagrama de Rede

R3 e R4 redistribuem a mesma rede 172.16.1.0/24 com a mesma métrica da rota E2 do tipo externo OSPF. R6 prefere a rota anunciada por R3 porque a métrica de encaminhamento para o ASBR R3 é menor que R4 e o próximo salto para 172.16.1.0/24 é R1. (De acordo com o RFC 1583, a seleção do caminho é baseada apenas no custo.)

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 prefere a rota anunciada por R4 apesar do custo mais alto porque é uma rota intra-área para ASBR. A rota não passa pela área de backbone e o próximo salto é R6 (conforme 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

Isso causa um loop na rede, pois R6 envia os pacotes para R1 e R1 os envia de volta para 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

Como você vê, o pacote faz loops entre R1 e R6. Para resolver esse problema, você precisa alterar a compatibilidade de RFC no 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

Agora, R1 o aponta corretamente para R2 e o loop é removido da rede.

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

Cenário 2

Diagrama de Rede

R1 recebe uma rota NSSA-Externa (Tipo 7) de R6 e uma rota Externa (Tipo 5) de R2 para o mesmo prefixo 172.16.1.0/24. O R1 prefere o Tipo 7, embora normalmente no OSPF Tipo 5 seja preferível ao 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.

Como R1 não tem o comando rfc1583compatibility configurado no processo do roteador OSPF e o tipo 5 Link State Advertisement s (LSAs) da rota ADV-router-id está acessível na área 0 (roteador de backbone), o OSPF sempre seleciona o caminho para a rota através da área de não backbone. Nesse caso, o próximo salto é escolhido na área 2 (conforme 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.

Recomendação

Há outros cenários de projeto ou de rede em que esse problema de compatibilidade pode causar loops ou roteamento subótimo na rede se a rede tiver NXOS e Cisco IOS executados junto com OSPFv2.

A Cisco recomenda usar o comando de compatibilidade RFC 1583 no modo de configuração do roteador OSPF NXOS se a rede incluir dispositivos que suportam somente RFC1583, que é o Cisco IOS.

Verificar

No momento, não há procedimento de verificação disponível para esta configuração.

Troubleshoot

Atualmente, não existem informações disponíveis específicas sobre Troubleshooting para esta configuração.

Informações Relacionadas

TAC Authored

Colaborado por engenheiros da Cisco

  • Sumit Kothiyal and Vinod Sharma
    Cisco TAC Engineers.

Este documento lhe foi útil?

FeedbackFeedback

Contate a Cisco

Este documento se refere a estes produtos