DMVPN WAN 페일오버: 라우트 정책인가, 터널 종료인가?

WAN 두 개를 가진 DMVPN 허브는 두 가지 방식 중 하나로 페일오버하며, 그 차이는 보이는 것보다 큽니다. 하나는 라우트 정책이 고르는 다음 홉을 바꾸므로 패킷은 계속 흐르고 출구만 달라집니다. 다른 하나는 터널을 관리적으로 종료하여 그 인터페이스의 모든 서비스를 함께 내립니다. 둘 다 옳을 수 있습니다. 서로 다른 질문에 답하기 때문입니다.

결정은 구성보다 먼저 온다

세 가지 조건이 이를 대신 정해 줍니다. 터널 인터페이스가 살아 있는 것에 다른 무엇이 의존하는가, 예컨대 두 번째 DMVPN 프로파일이나 그 상태를 읽는 모니터인가? 또 페일오버해야 하는 트래픽 이 자체 정책을 가지는가, 아니면 전역 라우팅 테이블에 의존하는가? 그리고 운영자에게 명백한 상태 변화가 필요한가, 아니면 조용한 경로 전환이면 충분한가? 이 셋에 답하면 선택은 대개 스스로 정해집니다.

종료가 작동하던 서비스를 내린다면 라우트 정책이 더 작은 조치입니다. 기본 WAN이 내려가 있는 동안 터널이 존재해서는 안 된다는 요구라면, 어떤 정책 항목으로도 표현할 수 없습니다.

답을 적어 두십시오. 구성은 쉬운 부분입니다.

라우트 정책이 실제로 바꾸는 것

정책 기반 라우팅에서는 추적 객체가 다음 홉을 통제할 수 있습니다. 라우트 맵 항목은 후보 다음 홉과 그것을 쓰기 위해 살아 있어야 하는 추적 객체를 지정하며, 그 추적 상태는 IP SLA 프로브에서 옵니다. 객체가 내려가면 항목은 더 이상 일치하지 않고 패킷은 다음 항목이나 일반 라우팅 테이블로 평가됩니다.

마지막 세부가 사람들을 놀라게 합니다. 다음 홉 선택을 멈추는 정책은 보통 트래픽을 막는 대신 정상 라우팅을 허용합니다. 장애 시 블랙홀 이 필요하다면 직접 작성해야 합니다.

구문은 플랫폼과 릴리스마다 다르므로 실제로 실행하는 버전의 안내서를 확인하십시오.

터널 종료가 바꾸는 것

인터페이스를 종료하면 관리 상태가 바뀝니다. 그것에 의존하는 모든 터널, 라우트, 세션이 한꺼번에 내려가며, 터널이 사라져야 하는 대상이라면 바로 원하는 결과입니다. EEM 애플릿이 WAN 문제를 무관한 서비스까지 포함하는 장애로 바꾸는 방식도 같습니다.

이 길을 택한다면 애플릿을 하나의 인터페이스와 하나의 트리거로 제한하고, 이전 관리 상태를 저장하고, 복구 동작을 정의하며, 반복되는 플랩이 루프로 몰지 못하게 하십시오.

하드코딩된 복구 명령은 다른 사람이 수행한 유지보수 종료를 덮어쓸 수도 있습니다.

프로브를 생각하는 경로로 지나가게 하라

현재 최선 경로를 따르는 프로브는 다른 모든 것과 함께 백업 WAN으로 옮겨 간 뒤, 더 이상 그것을 쓰지 않기 때문에 기본을 정상이라고 보고합니다.

프로브를 시험하는 경로의 인터페이스나 출발지 주소에 고정하십시오. 무엇을 겨냥하는지도 확인하십시오. ISP의 다음 홉에 닿는 것은 터널이 존재하는 이유인 서비스에 닿는 것보다 약한 증거입니다. 업 및 다운 지연을 의도적으로 설정하십시오. 짧은 다운 지연은 빠르게 반응하고 플랩하며, 긴 지연은 작은 흔들림을 넘기고 실제 장애를 감춥니다. Cisco의 IOS XE 추적 및 정책 라우팅 안내서 는 지원되는 조합을 문서화하며, 플랫폼의 기능 집합이 그중 무엇을 쓸 수 있는지 결정합니다.

두 지연 값을 추적 객체 옆에 기록하십시오. 그렇지 않으면 왜 그렇게 동작했는지 아무도 알 수 없습니다.

복구를 정한 뒤 검증하라

복구에는 그 자체의 결정이 필요합니다. 임계값을 계속 넘는 링크는 분명히 실패한 링크보다 세션을 더 자주 옮길 수 있고, 옮길 때마다 키 재협상과 애플리케이션 재시도 비용이 듭니다. 안정성 요구를 고르고 지연이 그것을 표현하게 하십시오. 그다음 변경 창에서 프로브 경로를 보이게 둔 채 검증하십시오. 선택된 라우트, 외부 피어 경로, 그리고 애플리케이션이 실제로 한 일입니다.

페일오버는 되는데 애플리케이션이 계속 깨진다면 문제는 라우팅 계층 위에 있고, 아무리 추적해도 고쳐지지 않습니다.

그 창에서 나온 증거를 보관하십시오. 다음 변경은 그것과 비교됩니다.