DMVPN 오버레이에서 EIGRP 이웃이 올라오지 않을 때

오버레이의 유니캐스트는 되는데 인접 관계가 계속 실패한다면 NHRP 멀티캐스트 복제, 터널의 EIGRP 정책, IPsec을 세 개의 계층으로 나누어 확인해야 합니다.

터널은 올라와 있고 한 스포크가 다른 스포크를 ping할 수 있는데, 허브에서는 EIGRP 이웃이 하나도 보이지 않습니다. 이 조합은 신비로운 것이 아니라 정상입니다. ping이 증명하는 것은 NHRP를 통한 유니캐스트 도달성이고, EIGRP hello는 멀티캐스트이기 때문입니다. DMVPN 오버레이에서 라우팅 프로토콜의 전달 모델은 두 번째 설정 면이며, 사람들이 건너뛰는 것도 바로 이 면입니다. 첫 번째 면이 이미 건강해 보이기 때문입니다. 아래의 각 계층은 저마다의 명령으로 확인하므로, 한 계층에서 실패해도 목록 맨 위로 되돌아가지 않습니다.

기대하는 인접 관계를 적어 두십시오

어떤 show 명령이든 내리기 전에 짧은 목록을 만드십시오. 어느 스포크가 어느 허브와, 어느 터널 인터페이스를 통해, 어느 EIGRP 자율 시스템에서 피어가 되어야 하는지. 다중 허브 설계는 허브 사이의 틈에서 무너집니다 그리고 목록이 있으면 «EIGRP가 고장 났다»가 아니라 «스포크 3이 허브 2에 등록하지 않는다»가 됩니다. 각 링크에서 기대하는 터널 서브넷도 적어 두십시오. 양 끝의 주소 불일치는 프로토콜 장애와 똑같이 보이기 때문입니다. 목록은 티켓에 적어 두어 다음 교대조가 마지막 스크린샷이 아니라 설계와 비교하도록 하십시오.

NHRP를 확인하고, 다음으로 멀티캐스트 경로를 확인하십시오

등록 상태와 허브가 실제로 보유한 매핑부터 시작하십시오. 허브에 동적 항목이 없는 스포크는 등록되지 않은 것이며, 어떤 라우팅 프로토콜도 그것을 고치지 못합니다. 그다음 스포크가 허브의 NBMA 주소에서 멀티캐스트를 받아들이는지 확인하십시오. 이는 NHS 항목과는 별개의 줄입니다.

show dmvpn
show ip nhrp
show ip nhrp nhs detail
interface Tunnel0
 ip nhrp network-id 1
 ip nhrp nhs 203.0.113.1 nbma 198.51.100.1
 ip nhrp map multicast 198.51.100.1
 tunnel mode gre multipoint
 tunnel key 100

ip nhrp map multicast 줄이 스포크의 hello를 오버레이를 통해 복제 멀티캐스트로 허브에 보내게 하고, 허브의 멀티캐스트가 등록된 스포크에 도달하게 합니다. 이것이 없으면 NHRP를 통한 유니캐스트는 되고 멀티캐스트는 되지 않으며, ping이 증거처럼 보이게 만드는 것이 바로 이 분리입니다. Cisco의 IOS XE DMVPN 가이드 는 각 단계별 허브와 스포크의 멀티캐스트 동작을 문서화하므로, 다른 토폴로지에서 조각을 복사하지 말고 실제로 배포한 단계에 설정을 맞추십시오.

EIGRP 자체의 인터페이스 정책을 확인하십시오

EIGRP 프로세스에 없거나 passive인 터널은 오버레이가 아무리 건강해도 인접 관계를 만들지 못합니다. 인터페이스의 참여 여부와 이웃 테이블을 함께 읽으십시오. 앞의 것이 뒤의 것을 설명합니다.

show ip eigrp interfaces detail Tunnel0
show ip eigrp neighbors detail
show run | section router eigrp
router eigrp 100
 network 10.10.0.0 0.0.0.255
 passive-interface default
 no passive-interface Tunnel0

인증과 메트릭 가중치는 양 끝에서 일치해야 합니다. 모드가 잘못된 키 체인이나 K 값의 불일치는 수신 측에 뚜렷한 syslog 줄 없이 hello를 떨어뜨립니다. 설계가 명시적으로 구성한 유니캐스트 이웃을 쓴다면, 멀티캐스트 설정 위에 겹치지 말고 그 모델을 완전히 따르십시오.

GRE 수송과 IPsec 보호를 분리하십시오

DMVPN은 멀티캐스트를 GRE 안에 실어 나르고, IPsec은 내부 멀티캐스트가 아니라 GRE 패킷을 보호합니다. 그래서 «IPsec은 멀티캐스트를 나를 수 없다»는 통설은 이 설계에서는 틀렸고 진단으로도 쓸모가 없습니다. 터널의 IPsec 프로필, 각 피어의 보안 연관, 터널 인터페이스 상태를 세 가지 별개의 사실로 확인하십시오.

show crypto ipsec sa peer 198.51.100.1
show interfaces Tunnel0 | include line protocol
show ip nhrp multicast

SA가 올라와 있고 카운터가 움직이는데 EIGRP가 내려가 있으면 조사는 스택 위쪽으로 돌아갑니다. 패킷은 보호되고 전달되고 있으므로, 문제는 프로토콜이 어떤 패킷을 보내기로 선택하는가입니다.

이웃 수만이 아니라 경로를 검증하십시오

인접 관계가 만들어지면 그것이 무엇을 광고하고 설치하는지 읽으십시오. 다중 지점 터널에서는 split horizon과 next-hop 동작이 스포크가 허브를 거쳐 다른 스포크에 도달할 수 있는지를 결정하고, 요약은 이웃 관계가 완벽해도 프리픽스를 감출 수 있습니다.

두 사이트 사이의 허용된 애플리케이션으로 마무리하고 그것이 지나는 경로를 확인하십시오. 직접 스포크 간 지름길은 자체 NHRP와 보안 상태를 가진 포워딩 요구 사항이며, 이웃 수를 좋아 보이게 하려고 추가하면 보통 두 번째 문제를 만듭니다.

단계별 설계, 멀티캐스트 매핑, EIGRP 정책을 한곳에 기록하십시오. 다음 엔지니어에게 필요한 것은 설계이지 녹취록이 아닙니다.

관련 글