VPN에서 OSPF 네이버가 맺어지지 않나요? 이 순서대로 확인하세요

터널은 올라와 있고 인터페이스도 같은 서브넷에 있는데 OSPF는 아무것도 보여주지 않습니다. 대부분 터널은 정상이고 OSPF 요구 사항 하나가 충족되지 않은 경우입니다. 아래 다섯 가지 확인을 순서대로 진행하고 처음 실패하는 지점에서 멈추세요.

각 확인은 증상이 다르므로 목록 자체보다 순서가 더 중요합니다.

확인 1: 링크 모델이 올바른가

포인트 투 포인트 인터페이스와 공유 멀티 액세스 네트워크는 서로 다른 OSPF 환경입니다. 브로드캐스트 LAN 구성을 터널에 복사하는 것이 여기서 가장 흔한 실수입니다. VPN 구현이 지원하는 네트워크 유형을 설정하세요. 라우팅되는 터널이라면 보통 포인트 투 포인트입니다. 그다음 플랫폼이 이 설정에 동의하는지 확인하세요. 일부 구현은 설정을 무시하거나 덮어씁니다.

링크 모델이 틀렸다면 목록의 나머지는 도움이 되지 않습니다.

확인 2: 패킷이 통과하도록 허용되는가

OSPFv2는 IP 프로토콜 89이며 TCP나 UDP 포트가 아니므로, 포트 기준으로 작성한 방화벽 규칙은 이를 조용히 버립니다. Hello는 멀티캐스트 주소로도 가는데 정책이 이를 허용하지 않을 수 있습니다. 터널 양 끝 사이에서 프로토콜 89를 허용한 다음 플랫폼에 명시적인 네이버 설정이 필요한지 확인하세요.

ping만 통과하는 터널은 라우팅 문제가 아니라 정책 문제입니다.

확인 3: 네이버 매개변수가 일치하는가

영역 ID, hello 및 dead 간격, 인증, stub 플래그가 모두 일치해야 합니다. 불일치가 있으면 보통 조용히 실패하는 대신 눈에 보이는 상태로 멈추므로 유용합니다. 의도한 구성이 아니라 양쪽에서 실제로 동작 중인 구성을 비교하세요.

눈에 잘 띄지 않는 것이 MTU 불일치입니다. ExStart에서 데이터베이스 교환을 막기 때문에 네이버는 Full에 도달하지 못합니다.

확인 4: 상태가 무엇을 말하는가

상태가 실패 원인을 알려줍니다. Init은 hello는 도착하지만 이 라우터가 목록에 없다는 뜻으로, 단방향 경로나 멀티캐스트 문제를 가리킵니다. Two-Way는 DR이 아닌 네이버가 있는 브로드캐스트 세그먼트에서는 정상이고 포인트 투 포인트 링크에서는 비정상입니다. ExStart나 Exchange에서 멈추면 MTU나 데이터베이스 설명 문제입니다. Loading은 링크 상태 요청에 응답이 없다는 뜻입니다.

무엇이든 바꾸기 전에 상태를 읽으세요. 목록의 대부분이 그것으로 걸러집니다.

show ip ospf neighbor는 상태, 네이버 주소, dead 타이머를 출력합니다. 그 타이머를 양쪽의 hello 간격과 비교하세요. dead가 hello의 네 배면 정상이고 그 밖의 값은 불일치입니다. 상태 열은 페이지 전체에서 가장 빨리 읽을 수 있는 정보입니다.

확인 5: 실제로 무엇이 광고되는가

Full 인접은 경로가 아닙니다. 어떤 네트워크가 생성되고, 어떤 것이 학습되며, 어떤 것이 라우팅 테이블에 설치되는지 확인하세요. 네트워크 문장이 빠졌거나 사이트 프리픽스를 제외하는 재분배 정책이 있으면 네이버는 정상인데 테이블은 비어 있습니다.

다음으로 호스트 수준 애플리케이션과 반환 경로를 테스트하세요. 라우팅 프로토콜은 방화벽을 열지 않습니다.

IPv6의 경우 OSPFv3에는 자체 요구 사항이 있으며 모든 OSPFv2 설정에 대한 주소 패밀리 토글이 아닙니다. 해당 프로토콜과 플랫폼 문서를 사용하세요. 그리고 연결이 고정 링크 하나뿐이라면 운영해야 할 제어 평면을 추가하기 전에 정적 경로와 비교하세요.