OMP 실패 및 TLOC-Action 트러블슈팅
소개
이 문서에서는 Cisco SD-WAN에서 네트워크 복원력을 제공하기 위한 OMP(Overlay Management Protocol) 실패 시나리오 트러블슈팅 및 모범 사례에 대해 설명합니다.
사전 요구 사항
요구 사항
Cisco SD-WAN(Software Defined Wide Area Network) 솔루션에 대한 지식이 있는 것이 좋습니다.
사용되는 구성 요소
이 문서의 정보는 다음 소프트웨어 및 하드웨어 버전을 기반으로 합니다.
- Cisco IOS Catalyst SD-WAN Manager(vManage라고도 함)
- Cisco IOS Catalyst SD-WAN Validator(vBond라고도 함)
- Cisco IOS Catalyst SD-WAN Controller(vSmart라고도 함)
- vEdge 장치
이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다. 이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다. 네트워크가 가동 중인 경우 모든 명령의 잠재적인 영향을 이해해야 합니다.
OMP 개요
아시다시피 Cisco SD-WAN Edge 디바이스는 Catalyst SD-WAN 컨트롤러와 경로만 공유합니다. 경로가 유효하고 해당 전달 테이블에 설치되려면 다음을 수행합니다.
- TLOC(Next Hop Transport Locator)에 연결할 수 있어야 합니다. 즉, 에지 디바이스에 TLOC에 대한 유효한 경로가 있어야 합니다.
- 가리키는 TLOC입니다. TLOC를 활성화하려면 활성 BFD(Bidirectional Forwarding) 세션이 해당 TLOC와 연결되어야 합니다. BFD 세션은 각 원격 TLOC와 별도의 BFD 세션을 생성하는 각 디바이스에 의해 설정됩니다. BFD 세션이 비활성화되면 Cisco Catalyst SD-WAN Controller는 해당 TLOC를 가리키는 모든 OMP 경로를 포워딩 테이블에서 제거합니다.
- OMP 경로는 최상으로 계산되어야 합니다.
이러한 모든 설명이 논리적이고 간단하지만 장애 시나리오에서 OMP와 EIGRP(Enhanced Interior Gateway Routing Protocol) 및 OSPF(Open Shortest Path First)와 같은 기존 라우팅 프로토콜 간에는 상당한 차이가 있습니다.
EIGRP 실패 시나리오
다음 네트워크에는 세 개의 사이트, 즉 Site1, Site3, Site4가 있으며, 각각 단일 WAN 연결을 사용하는 라우터 RTR1/RTR2, RTR3, RTR4가 있습니다. 기존 라우팅 프로토콜 EIGRP는 IPSec을 통해 실행되며 IP1, IP2, IP3 및 IP4는 각 위치의 WAN 인터페이스 IP 주소입니다.
현재는 RTR3 및 RTR4에 중점을 두고 네트워크를 분리해야 합니다. RTR3에서 10.1.4.0/24에 도달하는 경로는 RTR3-RTR4 간의 직접 터널을 통해 이루어집니다. 터널이 다운되면 이 경우 EIGRP는 어떻게 반응합니까? 터널이 다운되는 즉시 EIGRP가 실행되고 10.1.4.0/24 네트워크에 대한 인접 라우터에 쿼리를 보내며 수신된 응답을 기반으로 검사하고 최적의 경로 계산을 게시하는 라우팅 테이블에 대상에 대한 새 경로를 설치합니다.
이는 기존 라우팅 프로토콜 통합 프로세스에 대한 매우 간단한 설명입니다. 따라서 EIGRP와 같은 일반적인 라우팅 프로토콜에서는 네트워크 재계산을 수행할 수 있습니다.
- 대상에 대한 현재 경로가 다운된 경우
- 대상에 대해 실행 가능한 successor가 없는 경우
- 토폴로지 변경 시
OMP 실패 시나리오
다음은 OMP에 대한 두 가지 실패 시나리오입니다.
- 직접 실패
- 간접 실패
직접 실패
다음 토폴로지에는 단일 전송 연결을 사용하는 사이트가 3개 있습니다.
|
사이트 |
라우터 |
전송 로케이터(TLOC) |
시스템 IP |
서브넷 |
|
SIte1 |
vEdge-1 vEdge 2 |
T1 T2. |
1.1.1.1 2.2.2.2 |
10.1.1.0/24 |
|
사이트 3 |
vEdge-3 |
T3 |
3.3.3.3 |
10.1.3.0/23 |
|
사이트 4 |
vEdge-4 |
T4 |
4.4.4.4 |
10.1.4.0/24 |
Catalyst SD-WAN Controller에서 모든 것이 기본값으로 설정되어 있다고 가정합니다. vEdge 디바이스는 Catalyst SD-WAN 컨트롤러와 직접 라우팅 정보를 공유하며, 컨트롤러는 모든 vEdge 디바이스와 라우팅 정보를 공유합니다. 다음 토폴로지는 모든 라우터의 라우팅 테이블을 보여줍니다.
현재 모든 BFD 세션이 실행 중입니다.
vEdge-DC1# show bfd sessions
SOURCE TLOC REMOTE TLOC DST PUBLIC DST PUBLIC DETECT TX
SYSTEM IP SITE ID STATE COLOR COLOR SOURCE IP IP PORT ENCAP MULTIPLIER INTERVAL(msec) UPTIME TRANSITIONS
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
1.1.1.1 1 up mpls mpls 60.1.1.1 20.1.1.1 12346 ipsec 7 1000 0:00:03:12 0
2.2.2.2 1 up mpls mpls 60.1.1.1 10.10.20.2 12406 ipsec 7 1000 0:06:28:51 0
4.4.4.4 2 up mpls mpls 60.1.1.1 30.1.1.1 12386 ipsec 7 1000 0:00:00:51 0
vEdge-DC1# show omp routes vpn 20 | t
Code:
C -> chosen
I -> installed
Red -> redistributed
Rej -> rejected
L -> looped
R -> resolved
S -> stale
Ext -> extranet
Inv -> invalid
Stg -> staged
IA -> On-demand inactive
U -> TLOC unresolved
PATH ATTRIBUTE
VPN PREFIX FROM PEER ID LABEL STATUS TYPE TLOC IP COLOR ENCAP PREFERENCE
--------------------------------------------------------------------------------------------------------------------------------------
20 10.1.1.0/24 2.2.2.2 43 1005 C,I,R installed 1.1.1.1 mpls ipsec -
2.2.2.2 37 1006 C,I,R installed 2.2.2.2 mpls ipsec -
20 10.1.3.0/24 0.0.0.0 66 1005 C,Red,R installed 3.3.3.3 mpls ipsec -
20 10.1.4.0/24 2.2.2.2 45 1006 C,I,R installed 4.4.4.4 mpls ipsec -
vEdge3과 vEdge4 간의 연결이 비활성화되면 터널이 다운될 때 vEdge3과 vEdge4 모두 BFD 세션도 다운됩니다. 그러면 해당 경로가 'Invalid' 및 'TLOC Unresolved'로 표시됩니다. 다음 출력에서 확인할 수 있습니다.
vEdge3# show bfd sessions
SOURCE TLOC REMOTE TLOC DST PUBLIC DST PUBLIC DETECT TX
SYSTEM IP SITE ID STATE COLOR COLOR SOURCE IP IP PORT ENCAP MULTIPLIER INTERVAL(msec) UPTIME
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
1.1.1.1 1 up mpls mpls 60.1.1.1 20.1.1.1 12386 ipsec 7 1000 0:05:57:27
2.2.2.2 1 up mpls mpls 60.1.1.1 10.10.20.2 12426 ipsec 7 1000 0:05:57:27
4.4.4.4 4 down mpls mpls 60.1.1.1 30.1.1.1 12406 ipsec 7 1000 NA
vEdge3# show omp routes vpn 20 | t
Code:
C -> chosen
I -> installed
Red -> redistributed
Rej -> rejected
L -> looped
R -> resolved
S -> stale
Ext -> extranet
Inv -> invalid
Stg -> staged
IA -> On-demand inactive
U -> TLOC unresolved
PATH ATTRIBUTE
VPN PREFIX FROM PEER ID LABEL STATUS TYPE TLOC IP COLOR ENCAP PREFERENCE
--------------------------------------------------------------------------------------------------------------------------------------
1 10.1.1.0/24 2.2.2.2 43 1005 C,I,R installed 1.1.1.1 mpls ipsec -
2.2.2.2 37 1006 C,I,R installed 2.2.2.2 mpls ipsec -
1 10.1.3.0/24 0.0.0.0 66 1005 C,Red,R installed 3.3.3.3 mpls ipsec -
1 10.1.4.0/24 2.2.2.2 45 1006 Inv,U installed 4.4.4.4 mpls ipsec -
간접 실패
'간접 실패'를 이해하기 위해 제어 정책이 vEdge3에서 vEdge2를 통해 경로 10.1.4.0/24에 대한 다음 홉을 변경하도록 정의되었고, vEdge4에서 10.1.3.0/24에 대한 다음 홉이 vEdge1로 변경되었다고 가정합니다. 즉, vEdge 3과 4 간의 트래픽의 경우 vEdge 2와 1이 중간 홉으로 삽입되었습니다. 다음 다이어그램에서 확인할 수 있습니다.
vEdge2와 vEdge4 간 연결 손실이 발생하는 네트워크 장애가 발생한 경우, T2-T4 간 오버레이 터널이 다운된 동안 vEdge3에는 T2를 통해 10.1.4.0에 대한 유효한 경로가 남아 있습니다. 따라서 vEdge2로 트래픽을 전송합니다. vEdge2에는 vEdge4의 유효한 터널이 없으므로 경로가 더 이상 활성화되지 않으므로 트래픽이 삭제됩니다.
이전 로그와 테스트를 토대로 다음과 같은 결론을 내릴 수 있습니다.
- OMP에서는 라우팅 피어 및 다음 홉에 대한 자동 검색이 없습니다
- 터널이 다운되면 토폴로지 재계산이 수행되지 않습니다
- OMP는 터널이 다운될 때 목적지 접두사로 라우팅합니다. 다음 홉, 즉 TLOC에 대한 연결성만 변경됩니다.
- 직접 오버레이 실패의 경우, 동일한 대상에 대해 여러 터널이 있는 터널 이중화를 제공해야 합니다.
- 오버레이 경로에 중간 홉/홉을 도입하는 동안 각별한 주의를 기울여야 하며, 트래픽 부족을 방지하기 위해 터널 이중화를 제공해야 합니다.
이제 OMP는 기본적으로 오버레이 실패 시 재계산하거나 경로를 재지정하지 않는다는 것을 알 수 있습니다. 이 문제를 해결하기 위해 제어 정책을 통해 'TLOC-Action'이라는 기능을 활성화할 수 있습니다.
TLOC-작업
- Cisco SD-WAN에서 제어 정책 내의 'TLOC 작업'을 사용하면 소스에서 대상까지의 전체 경로에 대한 가시성을 유지하면서 트래픽 포워딩에 사용할 중간 홉(TLOC)의 삽입을 허용할 수 있습니다. 즉, TLOC 작업 옵션을 설정하면 Cisco Catalyst SD-WAN Controller가 최종 대상 장치에 대한 경로를 엔드 투 엔드 추적을 수행할 수 있습니다. 해당 경로가 다운되면 컨트롤러는 이 OMP 경로를 수신한 WAN 에지 라우터에 알립니다.
- 기본 링크 장애 시 백업 경로를 제공하여 SD-WAN 오버레이 네트워크 내에서 네트워크 탄력성 및 내결함성을 향상합니다. 이는 목적지에 도달하기 위해 사용되는 TLOC를 조작하여 트래픽이 네트워크를 통해 라우팅되는 방법을 제어하는 방법입니다.
- TLOC 작업이 정책에 정의된 경우, SD-WAN 컨트롤러에 중간 TLOC를 경로 계산에 삽입하도록 지시합니다. 즉, 필요한 경우 최종 대상에 도달하기 전에 트래픽이 먼저 이 지정된 '백업' 위치로 이동합니다.
- 이 기능은 지정된 TLOC를 통해 다른 경로를 통해 트래픽을 자동으로 리라우팅함으로써 기본 링크가 다운되더라도 연결을 보장하려는 경우에 특히 유용합니다.
다음 토폴로지에서는 vEdge2, vEdge3, vEdge4에 초점을 맞추어 더 잘 이해할 수 있도록 하겠습니다. 현재 정의된 정책이 없으며 vEdge3의 10.1.4.0/24에 대한 데이터 트래픽이 T3과 T4 사이의 직접 터널을 통과하고 있습니다.
내결함성 및 네트워크 복원력을 제공하기 위해 제어 정책은 지정된 TLOC를 통해 다른 경로를 통해 트래픽을 다시 라우팅하도록 구성됩니다.
- vEdge4는 직접 연결된 네트워크 10.1.4.0/24에 대한 OMP 업데이트를 next-hop T4와 함께 Catalyst SD-WAN 컨트롤러로 'T4를 통해 10.1.4.0/24으로 전송합니다.
- 이 경로는 SD-WAN 컨트롤러에 구성된 제어 정책과 일치하며 정의된 정책에 따라 새 TLOC 및 TLOC-Actions를 설정합니다. 즉, 새 '중간 TLOC'를 삽입합니다.
- 컨트롤러는 현재 중간 TLOC(T3, 3.3.3.3) 및 ultimate TLOC(원래 경로의 next-hop-T4)의 두 개의 next-hop을 사용하여 vEdge1에 OMP 경로를 광고합니다. 이렇게 하면 T2 및 T4를 통해 대상 접두사 10.1.4.0/24에 연결할 수 있다는 인텔리전스가 vEdge1에 제공됩니다.
이제 정의된 TLOC-Action에 따라 vEdge1은 10.1.4.0/24에 대한 트래픽을 전달합니다. 따라서 컨트롤 플레인 정책에서 다음 네 가지 유형의 TLOC-Action을 정의할 수 있습니다.
- Strict(기본값) - 'TLOC-Action strict'는 vEdge1과 vEdge4 간의 트래픽이 T3(중간 홉)을 거쳐야 하며 vEdge1과 vEdge4 간의 터널이 다운되면 트래픽이 삭제되어야 함을 정의합니다.
- Primary - 'TLOC-Action primary'는 vEdge1과 vEdge4 간의 트래픽이 중간 홉 T3(3.3.3.3)을 통과하도록 정의하며, 이 오버레이 터널이 다운되면 SD-WAN Controller는 vEdge1과 직접 터널을 통해 T4로 라우팅된 트래픽을 알립니다.
- 백업 - 'TLOC-Action 백업'은 vEdge1과 vEdge4 간의 트래픽이 최종 LOC(원래 경로의 next-hop -T4)로 직접 이동하는 것을 정의하며, vEdge1과 vEdge4 간의 직접 오버레이 터널이 중단되는 경우 SD-WAN 컨트롤러가 vEdge1에 알리고 트래픽이 중간 홉 T3을 거칩니다.
- ECMP(Equal-Cost Multi-Path) - 'TLOC-Action ECMP'는 정상적인 상황에서 vEdge1과 vEdge4 간의 통신이 중간 홉 T3 및 최종 홉 T4를 통해 로드 밸런싱되도록 지정합니다.
개정 이력
| 개정 | 게시 날짜 | 의견 |
|---|---|---|
1.0 |
12-Feb-2025
|
최초 릴리스 |
피드백