| VMware SASE 5.0.1 | 2023년 4월 25일 업데이트 |
이 릴리스 정보의 추가 사항 및 업데이트 사항을 확인하십시오. |
| VMware SASE 5.0.1 | 2023년 4월 25일 업데이트 |
이 릴리스 정보의 추가 사항 및 업데이트 사항을 확인하십시오. |
릴리스 정보에는 다음과 같은 항목이 포함됩니다.
이 릴리스는 릴리스 5.0.0에서 처음으로 제공하는 기능이 필요한 모든 고객뿐 아니라 아래에 나열되어 있으나 릴리스 5.0.0 이후에 해결된 문제의 영향을 받은 고객에게 권장됩니다.
릴리스 5.0.1 Orchestrator, 게이트웨이 및 허브 Edge는 릴리스 3.2.2 이상의 모든 이전 VMware SD-WAN Edge 버전을 지원합니다.
릴리스 5.0.1은 유지 보수 릴리스로 분류되며, 프로토콜이 해당 프로토콜이 속한 주/부 릴리스와 동일하기 때문에 유지 보수 릴리스는 상호 운용성 테스트 일부를 진행합니다. 이 프로토콜 버전과 함께 테스트된 다른 소프트웨어 버전 목록은 VMware SASE 5.0.0 릴리스 정보를 참조하십시오.
다음과 같은 SD-WAN 상호 운용성 조합은 명시적으로 테스트되었습니다.
| Orchestrator |
게이트웨이 |
Edge |
|
| 허브 |
분기/스포크 |
||
| 5.0.1 |
5.0.1 |
4.3.1 |
4.3.1 |
| 5.0.1 |
5.0.1 |
4.5.0 |
4.5.0 |
| 5.0.1 |
5.0.1 |
5.0.0 |
5.0.0 |
| 5.0.1 |
4.3.1 |
4.3.1 |
4.3.1 |
| 5.0.1 |
4.5.0 |
4.5.0 |
4.5.0 |
| 5.0.1 |
5.0.0 |
5.0.0 |
5.0.0 |
| 5.0.0 |
5.0.1 |
5.0.1 |
5.0.1 |
위 표는 SD-WAN 서비스를 사용하는 고객에게만 유효합니다. VMware Cloud Web Security 또는 VMware Secure Access에 액세스해야 하는 고객은 해당 Edge를 릴리스 4.5.0 이상으로 업그레이드해야 합니다.
VMware SD-WAN 릴리스 3.2.x, 3.3.x 및 3.4.x는 지원 종료되었습니다.
릴리스 3.2.x 및 3.3.x는 2021년 12월 15일에 EOGS(일반 지원 종료), 2022년 3월 15일에 EOTG(기술 지침 종료)에 도달했습니다.
Orchestrator 및 게이트웨이에 대해 릴리스 3.4.x는 2022년 3월 30일에 EOGS(일반 지원 종료)에 도달했으며, 2022년 9월 30일에 EOTG(기술 지침 종료)에 도달하게 됩니다.
Edge용 릴리스 3.4.x는 2022년 12월 31일에 EOGS(지원 종료)에 도달했으며 2023년 3월 31일에 EOTG(기술 지침 종료)에 도달했습니다.
자세한 내용은 기술 자료 문서를 참조하십시오. 알림: VMware SD-WAN 릴리스 3.x(84151)의 지원 기간 종료
VMware SD-WAN 릴리스 4.0.x는 지원 종료에 도달했고, 릴리스 4.2.x는 게이트웨이 및 Orchestrator에 대한 지원 종료에 도달했고, 4.3.x는 게이트웨이 및 Orchestrator에 대한 지원 종료에 도달하게 됩니다.
릴리스 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(일반 지원 종료)에 도달하고 2025년 9월 30일에는 EOTG(기술 지침 종료)에 도달하게 됩니다.
릴리스 4.3.x Orchestrator 및 게이트웨이는 2023년 6월 30일에 EOGS(일반 지원 종료)에 도달하고 2023년 9월 30일에는 EOTG(기술 지침 종료)에 도달하게 됩니다.
릴리스 4.3.x Edge는 2023년 6월 30일에 EOGS(일반 지원 종료)에 도달하고 2025년 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 중에서 선택할 수 있습니다.
다음은 Orchestrator, 게이트웨이 또는 Edge를 이전 릴리스에서 릴리스 5.0.1으로 업그레이드하려는 고객을 위한 경로입니다.
Orchestrator
릴리스 4.0.0부터 진행된 Orchestrator의 인프라 변경으로 인해 3.x 릴리스를 사용하는 Orchestrator는 5.0.1로 업그레이드하기 전에 먼저 4.0.0으로 업그레이드해야 합니다. 릴리스 4.0.0 이상을 사용하는 Orchestrator를 릴리스 5.0.1로 업그레이드할 수 있습니다. 따라서 Orchestrator의 업그레이드 경로는 다음과 같습니다.
릴리스 3.x를 사용하는 Orchestrator → 4.0.0 → 5.0.1.
릴리스 4.x를 사용하는 Orchestrator → 5.0.1.
게이트웨이
3.x에서 5.0.1로의 게이트웨이 업그레이드는 지원되지 않습니다. 3.x 게이트웨이는 업그레이드하는 대신 동일한 VM 특성으로 새로 배포해야 하며 이전 인스턴스는 더 이상 사용되지 않습니다.
릴리스 4.0.0 이상을 사용하여 게이트웨이를 업그레이드하는 것은 모든 게이트웨이 유형에 대해 완전히 지원됩니다.
참고: 5.0.1을 사용하여 새 게이트웨이를 배포하는 경우 VMware ESXi 인스턴스는 6.7 Update 3 버전 이상, 7.0 버전 이하여야 합니다. 이전 ESXi 인스턴스를 사용하면 릴리스 5.0.0 이상을 실행하려고 할 때 게이트웨이의 데이터부 서비스가 실패합니다.
참고: 게이트웨이를 5.0.1으로 업그레이드하기 전에 ESXi 인스턴스를 6.7, Update 3, 버전 7.0 이상으로 업그레이드해야 합니다. 이전 ESXi 인스턴스를 사용하면 릴리스 5.0.1 이상을 실행하려고 할 때 게이트웨이의 데이터부 서비스가 실패합니다.
Edge
Edge는 모든 릴리스 3.x 이상에서 릴리스 5.0.1로 바로 업그레이드할 수 있습니다.
고가용성에서 Wi-Fi 지원 및 비 Wi-Fi 지원 Edge를 혼합해서 사용할 수 없음
2021년부터 VMware SD-WAN Edge 모델 510N, 610N, 620N, 640N 및 680N과 같이 Wi-Fi 모듈이 포함되지 않은 Edge 모델을 도입했습니다. 이러한 모델은 Wi-Fi를 제외한 Wi-Fi 지원 Edge와 동일하게 나타나지만 동일한 모델의 Wi-Fi 지원 Edge 및 비 Wi-Fi 지원 Edge(예: Edge 640 및 Edge 640N)를 고가용성 쌍으로 배포하는 것은 지원되지 않습니다. 고객은 고가용성 쌍으로 배포된 Edge가 동일한 유형(Wi-Fi 지원 또는 비 Wi-Fi 지원 모두)인지 확인해야 합니다.
Orchestrator에서 더 이상 Grafana를 사용할 수 없음
릴리스 5.0.0 이상 Orchestrator는 라이센스 제한으로 인해 Grafana 애플리케이션을 포함하지 않습니다. Grafana는 Orchestrator의 성능을 모니터링하기 위해 Orchestrator 온-프레미스를 실행하는 고객 및 파트너가 주로 사용합니다. 이러한 요구 사항을 위해 고객 또는 파트너는 Orchestrator 외부에서 자체 Grafana 애플리케이션을 호스팅하고 Orchestrator의 Telegraf가 이를 가리키도록 구성해야 합니다.
VMware SASE 빌드에 네 번째 숫자가 포함됨
릴리스 5.0.0부터는 이제 릴리스 빌드에 네 번째 숫자가 포함됩니다.
소프트웨어 릴리스의 경우 VMware SASE는 a.b.c 번호 지정 체계를 따릅니다. 여기서는 다음이 적용됩니다.
a = 주 버전(예: 5.0.0) → 여러 개의 큰 기능과 잠재적으로 중요한 아키텍처 변경 내용이 포함된 릴리스입니다.
b = 부 버전(예: 5.2.0) → 여러 가지 작은 기능이나 두어 개의 큰 기능이 있고 아키텍처가 크게 변경되지 않은 릴리스입니다.
c = 유지 보수(예: 5.2.1) → 필드의 발견된 문제에 대해 잠재적으로 많은 수정 사항이 있고, 내부적으로 발견된 문제에 대해 새로운 하드웨어 플랫폼 지원을 제외하고는 기능이 없는 수정 사항을 포함하는 릴리스입니다.
릴리스 5.0.0에서는 Edge, 게이트웨이 및 Orchestrator 빌드에 네 번째 숫자가 추가되므로 번호 지정 체계는 a.b.c.d입니다.
d = 롤업 빌드(예: 5.2.1.1) → 롤업은 알려진 고객이 찾은 결함 수정 사항 또는 중요한 내부 발견 결함의 누적 집계입니다.
4.x 이하 버전의 롤업 빌드는 이미지 이름의 GA 날짜로 구분되며, 이것은 고객에게 빌드 버전을 전달하는 최적의 방법이 아닙니다. 5.0.0 빌드 이상에서 네 번째 숫자를 추가하게 되어 특정 구성 요소에서 사용 중인 소프트웨어 버전을 더욱 명확하게 확인할 수 있습니다.
이 빌드 번호 지정 규칙은 릴리스 5.0.0 이상에만 적용되며 4.x 이하 릴리스는 롤업 빌드가 기존의 날짜별 방식으로 식별되는 3자리 숫자로 계속됩니다.
Cloud Web Security 및 Secure Access 액세스
VMware Cloud Web Security 또는 VMware Secure Access에 액세스하려는 고객은 Edge를 릴리스 4.5.0 이상으로 업그레이드해야 합니다. 이러한 서비스는 4.5.0 이전 릴리스를 사용하는 Edge에서 액세스할 수 없습니다.
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 또는 5.x로 업그레이드하는 고객은 올바르지 않은 BGP 최적 경로 선택을 방지하기 위해 AS-PATH prepending 구성을 편집하여 "쉼표를 공백으로 교체"해야 합니다.
Edge 3x00 모델에 대해 확장된 업그레이드 시간
Edge 3x00 모델(예: 3400, 3800 및 3810)에서 이 버전으로 업그레이드하는 데 평균 업그레이드 시간(3~5분)보다 오래 걸릴 수 있습니다. 이는 문제 53676을 해결하는 펌웨어 업그레이드 때문에 발생합니다. 이전에 릴리스 3.4.5/3.4.6, 4.0.2, 4.2.1, 4.3.0, 4.5.0 또는 5.0.0에서 펌웨어를 업그레이드한 Edge 3400 또는 3800은 예상대로 업그레이드됩니다. 자세한 내용은 해당 릴리스 정보의 해결된 문제 53676을 참조하십시오.
Edge 및 게이트웨이의 IPsec을 통한 BGP 및 Azure Virtual WAN Automation에 대한 제한 사항
Edge 및 게이트웨이의 IPsec을 통한 BGP 기능은 Edge 또는 게이트웨이의 Azure Virtual WAN Automation과 호환되지 않습니다. Edge 또는 게이트웨이에서 Azure vWAN으로의 연결을 자동화할 때 고정 경로만 지원됩니다.
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)에서 자동 협상 기능을 비활성화할 경우의 제한 사항을 참조하십시오.
2022년 8월 5일. 1차 개정판.
2022년 8월 11일. 2차 개정판.
Orchestrator의 해결된 문제 섹션에 해결된 문제 #89346, #90067, #90128, #90540, #91054, #91720 및 #92082를 추가했습니다. 이러한 티켓은 5.0.1 릴리스 정보의 첫 번째 개정판에서 발생하는 오류로 인해 생략되었습니다.
2022년 8월 15일. 3차 개정판.
Edge/게이트웨이의 해결된 문제 섹션에 해결된 문제 #89217을 추가했습니다. 이 티켓은 5.0.1 릴리스 정보의 첫 번째 개정판에서 발생하는 오류로 인해 생략되었습니다.
2022년 8월 18일. 4차 개정판.
Orchestrator의 해결된 문제 섹션에 업데이트된 Orchestrator 빌드 R5010-20220817-GA를 추가했습니다. 빌드 R5010-20220817-GA는 원래 Orchestrator 빌드 R5010-20220803-GA를 대신하며 릴리스 5.0.1에 대한 새로운 Orchestrator GA 빌드입니다.
이 업데이트된 Orchestrator 빌드에는 Orchestrator의 해결된 문제 섹션에 추가된 문제 #95613에 대한 수정 사항이 포함되어 있습니다.
2022년 9월 9일 5차 개정판.
Edge/게이트웨이의 해결된 문제 섹션에 해결된 문제 #87552, #90151 및 #93383을 추가했습니다. 이러한 티켓은 5.0.1 릴리스 정보의 첫 번째 개정판에서 발생하는 오류로 인해 생략되었습니다.
Edge/게이트웨이의 알려진 문제에 포함되어 있는 미해결 문제 #49712를 엔지니어링 팀에서 코드 결함이 아닌 구성 오류에 의한 것으로 결론지었으므로 알려진 문제 목록에서 제거되었습니다.
엔지니어링에서 문제를 재현하지 못하고 DR 동기화가 5.0.1 Orchestrator 빌드에서 예상대로 작동하므로 Edge/게이트웨이의 알려진 문제에서 미해결 문제 #90065가 제거되었습니다.
2022년 9월 16일. 6차 개정판.
Orchestrator의 해결된 문제 섹션에 업데이트된 Orchestrator 빌드 R5010-20220912-GA를 추가했습니다. 빌드 R5010-20220912-GA는 원래 Orchestrator 빌드 R5010-20220817-GA를 대신하며 릴리스 5.0.1에 대한 새로운 Orchestrator GA 빌드입니다.
이 업데이트된 Orchestrator 빌드에는 Orchestrator의 해결된 문제 섹션에 추가된 문제 #90749, #95847 및 #96095에 대한 수정 사항이 포함되어 있습니다.
Edge/게이트웨이의 해결된 문제 섹션에 해결된 문제 #91875를 추가했습니다. 이 티켓은 5.0.1 릴리스 정보의 첫 번째 개정판에서 발생하는 오류로 인해 생략되었습니다.
Edge/게이트웨이의 알려진 문제 섹션에 문제 #96055 및 #96231을 추가했습니다.
2022년 9월 23일. 7차 개정판.
Orchestrator의 해결된 문제 섹션에서 Orchestrator 빌드 R5010-20220912-GA에 해결된 문제 #96108을 추가했습니다. 이 문제는 이 릴리스 정보의 6차 개정판 오류에서 생략되었습니다.
Orchestrator의 해결된 문제 섹션에서 해결된 문제 #90749가 Orchestrator 빌드 R5010-20220912-GA에서 원래 Orchestrator 빌드 R5010-20220803-GA로 이동했습니다. 이 문제의 경우 릴리스 5.0.1에서 실제로 문제 해결이 추가되었습니다.
Edge/게이트웨이의 해결된 문제 섹션에 해결된 문제 #87982을 추가했습니다. 이 티켓은 5.0.1 릴리스 정보의 첫 번째 개정판에서 발생하는 오류로 인해 생략되었습니다.
Edge/게이트웨이의 알려진 문제 섹션에 미해결 문제 #86098, #94204, #95565, #96441 및 #96888을 추가했습니다.
2022년 9월 28일. 8차 개정판.
Edge/게이트웨이의 알려진 문제 섹션에 #98136을 추가했습니다.
2022년 10월 12일. 9차 개정판.
Edge 및 게이트웨이의 해결된 문제 섹션에 새로운 Edge/게이트웨이 롤업 빌드 R5011-20221007-GA를 추가했습니다. 이것은 첫 번째 Edge/게이트웨이 롤업 빌드 및 릴리스 5.0.1에 대한 새로운 Edge/게이트웨이 GA 빌드입니다.
Edge/게이트웨이 빌드 R5011-20221007-GA에는 이 섹션에 설명된 해결된 문제 #89235, #94430, #95503, #96055, #96231, #98157 및 #99188을 포함합니다.
2022년 10월 18일. 10차 개정판.
기존 5.0.1 GA 빌드 R5010-20220729-GA에 대해 Edge/게이트웨이 해결된 문제 섹션에 해결된 문제 #90876이 추가되었습니다. 이 문제는 5.0.1 릴리스 정보의 1차 개정판에서 발생하는 오류로 인해 생략되었습니다.
2022년 10월 31일. 11차 개정판.
기존 5.0.1 GA 빌드 R5010-20220729-GA에 대해 Edge/게이트웨이 해결된 문제 섹션에 해결된 문제 #72491이 추가되었습니다. 이 문제는 5.0.1 릴리스 정보의 1차 개정판에서 발생하는 오류로 인해 생략되었습니다.
2022년 11월 14일. 12차 개정판.
Edge/게이트웨이의 해결된 문제 섹션에 새로운 Edge 롤업 빌드 R5012-20221107-GA를 추가했습니다. 이는 두 번째 Edge 롤업 빌드이고 릴리스 5.0.1에 대한 새로운 Edge GA 빌드이며 Edge 릴리스 5.0.x.x를 실행하는 모든 고객에게 권장됩니다.
Edge 빌드 R5012-20221107-GA에는 이 섹션에 설명된 해결된 문제 #96411, #96441, #96888, #97483, #98514, #100377 및 #101049를 포함합니다.
이전 Edge 5.0.x.x 빌드를 사용하는 경우 Edge를 5.0.1.2로 업그레이드해야 합니다.
2022년 11월 22일. 13차 개정판.
Orchestrator 해결된 문제 섹션에 새로운 Orchestrator 롤업 빌드 R5011-20221117-GA를 추가했습니다. 이는 첫 번째 Orchestrator 롤업 빌드이며 릴리스 5.0.1에 대한 새로운 Orchestrator GA 빌드입니다.
Orchestrator 빌드 R5011-20221117-GA에는 #80735, #88957, #97713, #98086, #98357, #98518, #98654, #99109, #99247, #99250, #100656 및 #101449 문제에 대한 수정 사항이 포함되어 있으며 각각은 이 섹션에 문서화되어 있습니다.
Edge/게이트웨이의 해결된 문제 섹션에 해결된 문제 #89873을 추가했습니다. 이 문제는 5.0.1 릴리스 정보의 1차 개정판에서 발생하는 오류로 인해 생략되었습니다.
Edge/게이트웨이의 알려진 문제에 미해결 문제 #97559를 추가했습니다.
2022년 11월 30일. 14차 개정판.
Orchestrator 롤업 빌드 R5011-20221117-GA를 수정된 빌드 R5011-20221129-GA로 대체했습니다. 이를 통해 Orchestrator를 업그레이드하여 R5011-20221117-GA를 빌드할 때 VMware 운영 팀에게 확인되는 업그레이드 문제가 해결되었습니다. 이 업그레이드 문제는 업그레이드 패키지 매니페스트의 버전 불일치로 인해 발생했으며 이 새 빌드에는 추가된 새 기능이 없습니다.
2022년 12월 16일. 15차 개정판.
Edge/게이트웨이의 해결된 문제 섹션에 새로운 게이트웨이 롤업 빌드 R5012-20221214-GA를 추가했습니다. 이는 두 번째 게이트웨이 롤업 빌드이며 릴리스 5.0.1에 대한 새로운 게이트웨이 GA 빌드입니다.
게이트웨이 빌드 R5012-20221214-GA에는 이 섹션에 설명된 문제 #96863, #97272 및 #99650에 대한 수정 사항이 포함되어 있습니다.
원래 5.0.1.1 게이트웨이 빌드(R5011-20221007-GA)의 빌드 문제로 인해 게이트웨이를 다른 5.0.1.1 게이트웨이 빌드로 업그레이드할 수 없으며 5.0.1.1에서 5.0.1.2로 직접 업그레이드해야 합니다.
Orchestrator 해결된 문제 섹션에 새로운 Orchestrator 롤업 빌드 R5012-20221214-GA를 추가했습니다. 이는 두 번째 Orchestrator 롤업 빌드이며 릴리스 5.0.1에 대한 새로운 Orchestrator GA 빌드입니다.
Orchestrator 빌드 R5012-20221214-GA에는 이 섹션에 설명된 문제 #96538, #100133, #101835 및 #102806에 대한 수정 사항이 포함되어 있습니다.
2023년 1월 30일. 16차 개정판.
문제 해결에 필요한 수정된 Edge 버전 (R5012-20230123-GA-103475) 및 플랫폼 펌웨어 버전 (R131-20221216-GA)를 반영하도록 고정 티켓 #89217을 수정했습니다. 또한 이 티켓은 #89217을 포함하며 6x0 Edge 업그레이드를 위한 단계별 지침이 포함된 KB 문서에 대한 링크를 추가합니다.
호환성 섹션에서 4.2.x에 대한 지원 종료와 관련된 가져오기 참고 사항을 수정하고 SD-WAN Edge 소프트웨어에 대해 새로 수정된 날짜를 반영하도록 릴리스 4.3.x를 추가했습니다.
2023년 2월 17일. 17차 개정판.
릴리스 4.3.0에서 해결된 다른 티켓 #39501과 중복되므로 Edge/게이트웨이의 알려진 문제 섹션에서 문제 #39659가 제거되었습니다.
2023년 3월 15일. 18차 개정판.
Orchestrator 해결된 문제 섹션에 새로운 Orchestrator 롤업 빌드 R5013-20230310-GA를 추가했습니다. 이것은 세 번째 Orchestrator 롤업 빌드이며 릴리스 5.0.1에 대한 새로운 Orchestrator GA 빌드입니다.
Orchestrator 빌드 R5013-20230310-GA에는 이 섹션에 설명된 문제 #105610, #106242 및 #109595에 대한 수정 사항이 포함되어 있습니다.
2023년 3월 26일. 19차 개정판.
Edge 및 게이트웨이의 해결된 문제 섹션에 새로운 Edge/게이트웨이 롤업 빌드 R5013-20230322-GA를 추가했습니다. 이것은 세 번째 Edge/게이트웨이 롤업 빌드이며 릴리스 5.0.1에 대한 새로운 Edge 및 게이트웨이 GA 빌드입니다.
Edge 및 게이트웨이 빌드 R5013-20230322-GA에는 문제 #78050, #80149, #84593, #86994, #95603, #96880, #97404, #97559, #98782, #99676, #103527, #103529, #103983, #104141, #104183, #104487, #105360, #105744, #106627, #106700, #107302, #107309, #107356 및 #109131에 대한 수정 사항이 포함되어 있으며 각 문제는 이 섹션에 설명되어 있습니다.
2023년 4월 12일. 20차 개정판.
Orchestrator 해결된 문제 섹션에 새로운 Orchestrator 롤업 빌드 R5014-20230408-GA를 추가했습니다. 이것은 네 번째 Orchestrator 롤업 빌드이며 릴리스 5.0.1에 대한 새로운 Orchestrator GA 빌드입니다.
Orchestrator 빌드 R5014-20230408-GA에는 이 섹션에 설명된 문제 #107766, #108363, #110946, #111946, #111957 및 #112201에 대한 수정 사항이 포함되어 있습니다.
Edge/게이트웨이의 알려진 문제에 미해결 문제 #94980 및 #110564를 추가했습니다.
문제 해결에 필요한 수정된 Edge 버전 (R5012-20230327-GA-107522)를 반영하도록 고정 티켓 #89217을 수정했습니다. Edge 버전 R5012-20230327-GA-107522는 Orchestrator를 통해 고가용성 토폴로지에 배포된 사이트를 자동으로 업그레이드하는 기능을 추가적으로 제공합니다. 이 문제 해결과 관련된 이전 Edge 버전인 R5012-20230123-GA-103475에는 해당 기능이 포함되지 않았으며 호스팅된 모든 Orchestrator에서 성능 저하됨으로 표시됩니다.
2023년 4월 25일. 21차 개정판.
원본 GA 빌드 R5010-20220729-GA에 대한 Edge/게이트웨이의 해결된 문제 섹션에 해결된 문제 #93052가 추가되었습니다. 이 문제는 5.0.1 릴리스 정보의 1차 개정판에서 발생하는 오류로 인해 생략되었습니다.
호환성 섹션이 업데이트되어 모든 3.x 릴리스가 EOSL(서비스 수명 종료)에 도달한 것으로 표시되었습니다. 또한 4.2.x Orchestrator 및 게이트웨이를 EOSL(서비스 수명 종료)으로 표시하도록 4.x 섹션이 업데이트되었습니다.
Edge/게이트웨이 빌드 R5013-20230322-GA는 2023년 03월 25일에 릴리스되었으며 릴리스 5.0.1에 대한 세 번째 Edge/게이트웨이 롤업입니다.
이 Edge/게이트웨이 롤업 빌드는 두 번째 Edge/게이트웨이 롤업 빌드, R5012-20221214-GA 이후의 아래와 같은 중요한 문제를 해결합니다.
해결된 문제 78050: LAN 측에 PPTP 서버가 있는 경우 VMware SD-WAN Edge에서 데이터부 서비스 장애가 발생할 수 있습니다.
PPTP 서버가 LAN 측에 있고 인터넷의 PPTP 클라이언트가 인바운드 방화벽 규칙을 통해 연결하면 PPTP 제어 채널 조회 실패로 인해 Edge 서비스가 실패할 수 있습니다. GRE 데이터 채널이 동일한 링크를 통해 PPTP 클라이언트로 다시 전송되도록 하려면 이 제어 채널 조회가 필요합니다.
이 문제에 대한 수정 사항 없는 빌드를 사용하는 Edge에서 고객의 유일한 대안은 PPTP 세션을 사용하지 않는 것입니다.
해결된 문제 80149: 중복 터널이 있는 NSD(비 SD-WAN 대상) 또는 CSS(클라우드 보안 서비스)에 대해 L7(계층 7) 상태 점검이 활성화되면 고객에게 두 터널이 동시에 종료된 것으로 표시될 수 있으며 기본 터널에 전송 문제가 있는 경우 간헐적으로 작동하는 문제가 발생할 수 있습니다.
이 문제가 발생하면 기본 터널 및 보조 터널 모두에 대한 L7 프로브가 기본 터널 인터페이스를 통해 전송됩니다. 기본 터널 인터페이스에 패킷 전송 실패(예: 높은 지연 시간)가 발생하는 경우 기본 및 보조 L7 프로브 패킷 모두에 영향을 미치며 터널이 동시에 해체되어 해당 NSD 또는 CSS에 대한 고객 트래픽에 영향을 미칩니다.
해결된 문제 84593: KVM 유형을 사용하는 VMware SD-WAN 가상 Edge에 대해 터널이 실행되지 않을 수 있습니다.
각 패킷에 4개의 추가 트레일러 바이트를 추가하는 FCS(프레임 검사 순서)를 사용하여 패킷을 수신하면 프로세스가 실제 패킷 길이를 사용하는 대신, 수신된 프레임 길이를 암호 해독 작업에서 사용하기 때문에 DPDK IPsec 프로세스가 패킷의 암호를 해독하지 못합니다. 그 결과 KVM Edge가 게이트웨이 또는 Orchestrator에 대한 IPsec 터널을 구축할 수 없습니다.
해결된 문제 86994: 동적 분기 간이 활성화된 고객 엔터프라이즈에서 이 엔터프라이즈의 VMware SD-WAN Edge 문제를 해결하려고 할 때 dispcnt 디버그 명령이 작동하지 않습니다.
dispcnt 디버그 명령이 모든 카운터 값을 제공하지 않으며 Domain (null) does not exist가 표시되면서 실패합니다. Edge 진단 번들에서 관련 로그를 참조할 때도 실패합니다. 이는 고객 네트워크 문제 해결에 심각한 지장을 일으킵니다.
이 문제는 각 피어에 대해 생성 및 해체된 대량의 터널로 인해 동적 분기 간이 활성화된 엔터프라이즈에서 발생합니다. 피어의 다양한 메트릭을 저장하는 카운터는 공유 메모리에 저장되고, 시간이 지남에 따라 이러한 공유 메모리 세그먼트는 충돌로 인해 잘못된 상태가 되며 dispcnt 명령을 통해 카운터를 가져오지 못합니다.
이 문제는 Edge의 서비스를 다시 시작해야만 해결할 수 있습니다.
해결된 문제 95603: Zscaler 서버가 IP 주소를 변경하면 DNS 조회에서 이전 IP 주소를 계속 사용하므로 NSD(비 SD-WAN 대상) 터널 오류가 발생합니다.
원격 서버가 IP 주소를 변경하면 L7 상태 점검이 실패하고 복구되지 않습니다. 이 문제에 대한 수정 사항은 IP 주소 변경을 검색하고 L7 상태 점검 테이블을 플러시합니다.
이 문제에 대한 수정 사항이 없는 VMware SD-WAN에서 Edge를 재부팅하면 터널이 다시 설정됩니다.
해결된 문제 96880: 원격 IPv6 경로가 VMware SD-WAN Edge에 없을 수 있습니다.
이 문제는 세그먼트에 IPv6 주소가 하나만 있지만 상위 라우팅 인터페이스에 IPv6 주소가 없는 경우에 발생합니다.
이 문제에 대한 수정 사항이 없는 Edge에서 해결 방법은 상위 인터페이스에서 IPv6 주소를 구성하는 것입니다.
해결된 문제 97404: VMware SD-WAN Edge IPv6/IPv4 인터페이스가 다른 세그먼트로 이동되면 Edge는 새 세그먼트에서 해당 IPv6/IPv4 원격 경로를 학습하지 않고 원격 경로가 이전 세그먼트에서 유지됩니다.
이 시나리오에서 Edge 경로 학습은 실패합니다. 인터페이스가 한 세그먼트에서 다른 세그먼트로 이동될 경우 구성 변경을 완료하기 위해 Edge 프로세스를 다시 시작해야 하는데 이 문제에서 해당 작업이 수행되지 않기 때문입니다(Edge 다시 시작 동작 변경으로 인해 발생 https://kb.vmware.com/s/article/60247).
이 문제에 대한 수정 사항을 적용하지 않은 Edge에서 사용자는 원격 작업(Remote Actions) > 서비스 다시 시작(Restart Service)을 실행하여 구성 변경을 완료할 수 있습니다. 이 작업은 적절한 유지 보수 기간에 수행해야 합니다.
해결된 문제 97559: 향상된 고가용성 토폴로지로 배포된 고객 사이트에서 대기 역할의 VMware SD-WAN Edge에 연결된 WAN 링크가 VMware SASE Orchestrator에서 종료된 것으로 표시되고 WAN 링크가 연결된 Edge의 WAN 인터페이스가 실행 중인 경우에도 고객 트래픽을 전달하지 않을 수 있습니다.
tcpdump 또는 진단 번들 로깅을 살펴보는 사용자는 ARP 요청이 들어오고 해당 포트 차단으로 인해 [대기(Standby)] Edge가 응답하지 않는 것을 확인할 수 있습니다. 고급 HA에서 Edge가 대기 역할을 가정할 때는 다음 이벤트가 순서대로 발생합니다.
대기 Edge는 모든 포트를 차단합니다.
그런 다음, 대기 Edge는 향상된 HA에 배포되었음을 감지하고 트래픽을 전달하기 위해 WAN 포트를 차단 해제합니다.
이 문제가 발생하면 이벤트 1에서 초기 포트 차단을 완료하는 데 예기치 않게 긴 시간이 걸리고 후속 이벤트 2에서 이벤트 1이 완료되기 전에 모든 WAN 포트의 차단 해제가 완료됩니다. 그런 다음, 이벤트 1이 완료되므로 최종 상태는 대기 Edge에서 모든 WAN 포트가 차단된 상태입니다.
이 문제에 대한 수정 사항을 적용하지 않은 HA Edge에서 해결 방법은 대기 Edge를 [활성(Active)]으로 승격하는 HA 페일오버를 강제로 수행하여 HA Edge의 WAN 링크를 작동하는 것입니다.
해결된 문제 98782: VMware SD-WAN Gateway에서 IPsec Tunnel을 설정하는 동안 데이터부 서비스 장애가 발생하여 코어가 생성되고, 결과적으로 다시 시작될 수 있습니다.
[게이트웨이(Gateway)]에서 이 문제가 발생하면 해당 [게이트웨이(Gateway)]와 그 [게이트웨이(Gateway)]를 IPsec Tunnel 연결에 사용하는 [비 SD-WAN 대상(Non SD-WAN Destinations)]에 연결된 Edge 모두 재시작으로 인해 고객 트래픽이 잠시 중단될 수 있습니다. 이 문제는 [게이트웨이(Gateway)]가 IPsec Tunnel을 설정할 때 발생하는 경합 조건으로 인해 데이터부 서비스 장애가 트리거되기 때문에 발생합니다.
해결된 문제 99676: Wavefront를 사용하여 VMware SD-WAN Gateway를 모니터링하는 고객의 경우 출력에 코어 사용량, 네트워크 인터페이스(netif) 및 코어당 메트릭이 포함되지 않습니다.
게이트웨이 릴리스 5.0.1.3에는 게이트웨이 코어 사용량, netif 및 코어당 메트릭을 Wavefront 모니터링 서비스로 내보낼 수 있는 향상된 기능이 포함되어 있습니다.
해결된 문제 103527: 연결이 끊긴 후 PPTP(지점 간 터널링 프로토콜) 세션이 다시 설정되지 않습니다.
PPTP 세션이 다시 연결되면 Edge는 호출 요청/회신 재전송이 표시되지만, 전송된 응답을 수신하는 즉시 Edge는 GRE-NAT 항목을 지우지 않고 오류를 반환합니다. 기존 GRE-NAT 항목으로 인해 추가 연결 시도가 삭제됩니다.
이 문제에 대한 수정 사항이 없는 Edge에서 해결 방법은 원격 진단(Remote Diagnostics) > NAT 플러시(Flush NAT)를 실행하여 NAT 데이터베이스를 지우는 것입니다.
해결된 문제 103529: 하나 이상의 1:1 NAT 규칙이 구성된 고가용성 토폴로지를 사용하는 고객 사이트의 경우 HA 페일오버 후에 1:1 NAT 규칙을 사용하는 트래픽이 삭제될 수 있습니다.
1:1 NAT가 구성된 HA 설정의 Edge에서 해당 흐름이 대기 Edge와 동기화되면 흐름 동기화 테이블에 정보가 누락되어 잘못된 대상 경로가 선택되고 잘못된 경로 선택으로 인해 트래픽이 삭제될 수 있습니다.
이 문제에 대한 수정 사항을 적용하지 않은 HA Edge 쌍에서 원격 진단(Remote Diagnostic) > 흐름 플러시(Flush Flows)를 실행하면 다음 HA 페일오버까지 일시적으로 문제가 해결됩니다.
해결된 문제 103983: 중복 터널을 사용하는 Edge를 통한 비 SD-WAN 대상(Non SD-WAN Destination via Edge)이 있고 L7 상태 점검 기능을 설정한 VMware SD-WAN Edge의 경우 기본 터널이 종료되면 백업 터널도 종료되어 이 NSD를 사용하는 모든 트래픽이 삭제됩니다.
이 문제는 L7 프로브가 잘못된 경로로 이동하기 때문에 발생하며 이로 인해 Edge는 기본 터널에 대해 프로브가 실패할 때 기본 터널과 함께 보조 터널도 종료되었는지 확인합니다.
해결된 문제 104141: VMware SD-WAN Edge 뒤에 있는 사용자 또는 VMware SD-WAN Gateway에 연결된 고객은 해당 Edge를 사용하거나, 해당 [게이트웨이(Gateway)]를 통과해서 트래픽이 전달되지 않을 수 있는 지점까지 이동하는 트래픽으로 인해 심각한 문제가 발생할 수 있습니다.
이 문제가 발생하면 Edge 또는[게이트웨이(Gateway)]는 피어에서 수신된 관리 Tunnel 타임스탬프의 증가로 인해 지터 버퍼 대기열에서 제한되지 않은 수의 메모리 버퍼(mbufs)가 사용됩니다. 이로 인해 지터 계산에서 정수 언더플로가 트리거되어 패킷이 무기한으로 효과적으로 버퍼링됩니다. 처음에는 버퍼링된 흐름에만 영향을 주지만, 충분한 기간에 걸쳐 지터 버퍼 대기열에 사용되는 mbuf 수가 사용 가능한 총 mbuf 수에 가까워지고 SD-WAN 디바이스(Edge 또는 [게이트웨이(Gateway)])가 모든 트래픽을 완전히 전달하지는 못할 수 있습니다. 이 문제가 [게이트웨이(Gateway)]에 영향을 미치는 경우 [게이트웨이(Gateway)]를 통과하는 다중 경로 트래픽에만 영향을 미치며 직접 이동하는 고객 트래픽은 영향을 받지 않습니다.
또 다른 티켓인 #105744는 여기에서 발견된 증상을 해결할 뿐만 아니라 별도의 원인을 해결합니다. 두 티켓의 차이점: #104141에 포함된 수정 사항은 피어에서 수신되는 관리 타임스탬프의 증가로 인해 지터 버퍼 대기열에서 사용되는 메모리 버퍼를 해결합니다. #105744에 포함된 수정 사항은 이 문제가 재발할 수 없도록 하기 위해 어떤 상황이 발생하든 지터 버퍼 수를 총 메모리 버퍼의 25%로 제한합니다.
Edge 또는 [게이트웨이(Gateway)]에 이 문제에 대한 수정 사항을 적용하지 않으면 사용자는 Orchestrator에서 메모리 버퍼(mbuf) 사용량을 모니터링하고 지터 버퍼에서 대기 중인 패킷으로 인해 mbuf 사용량이 늘어날 수 있습니다. 사용자가 이 문제를 확인하는 경우 Edge(원격 진단을 통해) 또는 [게이트웨이(Gateway)]에 대한 흐름을 플러시하여 일시적으로 문제를 완화할 수 있지만 수정 사항이 적용될 때까지 문제가 다시 발생합니다.
해결된 문제 104183: USB/LTE 모뎀을 사용하는 VMware SD-WAN Edge에서 데이터부 서비스 장애가 발생하고 코어 파일이 생성될 수 있습니다.
Edge는 하나 이상의 USB 모뎀이 여러 번 종료되었다가 실행될 때(플래핑) 이 문제가 발생할 수 있습니다.
해결된 문제 104487: VMware SD-WAN Edge가 특정 VMware SD-WAN Gateway를 기본 게이트웨이로 사용하는 고객 사이트는 게이트웨이가 Orchestrator 모니터링에 실행 중으로 표시되더라도 인터넷에 연결할 수 없기 때문에 게이트웨이로 향하는 사용자 트래픽에 문제가 발생할 수 있습니다.
이 문제가 발생하면 게이트웨이의 전송 대기열에서 이러한 패킷이 중단되어 게이트웨이가 RAS(원격 액세스 서비스)로 패킷을 전송하지 못하므로 이 게이트웨이에 연결된 Edge가 터널을 구축할 수 없습니다. 이 문제는 고객 트래픽이 포함된 데이터 패킷에 대해서만 발생하며 게이트웨이와 RAS 간의 연결 유지 패킷에 대해서는 발생하지 않으므로 문제가 발생해도 게이트웨이가 Orchestrator 모니터링에 계속 표시됩니다. 인터넷에 대해 [직접(Direct)]으로 태그가 지정된 고객 트래픽은 게이트웨이를 사용하여 인터넷에 연결하지 않으므로 이 문제의 영향을 받지 않습니다.
해결된 문제 105360: 5.0.x 릴리스를 사용하는 VMware SD-WAN Gateway에서 데이터부 서비스 장애가 여러 번 발생할 수 있으며 각 릴리스 후에 다시 시작될 수 있습니다.
이 문제는 게이트웨이가 Edge에서 게이트웨이의 IP 주소로 직접 조각화된 패킷을 수신할 때 발생할 수 있습니다(예: ping의 ICMP 패킷). 조각화된 패킷이 VCMP(SD-WAN 관리) 터널 또는 IPsec 터널을 통해 전송되는 경우에는 이 문제가 발생하지 않습니다.
해결된 문제 105744: VMware SD-WAN Edge 뒤에 있는 사용자 또는 VMware SD-WAN Gateway에 연결된 고객은 해당 Edge를 사용하거나, 해당 [게이트웨이(Gateway)]를 통과해서 트래픽이 전달되지 않을 수 있는 지점까지 이동하는 트래픽으로 인해 심각한 문제가 발생할 수 있습니다.
이 티켓 및 문제 #1044141이 직접 관련되어 있고 여기에서 반복되는 동일한 증상과 원인이 나타납니다. 이 문제가 발생하면 Edge 또는 [게이트웨이(Gateway)]는 피어에서 수신된 관리 Tunnel 타임스탬프의 증가로 인해 지터 버퍼 대기열에서 제한되지 않은 수의 메모리 버퍼(mbufs)가 사용됩니다. 이로 인해 지터 계산에서 정수 언더플로가 트리거되어 패킷이 무기한으로 효과적으로 버퍼링됩니다. 처음에는 버퍼링된 흐름에만 영향을 주지만, 충분한 기간에 걸쳐 지터 버퍼 대기열에 사용되는 mbuf 수가 사용 가능한 총 mbuf 수에 가까워지고 SD-WAN 디바이스(Edge 또는 [게이트웨이(Gateway)])가 모든 트래픽을 완전히 전달하지는 못할 수 있습니다. 이 문제가 [게이트웨이(Gateway)]에 영향을 미치는 경우 [게이트웨이(Gateway)]를 통과하는 다중 경로 트래픽에만 영향을 미치며 직접 이동하는 고객 트래픽은 영향을 받지 않습니다.
두 티켓 간의 차이점: #104141에 포함된 수정 사항은 피어에서 수신되는 관리 타임스탬프의 증가로 인해 지터 버퍼 대기열에서 사용되는 메모리 버퍼를 해결합니다. #105744에 포함된 수정 사항은 이 문제가 재발할 수 없도록 지터 버퍼 수를 총 메모리 버퍼의 25%로 제한합니다.
Edge 또는 게이트웨이에서 이 문제에 대한 수정 사항을 적용하지 않으면 Orchestrator에서 두 구성 요소를 모니터링하고 지터 버퍼에서 대기열에 대기된 패킷으로 인해 mbuf 사용량이 증가된 것을 확인할 수 있으며, Edge 또는 게이트웨이에 대한 흐름을 플러시하여 문제를 일시적으로 완화할 수 있지만 결국 수정 사항이 적용될 때까지 문제가 다시 발생할 수 있습니다.
해결된 문제 106627: 중복 터널도 구성된 NSD(비 SD-WAN 대상) 또는 CSS(클라우드 보안 서비스)에서 L7(계층 7) 상태 점검을 사용하는 고객에게는 모든 터널이 실행 중이더라도 종료된 것으로 표시될 수 있습니다.
이 문제는 VMware SD-WAN Edge가 기본 터널 대신 백업 터널로 L7 프로브를 전송하여 터널이 종료되었다는 잘못된 표시를 트리거하기 때문에 발생합니다.
해결된 문제 106700: 루프백 인터페이스를 VMware SD-WAN Edge의 계층 7(L7) 상태 점검에 대한 소스 인터페이스로 구성한 사용자의 경우 루프백 인터페이스의 매개 변수를 변경하면 L7 프로브가 실패하며 해당 L7 상태 점검과 연결된 IPsec 터널이 종료된 것으로 보고됩니다.
루프백 인터페이스 구성이 어떤 방식으로든 변경되면 L7 프로브는 IP 주소가 0.0.0.0이고 “없음(None)”으로 지정된 인터페이스로 전송될 수 있으므로 프로브는 실패하고 IPsec 터널이 종료 상태로 표시됩니다.
해결된 문제 107302: IP 주소 변경을 포함하여 계층 7(L7) 상태 점검 프로브에 대해 선택한 소스 인터페이스가 수정되면 L7 상태 점검과 연결된 IPsec 터널이 최대 30초 동안 종료 상태일 수 있습니다.
프로브를 수정하는 데 최대 30초가 걸릴 수 있습니다. 이로 인해 구성을 수정하기 전에 충분한 프로브가 실패하면 IPsec 터널이 종료로 표시될 수 있습니다.
해결된 문제 107309: 고객이 4.x Orchestrator에서 Edge를 통한 비 SD-WAN 대상(Non SD-WAN Destination via Edge)에 대해 L7 상태 점검을 구성하고 Orchestrator가 릴리스 5.x로 업그레이드될 때 고객이 L7 프로브 재시도 값을 수정하려고 하면 Edge에서 새 값을 적용하지 않습니다.
예를 들어 L7 상태 점검 프로브 재시도 값이 3이고(실패한 프로브 3개에서 터널이 종료된 것으로 표시됨) 고객이 이 값을 1로 변경하면 L7 상태 점검은 터널이 종료된 것으로 표시되기 전에 원래 값인 3번의 재시도를 계속 사용합니다. 이 문제는 Edge가 Orchestrator에서 수신하는 새 구성을 적용하지 않으므로 Edge 빌드에서 해결되었습니다.
해결된 문제 107356: 중복 터널 및 계층 7(L7) 상태 점검이 활성화된 NSD(비 SD-WAN 대상)를 배포한 고객의 경우 기본 터널이 종료된 후 최대 30초 동안 보조 NSD 터널이 실행되지 않을 수 있습니다.
중복 기본/보조 터널로 구성된 NSD의 경우 보조 터널의 L7 상태가 인스턴스 간에 전달됩니다. 보조 터널이 실행되었다가 종료되면 L7 상태가 종료 상태로 표시되어 보조 터널이 종료 상태로 유지될 수 있습니다. 보조 터널이 나중에 다시 실행되면 L7 상태 점검 프로세스가 터널을 확인하고 보조 터널이 실행 중임을 확인하는 L7 프로브 전송을 재개하는 데 최대 30초가 걸릴 수 있습니다.
해결된 문제 109131: 연결이 끊긴 후 PPTP(지점 간 터널링 프로토콜) 세션이 다시 연결되지 않습니다.
이 문제는 PPTP 클라이언트는 WAN을 통해 연결되지만(원격으로) PPTP 서버는 VMware SD-WAN Edge LAN 측에서 연결되는 경우 LAN 측(PPTP 서버)에서 GRE 패킷이 삭제되기 때문에 발생합니다.
이 문제에 대한 수정 사항이 없는 Edge에서 해결 방법은 원격 진단(Remote Diagnostics) > NAT 플러시(Flush NAT)를 실행하여 NAT 데이터베이스를 지우는 것입니다.
게이트웨이 빌드 R5012-20221214-GA는 2022년 12월 14일에 릴리스되었으며 두 번째 릴리스 5.0.1용 게이트웨이 롤업입니다.
이 게이트웨이 롤업 빌드는 게이트웨이 빌드, R5011-20221007-GA 이후의 아래와 같은 중요한 문제를 해결합니다.
원래 5.0.1.1 게이트웨이 빌드(R5011-20221007-GA)의 빌드 문제로 인해 게이트웨이를 다른 5.0.1.1 게이트웨이 빌드로 업그레이드할 수 없으며 5.0.1.1에서 5.0.1.2로 직접 업그레이드해야 합니다.
해결된 문제 96863: WAN 링크가 IPv6을 선호하는 VMware SD-WAN Edge에서 데이터부 서비스 장애가 발생하여 고객 트래픽이 잠시 중단될 수 있습니다.
이 문제는 IPv6가 활성화된 경우 Edge 또는 VMware SD-WAN Gateway에서 발생할 수 있으며 이로 인해 서비스 장애가 나타나고 복구하기 위해 다시 시작될 수 있습니다.
해결된 문제 97272: OSPF가 사용되는 고가용성 토폴로지 사이트에서 분할 브레인 상태가 발생하면(두 VNware SD-WAN Edge가 활성 상태임) 코어 라우터에 대한 기본 경로가 제거되고 HA 사이트가 네트워크의 피어 사이트에 연결할 수 없습니다.
코어 라우터의 LSA(링크 상태 보급) 사용 기간은 활성 Edge와 동기화됩니다. HA 분할 브레인 상태가 발생하면 대기 Edge는 활성 상태로 전환되고 새 LSA 사용 기간을 코어 라우터로 전송합니다. 활성 및 대기 Edge 모두 동일한 라우터 ID를 가지므로 새 활성 Edge에서 다른 LSA 사용 기간을 전송합니다. 이 불일치로 인해 코어 라우터에서 LSA 사용 기간은 최대 3600으로 설정되고 HA 사이트에 대한 코어 경로도 제거되어 사이트에서 완전한 중단이 발생합니다.
해결된 문제 99650: 비 SD-WAN 대상이 IKEv1로 구성된 고객 사이트에서 VMware SD-WAN Edge와 NSD 피어 간에 터널이 형성되지 않을 수 있으며 고객 트래픽이 피어 사이트에 도달하지 못할 수 있습니다.
초기 패킷 분류 중에 NSD 터널의 조각화된 ESP 패킷이 일반 사용자 패킷으로 잘못 분류된 다음, 모니터링되지 않는 대기열로 전송되었습니다. 이로 인해 패킷이 해당 대기열에 누적되고 처리 및 누수되지 않습니다.
Edge 빌드 R5012-20221107-GA는 2022년 11월 14일에 릴리스되었으며 두 번째 릴리스 5.0.1용 Edge 롤업입니다.
이 Edge 롤업 빌드는 첫 번째 Edge 롤업 빌드, R5011-20221007-GA 이후의 아래와 같은 중요한 문제를 해결합니다.
이전 Edge 5.0.x.x 빌드를 사용하는 경우 Edge를 5.0.1.2로 업그레이드해야 합니다. 이전 Edge 5.0.x.x 빌드는 VMware SASE 호스팅 Orchestrator에서 더 이상 사용되지 않는 것으로 표시되었습니다.
자세한 내용은 기술 자료 문서 https://kb.vmware.com/s/article/90042를 참조하십시오.
해결된 문제 70311: VMware SD-WAN Edge에 데이터부 서비스 장애가 발생하여 다시 시작될 수 있습니다.
Edge 서비스를 다시 시작하는 동안 고객 트래픽이 15~30초 동안 중단됩니다. 이 문제는 일관되지 않게 발생하지만 이 문제가 발생하면 Edge가 IKE SA(보안 연결)를 해체합니다. 이 문제는 일반적으로 SA 타이머(VMware SD-WAN Orchestrator에 구성된 대로)가 만료되는 경우나 사용자가 Orchestrator에서 IPSec 구성을 수정하는 경우에만 발생합니다.
해결된 문제 96411: VMware SD-WAN Edge에서 데이터부 서비스 장애가 발생하고 그에 따라 다시 시작되어 고객 트래픽이 10~15초 동안 중단될 수 있습니다.
이 문제는 링크가 자주 플래핑(WAN 링크가 종료된 후 빠르게 연속해서 반환)되는 Edge에서 발생할 수 있습니다. 이 문제는 메모리 손상으로 인해 발생하고, 그에 따라 이중 사용 가능 상태 및 Edge 서비스 장애가 발생합니다.
해결된 문제 96441: 고가용성 토폴로지를 사용하는 사이트에서 HA 페일오버가 자주 발생할 수 있습니다.
이 문제는 Edge에서 HA 인터페이스를 종료 상태로 표시한 다음 500~1000ms 내에 다시 실행하면서 HA 페일오버가 트리거될 수 있기 때문에 발생합니다. 하지만 이러한 인터페이스 종료 이벤트는 허위이며 인터페이스 상태를 확인하기 위해 500ms 간격의 폴링을 사용하는 DPDK 사용 설정 인터페이스로 인해 발생합니다. 이 방법을 사용하면 기본 디바이스 드라이버가 가상 인터페이스 종료 이벤트를 보고할 수 있고, 각 이벤트로 인해 인터페이스 상태(500ms)의 다음 폴링에서 인터페이스를 실행 중이라고 보고할 때까지 Edge가 인터페이스를 종료된 것으로 표시할 수 있습니다.
해결된 문제 96888: 특정 로드 조건에서 BGP 또는 OSPF에 대한 라우팅 프로토콜이 임의로 다시 시작되어 경로 재수렴 및 트래픽 중단이 발생할 수 있습니다.
로드 조건이 높을수록 Edge CPU가 스케줄링하기 위해 BGP 및 OSPF 라우팅 프로토콜 프로세스가 예상보다 오래 대기하게 되며, 이로 인해 라우팅 프로토콜이 중지되었다가 다시 시작됩니다. 라우팅 프로토콜 지연은 CPU 대역폭 할당이 부족하기 때문에 발생하며 모든 Edge 모델에서 발생할 수 있습니다.
해결된 문제 97483: CPU 코어가 2개인 VMware SD-WAN 가상 Edge를 사용하는 사이트에서 전송(Tx) 방향의 처리량이 500Mb를 초과하지 않습니다.
2코어 가상 Edge의 처리량은 CPU가 오버로드되지 않도록 500Mbps로 소프트 제한(즉, Edge 소프트웨어를 통해 제한됨)됩니다. 또한 Edge 소프트웨어가 개선되어 CPU가 오버로드되고 기존 500Mbps 한도가 심하게 제한되지 않으면서 2코어 가상 Edge가 훨씬 더 많은 트래픽을 처리할 수 있습니다. 이 Edge 빌드에서는 2코어 처리량 한도가 1000Mbps로 증가합니다.
해결된 문제 98514: 고가용성 토폴로지로 배포된 고객 엔터프라이즈에서 VMware SD-WAN HA Edge에 구성 변경이 적용될 때마다 대기 Edge에서 "관리 서비스 실패"라는 이벤트가 표시되고 관리 서비스가 그에 따라 다시 시작될 수 있습니다.
이는 관리 서비스(고객 트래픽이 포함되지 않음)이고, 대기 Edge에 있으므로 대기 Edge의 관리 서비스가 다시 시작될 때 HA 사이트의 클라이언트 사용자에게 부정적인 영향을 미치지 않습니다. 이 이벤트는 여전히 Edge 이벤트에 기록되어 고객 관리자에게 큰 문제가 될 수 있는 중요한 이벤트입니다.
해결된 문제 100377: VMware SD-WAN Edge를 릴리스 5.0.x로 업그레이드하면 LAN 측 클라이언트 사용자는 모든 고객 트래픽이 삭제되고 다른 사이트 및 인터넷에 연결할 수 없게 됩니다.
설명: 이 문제는 임의로 발생하며 LAN 측 트래픽에 영향을 미칩니다. Edge는 게이트웨이와 Orchestrator 둘 다에 연결되어 있습니다. Orchestrator에서 모니터링(Monitor) > Edge > 상태(Health)를 확인할 때 사용자는 핸드오프 대기열 손실 개수가 증가하는 것을 관찰합니다. 이 문제는 5.x Edge 빌드에 도입된 동작의 변화로 인해 패킷 누수가 발생하고, 변경과 연결된 특정 패킷이 더 이상 해제되지 않고, 시간이 지남에 따라 패킷 버퍼가 오버로드되고 모든 패킷 삭제가 시작되기 때문에 발생합니다.
이 문제를 수정하지 않은 Edge에서 Edge 서비스를 다시 시작하면 패킷 버퍼가 일시적으로만 지워집니다.
해결된 문제 101049: 고객 엔터프라이즈가 보안 및 비보안 경로를 모두 사용하는 경우 높은 경로 손실이 발생할 수 있습니다.
보안 경로와 비보안 경로를 모두 사용하는 예시로는 파트너 게이트웨이가 사용되고 Edge가 BGP 인접 항목(비보안)의 서브넷을 학습한 다음 Edge가 네트워크의 다른 Edge(보안)에서 동일한 서브넷을 학습하는 엔터프라이즈가 있습니다. 이 시나리오에서는 보안 경로가 선호되지만 보안 경로가 해지된 경우 트래픽이 비보안 경로로 전환되지 않습니다. 이 문제는 Edge 서비스가 라우팅을 담당하는 관리 터널을 올바르게 배열하지 않아 발생합니다.
Edge/게이트웨이 빌드 R5011-20221007-GA는 2022년 10월 11일에 릴리스되었으며 첫 번째 릴리스 5.0.1용 Edge/게이트웨이 롤업입니다.
이 Edge/게이트웨이 롤업 빌드는 기존 GA 빌드 R5010-20220729-GA 이후의 아래와 같은 중요한 문제를 해결합니다.
해결된 문제 89235: 허브/스포크 토폴로지를 사용하고 인터넷 백홀 정책을 사용하는 고객 엔터프라이즈에서 인터넷을 향하는 VMware SD-WAN 스포크 Edge의 백홀 트래픽이 허브 Edge에 의해 삭제될 수 있습니다.
이 문제가 발생하면 클라이언트 사용자는 인터넷으로 향하는 트래픽에서 문제를 발견할 수 있습니다. 이 문제는 Edge 전원 주기(예: 정전 후), Edge 서비스 다시 시작 또는 구성 변경 후에 발생하며, 스포크 Edge에서 시작되는 백홀 트래픽과 스포크 Edge에서 애드버타이즈된 경로 간의 타이밍 문제로 인해 발생합니다.
이 수정 사항이 없는 스포크 Edge에서 이 문제가 발생하면 사용자는 영향을 받는 스포크 Edge의 흐름을 플러시하여 백홀 트래픽의 정상적인 라우팅을 복원해야 합니다. 이 작업은 Orchestrator에서 원격 진단(Remote Diagnostics) > 흐름 플러시(Flush Flows)를 통해 수행할 수 있습니다.
해결된 문제 94430: 여러 허브가 배포된 허브/스포크 토폴로지를 사용하는 고객 엔터프라이즈의 경우 VMware SD-WAN 스포크 Edge 뒤의 사용자에게 허브 Edge로 향하는 트래픽에 문제가 발생할 수 있습니다.
스포크 Edge가 트래픽을 수신할 것으로 예상되는 허브와 다른 허브로 트래픽을 전달할 때 클라이언트 트래픽 문제가 발생합니다. 이 문제는 특정 시나리오에서 원격 BGP 경로에 대한 AS 경로 길이가 제대로 계산되지 않아 발생합니다. 따라서 라우팅 기본 설정이 더 낮아야 하는 허브의 경로는 더 긴 AS_PATH 길이가 되고 선호될 수 있습니다.
수정하지 않고 이 문제가 발생하면 고객은 선호될 것으로 예상되는 경로를 철회하고 다시 애드버타이즈할 수 있습니다.
해결된 문제 95503: 드물게 VMware SD-WAN Edge 모델 610, 610N 또는 610-LTE에서 모든 이더넷 인터페이스에 대해 동일한 MAC 주소가 표시될 수 있습니다.
Edge 610(모든 유형)에서 0xF*로 끝나는 eth0 MAC 주소가 표시될 수 있습니다. 이러한 경우 GE1~GE6 포트는 MAC 주소를 계산하고 할당하는 스크립트의 문제로 인해 동일한 MAC 주소를 수신합니다.
이 수정 사항은 이 스크립트 동작을 수정하며 Edge가 이를 포함하는 빌드로 업그레이드되면 영향을 받는 Edge 610 유형이 고유한 MAC 주소를 올바르게 계산하고 할당합니다.
해결된 문제 96055: VMware SD-WAN Gateway에서 신호 6(SIGABRT)을 포함한 데이터부 서비스 장애가 발생하고 코어가 생성될 수 있습니다.
이 문제는 VMware SD-WAN Edge가 잘못된 세그먼트를 참조하는 패킷을 Edge의 기본 게이트웨이로 전송하는 경우에 발생할 수 있습니다. 게이트웨이가 이 패킷을 수신하면 이러한 패킷을 삭제하여 상황을 정상적으로 처리하지 않고 게이트웨이 프로세스가 실패합니다.
해결된 문제 96231: 고객이 Palo Alto Networks 유형을 사용하여 게이트웨이를 통한 NSD(비 SD-WAN 대상)를 배포하고 이 NSD에서 사용할 Palo Alto의 "Prisma 터널 모니터링 기능"을 구성하는 경우 이 NSD에 대해 IPsec 터널이 설정되어 있는 동안 5~15초마다 지속적으로 해체 및 재구축되어 NSD를 사용하는 트래픽이 중단되는 것을 확인할 수 있습니다.
Prisma 터널 모니터링이 사용 설정되면 Prisma 애플리케이션은 암호화된 ICMP 패킷을 SD-WAN Gateway로 전송하고 게이트웨이가 ICMP 패킷에 다시 응답하면 Prisma는 터널이 설정됨을 확인합니다. 실제로 Prisma는 IPsec 터널 활성 검사의 종류입니다. 하지만 이 인스턴스의 문제는 게이트웨이가 Prisma의 ICMP 패킷을 삭제하고 있으므로 Prisma가 터널을 중단으로 표시하여 터널 해체 및 재구축을 트리거한다는 것입니다.
이 문제는 게이트웨이가 ICMP 패킷을 수신하고 에코 요청 패킷이 있는지 확인하기 때문에 유형 필드를 확인하는 대신 게이트웨이가 ICMP 헤더의 코드 필드를 잘못 확인하므로 게이트웨이가 ICMP 패킷을 삭제하여 Prisma가 터널을 해체하도록 트리거합니다.
이 문제에 대한 수정 사항이 없는 게이트웨이에서 고객은 Palo Alto 유형 NSD에 대해 Prisma를 사용하지 않아야 합니다.
해결된 문제 98157: VMware SD-WAN Gateway에 데이터부 서비스 장애가 발생하여 다시 시작될 수 있습니다.
드문 경우지만 SD-WAN 터널의 소스 포트가 변경되는 경우(예를 들어 중간 NAT 디바이스가 다시 시작) 게이트웨이의 데이터부 프로세스가 실패하고 다시 시작되며 코어가 생성될 수 있습니다.
해결된 문제 99188: 경우에 따라 고객 엔터프라이즈에 대해 BGP 세션이 실행되지 않을 수 있습니다.
이 문제는 2147483648 이상의 ASN 값이 구성된 경우에 발생합니다. 이러한 경우 구성이 적용되지 않으므로 BGP 세션이 실행되지 않습니다.
Edge 및 게이트웨이 버전 R5010-20220729-GA는 2022년 8월 5일에 릴리스되었으며 Edge/게이트웨이 버전 R5002-20220506-GA 이후의 다음 문제를 해결합니다. 따라서 5.0.0 릴리스 정보에 나열된 모든 Edge 또는 게이트웨이 문제에 대한 수정 사항이 모든 릴리스 5.0.1 빌드에 포함되어 있습니다.
해결된 문제 58791: BGP가 사용되는 고가용성 토폴로지로 배포된 사이트에서 VMware SD-WAN Edge가 반복적으로 페일오버되는 문제가 발생할 수 있습니다.
이 문제는 HA 사이트에 512개를 초과하는 BGPv4 필터 접두사가 구성된 경우 Hub/스포크 토폴로지 내에 구성된 HA 사이트에 영향을 미칩니다.
BGP가 구성된 여러 네트워크 명령과 함께 사용되고 대기 Edge가 실행되는 동안 모든 구성을 대칭적으로 구문 분석하고 모든 네트워크에 대해 명령 vtysh가 생성되므로 verp 스레드가 실행되지 않습니다. verp 스레드가 지연되어 하트비트 처리가 지연되며, 이로 인해 대기 Edge가 활성 Edge를 종료된 것으로 판단하고 대기 Edge가 활성화되어 분할 브레인 상태(활성-활성)가 됩니다. 분할 브레인 상태에서 복구하기 위해 대기 Edge가 다시 시작되며 순환이 반복됩니다.
수정하지 않는 경우 BGP 필터 접두사 구성 수를 집계하고 전체 수를 512(인바운드 256개 및 아웃바운드 필터 256개)개 미만으로 줄여 문제를 해결할 수 있습니다.
BGP 'match 및 set' 작업을 사용할 때 HA 사이트가 중단되는 유사한 문제가 있고 이 문제는 해결된 문제 #84825에서 별도로 추적되며, 이 Edge 빌드에서 해결되었습니다.
해결된 문제 67458: 많은 수의 스포크 Edge가 있는 VMware SD-WAN Hub Edge를 릴리스 4.2.1 이상으로 업그레이드하면 허브 Edge에 대해 다른 스포크 Edge로의 일부 터널이 실행되지 않습니다.
스포크 Edge가 1000개 이상일 때 대량으로 인식됩니다. 이 문제는 일관되지 않지만 일반적으로 허브 Edge와 연결된 스포크 Edge 간에 VCMP(VeloCloud 관리 프로토콜) 터널 중 1/3 이하가 설정되지 않습니다. 이 문제는 반개방 TD의 수가 허브 Edge의 상한을 초과하기 때문에 허브 Edge가 MP_INIT을 무시하기 때문에 발생합니다.
수정 사항을 적용하지 않고 이 문제가 발생한 경우 Edge 서비스를 다시 시작하면 전체 터널 연결이 복원됩니다.
해결된 문제 70129: 대규모 VMware SD-WAN Gateway에서 Syslog를 활성화하면 /var/log 폴더가 짧은 시간 내에 Syslog 로그 파일로 채워질 수 있습니다.
일반적으로 ~100-150K 흐름과 ~50-100K NAT 항목이 있는 4K 이하의 피어 및 ~6K 이하의 터널이 있는 게이트웨이가 대규모로 인식됩니다. syslog.log 파일 크기가 3.2Gb보다 크게 유지되는 24시간 정도가 짧은 기간일 수 있습니다. 이 문제는 일부 NAT 로그가 다른 폴더로 전송되어야 하는 /var/log로 전송되기 때문에 발생합니다.
해결된 문제 70586: VMware SD-WAN Edge의 라우팅된 인터페이스가 802.1x에 대해 구성된 경우(RADIUS 인증 사용), 해당 인터페이스에 연결된 클라이언트는 다른 인터페이스가 플래핑될 때마다(다시 말해 802.1x가 아닌 모든 인터페이스가 빠르게 연속해서 종료 및 시작됨) 자동으로 인증 해제되고, 클라이언트가 Edge 연결을 해제하고 다시 연결할 때까지 모든 트래픽이 삭제됩니다.
Edge는 플래핑된 인터페이스가 실제로 802.1x 클라이언트가 인증된 인터페이스인지 확인하지 않기 때문에 모든 인터페이스 플래핑을 802.1x 인터페이스 플래핑으로 취급하고 그에 따라 작동합니다.
이 수정 사항을 적용하지 않고 이 문제를 해결할 수 있는 유일한 방법은 클라이언트가 물리적으로 연결을 끊었다가 다시 연결하여 다시 인증되도록 하는 것입니다.
해결된 문제 74291: 인터넷 액세스 및 기능 DNS가 있음에도 불구하고 고가용성 토폴로지의 VMware SD-WAN Edge가 페일오버 후 오프라인으로 표시될 수 있습니다.
이 문제는 고가용성 페일오버 후 발생할 수 있으며 새로 승격된 활성 Edge의 토큰 오류로 인해 Orchestrator에 하트비트가 실패하게 됩니다. 하트비트가 없으면 Orchestrator는 Edge를 종료된 것으로 표시합니다.
수정 사항이 적용된 Edge 빌드가 없으면 문제를 해결하는 방법은 로컬 UI를 통해 또는 활성 Edge의 전원 주기를 통해 로컬로 다른 페일오버를 강제로 실시하는 것입니다.
해결된 문제 72925: 엔터프라이즈 모니터링을 위해 SNMP 폴링을 사용하고, 4.x 소프트웨어 릴리스를 실행하는 하위 모델 VMware SD-WAN Edge(예: Edge 모델 510, 520 또는 610)를 배포하는 고객의 경우 SNMP 폴링을 처리하는 데 예외적으로 오랜 시간이 소요되며 시간 초과될 수도 있습니다.
이 문제가 발생하면 510, 5x0 및 6x0 시리즈에서 Edge를 사용할 때 네트워크 모니터링을 위한 SNMP 폴링의 효율성이 크게 줄어듭니다. 이 문제는 릴리스 4.x SNMP 에이전트가 디버그 명령 목록을 탐색하는 데 불필요하게 긴 시간이 소요되기 때문에 발생합니다. 이 작업은 SNMP 프로세스에 실제로 필요하지 않습니다.
해결된 문제 73830: SCCM(System Center Configuration Manager) 애플리케이션 트래픽이 VMware SD-WAN Edge에서 BITS(Business Intelligence Service) 트래픽으로 잘못 분류되고 있으며 SCCM 트래픽용으로 설계된 비즈니스 정책 또는 방화벽 규칙을 사용하는 고객은 해당 트래픽이 영향을 받는 것을 확인할 수 있습니다.
Edge의 DPI(심층 패킷 검사) 엔진이 SCCM 애플리케이션 패킷을 BITS 트래픽으로 잘못 분류하고 있으며 해당 트래픽을 조절하거나 방화벽 규칙에서 트래픽을 허용하도록 설계한 비즈니스 정책 또는 방화벽 규칙이 있는 경우 SCCM 트래픽이 차단되어 고객 작업이 중단됩니다. 이 문제에 대한 수정 사항에서는 이러한 잘못된 분류가 방지되도록 기본 4.5.1/5.0.1 이상 애플리케이션 맵을 수정합니다.
해결된 문제 74316: Edge에 서비스 다시 시작 또는 전체 재부팅이 있더라도 VMware SD-WAN 스포크 Edge가 할당된 모든 또는 일부 허브 Edge 클러스터에 연결하지 못할 수 있습니다.
특정 클러스터 멤버-슈퍼 게이트웨이 오버레이 플래핑 시나리오에서 클러스터 멤버의 끝점 정보 없이 클러스터 할당 매핑을 생성하는 클러스터 재할당 논리에 문제가 있습니다. 그 결과, 허브 클러스터 멤버에 할당된 스포크 Edge가 나중에 허브 클러스터 멤버의 끝점 정보를 수신하지 못하여 스포크 Edge와 허브 클러스터 간에 오버레이가 발생하지 않습니다.
이 수정 사항을 적용하지 않을 경우 일시적으로 해당 조건을 수정하는 유일한 방법은 게이트웨이 액세스 권한이 있는 사람이 슈퍼 게이트웨이에서 클러스터 재할당을 수동으로 트리거하는 것입니다.
해결된 문제 76690: VMware SD-WAN Edge에 대한 문제 해결을 시도할 때 덜 중요한 이벤트 항목이 반복적으로 표시되면서 중요 로그가 누락되는 것을 확인할 수 있습니다.
진단 번들에서 velocloud/log에 이벤트 vc_peer_qos_update_cos_nsimits의 반복적인 로깅이 있을 수 있습니다. 이 이벤트의 로그 수준은 관리부이며 반복적인 로깅으로 인해 로그 오버플로 및 롤오버가 발생할 수 있습니다. 문제 해결 시나리오에서는 중요 로그 메시지가 롤오버되고 지워져 누락될 수 있습니다.
해결된 문제 78276: VMware SD-WAN Edge의 이름에 ASCII가 아닌 문자가 포함되어 있으면 VMware SD-WAN Gateway에서 debug.py -qos_net 명령을 실행하지 못합니다.
한 가지 예는 중국어 문자를 사용하는 경우이지만, 이 문제는 ASCII가 아닌 모든 문자에 적용되며, ASCII가 아닌 문자를 포함하도록 Edge 이름을 변경하고 Edge를 재부팅할 때 확인될 수 있습니다. 그러면 게이트웨이가 Edge에 연결됩니다. 다음 CLI 명령을 실행하여 Edge의 논리적 ID를 가져옵니다. debug.py --list 3. 그런 후 다음 게이트웨이 CLI 명령을 실행합니다. debug.py -qos_net [logical ID] all stats. 그리고 사용자는 명령 실패를 확인할 수 있습니다.
해결된 문제 78300: VMware SD-WAN Edge가 백업용으로 구성된 WAN 링크를 사용하는 경우 사용자는 이 링크에 대해 터널이 작동 중이거나 종료되었음을 암시하는 Orchestrator 이벤트 또는 로그를 확인할 수 있습니다.
설계상 백업 링크에 대해 터널이 설정되지 않습니다. 그러나 원격 끝(일반적으로 동적 Edge 간 터널)의 터널 요청은 스택을 통과할 때 링크 상태를 변경할 수 있습니다. 이 수정 사항은 백업 링크에 대해 터널 형성 또는 해체가 진행 중임을 나타내는 로그가 표시되지 않도록 주의해서 작성되었습니다.
해결된 문제 78391: Speedtest 애플리케이션 분류가 적용된 트래픽이 제대로 작동하지 않습니다.
speedtest.net 및 fast.com 둘 다에는 기본 애플리케이션 맵에 누락된 speedtest 서버 IP 주소가 새로 추가되었기 때문에 이러한 애플리케이션을 처리하는 비즈니스 정책이 적용되지 않습니다.
릴리스 4.5.1 또는 5.0.1로 업그레이드하지 않으면 운영자는 VMware SASE Orchestrator의 애플리케이션 맵 편집기를 사용하여 필요한 speedtest IP를 기존 애플리케이션 맵에 추가할 수 있습니다.
해결된 문제 79261: Office 365/Microsoft 365 애플리케이션 트래픽이 VMware SD-WAN Edge에서 Tencent Meeting(VooV Meeting) 애플리케이션 트래픽으로 잘못 분류됩니다.
이로 인해 비즈니스 또는 방화벽 정책에 따라 Office 365/Microsoft 365 트래픽을 라우팅하고 우선 순위를 지정하는 고객이 해당 트래픽을 Tencent Meeting으로 분류하여 완전히 다른 규칙을 준수하도록 하지 못할 수 있습니다. 4.3.2 기본 애플리케이션 맵에서 수정된 잘못된 Tencent용 애플리케이션 맵 서브넷의 문제로 추적됩니다. 4.3.2을 사용하지 않는 고객은 Orchestrator 애플리케이션 맵 편집기를 통해 애플리케이션 맵을 편집하여 Tencent 서브넷을 수정하는 운영자가 해당 문제를 수정할 수 있습니다.
해결된 문제 80010: SD-WAN 연결 가능(SD-WAN Reachable)도 구성된 허브/스포크 토폴로지를 사용하는 고객 엔터프라이즈의 경우 스포크-허브 경로가 지점 간에 수행된 경우 허브 경로를 통한 스포크-게이트웨이 경로(공용 WAN 링크 사용)가 실행되지 않습니다.
스포크 Edge가 연결된 허브를 통해 게이트웨이에 연결하기 위한 패스스루인 SD-WAN 연결 가능 기능은 스포크 Edge 및 허브 Edge가 지점 간 링크로 연결되는 경우(즉, 스포크의 IP 주소가 허브의 연결된 경로와 일치함)에는 지원되지 않습니다. 이 문제에 대한 수정 사항은 이 기능을 추가합니다.
해결된 문제 80196: VMware SD-WAN Gateway에서 SIGXCPU 메시지를 나타내며 데이터부 서비스 장애가 발생할 수 있으며 게이트웨이는 15~30초 동안 게이트웨이 트래픽에 영향을 미치면서 복구를 위해 서비스를 다시 시작합니다.
이 문제는 처리량 용량에 비해 해당 게이트웨이의 처리량이 높기 때문에 대규모 배포(예: 4K Edge 및 6K 터널)에서 발생할 가능성이 더 높습니다. 높은 속도의 트래픽이 게이트웨이에 도달하면 일부 경우에 게이트웨이에서 스레드 잠금이 발생하고 다시 시작하는 동안 코어가 생성됩니다. 코어에서 사용자는 다음을 확인할 수 있습니다. Program terminated with signal SIGXCPU, CPU time limit exceeded.
해결된 문제 80479: VMware SD-WAN Gateway에서 데이터부 서비스 장애가 발생하여 복구를 위해 서비스가 다시 시작될 수 있습니다. 이에 따라 15~30초 동안 게이트웨이 트래픽이 영향을 받게 됩니다.
이 문제는 VMware SD-WAN Edge가 E2E(Edge-Edge)를 구성한 게이트웨이에 연결되어 있고 루프백 인터페이스 경로가 애드버타이즈된 경우에 발생할 수 있습니다. 사용자가 이 Edge에 대해 E2E를 해제하면 경로 시작이 트리거되지만 루프백 경로가 삭제되지 않고 경로가 경로의 프로필 플래그를 업데이트합니다. 다음으로, 사용자가 루프백 경로에 대한 애드버타이즈를 제거하면 FIB에서 경로가 삭제되지만 게이트웨이의 E2E 테이블에는 오래된 경로가 유지됩니다. 루프백 경로가 다시 애드버타이즈되고 FIB에 추가되며 이후 사용자가 해당 플래그만 다시 업데이트하는 E2E를 다시 설정하면 해당 경로(오래된 경로)가 게이트웨이의 E2E 테이블에 있더라도 실제 route ref_count는 올바르지 않습니다. 마지막으로 터널이 해체되면 게이트웨이에서 데이터부 서비스 장애가 트리거됩니다.
이 수정 사항을 적용하지 않으면 운영자는 Edge에 대한 프로필을 변경하기 전에 경로가 취소되었는지 확인해야 합니다.
해결된 문제 80496: SD-WAN 터널을 통해 VMware SD-WAN Edge에서 원격 Edge의 분기 루프백 IP 주소로 수행하는 Ping이 작동하지 않을 수 있습니다.
조각화를 유발할 정도로 패킷 크기가 충분한 ping에 대해 문제가 확인됩니다. 큰 패킷 크기를 사용하여 Edge에서 원격 분기 Edge의 루프백 IP 주소로 ping을 시작하면 조각화된 ICMP 응답이 ping을 시작하는 Edge에 도달하지만 다음 조각이 삭제되기 때문에 ping 애플리케이션에 도달하지 못합니다.
해결된 문제 80721: Telegraf를 사용하여 VMware SD-WAN Gateway를 모니터링하는 파트너와 운영자는 Telegraf에서 네트워크 시간 초과가 발생하면 메트릭이 재개되지 않는 것을 확인할 수 있습니다.
이 문제가 발생하는 게이트웨이는 Telegraf 버전 1.17.3을 사용하고 있습니다. 이와 달리 VMware SASE Orchestrator에서 사용 중인 Telegraf 버전은 다음과 같습니다. 1.21.1. 이 버전 불일치로 인해 네트워크 시간 초과 시 Telegraf가 중단되는 문제가 발생합니다. 이 문제가 수정된 게이트웨이의 경우 해당 릴리스(예: 4.5.1 또는 5.0.1)의 향후 게이트웨이 빌드와 마찬가지로 Telegraf 버전 1.21.1을 포함합니다.
이 문제가 발생하는 게이트웨이에서 유일한 해결 방법은 Telegraf를 다시 시작하여 메트릭 전송을 재개하는 것입니다.
해결된 문제 80814: 로컬 Edge 클라이언트 소스 IP 주소와 원격 클라이언트를 대상 IP 주소로 사용하고 다른 트래픽에 대해 “모두 거부(Deny All)” 규칙이 있는 표준 방화벽 허용 규칙이 구성된 VMware SD-WAN Edge에서 원격 클라이언트로부터 로컬 클라이언트로의 트래픽이 삭제됩니다.
이 문제는 소스 호스트와 대상 호스트 간에 VLAN IP 주소가 일치하지 않는 경우에 발생합니다. 소스 및 대상 호스트가 서로 다른 VLAN에 속하는 경우 SD-WAN 서비스는 방화벽 조회 키에 있는 첫 번째 패킷의 소스/대상 IP 주소를 선호합니다. 따라서 오버레이 인바운드 흐름의 경우 불일치가 발생하고 트래픽에 [모두 거부(Deny All)] 방화벽 규칙이 적용됩니다.
이 수정 사항을 적용하지 않는 경우 이 문제의 해결 방법은 패킷이 방화벽 규칙과 일치할 수 있도록 흐름의 첫 번째 IP 패킷 방향으로 규칙을 되돌리는 것입니다.
해결된 문제 80897: VMware SD-WAN Edge가 VMware SD-WAN 파트너 게이트웨이에 연결된 고객 엔터프라이즈의 경우 고객 트래픽의 성능이 저하될 수 있습니다.
성능 저하는 기본 보안 고정 경로를 사용할 수 있지만 Edge가 이러한 경로의 레이블에 보안 레이블을 제대로 지정하지 않은 경우 Edge로 경로를 분산하는 파트너 게이트웨이에서 라우팅 문제가 발생한 것에 따른 결과입니다. 그 결과, Edge는 예상된 동작이 항상 비보안 경로보다 보안 경로를 선호할 때 모든 경로가 동일하게 처리되기 때문에 비기본 및 비보안 경로를 보안 경로에 애드버타이즈할 수 있습니다.
이 문제를 해결하려면 파트너 게이트웨이와 고객 Edge를 모두 이 수정 사항이 포함된 빌드로 업그레이드해야 합니다.
해결된 문제 81221: 고객이 VMware SD-WAN Edge에 대해 1:1 NAT 규칙을 구성하고 해당 Edge가 재부팅될 때 규칙이 더 이상 작동하지 않습니다.
재부팅 후 Edge는 NAT 규칙이 적용되는 Edge 인터페이스 주소로 NAT 주소를 할당하므로 해당 규칙과 일치하는 트래픽에 대해 터널이 구축되지 않습니다.
이 수정 사항을 적용하지 않고 이 문제를 해결할 수 있는 유일한 방법은 전체 NAT 테이블을 플러시하고 올바른 NAT 규칙 작업을 다시 설정하는 원격 진단(Remote Diagnostic) > NAT 플러시(Flush NAT)를 실행하는 것입니다.
해결된 문제 81809: 사용자가 다른 Edge 뒤에 있는 원격 클라이언트에서 또는 VMware SD-WAN Gateway에서도 VMware SD-WAN Edge의 VLAN IP에 대해 SSH를 시도하면 SSH 시도가 실패합니다.
LAN 클라이언트에서 Edge VLAN IP로의 SSH 시도는 제대로 작동합니다. 원래 Edge의 관리 IP는 Edge에 대해 SSH를 수행하는 데 사용되었습니다. 그러나 Edge 관리 IP가 더 이상 사용되지 않는 경우 루프백 IP가 여전히 SSH를 지원하지 않으므로 사용자가 원격 Edge 클라이언트의 오버레이를 통해 Edge에 대해 SSH를 수행하는 옵션이 없었습니다.
해결된 문제 81859: VMware SD-WAN Edge 610-LTE가 Edge 릴리스 5.0.0으로 활성화되면 Edge를 해당 릴리스로 업그레이드한 후 CELL 인터페이스가 나타나지 않을 수 있습니다.
이 문제는 일관되지 않지만 Edge 610-LTE의 유일한 공용 링크가 모바일 CELL 링크인 경우 Edge가 효과적으로 종료되고 이 Edge에 대한 개입이 로컬로 진행되어야 하므로 이 문제가 발생하면 큰 영향을 미칠 수 있습니다.
수정하지 않은 Edge에서 이 문제가 발생하면 사용자는 Edge 서비스를 다시 시작하거나(Orchestrator를 통해 Edge에 액세스할 수 없는 경우 전원 주기/재부팅) Edge의 모뎀을 다시 시작하여 CELL 인터페이스를 복원해야 합니다.
해결된 문제 82182: Edge 릴리스 5.0.0을 실행하는 VMware SD-WAN Edge 모델 510 또는 510-LTE 경우 사용자가 Edge의 서비스 다시 시작하려고 하면 Edge가 재부팅될 수도 있습니다.
Edge가 재부팅 프로세스를 진행하는 동안 2~3분 동안 고객 트래픽이 중단됩니다. Edge 510/510-LTE에 Edge 서비스를 다시 시작하는 동안 중지하지 못할 수 있는 Wi-Fi 디바이스 중단 모니터링 스크립트가 있으며 이로 인해 재부팅이 트리거됩니다.
이 수정 사항을 적용하지 않으면 사용자가 Edge 서비스를 다시 시작해야 하지만 이러한 모델에서 Edge 서비스는 이러한 문제가 발생할 수 있다는 사실을 이해한 경우에 유지 보수 기간에만 다시 시작해야 합니다.
해결된 문제 82264: AWS C4 인스턴스를 사용하는 VMware SD-WAN 가상 Edge는 릴리스 5.0.0으로 업그레이드할 수 없습니다.
릴리스 5.0.0으로 업그레이드된 AWS C4 가상 Edge는 복구되지 않으며 유일한 수정 방법은 사용자가 Edge를 5.0.0이 아닌 버전으로 다시 활성화하는 것입니다. 다른 AWS 인스턴스(예: C5)는 이 문제의 영향을 받지 않지만 이 결함의 치명적인 특성으로 인해 AWS Edge Upgrade 소프트웨어 패키지를 릴리스 5.0.0에 사용할 수 없습니다.
Edge 릴리스 5.0.1 이상에서 이 문제를 수정하고 AWS C4 인스턴스를 릴리스 5.0.1 이상으로 업그레이드할 수 있습니다.
해결된 문제 82463: CSS(클라우드 보안 서비스)로 구성된 사이트의 경우 VMware SD-WAN Edge가 CSS로 향하는 트래픽을 삭제할 수 있습니다.
사이트가 CSS를 통해 모든 인터넷 트래픽을 라우팅하는 경우 이 문제의 영향이 클 수 있습니다. 이 문제가 발생하면 CSS 패킷이 실제 인터페이스의 IP 주소를 소스로 사용하여 잘못된 인터페이스로 전송되므로 애플리케이션 액세스가 실패합니다. 이 문제는 CSS 컨텍스트 조회 스레드와 송신 인터페이스 선택 스레드 간의 잠재적인 경합으로 인해 발생하며 이로 인해 송신 인터페이스가 흐름과 잘못 연결되고 CSS 경로의 일부 흐름이 실패합니다.
이 수정 사항을 적용하지 않을 경우 문제가 발생하면 사용자가 새 흐름을 시작하거나 원격 진단(Remote Diagnostics) > 흐름 플러시(Flush Flows)에서 Edge의 모든 흐름을 플러시하여 문제를 해결할 수 있습니다.
해결된 문제 82485: 초급 VMware SD-WAN Edge 모델(예: Edge 510, 510-LTE 또는 610)에서 사용자가 원격 진단 "경로 테이블 덤프"를 실행하는 경우 Orchestrator UI 페이지가 시간 초과되어 결과를 반환하지 않을 수 있습니다.
16,000개보다 많은 경로가 있는 경우 Edge가 결과를 반환하는 데 30초 넘게 걸리므로 이 문제가 발생합니다. 30초는 페이지의 WebSocket에 대한 시간 제한이므로 결과가 반환되지 않습니다. 이 문제에 대한 수정 사항을 적용하면 시간 초과가 발생하지 않도록 경로 테이블 워크가 최적화됩니다.
해결된 문제 82522: 높은 처리량의 트래픽이 VMware SD-WAN Edge에 도달하면 Edge에서 실제 처리량이 감소된 것으로 확인될 수 있습니다.
처리량이 높은 경우 Edge의 NDP(Neighbor Discovery Protocol) 스레드는 연결할 수 있는 것으로 표시되고 추가 처리가 필요하지 않은 NDP 항목에 대해서도 잠금을 두 번 획득합니다. 이러한 중복 잠금은 추가 처리를 발생하므로 처리량이 감소되도록 합니다.
해결된 문제 82652: L7 상태 점검이 구성된 CSS(클라우드 보안 서비스)를 사용하는 고객의 경우 VMware SD-WAN Edge는 5분 넘게 종료된 것으로 표시된 IPsec CSS 터널을 복구하려고 시도하지 않습니다.
L7 상태 점검의 현재 구현에서 Edge는 모든 CSS 터널에서 L7 프로브를 전송하고, 해당 프로브가 설정된 횟수만큼 실패하면 Edge는 해당 터널을 종료(Down)로 표시한 다음, L7 프로브를 계속 전송하고 터널이 자체적으로 실행될 때까지 기다립니다. 이 문제는 터널이 5분 넘게 종료(Down) 상태에 있을 때 터널을 복구하려고 시도하지 않고 IKE는 실행 상태를 유지한다는 것입니다(IKE도 종료(Down) 상태인 경우 IPsec 터널은 20초 후에 자동으로 재설정됨).
이 티켓의 수정 사항은 IPsec 기반 CSS 터널에 대한 추가 단계를 포함하여 L7 상태 점검을 개선합니다. IPsec 기반 CSS 터널이 5분 넘게 종료(Down) 상태(성공적인 L7 프로브 없음)이고 동일한 기간 동안 터널에 대한 IKE가 실행 상태를 유지하면 Edge는 IPsec 터널을 해체하고 CSS 터널의 복구를 시도할 때 IKE를 재설정합니다. 이 문제가 발생하는 동안 L7 프로브가 계속 전송되며, 성공할 경우 터널이 [실행 중(Up)]으로 표시될 수 있습니다. 터널이 종료된 상태로 유지되면 추가로 5분 후에 동일한 단계가 적용되었습니다.
이 추가된 동작은 IPsec 터널이 있는 CSS에만 적용되고 GRE 터널을 사용하는 CSS에는 적용되지 않습니다.
해결된 문제 82790: Azure 환경에 배포된 VMware SD-WAN Gateway에서 게이트웨이 인터페이스 카운터를 Wavefront 모니터링 서비스로 내보내지 않습니다.
Azure는 DPDK가 사용 구성되지 않은 환경으로, DPDK 인터페이스 카운터(처리량 비율, PPS 및 삭제 카운터)만 Wavefront 서비스로 내보냅니다. 이로 인해 DPDK가 사용되지 않는 Azure와 같은 플랫폼에서 모니터링 기능이 줄어듭니다.
해결된 문제 82839: 사용자가 VMware SASE Orchestrator에서 Zscaler Cloud Security Service 터널에 대해 IPsec 자동화 삭제 작업을 수행하는 경우 해당 Zscaler 위치와 연결된 모든 VPN 자격 증명도 삭제되며 위치 자체도 삭제됩니다.
IPsec 자동화 삭제 작업은 Zscaler 위치에서 연결된 VPN 자격 증명만 삭제해야 합니다. 해당 Zscaler 위치에 연결된 다른 모든 VPN 자격 증명은 영향을 받지 않은 상태를 유지해야 합니다.
해결된 문제 83029: 독립 실행형 VMware SD-WAN Edge 또는 하나 이상의 PPPoE 링크가 사용되는 고가용성 토폴로지로 배포된 사이트의 경우, 해당 PPPoE 링크에 대한 Edge 인터페이스가 플래핑되거나 HA 사이트가 페일오버의 영향을 받은 후 PPPoE 끝점 IP가 변경되면 PPPoE 링크에서 트래픽이 전달되지 않습니다.
PPPoE 링크를 사용하는 사이트에서는 PPPoE 끝점 IP가 변경되면 고객 트래픽이 전달되지 않습니다. 이 문제는 새 PPPoE 끝점 IP 주소가 수신된 후 삭제되지 않은 Edge에 있는 PPPoE 끝점의 이전 IP 주소를 사용하는 오래된 기본 경로가 있기 때문에 발생합니다.
이 버그 수정 사항을 적용하지 않으면 현장 사용자는 각 PPPoE 케이블의 연결을 끊었다가 다시 연결하여 강제로 재협상을 수행하거나 Edge를 재부팅하여 강제로 재협상해야 합니다.
해결된 문제 83083: 릴리스 4.3.1 이상으로 업그레이드된 VMware SD-WAN Gateway에서 천천히 진행되는 메모리 누수로 인해 게이트웨이 서비스가 다시 시작되고 메모리가 지워질 수 있습니다.
게이트웨이 다시 시작은 게이트웨이 서비스가 다시 시작하는 데 소요되는 30~45초 동안 고객 트래픽이 중단될 수 있습니다. 운영자가 게이트웨이에서 debug.py --flow_dump all all all 명령을 실행할 때마다 게이트웨이에 일부 메모리가 누수됩니다. 이 디버그 명령을 충분한 횟수만큼 실행하면 게이트웨이의 메모리 사용량이 위험 수준에 도달하고 게이트웨이 서비스 다시 시작을 트리거하여 메모리를 지웁니다.
이 수정 사항을 적용하지 않은 게이트웨이의 경우 운영자는 게이트웨이에서 debug.py --flow_dump all all all 명령을 실행하지 않아야 합니다. 이 디버그 명령의 사용을 피할 수 없는 경우 메모리 사용량을 모니터링하고 유지 보수 기간을 스케줄링하여 예약되지 않은 다시 시작 전에 서비스를 선점적으로 다시 시작하여 메모리를 지웁니다.
해결된 문제 83209: 엔터프라이즈에서 OSPF를 사용하는 고객의 경우 OSPF 라우팅이 예상대로 작동하지 않을 수 있습니다.
이 문제는 OSPF router-id가 변경되고 Edge 서비스가 다시 시작되면 발생합니다. router-id 선택에는 루프백 인터페이스와 'Advertise' 플래그가 설정된 인터페이스만 고려됩니다. 더 높은 IP 주소로 구성된 새 루프백 인터페이스가 있는 경우 Edge 서비스를 다시 시작할 때 새 루프백 IP 주소가 router-id로 선택되고 Edge가 DR(지정된 라우터)로 선택되면 문제가 발생합니다.
이 수정 사항을 적용하지 않는 경우 유일한 해결 방법은 이전 라우터 ID를 강제로 사용하는 것입니다. 이전 라우터 ID를 다시 가져오고 해당 인터페이스에서 애드버타이즈 플래그를 설정합니다(Edge 서비스를 다시 시작해야 함).
해결된 문제 83402: 여러 WAN 링크가 있는 VMware SD-WAN Edge에서 하나 이상의 WAN 링크가 트래픽 전달을 중지할 수 있습니다.
트래픽 전달을 중지하는 WAN 링크에서 DHCP 획득 주소가 갱신되지 않고 WAN 인터페이스의 주소가 손실됩니다. 이 문제는 DHCP를 사용하여 IP 주소를 가져오는 여러 인터페이스가 있고 DHCP 서버가 클라이언트와 다른 네트워크에 있는 경우에 발생합니다. DHCP 갱신 유니캐스트 패킷의 송신 인터페이스는 경로 조회를 통해 결정됩니다. 다양한 인터페이스를 통해 다양한 메트릭 값이 학습된 여러 기본 경로가 있기 때문에 DHCP 요청 패킷이 다른 인터페이스에서 전송될 수 있습니다.
이 수정 사항을 적용하지 않으면 현장 사용자는 Edge에서 영향을 받는 WAN 링크를 분리했다가 다시 연결하여 해당 IP 주소를 강제로 다시 가져와야 합니다.
해결된 문제 83411: 새로 활성화된 VMware SD-WAN Edge에서 고가용성이 설정되면 HA Edge 쌍이 오프라인 상태가 될 수 있습니다.
HA가 설정되면 모든 Edge 인터페이스 MAC 주소가 가상 MAC 주소로 변경되고, 문제 상태인 동안 DPDK 구성이 이러한 VMAC 주소로 업데이트되지 않습니다. 그에 따라 대상 MAC 불일치로 인해 Orchestrator로 향하는 하트비트 패킷이 삭제되고, Orchestrator는 HA Edge 쌍을 종료된 것으로 표시합니다.
해결된 문제 83424: 인터페이스 및 경로 관련 OID에 대해 SNMP 워크가 제대로 작동하지 않을 수 있습니다.
일부 Edge 배포에 대해 snmpbulk 명령이 실행될 때 SNMP 워크가 너무 오래 걸리고 시간이 초과될 수 있습니다. 이 문제에 대한 수정 사항은 SNMP를 최적화하고 SNMP 워크 요청에 대한 더욱 빠른 응답을 보장합니다. 하지만 드물게 SNMP 프로세스가 Edge에서 낮은 우선 순위 프로세스로 남아 있기 때문에 이 문제가 계속 발생할 수 있다는 점에 유의해야 합니다.
해결된 문제 83428: 허브/스포크 토폴로지를 사용하는 고객 엔터프라이즈에서 VMware 허브 Edge와 스포크 Edge 간의 고정 터널에서 대역폭 측정을 시도하는 동안 트래픽 전달이 중지될 수 있습니다.
허브 Edge에서는 터널 설정 프로세스 중에 터널 기본 설정이 업데이트되는 시나리오를 처리하기 위한 메커니즘이 없습니다. 대역폭 측정 프로세스는 터널을 정지 상태로 전환하고 트래픽이 이 터널을 통과하지 못합니다. 고객 트래픽은 게이트웨이를 통해 재라우팅할 수 있지만 이로 인해 허브/스포크 트래픽에 지연 시간이 발생할 수 있습니다.
해결된 문제 83432: 고가용성 토폴로지로 배포된 사이트의 경우 추가 터널이 사이트에 추가되면 VMware SD-WAN 대기 Edge에서 데이터부 서비스가 충돌하고 코어가 생성될 수 있습니다.
터널을 추가하는 일반적인 방법은 HA Edge에 WAN 링크를 추가하는 것입니다. 대기 Edge가 활성 Edge와 동기화해야 하는 터널 수가 80을 초과하면 대기에서 예외 및 데이터부 서비스 실패가 트리거됩니다. 기존 HA 토폴로지에서 이 문제가 발생하는 경우 대기 Edge가 고객 트래픽을 전달하지 않으므로 고객에게 미치는 영향은 최소화됩니다. 대기 Edge가 트래픽도 전달하는 고급 HA 배포에서는 재부팅으로 인해 일부 고객 트래픽이 중단될 수 있습니다.
해결된 문제 83611: 고객은 VMware SASE Orchestrator UI의 VMware SD-WAN Hub Edge에서 비정상적으로 많은 EDGE_NEW_DEVICE 이벤트를 확인할 수 있습니다.
이 문제는 다음 토폴로지에서 발생할 수 있습니다. 클라이언트 디바이스 - 스포크 Edge - 허브 Edge - DHCP 서버. 이 토폴로지를 사용하면 스포크 Edge 뒤의 클라이언트 사용자가 DHCP 패킷을 보낼 때마다 스포크 Edge가 이 클라이언트 디바이스에 대한 Edge_New_Device 이벤트를 올바르게 트리거합니다. 하지만 허브 Edge가 DHCP 릴레이 패킷을 수신할 때 허브 Edge가 Orchestrator에 대한 Edge_New_Device 이벤트를 다시 트리거하며, 이 이벤트는 올바르지 않습니다.
해결된 문제 83699: VMware SASE Orchestrator의 새 UI에서 VMware SD-WAN Gateway가 중지 모드로 설정된 경우 사용자가 교체용 게이트웨이를 새로 선택하면 Orchestrator는 교체 게이트웨이에 대한 구성 변경을 허용하지 않습니다.
이 문제는 중지된 게이트웨이를 대체하는 새 게이트웨이를 선택하는 Orchestrator의 새 UI 부분을 통해 비 SD-WAN 대상 마이그레이션 프로세스를 활성화한 후에 발생합니다. 새 게이트웨이가 교체용 게이트웨이로 지정된 경우 교체용 게이트웨이의 구성을 변경하려고 하면 운영자에게 다음과 유사한 오류 메시지가 표시됩니다. GATEWAY_SERVICE_STATE_INVALID: Cannot change the state of the gateway to null, as it is already used as a replacement gateway
해결된 문제 83928: VMware SD-WAN Edge에서 높은 CPU 사용량과 낮은 고객 트래픽 성능이 발생할 수 있습니다.
해당 Edge에 대한 Orchestrator의 모니터링(Monitor) > Edge > QoE 화면을 볼 때 낮은 QoE 점수를 확인할 수도 있습니다. 이 문제는 Edge에서 여러 번 인스턴스화되는 ACL(액세스 제어 목록) 규칙으로 인해 발생하며, 이러한 많은 ACL 규칙을 한 번에 처리하는 것은 Edge의 CPU 용량에 스트레스를 주게 되며 Edge는 고객 트래픽을 제대로 처리할 수 없게 됩니다.
해결된 문제 83946: VMware SD-WAN Edge LAN 측 클라이언트는 트래픽 중단을 관찰할 수 있으며 RADIUS 인증을 사용하는 사이트의 경우 클라이언트 사용자가 인증 실패를 관찰할 수 있습니다.
큰 패킷은 조각화되고 이러한 조각화된 패킷은 Edge에 의해 삭제될 수 있습니다. 일부 오류 시나리오에서 조각 IP ID 변환 중에 메모리 누수로 인해 패킷이 삭제되고, 조각화된 패킷에 대한 Edge 제한이 초과되면 조각화된 패킷이 Edge에서 추가로 삭제됩니다.
무선 클라이언트에서 Edge로 RADIUS 인증을 사용하는 큰 패킷이 포함된 RADIUS를 사용하는 고객의 경우 이로 인해 인증이 실패할 수 있습니다. 예를 들어, WLC(무선 LAN 컨트롤러)에서 RADIUS 서버로 전송되는 큰 패킷이 삭제될 수 있습니다.
해결된 문제 84106: VMware SD-WAN Edge가 잘못된 시간 간격으로 NetFlow 통계를 내보내서 수신 시스템이 동기화되지 않을 수 있습니다.
NetFlow 패킷은 구성된 간격에서 5초의 추가 지연이 있을 수 있습니다. NetFlow 내보내기는 5초마다 한 번씩만 내보내기 시간을 확인하므로 NetFlow 패킷에서 구성된 간격과 실제 내보내기 간격 사이에 5초 정도 지연이 발생할 수 있기 때문입니다.
해결된 문제 84359: VMware SD-WAN Edge 인터페이스가 플래핑되면 여러 IPv4 주소를 할당할 수 있습니다.
인터페이스가 DHCP 클라이언트 플래핑(빠르게 연속해서 종료되었다가 실행됨)으로 구성되면 전체 DHCP 클라이언트 프로세스가 다시 수행되고 매번 다른 IP 주소를 획득하는 시나리오가 있을 수 있습니다. 이 경우 이전 IP 주소는 지워지지 않고 오래된 상태가 됩니다.
이 수정 사항을 적용하지 않으면 이 문제를 해결하는 유일한 방법은 사용자가 ip address del 명령을 사용하여 Linux 셸을 통해 인터페이스에서 IP 주소를 수동으로 삭제하는 것입니다.
해결된 문제 84501: 802.1x 인증(예: RADIUS, Cisco ISE)을 사용하는 고객 엔터프라이즈의 경우 VMware SD-WAN Edge를 릴리스 4.3.1 이상으로 업그레이드하면 Edge에 연결된 클라이언트 디바이스는 WAN을 통해 호스팅되는 NAS(네트워크 액세스 서버)에 대한 인증에 실패할 수 있습니다.
NAS IP 주소는 Edge(인증자)에서 RADIUS 또는 ISE 서버로 전송된 RADIUS 또는 ISE 패킷에서 기본적으로 루프백 IP 주소로 설정되며 이로 인해 인증 패킷이 NAS에 도달하지 않아 인증이 실패할 수 있습니다. 이 문제를 해결하기 위해 이 수정 사항이 적용된 빌드는 NAS IP 주소를 802.1x 인증 설정에 선택 및 구성된 소스 인터페이스 IP 주소로 설정합니다. '자동(Auto)'을 소스 인터페이스로 선택한 경우 루프백 IP가 기본적으로 NAS IP 주소로 설정됩니다.
해결된 문제 84825: 단일 단계에서 VMware SD-WAN Edge에 대량 라우팅 구성을 적용하면 Edge에서 데이터부 서비스 오류가 반복적으로 발생하여 Edge 서비스가 반복적으로 다시 시작되어 각 오류로부터 복구될 수 있습니다.
독립형(비 HA) Edge에서 이 문제가 발생하는 경우 단일 Edge 서비스를 다시 시작하면 최대 15초 동안 트래픽이 중단되지만 Edge 서비스 다시 시작을 반복하면 최대 60초 이상이 중단되므로 고객 트래픽에 상당한 영향을 미칩니다. 고가용성 토폴로지가 있는 사이트에서 Edge 서비스가 다시 시작되어 고객 트래픽도 중단되는 페일오버가 반복적으로 발생합니다.
이 문제는 많은 수의 인접 항목 및 경로 맵을 포함하는 대량 라우팅 구성이 단일 단계로 Edge에 적용되는 경우에 발생합니다. Edge 시스템은 이러한 구성을 명령 규격으로 변환하고 짧은 기간 내에 라우팅 프로토콜에 적용하면서 스트레스가 매우 커지고 이로 인해 Edge 서비스 실패 및 다시 시작이 반복됩니다.
수정 사항을 적용하지 않은 Edge 빌드에서 이 문제의 위험을 완화하려면 고객 사용자는 다음을 수행해야 합니다.
단일 단계에서 대규모 구성을 적용하는 대신, 각 섹션이 별도로 적용된 여러 개의 작은 섹션으로 구성을 구분해야 합니다.
라우팅 필터 수를 최소화해야 합니다.
Edge는 유지 보수 기간에만 고의로 다시 시작해야 하며, 다시 시작하는 동안 전체 Edge 구성이 한 번에 적용되어 이 문제가 발생할 위험이 크게 증가하므로 여러 라우팅 필터가 구성된 경우 일반적으로 Edge 서비스를 다시 시작하지 않아야 합니다.
해결된 문제 84847: VMware SD-WAN Edge에 USB 기반 LTE 모뎀을 배포하거나 VMware SD-WAN Edge LTE 모델(510-LTE 610-LTE)을 배포하는 고객의 경우 모뎀을 재설정한 후 CELL 인터페이스에서 터널을 구축할 때 간헐적으로 문제가 발생할 수 있습니다.
다음 시나리오 중 하나에서 LTE 모뎀을 재설정한 경우:
USB 모뎀을 사용하는 Edge에서 USB 포트의 모뎀을 제거했다가 다시 연결한 경우.
Edge-LTE에서 Edge를 재부팅한 후 또는 테스트 및 문제 해결(Test & Troubleshoot) > 원격 진단(Remote Diagnostics) > USB 모뎀 재설정(Reset USB Modem) > CELL1을 통해 CELL1 인터페이스를 재설정한 경우.
두 시나리오 모두에서 기본 네트워크 디바이스가 wwan0에서 wwan1로 변경되고 Edge는 중복된 인터페이스로 표시되기 때문에 이 새 이름이 적용되지 않습니다.
이 수정 사항을 적용하지 않은 경우 LTE 인터페이스를 복원하는 해결 방법은 원격 작업(Remote Actions) > 서비스 다시 시작(Restart Service)을 통해 Edge 서비스를 다시 시작하는 것입니다.
해결된 문제 85369: 고가용성 토폴로지를 사용하여 배포된 사이트의 경우 고객 트래픽이 중단되고 VMware SD-WAN 대기 Edge가 여러 차례 재부팅될 수 있습니다.
HA Edge의 여러 스레드가 일시 중단되고 HA 활성-활성 상태를 포함하지만 이에 국한되지 않는 다양한 문제가 HA에서 발생합니다. 사이트가 활성-활성 상태가 되는 경우 대기 Edge가 이 토폴로지에서 트래픽을 전달하지 않으므로 기존 HA 설정에서는 최소한의 트래픽 중단만 발생하지만 대기 Edge가 트래픽도 전달하는 고급 HA 배포에서는 재부팅으로 인해 일부 고객 트래픽이 중단될 수 있습니다. 또한 여러 스레드의 일시 중단으로 인해 고객 트래픽 중단으로 확인될 수 있는 경로 중단이 발생할 수 있습니다. 따라서 대기 Edge가 재부팅되는 활성-활성 시나리오의 징후가 나타나지 않으면서 고객 HA 사이트에서 이 문제가 발생할 수 있습니다.
여러 HA Edge 스레드가 일시 중단되는 것에 대한 근본 원인은 여전히 조사 중입니다.
해결된 문제 85375: VMware SD-WAN Edge에서 USB 기반 LTE 모뎀을 사용하거나 VMware SD-WAN Edge LTE 모델(510-LTE 또는 610-LTE)을 사용하는 고객은 LTE 트래픽이 중단될 수 있습니다.
LTE 인터페이스를 통과하는 트래픽 없이 증가되는 Edge 로그 RX 오류가 확인될 수 있습니다. 이 문제의 한 가지 측면은 LTE 링크의 MTU가 1500 미만인 경우에만 발생한다는 것입니다.
해결된 문제 85459: LAN 측 NAT 규칙이 구성된 후 Edge LAN 측 클라이언트에서 Edge로 또는 원격 분기 Edge 클라이언트에서 Edge로 SSH를 수행하려는 시도가 작동하지 않을 수 있습니다.
Edge의 SSH 프로세스에서 수신되는 SSH 응답 패킷 패킷은 Edge의 데이터부 서비스를 통과하며 LAN 측 NAT 규칙이 구성된 후에 SSH 응답 패킷이 LAN 측 NAT 규칙을 사용하여 SSH 트래픽을 생성한 원래 클라이언트가 아닌 다른 대상으로 이동하면 Edge에 대한 SSH 시도가 작동하지 않을 수 있습니다.
수정 사항이 없는 Edge에서 유일한 해결 방법은 NAT 규칙을 제거하는 것입니다.
해결된 문제 86032: VMware SD-WAN Gateway를 릴리스 4.3.x에서 4.5.1 또는 5.0.0으로 업그레이드하면 게이트웨이는 VMware SASE Orchestrator와의 통신이 끊어지고 eth0 및 eth1 인터페이스가 제거됩니다.
핵심 문제는 업그레이드 후 게이트웨이의 데이터부 프로세스가 중지되는 것입니다. 이 문제는 Telegraf 서비스를 시작하지 못하고 Telegraf 서비스가 게이트웨이 시작 스크립트의 일부로 활성화되기 때문에 발생하며, Telgraf가 시작되지 않으면 게이트웨이 서비스도 시작되지 못합니다.
게이트웨이가 이 수정 사항이 적용되지 않은 빌드로 업그레이드되는 경우 문제를 해결하는 유일한 방법은 Telegraf 서비스를 다시 시작하면서 게이트웨이에 대해 vc_procmon restart를 실행하는 것입니다.
해결된 문제 86103: RADIUS 인증을 사용하는 고객 엔터프라이즈의 경우 일부 사이트의 클라이언트 사용자가 VMware SD-WAN Edge에 연결하여 트래픽을 전달하지 못할 수 있습니다.
이 문제는 Edge가 IP 헤더에 DF(Don't Fragment) 비트에 설정된 조각화된 RADIUS 패킷을 조각화되지 않은 것으로 잘못 분류하기 때문에 발생합니다. 이러한 패킷 중 하나 이상이 여러 Edge에 도달하지 못하므로 RADIUS 인증에 의존하는 트래픽이 해당 Edge에 대해 전달되지 않습니다. 이 문제는 허브/스포크 및 단순 분기 간을 비롯한 모든 토폴로지에서 발생할 수 있습니다.
이 수정 사항을 적용하지 않을 경우 유일한 해결 방법은 조각난 패킷을 전송하는 동안 IP 헤더에 DF 비트를 설정하지 않도록 RADIUS 서버를 구성하는 것입니다.
해결된 문제 86314: 원격 피어에 의해 LAN 측 NAT 흐름이 시작될 때 VMware SD-WAN Edge가 잘못된 상태 저장 방화벽 규칙 조회를 시행할 수 있습니다.
사용자가 상태 저장 방화벽이 사용 중인 Edge에서 LAN 측 소스 NAT를 구성하고(예: Edge 뒤에 내부 IP 서브넷을 숨김) 원격 피어에서 흐름이 시작되면 첫 번째 반환 패킷에 대해 잘못된 방화벽 조회가 수행됩니다.
예를 들어 Edge에 다음과 같은 구성이 있다고 가정합니다.
LAN-side NAT: [source] inside address: 10.0.2.25/32 outside address: 7.0.2.25/32 Static route: 7.0.2.25/32 [advertise] next hop: 10.0.2.1원격 클라이언트가 10.0.1.25에서 7.0.2.25로 ping을 보내면 Edge에서 두 개의 방화벽 규칙 조회가 발생합니다. 첫 번째 수신 패킷으로 인해 10.0.1.25 > 7.0.2.25에 대한 방화벽 조회가 발생하고 첫 번째 반환 패킷은 10.0.2.25 > 10.0.1.25에 대해 비 NAT IP를 사용하여 방화벽 규칙 조회가 수행되도록 합니다. 두 번째 방화벽 규칙 조회는 오류로 수행됩니다.
이 수정 사항이 없으면 사용자는 흐름의 첫 번째 반환 패킷을 허용하는 추가 방화벽 규칙을 생성해야 합니다.
해결된 문제 86617: BGP가 구성된 파트너 게이트웨이에서 루프백 IP 주소를 사용하는 고객 엔터프라이즈의 경우 루프백 IP 경로를 사용해야 하는 트래픽이 삭제되어 고객 트래픽이 중단되는 것을 확인할 수 있습니다.
루프백 IP 주소 경로가 VMware SD-WAN Edge에서 누락되고 Edge 및 파트너 게이트웨이에 대해 BGP가 구성되고 루프백 IP 주소가 BGP를 통해 Edge로 전송되지만 Edge가 루프백 IP 경로를 학습하지 않는 경우에 문제가 발생합니다.
해결된 문제 86740: 원격 진단 "인터페이스 상태"를 실행할 때 VMware SD-WAN Edge의 SFP2 인터페이스에 배포되는 동안 GPON 유형 SFP 모듈이 표시되지 않습니다.
이 문제는 Edge에서 실행되고 Edge의 SFP2 인터페이스를 제대로 고려하지 않는 원격 진단 백엔드 스크립트의 결함으로 인해 발생합니다.
해결된 문제 86808: 일부 BGP 경로가 BGP 필터에 따라 애드버타이즈되지 않아야 할 때 애드버타이즈되거나 애드버타이즈되어야 할 때 애드버타이즈되지 않습니다.
지정된 경로 맵 규칙의 경우 Edge에는 규칙 일치 유형을 기준으로 하는 Edge 라우팅에 대한 prefix-list 또는 community-list 구성이 있을 수 있습니다. 그러나 route-map 적용 취소 기능의 경우 Edge는 각 규칙에 대해 prefix-list와 community-list를 모두 삭제하려고 합니다. 그렇지만 이중 하나는 존재하지 않습니다.
이전에는 존재하지 않는 prefix-list 및/또는 community-lists에 대한 명령이 별도의 vtysh 명령으로 Edge의 라우팅 프로세스로 전송되어 no-ops가 되고 다른 명령에는 영향을 주지 않기 때문에 문제가 발생하지 않았습니다. 당시에는 route-map 적용 취소 기능에서 간단히 진행되므로 의도적으로 호출되었습니다.
그렇지만 문제 #84825에 대한 수정 사항의 일부로, Edge는 Edge의 라우팅 프로세스로 전송할 여러 prefix-lists/community-list removal vtysh 명령을 함께 일괄 처리하기 시작했습니다. 이제 존재하지 않는 prefix-list/community-list를 삭제하려고 하면 전체 명령 배치가 실패하고 Edge의 라우팅 프로세스에서 오래된 prefix-list/community-list 구성으로 Edge가 채워집니다.
이 문제에 대한 수정 사항이 포함되지 않은 Edge에서 사용자는 모든 BGP 경로가 적절히 애드버타이즈되도록 Edge 서비스를 다시 시작해야 합니다.
해결된 문제 87304: 사용자가 VMware SASE Orchestrator UI를 사용하여 VMware SD-WAN Edge에서 LAN 인터페이스를 비활성화하는 경우에도 인터페이스가 SNMP에 의해 [실행 중]으로 보고됩니다.
인터페이스 출력에 대한 키 디버그 프로세스에는 Edge LAN 인터페이스(예: GE1 또는 GE2)에 대한 물리적 포트 세부 정보가 포함되지 않습니다. 따라서 SNMP가 해당 인터페이스를 폴링할 때 인터페이스가 구성된 방식에 관계없이 항상 실행 중 결과를 반환합니다.
해결된 문제 87552: VMware SD-WAN Edge가 Edge를 통한 NSD(비 SD-WAN 대상)(Non SD-WAN Destination via Edge) 또는 CSS(클라우드 보안 서비스)를 사용하도록 구성된 경우 VMware SD-WAN Edge에서 정기적으로 데이터부 서비스 장애가 발생할 수 있으며 NSD 또는 CSS 터널이 불안정하면 다시 시작됩니다.
Edge가 NSD 또는 CSS(IPsec 또는 GRE)에 대한 터널을 해체하면 이전에 선택한 터널의 잘못된 릴리스가 수행되어 Edge 데이터부 서비스에서 예외가 트리거되고 Edge 서비스가 다시 시작되어 서비스가 복원됩니다. Edge 서비스를 다시 시작하면 고객 트래픽이 10~15초 동안 중단됩니다.
이 문제에 대한 수정 사항이 없는 Edge에서는 Edge를 통한 NSD 또는 CSS를 하나의 WAN 링크에 연결하여 이 문제가 발생할 가능성을 줄입니다. 즉, 여러 WAN 링크에서 NSD 또는 CSS를 구성하는 대신 하나의 WAN 링크만 선택합니다. 이렇게 하면 이중화가 손실되지만 이 문제로 인한 영향이 완화됩니다.
해결된 문제 87612: 하나 이상의 VLAN에서 VNF 삽입을 사용하는 VMware SD-WAN Edge의 경우 해당 VLAN의 클라이언트 사용자가 DHCP 릴레이 서버에서 IP 주소를 가져올 수 없습니다.
Edge가 DHCP 릴레이 패킷을 전달하지 않으므로 클라이언트 사용자가 IP 주소를 수신하지 않습니다.
수정 사항이 적용되지 않은 경우 유일한 해결 방법은 VLAN에서 VNF 삽입을 사용하지 않는 것입니다.
해결된 문제 87982: 개인 PPPoE WAN 링크가 있는 Metanoia-type SFP 모듈을 사용하는 VMware SD-WAN Edge가 BGP 피어링을 설정하고 다른 사이트에 연결하지 못할 수 있습니다.
개인 PPPoE 링크를 사용하여 VLAN 태그가 지정된 패킷이 Edge에 의해 손상되고 결과적으로 대상에 도달하지 않습니다. 이 문제는 공용 PPPoE 링크에 영향을 주지 않습니다.
해결된 문제 88757: Orchestrator UI에서 [원격 진단(Remote Diagnostic)] > [경로 테이블 덤프(Route Table Dump)]를 실행 중인 경우 시도 시간이 초과되어 페이지가 결과를 반환하지 않을 수 있습니다.
WebSocket 시간 초과가 30초이고 많은 수의 경로가 있는 사이트에서는 디버그 명령이 Orchestrator로 모든 경로를 전달하는 데 걸리는 시간이 이 시간을 초과할 수 있으므로 경로 테이블 덤프 진단 시간이 초과될 수 있습니다. 이 수정 사항은 경로 덤프 프로세스의 시간 초과를 30초 미만으로 줄이고 WebSocket이 그 전에 시간 초과되지 않게 하므로 경로 테이블 덤프가 결과를 반환하게 됩니다.
해결된 문제 88796: VMware SASE Orchestrator 또는 VMware SD-WAN Gateway를 배포하고 vSphere에서 OVA를 사용하는 경우 배포의 일부로 설정된 OVF 속성(암호, 네트워크 정보 등)이 이미지에 적용되지 않으며 배포 후에 시스템에 액세스할 수 없습니다.
이것은 OVF/vApp 속성을 사용하여 OVA에서 배포된 새 시스템에만 영향을 줍니다(ISO 파일 사용과 비교). 이 문제는 최근 업데이트에서 cloud-init에 대한 업스트림 변경으로 인해 발생합니다.
이 수정 사항을 적용하지 않은 게이트웨이에서는 운영자가 cloud-init user-data ISO 파일을 사용하여 시스템을 배포하면 문제를 해결할 수 있습니다.
이 열린 티켓은 게이트웨이 빌드에만 적용됩니다. Orchestrator 문제는 릴리스 R5002-20220517-GA 빌드 이상에서 해결되었습니다.
해결된 문제 89217: 6x0 모델 라인(610, 610N, 610-LTE, 620, 620N, 640, 640N, 680, 680N)의 VMware SD-WAN Edge가 이유 없이 갑자기 전원이 꺼질 수 있습니다.
6x0 Edge는 전면 상태 LED 및 후면 이더넷 포트 표시등을 모두 끄고 수동으로 Edge 전원 주기를 수행해야만 복구할 수 있습니다.
이 문제의 원인은 v20M 또는 이전 버전(v20L, v20K, v20J)의 PIC 펌웨어 버전을 사용하는 Edge 6x0 라인 전용의 PIC 마이크로 컨트롤러로 추적됩니다. 이 문제는 6x0 Edge가 v20M 또는 이전 버전의 PIC 버전을 사용하는 경우에만 발생할 수 있지만 이 버전에서도 전원 끄기 문제가 발생하는 경우는 드물게 발생합니다(약 1/1,000). 이 문제는 v20N 이상의 PIC 펌웨어 버전을 사용하는 6x0 Edge에서는 발생할 수 없습니다.
해당 Edge에 대한 모니터링(Monitor) > Edge > 개요(Overview) 페이지로 이동하고 Edge 정보, 디바이스 버전 및 디바이스 펌웨어를 포함하는 Edge 이름 옆에 있는 드롭다운 정보 상자를 클릭하여 5.x를 사용하는 Orchestrator에서 PIC 버전을 포함하는 6x0 Edge의 펌웨어를 확인할 수 있습니다.
이 문제는 6x0 Edge를 플랫폼 펌웨어 1.3.1(R131-20221216-GA)로 업그레이드해야 해결되며, 여기에는 PIC 버전 v20N이 포함됩니다. 이렇게 하려면 릴리스 5.x(5.0.0 이상)를 사용하여 VMware SASE Orchestrator에 연결해야 하며 6x0 Edge를 먼저 Edge 핫픽스 빌드 R5012-20230327-GA-107522로 업그레이드해야 합니다. 6x0 Edge가 R5012-20230327-GA-107522로 업그레이드되면 사용자는 Edge의 소프트웨어 버전이 수정되는 것과 동일한 방식으로 6x0 Edge 플랫폼 펌웨어를 버전 R131-20221216-GA로 업데이트합니다.
6x0 Edge를 플랫폼 펌웨어 1.3.1로 업그레이드하기 위한 자세한 내용 및 단계별 가이드는 다음 KB 문서를 참조하십시오. VMware SD-WAN 6X0 모델 Edge는 LED 없이 전원이 꺼질 수 있고 전원 주기를 작동 상태로 되돌려야 할 수 있습니다(88970). 이 KB 문서는 문제를 해결하는 데 필요한 새로운 Edge 및 플랫폼 소프트웨어를 반영하기 위해 2023년 4월 4일에 업데이트되었습니다.
Orchestrator에 플랫폼 펌웨어 번들을 업로드하는 데 대한 자세한 내용은 VMware SD-WAN 운영자 가이드의 새 Orchestrator UI를 사용하는 플랫폼 펌웨어 및 공장 이미지 섹션을 참조하십시오.
6x0 Edge의 플랫폼 펌웨어 업데이트에 대한 내용은 VMware SD-WAN 관리 가이드의 Edge 정보 보기 또는 수정 섹션을 참조하십시오.
Edge를 더 낮은 소프트웨어 릴리스(예: 릴리스 4.3.1 또는 4.5.1)로 유지하려는 경우 고객은 일시적으로 Edge를 R5012-20230327-GA-107522로 업그레이드하고, 플랫폼 펌웨어를 버전 1.3.1(R131-20221216-GA)로 업그레이드하여 PIC 버전을 v20N으로 유지한 다음, Edge 소프트웨어를 기본 버전으로 다시 다운그레이드할 수 있습니다. 6x0 Edge의 소프트웨어를 이전 버전으로 다운그레이드해도 Edge의 플랫폼 펌웨어도 다운그레이드되지 않으며 Edge는 계속해서 플랫폼 펌웨어 버전 1.3.1을 사용합니다. 이 사용 사례에서 고객 Edge는 릴리스 5.x를 사용하여 Orchestrator에 있어야 합니다.
6x0 Edge가 버전 5.x를 사용하지 않는 Orchestrator에 있고 이 문제가 발생했으며, 해당 PIC 펌웨어를 업데이트해야 하는 경우 고객은 VMware SD-WAN 지원에 문의할 수 있으며 Edge의 PIC 버전을 수동으로 업데이트합니다.
해결된 문제 89873: VMware SD-WAN Edge의 메모리 활용률이 증가하여 Orchestrator에서 메모리 사용량 주의 이벤트가 발생하고 Edge의 메모리를 복구하기 위해 갑작스럽게 Edge 서비스가 다시 시작될 수 있습니다.
이 문제는 고유한 IP 주소 및 포트가 있는 UDP 흐름이 Edge에서 높은 비율로 처리될 때 발생합니다. 흐름 생성 은 Edge에서 비동기식으로 처리되며 동일한 흐름의 여러 패킷이 흐름 생성 서비스 큐에 대기되면 흐름 개체가 누수되어 Edge 메모리 누수로 이루어집니다. 이러한 영향은 Edge 메모리 양이 더 적지만 충분히 긴 기간에 걸쳐 모든 Edge 모델이 위험 메모리 수준(90초 이상 동안 메모리 활용률 60%)에 도달하고 다시 시작될 수 있는 초급 Edge 모델(예: 510, 610 또는 620)에서 더 일반적으로 발견됩니다. 메모리를 지우기 위해 계획되지 않은 Edge 서비스를 다시 시작하면 고객 트래픽이 잠시 중단될 수 있습니다.
이 문제에 대한 수정 사항을 적용하지 않을 경우 이 문제가 고객 사이트에 영향을 미치지 않도록 하는 유일한 방법은 메모리를 모니터링하는 것입니다. 메모리 활용률이 40%에 도달하고 Orchestrator가 메모리 주의 이벤트를 기록하면 유지 보수 기간 동안 Edge 서비스가 다시 시작되도록 스케줄링하여 메모리를 지우고 고객에게 미치는 영향을 최소화합니다.
해결된 문제 90151: 게이트웨이의 IPsec을 통한 BGP의 경우 기본 및 보조 인접 항목에 다른 BGP 필터를 적용하는 것이 예상대로 작동하지 않을 수 있습니다.
VMware SD-WAN Gateway의 기본 및 보조 인접 항목의 NSD(비 SD-WAN 대상)-BGP에 서로 다른 필터를 적용하면 BGP 인접 항목 둘 다에 하나의 필터만 적용됩니다.
이 문제의 원인은 PG(파트너 게이트웨이)-BGP의 경우 SD-WAN 서비스가 파트너 게이트웨이-BGP에 대해 enterprise_logical_id와 segment_id의 조합을 사용하고 enterprise_logical_id를 사용하여 BGP 필터를 식별하며, 지정된 엔터프라이즈 세그먼트 조합의 경우 SD-WAN에는 PG-BGP 인접 항목이 하나만 있을 수 있기 때문입니다.
그러나 이 방법은 동일한 엔터프라이즈 세그먼트 조합에 대해 최대 2개의 BGP 인접 항목(기본 및 보조)이 있을 수 있는 게이트웨이의 NSD-BGP에 대해 상속되었습니다. 따라서 enterprise_logical_id 및 segment_id 조합은 2개의 서로 다른 NSD-BGP 인접 항목의 필터를 구분하는 데 충분하지 않습니다.
해결된 문제 90283: VMware SD-WAN Edge에서 사용되는 WAN 링크에 대해 언더레이 계산이 켜진 경우 고객이 VoIP 및 화상 통화 호출에서 경험하는 오디오 및/또는 비디오 품질이 저하될 수 있습니다.
로그를 확인할 때 사용자는 트래픽이 비대칭으로 라우팅되고 경로 중 하나가 언더레이를 통해 전송되는 양방향 트래픽용 패킷을 확인합니다. 즉, 흐름에 대한 경로가 한 방향의 비대칭이면 트래픽이 언더레이 경로를 가져오고, 역방향으로 오버레이 경로를 가져오며, 해당 WAN 링크에 대해 언더레이 계산(Underlay Accounting)이 켜져 있는 경우, 패킷 손실이 VoIP 및 화상 통화 호출 등의 일반적인 양방향 흐름에서 발생할 수 있습니다.
해결된 문제 90876: LAN 인터페이스 또는 게이트웨이 IP 없이 라우팅된 하위 인터페이스를 통해 VMware SD-WAN Edge에 연결된 단일 홉 외부 클라이언트에 대해 비글로벌 세그먼트에서 DNS가 실패합니다.
이 문제의 원인은 단일 홉 외부 클라이언트가 사용 중인 Edge 인터페이스 유형에 따라 다릅니다.
단일 홉 외부 클라이언트가 LAN 포트를 통해 Edge에 연결된 경우 비글로벌 세그먼트에 대한 DNS 확인에 실패합니다. Edge가 클라이언트로 응답 패킷을 라우팅하는 것은 VCE1 인터페이스이고 Edge 프로세스는 이를 글로벌 세그먼트로 처리하기 때문입니다. 그에 따라 글로벌 세그먼트 라우팅 테이블에서 고정 경로를 사용할 수 있으므로 응답 패킷이 삭제됩니다.
단일 홉 외부 클라이언트가 게이트웨이 IP 주소와 Orchestrator의 클라이언트에 대한 고정 경로가 없는 라우팅된 하위 인터페이스 포트를 통해 Edge에 연결된 경우 Edge에 클라이언트에 대한 경로가 없으므로 클라이언트에 대한 DNS 확인이 실패합니다. 연결된 경로와 일치하고 대상 IP 자체에 대한 ARP를 전송하고 ARP가 실패하며 응답이 전송되지 않습니다.
이 문제에 대한 수정 사항이 없는 Edge의 경우 Edge의 LAN을 사용하는 클라이언트에 대한 해결 방법은 글로벌 세그먼트만 사용하는 것입니다. 라우팅된 하위 인터페이스를 사용하는 클라이언트의 경우 해결 방법은 게이트웨이 IP 주소를 제공하는 것이며, 불가능한 경우 글로벌 세그먼트만 사용하는 것입니다.
해결된 문제 91875: VMware SD-WAN Edge에서 WAN 링크를 백업으로 구성한 고객의 경우 링크가 활성 상태가 되는 데 필요한 조건이 없더라도 백업 WAN 링크가 간헐적으로 활성 상태가 되는 것을 볼 수 있습니다.
이 문제는 Edge가 백업 WAN 링크가 필요하다고 잘못 생각하게 되고 Edge가 이 잘못된 터널을 감지하고 해체하기 위한 페일세이프가 없는 해당 링크에 대한 터널을 구축하도록 하는 Edge 프로세스의 경합 조건으로 인해 발생합니다.
해결된 문제 93052: VMware SD-WAN Edge 뒤의 클라이언트 사용자는 높은 지연 시간 및 느린 처리량 속도를 비롯한 트래픽 품질 저하를 확인할 수 있습니다.
이 문제의 즉각적인 원인은 100% Edge CPU 사용량으로 실행되는 경로 FSM(Finite State Machine) 스레드입니다. Edge CPU가 100%로 실행되면 경로 품질이 저하됩니다.
경로 FSM 스레드가 Edge CPU를 최대로 사용하는 이유는 신뢰할 수 없는 카운터 값으로 인해 경로 FSM 스레드가 제공하는 대기열에 더 많은 메시지가 있다(실제로는 메시지가 없음)고 단정하기 때문입니다. 이로 인해 스레드가 절전 모드로 전환되지 않고 항상 실행됩니다. 이 버그 수정 사항은 실제 대기열 데이터 구조를 확인하여 대기열의 상태를 결정하는 API를 추가합니다.
해결된 문제 93383: VMware SD-WAN Edge에서 고객 트래픽 중단으로 인해 하나 이상의 데이터부 서비스 장애가 발생할 수 있습니다.
이 문제는 두 개의 서로 다른 데이터 구조의 Edge에 저장된 인터페이스가 일치하지 않는 드문 상황으로 인해 발생하고, 그에 따라 예외가 트리거되고 Edge 서비스에서 여러 차례 장애가 발생합니다. 복구를 위해 Edge 서비스를 다시 시작해야 하고, HA가 아닌 배포에서 재시작할 때마다 고객 트래픽이 10~15초 동안 중단됩니다. 하지만 Edge 서비스가 세 번 연속으로 실패하는 경우 Edge를 복구하려면 재부팅 또는 전원 주기가 필요합니다.
Orchestrator 빌드 R5014-20230408-GA는 2023년 4월 11일에 릴리스되었으며 네 번째 릴리스 5.0.1용 Orchestrator 롤업입니다.
이 Orchestrator 롤업 빌드는 Orchestrator 빌드, R5013-20230310-GA 이후의 아래와 같은 중요한 문제를 해결합니다.
해결된 문제 107766: 고객이 Edge를 통한 비 SD-WAN 대상(Non SD-WAN Destination via Edge) 또는 CSS(클라우드 보안 서비스)를 구성하고 수준 7(L7) 상태 점검 옵션도 구성하는 경우 터널이 L7 상태 점검 구성 값을 기준으로 할 때와 비교하여 예기치 않게 종료 또는 실행 중으로 표시될 수 있습니다.
이 문제는 Orchestrator가 고객이 구성한 항목과 관계없이 기본 L7 상태 점검 매개 변수를 VMware SD-WAN Edge로 푸시한다는 것입니다. 따라서 터널의 조건이 고객이 구성한 조건과 일치하더라도 터널 상태가 기본 L7 상태 점검 값을 준수하기 때문에 변경되지 않은 상태로 유지될 수 있습니다.
해결된 문제 108363: VMware SASE Orchestrator를 5.x 릴리스로 업그레이드한 후 Zscaler와 같은 CSS(클라우드 보안 서비스)를 배포하고 수준 7(L7) 상태 점검도 구성된 VMware SD-WAN Edge는 해당 CSS를 사용하는 트래픽이 약 30초 동안 손실될 수 있습니다.
Orchestrator가 업그레이드되면 모든 Edge에 대한 구성 업데이트가 트리거되고 이로 인해 구성이 수정될 때까지 L7 상태 점검이 구성된 일부 CSS 사이트가 종료될 수 있습니다.
이 문제는 Edge의 문제를 해결하는 해결된 문제 #107302로 연결됩니다. 이 버그 수정은 Orchestrator가 업그레이드 시 Edge에 대한 구성 업데이트를 트리거하지 못하게 하므로 #107302에 대한 수정 사항이 없는 Edge를 보호합니다.
해결된 문제 110946: 릴리스 4.2.x 이하를 사용하는 VMware SD-WAN Orchestrator는 릴리스 4.3.x 이상을 사용하여 SASE Orchestrator로 업그레이드하면 실패할 수 있습니다.
4.2.x 이하 Orchestrator는 4.3.x 이상으로 업그레이드할 때 apt update service 루틴을 실행하기 전에 apt 캐시를 정리하지 않으므로 업그레이드 중에 MySQL 데이터베이스가 다시 시작되어 업그레이드가 실패합니다.
이 문제에 대한 수정 사항 없이 Orchestrator 버전으로 업그레이드하는 경우 운영자는 업그레이드 전에 명령 rm -rf /var/lib/apt/lists/를 실행할 수 있습니다.
해결된 문제 111946: 피어 목록이 100보다 크면 VMware SASE Orchestrator에서 [Edge] > [모니터링(Monitor)] > [경로(Paths)] 탭에서 경로를 볼 수 없습니다.
사용자가 Edge > 모니터링(Monitor) > 경로(Paths) 탭으로 이동하면 Orchestrator의 백엔드는 레코드가 100개보다 많은 경우에도 모든 레코드가 반환됩니다. 백엔드가 반환해야 하는 최대 레코드 수인 제한 제약 조건을 생략하기 때문입니다. 제한 개수를 넘어 반환되는 레코드는 정규화되지 않습니다. 즉, UI와 호환되는 방식으로 형식이 지정되지 않습니다. 이로 인해 UI에 오류가 발생합니다. Orchestrator는 제출된 제한 내에 있는 레코드만 반환해야 합니다.
해결된 문제 111957: 운영자가 VMware SASE Orchestrator를 업그레이드한 후 실패한 장기 실행 스키마 업데이트와 관련된 오류가 표시될 수 있습니다. 예를 들어 새로 학습된 경로(BGP 또는 OSPF)가 OFC 페이지에서 누락될 수 있습니다. 학습된 경로와 관련된 Orchestrator의 업로드 로그에서도 오류가 확인됩니다.
Orchestrator를 장기 실행 스키마 업데이트로서 릴리스 4.2.x에서 릴리스 4.3.x 이상으로 업그레이드할 때 VELOCLOUD_LEARNED_PARTNER_ROUTE_ASSOC의 외래 키가 삭제되었다가 다시 추가됩니다. 이 외래 키는 업그레이드 결함이 있는 일부 이전 2.1.x 빌드를 통과하는 업그레이드 경로가 있는 일부 Orchestrator에 아직 존재하지 않으며 BGP 경로를 학습하던 게이트웨이가 Orchestrator에서 삭제되었습니다. 이러한 Orchestrator에서는 테이블에 이미 레코드를 위반하는 외래 키가 있는 경우 4.2.x > 4.3.x+ 업그레이드에 대한 외래 키 추가가 실패합니다.
이 문제에 대한 수정 사항은 레코드를 위반하는 외래 키를 삭제한 다음, 외래 키를 다시 추가하여 근본 원인을 수정합니다.
이 문제에 대한 수정 사항 없이 Orchestrator로 업그레이드하는 경우 해결 방법은 MySQL의 VeloCloud 스키마에서 다음 쿼리를 실행하는 것입니다. DELETE FROM VELOCLOUD_LEARNED_PARTNER_ROUTE_ASSOC WHERE gatewayId not in (select id from VELOCLOUD_GATEWAY) 후 장기 실행 스키마 업데이트를 다시 트리거합니다.
해결된 문제 112201: 사용자가 API를 통해 CSS(클라우드 보안 서비스)를 구성하고 CSS를 없음(비어 있음)으로 설정하는 경우 VMware Edge CSS 구성 아래에 VMware SASE Orchestrator가 구성을 표시하지 않지만 Edge의 데이터베이스 및 API 응답에서 CSS가 실행 중이고 작동합니다.
Orchestrator는 새 Orchestrator UI에서 특정 세그먼트와 관련된 CSS 개체를 확인하는 데 사용된 세그먼트의 CSS 필드를 통해 CSS를 Edge 디바이스 설정 개체와 연결하지 않으며 참조 개체만 제공됩니다. 이 상태의 CSS는 비즈니스 정책의 일부로 사용할 수 없습니다.
이 문제에 대한 수정 사항을 적용하지 않은 Orchestrator에서는 고객이 API가 아닌 Orchestrator의 UI를 사용하여 새 CSS를 구성해야 합니다.
Orchestrator 빌드 R5013-20230310-GA는 2023년 3월 13일에 릴리스되었으며 릴리스 5.0.1에 대한 세 번째 Orchestrator 롤업입니다.
이 Orchestrator 롤업 빌드는 Orchestrator 빌드, R5012-20221214-GA 이후의 아래와 같은 중요한 문제를 해결합니다.
해결된 문제 105610: 사용자가 새 IPv4 개체 그룹을 생성하려고 시도하거나 '255'로 시작하고 '0'으로 끝나는 와일드카드 마스크(예: 255.0.1.0)를 포함하는 기존 IPv4 개체 그룹을 업데이트하려고 하면 VMware SASE Orchestrator는 이 와일드카드 마스크를 허용하지 않으며 유효한 와일드카드 표현식이므로 허용되어야 하는 경우에도 오류를 발생합니다.
5.0.x 이상부터 Orchestrator에서 개체 그룹의 와일드카드 마스크에 대한 유효성 검사가 수행되지 않으므로 사용자가 이에 대해 와일드카드 마스크를 구성하면 오류가 발생합니다.
해결된 문제 106242: VMware SASE Orchestrator의 [진단(Diagnostics)] > [원격 진단(Remote Diagnostics)] 페이지에 액세스하는 사용자가 Edge 진단을 수행하는 동안 [원격 진단(Remote Diagnostics)] 페이지에서 예기치 않게 로그아웃될 수 있습니다.
이 문제가 발생하면 Orchestrator가 가능한 연결 수 제한에 도달하고 Orchestrator가 원격 진단 사용자를 로그아웃하여 정상적인 작동을 보장하기 때문입니다. 이 문제는 데이터베이스 연결이 더 이상 필요하지 않게 될 경우 Orchestrator가 잘못해서 연결을 해제하지 않아 연결 제한 동작을 트리거하기 때문에 발생합니다.
해결된 문제 109595: 운영자가 VMware SASE Orchestrator를 4.x 버전에서 5.x 버전으로 업그레이드하려고 하면 업그레이드가 실패할 수 있습니다.
이 문제가 발생하면 운영자에게 다음 오류 메시지가 표시될 수 있습니다. 업그레이드 - 오류 - 반환 코드 1을 나타내며 설치 관리자 실패. 이 문제는 Orchestrator의 Docker 소프트웨어가 5.x 빌드로 업그레이드할 때 필요한 폴더를 생성하지 않기 때문에 발생합니다.
Orchestrator 빌드 R5012-20221214-GA는 2022년 12월 14일에 릴리스되었으며 두 번째 릴리스 5.0.1용 Orchestrator 롤업입니다.
이 Orchestrator 롤업 빌드는 Orchestrator 빌드, R5011-20221129-GA 이후의 아래와 같은 중요한 문제를 해결합니다.
해결된 문제 96538: 원격 진단 [BGP 인접 항목 학습 경로 표시(Show BGP Neighbor Learned Routes)]가 실패합니다.
기본 API 호출의 상호 운용성 문제로 인해 [BGP 인접 항목 학습 경로 표시(Show BGP Neighbor Learned Routes)] 원격 진단을 실행할 때 유효성 검사 오류가 발생합니다.
해결된 문제 100133: Orchestrator의 각 [Edge로 푸시(Push to Edge)] 구성에서 성능 문제가 발생합니다.
고객이 Edge 클러스터를 연결하여 매우 많은 수의 비즈니스 정책 규칙을 구성하는 경우 Orchestrator의 각 [Edge로 푸시(Push to Edge)] 구성에서 성능 문제가 발생합니다.
해결된 문제 101835: 사용자가 클라우드 VPN이 구성된 비글로벌 세그먼트를 선택하는 경우 새 Orchestrator UI에서 [클라우드 VPN(Cloud VPN)] 섹션을 사용할 수 없습니다.
새 Orchestrator UI의 구성(Configure) > Edge > 디바이스(Device) 설정 페이지에서 [클라우드 VPN(Cloud VPN)]이 구성된 비글로벌 세그먼트를 선택하는 경우 [클라우드 VPN(Cloud VPN)] 섹션을 사용할 수 없습니다.
해결된 문제 102806: 고객은 게이트웨이 수준에서 파트너 게이트웨이 전달 구성을 편집할 수 없습니다.
이 문제는 고객이 업그레이드 중에 파트너 게이트웨이 전달을 구성할 때 발생합니다.
Orchestrator 빌드 R5011-20221129-GA는 2022년 11월 29일에 릴리스되었으며 첫 번째 릴리스 5.0.1용 Orchestrator 롤업입니다.
Orchestrator 빌드 R5011-20221129-GA는 빌드 R5011-20221117-GA를 대체하고 Orchestrator를 R5011-20221117-GA 빌드로 업그레이드할 때 VMware 운영 팀에게 확인되는 업그레이드 문제를 해결되었습니다. 이 업그레이드 문제는 업그레이드 패키지 매니페스트의 버전 불일치로 인해 발생했으며 이 새 빌드에는 추가된 새 기능이 없습니다.
이 Orchestrator 롤업 빌드는 Orchestrator 빌드, R5010-20220912-GA 이후의 아래와 같은 중요한 문제를 해결합니다.
해결된 문제 80735: 사용자가 하나 이상의 VMware SD-WAN Edge에도 할당된 프로필의 구성을 변경하면 프로필 수준의 BGP 필터가 제거됩니다.
이전에 사용자가 BGP 필터의 세부 정보를 볼 수 있었던 위치의 VMware SASE Orchestrator UI에서 "오류: 잘못된 필터 참조"가 표시됩니다. BGP에 의존하는 고객 네트워킹에 미치는 영향은 중요하며 BGP 필터를 복원하는 유일한 방법은 필터를 수동으로 복원하는 것입니다.
해결된 문제 88957: 서브넷이 /30인 VLAN에 대한 사용자 구성이 구현되지 않았습니다.
사용자가 VLAN에 대해 /30 서브넷을 구성하고 적용하면 Orchestrator는 올바른 x.x.x.2와 비교할 때 x.x.x.1의 DCHP 시작 범위를 자동으로 설정합니다. 사용자가 DHCP 시작 범위를 다시 .2로 수동으로 변경하여 이 구성을 수동으로 재정의하더라도 구성이 로드될 때마다 Orchestrator는 다시 .1로 변경합니다.
해결된 문제 97713: 고객이 [모니터링(Monitor)] > [네트워크 서비스(Network Service)] > [Edge 클러스터(Edge Cluster)] 테이블을 확인하면 VMware SASE Orchestrator UI에서 Edge 클러스터 상태 통계 메트릭을 볼 수 없습니다.
이 문제는 클러스터 Edge가 해당 통계를 Orchestrator에 업로드하고 그동안 Orchestrator가 예상하지 못한 수치를 전송하기 때문에 발생합니다. Orchestrator는 상태 통계를 데이터베이스에 저장하는 대신, 모든 상태 통계를 삭제합니다.
해결된 문제 98086: IT 전문가, 고객 지원 또는 엔터프라이즈 역할이 있는 파트너 관리자는 VMware SASE Orchestrator UI에서 경로 통계를 볼 수 없습니다.
Orchestrator는 이러한 파트너 관리자 역할에 대한 권한을 제공하지 않으며 이러한 사용자는 경로 통계(Path Stats) 탭에서 그래프 또는 메트릭을 볼 수 없습니다.
해결된 문제 98357: 사용자가 기존 역할에 증분 허용 권한을 추가하려고 하면 오류를 나타내며 실패합니다.
사용자가 5.x Orchestrator에서 사용자 지정 패키지를 편집하여 [경로 통계 보기(View Path Stats)]와 같은 작업에 대해 허용 권한을 추가하려고 하면 Orchestrator에서 사용자 지정 패키지를 거부합니다.
이 문제는 API 유효성 검사기가 허용 권한만 처리하고 거부 권한을 처리하지 않기 때문에 발생합니다.
해결된 문제 98518: 사용자가 할당된 고객이 없는 게이트웨이 풀에서 VMware SD-WAN Gateway를 제거하면 파트너 게이트웨이를 사용하는 고객은 여러 게이트웨이에 대해서도 파트너 전달 구성이 제거된 것을 확인할 수 있습니다.
게이트웨이가 게이트웨이 풀에서 제거되면 Orchestrator는 전달을 확인하고 일부 전달이 사용 중인 경우에도 사용 중이 아닌 것으로 잘못 표시됩니다. 이로 인해 사용 중인 전달 구성이 없다고 잘못 이해되므로 Orchestrator가 해당 게이트웨이에 대한 전달 구성을 설정 해제했다가 재정의합니다.
해결된 문제 98654: VMware SASE Orchestrator가 릴리스 5.0.0.0 이상으로 업그레이드된 경우 VMware SD-WAN Edge가 [인증서 필요(CERTIFICATE REQUIRED)] 모드로 구성되면 Edge와 Orchestrator 간의 통신이 끊어지고 인증서 갱신 후 종료된 것으로 표시될 수 있습니다.
릴리스 Orchestrator 5.0.0.0에는 [인증서 필요(CERTIFICATE REQUIRED)]로 구성된 Edge에 대한 클라이언트 인증서의 확장된 키 사용을 확인하는 새로운 기능이 도입되었습니다. 이 확인 프로세스에는 올바른 인증서를 잘못된 것으로 잘못 처리하여 하트비트가 실패하게 하는 결함이 있습니다.
해결된 문제 99109: VMware SASE Orchestrator를 5.0.0 이상으로 업그레이드하면 기존 Zscaler 배포를 사용하는 고객 엔터프라이즈 사용자는 "클라우드 구독은 null일 수 없으며 클라우드 이름과 일치해야 합니다."라는 오류를 나타내며 Zscaler 설정을 변경할 수 없습니다.
Orchestrator 릴리스 5.0.0에는 Zscaler와 같은 새 클라우드 서비스를 구성하는 고객을 위한 새로운 클라우드 구독 구성(Configure Cloud Subscription) 프로세스가 도입되었습니다. 이 추가 메커니즘의 일부로 Orchestrator를 릴리스 5.0.0/5.0.1로 업그레이드하면 기존 배포가 Orchestrator에서 감지되고 클라우드 구독으로 자동으로 마이그레이션되어야 합니다. 그렇지만 이 문제에서는 이 현상이 발생하지 않고 고객 사용자는 기존 Zscaler 구성을 변경하기 위해 새 클라우드 구독 구성(Configure Cloud Subscription) 방법을 사용하여 Zscaler에 대한 각 Edge를 수동으로 구성해야 합니다.
해결된 문제 99247: 사용자가 CSS(클라우드 보안 서비스)를 사용하여 트래픽을 백홀하도록 비즈니스 정책을 구성한 Zscaler 유형 CSS를 사용하는 고객 엔터프라이즈의 경우 VMware SASE Orchestrator를 릴리스 5.0.0/5.0.1로 업그레이드하면 VMware SD-WAN Edge에서 CSS 구성을 더 이상 변경할 수 없다는 사실이 확인됩니다.
구성(Configure) > Edge > 디바이스 설정(Device Settings)을 확인하면 [클라우드 구독(Cloud Subscription)]이 잠기고 [없음(None)]이 선택됩니다. 구성 변경을 시도하면 "클라우드 구독은 없음일 수 없습니다."라는 오류를 나타냅니다. 또한 백홀 비즈니스 정책을 먼저 감지하지 않으면 클라우드 구독을 선택할 수 없습니다.
해결된 문제 99250: VMware SASE Orchestrator에서 VMware SD-WAN Edge의 CPU 코어 온도가 그래프에 올바르게 표시되지 않습니다.
모니터링(Monitor) > Edge > 시스템(System) 탭을 살펴보면 CPU 코어 온도(CPU Core Temperature)가 항상 0으로 표시됩니다.
Edge가 Orchestrator에 올바른 CPU 코어 온도를 보고하지만 서식 문제로 인해 숫자가 삭제되며, 데이터가 없는 경우 Orchestrator에 기본값 0이 표시됩니다.
해결된 문제 100656: VMware SASE Orchestrator UI에서 [모니터링(Monitor)] > [Edge] > [QoE]로 이동하면 Edge의 QoE 그래프에서 큰 차이가 확인될 수 있습니다.
이 문제는 쿼리 기간 15분 동안 QoE 데이터가 감지되지 않을 때 VMware SASE Orchestrator의 백필 함수에서 오류가 발생하기 때문에 나타납니다.
해결된 문제 101449: 사용자가 릴리스 4.3.x 이상을 사용하여 VMware SD-WAN Edge에서 32개가 넘는 하위 인터페이스를 구성하는 경우 Orchestrator에서 오류를 발생시키며 구성이 적용되지 않게 됩니다.
이 제한은 Edge에서 4.3.x 미만(예: 4.2.2 또는 3.4.6)의 릴리스를 실행하고 있으며 32개가 넘는 하위 인터페이스가 지원되지 않는 고객 엔터프라이즈를 보호하도록 설계되었습니다. 이렇게 변경하면 Orchestrator에서 32개가 넘는 하위 인터페이스를 구성할 수 있으며 Edge가 릴리스 4.3.0 이상을 사용하는 경우에만 이 작업을 수행하라는 경고가 표시됩니다.
Orchestrator 버전 R-GA는 2022년 9월 13일에 릴리스되었으며 릴리스 5.0.1용으로 업데이트된 Orchestrator R5010-20220912-GA 빌드입니다.
업데이트된 R5010-20220912-GA Orchestrator 빌드는 Orchestrator 빌드 R5010-20220817 이후의 아래 문제를 해결합니다.
해결된 문제 96108: VMware SASE Orchestrator를 5.x 빌드로 업그레이드하면 UI의 [모니터링(Monitor)] > [Edge] 페이지를 볼 때 VMware SD-WAN Edge에 대한 메모리 사용량 통계가 누락될 수 있습니다.
이 문제는 Orchestrator가 현재 이름(memPct)을 사용하여 Edge의 이전 상태 통계 메모리 필드를 수신해야 하는 경우 이전 Edge가 상태 통계 메모리 필드(memoryPct)에 대해 다른 이름을 전송하여 5.x Orchestrator로 마이그레이션하는 동안 발생합니다. 그에 따라 Orchestrator는 예기치 않은 memPct 이름으로 제출된 Edge 상태 통계 메모리 필드 값을 무시하고 Orchestrator는 상태 통계 메모리 필드 값을 기본값인 0으로 사용합니다.
이 문제에 대한 수정 사항은 Orchestrator UI에서 Edge 상태 통계 누락의 다른 원인을 해결하며, 첫 번째 원인은 기존 5.0.1 GA 빌드의 #90749에서 해결되었습니다.
해결된 문제 96095: VMware SASE Orchestrator가 DR(재해 복구)에 대해 구성되면 모든 운영자 프로필에서 IPv6 Orchestrator IP 주소가 지워지고 IPv6 전용 SD-WAN Edge가 Orchestrator에 의해 종료된 것으로 표시됩니다.
운영자 프로필이 IPv4 및 IPv6 유형 모두에 대한 Orchestrator IP 주소로 구성되었지만 IPv4 주소만 사용하여 DR을 설정하는 경우 IPv6 주소가 Orchestrator의 [운영자 프로필(Operator Profile)]에서 제거됩니다. 이로 인해 IPv6 전용 Edge가 Orchestrator와의 통신을 중지하여 해당 Edge를 종료된 것으로 표시하고 구성 변경 사항 푸시를 중지합니다.
수정 사항 없이 Orchestrator에서 이 문제가 발생하는 경우 사후 업그레이드를 수행하려면 DR을 끊고 관리 IP 주소를 복원하도록 다시 설정해야 합니다.
해결된 문제 95847: VMware SASE Orchestrator를 버전 5.0.1로 업그레이드하면 업그레이드를 수행하는 운영자가 스키마 업그레이드가 성공하지 않은 것을 확인할 수 있으며 수동으로 다시 실행해야 합니다.
Orchestrator를 새 ClickHouse 스키마가 있는 버전으로 업그레이드하면 백엔드에서 경합 조건이 발생할 가능성이 있으며 이전 스키마 버전이 업그레이드되기 전에 실행 중이 아니고 준비 상태가 됩니다. 따라서 운영자는 스키마 업그레이드를 수동으로 다시 실행해야 합니다.
Orchestrator 버전 R-GA는 2022년 8월 17일에 릴리스되었으며 릴리스 5.0.1용으로 업데이트된 Orchestrator R5010-20220817-GA 빌드입니다.
이 Orchestrator 빌드는 문제 #95613이 포함된 원래 GA 빌드 R5010-20220803-GA를 대신합니다. 이 문제는 이 빌드가 2022년 8월 5일에 릴리스된 후 Orchestrator 업그레이드 중에 발견되었습니다. 고객은 R5010-20220817-GA 빌드만 사용해야 하며 R5010-20220803-GA를 사용하지 않아야 합니다.
해결된 문제 95613: VMware SASE Orchestrator가 R5010-20220803-GA 빌드로 업그레이드되면 해당 Orchestrator에 연결된 고객은 Edge를 모니터링하는 데 어려움을 겪을 수 있으며 API 호출을 사용하면 해당 호출이 실패합니다. 운영자 사용자는 API 프로세스가 실패하는 것을 확인할 수 있으며 Orchestrator에서 많은 CPU를 사용하면서 다시 시작해야 합니다.
이 문제는 시간 간격 차이 없이 API 호출을 수행하도록 엔터프라이즈를 구성할 경우(즉, 각 API 호출 직후에 다른 API 호출 수행) 트리거됩니다. 이 작업으로 인해 API 호출을 처리하는 v2 API 프로세스에서 예외가 발생하고 API 요청을 수신하지 못합니다. v2 API 프로세스가 실패한다는 것은 링크 통계(API 호출에 의존)와 같은 데이터에 대한 Edge 모니터링 시 정확한 데이터가 표시되지 않으며 API 호출을 사용하는 고객 엔터프라이즈에서도 실패가 확인됨을 의미합니다. 또한 동일한 엔터프라이즈가 시간 간격 차이 없이 API 호출을 계속하는 경우 v2 API 프로세스는 실제로 실패 주기에서 중단되며 해당 API 호출을 중지하거나 시간 간격을 포함하도록 수정할 때까지 다시 시작됩니다.
또한 v2 API 프로세스가 실패하고 다시 시작되면 Orchestrator CPU 사용량이 높아지고 API 호출 처리 외에 Orchestrator의 전반적인 성능에 영향을 줄 수 있습니다.
Orchestrator 버전 R5010-20220803-GA는 2022년 8월 5일에 릴리스되었으며 Orchestrator 버전 5002-20220517-GA 이후의 다음 문제를 해결합니다. 따라서 5.0.0 릴리스 정보에 나열된 모든 Edge 또는 게이트웨이 문제에 대한 수정 사항이 모든 릴리스 5.0.1 빌드에 포함되어 있습니다.
해결된 문제 49535: 모니터링(Monitor) > 네트워크 서비스(Network Services) 페이지에서 VMware SASE Orchestrator가 오프라인으로 전환된 VMware SD-WAN Edge의 BGP 인접 항목 상태를 즉시 업데이트하지 않습니다.
BGP Edge 인접 항목 상태(BGP Edge Neighbor State) 테이블에서 오프라인 Edge가 계속 "설정됨(Established)"으로 표시되고 Edge가 오프라인으로 전환된 후 몇 시간 동안 유지됩니다. 이러한 세부 정보를 확인하기 위해 Orchestrator UI를 사용하는 모든 사용자가 영향을 받습니다.
해결된 문제 68463: 품질에 대해 그래프 섹션이 노란색/양호로 나열된 VMware SASE Orchestrator의 모니터링(Monitor) > QoE 그래프를 살펴보면 클래식 UI와 새 UI를 확인할 때 그래프 섹션이 노란색/양호로 표시되는 이유 사이에서 차이가 있을 수 있습니다.
이 문제가 발생할 경우 클래식 UI에서 팝업 상자에 지연 시간(Latency)이 적정 QoE 점수의 원인으로 나열되는 경우, 새 UI에서는 지터(Jitter)를 적정 QoE 점수의 원인으로 나열하는 팝업 상자가 있습니다. 이 문제는 새 UI에서 지연 시간(Latency) 및 지터(Jitter) 값의 매핑이 잘못되어 발생합니다.
해결된 문제 70005: VMware Cloud Web Security를 사용하는 경우 사용자는 VMware SASE Orchestrator에서 기존 보안 정책을 편집하고 빈 이름으로 바꾼 후 저장할 수 있습니다.
사용자는 빈 이름으로 보안 정책을 생성할 수 없지만 기존 정책을 편집하여 이름을 비워 두도록 구성할 수 있으며 Orchestrator는 변경을 허용하고 오류를 발생시키지 않습니다.
해결된 문제 76036: VMware SASE Orchestrator에서 해당 파트너에 대한 [파트너 개요(Partner Overview)] 페이지 및/또는 [구성(Configure) > 고객(Customer)] 페이지에 액세스하려고 하면 "예기치 않은 오류가 발생함" 메시지가 표시되면서 로드되지 않습니다.
enterpriseProxy /getEnterpriseProxyGatewayPools API 시간이 초과되므로 해당 파트너가 지원하는 고객에 대해 파트너 개요(Partner Overview) 페이지 및/또는 구성(Configure) > 고객(Customer) 페이지가 로드되지 않을 수 있습니다. 이러한 페이지가 로드되지 않도록 하는 트리거는 많은 수의 게이트웨이 풀과 게이트웨이가 포함되어 있는 것입니다. 이 경우 페이지에 사용되는 enterpriseProxy /getEnterpriseProxyGatewayPools API가 시간 초과되어 각 UI 페이지에 대한 페이지 로드 문제가 발생할 수 있습니다.
해결된 문제 76036: VMware SASE Orchestrator에서 해당 파트너에 대한 [파트너 개요(Partner Overview)] 페이지 및/또는 [구성(Configure) > 고객(Customer)] 페이지에 액세스하려고 하면 "예기치 않은 오류가 발생함" 메시지가 표시되면서 로드되지 않습니다.
enterpriseProxy /getEnterpriseProxyGatewayPools API 시간이 초과되므로 해당 파트너가 지원하는 고객에 대해 파트너 개요(Partner Overview) 페이지 및/또는 구성(Configure) > 고객(Customer) 페이지가 로드되지 않을 수 있습니다. 이러한 페이지가 로드되지 않도록 하는 트리거는 많은 수의 게이트웨이 풀과 게이트웨이가 포함되어 있는 것입니다. 이 경우 페이지에 사용되는 enterpriseProxy /getEnterpriseProxyGatewayPools API가 시간 초과되어 각 UI 페이지에 대한 페이지 로드 문제가 발생할 수 있습니다.
해결된 문제 81835: VMware SASE Orchestrator UI의 모니터링(Monitor) > Edge > QoE 페이지에서 WAN 링크의 상태(온라인, 오프라인 또는 성능 저하됨)를 정확하게 나타내거나 선택한 기간에 대한 링크 메트릭을 정확하게 나타내지 않을 수 있습니다.
시간 간격이 다르면 QoE 그래프가 WAN 링크 상태에 대해 다른 결과를 표시할 수 있습니다. 또한 링크 메트릭의 경우 QoE 그래프는 정확한 시간에 실제 메트릭 값을 반영하지 않는 특정 QoE 값(지연 시간, 손실 또는 지터)을 표시할 수 있습니다.
이 문제는 다른 엔터프라이즈에 속하는 여러 WAN 링크에 동일한 링크 논리적 ID가 할당되어 Orchestrator의 링크 데이터 백필 프로세스가 잘못 작동하기 때문에 발생합니다. Orchestrator는 WAN 링크 논리적 ID가 고객의 엔터프라이즈 ID에 연결되지 않았기 때문에 고유하다고 잘못 가정합니다. 이로 인해 중복된 링크 논리적 ID와 잘못된 링크 메트릭 및 상태가 발생할 수 있습니다.
이 문제에 대한 수정 사항은 고객 엔터프라이즈 논리적 ID 및 WAN 링크의 논리적 ID를 조합한 링크 키를 Orchestrator의 데이터베이스에 저장하여 각 WAN 링크가 고유한지 확인합니다.
해결된 문제 82725: VMware SASE Orchestrator가 암호 재설정 링크를 올바르게 생성하지 못할 수 있습니다.
이 문제는 Orchestrator의 URL이 정확히 https://domain/ 또는 https://domain/operator/가 아닐 때 발생합니다. 하지만 예를 들어 URL이 https://domain/test/인 경우 암호 재설정 링크가 작동하지 않고 로그인 페이지로 다시 이동됩니다.
수정 사항이 적용되지 않은 Orchestrator에서 문제가 발생하는 경우 Orchestrator URL을 위에 표시된 URL로 수정할 수 없는 경우 수퍼유저 또는 운영자가 사용자의 새 암호를 수동으로 입력한 다음, 영향을 받는 사용자와 공유합니다. 이러한 사용자가 다시 로그인한 후에 다른 암호를 재구성할 수 있도록 하는 것이 유일한 옵션입니다.
해결된 문제 82775: 릴리스 5.0.0을 사용하는 VMware SASE Orchestrator에서 Zscaler 유형 CSS(클라우드 보안 서비스)가 고객에 대해 구성되고 VMware SD-WAN Edge와 연결된 다음, 비즈니스 정책이 CSS 백홀 규칙으로 구성된 경우 사용자는 해당 CSS에 대한 CSS 해시 또는 암호화 매개 변수를 변경할 수 없습니다.
Orchestrator는 사용자가 CSS 백홀 비즈니스 정책과 연결되면 Zscaler CSS 구성을 수정하지 못하도록 잠급니다.
이 문제가 수정되지 않은 Orchestrator에서 사용자는 CSS 백홀 비즈니스 정책을 삭제하여 Zscaler CSS 구성을 수정한 다음, 동일한 비즈니스 정책을 다시 생성해야 합니다.
해결된 문제 82864: 릴리스 5.0.0을 사용하는 VMware SASE Orchestrator에서 구성(Configure) > 프로필(Profiles) 페이지에 있고 수정(Modify)을 선택하면 사용자가 프로필(Profile) > 디바이스 설정(Device Settings) 페이지 대신, 프로필(Profile) > 개요(Overview) 페이지로 리디렉션됩니다.
구성(Configure) > 프로필(Profiles)에서 [수정(Modify)] 버튼이 올바른 페이지에 매핑되지 않습니다.
해결된 문제 83165: 운영자 사용자는 고객과 파트너에게 동일한 게이트웨이 풀이 있더라도 동일한 게이트웨이 풀이 없다는 이유로 VMware SASE Orchestrator에서 고객을 의 파트너로 전송할 수 없습니다.
이 문제는 API 호출 network/getNetworkEnterpriseProxies가 게이트웨이 풀 세부 정보를 반환하지 않고, Orchestrator가 파트너 및 고객에게 동일한 게이트웨이 풀이 없다고 판단하도록 하고 할당을 거부하기 때문에 발생합니다.
해결된 문제 83538: Secure Access 서비스를 사용하는 고객의 경우 원격 액세스 서비스를 생성할 때 VMware SASE Orchestrator의 엔터프라이즈 및 네트워크 설정(Enterprise & Network Settings) 화면에 내부 오류 메시지 키가 표시됩니다.
원격 액세스 서비스를 생성할 때 사용자가 고객 서브넷 또는 서브넷 비트 필드에 잘못된 데이터를 입력하는 경우 이러한 필드 아래에 번역되지 않은 오류 메시지가 표시되지 않습니다. 이 오류 메시지는 사용자에게 유용하지 않으며 이러한 필드의 잘못된 데이터와 관련된 실제 문제 해결을 나타내지 않습니다.
해결된 문제 83539: DR(재해 복구) 구성으로 배포된 VMware SASE Orchestrator에서 Orchestrator를 새 소프트웨어 버전으로 업그레이드하면 DR 동기화가 실패합니다.
업그레이드 전에 DR이 제대로 실행되고 있지만 운영자 사용자가 활성 및 대기 Orchestrator를 업그레이드하면 DR 상태가 실패로 표시됩니다.
해결된 문제 83582: VMware SASE Orchestrator를 릴리스 4.5.0에서 릴리스 5.0.0으로 업그레이드할 때 프로세스가 예상보다 오래 걸리고 프로세스가 완료될 때까지 모든 Orchestrator 서비스를 사용할 수 없습니다.
LRQ 스키마를 대신 업데이트해야 하는 경우 업그레이드 도중 Edge 통계 테이블이 업데이트되는 스키마 업데이트가 15분 넘게 걸릴 수 있으며 이로 인해 Orchestrator 업데이트 완료까지 상당한 지연이 발생합니다.
해결된 문제 83822: VMware Cloud Web Security를 사용하는 고객의 경우 VMware SASE Orchestrator의 모니터링(Monitor) > 로그(Logs) > 웹 로그(Web Logs)에서 사용자는 최대 100개의 로그만 볼 수 있으며, 추가 로그를 보기 위해 더 많은 페이지를 로드할 수 없습니다.
이 문제로 인해 사용자는 단일 페이지에서 최대 100개의 로그만 볼 수 있으며 Orchestrator UI의 웹 로그(Web Logs)에 대해 페이지 매기기가 중단되어 추가 로그를 볼 수 없습니다. 이는 사용자가 긴 기간(예: 30일)을 로드하려는 경우 해당 기간에 대한 모든 로그를 볼 수 없기 때문에 사용자에게 큰 방해가 됩니다. 유일한 해결 방법은 100개 이하의 로그를 반환하도록 짧은 기간을 로드하는 것입니다.
해결된 문제 84152: 고객이 엔터프라이즈에 대한 상위 토커 보고서를 생성하면 상위 토커 이름이 '알 수 없음(Unknown)'으로 표시될 수 있습니다.
"상위 토커"는 지정된 시간 범위의 모든 흐름에서 제공되는 상위 소스입니다. (소스 IP + MAC 주소) 고유 쌍에 대해 클라이언트 디바이스가 없는 경우 상위 토커 이름이 표시되지 않을 수 있습니다. 이 문제는 클라이언트 디바이스가 VMware SD-WAN Edge에 대해 구성된 가시성 모드(IP 주소 또는 MAC 주소)를 기준으로 저장되기 때문에 발생합니다. 예를 들어 Orchestrator는 (IP 주소 1, MAC 주소 1)에 대한 디바이스를 저장한 다음, 가시성 모드가 IP 주소로 설정된 경우 (IP 주소 2, MAC 주소 2) 레코드가 저장되지 않을 수 있습니다. 이로 인해 IP 주소 2/MAC 주소2에 해당하는 상위 토커가 '알 수 없음(Unknown)'으로 표시됩니다.
해결된 문제 84214: 운영자 사용자가 VMware SASE Orchestrator UI의 게이트웨이 페이지에 있는 경우 슈퍼 게이트웨이 역할에 대해 특정 게이트웨이를 할당하지 못할 수 있습니다.
게이트웨이에 이미 슈퍼 및 대체 슈퍼 게이트웨이의 역할이 모두 할당되어 있고, 운영자가 게이트웨이(Gateways) > 게이트웨이 구성(Configure Gateways) 화면의 고객 사용량 목록에서 엔터프라이즈의 슈퍼 게이트웨이 할당을 편집하려고 하면 UI가 슈퍼 게이트웨이에 대한 연결된 데이터를 올바르게 찾지 못하고 콘솔에서 오류가 발생하면서 슈퍼 게이트웨이 할당 대화 상자가 표시되지 않습니다.
해결된 문제 84969: 재정의된 비기본 관리 IP로 구성된 4.2.x 릴리스를 실행하는 VMware SD-WAN Edge가 4.3.x 이상을 실행하는 VMware SD-WAN Orchestrator에서 릴리스 4.3.x 이상으로 업그레이드되면 Edge에서 구성된 재정의된 관리 IP가 손실될 수 있습니다.
4.3.x 이상을 실행하는 Orchestrator는 Edge가 4.2.x에서 4.3.x 이상 빌드로 업그레이드될 때 Edge에 대해 재정의된 비기본 관리 IP를 유지하면서 루프백 인터페이스를 자동으로 생성하지 않습니다.
해결된 문제 86546: VMware Secure Access를 사용하는 고객의 경우 일부 SASE PoP에서 Secure Access를 사용하지 못할 수 있으며, 일부 PoP는 VMware SASE Orchestrator에서 오프라인으로 표시될 수도 있습니다.
Secure Access 사용이 구성되지 않은 VMware 게이트웨이(즉, PoP의 터널 서버와 Geneve 터널이 없는 게이트웨이)도 Orchestrator에서 Secure Access 서비스에 대한 정보를 제공합니다. 이로 인해 고객 트래픽 라우팅을 위해 일부 인스턴스에서 경로가 끊어집니다. 이 문제는 특정 Orchestrator의 게이트웨이 풀당 PoP에 둘 이상의 게이트웨이가 할당된 경우에만 발생할 수 있습니다.
이 문제에 대한 수정 사항이 없는 Orchestrator에서 해결 방법은 각 게이트웨이 풀에 PoP당 하나의 게이트웨이만 추가하고 유지하여 이 게이트웨이가 항상 Secure Access 및 올바른 경로 설정에 대해 선택되도록 하는 것입니다.
해결된 문제 86848: 고객 관리자가 네이티브(사용자 이름/암호) 방법을 사용하여 VMware SASE Orchestrator의 고객 엔터프라이즈에 로그인하지 못한 경우 Orchestrator는 Ui의 모니터링(Monitor) > 이벤트(Events) 페이지에 실패한 시도를 로그하지 않습니다.
Orchestrator는 모든 사용자 계정에 대한 적절한 책임을 보장하고 모든 관리자가 비정상적인 로그인 활동을 감지할 수 있도록 성공 여부와 관계없이 모든 로그인 시도를 로그해야 합니다. 이 문제는 실패한 사용자 이름/암호 인증 시도에 대해 enterpriseId 메타데이터를 포함하지 않은 Orchestrator로 인해 발생합니다. 네이티브(사용자 이름/암호) 인증을 사용하는 고객 사용자에게만 영향을 미치며 SSO(Single Sign On)를 사용하는 고객 엔터프라이즈는 이 문제의 영향을 받지 않습니다.
해결된 문제 87111: VMware SASE Orchestrator가 4.3.x 이상으로 업그레이드되면 BGP를 사용하도록 구성된 Orchestrator에 연결된 VMware SD-WAN Edge에 업링크 플래그가 구성되지 않습니다.
BGP 업링크 플래그가 SD-WAN 4.3.0 릴리스 및 Edge 버전 4.3.0 이상에서 구성으로 추가되고 업링크 플래그가 존재할 것으로 예상됩니다. 하지만 Orchestrator가 업그레이드된 후 Orchestrator가 이 플래그가 누락된 모든 Edge에 구성 업데이트를 푸시하지는 않습니다.
해결된 문제 88621: 마이그레이션 중인 VMware SD-WAN Gateway가 해당 구성을 수정하고 VMware SASE Orchestrator에 저장할 수 없습니다.
운영자 사용자가 구성을 저장하려고 할 때 Orchestrator에서 다음 오류를 반환하고 프로덕션 게이트웨이 위치를 업데이트할 수 없습니다. GATEWAY_SERVICE_STATE_INVALID: Cannot change the state of the gateway to null, as it is already used as a replacement gateway.
해결된 문제 89346: 빌드 5.0.0.2를 사용하는 VMware SASE Orchestrator의 [고객 모니터링(Monitor Customers)] 화면에서 새로 생성된 보고서는 보고서 언어가 영어가 아닌 언어로 지정된 경우에도 항상 영어로 제공됩니다.
다운로드한 보고서는 보고서 언어(Report Language)로 지정된 언어로 표시되어야 하지만 대신 사용되는 언어는 항상 영어입니다.
해결된 문제 89800: 사용자가 VMware SASE Orchestrator에서 세그먼트 속성을 업데이트하면 Zscaler CSS(클라우드 보안 서비스)에 대한 Edge 터널이 종료되고 Zscaler로 라우팅되는 트래픽이 손실됩니다.
사용자가 구성(Configure) > 네트워크 서비스(모든 CSS 유형)(Network Service (any CSS type))에서 CSS를 구성한 다음 Edge 재정의를 사용하여 Configure(구성) > Edge > 디바이스(Device) > 클라우드 보안 서비스(Cloud Security Service)에서 FQDN 및 PSK 인증 세부 정보를 구성하는 경우, 사용자가 Orchestrator의 Configure(구성) > 세그먼트(Segment) 섹션에서 세그먼트를 업데이트하면 Edge의 CSS 인증 구성이 삭제되고 Edge를 더 이상 Zscaler 피어에 연결할 수 없습니다.
해결된 문제 90128: CSS(클라우드 보안 서비스)가 구성된 고객 엔터프라이즈에서 사용자가 CSS 구성을 변경하면 CSS 이벤트에 CSS의 PSK 키가 포함됩니다.
이 동작이 직접적인 취약성을 제공하지는 않지만 CSS PSK 값은 로그 파일에 포함되지 않아야 하는 중요한 정보입니다.
해결된 문제 90540: 릴리스 5.0.0을 사용하는 VMware SASE Orchestrator에서 Edge 릴리스 4.5.1을 사용하는 VMware SD-WAN Edge를 릴리스 5.0.0으로 업그레이드하면 Edge의 DNS 기능이 손실되고 인터넷 연결이 끊어질 수 있습니다.
Edge를 5.0.0으로 업그레이드하는 과정 동안 Orchestrator의 역할은 업데이트된 Edge 구성을 푸시하는 것이며, 해당 구성의 DNS 부분이 4.5.x Edge 빌드와 호환되지 않아 DNS 설정이 손실되고 인터넷에 대한 연결이 차단됩니다. Edge는 DNS가 요인이 아닌 다른 위치(예: Orchestrator, 기타 Edge, 허브 Edge 및 비 SD-WAN 대상)로 트래픽을 계속 전달합니다.
해결된 문제 90067: VMware SASE Orchestrator를 4.5.1 또는 5.0.0으로 업그레이드하면 운영자에게 높은 CPU 사용량 및 로드 문제가 발생할 수 있습니다.
업그레이드하는 동안 Orchestrator의 중요한 시스템 속성인 edge.learnedRoute.maxRoutePerCall이 손실됩니다. 이 속성은 Orchestrator에서 한 번에 수신할 수 있는 라우팅 프로토콜 이벤트 수를 제한합니다. 이 속성이 없으면 라우팅 프로토콜 이벤트로 Orchestrator가 플러딩되어 Orchestrator가 높은 로드 상태가 되며 Orchestrator의 성능에 영향을 미칠 수 있습니다. 이 버그 수정 사항은 Orchestrator 업그레이드가 수행되어도 시스템 속성 edge.learnedRoute.maxRoutePerCall이 유지됩니다.
해결된 문제 90749: VMware SASE Orchestrator를 5.x 빌드로 업그레이드하면 UI의 [모니터링(Monitor)] > [Edge] 페이지를 볼 때 하나 이상의 VMware SD-WAN Edge에 대한 기록 통계가 누락될 수 있습니다.
Orchestrator가 5.x 빌드로 업그레이드된 이후 Orchestrator 로그에서 운영자에게 "상태 통계 마이그레이션 도중 오류(Error while migrating health stats)" 및 "ClickHouse로 데이터 파일을 쓰는 도중 오류(Error while writing data file to clickhouse)" 로그 메시지와 타임스탬프가 표시됩니다. 이 문제는 Orchestrator 업그레이드 중에 Edge가 잘못된 데이터(예: 음수의 잘못된 터널 수)를 Orchestrator에 전송하여 Orchestrator가 잘못된 데이터뿐만 아니라 해당 특정 Edge에 대한 전체 기록 데이터 일괄 처리 전체를 거부하게 되면서 발생합니다. 그에 따라 Orchestrator 업그레이드 후 모니터링(Monitor) > Edge 페이지를 볼 때 해당 Edge에 대한 그래프에서 큰 시간 차이가 확인됩니다. 이 문제는 Orchestrator에 연결된 모든 Edge에 균일하게 영향을 미치지 않으며, 잘못된 데이터를 전송하는 소수에만 영향을 미칩니다.
Orchestrator 빌드 R5010-20220912-GA에서 수정된 Edge 상태 통계 누락을 야기하는 관련 문제 #96108이 있습니다.
해결된 문제 90835: VMware Cloud Web Security 서비스를 사용하는 고객의 경우 사용자는 VMware SASE Orchestrator를 사용하는 Cloud Web Security에서 웹 프록시에 대한 Office 365 도메인 규칙을 구성할 수 없습니다.
사용자가 PAC 파일 마법사를 사용하여 Cloud Web Security에서 웹 프록시에 대한 Office 365(최근에 Microsoft 365로 이름이 변경됨) 도메인 규칙을 구성할 수 없습니다.
해결된 문제 91054: VMware Cloud Web Security를 사용하는 고객의 경우 Single Sign-On 인증을 구성하려고 하면 VMware SASE Orchestrator UI에서 여러 가지 사용 편의성 문제가 발생할 수 있습니다.
Cloud Web Security 서비스에서 Single Sing-On을 구성하는 동안 발생할 수 있는 문제는 다음과 같습니다.
• [인증서(Certificate)] 페이지 대신 기본 [인증(Authentication)] 페이지에 인증서 오류가 표시됩니다. 사용자가 경우에 따라 잘못된 인증서를 저장할 수 있습니다.• 인증서를 변경하면 인증 양식에서 다른 값이 재설정되는 경우가 있습니다.• 개별 필드에 유효성 검사 메시지가 필드와 인라인으로 표시되지 않습니다.• [인증(Authentication)] 페이지를 저장할 때 Orchestrator UI에 진행률 회전자가 표시되지 않습니다.• [상세 디버깅(Verbose Debugging)] 도구 설명에 실제 시간 대신 "t+2시간"이 표시됩니다.• 일부 언어에서는 Single Sign-On 토글 레이블이 둘 이상의 줄로 표시됩니다.• 짧은 화면에서 변경 내용 저장(Save Changes) 바닥글 레이아웃이 올바르지 않습니다.
나열된 모든 문제는 #91054에 대한 수정 사항이 포함된 Orchestrator에서 해결되었습니다.
해결된 문제 91179: WAN 링크가 핫 대기(Hot Standby)로 구성된 VMware SD-WAN Edge의 경우 핫 대기 링크의 상태가 대기일 때 VMware SASE Orchestrator의 새 UI에서 핫 대기 링크(활성)에 대한 잘못된 상태를 표시합니다.
Orchestrator의 클래식 UI에서 링크에 대한 올바른 상태(유휴)가 표시되므로 이는 새 UI에만 국한됩니다. 이 문제는 새 UI가 핫 대기 WAN 링크의 상태 변경에 대한 올바른 업데이트를 받지 못하기 때문에 발생합니다.
해결된 문제 91720: 허브/스포크 토폴로지를 사용하는 고객 엔터프라이즈의 경우 인터넷 백홀을 사용하도록 구성된 비즈니스 정책에 따라 허브를 사용하고 있더라도 사용자는 백홀 허브 구성에서 VMware SD-WAN Hub Edge를 제거할 수 있습니다.
허브 Edge를 통해 스포크 Edge 트래픽을 백홀하기 위한 비즈니스 정책이 구성되면 예상되는 동작은 VMware SASE Orchestrator가 해당 허브 Edge를 "잠그고" 사용자가 구성(Configure) > 디바이스 설정(Device Settings)의 백홀 허브 구성에서 해당 허브 Edge를 제거하지 못하게 하는 것입니다. 그러나 이 문제로 인해 사용자는 허브 Edge를 제거하고 상당한 고객 트래픽 중단을 유발할 수 있습니다.
해결된 문제 92082: VMware Cloud Web Security를 사용하는 고객의 경우 컨텐츠 필터링 규칙이 구성된 도메인을 준수하지 않는 것을 확인할 수 있습니다.
컨텐츠 필터링 규칙은 사용자가 범주에 대해서도 [모두(ALL)]를 선택한 경우 제공된 구성된 도메인을 재정의합니다. 또는 사용자가 범주에 대해 [없음(NONE)]을 선택하는 경우 마법사는 기본적으로 이 선택 항목이 모든 범주를 의미하는 것으로 인식하므로 도메인도 적용되지 않습니다. 이 문제는 컨텐츠 필터링 마법사 및 API의 문제로 인해 발생합니다. 사용자가 하나 이상의 범주를 구성하는 경우 도메인이 적용됩니다.
이 수정 사항이 없는 Orchestrator에서 사용자는 도메인과 함께 특정 범주를 구성해야 합니다. 그러면 Orchestrator는 컨텐츠 필터링에서 도메인을 적용합니다.
릴리스 5.0.1의 미해결 문제.
문제 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)" 상태가 잘못 표시될 수 있습니다.
해결 방법:원격 진단(Remote Diagnostics) > 인터페이스 상태(Interface Status)에서 Orchestrator UI를 참조하십시오.
문제 32981:
DPDK로 구성된 포트에서 하드 코딩 속도 및 전이중을 사용하려면 DPDK를 해제해야 하므로 구성을 적용하려면 VMware SD-WAN Edge를 재부팅해야 할 수 있습니다.
문제 34254:
Zscaler CSS가 생성되고 글로벌 세그먼트에 FQDN/PSK 설정이 구성되어 있으면 이러한 설정이 비 글로벌 세그먼트에 복사되어 Zscaler CSS에 대한 IPsec 터널이 형성됩니다.
문제 35778:
단일 인터페이스에 여러 사용자 정의 WAN 링크가 있는 경우 해당 WAN 링크 중 하나에만 Zscaler에 대한 GRE 터널이 유지될 수 있습니다.
해결 방법: Zscaler에 대한 GRE 터널을 구축해야 하는 각 WAN 링크에 대해 다른 인터페이스를 사용합니다.
문제 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 작업이 실패할 수 있습니다.
문제 39753:
동적 분기 간 VPN을 해제하면 동적 분기 간 VPN을 사용하여 현재 전송 중인 기존 흐름이 중단될 수 있습니다.
해결 방법: 유지 보수 기간에만 동적 분기 간 VPN을 비활성화합니다.
문제 40421:
인터페이스가 전환된 포트로 구성된 VMware SD-WAN Edge를 통과하는 경우 Traceroute에 해당 경로가 표시되지 않습니다.
문제 40096:
활성화된 VMware SD-WAN Edge 840을 다시 부팅하면 링크 표시등이 켜지고 VMware SD-WAN Orchestrator가 포트를 '실행 중(Up)'으로 표시하더라도 Edge에 연결된 SFP 모듈이 트래픽 전달을 중지하게 될 수 있습니다.
해결 방법: 포트에서 SFP 모듈을 뽑았다가 다시 꽂습니다.
문제 42278:
특정 유형의 피어 구성 오류가 있을 때 VMware SD-WAN Gateway가 계속해서 비 SD-WAN 피어에 IKE 초기화 메시지를 보낼 수 있습니다. 이 문제로 인해 게이트웨이에 대한 사용자 트래픽이 중단되지는 않습니다. 그러나 게이트웨이 로그가 IKE 오류로 채워질 수 있으며, 이로 인해 유용한 로그 항목이 모호해질 수 있습니다.
문제 42388:
VMware SD-WAN Edge 540에서 VMware SD-WAN Orchestrator의 인터페이스를 비활성화했다가 다시 활성화한 후에 SFP 포트가 감지되지 않습니다.
문제 42872:
허브 클러스터가 연결된 허브 프로필에서 프로필 분리를 활성화하면 RIB(라우팅 정보 기반)의 허브 경로가 해지되지 않습니다.
문제 43373:
여러 VMware SD-WAN Edge에서 동일한 BGP 경로를 학습한 경우 오버레이 흐름 제어에서 이 경로가 기본 설정에서 적격 종료로 전환되면 Edge는 애드버타이즈 목록에서 제거되지 않고 계속 애드버타이즈됩니다.
해결 방법: VMware SD-WAN Orchestrator에서 분산 비용 계산(DCC)을 활성화합니다.
문제 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 암호화로 터널을 시작하지 않습니다.
해결 방법: 고객이 AES-256을 사용하는 경우에는 Edge를 4.x 릴리스로 업그레이드하기 전에 Orchestrator에서 명시적으로 GCM 사용 안 함으로 설정해야 합니다. 모든 Edge가 4.x 릴리스를 실행하면 고객이 AES-256-GCM 및 AES-256-CBC 중에서 선택할 수 있습니다.
문제 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에서 사용할 수 있습니다.
문제 47664:
허브 VPN을 통한 분기 간 방식이 구성되지 않은 허브 및 스포크 구성에서 L3 스위치/라우터의 요약 경로를 사용하여 분기 간 트래픽을 유턴하려고 하면 라우팅 루프가 발생합니다.
해결 방법: 분기 간 VPN을 활성화하도록 클라우드 VPN을 구성하고 "VPN에 허브 사용"을 선택합니다.
문제 47681:
VMware SD-WAN Edge의 LAN 측 호스트가 Edge의 WAN 인터페이스와 동일한 IP를 사용하는 경우 LAN 호스트에서 WAN으로의 연결이 작동하지 않습니다.
문제 48530:
VMware SD-WAN Edge 6x0 모델은 삼중 속도(10/100/1000Mbps) Copper SFP의 자동 협상을 수행하지 않습니다.
해결 방법: Edge 520/540은 삼중 속도 Copper SFP를 지원하지만 이 모델은 2021년 1사분기까지 판매 종료되는 것으로 표시되었습니다.
문제 48597: 피어에 대한 두 경로 중 하나가 종료된 경우 멀티 홉 BGP 인접 관계가 유지되지 않습니다.
여러 경로가 있고 경로 중 하나가 종료된 피어에 대해 멀티 홉 BGP 인접 관계가 있는 경우 해당 BGP 인접 관계가 종료되고 사용 가능한 다른 경로를 사용해도 실행되지 않는다는 알림이 표시됩니다. 여기에는 로컬 IP-루프백 인접 관계 사례도 포함됩니다.
해결 방법: 이 문제에 대한 해결 방법은 없습니다.
문제 50518:
PKI가 구성된 VMware SD-WAN Gateway에서 6,000개보다 많은 PKI 터널이 게이트웨이에 연결하려고 하면 인바운드 SA가 삭제되지 않기 때문에 터널이 모두 표시되지는 않을 수 있습니다.
참고: PSK(사전 공유 키) 인증을 사용하는 터널에는 이 문제가 발생하지 않습니다.
문제 51436: LTE 모뎀을 사용하여 VMware SD-WAN Edge를 배포하는 동안 향상된 고가용성 토폴로지를 사용하는 사이트의 경우 사이트가 "분할 브레인" 상태가 되면 HA 페일오버에 5-6분 정도 소요됩니다.
분할 브레인 상태에서 복구하면서 LAN 포트는 활성 Edge에서 종료되며, 이러한 상황은 포트가 종료되고 사이트를 복구할 수 있게 될 때까지 LAN 트래픽에 영향을 미칩니다.
해결 방법: 이 문제에 대한 해결 방법은 없습니다.
문제 52955: 상태 저장 DHCP에서 DAD가 실패한 후 Edge에서 DHCP 거부가 전송되지 않고 DHCP 재바인딩이 다시 시작되지 않습니다.
DHCPv6 서버가 DAD 검사 중에 커널에서 중복된 것으로 감지되는 주소를 할당하는 경우 DHCPv6 클라이언트가 거부를 전송하지 않습니다. 이로 인해 인터페이스 주소가 DAD 검사 실패로 표시되어 사용되지 않으므로 트래픽이 삭제됩니다. 이 경우 네트워크에서 트래픽이 루핑되지 않으며 트래픽 블랙홀이 확인됩니다.
해결 방법: 이 문제에 대한 해결 방법은 없습니다.
문제 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 세션이 실패할 수 있습니다.
해결 방법: 이 문제에 대한 해결 방법은 없습니다.
문제 53934: VMware SD-WAN Hub 클러스터가 구성된 엔터프라이즈에서 기본 허브의 LAN 측에 멀티 홉 BGP 인접 관계가 있는 경우, LAN 측에 장애가 발생하거나 모든 세그먼트에서 BGP가 구성되지 않으면 고객이 스포크 Edge에서 트래픽이 삭제될 수 있습니다.
허브 클러스터에서 기본 허브는 피어 디바이스와의 멀티 홉 BGP 인접 관계가 있어서 경로를 학습할 수 있습니다. BGP 인접 관계가 설정된 허브의 물리적 인터페이스가 종료되면 BGP 보기가 비어 있더라도 BGP LAN 경로가 0이 되지 않을 수 있습니다. 이로 인해 허브 클러스터 재조정이 발생하지 않을 수 있습니다. 이 문제는 BGP가 모든 세그먼트에 대해 구성되지 않고 하나 이상의 멀티 홉 BGP 인접 관계가 있는 경우에도 발생할 수 있습니다.
해결 방법: LAN 측 장애(또는 BGP가 활성화되지 않음)가 있는 허브를 다시 시작하십시오.
문제 57210: VMware SD-WAN Edge가 정상적으로 작동하고 인터넷에 연결할 수 있는 경우에도 로컬 UI [개요(Overview)] 페이지의 LED가 "빨간색"으로 표시됩니다.
Edge의 로컬 UI는 Google의 DNS 확인자(8.8.8.8)를 통해 잘 알려진 이름을 확인할 수 있는지 여부를 통해 Edge의 연결을 확인합니다. 어떤 이유로든 이러한 사항을 확인할 수 없으면 오프라인 상태로 간주하고 LED를 빨간색으로 표시합니다.
해결 방법: 8.8.8.8로의 DNS 트래픽이 대상에 도달하여 성공적으로 확인될 수 있도록 하는 것을 제외하고 이 문제에 대한 해결 방법은 없습니다.
문제 61543: 동일한 내부 IP를 사용하는 서로 다른 인터페이스에 2개 이상의 1:1 NAT 규칙을 구성한 경우 하나의 인터페이스에서 인바운드 트래픽이 수신될 수 있으며 동일한 흐름의 아웃바운드 패킷을 다른 인터페이스를 통해 라우팅할 수 있습니다.
외부에서 내부로의 NAT 흐름에서는 1:1 NAT 규칙이 외부 IP 및 패킷이 수신되는 인터페이스와 일치하는지 확인됩니다. 동일한 흐름의 아웃바운드 패킷의 경우 VMware SD-WAN Edge가 내부 IP를 비교하여 NAT 규칙이 일치하는지 다시 확인하며, "아웃바운드 트래픽(Outbound Traffic)"을 구성한 첫 번째 일치 규칙에 구성된 인터페이스를 통해 아웃바운드 트래픽을 라우팅할 수 있습니다.
해결 방법: 이 문제는 특정 내부 IP 주소를 사용하여 1:1 NAT 규칙이 두 개 이상 구성되지 않도록 하는 것 외에 다른 해결 방법이 없습니다.
문제 62701: Edge 허브 클러스터의 일부로 배포된 VMware SD-WAN Edge의 경우 클라우드 VPN이 글로벌 세그먼트에서 활성화되지 않았지만 비 글로벌 세그먼트에서 활성화된 경우, Orchestrator에서 전송된 제어부 업데이트로 인해 허브 Edge에서 모든 WAN 링크가 플래핑될 수 있습니다.
허브 Edge의 WAN 링크가 종료된 후 빠르게 연속해서 실행(플래핑)되면 음성 통화와 같은 실시간 트래픽에 영향을 미칩니다. 이 문제는 허브 Edge의 글로벌 세그먼트에서 클라우드 VPN이 활성화되지 않은 고객 배포에서 발견되었지만 클러스터 구성이 활성화되었고, 이는 허브 Edge가 클러스터의 일부였음을 의미합니다(그리고 클러스터 구성은 모든 세그먼트에 적용 가능함). 구성 변경 내용이 허브 Edge로 푸시되면 허브 Edge의 데이터부가 데이터 구문 분석을 시작하고 글로벌 세그먼트가 시작되는데, 여기에서 클라우드 VPN이 활성화되지 않고 허브 Edge가 이 글로벌 세그먼트에서 클러스터링이 비활성화되었다고 잘못 생각합니다. 그 결과, 허브 Edge가 허브의 WAN 링크에서 모든 터널을 해체하여 모든 Edge의 WAN 링크에서 링크가 플래핑됩니다. 이러한 인시던트에 대해 WAN 링크는 종료된 후 제어 창 업데이트당 한 번만 복구됩니다.
해결 방법: 해결 방법은 모든 세그먼트(글로벌 세그먼트 및 모든 비글로벌 세그먼트)에서 클라우드 VPN을 활성화하는 것입니다.
문제 65560: 고객으로부터 PE(제공자 Edge) 디바이스로의 트래픽이 전송이 실패합니다.
전달 구성에서 tag-type이 "none"으로 선택되면 파트너 게이트웨이와 제공자 Edge 간의 BGP 인접 관계가 설정되지 않습니다. 이는 tag-type이 "none"인 경우 Orchestrator의 전달 구성 대신 /etc/config/gatewayd에서 ctag, stag 값이 선택되기 때문입니다.
해결 방법: /etc/config/gatewayd의 vrf_vlan->tag_info에서 ctag, stag 값을 각각 0으로 업데이트합니다. vc_procmon을 다시 시작합니다.
문제 67879: 사용자가 WAN 인터페이스 설정에서 WAN 오버레이 설정을 자동 감지에서 사용자 정의로 변경하면 CSS(클라우드 보안 서비스) 터널이 삭제됩니다.
변경 내용을 저장한 후에는 고객이 CSS 터널을 종료했다가 다시 터널을 실행하기까지는 터널이 다시 시작되지 않습니다. WAN 구성을 변경하면 CSS 터널이 종료되고 CSS 설정이 다시 구문 분석됩니다. 그러나 일부 경우에 nvs_config->num_gre_links가 0이고 CSS 터널이 실행되지 않습니다.
해결 방법: CSS 설정을 비활성화한 다음 다시 활성화하면 CSS 터널이 가동됩니다.
문제 68057: WAN 인터페이스 주소 모드를 DHCP 상태 저장에서 고정 IPv6 주소로 변경하는 동안 VMware SD-WAN Edge에서 DHCPv6 릴리스 패킷이 전송되지 않으며, 리스가 유효 기간에 도달할 때까지 활성 상태로 유지됩니다.
DHCPv6 클라이언트는 구성 변경이 완료되면 해제되지 않는 리스를 소유합니다. DHCPv6 서버에서 수명이 만료되고 삭제될 때까지 리스가 유효한 상태로 유지됩니다.
해결 방법: 리스가 유효 수명까지 활성 상태로 유지되므로 이 문제를 해결할 방법이 없습니다.
문제 68851: VMware SD-WAN Edge 및 VMware SD-WAN Gateway 각각에 동일한 TCP syslog 서버가 구성된 경우 Edge에서 syslog 서버로의 TCP 연결이 설정되지 않습니다.
Edge와 게이트웨이 각각에 동일한 TCP 서버가 있고 Edge의 syslog 패킷이 게이트웨이를 통해 라우팅되면 syslog 서버는 Edge로 TCP 재설정을 전송합니다.
해결 방법: 게이트웨이를 통해 라우팅하는 대신 Edge에서 직접 syslog 패킷을 보내거나 Edge 및 게이트웨이에 대해 다른 syslog 서버를 구성합니다.
문제 69284: Edge가 HA 구성에 VNF를 배포하고 릴리스 4.x를 사용하는 고가용성 토폴로지를 사용하는 사이트의 경우 이러한 HA Edge를 HA VNF가 지원되지 않는 3.4.x 릴리스로 다운그레이드한 다음, 4.5.0으로 업그레이드한 후에 HA VNF를 다시 활성화하면 대기 Edge VNF가 실행되지 않습니다.
대기 Edge의 VNF 상태가 SNMP를 통해 종료된 것으로 전달됩니다. HA VNF 쌍이 VNF-HA(릴리스 4.0 이상)를 지원하는 버전에서 Orchestrator의 VNF를 구성했을 때 이 기능을 지원하지 않는 릴리스로 다운그레이드되는 경우. 이 문제는 Edge가 VNF-HA를 지원하는 버전으로 다시 업그레이드되고 Orchestrator에서 다시 구성될 때 발생합니다.
해결 방법: Edge를 지원하지 않는 버전으로 다운그레이드하는 경우 HA 구성을 사용하려면 먼저 VNF를 비활성화해야 합니다.
문제 71719: Edge-클라우드 경로를 따라 PPTP 연결이 설정되지 않았습니다.
VMware SD-WAN Edge 뒤의 PPTP 서버에 대한 연결이 설정되지 않습니다.
해결 방법: Edge를 다시 시작하거나 재부팅하는 경우에도 이 문제에 대한 해결 방법은 없습니다.
문제 72358: VMware SD-WAN Orchestrator DNS 이름의 IP 주소가 변경되면 VMware SD-WAN Gateway의 관리부 프로세스가 이를 제대로 확인하지 못하고 게이트웨이가 Orchestrator에 연결할 수 없게 됩니다.
게이트웨이의 관리 프로세스는 Orchestrator의 DNS 이름의 DNS 확인을 주기적으로 수행하여 게이트웨이가 최근에 변경되었는지 확인하여 올바른 호스트에 연결될 수 있도록 합니다. DNS 확인 코드에 문제가 있어서 이러한 모든 확인 검사가 실패하고 게이트웨이가 이전 주소를 계속 사용하므로 Orchestrator에 더 이상 연결할 수 없습니다.
해결 방법: 이 문제가 해결될 때까지 운영자 사용자는 Orchestrator의 IP 주소를 변경하지 않아야 합니다. Orchestrator의 IP 주소를 변경해야 하는 경우 해당 Orchestrator에 연결하는 모든 게이트웨이를 재활성화해야 합니다.
문제 77541: IPv6을 지원하는 USB 모뎀을 분리했다가 VMware SD-WAN Edge USB 인터페이스에 다시 연결하면 IPv6 주소가 USB 인터페이스에 프로비저닝되지 않을 수 있습니다.
이는 ModemManager 애플리케이션에서 관리되는 경우보다 IP 기반 USB 모뎀에 더 많은 영향을 줍니다. 대부분의 Inseego 모뎀은 IP 기반이며 Inseego는 VMware SASE에서 권장하는 모뎀 제조업체이기 때문에 중요합니다. 연결 해제 및 연결 시나리오에서는 ModemManager를 사용하는 IPv6 지원 USB 모뎀과 IP 기반 모드가 잘 지원됩니다.
해결 방법: USB 모뎀을 Edge의 USB 포트에 다시 연결한 후에 Edge를 재부팅하거나 전원을 껐다 켜야 합니다. 재부팅 후 Edge는 모뎀의 IPv6 주소를 검색합니다.
문제 81852: L7 상태 점검이 켜진 GRE 터널을 사용하는 Zscaler 유형 CSS(클라우드 보안 서비스)를 사용하는 VMware SD-WAN Edge의 경우 Edge를 릴리스 5.0.0으로 업그레이드하면 일부 경우에 고객이 L7 상태 점검 오류를 확인할 수 있습니다.
이 문제는 일반적으로 소프트웨어 업그레이드 도중 또는 시작 시에 표시됩니다. GRE 터널을 사용하는 CSS에 대해 L7 상태 점검이 설정되면 소켓 getaddress 오류와 관련된 오류 메시지가 표시될 수 있습니다. 발견된 오류는 간헐적으로 확인되며 일관되지 않습니다. 이로 인해 L7 상태 점검 프로브 메시지가 전송되지 않습니다.
해결 방법: 이 수정 사항을 적용하지 않을 경우 문제를 해결하려면 사용자가 L7 상태 점검 구성을 해제했다가 다시 설정해야 하며, 이 경우 이 기능이 예상대로 작동합니다.
문제 82184: Edge 릴리스 5.0.0을 실행하는 VMware SD-WAN Edge에서 traceroute 또는 traceroute6이 Edge의 br-network IPv4/IPv6 주소로 실행되면 UDP 프로브가 사용될 때 traceroute가 올바르게 종료되지 않습니다.
기본 모드(즉, UDP 프로브)가 사용되는 경우 Edge의 br-network IPv4/IPv6 주소에 대한 traceroute 또는 traceroute6이 제대로 작동하지 않습니다.
해결 방법: traceroute 및 traceroute6에서 -I 옵션을 사용하여 ICMP 프로브를 사용한 다음, br-network IPv4/IPv6 주소에 대한 traceroute가 예상대로 작동합니다.
문제 83166: IPv6 옵션이 선택된 AWS 포털에서 AWS c5.4xlarge 인스턴스 유형을 사용하여 VMware SD-WAN Gateway를 새로 배포하면 IPv6 및 기본 경로가 둘 다 구성되지 않습니다.
IPv6 및 기본 경로가 구성되지 않아 AWS Gateway IPv6 관리 터널이 형성되지 않고 게이트웨이가 작동하지 않습니다.
해결 방법: 이 문제에 대한 해결 방법은 없습니다. 위에 언급된 속성을 사용하여 게이트웨이를 배포하지 마십시오.
문제 83227: 128개 세그먼트로 구성된 릴리스 5.0.0을 실행하는 VMware SD-WAN Edge의 경우 Edge의 dnsmasq 프로세스가 중지되고 종료됩니다.
128개 세그먼트에서 IPv6을 활성화하고 DCPv6 서버가 각 세그먼트의 LAN에 구성되면 열려 있는 총 파일 설명자 수가 초과될 때 dnsmasq 프로세스가 중지됩니다. dnsmasq 프로세스는 30분 정도 계속되다가 종료되며, 이때 Edge의 IP 주소 DHCP 할당이 실패합니다.
해결 방법: Edge를 재부팅하면 30분 이내에 dnsmasq 프로세스가 복원되지만 다시 실패합니다. 유일한 해결 방법은 세그먼트 수를 128개 미만으로 줄이는 것입니다.
문제 84790: 모델 유형이 510/510-LTE가 아닌 VMware SD-WAN Edge가 재부팅되면 Edge는 위험 이벤트 Unable to launch service wifihang을 VMware SASE Orchestrator에 잘못 보고합니다.
wifihang 이벤트 메시지는 Edge 510/510-LTE 모델에서만 사용하도록 설계되었으며 고객에게 해당 Edge 모델의 Wi-Fi 프로세스에 문제가 있음을 경고합니다. 이 이벤트 메시지가 다른 Edge 모델에서 확인되면 해당 모델이 Wi-Fi를 사용하든 그렇지 않든(예: Edge 3400) 이벤트 메시지는 가상이며 이벤트를 무시해도 안전합니다.
해결 방법: Edge 510 또는 510-LTE 이외의 Edge에서 발생하는 wifihang 이벤트 메시지는 가상이므로 무시해도 됩니다.
문제 86098: 대기 Edge에서 PPPoE WAN 링크가 사용되는 고급 고가용성 토폴로지를 사용하는 사이트의 경우 기본 프록시 경로가 활성 Edge에 설치되어 있지 않고 해당 링크를 사용하는 트래픽이 실패할 수 있습니다.
고급 HA Edge 쌍이 실행되면 PPPoE 링크가 대기 Edge와 동기화하고 다음 홉인 0.0.0.0이 포함된 기본 경로를 제공합니다. 그에 따라 이 경로가 활성에 설치되지 않고 이 링크를 사용하는 트래픽이 삭제됩니다.
해결 방법: 이 문제에 대한 해결 방법은 없습니다.
문제 92481: VMware SD-WAN Edge의 WAN 인터페이스가 VMware SASE Orchestrator에서 비활성화된 경우에도 인터페이스가 SNMP에 의해 '실행 중'으로 보고됩니다.
인터페이스 출력에 대한 키 디버그 프로세스에는 Edge WAN 인터페이스에 대한 물리적 포트 세부 정보(예: Edge 6x0 또는 3x00 모델의 GE3 또는 GE4)가 포함되지 않습니다. 따라서 SNMP가 해당 인터페이스를 폴링할 때 인터페이스가 구성된 방식에 관계없이 항상 실행 중 결과를 반환합니다.
해결 방법: 이 문제에 대한 해결 방법은 없습니다.
문제 92676: 게이트웨이를 통한 NSD(비 VMware SD-WAN 대상)가 중복 터널 및 중복 게이트웨이를 사용하도록 구성되어 있고 IPsec을 통한 BGP를 사용하는 고객 배포의 경우 기본 및 보조 게이트웨이가 기본 및 보조 NSD 터널에 대해 동일한 AS 경로를 지정하여 접두사를 애드버타이즈하면 기본 NSD 터널은 기본 게이트웨이보다 중복된 게이트웨이 경로를 선호합니다.
게이트웨이를 통한 기본 NSD 터널에 기본 게이트웨이를 통한 중복 게이트웨이 경로를 기본으로 사용할 경우에 미치는 영향은 NSD에서 게이트웨이로의 반환 트래픽에만 작용합니다.
이 문제를 수정하지 않는 경우 사용자는 NSD의 기본 터널이 반환 트래픽에 대해 기본 게이트웨이를 선택하는 데 도움이 되므로 관심 있는 접두사에 대해 중복 게이트웨이에 더 높은(3개 이상) 메트릭을 구성해야 합니다.
해결 방법: NSD의 기본 터널이 반환 트래픽에 대해 기본 게이트웨이를 선택하는 데 도움이 되므로 관심 있는 접두사에 대해 중복 게이트웨이에 더 높은(3개 이상) 메트릭을 구성합니다.
문제 93062: 사용자가 VMware Orchestrator에서 원격 진단 "인터페이스 상태(Interface Status)"를 실행하면 Orchestrator에서 해당 테스트에 대한 오류를 반환하고 완료되지 않거나 테스트가 라우팅된 인터페이스에 대한 결과를 반환하지 않습니다.
"테스트 데이터를 읽는 중 오류 발생"이라는 오류 메시지가 표시됩니다. 테스트가 완료되면 라우팅된 인터페이스에 대한 결과가 비어 있고 속도 또는 전이중 모드에 대한 정보도 없습니다. 어느 방향으로든 인터페이스 상태가 끊어집니다. 이 문제는 DPKD 활성화 포트를 생략하는 인터페이스 상태의 기반이 되는 디버그 명령과 관련이 있습니다.
해결 방법: 사용자는 라우팅된 인터페이스의 상태를 보려면 Edge에 대한 진단 번들을 생성해야 합니다.
문제 93141: 고가용성 토폴로지로 배포된 사이트에서 HA Edge 쌍의 L2 스위치 업스트림을 사용하는 고객이 실제 루프가 없지만 스위치 로그에서 L2 트래픽 루프의 증거를 확인할 수 있습니다.
이 문제는 HA Edge가 가상 MAC 주소를 사용하는 HA 인터페이스 하트비트가 인터페이스 실제 MAC 주소가 아닌 Orchestrator로 전송하기 때문에 발생하며, 이는 HA Edge가 해당 MAC 파일에 가상 MAC 주소를 저장하기 때문에 발생합니다. 따라서 연결된 L2 스위치는 두 개의 서로 다른 Edge 인터페이스에서 들어오는 동일한 소스 MAC의 트래픽을 감지하고 L2 루프로 기록합니다. 이 문제는 실제 L2 루프가 없고 이 문제로 인해 Orchestrator와의 고객 트래픽 중단 또는 연결 손실이 발생하지 않으므로 로그 수준에서 겉으로만 드러나는 문제입니다.
해결 방법: 고객은 Edge의 HA 인터페이스(일반적으로 GE1)에서 발생하는 업스트림 스위치의 L2 루프 감지 이벤트를 무시할 수 있습니다.
문제 94204: VNF 지원 VMware SD-WAN Edge에 대한 진단 번들을 생성하려는 시도가 실패합니다.
Edge의 디스크 공간이 부족하기 때문에 VNF 지원 Edge에서 진단 번들을 완료하지 못합니다. 이 문제는 Edge가 하나 이상의 코어를 생성하는 경우 발생할 수 있고, Edge가 이러한 코어를 /vnf/tmp 폴더로 전송하기 때문에 발생합니다. 각 코어는 /vnf/tmp 폴더에 압축 해제되고, 압축 해제된 코어의 크기가 이 폴더를 빠르게 채워 진단 번들에 장애가 발생합니다.
VNF(가상 네트워크 기능) 지원 Edge에는 다음 모델이 포함됩니다. 520v, 620, 640, 680, 840.
해결 방법: 이 문제에 대한 해결 방법은 없습니다.
문제 94980: 고가용성 토폴로지로 배포된 사이트의 경우 VMware SD-WAN 대기 Edge에서 데이터부 서비스 오류가 발생하고 HA Edge에 대해 PPPoE WAN 링크가 구성된 후 다시 시작될 수 있습니다.
대기 Edge에서 생성된 코어를 검사할 때 PPPoE 링크가 구성된 후 vc_is_use_cloud_gateway_set 메시지가 표시됩니다.
해결 방법: 이 작업의 위험을 관리하기 위해 유지 보수 기간에 PPPoE 링크를 구성하는 것 외에는 이 문제에 대한 해결 방법이 없습니다.
문제 95565: 고가용성 토폴로지를 사용하는 사이트에서 VMware SD-WAN 활성 Edge에서 코어가 생성되고 고가용성 페일오버가 트리거되면서 데이터부 서비스 장애가 발생할 수 있습니다.
이 문제는 SNMP 쿼리가 빈번한 SNMP를 사용하는 동안 활성 Edge의 WAN 링크가 한 번 이상 플래핑(종료되었다가 빠르게 실행)되면서 트리거됩니다. 인터페이스가 다시 실행되고 SNMP 쿼리가 교착 상태를 트리거하여 데이터부 서비스가 실패하고 코어를 생성할 수 있는 타이밍 문제가 있습니다. 단일 WAN 링크 플래핑만 이 문제를 유발할 수 있지만 WAN 링크 플래핑의 빈도가 높을수록 이 문제가 발생할 가능성이 높을 수 있습니다.
해결 방법: 이 문제가 발생하고 수정 사항이 적용되지 않은 HA Edge 쌍에서 해결 방법은 타이밍 문제이므로 SNMP를 사용하지 않도록 설정하는 것입니다. 이렇게 하면 위험이 줄어듭니다.
문제 97321: Edge Network Intelligence 분석이 VMware SD-WAN Edge에서 활성화되면 Edge가 Edge 서비스 다시 시작을 트리거하여 10~15초 동안 고객 트래픽이 중단될 수 있습니다.
Edge에서 분석을 사용하도록 설정하면 Edge에서 메모리 부족 상태가 발생한 후 "이중 사용 가능" 메모리 상태가 발생할 수 있습니다. Edge는 해당 서비스를 다시 시작하여 메모리를 복원합니다. 분석이 활성화된 동안 이 문제의 증상이 여러 번 발생할 수 있습니다.
해결 방법: 이 문제에 대한 해결 방법은 없습니다.
문제 97559: 향상된 고가용성 토폴로지로 배포된 고객 사이트에서 대기 역할의 VMware SD-WAN Edge에 연결된 WAN 링크가 VMware SASE Orchestrator에서 종료된 것으로 표시되고 WAN 링크가 연결된 Edge의 WAN 인터페이스가 실행 중인 경우에도 고객 트래픽을 전달하지 않을 수 있습니다.
tcpdump 또는 진단 번들 로깅을 확인하면 들어오는 ARP 요청이 관찰되고 대기 Edge가 포트 차단으로 인해 응답하지 않습니다.
고급 HA에서 Edge가 대기 역할을 가정하는 경우 다음 이벤트가 다음 순서로 발생해야 합니다.
대기 Edge는 모든 포트를 차단합니다.
그런 다음, 대기 Edge는 향상된 HA에 배포되었음을 감지하고 트래픽을 전달하기 위해 WAN 포트를 차단 해제합니다.
이 문제가 발생하면 이벤트 1에서 초기 포트 차단을 완료하는 데 예기치 않게 긴 시간이 걸리고 후속 이벤트 2에서 이벤트 1이 완료되기 전에 모든 WAN 포트의 차단 해제가 완료됩니다. 그런 다음, 이벤트 1이 완료되므로 최종 상태는 대기 Edge에서 모든 WAN 포트가 차단된 상태입니다.
해결 방법: 대기 Edge를 활성으로 승격하는 HA 페일오버가 발생하면 HA Edge의 WAN 링크가 실행됩니다.
문제 98136: 동적 분기 간 VPN이 구성된 허브/스포크 토폴로지를 사용하는 고객 엔터프라이즈의 경우 SD-WAN 스포크 Edge 뒤에 있는 클라이언트 사용자에게 일부 트래픽이 최적의 경로를 사용하는 트래픽으로 인해 예기치 않은 지연 시간이 발생할 수 있습니다.
이 문제가 발생하는 스포크 Edge 트래픽은 처음에는 스포크 Edge가 사용했던 프로필에 포함되지 않은 허브 Edge에 대한 비업링크 경로인 경로를 사용합니다. 트래픽이 관련되지 않은 다른 접두사로 전송되고 이 경우 비업링크 경로가 스포크 Edge에 설치되기 때문에 스포크 Edge에서 허브 Edge로 동적 분기 간 VPN 터널을 형성할 수 있습니다.
이 비업링크 경로의 결과로 이 접두사로 향하는 모든 트래픽이 허브 Edge를 통과하기 시작하고 비업링크 경로가 업링크(업링크 커뮤니티로의 커뮤니티 변경)가 되지만 이전에 설치한 비업링크 경로는 해지되지 않으며 동적 분기 간 VPN 터널이 작동되는 한 트래픽은 허브 Edge 경로를 사용합니다.
해결 방법: 동적 분기 간 VPN 터널이 해체될 때까지 기다립니다. 이후 허브 Edge로의 새 동적 분기 간 VPN 터널이 형성될 때 스포크 Edge에 업링크 경로가 설치되지 않습니다.
문제 110564: 향상된 고가용성 토폴로지에 배포된 고객 사이트의 경우 VMware SD-WAN 활성 Edge가 대기 Edge 링크 상태를 표시하지 않고 대기 Edge 일련번호가 VMware SASE Orchestrator에서 알 수 없음으로 표시됩니다.
모니터링(Monitor) 또는 원격 진단(Remote Diagnostics) 아래에서 Orchestrator를 확인할 때 향상된 HA 사이트가 제대로 작동하더라도 활성 Edge는 대기 Edge의 링크 또는 대기 Edge의 일련번호에 대한 정확한 상태를 보고하지 않습니다.
해결 방법: 이 문제에 대한 해결 방법은 없습니다.
문제 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의 프로필에서 허브 클러스터의 선택을 취소할 수 있습니다.
문제 35658:
VMware SD-WAN Edge가 한 프로필에서 다른 CSS 설정이 지정된 다른 프로필로 전환되면(예: profile1의 IPsec에서 profile2의 IPsec으로) Edge 수준 CSS 설정은 이전 CSS 설정(예: GRE 대신 IPsec)을 계속 사용합니다.
해결 방법: Edge 수준에서 GRE를 비활성화한 다음 GRE를 다시 활성화하여 문제를 해결합니다.
문제 35667:
VMware SD-WAN Edge가 한 프로필에서 CSS 설정은 동일하지만 GRE CSS 이름(동일한 끝점)은 다른 프로필로 전환되면 일부 GRE 터널이 모니터링 시 표시되지 않습니다.
해결 방법: Edge 수준에서 GRE를 비활성화한 다음 GRE를 다시 활성화하여 문제를 해결합니다.
문제 36665:
VMware SD-WAN Orchestrator가 인터넷에 연결할 수 없는 경우 Google Maps API에 액세스해야 하는 사용자 인터페이스 페이지가 완전히 로드되지 않을 수도 있습니다.
문제 32913:
고가용성을 활성화한 후 VMware SD-WAN Edge에 대한 멀티캐스트 세부 정보가 모니터링(Monitoring) 페이지에 표시되지 않습니다. 페일오버를 수행하면 문제가 해결됩니다.
문제 33026:
계약을 삭제한 후 ‘EUSA(최종 사용자 서비스 계약)(End User Service Agreement(EUSA))’ 페이지가 제대로 다시 로드되지 않습니다.
문제 38056:
Edge-Licensing export.csv 파일에 지역 데이터가 표시되지 않습니다.
문제 38843:
애플리케이션 맵을 푸시할 때 운영자 이벤트가 없으며 Edge 이벤트는 사용이 제한됩니다.
문제 39633:
사용자가 대체 게이트웨이를 슈퍼 게이트웨이로 할당한 후에는 슈퍼 게이트웨이 하이퍼링크가 작동하지 않습니다.
문제 39790:
VMware SD-WAN Orchestrator는 VMware SD-WAN Edge의 라우팅된 인터페이스를 지원되는 32개의 하위 인터페이스보다 더 많이 유지하도록 허용하므로 사용자가 인터페이스에서 33개 이상의 하위 인터페이스를 구성하여 Edge의 데이터부 서비스 실패를 유발할 위험이 있습니다.
문제 41691:
구성(Configure) > Edge > 디바이스(Device) 페이지에서 DHCP 풀이 고갈되지 않더라도 사용자가 '주소 수(Number of addresses)' 필드를 변경할 수 없습니다.
문제 43276:
VMware SD-WAN Edge 또는 프로필에 파트너 게이트웨이가 구성된 경우 사용자는 세그먼트 유형을 변경할 수 없습니다.
해결 방법: 개인 및 정규 간에 세그먼트를 변경할 수 있도록 프로필 또는 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을 삭제할 수 있습니다.
이 문제가 발생하면 "Edge [b1-edge1(GEx-disabled)]에서 사용 중인 VLAN ID [xx]을(를) 제거할 수 없습니다."라는 오류 메시지가 표시됩니다.
문제 51722: VMware SASE Orchestrator에서 시간 범위 선택기는 [모니터링(Monitor)] > [Edge] 탭의 통계에서 2주보다 크지 않습니다.
통계 집합의 보존 기간이 2주보다 긴 경우에도 시간 범위 선택기는 모니터링(Monitor) > Edge 탭의 [지난 2주(Past 2 Weeks)]보다 큰 옵션을 표시하지 않습니다. 예를 들어, 경로 통계는 기본적으로 2주 동안만 보존되지만(구성 가능) 흐름 및 링크 통계는 기본적으로 365일 동안 보존됩니다(구성 가능). 이 문제는 사용자가 해당 통계의 보존 기간과 일치하는 기간을 선택할 수 있도록 허용하지 않고, 모든 모니터링 탭에서 가장 짧은 통계 유지 기간을 따르도록 합니다.
해결 방법: 시간 범위 선택기에서 "사용자 지정(Custom)" 옵션을 사용하여 2주일보다 오래된 데이터를 볼 수 있습니다.
문제 60522: VMware SD-WAN Orchestrator UI에서 세그먼트를 제거하려고 하면 많은 오류 메시지가 표시됩니다.
이 문제는 프로필에 세그먼트를 추가하고 세그먼트를 여러 VMware SD-WAN Edge와 연결할 때 발견될 수 있습니다. 사용자가 프로필에서 추가된 세그먼트를 제거하려고 하면 많은 오류 메시지가 표시됩니다.
해결 방법: 이 문제에 대한 해결 방법은 없습니다.
문제 82680: MT-GRE 터널 자동화를 사용하는 고객의 경우 CCI를 사용하도록 구성된 VMware SD-WAN Gateway에서 클라우드 간 상호 연결(Cloud-to-Cloud Interconnect) 플래그를 끄면 Zscaler MT-GRE 항목이 Zscaler 포털에서 일관되게 삭제되지 않을 수 있습니다.
게이트웨이에서 CCI 사이트가 삭제된 후에는 이 사이트에 대한 항목도 제거되어야 합니다. 이 문제는 테스트 자동화 중에만 확인되었으며 수동으로 재현되지는 않았지만 여전히 위험합니다.
해결 방법: 재시도하기 전에 Zscaler에서 리소스를 수동으로 삭제하십시오.
문제 82681: MT-GRE 터널 자동화를 사용하는 고객의 경우 CCI를 사용하도록 구성된 VMware SD-WAN Gateway에서 클라우드 간 상호 연결(Cloud-to-Cloud Interconnect) 플래그를 끄고 Zscaler 클라우드 보안 서비스를 사용하여 CCI가 구성된 VMware SD-WAN Edge에서 CCI 플래그를 비활성화하면 Zscaler MT-GRE 항목이 Edge 또는 Zscaler 포털에서 일관되게 삭제되지 않을 수 있습니다.
게이트웨이에서 CCI 사이트가 삭제된 후에는 이 사이트에 대한 항목도 제거되어야 합니다. 이 문제는 테스트 자동화 중에만 확인되었으며 수동으로 재현되지는 않았지만 여전히 위험합니다.
해결 방법: 재시도하기 전에 Zscaler에서 리소스를 수동으로 삭제하십시오.
문제 65001: VMware Cloud Web Security를 사용하는 고객의 경우 VMware Orchestrator를 사용할 때 파일 해시 확인을 설정/해제하도록 검사 엔진을 구성할 수 없습니다.
사용자가 Orchestrator를 사용하여 “알 수 없는 파일 다운로드에 대한 작업(Action for Unknown File Download)” 및 “알 수 없는 문서 다운로드에 대한 작업(Action for unknown document Download)”에 대해 Cloud Web Security 검사 엔진의 파일 해시 확인 매개 변수를 구성하는 경우 해당 변경 내용이 검사 엔진으로 전송되지 않고 적용되지 않습니다.
해결 방법: 이 문제에 대한 해결 방법은 없습니다.
문제 63149: 고객 배포에서 프로필에 겹치는 서브넷이 있고, VMware Cloud Web Security 정책에 대한 서브넷을 구성하고, Cloud Web Security 정책을 프로필 및 세그먼트에 연결하는 경우 해당 서브넷의 Edge 클라이언트는 인터넷에 연결할 수 없습니다.
동일한 세그먼트 내에서 VMware SD-WAN Edge 뒤에 있는 LAN 세그먼트에 대해 겹치는 서브넷을 구성한 경우 Edge 뒤에 있는 리소스의 인터넷 바인딩 트래픽에 대해 Cloud Web Security 정책을 적용할 수 없습니다. 인터넷에서 Cloud Web Security으로의 반환 트래픽에 대해 대상 Edge를 고유하게 식별할 방법이 없기 때문입니다.
해결 방법: Edge에서 LAN 측 NAT를 설정하고 고유 서브넷이 Edge 뒤의 리소스에서 시작된 트래픽을 나타내도록 합니다.
문제 62934: VMware Cloud Web Security를 사용하는 엔터프라이즈의 경우, 클라이언트 사용자가 시크릿 모드에서 Chrome 브라우저를 열고 파일을 다운로드하려고 하면 다운로드가 성공하지 못할 수 있습니다.
시크릿 모드를 사용하려면 타사 쿠키를 설정해야 합니다. 타사 쿠키를 설정하고 작업을 다시 시도하십시오. 다운로드가 실패하면 사용자에게 “오류가 발생했습니다. 관리자에게 문의하십시오.” 화면이 표시되거나 사용자 지정 웹 서버의 파일에 대해 “이 페이지가 작동하지 않습니다.” 화면이 표시됩니다. 경우에 따라 일부 웹 서버 또는 파일에서 Cloud Web Security 서비스가 인식하지 못하는 파일 서명 차이가 나타날 수 있으므로 이 문제가 발생합니다.
해결 방법: 타사 쿠키 허용을 설정하고 다시 시도하십시오. 시크릿 모드 창을 사용할 경우 이 문제에 대한 알려진 해결 방법이 없습니다.
문제 64541: VMware Secure Access를 사용하는 고객의 경우 Workspace ONE UEM 구성의 옵션을 사용하여 조직 그룹 내의 터널 호스트 이름을 구성할 때 사용자가 [예(Yes)]를 선택하면 호스트 이름을 수동으로 구성할 필요가 없이 UEM 콘솔에서 호스트 이름이 자동으로 생성됩니다.
사용자는 호스트 이름이 자동으로 생성되지 않고 수동으로 구성하는 옵션을 사용할 수 있습니다.
해결 방법: 이 수정 사항을 적용하지 않은 경우 해결 방법은 UEM 콘솔에서 수동으로 설정하는 것입니다.
