계층형 DMVPN: 터널 관계당 하나의 클라우드

지사 스포크가 지역 허브에 성공적으로 등록되었는데도 다른 지역의 서비스에는 도달하지 못합니다. 터널은 활성 상태이고 NHS 상태도 정상으로 보이며, 장애는 계층 경계를 넘는 목적지에서만 나타납니다. 이런 패턴은 보통 어떤 장비가 어떤 DMVPN 클라우드에 참여하는지를 설계가 명시하지 않았음을 뜻하므로, 계층이 직관으로 구축되어 이제 서로 맞지 않습니다.

증상은 계층 경계에서 나타난다

계층 설계에서는 중앙 허브, 여러 지역 허브, 많은 지사 스포크가 각각 위치를 차지합니다. 지역 허브는 하나 이상의 터널 관계를 가질 수 있고, 지사는 모든 중앙 엔드포인트에 등록할 필요가 없습니다. 중요한 경로는 지사에서 지역 서비스로, 지사에서 승인된 다른 지역 스포크로, 지사에서 중앙 목적지로 가는 경로입니다.

다른 경로는 동작하는데 그중 하나가 실패하면, 문제는 거의 항상 끊어진 터널이 아니라 역할 정의의 누락이나 충돌입니다. 의도한 경로를 적고 장비가 실제로 구축한 것과 비교하십시오. 그 비교는 한 시간이 걸리고 일주일의 추측을 막습니다. 설계 문서와 함께 보관하십시오.

하나의 클라우드, 하나의 인터페이스 계약

각 클라우드에 대해 터널 인터페이스, 오버레이 주소 지정, 로컬 언더레이 소스, NHS 및 NBMA 관계, 멀티캐스트 전달, 보호 정책을 기록하십시오. 지역과 중앙 맥락 사이에서 어떤 경로가 넘어가는지도 그 문장이 곧 설계이므로 명시하십시오.

터널 인터페이스가 두 개인 지역 허브에는 주소가 두 개인 계약 하나가 아니라 계약 두 개가 필요합니다. 언더레이 소스, NHRP 도메인, 경로는 인터페이스마다 다를 수 있으며, 이를 합친 문서는 두 번째를 구성하는 사람을 오도합니다.

ID는 로컬 맥락이며 접근 제어가 아니다

NHRP 네트워크 ID와 GRE 키는 전역 설정으로 가장 많이 오해되는 두 값입니다. IOS XE NHRP 가이드는 네트워크 ID를 로컬에서 의미 있는 것으로 설명하므로, 원격 라우터에서 숫자가 같다고 해서 아무것도 인증되지 않으며 한 라우터의 로컬 숫자를 바꾼다고 접근 경계가 생기지 않습니다.

GRE 키는 설계가 사용하는 경우 수신 터널의 맥락을 식별하는 데 도움이 되며, 그 맥락을 공유하는 엔드포인트 사이에서 합의됩니다. 암호가 아니며 IKE 인증이나 라우팅 정책을 대체하지 않습니다. 두 값을 관계 안에서 일치해야 하는 구성 맥락으로 취급하고, 지역을 나누는 보안 제어로 취급하지 마십시오.

계층 사이를 의도적으로 라우팅하십시오

지역 허브가 위쪽으로 광고할 프리픽스와 지사에 제공할 중앙 목적지를 결정하십시오. 그런 다음 요약 경로와 단축 경로가 다이어그램과 크게 다른 전달을 만들 수 있으므로, 각 경로의 실제 다음 홉과 단계별 단축 경로 동작을 확인하십시오.

지역 분리를 강제하려면 라우팅과 접근 정책을 사용하십시오. 지사가 다른 지역에 직접 도달해서는 안 된다면, 그것을 강제하도록 설계된 적 없는 ID에 의존하지 말고 경로와 정책이 그렇게 말해야 합니다. 정책을 ID 옆에 적으십시오. 그렇지 않으면 다음 엔지니어는 숫자가 일을 한다고 가정할 것입니다.

예상치 못한 단축 경로를 진단하십시오

지사가 중앙 엔드포인트와 직접 관계를 만들려고 할 때, ID를 무작위로 바꾸기 전에 해당 지사의 경로, NHRP 매핑, 선택된 터널 맥락을 검사하십시오. 도달 불가, 의도하지 않은 NHS 관계, 합법적이지만 승인되지 않은 단축 경로는 세 가지 다른 수정을 요구합니다.

DMVPN 구성 가이드는 터널과 NHRP 설정을 함께 보여 주며, 바로 그래서 범위를 먼저 종이 위에서 분리해야 합니다. 클라우드 계약을 기록하고 계층 경로를 명시적으로 유지하면, 다음 경계 장애는 가리킬 곳이 생깁니다.