Viptela SD-WAN 라우터에서 VRRP 액티브-액티브 문제 해결

소개

이 문서에서는 Active-Active 상태에서 중단된 Viptella SD-WAN 라우터 VRRP(Virtual Router Redundancy Protocol)를 해결하는 방법에 대해 설명합니다.

사전 요구 사항

요구 사항

다음 주제에 대한 지식을 보유하고 있으면 유용합니다.

• Meraki 솔루션에 대한 기본 지식
• VRRP에 대한 기본 지식

사용되는 구성 요소

이 문서의 정보는 다음 소프트웨어 및 하드웨어 버전을 기반으로 합니다.

• vEdge 2000, 버전 19.2.3
• MS250-48FP, 버전 MS 12.28

이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다. 이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다. 현재 네트워크가 작동 중인 경우 모든 명령의 잠재적인 영향을 미리 숙지하시기 바랍니다.

토폴로지

증상 1. 활성-활성 상태의 VRP

두 업스트림 게이트웨이 vEdge 디바이스 모두 Meraki 스택 스위치에 아래쪽으로 연결되어 VRP 기본으로 작동합니다.

VE1# show vrrp



MASTER PREFIX

GROUP VRRP OMP ADVERTISEMENT DOWN LIST

VPN IF NAME ID VIRTUAL IP VIRTUAL MAC PRIORITY STATE STATE TIMER TIMER LAST STATE CHANGE TIME TRACK PREFIX LIST STATE

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------

11 10ge0/0.670 1 10.17.69.1 00:00:5e:00:01:01 110 master up 1 3 2021-10-12T02:16:49+00:00 Default_Route_Prefix_List resolved





VE2# show vrrp



MASTER PREFIX

GROUP VRRP OMP ADVERTISEMENT DOWN LIST

VPN IF NAME ID VIRTUAL IP VIRTUAL MAC PRIORITY STATE STATE TIMER TIMER LAST STATE CHANGE TIME TRACK PREFIX LIST STATE

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------

11 10ge0/0.670 1 10.17.69.1 00:00:5e:00:01:01 100 master up 1 3 2021-10-12T02:16:40+00:00 Default_Route_Prefix_List resolved

증상 2. 스위치에 BAD DNS에 대한 경고가 표시됨

VE2에 연결된 스위치 2는 Meraki 대시보드에서 "DNS가 잘못 구성됨"이라는 알림을 받았습니다.

증상 3. AP가 리피터 모드로 전환됨

스위치 2에 연결된 AP는 스위치에 게이트웨이 연결성이 없으므로 리피터 모드로 전환되었습니다.

문제 해결

1. vEdge에서 VRRP 동작을 확인합니다.

두 vEdge에서 "tcpdump"를 수집하고 VRRP 패킷 상태를 확인합니다. 이 경우 VRRP 패킷은 VE1에서 수신하고 전송하는 것을 확인했지만 VE1에서 VE2로 수신되는 VRRP 패킷은 없습니다.  그러나 VE1에서 동일한 메시지가 전송되었습니다. 따라서 게이트웨이 vEdge 기능에 문제가 없는지 확인할 수 있습니다.

VE1에서:

    10.17.69.3 > 224.0.0.18: vrrp 10.17.69.3 > 224.0.0.18: VRRPv2, Advertisement, vrid 1, prio 100, authtype none, intvl 1s, length 20, addrs: 10.17.69.1

08:57:12.744406 80:b7:09:32:e5:02 > 01:00:5e:00:00:12, ethertype IPv4 (0x0800), length 54: (tos 0xc0, ttl 255, id 6968, offset 0, flags [DF], proto VRRP (112), length 40)

    10.17.69.2 > 224.0.0.18: vrrp 10.17.69.2 > 224.0.0.18: VRRPv2, Advertisement, vrid 1, prio 110, authtype none, intvl 1s, length 20, addrs: 10.17.69.1

08:57:13.708034 00:00:5e:00:01:01 > 01:00:5e:00:00:12, ethertype IPv4 (0x0800), length 56: (tos 0xc0, ttl 255, id 29924, offset 0, flags [DF], proto VRRP (112), length 40)

VE2에서:

10.17.69.3 > 224.0.0.18: vrrp 10.17.69.3 > 224.0.0.18: VRRPv2, Advertisement, vrid 1, prio 100, authtype none, intvl 1s, length 20, addrs: 10.17.69.1

08:57:50.644532 80:b7:09:31:82:a2 > 01:00:5e:00:00:12, ethertype IPv4 (0x0800), length 54: (tos 0xc0, ttl 255, id 31817, offset 0, flags [DF], proto VRRP (112), length 40)

VE1(10.17.69.2)에서 VRRP 패킷이 없으므로 VE2는 VE1이 다운되어 VRRP 기본으로 작동하는 것으로 간주합니다.

2. Meraki 스택 동작을 확인합니다.

Meraki 대시보드는 AP4 및 AP3이 잘못된 DNS에 대한 알림을 받는 업링크 스위치2에 연결된 리피터 모드에 있음을 나타냅니다.

스택 상태를 확인하려면 Meraki TAC를 열고 스택 통신 마사지는 Meraki TAC에만 표시됩니다. 확인 시 스택의 기본 및 보조 스위치 간에 스택 내 통신 문제가 발생한 것으로 확인됩니다.

또한 Meraki는 이 문제가 스택 멤버 스위치1(기본)에서 스택 멤버 멤버 2를 통해 VE2에 도달하지 않은 VRRP 패킷에 의해 발생했음을 확인했습니다. 이는 12.28 코드에서 알려진 문제입니다.

솔루션

1. 스택의 모든 멤버 스위치를 다시 로드합니다(임시 수정).
2. Meraki 스위치 펌웨어를 최신 안정적인 빌드로 업그레이드합니다.