OSPF가 PRI, BRI 또는 다이얼러 인터페이스에서 인접성을 형성하지 않는 이유는 무엇입니까?

소개

이 기술 노트에서는 다이얼러 인터페이스가 포인트-투-포인트 링크로 구성된 경우 OSPF 인접성 형성 문제에 대해 설명합니다.

사전 요구 사항

요구 사항

이 문서에 대한 특정 요건이 없습니다.

사용되는 구성 요소

이 문서는 특정 소프트웨어 및 하드웨어 버전으로 한정되지 않습니다.

표기 규칙

문서 규칙에 대한 자세한 내용은 Cisco 기술 팁 표기 규칙을 참조하십시오.

문제

PRI(Primary Rate Interface), BRI(Basic Rate Interface) 및 다이얼러 인터페이스의 OSPF 네트워크 유형은 포인트-투-포인트이므로 인터페이스가 둘 이상의 인접 디바이스로 인접성을 형성할 수 없습니다. PRI, BRI 또는 다이얼러 인터페이스에서 OSPF 인접성을 형성하려고 할 때 일반적으로 발생하는 문제는 인접 디바이스가 exstart/exchange 프로세스에서 중단된다는 것입니다. 예를 살펴보겠습니다.

show ip ospf neighbor 명령을 사용하면 네이버 상태가 "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

RTR-Bs 컨피그레이션은 네트워크 유형이 포인트 투 포인트(point-to-point)임을 보여줍니다.

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) 

debug ip ospf adj 명령을 사용하여 이 상황을 디버깅할 수 있습니다. 위의 그림에서 RTR-B에서 이 명령을 실행하는 동안 몇 가지 샘플 출력을 살펴보겠습니다.

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 

행 1 - 3: RTR-B는 시퀀스 0xB41의 첫 번째 DBD를 3.3.3.2(RTR-A)에 보내고 시퀀스 번호 0x1D06의 3.3.3.2(RTR-A)에서 첫 번째 DBD를 받습니다. 네이버 협상이 아직 완료되지 않았습니다.

행 4 - 6: RTR-B는 3.3.3.2(RTR-A)로부터 RTR-A가 RTR-B의 첫 번째 DBD를 받았음을 나타내는 응답을 받습니다. RTR-B에 더 높은 라우터 ID가 있으므로 RTR-A는 자체적으로 슬레이브를 선택합니다. RTR-A에서 승인을 받은 후 RTR-B는 자체 마스터를 선언하고 데이터가 포함된 첫 번째 DBD를 전송합니다. 시퀀스 번호(0xB42)를 확인합니다. RTR-B는 마스터이므로 시퀀스 번호만 늘릴 수 있습니다.

행 7: RTR-B는 RTR-A에 더 많은 데이터가 있다고 표시되었으므로 RTR-A에서 데이터를 요청합니다(RTR-A에서 수신된 마지막 DBD에서 0x2로 플래그 설정).

행 8: RTR-B는 링크 상태 요청 패킷을 3.3.3.2(RTR-A)에 전송합니다. OSPF 패킷 유형 3입니다. 이 패킷은 일반적으로 네이버의 IP 주소로 전송됩니다. 이 경우 네이버의 IP 주소는 라우터 ID입니다.

행 9 - 11: RTR-B는 완전히 다른 시퀀스 번호와 init 플래그인 0x7 플래그를 가진 슬레이브(RTR-A)로부터 응답을 받습니다. 이 DBD는 다른 라우터(RTR-C일 가능성이 가장 높음)용으로 사용되었지만 RTR-B가 잘못 수신했습니다. RTR-B는 0x7이라는 플래그는 인접성 교환 중에 MS(마스터/슬레이브) 비트를 설정하여 슬레이브가 마스터 비트로 상태를 변경했음을 의미하므로 불일치가 있음을 선언합니다. RTR-B도 순서가 틀려서 시퀀스 번호에 대해 불평합니다. 슬레이브는 항상 마스터의 시퀀스 번호를 따라야 합니다.

행 12: RTR-B는 마스터 및 슬레이브를 다시 선택하기 위해 첫 번째 DBD를 3.3.3.2에 전송하여 인접성을 다시 초기화합니다.

행 13 - 14: RTR-B는 3.3.3.2(RTR-A)에서 DBD를 수신하여 RTR-B의 시퀀스 번호를 인식하지 않고 슬레이브임을 나타냅니다. RTR-B는 마스터 및 슬레이브 협상이 아직 완료되지 않았으므로 이 DBD를 인식하지 못한다고 선언합니다. 이 DBD 패킷은 다른 라우터를 위한 것입니다.

행 15: RTR-B는 이전 DBD에 대해 3.3.3.2(RTR-A)로부터 회신을 수신하지만 RTR-B가 이미 인접성 프로세스를 다시 초기화했으므로 너무 늦습니다.

행 16: RTR-B는 RTR-B가 이미 중단된 "오래된" 인접성을 위한 것이므로 이 DBD를 인식하지 못합니다.

이 과정은 끊임없이 반복될 것이다.

솔루션

RFC 2328 의 섹션 8.1에 따르면 OSPF는 인터페이스가 양방향 상태가 된 후에도 포인트 투 포인트 네트워크 유형에 대한 멀티캐스트 패킷을 전송합니다. RTR-A가 RTR-B와 RTR-C를 모두 사용하여 인접성을 형성하려고 하므로 RTR-B는 RTR-C와 RTR-C에 대한 DBD 패킷을 수신하고 RTR-B에 대한 DBD 패킷을 수신합니다.

이 문제를 해결하려면 모든 라우터의 네트워크 유형을 point-to-multipoint로 변경합니다. 이렇게 하면 OSPF의 동작이 2방향 상태 후에 유니캐스트 패킷을 전송하도록 변경됩니다. 이제 RTR-B는 자신을 목적지로 하는 패킷만 수신하고 RTR-C는 자신을 목적지로 하는 패킷을 수신합니다. 이렇게 네트워크 유형을 변경하면 OSPF 라우터가 PRI, BRI 또는 다이얼러 인터페이스에서 인접성을 형성합니다.

network-type을 변경하려면 ENTER를 눌러 각 행을 종료하며 다음 컨피그레이션 명령을 입력합니다. 예를 들어 RTR-B를 변경하겠습니다.

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 

이제 RTR-B에 대한 show 명령을 살펴보면 네트워크 유형이 point-to-multipoint이고 상태가 꽉 찼는지 확인할 수 있습니다.

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 

관련 정보

• DDR 다이얼러 맵을 사용하여 BRI-BRI 다이얼업 구성
• OSPF 지원 페이지
• Technical Support - Cisco Systems