IP : Open Shortest Path First (OSPF)

Por que o OSPF não forma adjacência em um PRI, BRI ou interface do discador?

19 Setembro 2015 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (22 Agosto 2015) | Feedback


Índice


Introdução

Esta Nota Técnica explica uma edição com a formação de adjacência de OSPF quando as interfaces do discador são configuradas como os link de ponto a ponto.

Pré-requisitos

Requisitos

Não existem requisitos específicos para este documento.

Componentes Utilizados

Este documento não se restringe a versões de software e hardware específicas.

Convenções

Para obter mais informações sobre convenções de documento, consulte as Convenções de dicas técnicas Cisco.

O problema

O tipo de rede OSPF na relação da taxa principal (PRI), Basic Rate Interface (BRI), e as interfaces do discador são pontos a ponto, assim que ele significa que uma relação não pode formar a adjacência com o mais de um vizinho. Um problema comum quando um PRI, um BRI, ou umas interfaces do discador tentam formar uma adjacência de OSPF é o vizinho obtém colado no exstart/processo de intercâmbio. Vamos ver um exemplo.

/image/gif/paws/13691/20a.gif

Usando o comando show ip ospf neighbor, nós podemos ver que o estado vizinho está colado em “EXSTART”.

RTR-A# show ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
3.3.3.3           1   EXSTART/  -     00:00:37    3.3.3.3         Serial6/0:23
3.3.3.4           1   EXSTART/  -     00:00:39    3.3.3.4         Serial6/0:23

RTR-B# show ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
3.3.3.2           1   EXSTART/  -     00:00:36    3.3.3.2         BRI0

RTR-C# show ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
3.3.3.2           1   EXSTART/  -     00:00:35    3.3.3.2         BRI0

A configuração RTR-BS mostra que o tipo de rede é ponto a ponto:

RTR-B# show ip ospf interface bri0 
     BRI0 is up, line protocol is up (spoofing) 
       Internet Address 3.3.3.3/24, Area 2 
       Process ID 1, Router ID 3.3.3.3, Network Type POINT_TO_POINT, Cost: 1562 
       Transmit Delay is 1 sec, State POINT_TO_POINT, 
       Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 
         Hello due in 00:00:06 
       Index 1/1, flood queue length 0 
       Next 0x0(0)/0x0(0) 
       Last flood scan length is 1, maximum is 1 
       Last flood scan time is 0 msec, maximum is 0 msec 
       Neighbor Count is 1, Adjacent neighbor count is 0 
       Suppress hello for 0 neighbor(s) 

Nós podemos debugar esta situação usando o comando debug ip ospf adj. Deixe-nos olhar algum exemplo de saída tomado ao executar este comando no RTR-B na figura acima:

1: Send DBD to 3.3.3.2 on BRI0 seq 0xB41 opt 0x42 flag 0x7 len 32 
2: Rcv DBD from 3.3.3.2 on BRI0 seq 0x1D06 opt 0x42 flag 0x7 len 32 
   mtu 1500 state EXSTART 
3: First DBD and we are not SLAVE 
4: Rcv DBD from 3.3.3.2 on BRI0 seq 0xB41 opt 0x42 flag 0x2 len 92 mtu 
   1500 state EXSTART 
5: NBR Negotiation Done. We are the MASTER 
6: Send DBD to 3.3.3.2 on BRI0 seq 0xB42 opt 0x42 flag 0x3 len 92 
7: Database request to 3.3.3.2 
8: sent LS REQ packet to 3.3.3.2, length 12 
9: Rcv DBD from 3.3.3.2 on BRI0 seq 0x250 opt 0x42 flag 0x7 len 32 
   mtu 1500 state EXCHANGE 
10: EXCHANGE - inconsistent in MASTER/SLAVE 
11: Bad seq received from 3.3.3.2 on BRI0 
12: Send DBD to 3.3.3.2 on BRI0 seq 0x2441 opt 0x42 flag 0x7 len 32 
13: Rcv DBD from 3.3.3.2 on BRI0 seq 0x152C opt 0x42 flag 0x2 len 92 
    mtu 1500 state EXSTART 
14: Unrecognized dbd for EXSTART 
15: Rcv DBD from 3.3.3.2 on BRI0 seq 0xB42 opt 0x42 flag 0x0 len 32 
    mtu 1500 state EXSTART 
16: Unrecognized dbd for EXSTART 

Linhas 1 - 3: O RTR-B envia o primeiro DBD a 3.3.3.2 (RTR-A) com 0xB41 segs. e recebe o primeiro DBD de 3.3.3.2 (RTR-A) com seq# 0x1D06. A negociação vizinha não está ainda completa.

Linhas 4 - 6: O RTR-B recebe uma resposta de 3.3.3.2 (RTR-A) que indica que o RTR-A recebeu o DBD do RTR-b primeiro. Desde que o RTR-B tem o Router ID mais alto, o RTR-A elege-se escravo. Após ter recebido o reconhecimento do RTR-A, o RTR-B declara-se mestre e envia-se o primeiro DBD com dados nele. Note o número de sequência, que é 0xB42. Desde que o RTR-B é o mestre, simplesmente pode incrementar o número de sequência.

Linha 7: O RTR-B pede dados do RTR-A desde que o RTR-A indicou que tem mais dados a enviar (bandeira ajustada a 0x2 no último DBD recebido do RTR-A).

Linha 8: O RTR-B envia um pacote de requisição de estado de enlace a 3.3.3.2 (RTR-A). Este é um tipo 3. do pacote de OSPF. Este pacote é enviado geralmente ao endereço IP de Um ou Mais Servidores Cisco ICM NT do vizinho. Neste caso, o endereço IP de Um ou Mais Servidores Cisco ICM NT do vizinho é seu Router ID.

Alinha 9 - 11: O RTR-B recebe uma resposta do escravo (RTR-A) com um número de sequência completamente diferente e de uma bandeira de 0x7, que é a bandeira do init. Este DBD foi pretendido para um outro roteador (RTR-C mais provável), mas o RTR-B recebeu-o incorretamente. O RTR-B declara há uma discrepância porque uma bandeira de 0x7 significa que o escravo mudou seu estado para dominar ajustando o bit MS (mestre/escravo) durante a troca da adjacência. O RTR-B igualmente queixa-se sobre o número de sequência porque é fora de serviço. O escravo deve sempre seguir o número de sequência do mestre.

Linha 12: O RTR-B re-inicializa a adjacência enviando o primeiro DBD a 3.3.3.2 re-para eleger o mestre e o escravo.

Linhas 13 - 14: O RTR-B recebe um DBD de 3.3.3.2 (RTR-A), indicando que é um escravo, sem reconhecer o número de sequência do RTR-b. O RTR-B declara que não reconhece este DBD desde que a negociação do mestre e do escravo não está completa ainda. Este pacote DBD foi pretendido para um outro roteador.

Linha 15: O RTR-B recebe uma resposta de 3.3.3.2 (RTR-A) para o DBD velho, mas está demasiado atrasado porque o RTR-B re-tem inicializado já o processo adjacente.

Linha 16: O RTR-B não reconhece este DBD porque é para uma adjacência “velha”, que o RTR-B já rasgue para baixo.

Este processo repetirá infinitamente.

A solução

De acordo com a seção 8.1 do RFC 2328leavingcisco.com , o OSPF envia um pacote de transmissão múltipla para um tipo de rede Point-to-Point mesmo depois que a relação consegue o estado bidirecional. Desde que o RTR-A está tentando formar adjacências com ambo o RTR-B e RTR-C, o RTR-B recebe os pacotes DBD significados para o RTR-C e o RTR-C recebe os pacotes DBD significados para o RTR-B.

Para resolver este problema, mude o tipo de rede em todo o Roteadores ao ponto a multiponto. Isto muda o comportamento do OSPF para enviar pacotes do unicast após o estado bidirecional. Agora o RTR-B recebe somente os pacotes destinados para se e o RTR-C recebe os pacotes destinados para se. Mudar o tipo de rede assegura-se de desta maneira que o OSPF Router forme a adjacência em um PRI, em um BRI, ou em uma interface do discador.

Para mudar o tipo de rede, inscreva os seguintes comandos configuration, terminando cada linha pressionando o ENTER. Nós mudaremos o RTR-B como um exemplo.

RTR-B# configure terminal 
RTR-B(config)# int bri 0 
RTR-B(config-if)# ip ospf network point-to-multipoint 
RTR-B(config-if)# end 

Agora se nós olhamos os comandos show para o RTR-B, nós podemos verificar que o tipo de rede é point-to-multipoint e o estado está completo.

RTR-B# show ip ospf interface bri0 
BRI0 is up, line protocol is up (spoofing) 
  Internet Address 3.3.3.3/24, Area 2 
  Process ID 1, Router ID 3.3.3.3, Network Type POINT_TO_MULTIPOINT, Cost: 1562 
  Transmit Delay is 1 sec, State POINT_TO_MULTIPOINT, 
  Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5 
    Hello due in 00:00:16 
  Index 1/1, flood queue length 0 
  Next 0x0(0)/0x0(0) 
  Last flood scan length is 1, maximum is 1 
  Last flood scan time is 0 msec, maximum is 0 msec 
  Neighbor Count is 1, Adjacent neighbor count is 1 
    Adjacent with neighbor 172.16.141.10 
  Suppress hello for 0 neighbor(s) 
  
RTR-B# show ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
172.16.141.10     1   FULL/  -        00:01:36    3.3.3.2         BRI0 

Discussões relacionadas da comunidade de suporte da Cisco

A Comunidade de Suporte da Cisco é um fórum onde você pode perguntar e responder, oferecer sugestões e colaborar com colegas.


Informações Relacionadas


Document ID: 13691