Viptela SD-WAN 라우터의 VRRP 활성-활성 문제 해결

소개

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

사전 요구 사항

요구 사항

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

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

사용되는 구성 요소

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

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

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

토폴로지

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

Meraki 스택 스위치에 하향 연결된 두 업스트림 게이트웨이 vEdge 디바이스는 모두 VRRP 기본 디바이스의 역할을 합니다.

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. 스위치가 잘못된 DNS에 대해 알림

VE2에 연결된 스위치 2에 Meraki 대시보드에서 "DNS가 잘못 구성되었습니다."라는 알림이 표시됩니다.

증상 3. AP가 리피터 모드로 전환됩니다.

스위치 2에 연결된 AP가 리피터 모드로 전환된 이유는 스위치에 게이트웨이 연결 기능이 없기 때문입니다.

문제 해결

1. vEdges에서 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에서 VRRP 패킷(10.17.69.2)이 없으므로 VE2는 VE1이 다운된 것으로 가정하고 VRRP 기본 패킷 역할을 합니다.

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

Meraki 대시보드는 AP4 및 AP3가 업링크 스위치2에 연결된 리피터 모드에 있음을 나타냅니다. 그러면 불량 DNS에 대한 경고가 표시됩니다.

스택 상태를 확인하려면 스택 통신 마사지가 Meraki TAC에만 표시되므로 Meraki TAC를 엽니다. 확인 시 스택의 1차 스위치와 2차 스위치 간 스택 내 통신 문제가 확인됩니다.

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

솔루션

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