EIGRP 인접인가 DMVPN 트랜짓인가? 먼저 역할을 확인하세요

인접이 없고, 중간에 있는 라우터가 명백한 용의자처럼 보입니다. 하지만 무죄일 수 있습니다. 외부 터널 패킷을 전달하는 일과 오버레이 라우팅 프로토콜에 참여하는 일은 서로 다른 작업이며, 장비는 후자를 하지 않고 전자만 할 수 있습니다. 아래 다섯 가지 확인을 순서대로 진행하고 처음 실패하는 지점에서 멈추세요.

단계 1: 두 역할을 그립니다

의도한 EIGRP 인접을 두 라우터 사이의 논리적 연결로 그리고, 이어서 그 터널 패킷을 나르는 언더레이 라우터를 그립니다. 같은 장비가 두 목록에 모두 있을 필요는 없으며, 이 목록을 혼동하는 것이 정상적인 트랜짓 라우터가 인접을 깨뜨렸다고 의심받는 가장 흔한 이유입니다.

트랜짓 라우터는 평소의 IP 라우팅과 정책으로 외부 패킷을 전달합니다. 보호된 터널 안에서 운반되는 프로토콜을 실행할 필요가 없고, 그 패킷을 통과시키는 데 EIGRP 프로세스도 필요하지 않습니다.

단계 2: 중간 장비가 무엇을 종단하는지 확인합니다

중간 라우터가 터널을 종단하고 스포크와 EIGRP 인접을 형성해야 한다면 답은 완전히 달라집니다. 그 장비에는 지원되는 오버레이 라우팅 동작이 필요하며, 트랜짓이라고 부른다고 해서 인접 요구 사항이 사라지지는 않습니다. 라우팅 구성보다 터널 구성을 먼저 읽으세요. 그 답이 이후의 모든 확인을 결정합니다.

따라서 첫 번째 진짜 질문은 어떤 프로토콜을 조정할지가 아닙니다. 그 상자가 허브인지, 스포크인지, 순수한 언더레이 홉인지, 끝점 사이에서 프레임을 나르는 Layer 2 서비스인지가 질문입니다.

단계 3: 인접의 제어 평면을 확인합니다

인접이 되어야 하는 각 장비에서 네 가지를 확인하세요. EIGRP 인스턴스와 자율 시스템 번호, 인증 매개변수, 프로세스에 참여하는 인터페이스, 그 인터페이스를 포함하는 네트워크 문입니다. 이 중 하나라도 어긋나면 인터페이스는 올라가고 ping은 계속되지만 인접은 내려간 상태로 남습니다.

RFC 7868은 EIGRP를 멀티캐스트 제어 교환을 사용하는 IP 프로토콜로 설명합니다. 그래서 인접 관계는 중간 라우터가 패킷을 목적지로 라우팅하는 방식으로 대신할 수 있는 것이 아닙니다. 제어 교환이 피어에 도달하거나, 인접이 형성되지 않거나 둘 중 하나입니다.

단계 4: 전송이 제어 교환을 전달하는지 확인합니다

다음으로, 오버레이가 의도한 끝점 사이에서 제어 트래픽을 실제로 나르는지 확인합니다. 피어의 NHRP 매핑과 그 피어에 도달하는 외부 경로를 살펴보고, 터널 인터페이스가 올라가 트래픽을 통과하는지 확인하세요. 언더레이 ping이 성공한다는 것은 외부 경로가 존재한다는 뜻일 뿐, 오버레이 제어 교환이 전달되었다는 뜻은 아닙니다.

투명한 Layer 2 서비스, 지점 간 터널, 다지점 DMVPN 클라우드는 멀티캐스트를 서로 다른 방식으로 전달합니다. 셋이 모두 같다고 가정하지 말고 실제로 배포된 방식에 대해 지원되는 인터페이스, NHRP, 멀티캐스트 모델을 따르세요.

단계 5: 참여할 수 없다면 경계를 다시 설계합니다

필요한 오버레이 장비가 프로토콜을 실행할 수 없다면 설계를 명시적으로 바꾸세요. 그 경계에서 지원되는 프로토콜이나 교환 모델을 사용하거나, 인접이 실제로 서로 대화하는 끝점이 되도록 적절한 종단 간 터널을 마련하세요. 정적 경로가 비참여 장비를 모든 제어 패킷의 중계 역할로 바꿔 준다고 가정하지 마세요.

다이어그램에 각 장비의 역할을 적고 구성과 함께 보관하세요. RFC 7868은 프로토콜 교환을 정의하며, 그 정의가 트랜짓 전달로 인접 관계를 모사할 수 없는 이유의 근거입니다.

다섯 가지 확인을 모두 마친 뒤에도 인접이 실패한다면, 남은 용의자는 터널 인터페이스의 멀티캐스트 처리와 프로토콜 88을 필터링하는 정책 같은 플랫폼 기능입니다. 이는 구체적이고 시험 가능한 원인이며, 중간 라우터를 탓하는 또 한 차례보다 값어치가 있습니다.