Por que o OSPF não forma adjacência em um PRI, BRI ou interface do discador?
Í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.
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 2328
, 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
Feedback