| 업데이트 날짜: 2022년 6월 8일 VMware SD-WAN™ Orchestrator 버전 R421-20211216-GA 이 릴리스 정보의 추가 사항 및 업데이트 사항을 정기적으로 확인하십시오. |
릴리스 정보에 있는 내용
릴리스 정보에는 다음과 같은 항목이 포함됩니다.권장 사용
이 릴리스는 릴리스 4.2.0에서 제공되는 기능이 필요한 모든 고객뿐만 아니라 아래에 나열되어 있으나 릴리스 4.2.0 이후에 해결된 문제의 영향을 받은 고객에게 권장됩니다.
호환성
릴리스 4.2.1 Orchestrator, 게이트웨이 및 허브 Edge는 릴리스 3.0.0 이상의 모든 이전 VMware SD-WAN Edge 버전을 지원합니다.
참고: 즉, 3.0.0 이전 릴리스는 지원되지 않습니다.
다음과 같은 상호 운용성 조합은 명시적으로 테스트되었습니다.
| Orchestrator |
게이트웨이 |
Edge |
|
| 허브 |
분기/스포크 |
||
| 4.2.0 |
4.2.0 |
4.2.0 |
4.2.1 |
| 4.2.0 |
4.2.0 |
4.2.1 |
4.2.1 |
| 4.2.1 |
3.4.2 |
3.4.2 |
3.4.2 |
| 4.2.1 |
4.2.1 |
3.4.2 |
3.4.2 |
| 4.2.1 |
4.2.1 |
4.2.1 |
3.4.2 |
| 4.2.1 |
4.2.1 |
3.4.2 |
4.2.1 |
| 4.2.1 |
4.2.1 |
3.4.5 |
3.4.5 |
| 4.2.1 |
4.2.1 |
4.2.1 |
3.4.3, 3.4.4, 3.4.5 |
| 4.2.1 |
4.2.1 |
3.4.3, 3.4.4, 3.4.5 |
4.2.1 |
| 4.2.1 |
3.3.2 P3 |
3.3.2 P3 |
3.3.2 P3 |
| 4.2.1 |
4.2.1 |
3.3.2 P3 |
3.3.2 P3 |
| 4.2.1 |
4.2.1 |
4.2.1 |
3.3.2 P2, 3.3.2 P3 |
| 4.2.1 |
4.2.1 |
3.3.2 P2 |
4.2.1 |
| 4.2.1 |
3.2.2 |
3.2.2 |
3.2.2 |
| 4.2.1 |
4.2.1 |
3.2.2 |
3.2.2 |
| 4.2.1 |
4.2.1 |
4.2.1 |
3.2.2 |
| 4.2.1 |
4.2.1 |
3.2.2 |
4.2.1 |
| 4.2.1 |
4.0.0 |
4.0.0 |
4.0.0 |
| 4.2.1 |
4.0.0 |
4.0.1 |
4.2.1 |
| 4.2.1 |
4.2.1 |
4.0.0 |
4.0.1 |
주의: VMware SD-WAN 릴리스 4.0.x 및 4.2.x는 곧 지원 종료될 예정입니다.
- 릴리스 4.0.x는 2022년 9월 30일에 EOGS(일반 지원 종료)에 도달하고 2022년 12월 31일에는 EOTG(기술 지침 종료)에 도달하게 됩니다.
- 릴리스 4.2.x Orchestrator 및 게이트웨이는 2022년 12월 30일에 EOGS(일반 지원 종료)에 도달하고 2023년 3월 30일에는 EOTG(기술 지침 종료)에 도달하게 됩니다.
- 릴리스 4.2.x Edge는 2023년 6월 30일에 EOGS(일반 지원 종료)에 도달하고 2023년 9월 30일에는 EOTG(기술 지침 종료)에 도달하게 됩니다.
- 자세한 내용은 기술 자료 문서를 참조하십시오. 알림: VMware SD-WAN 릴리스 4.x(88319)의 지원 기간 종료
참고: 릴리스 3.x는 AES-256-GCM을 제대로 지원하지 않았습니다. 즉, AES-256을 사용하는 고객은 항상 GCM을 사용하지 않도록 설정한 Edge(AES-256-CBC)를 사용했습니다. 고객이 AES-256을 사용하는 경우에는 Edge를 4.x 릴리스로 업그레이드하기 전에 Orchestrator에서 명시적으로 GCM 사용 안 함으로 설정해야 합니다. 모든 Edge가 4.x 릴리스를 실행하면 고객이 AES-256-GCM 및 AES-256-CBC 중에서 선택할 수 있습니다.
중요 참고 사항
AS-PATH Prepending에 대한 BGPv4 필터 구성 구분 기호 변경
릴리스 3.x까지는 AS-PATH prepending에 대한 VMware SD-WAN BGPv4 필터 구성이 쉼표 및 공백 기반 구분 기호를 모두 지원합니다. 그러나 릴리스 4.0.0 이상부터 VMware SD-WAN에서는 AS-Path prepending 구성에서 공백 기반 구분 기호만 지원합니다.
3.x에서 4.x로 업그레이드하는 고객은 잘못된 BGP 최상의 경로 선택을 방지하기 위해 업그레이드 전에 AS-PATH prepending 구성을 편집하여 "쉼표를 공백으로 대체"해야 합니다.
Edge 3x00 모델에 대해 확장된 업그레이드 시간
Edge 3x00 모델(예: 3400, 3800 및 3810)에서 이 버전으로 업그레이드하는 데 평균 업그레이드 시간(3~5분)보다 오래 걸릴 수 있습니다. 이는 문제 53676을 해결하는 펌웨어 업그레이드 때문에 발생합니다. Edge 3400 또는 3800이 이전에 릴리스 3.4.5 또는 4.0.2에서 펌웨어를 업그레이드한 경우 Edge는 예상대로 업그레이드됩니다. 자세한 내용은 해결된 문제 53676을 참조하십시오.
VMware SD-WAN Edge 모델 520, 540, 620, 640, 680, 3400, 3800 및 3810에서 자동 협상 기능을 사용하지 않도록 설정할 경우의 제한 사항
VMware SD-WAN Edge 모델 620, 640 또는 680의 GE1 - GE4 포트, Edge 3400, 3800, 또는 3810의 GE3 또는 GE4 포트, 구리 인터페이스가 있는 SFP가 포트 SFP1 또는 SFP2에서 사용될 때 Edge 520/540에서 하드코드 속도 및 이중화에 대한 자동 협상 기능을 사용하지 않도록 설정하는 경우 재부팅 후에도 링크가 작동되지 않는 것을 확인할 수 있습니다.
이 문제는 자동 협상이 링크의 양쪽에서 모두 사용되지는 않을 때 전송 및 수신할 적절한 와이어를 동적으로 감지할 수 없는(자동 MDIX) 제한이 있는 Intel Ethernet Controller i350을 사용하는 나열된 각 Edge 모델에서 발생합니다. 연결의 양쪽이 동일한 와이어에서 전송 및 수신 중인 경우 링크가 감지되지 않습니다. 피어 측도 자동 협상이 없으면 자동 MDIX를 지원하지 않으며 링크가 직선 케이블을 통해 진행되지 않을 경우, 링크가 작동하려면 교차 이더넷 케이블이 필요합니다.
자세한 내용은 KB 문서 VMware SD-WAN Edge 모델 520, 540, 620, 640, 680, 3400, 3800 및 3810 (87208)에서 자동 협상 기능을 사용하지 않도록 설정할 경우의 제한 사항을 참조하십시오.
문서 개정 기록
2021년 4월 9일. 1차 개정판.
2021년 4월 13일. 2차 개정판.
- Edge/게이트웨이의 해결된 문제 섹션에 해결된 문제 53676을 추가했습니다. 이 문제는 원래 릴리스 정보에서 잘못 생략되었습니다.
- 53676에 대한 수정 사항의 일부로 펌웨어를 업그레이드해야 할 때 3x00에서 발생하는 확장된 업그레이드 시간을 해결하기 위해 중요 참고 사항 섹션이 추가되었습니다.
2021년 4월 21일. 3차 개정판.
- 새 Orchestrator 빌드를 추가했습니다. R421-20210415-GA를 가장 최근 빌드로 사용. Orchestrator의 해결된 문제 섹션에 R421-20210415-GA에 대한 새 섹션을 추가했습니다.
- Orchestrator의 R421-20210415-GA 해결된 문제 섹션에 티켓 #61312를 추가했습니다.
2021년 5월 7일. 4차 개정판.
- 테스트된 두 조합을 포함하도록 호환성 테이블을 수정했습니다.
- 릴리스 4.2.0의 Orchestrator 및 게이트웨이는 4.2.0을 사용하는 Hub Edge 및 4.2.1을 사용하는 스포크 Edge와 호환되는 것으로 테스트되었습니다.
- 릴리스 4.2.0의 Orchestrator 및 게이트웨이는 4.2.1을 사용하는 Hub Edge 및 4.2.1을 사용하는 스포크 Edge와 호환되는 것으로 테스트되었습니다.
- 해결된 Edge/게이트웨이 섹션에 해결된 문제 55949 및 56149를 추가했습니다. 이 티켓은 원래 GA 릴리스 정보에 포함되어야 하지만 그렇지 못합니다.
2021년 6월 15일. 5차 개정판.
- Edge/게이트웨이의 해결된 문제 56876은 이 문제의 수정 사항이 Edge 커널 패닉 및 재부팅을 야기하는 메모리 관리와 관련된 문제를 해결하는 두 번째 시나리오를 고려하도록 수정되었습니다.
- 이전 버전에서 잘못 생략되었던 Edge/게이트웨이의 해결된 문제 54001이 추가되었습니다.
2021년 8월 5일. 6차 개정판.
- Edge/게이트웨이 미해결 문제 섹션에 알려진 문제가 6개 추가되었습니다. #60006, #60225, #61361, #62552, #63359, #67790.
2021년 8월 11일. 7차 개정판.
- 새 Edge 버전 R421-20210624-GA-57011-60130을 추가하고 기존 티켓 57011 및 60130을 해당 Edge 빌드에 대해 생성된 새 섹션으로 이동했습니다.
2021년 9월 16일. 8차 개정판.
- 중요 참고 사항 참고: AS-PATH Prepending에 대한 BGPv4 필터 구성 구분 기호 변경이 추가되었습니다.
2021년 12월 21일. 9차 개정판.
- Orchestrator의 해결된 문제에 새로운 Orchestrator 빌드 R421-20211216-GA를 추가했습니다. 이 Orchestrator 빌드는 Log4j 버전 2.16.0으로 업데이트하여 CVE-2021-44228, Apache Log4j 취약점에 업데이트를 적용합니다. Apache Log4j 취약점에 대한 자세한 내용은 VMware Security Advisory VMSA-2021-0028.5를 참조하십시오.
- 중요 참고 사항 참고: VMware SD-WAN Edge 모델 520, 540, 620, 640, 680, 3400, 3800 및 3810에서 자동 협상 기능을 사용하지 않도록 설정할 경우의 제한 사항. 이 참고는 나열된 Edge 모델의 일부 이더넷 포트에서 강제 속도를 구성할 때 발생할 수 있는 문제를 다룹니다.
2022년 3월 24일, 10차 개정판
- Edge/게이트웨이의 알려진 문제 섹션에 문제 #84825를 추가했습니다.
2022년 6월 7일, 11차 개정판
- Edge/게이트웨이의 해결된 문제 섹션에 해결된 문제 #54493을 추가했습니다. 이 문제는 4.2.1 릴리스 정보의 1차 개정판에서 잘못 생략되었습니다.
해결된 문제
해결된 문제는 다음과 같이 그룹화되어 있습니다.
Edge의 해결된 문제버전 R421-20210624-GA-57011-60130에서 해결됨
아래 문제는 Edge 버전 R421-20210407-GA 이후에 해결되었습니다.
- 해결된 문제 57011: 고가용성 토폴로지로 구성된 사이트의 경우 해당 사이트에서 세그먼트를 추가했다가 삭제할 때마다 HA Edge 중 하나에서 데이터부 서비스 장애가 발생하며, 활성 Edge에 서비스 장애가 있는 경우 사이트에서 HA 페일오버도 발생합니다.
세그먼트를 추가한 다음, HA 사이트에서 삭제하면 부실 세그먼트가 발생할 수 있습니다(예: 삭제된 세그먼트가 HA 쌍의 Edge 중 하나에 계속 표시될 수 있습니다). HA Edge 간의 세그먼트 정보 불일치로 인해, 부실 세그먼트에 대한 모든 이벤트가 다른 Edge로 전송되면서 데이터부 서비스 장애가 발생하고, 활성 Edge에서 서비스 장애가 발생할 경우 HA 페일오버가 발생할 수 있으며, 페일오버 후 생성되는 진단 번들에서 확인되는 코어 덤프가 생성될 수 있습니다. 이 문제에 대한 해결 방법은 없습니다.
- 해결된 문제 60130: 사이트에서 높은 패킷 손실 및 연결 문제가 간헐적으로 발생할 수 있습니다.
이 문제의 원인은 MAC 주소 00:00:00:00을 전달하는 동안 Edge에 디바이스에 대한 ARP 확인이 성공했음을 알리는 ARP 해결을 확인하기 API 때문에 발생했습니다. 이 주소는 ARP 캐시에 유지되어 MAC이 0으로 나열된 디바이스용 패킷이 모두 삭제됩니다. 이 문제에서는 MAC 주소가 0인 성공적인 ARP의 많은 인스턴스가 전달되어 높은 패킷 손실 및 연결 문제가 발생할 수 있습니다.
이 수정 사항은 흐름에서 캐시된 MAC 주소 값 관련 문제(문제의 가장 일반적인 원인)는 해결하지만, ARP가 자체 캐시하여 0개의 MAC을 반환하는 드문 시나리오는 해결하지 않습니다. 이 문제는 62552에서 해결될 것입니다. 이 문제는 수정 사항이 적용된 Edge 이미지를 사용하는 것 외에 다른 해결 방법이 없습니다.
버전 R421-20210407-GA에서 해결됨
아래 문제는 Edge 버전 R420-20201218-GA 및 게이트웨이 버전 R420-20210208-GA-53243-54800 이후에 해결되었습니다.
- 해결된 문제 51025: VMware SD-WAN Edge에서 WAN 링크가 플래핑되는 경우(실행 및 종료 상태가 빠르게 바뀜) 라우팅된 인터페이스의 기본 게이트웨이에 대한 경로 테이블 항목이 제거되고 다시 적용되지 않을 수 있습니다.
Edge에서 이 문제가 발생하면 링크 플래핑이 발생하고 기본 게이트웨이 경로 항목이 해당 링크를 사용하는 인터페이스에 대해 제거되며 결과적으로 인터페이스에 대한 경로 테이블이 빈 상태가 됩니다. 그러나 빈 경로 테이블로 남아 있는 경우 Linux 연결 추적(conntrack)은 기본적으로 다음 테이블로 라우팅되므로 모든 패킷이 잘못 라우팅된 인터페이스를 통해 송신됩니다.
- 해결된 문제 52102: 허브/스포크 토폴로지를 사용하는 엔터프라이즈의 경우, 지정된 튜플에 대해 허브 Edge 페일오버에서 복구할 때 기존 흐름이 VMware SD-WAN 스포크 Edge에서 삭제됩니다.
기본 허브 Edge가 페일오버에서 복구되는 경우 이벤트 시퀀스로 인해 이 문제가 발생합니다.
1. 기본 허브 Edge가 종료되면 RIB의 경로를 유지하면서 해당 기본 허브 Edge의 FIB에서 경로가 제거됩니다.
2. 이제 기존 흐름이 보조 허브 Edge로 전환됩니다.
3. 기본 허브가 백업되면 스포크 Edge에서 기본 허브 간에 터널이 즉시 설정됩니다.
4. 이전에 게이트웨이를 통해 기본 허브에서 학습된 RIB의 경로가 검색되고 경로는 이 기본 허브를 가리키는 FIB에 설치됩니다.
5. 기본 허브는 해당 BGP 인접 네트워크에서 경로를 검색하지 못했지만 트래픽은 기본 허브로 다시 전환됩니다.
6. 이로 인해 경로 조회를 통해 기본 경로와 일치하는지 확인되고 반환 트래픽이 백홀 플래그로 표시됩니다.
7. 스포크 Edge는 백홀 플래그가 설정된 반환 트래픽을 예상하지 않으며, 이로 인해 트래픽이 손실됩니다.이 수정 사항을 적용하지 않으면 허브 Edge에서 지정된 튜플에 대한 원격 진단 [흐름 플러시(Flush Flows)]를 실행하여 트래픽이 복원됩니다.
- 해결된 문제 53415: ENI(Edge Network Intelligence)를 사용하도록 설정한 고객 엔터프라이즈에서 엔터프라이즈의 VMware SD-WAN Edge에 Wi-Fi가 사용하도록 설정되어 있는 경우 ENI 페이지에 Wi-Fi Access Point에 대한 잘못된 MAC 주소가 표시될 수 있으며 Access Point IP가 160.254.3.1로 표시됩니다.
이 문제는 Wi-Fi Access Point MAC 주소가 'selfMacAddress' 값으로 잘못 구성되고 ENI 페이지에서 160.254.3.1에 대해 항상 Access Point IP 주소가 구성되기 때문에 발생합니다. 이 버그 수정은 Wi-Fi 인터페이스 wlan0 및 분석 인터페이스의 IP 주소에서 MAC 주소를 파생합니다.
- 해결된 문제 53477: 고가용성 토폴로지에 구성된 VMware SD-WAN Edge를 다른 구성 프로필로 이동하면 Edge 환경에서 Edge 서비스가 반복적으로 다시 시작됩니다.
이 문제의 경우 HA Edge 중 하나가 다른 HA Edge보다 더 많은 LAN 또는 WAN 인터페이스를 사용하도록 구성되어 있으며(예: WAN 포트가 Edge 중 하나에서 사용하지 않도록 설정됨) 이러한 Edge를 다른 프로필로 이동하면 Edge 서비스가 지속적으로 다시 시작됩니다.
- 해결된 문제 53651: 향상된 고가용성 토폴로지가 있는 고객 사이트에서 VMware SD-WAN Edge 디바이스 설정의 구성을 변경함으로써 Edge 서비스를 다시 시작해야 하는 상황이 되면 두 번의 HA 페일오버가 연속적으로 발생할 수 있습니다.
디바이스 설정 구성 변경으로 인해 Edge 서비스를 다시 시작해야 하는 경우 HA 모듈은 구성을 처리하는 동안 Edge 서비스가 다시 시작되기 전에 LAN/WAN 수를 VMware SD-WAN Gateway로 잘못 업데이트하게 됩니다. 따라서 초기 HA 페일오버가 발생하고 현재 활성 Edge의 서비스가 대기로 강등되면서 다시 시작될 때 게이트웨이는 새 대기 Edge의 LAN/WAN 수가 적절하다고 착각하고 새로 승격된 활성 Edge에 페일오버 명령을 전송하여 두 번째 페일오버를 야기합니다.
참고: 서비스 다시 시작을 트리거할 수 있는 Edge 구성 변경 목록은 KB 문서 VMware SD-WAN Edge 구성 변경으로 인해 서비스 다시 시작이 트리거될 수 있음(60247)을 참조하십시오.
- 해결된 문제 53676: VMware SD-WAN Edge 3x00 플랫폼에서 입력 전압이 매우 짧은 기간(4밀리초) 불안정해져도 Edge가 다시 부팅될 수 있습니다.
이 문제는 일반적으로 UPS(무정전 전력 공급 장치)를 사용할 때 라인에서 배터리로 전환하면서 출력 전압이 약간만 불안정해져도 나타날 수 있습니다. 이 문제를 위한 수정 사항은 Edge 다시 부팅 전에 20~30ms의 전압 불안정 상태를 허용하도록 Edge의 펌웨어를 업그레이드합니다.
참고: 릴리스 3.4.5 또는 4.0.2를 사용하는 Edge의 펌웨어가 이전에 업그레이드되지 않은 경우 3x00의 펌웨어를 업그레이드할 때 Edge의 업그레이드 시간이 3~5분으로 연장됩니다.
이 수정 사항이 적용되지 않은 Edge 3x00 모델의 경우 고객의 유일한 선택 옵션은 출력 전압이 불안정해지지 않으면서 입력을 전환할 수 있는 좀 더 정교한 UPS를 사용하는 것입니다.
- 해결된 문제 53789: ESXi에서 실행 중인 VMware SD-WAN 가상 Edge에서 /var/log/messages가 30초마다 의사 오류 메시지로 채워집니다.
올바르지 않은 오류 메시지가 GuestInfoGetDiskDevice: Missing disk device name; VMDK mapping unavailable for "/", fsName: "/dev/root"로 표시되고 /var/log/messages에 항상 로깅되어 /var/log/messages 및 이의 저장된 대응 파일 /velocloud/log/messages*를 채우므로 영향을 받은 Edge의 로그를 참조할 때 더 중요한 메시지가 순차적으로 삭제됩니다.
- 해결된 문제 53929: 향상된 고가용성 토폴로지가 있는 고객 사이트에서 HA 페일오버 후 '게이트웨이를 통한 클라우드(Cloud via Gateway)' 흐름이 '클라우드로 직접(Direct to Cloud)' 경로로 전환됩니다.
HA 페일오버 후 트래픽이 VMware SD-WAN Edge에 도달할 때 VMware SD-WAN Gateway에 대한 경로가 작동하지 않으면 트래픽이 '게이트웨이를 통한 클라우드(Cloud via Gateway)’ 대신 '클라우드로 직접(Direct to Cloud)'으로 전환됩니다. 이러한 문제는 직접 트래픽에서는 이러한 최적화를 사용하지 않기 때문에 실시간 트래픽(예: 음성 및 화상)과 같은 동적 다중 경로 최적화를 사용하는 흐름에 상당한 영향을 미칠 수 있습니다.
- 해결된 문제 54001: SFP 인터페이스에서 Tx 대기열이 중단 후 VMware Edge가 트래픽을 전송할 수 없습니다.
드문 경우지만 Edge가 잘못된 크기의 패킷(17바이트보다 작거나 1526바이트보다 큼)을 DPDK로 전송하면 전송 대기열이 중단되고 Edge에서 추가 트래픽을 전달할 수 없게 됩니다. Edge를 다시 부팅하면 문제가 일시적으로 해결되지만 잘못된 크기의 패킷이 Edge 서비스에서 DPDK로 전송되면 이 문제가 다시 발생될 수 있습니다. 이 수정 사항이 있는 수준으로 업그레이드해야만 이 문제가 방지됩니다.
- 해결된 문제 54493: 운영자 또는 파트너 관리자는 VMware SD-WAN Gateway에서 Edge 트래픽에 대한 핸드오프 대기열 손실 개수가 증가하는 것을 관찰할 수 있습니다.
이 문제의 경우 게이트웨이에는 CPU 활용률 문제 또는 DPDK 삭제는 발생하지 않습니다. 이 문제는 제어부 이벤트(예: 경로 다시 계산)에 의해 트리거되고 게이트웨이는 게이트웨이 파이프라인의 다른 스레드로 전달되는 동안 Edge 패킷을 삭제하기 시작합니다. 이 문제는 패킷 버퍼링을 위한 대기열 크기가 충분하지 않기 때문에 발생합니다.
- 해결된 문제 54694: 고객이 SNMP 폴링을 사용하는 경우 SNMP 모니터링은 아웃바운드 트래픽에 대한 부정확한 측정값을 제공합니다.
IF-MIB::ifHCOutOctets에 대한 SNMP 호출은 TX 바이트 대신 TX 패킷을 전달하기 때문에 고객이 엔터프라이즈 모니터링을 수행하는 능력에 영향을 미치는 아웃바운드 8진수 개수가 부정확해집니다. 이 문제는 Tx 바이트와 대조적으로 Tx 패킷을 모니터링하는 snmpagent 프로세스로 인해 발생합니다.
- 해결된 문제 55949: 일부 시나리오에서는 게이트웨이를 통한 비 SD-WAN 대상(NSD) 터널이 종료되고 일정 기간 동안 복구되지 않습니다.
VMware SD-WAN Gateway가 다른 NSD 대상에 대해 IKE 키 재생성을 트리거하고 협상 중에 네트워킹 문제로 인해 키 재생성 시도가 실패하면 IKE 키 재생성이 계속 재시도됩니다. 링크가 다시 설정되면 DPD(데드 피어 감지) 이벤트가 새로 생성된 1단계 SA(보안 연결)를 삭제하게 됩니다. 이로 인해 일부 피어와 함께 IPsec SA가 삭제됩니다. 이러한 현상은 Zscaler에서 가장 두드러지게 나타납니다. 피어가 IPsec SA를 삭제하면 게이트웨이에서 IPsec SA를 감지할 수 없게 되며 다음 키 재생성 시간까지 터널이 종료됩니다. 이 수정 사항을 적용하지 않을 경우 이 키 재생성을 강제로 수행하는 한 가지 방법은 VMware SD-WAN Orchestrator를 통해 영향을 받는 NSD를 사용하지 않도록 설정했다가 다시 사용하도록 설정하여 터널을 반송하는 것입니다.
- 해결된 문제 56149: BGP를 사용하는 고객 엔터프라이즈에서 DCC(동적 비용 계산)를 사용하도록 설정한 후 언더레이 경로에 대한 BGP 경로가 플래핑될 경우 VMware SD-WAN Edge가 자동 수정된 경로에 대한 경로 기본 설정 값을 잘못 표시할 수 있습니다.
잘못된 원격 경로 기본 설정으로 인해 고객에게 미치는 영향은 비대칭 라우팅이며, 이로 인해 지연 시간이 길어지고 모든 고객 애플리케이션의 성능이 저하될 수 있습니다. DCC를 사용하도록 설정한 후 경로에서 새 RIB(라우팅 정보 기반) 기본 설정 값을 업데이트하고, 새 RIB 기본 설정 값을 VMware SD-WAN Gateway로 다시 애드버타이즈해야 합니다. 그러면 해당 값이 모든 Edge로 전달됩니다. 이 문제의 원인은 경로가 자동으로 수정될 때 이 RIB 기본 설정이 이전의 DCC 전 값을 유지하는 피어 Edge의 FIB 테이블에서 업데이트되지 않는 것입니다.
- 해결된 문제 56346: VMware SD-WAN Edge의 모니터링(Monitor) > 시스템(System) 페이지를 표시할 때 핸드오프 대기열 손실 개수가 확인될 수 있습니다.
VCRP(VeloCloud Route Protocol) 경로 이벤트 업데이트로 인해 VCMP(VeloCloud 관리부) 데이터 스레드에서 핸드오프 대기열 손실 개수가 발생합니다. 이러한 문제는 경로 업데이트가 수신될 때 해당 세그먼트의 모든 경로가 무효화되기 때문에 발생합니다. 이로 인해 데이터 경로에서 새로운 경로가 조회됩니다. 경로 조회의 일부로 호출되는 특정 기능은 비용이 많이 드는 해시 열거 작업을 수행하므로 VCMP 데이터 스레드 활용률이 40% 증가합니다. 현장에서 이 문제가 발견된 경우 핸드오프 대기열 손실 개수가 충분하지 않아 네트워크 성능에 영향을 주지 않습니다.
- 해결된 문제 56483: VMware SD-WAN Orchestrator의 모니터링(Monitor) > 전송(Transport) 화면 아래에 있는 WAN 링크 실시간 모니터링에 패킷 손실, 지터 및 지연 시간이 표시되지 않습니다.
사용자는 그래프가 직선으로 표시되므로 모니터링(Monitor) > 전송(Transport) 아래에서 특정 WAN 링크의 패킷 손실, 지터 또는 지연 시간에 대한 실시간 데이터를 얻을 수 없습니다. 또한 모니터링(Monitor) > Edge > 개요(Overview) 화면을 확인하면 손실, 지터 및 지연 시간에 대한 모든 값이 '0'으로 표시됩니다. 기록 통계는 모니터링(Monitor) > 전송(Transport)에 올바르게 표시되며, 이 문제는 "라이브 모드" 통계에만 영향을 줍니다.
- 해결된 문제 58535: 고객이 상태 저장 방화벽을 구성했으며 네트워크 및 플러드 보호(Network & Flood Protection)에서 거부 목록도 구성한 경우 거부 목록(Denylist)은 자동으로 새 연결에 대해 가장 적극적인 설정으로 설정되고 상태 저장 방화벽은 모든 새 연결을 차단합니다.
이 문제는 상태 저장 방화벽을 사용하는 고객에게 심각한 영향을 미치며 거부 목록(Denylist) 기능을 사용할 수 없게 됩니다. 거부 목록(Denylist) 기능을 사용하도록 설정하면 방화벽 이벤트가 다음 로그로 채워집니다. "FLOOD_ATTACK_DETECTED" and "Blacklisting source: xxx.xxx.x.x exceeded CPS limit : 0 per source". 여기서 IP 주소는 Edge 관리의 IP 주소이고 CPS는 초당 연결 수입니다. 새 연결 임계값(New Connection Threshold) 제한이 0%로 설정되어 모든 연결 시도가 거부 목록을 트리거함으로써 모든 연결이 차단됩니다. 새 연결 임계값(New Connection Threshold)의 기본값은 25%입니다.
- 해결된 문제 56876: VMware SD-WAN Edge에서 메모리 관리와 관련된 문제가 발생하여 커널 패닉을 트리거함으로써 Edge가 재부팅될 수 있습니다.
이 해결된 문제에는 커널 패닉을 트리거하는 Edge의 메모리 관리와 관련된 두 가지 시나리오에 대한 수정 사항이 포함되어 있습니다.
- Edge가 동적 분기 간을 사용하는 첫 번째 시나리오에서는 동적 터널이 생성되면 피어별 카운터를 저장하기 위해 소량이 메모리가 예약됩니다. 동적 터널이 삭제되면 다음번에 동일한 피어가 연결될 때 작동 시간을 최적화하기 위해 이 메모리가 정리되지 않습니다. 시간이 경과하면서 많은 수의 다른 대상에 연결되는 작은 Edge(예: Edge 500, 510, 520, 610)에서는 결과적으로 사용 가능한 메모리가 소진될 수 있으며 커널 패닉과 Edge 재부팅이 트리거될 수 있습니다. 이 수정 사항을 적용하지 않은 상태로 VMware SD-WAN Orchestrator에서 Edge의 모니터링(Monitor) > 시스템(System) 화면을 확인할 때 메모리 사용량이 상태 통계의 90%를 넘으면 사용자는 Edge의 서비스를 사전 대처용으로 다시 시작해야 합니다.
- 동적 분기 간으로 인해 발생하는 메모리 누수를 해결하는 동안 malloc_trim(조각난 메모리를 정리하는 프로세스)가 제대로 호출되지 못하는 것이 확인되었으며, 이를 수정하기 위해 이 프로세스도 수정되었습니다. malloc_trim을 올바르게 호출하지 못할 경우 다른 문제가 발생할 수 있고 모든 Edge(더 작은 Edge만이 아님)에 영향을 줄 수 있으며, Edge가 동적 분기 간을 사용할 필요도 없고, 모니터링(Monitor) > 시스템(System)에 메모리 사용량이 90%를 초과하는 것으로 표시되지도 않습니다. 이 시나리오는 Edge에 많은 수의 흐름이 있는 경우 발생할 가능성이 훨씬 높습니다.
- 해결된 문제 56931: Edge를 통한 비 SD-WAN 대상(NSD)를 구성한 고객 사이트의 경우 VMware SD-WAN Orchestrator UI에 잘못된 Edge 상태 통계를 표시할 수 있습니다.
Edge에서 NSD가 구성되면 SD-WAN 서비스는 재부팅 후 처음으로 시작 시간이 0인 상태 통계를 Edge에서 Orchestrator로 전송합니다. 이로 인해 Edge가 재부팅된 후 Orchestrator에 잘못된 데이터가 표시됩니다.
- 해결된 문제 57063: API 호출의 시작 및 종료 시간이 VMware SD-WAN Edge가 VMware SD-WAN Orchestrator로 데이터를 내보내는 시간과 정확히 겹치는 경우 다음 두 가지 동작이 관찰됩니다. a) Orchestrator UI 또는 SDK 클라이언트에서 실행된 링크 메트릭 API 호출은 일반적인 값보다 더 높은 값이 응답에서 반환되는 것으로 확인됩니다. b) Orchestrator UI 또는 SDK 클라이언트에서 실행된 링크 시리즈 API 호출은 시리즈 값이 평소보다 높은 마지막 시간을 확인합니다.
Orchestrator UI에서 모니터링(Monitor) > 전송(Transport) 탭을 확인하거나 SDK 클라이언트가 getEdgeLinkMetrics, getEdgeLinkSeries, getAggregateLinkMetrics API 호출을 수행할 때 이러한 불일치가 관찰될 수 있습니다. 어떤 경우든, 증상(Symptom) 설명에 지정된 요구 사항을 고려할 때 실제로 이러한 상황은 매우 드물게 확인됩니다.
Orchestrator 버전 R421-20211216-GA
Orchestrator 버전 R421-20211216-GA는 2021년 12월 20일에 릴리스되었습니다. 이 Orchestrator 빌드는 Log4j 버전 2.16.0으로 업데이트하여 CVE-2021-44228, Apache Log4j 취약점에 업데이트를 적용합니다. Apache Log4j 취약점에 대한 자세한 내용은 VMware Security Advisory VMSA-2021-0028.5를 참조하십시오.
___________________________________________________________________
버전 R421-20210415-GA에서 해결됨
아래 문제는 Orchestrator 버전 R421-20210326-GA 이후에 해결되었습니다.
- 해결된 문제 61312: VMware SD-WAN Orchestrator는 경로가 더 이상 업데이트되지 않고 Orchestrator의 CPU 사용률이 100%에 가까워질 때 문제가 발생할 수 있습니다. 이 문제는 Orchestrator가 업그레이드된 후에 특히 두드러집니다.
이 문제는 Edge가 Orchestrator의 라우팅 API에 2K 이상의 경로 업데이트를 보낼 때 확인됩니다. Orchestrator가 60초 이내에 특정 API 호출을 통해 전송된 경로 집합 전체를 처리하지 못하는 시나리오에서는 해당 호출에 대한 시간이 초과되어 API 호출이 완전히 거부됩니다. Edge는 이러한 거부를 수신하면 동일한 2K 이상의 경로를 Orchestrator에 다시 푸시하려고 시도하므로 Orchestrator의 vCPU 리소스를 오버로드하는 루프를 생성하게 되는 이전과 동일한 시나리오를 발생합니다. 이 문제가 있는 경우 경로 업데이트가 처리되지 못할 수 있습니다.
이 문제를 해결하기 위해 다음 두 개의 시스템 속성이 추가되었습니다.
edge.learnedRoute.maxRoutePerCall 이 속성은 Edge에서 제한된 수의 경로만 처리하도록 보장합니다. 속성값이 '200'이면 Edge 요청당 200개 경로가 처리됩니다. 그러면 제시간에 Edge로 승인이 전송됩니다.
vco.learnedRoute.simultaneous.maxQueue 이 속성은 구성된 수의 Edge만 한 번에 경로 요청을 대기할 수 있도록 합니다. 이 속성값이 '8'이면 한 번에 8개의 Edge만 경로 요청을 보낼 수 있으며, 구성된 값을 초과하는 Edge는 경로가 처리되기 전에 즉시 거부됩니다.
______________________________________
버전 R421-20210326-GA에서 해결됨
아래 문제는 Orchestrator 버전 R420-20210306-GA 이후에 해결되었습니다.
- 문제 20900: MaxMind 지리적 위치 서비스가 사용하도록 설정되고 MaxMind 서버에 연결할 수 없으면 새로운 VMware SD-WAN Edge 활성화가 작동하지 않습니다.
Edge는 활성화하기 위해 VMware SD-WAN Orchestrator에 대한 HTTPS 연결을 생성합니다. 요청의 기본 시간 초과는 120초이며 프록시된 연결의 경우 60초입니다. Orchestrator가 Edge(IPv4 원격 주소)의 지리적 위치를 지정하려고 하면 활성화를 진행하기 위해 업로드가 Maxmind 서비스의 응답을 기다립니다. 따라서 60초 후에 NGINX가 업로드 서비스의 응답을 위해 중지된 후 연결을 닫습니다. 따라서 NGINX에서 504 시간 초과가 발생하므로 활성화가 실패합니다.
새 시스템 속성인 service.maxmind.timeout.seconds를 사용하는 경우 사용자 지정 시간 초과를 사용하여 Maxmind API 호출이 수행됩니다. 이 시간 초과에 도달하면 호출이 수행되면서 활성화 워크플로로 진행되고 Edge가 성공적으로 활성화됩니다.
- 해결된 문제 49997: VMware Edge Network Intelligence 분석 모드가 VMware SD-WAN Orchestrator에서 사용하도록 설정된 상태에서 새 운영자를 생성할 경우 해당 운영자가 Orchestrator UI의 분석 섹션에 연결할 수 없습니다.
분석 모드를 활성화한 후 생성된 운영자는 지원 액세스를 사용하도록 설정한 모든 엔터프라이즈 고객의 VMware Edge Network Intelligence UI에 액세스할 수 있습니다(이 문제에 해당하지 않음).
- 해결된 문제 52379: VMware SD-WAN Edge가 구성된 지연 간격 내에 복구되면 VMware SD-WAN Orchestrator는 'Edge 종료(Edge Down)' 경고 이메일을 전송합니다.
관리자는 Edge가 해당 경고를 트리거하기 전에 특정 기간 동안 Edge 종료를 허용하도록 지연을 구성한 경우에도 네트워크에서 Edge가 종료된다는 잘못된 경고를 수신할 수 있습니다.
- 해결된 문제 53525: VMware SD-WAN Orchestrator에서 새 UI를 사용하고 Edge 개요(Edge overview) 페이지를 보는 경우 링크(Links) 열에 링크의 상태(예: 백업(Backup), 대기(Standby))가 표시되지 않습니다.
이 링크 상태 정보는 이전 UI에는 올바르게 표시되며 이 수정 사항을 적용하면 새 UI에서도 예상대로 표시됩니다.
- 해결된 문제 53652: 사용자 지정 애플리케이션 맵을 사용하는 고객 엔터프라이즈가 3.x에서 4.x로 업그레이드되면 업그레이드 전에 생성된 사용자 지정 애플리케이션에 대해 무작위 이름이 표시될 수 있습니다.
기본 초기 애플리케이션 맵의 일부로 이미 존재하는 애플리케이션 ID(appId)로 사용자 지정 애플리케이션 맵을 구성할 때마다 VMware SD-WAN Orchestrator에는 항상 기본 초기 애플리케이션 맵의 표시 이름이 표시되고 고객이 정의한 이름이 재정의됩니다. 또한 Orchestrator를 하위 버전에서 상위 버전으로 업그레이드하고 상위 버전의 기본 초기 애플리케이션 맵 appid가 하위 버전에서 생성된 사용자 지정 애플리케이션의 appId와 충돌하는 경우도 마찬가지입니다. Orchestrator 업그레이드 후 이러한 사용자 지정 애플리케이션에 상위 버전의 기본 초기 애플리케이션 맵 appid의 표시 이름에 해당하는 잘못된 표시 이름이 표시됩니다.
- 해결된 문제 53752: 3.4.x 릴리스를 사용하는 VMware SD-WAN Orchestrator에서 릴리스 4.2.0을 사용하는 Orchestrator로 마이그레이션하려고 하면 고객 엔터프라이즈 마이그레이션이 실패합니다.
최신 엔터프라이즈 마이그레이션 도구가 릴리스 4.2.x를 지원하지 않았기 때문에 마이그레이션이 실패했습니다.
- 해결된 문제 53857: 릴리스 4.0.0을 기준으로 하는 KVM 이미지를 사용하는 VMware SD-WAN Orchestrator 배포는 실패합니다.
실패 이유는 KVM 이미지에 잘못된 가상 디스크 크기가 있으며 볼륨이 필요한 크기로 확장되지 못하기 때문입니다. 배포에서 Orchestrator 스크립트는 Orchestrator 볼륨을 자동으로 확장하여 기본 디스크(물리적 볼륨)의 최대 크기의 80%를 차지하게 합니다. 이 경우 잘못된 가상 크기 때문에 이러한 확장은 Orchestrator 데이터베이스 요구 사항에 부적절하고 배포는 실패합니다. 이 버그 수정 없이 이전 빌드를 사용하여 Orchestrator를 배포할 수 있지만 볼륨을 수동으로 조정해야 합니다.
- 해결된 문제 53987: VMware SD-WAN Orchestrator의 Orchestrator UI에서 Edge 이벤트 '링크 MTU가 감지됨(Link MTU Detected)'을 검색할 수 없습니다.
이 문제는 릴리스 4.0.x 이상을 사용하는 Orchestrator에서 확인되었습니다. 이벤트(Events) 페이지의 Orchestrator UI에서 이벤트 검색을 수행할 때 필터에 대한 이벤트 목록에서 '링크 MTU가 감지됨(Link MTU Detected)'을 사용할 수 없습니다. 이로 인해 문제 해결 동안 해당 이벤트를 격리하기 어렵습니다.
- 해결된 문제 54035: VMware Edge Network Intelligence 분석 모드를 사용하도록 설정하면 syslog 데몬, aruba 데몬 및 snmptrap 데몬으로 전송되는 패킷이 VMware SD-WAN Edge에서 삭제되며 이 데이터가 Edge Network Intelligence 뷰어에 표시되지 않습니다.
해당하는 iptable 규칙이 누락되어 Edge Network Intelligence 데몬(syslogd, amond 및 snmptrapd)으로 전송되는 패킷이 Edge 데이터부 프로세스에서 삭제됩니다. 그 결과 Edge Network Intelligence 백엔드에서 해당 통계가 수신되지 않습니다.
- 해결된 문제 55259: 관리자가 SD-WAN VMware SD-WAN Orchestrator UI에 새 VMware SD-WAN Edge를 생성하면 "위치 설정(Set Location)" 필드가 누락됩니다.
이 문제가 발생하면 관리자는 위치 정보 없이 Edge를 생성할 수 있지만 Orchestrator는 Edge에 대해 자동 지리적 위치를 수행하고 올바른 게이트웨이를 할당할 수 없습니다. 관리자는 Edge가 생성된 후 추가 단계를 수행하여 Configure(구성) > Edge > Edge 개요(Edge Overview) 페이지로 가서 Edge 위치 정보를 입력해야 합니다.
- 해결된 문제 55871: REST APIv2(/sdwan) HTTP에 대한 일부 API 호출로 인해 서버가 HTTP 500 오류를 생성합니다.
고객 데이터가 API에서 예상하는 스키마를 정확하게 준수하지 않는 경우 API는 문서화된 API 스키마와 불일치하는 데이터를 반환하는 대신 HTTP 500 오류를 생성합니다. 이 동작은 이후에 다시 진행된 디자인 결정을 따른 것입니다. "GET /enterprises", "GET /enterprises/{enterpriseLogicalId}/edges" 및 "GET /enterprises/{enterpriseLogicalId}/clientDevices" 호출이 영향을 받는 것으로 알려져 있습니다.
- 해결된 문제 56763: 보고서를 사용하도록 설정한 릴리스 4.x 이상을 사용하는 VMware SD-WAN Orchestrator에서 어떤 이유로든 보고서를 생성하지 못하면 Orchestrator의 백엔드 서비스를 다시 시작할 때까지 Orchestrator를 사용하는 모든 고객에 대한 모든 후속 보고서가 생성되지 않습니다.
이 문제는 Orchestrator 백엔드 서비스가 다시 시작될 때까지 Orchestrator를 사용하는 모든 고객이 보고서를 받을 수 없으므로 영향을 받는 Orchestrator에 지대한 영향을 미치게 됩니다. 이 문제는 단일 보고서 오류로 인해 발생하며 이 경우 보고 서비스는 Orchestrator에서 백엔드 서비스를 다시 시작하는 것 외에는 복구할 수 없는 잘못된 상태가 됩니다. 이러한 문제는 새 보고서 생성이 이전 보고서 생성과는 독립적으로 발생하지 않기 때문입니다. 이 버그 수정은 보고 서비스가 보고서 생성 실패와는 별도로 새 보고서를 계속 생성할 수 있도록 보장합니다.
- 해결된 문제 56824: 릴리스 4.2.x를 사용하는 VMware SD-WAN Orchestrator에서 수신자 URL에 명시적 포트 번호가 포함되어 있는 경우 Webhook 수신자에게 경고가 전달되지 못합니다.
이전에 명시적 포트 번호가 포함된 Webhook 수신자 URL을 구성한 사용자는 해당 수신자에 대한 경고 전달이 무기한 실패하는 것을 확인할 수 있습니다. 이 빌드의 수정 사항이 없으면 관리자는 원래 Webhook 수신자에게 요청을 전달하도록 역방향 프록시를 구성하고 해당 역방향 프록시를 가리키도록 Webhook 수신자 URL을 업데이트해야 합니다.
- 해결된 문제 56896: API 실패 및 게이트웨이 시간 초과가 발생할 수 있습니다.
이 문제는 파일 누적으로 인해 VMware SD-WAN Orchestrator의 디스크 스토리지가 가득 차게 되기 때문에 발생합니다. 이러한 누적은 VMware SD-WAN Edge에 대한 흐름 통계 또는 차단 목록/거부 목록과 비슷한 Edge 목록을 사용하지 않도록 설정하는 방법이 있기 때문에 발생합니다. 이러한 Edge에 대한 흐름 처리를 건너뛰어도 파일이 삭제되지 않고 Orchestrator의 디스크에 남아 있는 것이 문제가 됩니다. 이 문제가 확인된 현장에서 문제를 해결하고 사용자 환경 문제를 방지하기 위한 충분한 모니터링이 수행되었지만 이러한 모니터링이 충분히 진행되지 못한 Orchestrator에서는 고객 트래픽에 영향을 줄 수 있습니다. 이 수정 사항을 적용하지 않으면 Orchestrator 운영자는 24시간 이상의 타임 스탬프가 있는 Orchestrator 디스크 스토리지에서 파일을 수동으로 삭제해야 합니다.
- 해결된 문제 56909: 릴리스 4.x를 사용하는 VMware SD-WAN Orchestrator에서 백업 링크가 포함되는 경우 보고서 생성이 실패할 수 있습니다.
링크에 링크 통계 레코드가 없는 경우 보고서 생성 시 오류가 발생합니다. 보고서에 대해 선택한 기간 동안 백업을 엄격하게 유지하면 백업에 대한 링크 집합이 링크 통계를 생성하지 않습니다. 이 버그 수정을 적용하지 않을 경우 보고서를 생성하는 유일한 방법은 보고서를 생성하는 동안 백업 링크를 선택하지 않는 것입니다. 이 경우 링크에 해당 레코드에 대한 일부 통계 데이터가 포함될 수 있습니다.
- 해결된 문제 57087: 사용자가 구성(Configure) > Edge 화면에서 VMware SD-WAN Edge의 프로필을 전환하려고 하면 실제 이유 대신 일반 오류 메시지가 포함된 알림 상자가 있는 유효성 검사 오류가 표시됩니다.
"항목을 처리하는 동안 오류가 발생했습니다. 다시 시도하십시오."라는 오류를 나타내며 VMware SD-WAN Edge를 삭제할 수 없습니다. 실제 유효성 검사 오류의 이유를 확인하기 위해 사용자는 웹 브라우저의 디버깅 콘솔을 확인해야 합니다. 수정 후 적절한 유효성 검사 오류/실패 이유가 표시됩니다.
- 해결된 문제 58627: 경고를 수신하도록 구성된 사용자는 링크가 실제로 종료된 상태로 유지될 때 연결 경고(Link Up Alert)를 수신할 수 있습니다.
경우에 따라 링크가 '종료(Down)'로 표시된 후 링크가 종료되기 전에 생성된 해당 링크에 대한 통계가 이벤트 후 최대 1분 동안 VMware SD-WAN Orchestrator로 전송되지 않을 수 있습니다. Orchestrator가 이러한 지연 링크 통계를 수신하면 링크가 백업되는 것으로 착각하게 되므로 경고 설정이 적극적이면(예: 0분 지연) 연결(Link Up) 경고가 트리거됩니다. 이 수정 사항을 적용하면 Orchestrator는 링크 통계 지연을 링크가 현재 실행 중임을 의미하는 것으로 해석하지 않게 됩니다.
- 해결된 문제 59094: 작업자가 VMware SD-WAN Orchestrator를 업그레이드하려고 하면 업데이트 스크립트는 스키마 업데이트 요구 사항에 대한 적절한 경고 메시지를 제공하지 않습니다.
작업자가 더 큰 테이블에 스키마 변경 사항을 적용하는 단계를 누락하면 Orchestrator 서비스에 오류가 발생할 수 있습니다. 또한 누락된 변경 사항을 쉽게 확인할 수 있는 방법이 없습니다. 이 버그 수정 사항은 백엔드 서비스가 다시 시작될 때 큰 테이블에 필요한 누락된 스키마 변경 내용을 재생성할 때 이 문제를 해결합니다.
- 해결된 문제 59967: VMware SD-WAN Orchestrator를 4.2.x 릴리스 이상으로 업그레이드한 후 운영자가 구성(Configure) > 비즈니스 정책(Business Policy) 또는 구성(Configure) > 방화벽 정책(Firewall policy) 페이지에 액세스하려고 하면 페이지가 로드되지 않고 오류가 발생합니다.
"예기치 않은 오류가 발생했습니다."라는 오류가 표시됩니다. 이 문제는 파트너 또는 고객 관리자에게는 영향을 미치지 않고 운영자에게만 영향을 미칩니다. 운영자에 대한 READ: OBJECT_GROUP 권한이 없으므로 페이지가 로드되지 않습니다. 즉, Orchestrator에서 운영자에게 비즈니스 정책(Business Policy) 및 방화벽(Firewall) 페이지에 액세스하는 데 필요한 권한이 있다고 인식하지 않습니다.
알려진 문제
릴리스 4.2.1의 미해결 문제
알려진 문제는 다음과 같이 그룹화되어 있습니다.
Edge/게이트웨이의 알려진 문제- 문제 14655:
SFP 어댑터를 연결하거나 연결을 해제하면 디바이스가 Edge 540, Edge 840 및 Edge 1000에서 응답을 중지하고 물리적 다시 부팅을 요구할 수 있습니다.
해결 방법: Edge를 물리적으로 다시 부팅해야 합니다. 이 작업은 원격 작업(Remote Actions) > Edge 다시 부팅(Reboot Edge)을 사용하여 Orchestrator에서 수행하거나 Edge를 껐다가 다시 켜는 방법으로 수행할 수 있습니다.
- 문제 25504:
고정 경로 비용이 255보다 크면 경로 순서가 예기치 않게 지정될 수 있습니다.
해결 방법: 0 ~ 255 사이의 경로 비용을 사용하십시오.
- 문제 25595:
WAN 오버레이에서 고정 SLA 변경 사항이 제대로 적용되려면 다시 시작해야 할 수 있습니다.
해결 방법: WAN 오버레이에서 고정 SLA를 추가 및 제거한 후 Edge를 다시 시작하십시오.
- 문제 25742:
언더레이로 인한 트래픽은 게이트웨이에 연결되지 않은 개인 WAN 링크의 용량보다 낮은 경우에도 VMware SD-WAN Gateway의 최대 용량으로 제한됩니다.
- 문제 25758:
VMware SD-WAN Edge가 다시 부팅될 때까지 한 USB 포트에서 다른 USB 포트로 전환되면 USB WAN 링크가 제대로 업데이트되지 않을 수 있습니다.
해결 방법: 한 포트에서 다른 포트로 USB WAN 링크를 이동한 후에 Edge를 다시 부팅합니다.
- 문제 25855:
파트너 게이트웨이의 대규모 구성 업데이트(예: 200BGP 지원 VRF)로 인해 VMware SD-WAN Gateway를 통한 일부 트래픽에 대해 약 2-3초 동안 지연 시간이 증가할 수 있습니다.
해결 방법: 사용할 수 있는 해결 방법이 없습니다.
- 문제 25921:
허브에 연결된 분기 Edge가 3,000개 있는 경우 VMware SD-WAN Hub 고가용성 페일오버가 예상보다 오래(최대 15초) 걸립니다.
- 문제 25997:
전환된 포트로 변환한 라우팅된 인터페이스에서 트래픽을 올바르게 전달하려면 VMware SD-WAN Edge를 다시 부팅해야 할 수 있습니다.
해결 방법: 구성을 변경한 후에 Edge를 다시 부팅합니다.
- 문제 26421:
클러스터에 대한 터널을 설정하려면 모든 분기 사이트에 대한 기본 파트너 게이트웨이를 VMware SD-WAN Hub 클러스터에도 할당해야 합니다.
- 문제 28175:
NAT IP가 VMware SD-WAN Gateway 인터페이스 IP와 겹치면 비즈니스 정책 NAT가 실패합니다.
- 문제 31210:
VRRP: VMware SD-WAN Edge가 LAN 인터페이스에서 실행되는 비 글로벌 CDE 세그먼트에서 기본인 경우 ARP가 LAN 클라이언트에서 VRRP 가상 IP 주소로 확인되지 않습니다.
- 문제 32731:
OSPF를 통해 애드버타이즈된 조건부 기본 경로는 경로가 해제되어 있을 때 제대로 철회되지 않을 수 있습니다. 경로를 다시 사용하도록 설정했다가 사용하지 않도록 설정하면 성공적으로 취소됩니다.
- 문제 32960:
활성화된 VMware SD-WAN Edge에 대한 로컬 웹 UI에 인터페이스 "자동 협상(Autonegotiation)" 및 "속도(Speed)" 상태가 잘못 표시될 수 있습니다.
- 문제 32981:
DPDK 지원 포트에서 하드 코딩 속도 및 전이중을 사용하려면 DPDK를 사용하지 않도록 설정해야 하므로 VMware SD-WAN Edge를 다시 부팅해야 할 수 있습니다.
- 문제 34254:
Zscaler CSS가 생성되고 글로벌 세그먼트에 FQDN/PSK 설정이 구성되어 있으면 이러한 설정이 비 글로벌 세그먼트에 복사되어 Zscaler CSS에 대한 IPsec 터널이 형성됩니다.
- 문제 35778:
단일 인터페이스에 여러 사용자 정의 WAN 링크가 있는 경우 해당 WAN 링크 중 하나에만 Zscaler에 대한 GRE 터널이 유지될 수 있습니다.
해결 방법: Zscaler에 대한 GRE 터널을 구축해야 하는 각 WAN 링크에 대해 다른 인터페이스를 사용합니다.
- 문제 35807:
VMware SD-WAN Orchestrator에서 인터페이스를 사용하지 않도록 설정했다가 다시 사용하도록 설정하면 DPDK 라우팅 인터페이스가 완전히 사용되지 않도록 설정됩니다.
- 문제 36923:
해당 클러스터에 허브로 연결된 VMware SD-WAN Edge에 대한 NetFlow 인터페이스 설명에서 클러스터 이름이 올바르게 업데이트되지 않을 수 있습니다.
- 문제 38682:
DPDK 지원 인터페이스에서 DHCP 서버로 작동하는 VMware SD-WAN Edge가 연결된 모든 클라이언트에 대해 "새 클라이언트 디바이스(New Client Device)" 이벤트를 제대로 생성하지 못할 수 있습니다.
- 문제 38767:
Zscaler에 대한 GRE 터널이 구성된 WAN 오버레이가 자동 감지에서 사용자 정의로 변경되면 다음에 다시 시작할 때까지 오래된 터널이 남아 있을 수 있습니다.
해결 방법: Edge를 다시 시작하여 오래된 터널을 지웁니다.
- 문제 39134:
시스템 상태 통계 "CPU 백분율(CPU Percentage)"이 VMware SD-WAN Edge의 모니터링(Monitor) > Edge > 시스템(System), VMware SD-WAN Gateway의 모니터링(Monitor) > 게이트웨이(Gateways)에서 올바르게 보고되지 않을 수 있습니다.
해결 방법: 사용자는 CPU 백분율이 아닌 Edge 용량을 모니터링하기 위해 핸드오프 대기열 손실 개수를 사용해야 합니다.
- 문제 39374:
VMware SD-WAN Edge에 할당된 VMware SD-WAN 파트너 게이트웨이의 순서를 변경하면 게이트웨이 1이 대역폭 테스트에 사용될 로컬 게이트웨이로 올바르게 설정되지 않을 수 있습니다.
- 문제 39608:
원격 진단 "Ping 테스트"의 출력에 잘못된 컨텐츠가 잠시 표시되었다가 올바른 결과가 표시될 수 있습니다.
- 문제 39624:
상위 인터페이스가 PPPoE로 구성된 경우 하위 인터페이스를 통한 Ping 작업이 실패할 수 있습니다.
- 문제 39659:
각 VMware SD-WAN Edge에 하나의 WAN 링크가 있는 향상된 고가용성을 위해 구성된 사이트에서 대기 Edge에 PPPoE만 연결되어 있고 활성 Edge에 비 PPPoE만 연결되어 있는 경우, HA 케이블에 장애가 발생하면 분할 브레인 상태(활성/활성)가 가능할 수 있습니다.
- 문제 39753:
동적 분기 간 VPN을 사용하지 않도록 설정하면 동적 분기 간 VPN을 사용하여 현재 전송 중인 기존 흐름이 중단될 수 있습니다.
- 문제 40096:
활성화된 VMware SD-WAN Edge 840을 다시 부팅하면 링크 표시등이 켜지고 VMware SD-WAN Orchestrator가 포트를 '실행 중(Up)'으로 표시하더라도 Edge에 연결된 SFP 모듈이 트래픽 전달을 중지하게 될 수 있습니다.
해결 방법: 포트에서 SFP 모듈을 뽑았다가 다시 꽂습니다.
- 문제 40421:
인터페이스가 전환된 포트로 구성된 VMware SD-WAN Edge를 통과하는 경우 Traceroute에 해당 경로가 표시되지 않습니다.
- 문제 42278:
특정 유형의 피어 구성 오류가 있을 때 VMware SD-WAN Gateway가 계속해서 비 SD-WAN 피어에 IKE 초기화 메시지를 보낼 수 있습니다. 이 문제로 인해 게이트웨이에 대한 사용자 트래픽이 중단되지는 않습니다. 그러나 게이트웨이 로그가 IKE 오류로 채워질 수 있으며, 이로 인해 유용한 로그 항목이 모호해질 수 있습니다.
- 문제 42388:
VMware SD-WAN Edge 540에서 VMware SD-WAN Orchestrator의 인터페이스를 사용하지 않도록 설정했다가 다시 사용하도록 설정한 후에 SFP 포트가 감지되지 않습니다.
- 문제 42488:
스위치 또는 라우팅된 포트에 대해 VRRP를 사용하도록 설정된 VMware SD-WAN Edge에서 케이블이 포트에서 연결이 끊기고 Edge 서비스가 다시 시작되면 LAN 연결 경로가 애드버타이즈됩니다.
해결 방법: 이 문제에 대한 해결 방법은 없습니다.
- 문제 42872:
허브 클러스터가 연결된 허브 프로필에서 프로필 분리를 사용하도록 설정하면 RIB(라우팅 정보 기반)의 허브 경로가 해지되지 않습니다.
- 문제 43373:
여러 VMware SD-WAN Edge에서 동일한 BGP 경로를 학습한 경우 오버레이 흐름 제어에서 이 경로가 기본 설정에서 적격 종료로 전환되면 Edge는 애드버타이즈 목록에서 제거되지 않고 계속 애드버타이즈됩니다.
해결 방법: VMware SD-WAN Orchestrator에서 분산 비용 계산을 사용하도록 설정합니다.
- 문제 44526: 서로 다른 두 사이트가 고가용성 토폴로지를 사용하는 동시에 VMware SD-WAN Edge를 허브로 배포하는 엔터프라이즈에서 각 사이트가 다른 허브 사이트를 해당 프로필의 허브로 사용합니다. 허브 사이트 중 하나가 HA 페일오버를 트리거하는 경우 두 허브 Edge가 서로 간에 터널을 다시 설정하는 데 30분까지 걸릴 수 있습니다.
HA 페일오버에서 두 허브 Edge가 동시에 서로 간에 터널을 시작하려고 하지만 둘 다 피어에 응답하지 않으면 두 허브 간의 패킷 교환이 발생하지만 IKE는 성공하지 못합니다. 이로 인해 자체적으로 해결되는 데 최대 30분까지 소요되는 것으로 확인된 교착 상태가 발생합니다. 이 문제는 간헐적이며 모든 HA 페일오버 후 발생하는 것은 아닙니다.
해결 방법: 이 문제가 발생하는 것을 방지하려면 고객은 두 HA 허브 사이트 중 하나만 다른 허브 사이트를 자체 허브로 사용하도록 구성해야 합니다. 예를 들어, 두 개의 HA 허브 사이트 Hub1과 Hub2가 있는 경우 Hub1은 해당 프로필에서 자체 허브로 Hub2를 포함할 수 있지만, Hub2는 해당 프로필에서 Hub1을 허브로 사용하면 안 됩니다.
- 문제 44832:
하나의 Edge를 통한 비 SD-WAN 대상에서 다른 Edge를 통한 비 SD-WAN 대상으로 전송되는 트래픽(예: '헤어스피닝' 또는 'NAT 루프백')이 VMware SD-WAN Edge에서 삭제됩니다.
- 문제 44995:
OSPF 경로가 허브 클러스터에서 철회되는 경우 VMware SD-WAN Gateway와 VMware SD-WAN 스포크 Edge에서 해지되지 않습니다.
- 문제 45189:
소스 LAN 측 NAT가 구성된 경우, NAT 서브넷에 대한 고정 경로 구성 없이도 VMware SD-WAN 스포크 Edge에서 허브 Edge로의 트래픽이 허용됩니다.
- 문제 45302:
VMware SD-WAN Hub 클러스터에서 한 허브에서 허브와 할당된 스포크 Edge 사이에 공통되는 모든 VMware SD-WAN Gateway와의 연결이 5분 넘게 끊어지면 드문 경우에 스포크가 5분 후에 허브 경로를 보존하지 못할 수 있습니다. 이 문제는 허브가 게이트웨이와 다시 연결될 때 자체적으로 해결됩니다.
- 문제 46053:
인접 항목이 업링크 인접 항목으로 변경될 때 BGP 기본 설정이 오버레이 경로에 맞춰 자동으로 수정되지 않습니다.
해결 방법: Edge 서비스를 다시 시작하면 이 문제가 해결됩니다.
- 문제 46137:
3.4.x 소프트웨어를 실행하는 VMware SD-WAN Edge는 Edge가 GCM에 대해 구성된 경우에도 AES-GCM 암호화로 터널을 시작하지 않습니다.
- 문제 46216:
피어가 AWS 인스턴스인 게이트웨이 또는 Edge를 통한 비 SD-WAN 대상에서 피어가 2단계 키 재생성을 시작하면 1단계 IKE도 삭제되고 키 재생성이 강제로 다시 실행됩니다. 즉, 터널이 손상되었다가 다시 구축되면 터널 재구축 중에 패킷 손실이 발생합니다.
해결 방법: 터널 소멸을 방지하려면 게이트웨이/Edge를 통한 비 SD-WAN 대상 또는 CSS IPsec 키 재생성 타이머를 60분 미만으로 구성합니다. 이로 인해 AWS가 키 재생성을 시작하지 못합니다.
- 문제 46391:
VMware SD-WAN Edge 3800의 경우, 각각 SFP1 및 SFP2 인터페이스에 다중 속도 SFP(1/10G)에 문제가 있으며 해당 포트에서 사용하면 안 됩니다.
해결 방법: KB 문서 VMware SD-WAN 지원 SFP 모듈 목록(79270)에 따라 단일 속도 SFP를 사용하십시오. 다중 속도 SFP는 SFP3 및 SFP4에서 사용할 수 있습니다.
- 문제 46918:
3.4.2 릴리스를 사용하는 VMware SD-WAN 스포크 Edge가 클러스터 허브 노드의 개인 네트워크 ID를 올바르게 업데이트하지 않습니다.
- 문제 47084:
VMware SD-WAN Hub Edge에는 4000 스포크 Edge가 연결된 경우 750개보다 많은 PIM(프로토콜 독립 멀티캐스트) 인접 항목을 설정할 수 없습니다.
- 문제 47244:
DPDK가 사용하도록 설정되고 Copper SFP가 있는 활성화된 VMware SD-WAN Edge 6x0에서 케이블이 삽입되지 않은 경우에도 VMware SD-WAN Orchestrator UI에 Edge가 링크를 '실행 중'으로 표시합니다.
해결 방법: 케이블을 꽂았다가 뽑으면 잘못된 상태가 제거됩니다.
- 문제 47355:
로컬 언더레이 BGP, 허브 BGP 및/또는 파트너 게이트웨이에서 고정으로 구성된 BGP를 통해 동일한 경로가 학습될 경우 경로의 정렬 순서가 잘못되어 언더레이 BGP보다 허브 BGP가 선호됩니다.
- 문제 47664:
허브 VPN을 통한 분기 간 방식이 사용되지 않도록 설정된 허브 및 스포크 구성에서 L3 스위치/라우터의 요약 경로를 사용하여 분기 간 트래픽을 유턴하려고 하면 라우팅 루프가 발생합니다.
해결 방법: 분기 간 VPN을 설정하도록 클라우드 VPN을 구성하고 "VPN에 대해 허브 사용"을 선택합니다.
- 문제 47681:
VMware SD-WAN Edge의 LAN 측 호스트가 Edge의 WAN 인터페이스와 동일한 IP를 사용하는 경우 LAN 호스트에서 WAN으로의 연결이 작동하지 않습니다.
- 문제 47787:
VMware SD-WAN Gateway 경로를 통하는 트래픽이 허브 Edge에서 해당 스포크 Edge로 시작되면 백홀 비즈니스 정책으로 구성된 VMware SD-WAN 스포크 Edge는 해당 게이트웨이 경로를 통해 트래픽을 잘못 전송합니다.
- 문제 48166:
Ciena 가상화 OS를 사용하는 경우 KVM의 VMware SD-WAN 가상 Edge가 지원되지 않으며 Edge에서 데이터부 서비스 장애가 반복적으로 발생합니다.
- 문제 48175:
비 글로벌 세그먼트에 글로벌 세그먼트에 구성된 인터페이스와 동일한 IP 범위에 구성된 인터페이스가 있는 경우, 릴리스 3.4.2를 실행하는 VMware SD-WAN Edge가 비 글로벌 세그먼트에서 OSPF 인접 메뉴를 형성합니다.
- 문제 48530:
VMware SD-WAN Edge 6x0 모델은 삼중 속도(10/100/1000Mbps) Copper SFP의 자동 협상을 수행하지 않습니다.
해결 방법: Edge 520/540은 삼중 속도 Copper SFP를 지원하지만 이 모델은 2021년 1사분기까지 판매 종료되는 것으로 표시되었습니다.
- 문제 48597: 피어에 대한 두 경로 중 하나가 종료된 경우 멀티 홉 BGP 인접 관계가 유지되지 않음
여러 경로가 있고 경로 중 하나가 종료된 피어에 대해 멀티 홉 BGP 인접 관계가 있는 경우 해당 BGP 인접 관계가 종료되고 사용 가능한 다른 경로를 사용해도 실행되지 않는다는 알림이 표시됩니다. 여기에는 로컬 IP-루프백 인접 관계 사례도 포함됩니다.
해결 방법: 이 문제에 대한 해결 방법은 없습니다.
- 문제 48666:
IPsec 전면 게이트웨이 경로 MTU 계산은 61바이트의 IPsec 오버헤드를 고려하지 않으므로 LAN 클라이언트로 더 많은 애드버타이즈가 진행되고 후속 IPsec 패킷이 조각화됩니다.
해결 방법: 이 문제에 대한 해결 방법은 없습니다.
- 문제 49172:
두 개의 다른 VMware SD-WAN Edge에 대해 동일한 NAT 서브넷으로 구성된 정책 기반 NAT 규칙이 작동하지 않습니다.
- 문제 49738:
경우에 따라 VMware SD-WAN 스포크 Edge가 여러 허브 Edge를 사용하도록 구성되면 스포크 Edge가 허브 목록에 구성된 허브 중 하나로의 터널이 형성되지 않을 수 있습니다.
- 문제 50518:
PKI를 사용하도록 설정한 VMware SD-WAN Gateway에서 6,000개보다 많은 PKI 터널이 게이트웨이에 연결하려고 하면 인바운드 SA가 삭제되지 않기 때문에 터널이 모두 표시되지는 않을 수 있습니다.
참고: PSK(사전 공유 키) 인증을 사용하는 터널에는 이 문제가 발생하지 않습니다.
- 문제 51428: VMware SD-WAN Edge에 PIM으로 구성된 하위 인터페이스가 있는 사이트에서 멀티캐스트 트래픽 손실이 발견될 수 있습니다.
PIM으로 구성된 하위 인터페이스를 즉석에서 다른 세그먼트로 이동하면 pimd(PIM을 관리하는 프로세스)가 다시 시작되고 사이트에서 간헐적으로 멀티캐스트 트래픽 손실이 발생할 수 있습니다.
해결 방법: 먼저 하위 인터페이스를 사용하지 않도록 설정한 다음, 하위 인터페이스를 다른 세그먼트로 이동합니다. 이동한 후에는 하위 인터페이스를 다시 사용하도록 설정합니다.
- 문제 51436: LTE 모뎀을 사용하여 VMware SD-WAN Edge를 배포하는 동안 향상된 고가용성 토폴로지를 사용하는 사이트의 경우 사이트가 "분할 브레인" 상태가 되면 HA 페일오버에 5-6분 정도 소요됩니다.
분할 브레인 상태에서 복구하면서 LAN 포트는 활성 Edge에서 종료되며, 이러한 상황은 포트가 종료되고 사이트를 복구할 수 있게 될 때까지 LAN 트래픽에 영향을 미칩니다.
해결 방법: 이 문제에 대한 해결 방법은 없습니다.
- 문제 52483: 인터페이스에 대해 언더레이 계산을 사용하도록 설정하면 VMware SD-WAN Edge가 오버레이를 전달하는 대신, 동일한 인터페이스로 트래픽을 다시 잘못 전달합니다.
이 동작은 언더레이 계산 및 재귀 경로 확인 문제로 인해 발생합니다.
해결 방법: 영향을 받는 인터페이스에 대해 언더레이 계산을 사용하지 않도록 설정하십시오.
- 문제 53219: VMware SD-WAN Hub 클러스터를 재조정한 후 몇 개의 스포크 Edge에서 RPF 인터페이스/IIF를 올바르게 설정하지 못할 수 있습니다.
영향을 받는 스포크 Edge에서 멀티캐스트 트래픽이 영향을 받습니다. 클러스터 재조정 후 일부 스포크 Edge가 PIM 가입을 전송하지 못하게 됩니다.
해결 방법: 이 문제는 영향을 받는 스포크 Edge로 인해 Edge 서비스가 다시 시작될 때까지 지속됩니다.
- 문제 53337: 처리량이 3200Mbps를 초과하는 경우 VMware SD-WAN Gateway의 AWS 인스턴스에서 패킷 삭제가 확인될 수 있습니다.
트래픽이 3200Mbps보다 많은 처리량을 초과하고 패킷 크기가 1300바이트인 경우 RX 및 IPv4 BH 핸드오프에서 패킷 삭제가 확인됩니다.
해결 방법: 이 문제에 대한 해결 방법은 없습니다.
- 문제 53359: 일부 DDoS 공격 시나리오에서 BGP/BFD 세션이 실패할 수 있습니다.
라우팅된 인터페이스에 연결된 클라이언트에서 LAN 클라이언트로 트래픽이 플러드되면 BGP/BFD 세션이 실패할 수 있습니다. 또한 높은 우선 순위의 실시간 트래픽이 오버레이 대상으로 플러드되는 경우에도 BGP/BFD 세션이 실패할 수 있습니다.
해결 방법: 이 문제에 대한 해결 방법은 없습니다.
- 문제 53830: VMware SD-WAN Edge에서 DCC 플래그를 사용하도록 설정한 경우 BGP 보기의 일부 경로에 올바른 기본 설정이 구성되지 않고 값을 애드버타이즈하지 않아 Edge의 FIB에서 정렬 순서가 잘못될 수 있습니다.
Edge에 많은 수의 경로가 있는 확장된 시나리오에서 DCC(분산 비용 계산)를 사용하도록 설정한 경우, 로그 bgp_view에 대한 Edge 진단 번들을 보면 일부 경로가 기본 설정 및 애드버타이즈 값으로 올바로 업데이트되지 않을 수 있습니다. 이 문제는 대부분의 경우 대규모 엔터프라이즈의 일부인 일부 Edge(100개 이상의 스포크 Edge가 허브 Edge 또는 허브 클러스터에 연결된 경우)에서 확인될 수 있습니다.
해결 방법: 이 문제는 영향을 받는 경로에 대한 VMware SD-WAN Orchestrator의 OFC 페이지에서 언더레이 BGP 경로를 재학습하거나 "새로 고침(Refresh)" 옵션을 수행하여 해결할 수 있습니다. 경로의 "새로 고침(Refresh)"을 실행하면 엔터프라이즈의 모든 Edge에서 경로가 다시 학습됩니다.
- 문제 53934: VMware SD-WAN Hub 클러스터가 구성된 엔터프라이즈에서 기본 허브의 LAN 측에 멀티 홉 BGP 인접 관계가 있는 경우, LAN 측에 장애가 발생하거나 모든 세그먼트에서 BGP가 사용되지 않도록 설정되면 고객이 스포크 Edge에서 트래픽 삭제를 경험할 수 있습니다.
허브 클러스터에서 기본 허브는 피어 디바이스와의 멀티 홉 BGP 인접 관계가 있어서 경로를 학습할 수 있습니다. BGP 인접 관계가 설정된 허브의 물리적 인터페이스가 종료되면 BGP 보기가 비어 있더라도 BGP LAN 경로가 0이 되지 않을 수 있습니다. 이로 인해 허브 클러스터 재조정이 발생하지 않을 수 있습니다. 이 문제는 BGP가 모든 세그먼트에 대해 사용되지 않도록 설정되어 있고 하나 이상의 멀티 홉 BGP 인접 관계가 있는 경우에도 발생할 수 있습니다.
해결 방법: LAN 측 장애(또는 BGP 사용 안 함)가 있는 허브를 다시 시작하십시오.
- 문제 56218: 고가용성 토폴로지로 배포되거나 HA가 사용하도록 설정된 고객 사이트의 경우 Edge를 3.2.x에서 3.4.x로 업그레이드하면 대기 Edge가 종료될 수 있습니다.
로컬 UI를 사용하여 WAN 설정을 구성한 후 HA를 사용하도록 설정되거나 HA Edge를 3.2.2에서 3.4.x로 업그레이드하면 HA 인터페이스(예: Edge 모델에 따라 LAN1 또는 GE1)가 대기 Edge에서 제거되고 VMware SD-WAN Orchestrator에서 HA 상태가 HA_FAILED로 설정됩니다.
해결 방법: 대기 Edge를 재부팅하여 복구하십시오.
- 문제 60006: 620 및 640과 같은 하드웨어 기반 VMware SD-WAN Edge에서 HA를 사용하도록 설정하면 대기 Edge가 재부팅될 수 있습니다.
620 또는 640(이 문제가 발견되었던 모델)에서 HA를 사용하도록 설정하면 대기 Edge가 활성/활성 패닉을 감지하고 대기 Edge가 활성/활성 상태를 수정하기 위해 재부팅됩니다. 이 문제는 Edge 초기화 중 HA 인터페이스 초기화와 HA 상태 시스템 초기화 간의 경합 조건 가능성으로 인해 발생합니다. 즉, HA 인터페이스 드라이버 초기화가 완료되는 것보다 HA 상태 시스템 초기화가 훨씬 더 일찍 시작되므로 HA 상태 시스템은 피어 Edge에서 하트비트를 감지하지 못하고 활성 상태로 전환됩니다. 이 문제는 드물게 발생하므로 한 번 사이트에서 발생하더라도 같은 세션에서 또다시 발생할 확률은 낮습니다. 그러므로 사이트가 대기 Edge 재부팅을 끝없이 반복하지는 않을 것입니다.
해결 방법: 이 문제의 해결 방법은 없지만, 일반적으로 첫 번째 재부팅이 끝나면 대기 모드가 복구됩니다.
- 문제 60225: VMware SD-WAN Edge에 대한 원격 진단 "인터페이스 상태"를 실행할 때 SFP 인터페이스에 대한 VMware SD-WAN Orchestrator의 출력에 잘못된 속도 및 이중 정보가 표시됩니다.
Orchestrator의 데이터가 SFP 인터페이스에 대해 올바르지 않습니다. 예를 들어 Edge에서 데이터를 직접 본다면 0Mbps/반이중이 표시되겠지만 1000Mbps에서는 전이중 또는 유사한 방식으로 표시됩니다.
해결 방법: 해결 방법은 없습니다.
- 문제 60523: SLA 검색을 사용하도록 설정한 경우 라우팅된 클라이언트 IP 주소에 대한 ping이 실패합니다.
라우팅된 클라이언트 IP 주소에 대해 SLA 검색을 사용하도록 설정한 경우 Edge 데이터부 서비스에서 ICMP 응답 패킷을 처리하지 못합니다. 이 수정 사항을 적용하지 않고 이 문제를 해결할 수 있는 유일한 방법은 ICMP 검색을 사용하지 않도록 설정하는 것입니다.
해결 방법: ICMP 프로브를 사용하지 않도록 설정합니다.
- 문제 61361: 소프트웨어 업데이트를 적용하여 VMware SD-WAN Edge 3400, 3800 및 3810을 Edge 릴리스 3.4.5, 4.0.2, 또는 4.2.1로 업그레이드하면 업데이트 이후 Edge 모델이 즉시 부팅되지는 않을 수도 있습니다.
릴리스 3.4.5, 4.0.2 및 4.2.1에는 CPLD(복합 프로그래밍 가능 논리 디바이스)에 대한 특정 펌웨어 업데이트가 포함되어 있으며, 업데이트가 재부팅을 트리거하여 때에 따라 [중지(stuck)] 상태가 되면 수동 전원 주기로 시스템을 다시 시작해야 합니다.
해결 방법: Edge의 전원을 수동으로 껐다가 켜서 업데이트를 완료합니다.
- 문제 61543: 동일한 내부 IP를 사용하는 서로 다른 인터페이스에 2개 이상의 1:1 NAT 규칙을 구성한 경우 하나의 인터페이스에서 인바운드 트래픽이 수신될 수 있으며 동일한 흐름의 아웃바운드 패킷을 다른 인터페이스를 통해 라우팅할 수 있습니다.
외부에서 내부로의 NAT 흐름에서는 1:1 NAT 규칙이 외부 IP 및 패킷이 수신되는 인터페이스와 일치하는지 확인됩니다. 동일한 흐름의 아웃바운드 패킷의 경우 VMware SD-WAN Edge가 내부 IP를 비교하여 NAT 규칙이 일치하는지 다시 확인하며, "아웃바운드 트래픽(Outbound Traffic)"을 사용하도록 설정한 첫 번째 일치 규칙에 구성된 인터페이스를 통해 아웃바운드 트래픽을 라우팅할 수 있습니다.
해결 방법: 이 문제는 특정 내부 IP 주소를 사용하여 1:1 NAT 규칙이 두 개 이상 구성되지 않도록 하는 것 외에 다른 해결 방법이 없습니다.
- 문제 62552: 사이트에서 높은 패킷 손실 및 연결 문제가 간헐적으로 발생할 수 있습니다.
이 문제의 원인은 MAC 주소 00:00:00:00을 전달하는 동안 Edge에 디바이스에 대한 ARP 확인이 성공했음을 알리는 ARP 해결을 확인하기 API 때문에 발생했습니다. 이 주소는 ARP 캐시에 유지되어 MAC이 0으로 나열된 디바이스용 패킷이 모두 삭제됩니다. 이 문제에서는 MAC 주소가 0인 성공적인 ARP의 많은 인스턴스가 전달되어 높은 패킷 손실 및 연결 문제가 발생할 수 있습니다.
참고: 60130 문제와 해당 문제는 기본 동작과 원인이 동일하지만 각 티켓의 예상 수정 사항이 다릅니다. 60130에는 방어적인 해결 방법이 수정 사항으로 포함되며 62552에는 해당 문제의 재발을 방지하는 완전한 수정 사항이 포함됩니다.
해결 방법: 이 문제에 대한 해결 방법은 없습니다.
- 문제 63359: 고가용성 토폴로지 및 OSPF로 구성되고 VMware SD-WAN Edge가 MGMT IP Edge 빌드를 사용하는 사이트의 경우 이러한 Edge가 3.4.x에서 4.2.x MGMT-IP 빌드로 업그레이드되면 업그레이드 이후 OSPF 연결이 끊어질 수 있습니다.
HA Edge가 4.2.x MGMT IP 빌드로 업그레이드되면 HA 시스템이 해당 라우터 ID를 169.254.2.2로 정의할 수 있습니다. 이것은 라우터 ID의 Edge 선택이 HA 인터페이스의 IP 주소를 고려하지 않아야 한다고 가정할 때 예상되는 동작이 아닙니다. 해당 라우터 ID가 OSPF 연결을 끊으면 경로 교환이 더 이상 발생하지 않으므로 연결이 완전히 끊어집니다.
해결 방법: Edge 서비스를 다시 시작하여 HA 페일오버를 트리거합니다. 다시 시작하면 올바른 라우터 ID가 강제로 다시 선택됩니다.
- 문제 67790: BGP나 OSPF를 사용하고 인바운드 필터를 구성하여 특정 경로를 무시하는 고객 엔터프라이즈가 해당 엔터프라이즈에 DCC(동적 비용 계산)를 사용하도록 설정할 경우, 엔터프라이즈에 인바운드 필터가 더 이상 적용되지 않으며 트래픽이 해당 경로 사용을 시도합니다.
DCC를 사용하도록 설정하기 전에는 BGP/OSPF 인바운드 필터에서 무시(IGNORE)로 설정된 경로가 FIB(전달 정보 기반)에 포함되지 않습니다. 이제 DCC를 사용하도록 설정하면 FIB에 이러한 경로가 포함되며, 트래픽이 해당 경로를 사용하려고 시도하여 고객 엔터프라이즈에 심각한 트래픽 중단을 유발할 가능성이 있습니다.
해결 방법: 인바운드 필터가 제대로 적용되려면 OSPF/BGP를 다시 시작해야 합니다.
- 문제 84825: BGP가 구성된 고가용성 토폴로지로 배포된 사이트의 경우 사이트에 512개보다 많은 BGPv4 match 및 set 규칙이 구성된 경우 고객이 복구하지 않고 HA Edge 쌍이 지속적으로 페일오버되는 것을 확인할 수 있습니다.
BGPv4 match 및 set 규칙이 512개보다 많은 것은 고객이 인바운드 필터에 대해 256개보다 많은 규칙과 아웃바운드 필터에 대해 256개보다 많은 규칙을 구성하는 것으로 이해됩니다. 반복 페일오버로 인해 음성 통화와 같은 실시간 트래픽의 흐름이 지속적으로 삭제되었다가 다시 생성되기 때문에 이 문제는 고객에게 지장을 줄 수 있습니다. HA Edge에서 이 문제가 발생하면 Edge CPU 스레드를 동기화하는 프로세스가 실패하여 Edge가 재부팅되지만 승격된 Edge도 동일한 문제가 발생하고 사이트에서 복구에 도달하지 않은 상태로 재부팅됩니다.
해결 방법: 이 문제를 수정하지 않으면 고객은 HA 사이트에 대해 구성된 BGPv4 match 및 set 규칙이 512개를 초과하지 않는지 확인해야 합니다.
사이트에서 이 문제가 발생하고 사이트에 512개보다 많은 BGP/v4 match 및 set 규칙이 구성된 경우 고객은 즉시 규칙 수를 512개 이하로 줄여야 사이트를 복구할 수 있습니다.
또는 고객에게 512개가 넘는 BGPv4 match 및 set 규칙이 있어야 하는 경우 이 문제가 발생하지 않는 릴리스 3.4.6으로 HA Edge를 다운그레이드할 수 있지만 이후 릴리스에 있는 Edge 기능을 사용할 수 없게 됩니다. 이는 해당 Edge 모델이 3.4.6에서 지원되고 고객이 다운그레이드 전에 이를 확인해야 하는 경우에만 수행할 수 있습니다.
- 문제 19566:
고가용성 페일오버 후에 대기 VMware SD-WAN Edge의 일련번호가 Orchestrator에 활성 일련번호로 표시될 수 있습니다.
- 문제 21342:
세그먼트별로 파트너 게이트웨이를 할당할 때 VMware SD-WAN Edge 모니터링 목록의 운영자 옵션 "보기(View)" 게이트웨이 아래에 적절한 게이트웨이 할당(Gateway Assignments) 목록이 표시되지 않을 수 있습니다.
- 문제 24269:
QoE 그래프에 이 손실이 반영되지만 그래프로 나타내지 않은 모니터링(Monitor) > 전송(Transport) > 손실(Loss)에서 WAN 링크 손실이 확인되었습니다.
- 문제 25932:
VMware SD-WAN Orchestrator를 사용하는 경우에도 VMware SD-WAN Gateway를 게이트웨이 풀에서 제거할 수 있습니다.
- 문제 32335:
사용자가 계약에 동의하려고 하면 'EUSA(최종 사용자 서비스 계약)(End User Service Agreement(EUSA))' 페이지에서 오류가 발생합니다.
해결 방법: 엔터프라이즈 이름에 선행 또는 후행 공백이 없는지 확인합니다.
- 문제 32435:
정책 기반 NAT 구성에 대한 VMware SD-WAN Edge 재정의는 프로필 수준에서 이미 구성된 튜플에 대해 허용되고 그 반대의 경우도 마찬가지입니다.
- 문제 32856:
비즈니스 정책이 허브 클러스터를 사용하여 인터넷 트래픽을 백홀하도록 구성되었지만 사용자는 릴리스 3.2.1에서 릴리스 3.3.x로 업그레이드된 VMware SD-WAN Orchestrator의 프로필에서 허브 클러스터의 선택을 취소할 수 있습니다.
- 문제 32913:
고가용성을 사용하도록 설정한 후 VMware SD-WAN Edge에 대한 멀티캐스트 세부 정보가 모니터링(Monitoring) 페이지에 표시되지 않습니다. 페일오버를 수행하면 문제가 해결됩니다.
- 문제 33026:
계약을 삭제한 후 ‘EUSA(최종 사용자 서비스 계약)(End User Service Agreement(EUSA))’ 페이지가 제대로 다시 로드되지 않습니다.
- 문제 34828:
릴리스 2.x를 사용하는 VMware SD-WAN 스포크 Edge 및 릴리스 3.3.1을 사용하는 허브 Edge 간에 트래픽을 전달할 수 없습니다.
- 문제 35658:
VMware SD-WAN Edge가 한 프로필에서 다른 CSS 설정이 지정된 다른 프로필로 전환되면(예: profile1의 IPsec에서 profile2의 IPsec으로) Edge 수준 CSS 설정은 이전 CSS 설정(예: GRE 대신 IPsec)을 계속 사용합니다.
해결 방법: 이 문제를 해결하려면 Edge 수준에서 GRE를 사용하지 않도록 설정했다가 다시 사용하도록 설정합니다.
- 문제 35667:
VMware SD-WAN Edge가 한 프로필에서 CSS 설정은 동일하지만 GRE CSS 이름(동일한 끝점)은 다른 프로필로 전환되면 일부 GRE 터널이 모니터링 시 표시되지 않습니다.
해결 방법: 이 문제를 해결하려면 Edge 수준에서 GRE를 사용하지 않도록 설정했다가 다시 사용하도록 설정합니다.
- 문제 36665:
VMware SD-WAN Orchestrator가 인터넷에 연결할 수 없는 경우 Google Maps API에 액세스해야 하는 사용자 인터페이스 페이지가 완전히 로드되지 않을 수도 있습니다.
- 문제 38056:
Edge-Licensing export.csv 파일에 지역 데이터가 표시되지 않습니다.
- 문제 38843:
애플리케이션 맵을 푸시할 때 운영자 이벤트가 없으며 Edge 이벤트는 사용이 제한됩니다.
- 문제 39633:
사용자가 대체 게이트웨이를 슈퍼 게이트웨이로 할당한 후에는 슈퍼 게이트웨이 하이퍼링크가 작동하지 않습니다.
- 문제 39790:
VMware SD-WAN Orchestrator는 VMware SD-WAN Edge의 라우팅된 인터페이스를 지원되는 32개의 하위 인터페이스보다 더 많이 유지하도록 허용하므로 사용자가 인터페이스에서 33개 이상의 하위 인터페이스를 구성하여 Edge의 데이터부 서비스 실패를 유발할 위험이 있습니다.
- 문제 40341:
Skype 애플리케이션을 백엔드에서 실시간 트래픽으로 올바르게 분류했지만 VMware SD-WAN Orchestrator에서 Skype 비즈니스 정책을 편집할 때 서비스 클래스에서 "트랜잭션"을 잘못 표시할 수 있습니다.
- 문제 41691:
구성(Configure) > Edge > 디바이스(Device) 페이지에서 DHCP 풀이 고갈되지 않더라도 사용자가 '주소 수(Number of addresses)' 필드를 변경할 수 없습니다.
- 문제 43276:
VMware SD-WAN Edge 또는 프로필에 파트너 게이트웨이가 구성된 경우 사용자는 세그먼트 유형을 변경할 수 없습니다.
- 문제 44153:
VMware SD-WAN Orchestrator는 '경고 및 알림(Alerts and Notifications)' 섹션에 구성된 이메일 주소로 경고 이메일을 일관되게 전송하지 않습니다.
- 문제 46254:
VMware SD-WAN Edge 활성화 동안 VMware SD-WAN Orchestrator는 변경된 WAN 링크 MTU 또는 DHCP 구성 인터페이스에 대한 VLAN ID가 있는지 여부를 감지하지 않습니다.
- 문제 47269:
VMware SD-WAN 510-LTE 인터페이스가 LTE 인터페이스를 지원하지 않는 Edge 모델에 대해 표시될 수 있습니다.
- 문제 47713:
클라우드 VPN을 사용하지 않도록 설정한 상태에서 비즈니스 정책 규칙이 구성된 경우에는 클라우드 VPN을 사용하도록 설정할 때 NAT 구성을 다시 지정해야 합니다.
- 문제 47820:
프로필 수준에서 DHCP를 사용하지 않도록 설정한 상태로 VLAN을 구성했으며 DHCP를 사용하도록 설정한 해당 Edge에서 이 VLAN에 대한 Edge 재정의가 있지만 DNS 서버 필드 집합에 대한 항목이 없음(none)(IP 구성 안 함)으로 설정되면, 사용자는 구성(Configure) > Edge > 디바이스(Device) 페이지에서 변경을 수행할 수 없으며, 실제 문제를 설명하거나 가리키지 않는 '잘못된 IP 주소 []’ 오류 메시지가 표시됩니다.
- 문제 48085:
VMware SD-WAN Orchestrator를 통해 사용자는 인터페이스와 연결된 VLAN을 삭제할 수 있습니다.
- 문제 48737:
릴리스 4.0.0의 새 사용자 인터페이스를 사용하는 VMware SD-WAN Orchestrator의 사용자가 모니터링(Monitor) 페이지에서 시작 및 종료 시간 간격을 변경한 후 탭 간을 이동하면 Orchestrator는 시작 및 종료 간격 시간을 새 값으로 업데이트하지 않습니다.
- 문제 49225:
VMware SD-WAN Orchestrator는 32개의 총 VLAN 제한을 적용하지 않습니다.
- 문제 49790:
VMware SD-WAN Edge가 릴리스 4.0.0으로 활성화되면 활성화가 이벤트(Events)에 두 번 게시됩니다.
해결 방법: 중복 이벤트를 무시합니다.
- 문제 50531:
VMware SD-WAN Orchestrator의 4.0.0 릴리스 버전에서 새 UI에 액세스할 때 서로 다른 권한의 두 운영자가 동일한 브라우저 창을 사용하고 더 낮은 권한의 운영자가 높은 권한의 운영자 다음에 로그인을 시도하는 경우 권한이 더 낮은 운영자에게는 "사용자에게 권한이 없습니다."라는 여러 오류가 표시됩니다.
참고: 더 낮은 권한의 운영자에 대한 권한 에스컬레이션은 수행되지 않으며 오류 메시지만 표시됩니다.
해결 방법: 다음 운영자는 로그인하기 전에 해당 페이지를 새로 고쳐 오류가 표시되지 않도록 하거나, 각 운영자가 다른 브라우저 창을 사용하여 이 표시 문제를 방지할 수 있습니다.
- 문제 51722: 릴리스 4.0.0 VMware SD-WAN Orchestrator에서 시간 범위 선택기는 [모니터링(Monitor)] > [Edge] 탭의 통계에서 2주보다 크지 않습니다.
통계 집합의 보존 기간이 2주보다 긴 경우에도 시간 범위 선택기는 [모니터링(Monitor)] > [Edge] 탭의 "지난 2주(Past 2 Weeks)"보다 큰 옵션을 표시하지 않습니다. 예를 들어, 경로 통계는 기본적으로 2주 동안만 보존되지만(구성 가능) 흐름 및 링크 통계는 기본적으로 365일 동안 보존됩니다(구성 가능). 이 문제는 사용자가 해당 통계의 보존 기간과 일치하는 기간을 선택할 수 있도록 허용하지 않고, 모든 모니터링 탭에서 가장 짧은 통계 유지 기간을 따르도록 합니다.
해결 방법: 시간 범위 선택기에서 "사용자 지정(Custom)" 옵션을 사용하여 2주일보다 오래된 데이터를 볼 수 있습니다.
- 문제 60039: VMware SD-WAN Edge 모델이 변경된 경우 RMA 재활성화가 작동하지 않습니다.
Edge 모델도 변경되는 사이트에 대해 RMA 재활성화를 수행할 때 VMware SD-WAN Orchestrator가 모델 변경을 저장하지 못하여 재활성화 링크가 작동하지 않게 됩니다. 이로 인해 Edge 모델이 변경된 RMA 재동기화에만 영향을 미치며, Edge 모델이 동일하게 유지되는 RMA 재동기화는 예상대로 작동됩니다.
해결 방법: 사이트에 다른 Edge 모델을 사용하는 경우 사용자는 새 Edge를 생성하고 모든 Edge 관련 설정을 수동으로 적용해야 합니다.
