RSS
 

VMware SASE 4.5.1 | 2023년 4월 25일

  • VMware SASE™ Orchestrator 버전 R451-20220831-GA

  • VMware SD-WAN™ Gateway 버전 R451-20220701-GA

  • VMware SD-WAN™ Edge 버전 R451-20230112-GA-87923

  • Orchestrator 버전 R451-20220831-GA를 사용하는 VMware Cloud Web Security™

  • Orchestrator 버전 R451-20220831-GA를 사용하는 VMware Secure Access™ 버전

  • Orchestrator 버전 R451-20220831-GA를 사용하는 VMware Edge Network Intelligence™

이 릴리스 정보의 추가 사항 및 업데이트 사항을 확인하십시오.

릴리스 정보에 있는 내용

릴리스 정보에는 다음과 같은 항목이 포함됩니다.

권장 사용

이 릴리스는 릴리스 4.5.0에서 처음으로 제공하는 기능이 필요한 모든 고객뿐 아니라 아래에 나열되어 있으나 릴리스 4.5.0 이후에 해결된 문제의 영향을 받은 고객에게 권장됩니다.

호환성

릴리스 4.5.1 Orchestrator, 게이트웨이 및 허브 Edge는 릴리스 3.2.0 이상의 모든 이전 VMware SD-WAN Edge 버전을 지원합니다.

참고: 즉, 3.2.0 이전 릴리스는 지원되지 않습니다.

다음과 같은 SD-WAN 상호 운용성 조합은 명시적으로 테스트되었습니다.

Orchestrator

게이트웨이

Edge

허브

분기/스포크

4.5.0

4.5.1

4.5.0

4.5.0

4.5.0

4.5.1

4.5.1

4.5.1

4.5.0

4.5.0

4.5.1

4.5.0

4.5.1

3.4.6

3.4.6

3.4.6 

4.5.1

4.5.1

3.4.6

3.4.6

4.5.1

4.5.1

4.5.1

3.4.6

4.5.1

4.5.1

3.4.6

4.5.1

4.5.1

4.2.2

4.2.2

4.2.2

4.5.1

4.5.1

4.2.2

4.2.2

4.5.1

4.5.1

4.5.1

4.2.2

4.5.1

4.5.1

4.2.2

4.5.1

4.5.1

4.3.1

4.3.1

4.3.1

4.5.1

4.5.1

4.3.1

4.3.1

4.5.1

4.5.1

4.5.1

4.3.1

4.5.1

4.5.1

4.3.1

4.5.1

4.5.1

4.5.0

4.5.0

4.5.0

4.5.1

4.5.1

4.5.0

4.5.0

4.5.1

4.5.1

4.5.1

4.5.0

4.5.1

4.5.1

4.5.0

4.5.1

5.0.0

4.5.1

4.5.0

4.5.1

5.0.0

5.0.0

4.5.0

4.5.1

참고: 위 표는 SD-WAN 서비스를 사용하는 고객에게만 유효합니다. VMware Cloud Web Security 또는 VMware Secure Access에 액세스해야 하는 고객은 해당 Edge를 릴리스 4.5.0 또는 4.5.1로 업그레이드해야 합니다.

경고:

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에 대한 업그레이드 경로

Orchestrator

릴리스 4.0.0부터 진행된 Orchestrator의 인프라 변경으로 인해 3.x 릴리스를 사용하는 Orchestrator는 4.5.1로 업그레이드하기 전에 먼저 4.0.0으로 업그레이드해야 합니다. 릴리스 4.0.0 이상을 사용하는 Orchestrator를 릴리스 4.5.1로 업그레이드할 수 있습니다. 따라서 Orchestrator의 업그레이드 경로는 다음과 같습니다.

릴리스 3.x를 사용하는 Orchestrator → 4.0.0 → 4.5.1.

릴리스 4.x를 사용하는 Orchestrator → 4.5.1.

게이트웨이

3.x에서 4.5.1으로의 게이트웨이 업그레이드는 지원되지 않습니다. 3.x 게이트웨이는 업그레이드하는 대신 동일한 VM 특성으로 새로 배포해야 하며 이전 인스턴스는 더 이상 사용되지 않습니다.

릴리스 4.0.0 이상을 사용하여 게이트웨이를 업그레이드하는 것은 모든 게이트웨이 유형에 대해 완전히 지원됩니다.

Edge

Edge는 모든 릴리스 3.x 이상에서 릴리스 4.5.1으로 직접 업그레이드할 수 있습니다.

중요 참고 사항

고가용성 토폴로지를 사용하는 사이트의 잠재적 문제

Edge 쌍이 고가용성 토폴로지에 배포된 사이트에서 대기 Edge가 활성-활성 상태를 해결하기 위해 한 번 이상 재부팅되는 문제가 발생할 수 있습니다. 대기 Edge가 재부팅되면 고객 트래픽이 중단되고, 대기 Edge가 고객 트래픽을 전달하므로 고급 HA 토폴로지를 사용하는 사이트에 미치는 영향이 커질 수 있습니다. 릴리스 4.5.1의 첫 번째 롤업 빌드에서 해결된 문제 #85369가 다음과 같이 추적됩니다. R451-20220701-GA. 이 문제는 이 릴리스 정보의 R451-20220701-GA에 대한 Edge/게이트웨이의 해결된 문제 섹션에서 추적되며 HA 사이트를 사용하는 고객은 Edge를 R451-20220701-GA로 업그레이드하는 것이 권장됩니다.

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로 업그레이드하는 고객은 올바르지 않은 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에서 펌웨어를 업그레이드한 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)에서 자동 협상 기능을 비활성화할 경우의 제한 사항을 참조하십시오.

고가용성에서 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 지원 모두)인지 확인해야 합니다.

문서 개정 기록

2022년 5월 18일. 1차 개정판.

2022년 5월 20일. 2차 개정판.

  • Orchestrator의 알려진 문제 섹션에 미해결 문제 #89349를 추가했습니다. 이것은 R451-20220517-GA 빌드를 사용하여 4.5.1 Orchestrator를 배포하는 사용자의 로그인 페이지에 베타 라이센스 계약 주의가 표시되는 표면적인 문제입니다. R451-20220517-GA는 베타 빌드가 아니며 이 메시지가 최종 GA 빌드에 잘못 포함되었습니다. 이 문제는 향후 출시될 첫 번째 Orchestrator 롤업 빌드에서 수정됩니다.

2022년 5월 24일. 3차 개정판.

  • Orchestrator 해결된 문제 섹션에 새로운 Orchestrator 롤업 빌드 R451-20220520-GA를 추가했습니다. 이는 첫 번째 Orchestrator 롤업 빌드이며 릴리스 4.5.1에 대한 새로운 Orchestrator GA 빌드입니다.

  • Orchestrator 롤업 빌드 R451-20220520-GA에는 이 섹션에 설명된 해결된 문제 #89349를 포함합니다.

2022년 6월 1일, 4차 개정판.

  • 초기 GA 빌드의 Orchestrator 해결된 문제에 해결된 문제 #81835를 추가했습니다. 이 티켓은 4.5.1 릴리스 정보의 첫 번째 개정판에서 발생하는 오류로 인해 생략되었습니다.

  • Edge/게이트웨이의 알려진 문제 섹션에 문제 #85369 및 #85461이 추가되었습니다.

2022년 6월 8일. 5차 개정판.

  • 중요 참고 사항이 추가됨: Edge 쌍에 대해 고가용성 토폴로지를 사용하는 고객 사이트의 지속적인 문제와 관련된 "고가용성 토폴로지를 사용하는 사이트의 잠재적 문제". 이 문제는 Edge/게이트웨이의 알려진 문제에 있는 #85369로 계속 추적됩니다.

  • 호환성에서 릴리스 4.2.x Edge 소프트웨어의 수명 종료 날짜를 수정했습니다. Edge 소프트웨어는 별도의 항목으로 구분되며 이제 다음 내용을 표시합니다. "릴리스 4.2.x Edge는 2023년 6월 30일에 EOGS(일반 지원 종료)에 도달하고 2023년 9월 30일에는 EOTG(기술 지침 종료)에 도달하게 됩니다." 별도의 Orchestrator 및 게이트웨이 항목은 이전과 동일한 수명 종료 날짜를 유지합니다.

2022년 6월 17일. 6차 개정판.

  • Orchestrator 해결된 문제 섹션에 새로운 Orchestrator 롤업 빌드 R451-20220612-GA를 추가했습니다. 이는 두 번째 Orchestrator 롤업 빌드이며 릴리스 4.5.1에 대한 새로운 Orchestrator GA 빌드입니다.

  • Orchestrator 롤업 빌드 R451-20220612-GA에는 이 섹션에 설명된 해결된 문제 #86848, #89800이 포함됩니다.

  • 호환성 테이블에 테스트되고 검증된 새로운 세 가지 상호 운용성 조합이 추가되었습니다. 세 가지 조합 모두 4.5.0 Orchestrator 및 게이트웨이 소프트웨어를 포함하며 테이블 맨 위에 나열됩니다.

2022년 7월 1일. 19차 개정판.

  • Edge/게이트웨이의 알려진 문제 섹션에 미해결 문제 #88604와 #91746을 추가했습니다.

2022년 7월 14일. 20차 개정판.

  • Edge 및 게이트웨이의 해결된 문제 섹션에 새로운 Edge/게이트웨이 롤업 빌드 R451-20220701-GA를 추가했습니다. 이것은 첫 번째 Edge/게이트웨이 롤업 빌드 및 릴리스 4.5.1에 대한 새로운 Edge/게이트웨이 GA 빌드입니다.

  • Edge/게이트웨이 빌드 R451-20220701-GA에는 문제 #64196#78568, #83083, #85369, #85461, #87304, #89627, #89725#89861, #89873, #90151, #90280, #91746 및 #92216에 대한 수정 사항이 포함되어 있으며 각 문제는 이 섹션에 설명되어 있습니다.

  • Edge/게이트웨이의 알려진 문제 섹션에 미해결 문제 #81859, #91365, #92481 및 #92676을 추가했습니다.

  • 다음과 같은 중요 참고 사항이 수정되었습니다. "고가용성 토폴로지를 사용하는 사이트의 잠재적 문제"는 지금 문제 #85369가 새 Edge 빌드 R451-20220701-GA에서 해결되었으며 HA 사이트를 사용하는 고객은 가능한 한 빨리 Edge를 이 새 빌드로 업그레이드하는 것이 권장된다고 설명합니다.

2022년 8월 2일. 21차 개정판.

  • 중요 참고 사항이 추가됨: Edge Network Intelligence 서비스를 사용하는 고객이 분석을 사용하는 모든 Edge에서 메모리 누수로 인해 3-4일 간격으로 다시 시작되는 알려진 문제 #91365와 관련된 "Edge Network Intelligence를 사용하는 Edge 관련 문제"가 추가되었습니다. 문제 #91365는 새 핫픽스 빌드 R451-20220720-GA-91365에서 수정되었으며 Edge/게이트웨이의 알려진 문제에서 계속 추적되어야 합니다.

  • Orchestrator 롤업 빌드 R451-20220520-GA에 대한 Orchestrator의 해결된 문제 섹션에 해결된 문제 #84214 및 #86546을 추가했습니다. 이 첫 번째 Orchestrator 롤업 빌드의 초기 게시에서 두 티켓이 오류로 인해 생략되었습니다.

2022년 8월 11일. 22차 개정판.

  • Orchestrator 해결된 문제 섹션에 새로운 Orchestrator 롤업 빌드 R451-20220810-GA를 추가했습니다. 이것은 세 번째 Orchestrator 롤업 빌드이며 릴리스 4.5.1에 대한 새로운 Orchestrator GA 빌드입니다.

  • Orchestrator 롤업 빌드 R451-20220810-GA에는 이 섹션에 설명된 해결된 문제 #80735, #83507, #88120, #90067, #91179, #92082 등이 포함됩니다.

2022년 8월 16일. 23차 개정판.

  • Edge/게이트웨이의 알려진 문제 섹션에 미해결 문제 #89217을 추가했습니다.

2022년 8월 26일. 24차 개정판.

  • 기존 GA 빌드 R451-20220513-GA에서 문제 #86808을 Edge/게이트웨이의 알려진 문제에서 Edge/게이트웨이의 해결된 문제로 이동했습니다. 원래 릴리스 4.5.1 GA Edge 빌드 R451-20220513-GA에 수정 사항이 포함된 경우 이 문제는 릴리스 4.5.1에 대해 수정되지 않은 것으로 잘못 분류되었습니다.

  • Edge/게이트웨이의 알려진 문제에 포함되어 있는 미해결 문제 #49712를 엔지니어링 팀에서 코드 결함이 아닌 구성 오류에 의한 것으로 결론지었으므로 알려진 문제 목록에서 제거되었습니다.

2022년 9월 9일 25차 개정판.

  • Orchestrator 해결된 문제 섹션에 업데이트된 Orchestrator 3번째 롤업 빌드 R451-20220831-GA를 추가했습니다. 빌드 R451-20220831-GA는 원래 3번째 Orchestrator 빌드 R451-20220810-GA를 대신하며 릴리스 4.5.1에 대한 새로운 Orchestrator GA 빌드입니다. 업데이트된 이 빌드는 새로운 해결된 문제를 추가하지 않으며 이제 VMware 엔지니어링 팀에 필요한 문제 해결 변경 사항을 포함합니다.

  • Edge/게이트웨이의 알려진 문제 섹션에 문제 #87552 및 #93383을 추가했습니다.

2022년 9월 14일. 26차 개정판.

  • Edge/게이트웨이의 알려진 문제 섹션에 문제 #91875를 추가했습니다.

2022년 9월 23일. 27차 개정판.

  • Edge/게이트웨이의 해결된 문제 섹션에 새로운 Edge 롤업 빌드 R451-20220916-GA를 추가했습니다. 이는 두 번째 Edge 롤업 빌드이며 릴리스 4.5.1에 대한 새로운 Edge GA 빌드입니다. 게이트웨이 빌드는 변경되지 않고 그대로 유지됩니다.

  • Edge 빌드 R451-20220916-GA에는 이 섹션에 설명된 해결된 문제 #86098, #93383, #94204, #94395, #95565, #96441 및 #96888을 포함합니다.

  • Edge/게이트웨이의 알려진 문제 섹션에 #87982을 추가했습니다.

2022년 10월 5일. 28차 개정판.

  • Edge/게이트웨이의 알려진 문제 섹션에 #98136을 추가했습니다.

  • 기존 빌드 R451-20220513-GA에 대한 Edge/게이트웨이의 해결된 문제 섹션에 #75117을 추가했습니다. 이 문제는 기존 4.5.1 릴리스 정보에서 발생하는 오류로 인해 생략되었습니다.

2022년 11월 29일. 29차 개정판.

  • Edge/게이트웨이의 알려진 문제 섹션에 문제 #76837, #82104,#97321 및 #97559를 추가했습니다.

2022년 12월 7일. 30차 개정판.

  • 원래 빌드 R451-20220517-GA에 대한 Orchestrator 해결된 문제 섹션에 해결된 문제 #76508이 추가되었으며 릴리스 정보의 첫 번째 버전에서는 실수로 생략되었습니다.

2022년 12월 19일. 31차 개정판.

  • Edge/게이트웨이의 해결된 문제 섹션에 새로운 Edge 롤업 빌드 R451-20221213-GA를 추가했습니다. 이는 세 번째 Edge 롤업 빌드이며 릴리스 4.5.1에 대한 새로운 Edge GA 빌드입니다. 게이트웨이 빌드는 변경되지 않고 그대로 유지됩니다.

  • Edge 빌드 R451-20221213-GA에는 이 섹션에 설명된 해결된 문제 #68335, #77342, #87552, #91365, #94612, #96994, #97483, #97559, #100089 및 #101049가 포함됩니다. 

  • 문제 #91365는 중요 참고 사항 섹션 및 알려진 문제 섹션에서 제거되었습니다.

  • Edge/게이트웨이의 알려진 문제 섹션에 #78050, #81353, #84501, #89235, #95399, #97997 및 #100005를 추가했습니다.

2022년 1월 19일. 32차 개정판.

  • Edge/게이트웨이 해결된 섹션에 새로운 Edge 핫픽스 빌드 R451-20230112-GA-87923이 추가되었으며 이 빌드는 릴리스 4.5.1에 대한 새로운 Edge GA 빌드입니다. Edge 핫픽스 빌드 R451-20230112-GA-87923에는 이 섹션에 설명된 해결된 문제 #87923에 대한 수정 사항이 포함되어 있습니다. 

  • 게이트웨이 빌드는 변경되지 않고 그대로 유지됩니다.

2023년 1월 30일. 33차 개정판.

  • 문제 해결에 필요한 수정된 Edge 버전 (R5012-20230123-GA-103475) 및 플랫폼 펌웨어 버전 (R131-20221216-GA)를 반영하도록 알려진 문제 #89217을 수정했습니다. 또한 이 티켓은 #89217을 포함하며 6x0 Edge 업그레이드를 위한 단계별 지침이 포함된 KB 문서에 대한 링크를 추가합니다.

  • 호환성 섹션에서 4.2.x에 대한 지원 종료와 관련된 가져오기 참고 사항을 수정하고 SD-WAN Edge 소프트웨어에 대해 새로 수정된 날짜를 반영하도록 릴리스 4.3.x를 추가했습니다.

2023년 2월 2일. 34차 개정판.

  • 기존 빌드 R451-20220513-GA에 대한 Edge/게이트웨이의 해결된 문제 섹션에 #78003을 추가했습니다. 이 문제는 기존 4.5.1 릴리스 정보에서 발생하는 오류로 인해 생략되었습니다.

  • Edge/게이트웨이의 알려진 문제 섹션에 #98979을 추가했습니다.

2023년 2월 17일. 35차 개정판.

  • 릴리스 4.3.0에서 해결된 다른 티켓 #39501과 중복되므로 Edge/게이트웨이의 알려진 문제 섹션에서 문제 #39659가 제거되었습니다.

2023년 3월 14일. 36차 개정판.

  • Edge/게이트웨이의 알려진 문제 섹션에 문제 #75593을 추가했습니다.

2023년 4월 25일. 37차 개정판.

  • 호환성 섹션이 업데이트되어 모든 3.x 릴리스가 EOSL(서비스 수명 종료)에 도달한 것으로 표시되었습니다. 또한 4.2.x Orchestrator 및 게이트웨이를 EOSL(서비스 수명 종료)으로 표시하도록 4.x 섹션이 업데이트되었습니다.

Edge 및 게이트웨이의 해결된 문제

Edge 버전 R451-20230112-GA-87923에서 해결됨

Edge 버전 R451-20230112-GA-87923은 2023년 1월 19일에 릴리스되었으며 릴리스 4.5.1용 핫픽스 빌드입니다.

이 Edge 핫픽스 빌드는 세 번째 Edge 롤업 빌드, 버전 R451-20221213-GA 이후의 아래와 같은 중요한 문제를 해결합니다.

  • 해결된 문제 87923: 잘못된 형식의 ICMP 패킷이 VMware SD-WAN Edge로 전송되면 Edge에서 데이터부 서비스 장애가 발생하고 결과적으로 다시 시작될 수 있습니다.

    Edge는 IP 패킷 길이(예: IP 패킷 길이가 24인 ICMP 패킷)의 유효성을 검사하지 않으므로 Edge의 메모리가 손상되어 데이터부 서비스 장애가 트리거되고 다시 시작될 수 있습니다.

Edge 버전 R451-20221213-GA에서 해결됨

Edge 버전 R451-20221213-GA는 2022년 12월 19일에 릴리스되었으며 3번째 릴리스 4.5.1용 Edge 롤업입니다.

이 Edge 롤업 빌드는 두 번째 Edge 롤업 빌드, 버전 R451-20220916-GA 이후의 아래와 같은 중요한 문제를 해결합니다.

  • 해결된 문제 68335: SD-WAN 제어 트래픽은 Edge가 데이터 센터 클러스터에 연결하지 못할 때 높은 대역폭을 사용합니다.

    Edge가 해당 데이터 센터 클러스터와의 오버레이를 설정하지 못하면 Edge는 컨트롤러에 다른 클러스터 멤버를 다시 할당하도록 요청하여 연속 제어 이벤트를 전송하고 링크 대역폭을 사용하도록 합니다.

  • 해결된 문제 77342: VRRP의 경우 Edge가 기본이면 클라이언트의 클라우드 트래픽이 삭제됩니다.

    이 문제는 Edge 경로 테이블의 잘못된 클라우드 경로로 인해 발생합니다. 그 결과 다음 홉이 없어서 클라우드 IP에 대한 ARP가 실패하고 ipv4-send-encap-error를 발생하며 패킷이 삭제됩니다.

  • 해결된 문제 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 링크만 선택합니다. 이렇게 하면 이중화가 손실되지만 이 문제로 인한 영향이 완화됩니다.

  • 해결된 문제 91365: Edge Network Intelligence를 사용하는 고객의 경우 분석이 구성된 VMware SD-WAN Edge에서 메모리 누수로 인해 Edge 서비스가 다시 시작되어 메모리가 지워집니다.

    Edge에서 분석 기능이 사용하도록 설정되면 Edge의 데이터부 서비스에서 일정한 속도로 메모리 누수가 시작되어 Edge가 위험 수준(90초 이상 메모리 활용률 60% 지속)에 도달하면 예약되지 않은 서비스 다시 시작을 트리거하여 메모리 누수를 제거해야 합니다. Edge 서비스를 다시 시작하면 고객 트래픽이 10-15초 동안 중단됩니다. 현장에서 Edge 서비스 다시 시작을 트리거하는 데 소요되는 시간은 3~4일 이내이며, 메모리가 지워지면 메모리 누수는 이후 Edge 서비스가 다시 시작될 때 재개됩니다. Edge가 위험 메모리 사용량 수준에 도달하는 기간은 Edge 모델 및 분석 기능이 해당 Edge에 대해 기록하는 정보의 양에 따라 다릅니다.

  • 해결된 문제 94612: 트래픽이 BGP 네트워크 접두사에 도달할 수 없습니다.

    BGP 네트워크 접두사가 BGP에서 구성되지 못했으며 피어 노드에 애드버타이즈되지 않았습니다.

  • 해결된 문제 96994: VMware SD-WAN Edge에서 SNMP 워크를 수행할 때 일부 인터페이스가 표시되지 않을 수 있습니다.

    누락된 인터페이스가 snmpwalk에 표시되어야 하는 유효한 인터페이스일 수 있습니다. 그러나 Edge의 하드웨어 목록에 잘못된 인터페이스가 표시되어, 목록에서 잘못된 인터페이스 다음에 표시되는 유효한 인터페이스가 표시되지 않거나 snmpwalk에서 반환되지 않습니다. 여기에 있는 인터페이스는 하드웨어 목록에 나타나는 경우에는 유효하지만, Edge에서 ifconfig 명령을 실행할 때 나타나지 않는 경우 유효하지 않습니다.

    이 문제는 모든 Edge에 잠재적으로 영향을 줄 수 있지만 Azure를 사용하여 배포된 가상 Edge에서 발생할 가능성이 더 큽니다. 이 문제는 Azure Edge가 ifconfig를 사용하여 Edge 자체에서 식별된 인터페이스 수에 비해 더 많은 수의 인터페이스를 하드웨어 목록에 표시하는 경향이 있기 때문에 발생합니다.

  • 해결된 문제 97483: 2코어 가상 Edge의 처리량은 CPU 전원이 충분한데도 500Mbps(tx 방향)를 초과하지 않습니다.

    2코어 가상 Edge의 처리량은 오버로드되지 않도록 500Mbps로 소프트 제한되었습니다. 하지만 Edge 소프트웨어가 개선되어 이제 2코어 가상 Edge가 오버로드되어 한도가 너무 심하게 제한되는 상황이 발생하지 않고도 더 많은 트래픽을 처리할 수 있게 되었습니다. 한도는 이제 1000M으로 높아졌습니다.

  • 해결된 문제 97559: 향상된 고가용성 토폴로지로 배포된 고객 사이트에서 대기 역할의 VMware SD-WAN Edge에 연결된 WAN 링크가 VMware SASE Orchestrator에서 종료된 것으로 표시되고 WAN 링크가 연결된 Edge의 WAN 인터페이스가 실행 중인 경우에도 고객 트래픽을 전달하지 않을 수 있습니다.

    tcpdump 또는 진단 번들 로깅을 확인하면 들어오는 ARP 요청이 관찰되고 대기 Edge가 포트 차단으로 인해 응답하지 않습니다.

    고급 HA에서 Edge가 대기 역할을 가정하는 경우 다음 이벤트가 다음 순서로 발생해야 합니다.

    1. 대기 Edge는 모든 포트를 차단합니다.

    2. 그런 다음, 대기 Edge는 향상된 HA에 배포되었음을 감지하고 트래픽을 전달하기 위해 WAN 포트를 차단 해제합니다.

    이 문제가 발생하면 이벤트 1에서 초기 포트 차단을 완료하는 데 예기치 않게 긴 시간이 걸리고 후속 이벤트 2에서 이벤트 1이 완료되기 전에 모든 WAN 포트의 차단 해제가 완료됩니다. 그런 다음, 이벤트 1이 완료되므로 최종 상태는 대기 Edge에서 모든 WAN 포트가 차단된 상태입니다.

    이 문제에 대한 수정 사항을 적용하지 않은 HA Edge에서 해결 방법은 대기 Edge를 [활성(Active)]으로 승격하는 HA 페일오버를 강제로 수행하여 HA Edge의 WAN 링크를 작동하는 것입니다.

  • 해결된 문제 100089: VMware SD-WAN Edge OSPF/BGP 인접 항목에서 예기치 않은 경로가 발견되었습니다.

    vce1/gwd1(169.254.129.x)에 해당하는 내부 관리 경로는 SD-WAN Edge에 의해 BGP/OSPF로 재배포되고 SD-WAN Edge에 연결된 해당 OSPF/BGP 인접 항목에서 수신됩니다.

  • 해결된 문제 101049: 고객 엔터프라이즈가 보안 경로와 비보안 경로를 모두 사용하는 경우 높은 경로 손실이 발견될 수 있습니다.

    보안 경로와 비보안 경로를 모두 사용하는 예시로는 파트너 게이트웨이가 사용되고 SD-WAN Edge가 BGP 인접 항목(비보안)의 서브넷을 학습한 다음, SD-WAN Edge가 네트워크의 다른 SD-WAN Edge(보안)에서 동일한 서브넷을 학습하는 경우가 있습니다. 보안 경로가 선호되지만 보안 경로가 해지된 경우 트래픽이 비보안 경로로 전환되지 않습니다. 이 문제는 Edge 서비스가 적절한 라우팅을 담당하는 관리 터널의 순서를 지정하지 않은 경우에 발생했습니다.

Edge 버전 R451-20220916-GA에서 해결됨

Edge 버전 R451-20220916-GA는 2022년 9월 22일에 릴리스되었으며 2번째 릴리스 4.5.1용 Edge 롤업입니다.

이 Edge 롤업 빌드는 첫 번째 Edge 롤업 빌드, 버전 R451-20220701-GA 이후의 아래와 같은 중요한 문제를 해결합니다.

  • 해결된 문제 86098: 대기 Edge에서 PPPoE WAN 링크가 사용되는 고급 고가용성 토폴로지를 사용하는 사이트의 경우 기본 프록시 경로가 활성 Edge에 설치되어 있지 않고 해당 링크를 사용하는 트래픽이 실패할 수 있습니다.

    고급 HA Edge 쌍이 실행되면 PPPoE 링크가 대기 Edge와 동기화하고 다음 홉인 0.0.0.0이 포함된 기본 경로를 제공합니다. 그에 따라 이 경로가 활성에 설치되지 않고 이 링크를 사용하는 트래픽이 삭제됩니다.

  • 해결된 문제 93383: VMware SD-WAN Edge에서 고객 트래픽 중단으로 인해 하나 이상의 데이터부 서비스 장애가 발생할 수 있습니다.

    이 문제는 두 개의 서로 다른 데이터 구조의 Edge에 저장된 인터페이스가 일치하지 않는 드문 상황으로 인해 발생하고, 그에 따라 예외가 트리거되고 Edge 서비스에서 여러 차례 장애가 발생합니다. 복구를 위해 Edge 서비스를 다시 시작해야 하고, HA가 아닌 배포에서 고객 트래픽이 10~15초 동안 중단됩니다. 하지만 Edge 서비스가 세 번 연속으로 실패하는 경우 Edge를 복구하려면 재부팅 또는 전원 주기가 필요합니다.

  • 해결된 문제 94204: VMware SD-WAN Edge에 대한 진단 번들을 생성하려는 시도가 실패합니다.

    Edge의 디스크 공간이 부족하기 때문에 Edge 진단 번들을 완료하지 못합니다. 이 문제는 Edge가 하나 이상의 코어를 생성하는 경우 발생할 수 있고, Edge가 이러한 코어를 /vnf/tmp 폴더로 전송하기 때문에 발생합니다. 각 코어는 /vnf/tmp 폴더에 압축 해제되고, 압축 해제된 코어의 크기가 이 폴더를 빠르게 채워 진단 번들에 장애가 발생합니다.

  • 해결된 문제 94395: 고가용성 토폴로지로 배포된 사이트에서 활성 Edge가 실패한 후 대기 Edge가 활성 상태로 전환되지 않아 고객 트래픽이 중단되면서 HA 페일오버가 실패할 수 있습니다.

    이 문제는 둘 이상의 HA Edge 쌍이 동일한 업스트림 WAN 스위치 또는 브로드캐스트 네트워크에 연결된 경우에 발생할 수 있습니다. 이 시나리오에서 HA Edge는 비피어 HA WAN 하트비트를 처리할 수 있으며, 이로 인해 로컬 HA 상태에 영향을 미치고 대기 Edge가 활성으로 승격되지 않는 것을 비롯한 신뢰할 수 없는 HA 동작이 발생합니다.

    이 문제에 대한 수정 사항이 없는 HA 쌍에서 이 문제의 해결 방법은 서로 다른 두 HA 쌍 간에 동일한 브로드캐스트 네트워크를 공유하지 않는 것입니다.

  • 해결된 문제 95565: 고가용성 토폴로지를 사용하는 사이트에서 VMware SD-WAN 활성 Edge에서 코어가 생성되고 고가용성 페일오버가 트리거되면서 데이터부 서비스 장애가 발생할 수 있습니다.

    이 문제는 SNMP 쿼리가 빈번한 SNMP를 사용하는 동안 활성 Edge의 WAN 링크가 한 번 이상 플래핑(종료되었다가 빠르게 실행)되면서 트리거됩니다. 인터페이스가 다시 실행되고 SNMP 쿼리가 교착 상태를 트리거하여 데이터부 서비스가 실패하고 코어를 생성할 수 있는 타이밍 문제가 있습니다. 단일 WAN 링크 플래핑만 이 문제를 유발할 수 있지만 WAN 링크 플래핑의 빈도가 높을수록 이 문제가 발생할 가능성이 높을 수 있습니다.

    이 문제가 발생하고 수정 사항이 적용되지 않은 HA Edge 쌍에서 해결 방법은 타이밍 문제이므로 SNMP를 사용하지 않도록 설정하는 것입니다. 이렇게 하면 위험이 줄어듭니다.

  • 해결된 문제 96441: 고가용성 토폴로지를 사용하는 사이트에서 HA 페일오버가 자주 발생할 수 있습니다.

    이 문제는 Edge에서 HA 인터페이스를 종료 상태로 표시한 다음 500~1000ms 내에 다시 실행하면서 HA 페일오버가 트리거될 수 있기 때문에 발생합니다. 하지만 이러한 인터페이스 종료 이벤트는 허위이며 인터페이스 상태를 확인하기 위해 500ms 간격의 폴링을 사용하는 DPDK 사용 설정 인터페이스로 인해 발생합니다. 이 방법을 사용하면 기본 디바이스 드라이버가 가상 인터페이스 종료 이벤트를 보고할 수 있고, 각 이벤트로 인해 인터페이스 상태(500ms)의 다음 폴링에서 인터페이스를 실행 중이라고 보고할 때까지 Edge가 인터페이스를 종료된 것으로 표시할 수 있습니다.

  • 해결된 문제 96888: 특정 로드 조건에서 BGP 또는 OSPF에 대한 라우팅 프로토콜이 임의로 다시 시작되어 경로 재수렴 및 트래픽 중단이 발생할 수 있습니다.

    로드 조건이 높을수록 Edge CPU가 스케줄링하기 위해 BGP 및 OSPF 라우팅 프로토콜 프로세스가 예상보다 오래 대기하게 되며, 이로 인해 라우팅 프로토콜이 중지되었다가 다시 시작됩니다. 라우팅 프로토콜 지연은 CPU 대역폭 할당이 부족하기 때문에 발생하며 모든 Edge 모델에서 발생할 수 있습니다.

Edge/게이트웨이 버전 R451-20220701-GA에서 해결됨

Edge/게이트웨이 버전 R451-20220701-GA는 2022년 7월 8일에 릴리스되었으며 첫 번째 릴리스 4.5.1용 Edge/게이트웨이 롤업입니다.

이 Edge/게이트웨이 롤업 빌드는 원래의 4.5.1 Edge/게이트웨이 GA 빌드, 버전 R451-20220513-GA 이후의 아래와 같은 중요한 문제를 해결합니다.

  • 해결된 문제 64196: 아웃바운드 필터가 있는 하나 이상의 BGP 정책이 구성된 VMware SD-WAN Edge의 경우 아웃바운드 필터에 대한 구성을 변경하면 경로가 플래핑되고 아웃바운드 필터가 고객 트래픽 중단에 맞지 않게 적용될 수 있습니다.

    구성은 기존 필터를 수정하거나 새 아웃바운드 필터를 추가하여 변경할 수 있습니다. 이 문제가 발생하면 모든 경로가 애드버타이즈되도록 구성될 때 모든 경로를 거부하는 아웃바운드 필터가 적용된 BGP 정책을 사용하는 BGP 인접 항목이 발견될 수 있으며 이로 인해 상당한 고객 트래픽 문제가 발생합니다. 이 문제는 구성 변경으로 인해 업데이트되는 맵과 달리, 오래된 경로 맵과 관련된 BGP 인접 항목으로 인해 발생합니다.

    이 문제에 대한 수정 사항이 없는 Edge에서 원격 작업 > 서비스 다시 시작을 사용하여 Orchestrator를 통해 Edge 서비스를 다시 시작하면 다시 시작한 후에 모든 경로가 복원됩니다.

  • 해결된 문제 78568: BGP를 사용하고 VMware SD-WAN 파트너 게이트웨이에 연결된 고객의 경우 해당 서브넷의 애드버타이즈 플래그가 False로 설정된 후 파트너 게이트웨이가 VMware SD-WAN Edge의 VLAN 서브넷을 계속해서 애드버타이즈할 수 있습니다.

    Edge가 L3 BGP 인접 항목과의 BGP 인접 항목 인접 상태를 중단하면 연결된 파트너 게이트웨이 중 하나가 Edge VLAN 서브넷의 소유권을 유지하기 때문에 경로가 계속 애드버타이즈됩니다. 파트너 게이트웨이의 오래된 경로는 고객 트래픽에 부정적인 영향을 미치며 트래픽이 현재 존재하지 않는 경로로 라우팅되도록 할 수 있으므로 전체 고객 흐름이 삭제될 수 있습니다.

    이 수정 사항을 적용하지 않을 경우 문제를 해결하고 오래된 BGP 경로를 지우는 유일한 방법은 파트너 또는 운영자가 적절한 유지 보수 기간에 파트너 게이트웨이 서비스를 다시 시작하는 것입니다.

  • 해결된 문제 83083: 릴리스 4.3.1 이상으로 업그레이드된 VMware SD-WAN Gateway에서 천천히 진행되는 메모리 누수로 인해 게이트웨이 서비스가 다시 시작되고 메모리가 지워질 수 있습니다.

    게이트웨이 다시 시작은 게이트웨이 서비스가 다시 시작하는 데 소요되는 30~45초 동안 고객 트래픽이 중단될 수 있습니다. 운영자 사용자가 게이트웨이에서 debug.py --flow_dump all all all 명령을 실행할 때마다 게이트웨이에 일부 메모리가 누수됩니다. 이 디버그 명령을 충분한 횟수만큼 실행하면 게이트웨이의 메모리 사용량이 위험 수준에 도달하고 게이트웨이 서비스 다시 시작을 트리거하여 메모리를 지웁니다.

    이 수정 사항을 적용하지 않은 게이트웨이의 경우 운영자는 게이트웨이에서 debug.py --flow_dump all all all 명령을 실행하지 않아야 합니다. 이 디버그 명령의 사용을 피할 수 없는 경우 메모리 사용량을 모니터링하고 유지 보수 기간을 스케줄링하여 예약되지 않은 다시 시작 전에 서비스를 선점적으로 다시 시작하여 메모리를 지웁니다.

  • 해결된 문제 85369: 고가용성 토폴로지를 사용하여 배포된 사이트의 경우 트래픽이 중단되고 VMware SD-WAN 대기 Edge가 여러 차례 재부팅될 수 있습니다.

    로드 및 시스템 이벤트에 의해 트리거된 조건으로 인해 활성 Edge에서 대기 Edge로의 HA 하트비트 적시 전달에서 지연이 발생합니다. 지연으로 인해 대기 Edge가 하트비트를 누락하고 활성 역할이 활성-활성 상태를 유발하는 것으로 잘못 가정합니다. 활성-활성 상태에서 복구하기 위해 대기 Edge가 여러 번 재부팅될 수 있습니다.

    사이트가 활성-활성 상태가 되는 경우 대기 Edge가 이 토폴로지에서 트래픽을 전달하지 않으므로 기존 HA 설정에서는 최소한의 트래픽 중단만 발생하지만 대기 Edge가 트래픽도 전달하는 고급 HA 배포에서는 재부팅으로 인해 일부 고객 트래픽이 중단될 수 있습니다.

  • 해결된 문제 85461: VMware SD-WAN Edge가 DNS를 전달하는 데 사용되고 Edge에 연결된 LAN 디바이스가 DNS 전달에 Edge를 사용하는 경우 모든 DNS 트래픽이 실패할 수 있습니다.

    조건부 DNS뿐만 아니라 모든 DNS 전달 트래픽이 영향을 받습니다. Edge 소프트웨어에 따라 다음과 같이 Edge에서 이 문제가 발생할 수 있습니다.

    • Edge가 릴리스 4.2.2를 사용하는 경우 Edge에서 게이트웨이 IP 주소가 지정되지 않은 라우팅된 LAN 포트를 사용하면 이 문제가 발생할 수 있습니다. 전환된 LAN 포트 + VLAN은 4.2.2에서 영향을 받지 않습니다.

    • Edge가 릴리스 4.3.0/4.3.1, 4.5.0/4.5.1 또는 5.0.0.x를 사용하는 경우 전환된 LAN 포트 및 VLAN을 사용하거나 게이트웨이 IP 주소가 지정되지 않은 라우팅된 LAN 포트를 사용하면 문제가 발생할 수 있습니다.

    전환된 인터페이스의 경우 이 문제는 릴리스 4.3.x, 4.5.x 및 5.0.0.x 이상의 루프백 인터페이스를 위해 관리 IP 인터페이스를 사용 중단하고 제거하기 때문에 발생합니다. DNS는 세그먼트 NAT를 사용하기 때문에 Edge가 세그먼트 NAT 테이블 조회를 수행하고 패킷을 삭제할 때 DNS 패킷에 대상 IP와 일치하는 항목이 없습니다.

    라우팅된 인터페이스의 경우 게이트웨이 IP가 없다는 것은 DNS 패킷이 다음 홉으로서 Edge로 라우팅되고 Edge가 DNS 패킷을 더 이상 전달하지 않음을 의미합니다.

    이 문제에 대한 수정 사항을 적용하지 않을 경우 이 문제의 해결 방법은 DNS를 전달할 때 Edge를 사용하지 않거나 또는 다음과 같습니다.

    • Edge 릴리스 4.2.2를 사용하는 경우: 전환된 LAN 포트 또는 게이트웨이 IP 주소가 포함된 라우팅된 LAN 포트를 사용합니다.

    • 릴리스 4.3.x 또는 4.5.x를 사용하는 경우 게이트웨이 IP 주소가 지정된 라우팅된 LAN 포트만 사용합니다.

  • 해결된 문제 87304: VMware SD-WAN Edge의 LAN 인터페이스가 VMware SASE Orchestrator에서 비활성화된 경우에도 인터페이스가 SNMP에 의해 '실행 중'으로 보고됩니다.

    설명: 인터페이스 출력에 대한 키 디버그 프로세스에는 Edge LAN 인터페이스(예: GE1 또는 GE2)에 대한 물리적 포트 세부 정보가 포함되지 않습니다. 따라서 SNMP가 해당 인터페이스를 폴링할 때 인터페이스가 구성된 방식에 관계없이 항상 실행 중 결과를 반환합니다.

  • 해결된 문제 89627: Telegraf 서비스가 사용되는 VMware SD-WAN Gateway에서 사용자는 메모리 사용 증가량을 확인할 수 있습니다. 메모리 사용량이 이 수준에 도달하면 게이트웨이 서비스가 다시 시작되어 메모리가 지워질 수 있습니다.

    Telegraf가 사용되면 게이트웨이 서비스에서 메트릭 집합을 가져와 내보냅니다. 데이터 가져오기 작업 중에 소량의 메모리가 유출되고 메트릭을 저장하는 데 사용된 메모리가 해제되지 않습니다.

    이 수정 사항을 적용하지 않는 경우 해결 방법은 메모리 누수 방지를 위해 Telegraf 서비스를 종료하거나 게이트웨이의 메모리 사용량을 주의 깊게 모니터링하는 것입니다. 메모리 활용률이 60%에 도달하면 메모리를 지우기 위해 선점형 게이트웨이 서비스 다시 시작을 스케줄링합니다. 두 번째 해결 방법은 Telegraf를 계속 사용하는 동안 문제가 수정된 빌드로 게이트웨이를 업데이트할 때까지의 시간을 버는 것입니다.

  • 해결된 문제 89725: Edge 소프트웨어 릴리스 4.5.1 GA를 사용하는 VMware SD-WAN Edge의 경우 원격 진단 유틸리티 WAN 링크 대역폭 테스트 및 Traceroute가 작동하지 않습니다.

    WAN 링크 대역폭 테스트 및 Traceroute 유틸리티에는 인터페이스(BW 테스트의 경우) 또는 IP 주소(Traceroute의 경우)에 대한 추가 입력이 필요합니다. 이 문제가 발생하면 드롭다운 메뉴 옵션이 표시되지 않으므로 사용자가 해당 입력을 구성할 수 없게 됩니다. 따라서 두 인스턴스에서 모두 테스트하면 오류가 발생합니다.

  • 해결된 문제 89861: 사용자는 비즈니스 정책에 개체 그룹을 광범위하게 사용하는 VMware SD-WAN Edge에서 메모리 활용률이 일정하게 증가하는 것을 확인할 수 있습니다.

    비즈니스 정책에 개체 그룹을 사용하는 경우 Edge의 개체 그룹에 대해 완료된 모든 업데이트에서 주소 그룹과 관련된 Edge의 메모리 개체가 유출됩니다. 또한 이러한 개체 그룹 업데이트가 정기적으로 완료되는 경우(예: 스크립트 사용) 메모리 활용률은 위험 수준(90초 이상 동안 메모리 사용률 60%)에 도달할 때까지 지속적으로 증가하며 메모리 복구를 위해 Edge 서비스 다시 시작을 트리거합니다. 메모리를 지우기 위해 계획되지 않은 Edge 서비스를 다시 시작하면 고객 트래픽이 잠시 중단될 수 있습니다. 이러한 영향은 Edge 메모리 양이 더 적지만 충분히 긴 기간에 걸쳐 모든 Edge 모델이 위험 메모리 수준에 도달하고 다시 시작될 수 있는 초급 Edge 모델(예: 510, 610 또는 620)에서 더 일반적으로 발견됩니다.

    이 문제에 대한 수정 사항을 적용하지 않을 경우 해결 방법은 개체 그룹 업데이트의 빈도를 제한하거나, 불가능한 경우 메모리를 정기적으로 모니터링하고, 메모리 활용률이 40%에 도달하여 Orchestrator에서 메모리 주의 이벤트가 수신되면 유지 보수 기간 동안 Edge 서비스가 다시 시작되도록 스케줄링하여 메모리를 지우고 고객에게 미치는 영향을 최소화하는 것입니다.

  • 해결된 문제 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 필터를 식별하며, 지정된 엔터프라이즈 세그먼트 조합의 경우 PG-BGP 인접 항목이 하나만 있을 수 있기 때문입니다.

    그러나 이 방법은 동일한 엔터프라이즈 세그먼트 조합에 대해 최대 2개의 BGP 인접 항목(기본 및 보조)이 있을 수 있는 게이트웨이의 NSD-BGP에 대해 상속되었습니다. 따라서 enterprise_logical_id 및 segment_id 조합은 2개의 서로 다른 NSD-BGP 인접 항목의 필터를 구분하는 데 충분하지 않습니다.

  • 해결된 문제 90280: 고가용성 토폴로지로 배포되고 동적 Edge 간을 사용하도록 구성된 사이트에서 VMware SD-WAN HA Edge가 예기치 않게 페일오버될 수 있습니다.

    이 문제는 다른 Edge 사이에서 동적 터널 생성 및 삭제가 자주 발생하는 사이트에서 나타날 수 있습니다. 이러한 시나리오에서 Edge는 실행 중인 인터페이스 수를 잘못 판단하며 이로 인해 Edge 서비스가 모든 링크를 종료된 것으로 단정하고 HA 페일오버를 트리거할 수 있습니다.

  • 해결된 문제 91746: 유선 또는 무선 802.1x 인증(예: RADIUS, Cisco ISE)을 사용하는 VMware SD-WAN Edge는 Edge에서 이 인증 삭제가 필요한 모든 트래픽과 관련해서 인증서 인증 실패를 경험할 수 있습니다.

    이 문제는 Edge가 IP 조각화 패킷의 L4 헤더를 잘못 변경하여 Edge를 종료하기 전에 패킷이 손상되기 때문에 발생합니다. 이는 주로 UDP 패킷에 영향을 미치며 이러한 패킷이 802.1x 인증서 인증에 사용되면 802.1x 유선 또는 무선 클라이언트가 실패할 수 있습니다.

    해결 방법: 이 문제가 발생하는 Edge에서 해결 방법은 a) 802.1x 인증을 해제하거나 b) 이 문제가 없기 때문에 802.1x 인증이 제대로 작동했던 이전 Edge 소프트웨어 빌드로 Edge를 롤백하는 것입니다.

  • 해결된 문제 92216: VMware SD-WAN Edge가 지정된 터널 제한의 60%를 사용하고 있음을 나타내는 경고가 표시될 수 있습니다.

    Edge 터널에 대한 이 “소프트 한도 제한 경보”는 60%의 활용률에서는 실제 한도가 없으므로 고객에게 혼동을 줍니다. Edge 모델에 지정된 최대 터널 제한만이 유의미합니다. 모든 Edge 모델에 대한 Edge 터널 제한은 VMware SD-WAN Edge 플랫폼 규격 데이터 시트에서 찾을 수 있습니다. 최신 데이터시트에 대한 다운로드 링크는 VMware SD-WAN 하드웨어 가이드 페이지의 하단에 나와 있습니다.

Edge/게이트웨이 버전 R451-20220513-GA에서 해결됨

아래 문제는 Edge 버전 R450-20220413-GA 및 게이트웨이 버전 R450-20211123-GA-74198-70416-74482-30022 이후에 해결되었습니다.

참고:

릴리스 4.5.1에는 4.5.0 릴리스 정보에 나열된 모든 Edge 및 게이트웨이 수정 사항이 포함되어 있습니다.

  • 해결된 문제 35807: VMware SD-WAN Orchestrator에서 인터페이스를 해제했다가 다시 설정하면 DPDK의 라우팅된 인터페이스가 완전히 비활성화됩니다.

    라우팅된 포트를 비활성화하면 해당 네트워크 디바이스가 DPDK 제어 하드웨어에서 바인딩 해제되었다가 Linux 드라이버에 다시 바인딩되며 Edge 서비스가 다시 시작됩니다. /opt/vc/etc/dpdk.json 파일이 이 인터페이스를 제거하도록 업데이트되었으므로 다시 활성화하면 파일이 Linux에서 DPDK 제어 드라이버로 다시 바인딩 해제되도록 업데이트되지 않습니다.

    이 수정 사항을 적용하지 않을 경우 문제를 해결하는 유일한 방법은 Edge를 재부팅하여 상태를 지우고, 다시 기본 부팅 상태로 돌아가 디바이스를 Edge DPDK 계층에 다시 추가하는 것입니다.

  • 해결된 문제 48017: OSPF 및 BGP 경로가 OFC(오버레이 흐름 제어)에서 컨버전스하는 데 예상보다 시간이 오래 걸릴 수 있습니다.

    높은 로드에서는 VMware SD-WAN Edge에서 학습된 일부 또는 모든 경로가 OFC에 표시되지 않거나 필요한 애드버타이즈 및 기본 설정값이 할당되지 않을 수 있습니다(DCC(동적 비용 계산)가 사용되지 않음). 이로 인해 Edge가 VMware SD-WAN Orchestrator에 대한 이러한 경로의 동기화를 지속적으로 다시 시도하므로 Orchestrator의 로드가 추가로 증가할 수 있습니다.

  • 해결된 문제 49787: VMware SD-WAN Orchestrator UI에서 VMware SD-WAN Edge에 대한 [원격 진단(Remote Diagnostics)] 페이지로 이동하는 사용자가 요청을 처리하는 UI를 볼 수 있지만 Edge의 진단 페이지가 로드되지 않습니다.

    이 문제는 인증서가 사용되지 않는 Edge에 대해 발생할 수 있으며, Edge가 인증서를 반복적으로 갱신하여 VMware SD-WAN Edge의 연결이 지속적으로 재설정되기 때문에 발생할 수 있습니다.

  • 해결된 문제 51036: Edge 인터페이스가 DPDK를 사용하도록 구성된 경우 SNMP를 통해 VMware SD-WAN Edge를 폴링할 때 상태가 잘못된 값을 보고합니다.

    이것은 하드웨어 및 가상 Edge의 DPDK 구성 포트에 대해 예상되는 동작입니다. DPDK로 구성된 포트에 대한 속도 값을 얻을 수 있는 유일한 방법은 "debug.py --dpdk_ports" 명령을 사용하는 것입니다. Edge의 SNMP 모듈은 DPDK 구성 포트의 속도 값을 추출하는 데 이 명령을 사용하지 않습니다. SNMP는 Edge의 Linux 커널 인터페이스를 통해서만 쿼리하며 이 경우 dpdk_ports에 대한 속도 값이 채워지지 않습니다. 이 문제에 대한 수정 사항이 있는 Edge 빌드에서 SNMP는 명령 "debug.py --dpdk_ports"를 사용하여 DPDK 구성 포트에 대한 통계를 수집합니다.

  • 해결된 문제 53243: 게이트웨이가 2단계 SA(보안 연결)를 삭제하지 못하기 때문에 Check Point 유형을 사용하는 NSD(비 SD-WAN 대상)로의 트래픽이 중단될 수 있습니다.

    SA 측면에서 피어가 동기화되지 못하고 SA가 만료될 때까지 링크가 다운될 수 있습니다. Check Point 방화벽 유형을 사용하는 NSD에서 링크가 안정적이지 않은 경우 피어가 삭제 알림을 보내지만 게이트웨이가 2단계 SA를 삭제할 수 없는 상황이 발생할 가능성이 있습니다. 해당 1단계 SA가 이미 삭제되어 있기 때문입니다.

  • 해결된 문제 54846: VMware SD-WAN SNMP MIB는 지터, 지연 시간, 패킷 손실에 관한 카운터를 사용합니다.

    VMware SNMP MIB에서 지연 시간, 지터, 패킷 손실은 이러한 유형에 적합하지 않은 Counter64로 정의됩니다. 카운터는 값이 계속 증가하며 바이트 Tx/Rx와 같이 SNMP에서 재설정되지 않는 데이터 유형에 사용해야 합니다. 반면에 지연 시간, 지터, 패킷 손실은 값이 증가하지 않지만 동적으로 조정되므로 카운터를 사용하지 않는 것이 좋습니다.

  • 해결된 문제 55327: Edge에서 게이트웨이로의 터널이 지속적으로 플래핑되면 VMware SD-WAN Gateway에서 VMware SD-WAN Edge로의 SSH 연결이 작동하지 않을 수 있습니다.

    Edge에서 게이트웨이로의 터널이 계속 플래핑되면 게이트웨이에서의 SSH 연결을 허용하기 위해 Edge에 설치된 경로 항목이 삭제되어 SSH 연결이 실패할 수 있습니다.

  • 해결된 문제 57011: 고가용성 토폴로지로 구성된 사이트의 경우 해당 사이트에서 세그먼트를 추가했다가 삭제할 때마다 HA Edge 중 하나에서 데이터부 서비스 장애가 발생하며, 활성 Edge에 서비스 장애가 있는 경우 사이트에서 HA 페일오버도 발생합니다.

    세그먼트를 추가한 다음, HA 사이트에서 삭제하면 부실 세그먼트가 발생할 수 있습니다(예: 삭제된 세그먼트가 HA 쌍의 Edge 중 하나에 계속 표시될 수 있습니다). HA Edge 간의 세그먼트 정보 불일치로 인해, 부실 세그먼트에 대한 모든 이벤트가 다른 Edge로 전송되면서 데이터부 서비스 장애가 발생하고, 활성 Edge에서 서비스 장애가 발생할 경우 HA 페일오버가 발생할 수 있으며, 페일오버 후 생성되는 진단 번들에서 확인되는 코어 덤프가 생성될 수 있습니다.

  • 해결된 문제 58759: 원격 클라우드 위치에서 VMware SD-WAN Edge의 WAN 인터페이스로의 SNMP walk가 시간 초과됩니다.

    동일한 WAN 인터페이스의 Ping은 예상대로 작동합니다. 잘못된 조절 정책이 해당 패킷에 적용되기 때문에 SNMP 응답 패킷이 Edge에서 삭제됩니다.

  • 해결된 문제 65186: 여러 WAN 링크를 사용하는 고객 사이트의 경우 기본 설정 또는 필수 정책에 따라 하나의 링크를 사용하도록 구성된 비즈니스 정책이 있으면 비즈니스 정책이 적용되는 트래픽 유형은 사용 가능한 모든 링크에서 계속 로드 밸런싱됩니다.

    필수 또는 기본 구성을 사용하여 트래픽을 하나의 WAN 링크로 라우팅하도록 비즈니스 정책이 구성되어 있더라도 트래픽은 여러 WAN 링크에서 로드 밸런싱됩니다.

  • 해결된 문제 66325: BGP 학습 경로와 일치해야 하는 고객 트래픽은 대신 고객 트래픽을 중단시킬 가능성이 있는 비즈니스 정책과 일치합니다.

    고객 엔터프라이즈가 소스를 라우팅된 클라이언트의 IP로 구성하고 대상을 인터넷으로 구성하는 비즈니스 정책을 사용하는 경우 BGP 학습 경로와 일치해야 하는 트래픽은 대신, 해당 정책에 대한 트래픽 분류를 포함하는 비즈니스 정책을 사용하므로(예: 실시간) 고객 트래픽이 중단될 수 있습니다.

  • 해결된 문제 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 서비스를 다시 시작해야 합니다.

  • 해결된 문제 67745: 일부 ISP 제공 라우터와의 WAN 링크가 있는 VMware SD-WAN Edge에서 해당 ISP 경로가 종료되었다가 다시 실행되면 고객 트래픽 문제가 발생할 수 있습니다.

    Edge에서 일부 ISP 라우터로의 WAN 링크(이 문제는 Spectum에서 사용하는 ISP 라우터에서 발견됨)가 종료되거나 ISP 라우터가 종료되었다가 다시 실행되면 ISP 라우터는 서브넷 192.168.100.0/24의 Edge에 개인 IP를 할당하는 내용을 포함하는 진단을 수행한 후, 공용 IP 주소를 할당합니다. 그러나 Edge는 192.168.100.0/0에 대한 연결된 경로를 설치하며, 공용 IP 주소를 가져온 후 이 경로는 삭제되지 않습니다.

  • 해결된 문제 67889: 여러 VMware SD-WAN Edge를 폴링하는 고객의 경우 SNMPv3 폴링이 제대로 작동하지 않을 수 있습니다.

    여기서 문제는 VMware SD-WAN에서 해당 SNMP 프로세스(snmpd)가 각 Edge에 대해 임의의 engine_id를 생성하도록 허용하며, 대부분의 경우 이 engine-id가 여러 Edge에 대해 중복된다는 것입니다. 이 경우 동일한 engine-id를 가진 Edge 중 하나가 수집기에 통계를 다시 보고하지 않습니다.

  • 해결된 문제 68044: VNF를 사용하는 VMware SD-WAN Edge에서 데이터부 서비스 장애가 발생하고 다시 시작될 수 있습니다.

    트래픽이 VNF를 통해 전달되는지 여부를 모니터링하기 위해 Edge 프로세스는 정기적인 GARP(Gratuitous ARP)를 전송합니다. Edge가 VNF 구성을 업데이트할 때 동시에 GARP 타이머가 실행되면 메모리 손상이 발생할 수 있습니다.

  • 해결된 문제 68224: VMware SD-WAN Edge에서 대규모로 PE(제공자 Edge)의 경로를 제거할 때 데이터부 서비스 오류가 발생하고 다시 시작될 수 있습니다.

    100K 이상의 경로일 때 대규모로 정의됩니다. 이 문제는 한 스레드가 경로 테이블 잠금을 얻기 위해 너무 오래 기다려야 하고, 뮤텍스 모니터가 문제 해결을 위해 서비스를 다시 시작하여 데이터부 서비스 장애를 유발할 때 발생합니다. 이 문제는 BGP 재배포 해시 테이블 조회를 시도하는 동안 다른 스레드가 경로 테이블 잠금을 유지하고, 이 프로세스가 지정된 시간보다 오래 걸릴 때 발생합니다. 해시 프로세스가 노드를 균등하게 분산시키지 않으므로 과도한 해시 테이블 충돌을 유발하고, 조회를 수행할 때 연결된 목록 검색이 수행되기 때문에 이 프로세스가 너무 오래 걸립니다.

  • 해결된 문제 68785: DHCP INFORM 패킷이 DHCP 릴레이로 구성된 인터페이스에서 수신되면 VMware SD-WAN Edge 소프트웨어에 의해 삭제됩니다.

    DHCP 클라이언트는 IP 주소를 획득한 후 DHCP INFORM 메시지를 사용하여 DNS 서버 또는 게이트웨이 주소와 같은 추가 네트워크 정보를 요청할 수 있습니다. Edge가 릴레이 에이전트로 구성되면 이러한 INFORM 메시지가 DHCP 서버로 전달되어야 하지만 삭제됩니다.

  • 해결된 문제 68829: VMware SD-WAN Edge LTE 모델(즉, Edge 510-LTE 또는 Edge 610-LTE)의 경우 IPv6 경로가 해당 LTE 인터페이스를 통해 구성되지 않습니다.

    udp6 패킷은 0 체크섬과 함께 전송되어 다음 홉에서 삭제됩니다. 이로 인해 SD-WAN 관리 경로가 INIT 상태가 되었습니다. 올바른 동작은 udp6 패킷에 대한 체크섬을 채우는 것입니다.

  • 해결된 문제 68840: 고가용성 토폴로지를 사용하는 고객의 경우 SNMP 폴링이 VMware SD-WAN 대기 Edge에서 LAN 및 WAN 정보를 검색할 수 없습니다.

    HA SNMP GET의 경우 대기 LAN/WAN 수(vceHaStandbyLanItfNum 및 vceHaStandbyWanItfNum)가 부분적으로 표시되거나 전혀 표시되지 않습니다.

  • 해결된 문제 68923: BGP를 사용하는 고객 엔터프라이즈에서 설치된 기본 경로에 대한 연결 가능 상태가 'False'로 설정되어 있더라도 기본 경로가 BGP 피어에 재배포될 수 있습니다.

    Edge 인터페이스를 가리키는 VMware SD-WAN Edge에 고정 경로가 구성되어 있고 해당 BGP 피어가 Edge에서 기본 경로를 학습한 후 나중에 해당 인터페이스를 해제하여 해당 경로에 대한 연결 가능 플래그를 False로 변경해도 경로가 계속 애드버타이즈됩니다. 인터페이스가 종료되었기 때문에 재배포되지 않는 경로가 여기에 해당하지만, 인터페이스가 실행 중이고 경로 상태가 'True'로 표시되면 경로가 계속 재배포되지 않습니다. 두 인스턴스에서 원인은 Edge가 새 경로 상태를 반영하는 인터페이스 상태 변경 사항에서 경로를 다시 애드버타이즈하지 않기 때문입니다.

  • 해결된 문제 69462: VMware SD-WAN Gateway에서 학습된 PG(파트너 게이트웨이) 및 NAT 경로는 처음에 BGP를 통한 NSD(비 SD-WAN 대상)로 애드버타이즈되지 않습니다.

    경로는 고객 파트너 핸드오프에서 “보안 BGP 경로”를 전환한 후에 애드버타이즈됩니다. 파트너 게이트웨이 BGP가 NSD-BGP 이전에 표시될 때 NSD-BGP 구성이 redis 테이블을 다시 작성하여 redis 테이블에 추가된 일부 PG 경로가 생략되기 때문에 클라우드 경로가 재배포되지 않습니다. 이 수정 사항을 적용하면 redis 테이블이 이미 있는 경우 NSD-BGP가 테이블을 다시 작성하지 않게 됩니다.

  • 해결된 문제 69497: VMware SD-WAN MIB는 더 이상 유효한 개체가 아니더라도 vceLinkVpnState SNMP 개체를 표시합니다.

    VMware SD-WAN은 VMware SD-WAN Orchestrator에서 더 이상 구분된 VPN 상태를 표시하지 않지만 SNMP에서는 계속 노출합니다. 구체적으로 SNMP 수집기는 SNMP OID 1.3.6.1.4.1.45346.1.1.2.3.2.2.1.26을 폴링합니다. 이 폴링 작업은 더 이상 수행하면 안 됩니다.

  • 해결된 문제 69681: VMware SD-WAN Edge가 핫 대기 WAN 링크로 구성되고 SNMP 폴링도 사용하는 경우 SNMP 오류가 발생합니다.

    오류 메시지는 다음과 유사합니다.

    문제의 원인은 SNMP 경로 상태에 핫 대기 링크 상태가 포함되지 않기 때문이며, 이로 인해 오류 메시지를 포함하는 SNMP 문제가 발생합니다.

  • 해결된 문제 69724: 잘못된 패킷 길이로 인해 VMware SD-WAN Gateway에서 패킷 손실이 발생할 수 있습니다.

    패킷 파이프라인의 문제로 인해 패킷을 비보안으로 분류할 수 있으며 MTU 검사는 해당 분류를 기준으로 수행됩니다. 그러나 나중에 오버헤드가 더 많은 관리 터널을 통해 전송되므로 해당 크기가 링크 MTU보다 커지는 마지막 순간에 이 패킷이 삭제될 수 있습니다.

  • 해결된 문제 70041: VMware SD-WAN Gateway를 릴리스 4.3.0으로 업그레이드하는 파트너는 더 이상 게이트웨이의 VRF IP 주소를 ping할 수 없습니다.

    ping이 실패하면 route_drop 카운터가 증가합니다. 핸드오프 인터페이스에서 VRF IP 주소를 ping하는 작업이 4.5.0에서 제거되었으며 릴리스 4.5.1의 수정 사항을 통해 복원되었습니다.

  • 해결된 문제 70129: 대규모 VMware SD-WAN Gateway에서 사용하도록 syslog를 구성하면 /var/log 폴더가 짧은 시간 내에 syslog 로그 파일로 채워질 수 있습니다.

    일반적으로 ~100-150K 흐름과 ~50-100K NAT 항목이 있는 4K 이하의 피어 및 ~6K 이하의 터널이 있는 게이트웨이가 대규모로 인식됩니다. syslog.log 파일 크기가 3.2Gb보다 크게 유지되는 24시간 정도가 짧은 기간일 수 있습니다. 이 문제는 일부 NAT 로그가 다른 폴더로 전송되어야 하는 /var/log로 전송되기 때문에 발생합니다.

  • 해결된 문제 70154: 상태 저장 방화벽이 활성화된 고객 엔터프라이즈의 경우 사용자는 동일한 ICMP ID를 가진 분기 클라이언트 간에 양방향 ping을 전송할 때 패킷이 삭제되는 것을 볼 수 있습니다.

    분기 1의 클라이언트 A에서 분기 2의 클라이언트 B로 또는 그 반대로 ping을 시작하는 경우 ICMP ID가 동일하고, 시퀀스 번호 확인에 따라 여러 패킷 손실이 발생할 수 있는 경우 두 ping에 대한 ICMP 상태가 동일한 흐름 개체로 추적됩니다.

    이 수정 사항을 적용하지 않을 경우 해결 방법은 상태 저장 방화벽을 해제하거나 다른 ICMP ID를 사용하여 ping을 생성하는 것입니다.

  • 해결된 문제 70311: VMware SD-WAN Edge에 데이터부 서비스 장애가 발생하여 다시 시작될 수 있습니다.

    Edge 서비스를 다시 시작하는 동안 고객 트래픽이 15~30초 동안 중단됩니다. 이 문제는 일관되지 않게 발생하지만 이 문제가 발생하면 Edge가 IKE SA(보안 연결)를 해체합니다. 이 문제는 일반적으로 SA 타이머가 (VMware SD-WAN Orchestrator에 구성된 대로) 만료되는 경우나 사용자가 Orchestrator에서 IPSec 구성을 수정하는 경우에만 발생합니다.

  • 해결된 문제 70349: 드문 경우지만 NAT 트래픽이 VMware SD-WAN Gateway에서 더 이상 작동되지 않습니다.

    게이트웨이의 서비스를 다시 시작하면 조건이 지워집니다. 게이트웨이의 데이터부 프로세스에 대한 경합 조건으로 인해 게이트웨이가 natd(NAT 할당을 관리하는 게이트웨이의 데몬)와의 연결을 설정하지 못하여 게이트웨이가 NAT 항목을 할당하지 못할 수 있습니다. 이로 인해 게이트웨이를 통해 NAT된 모든 흐름이 실패합니다.

  • 해결된 문제 70438: NAT에 의존하는 트래픽이 있는 고객은 VMware SD-WAN Gateway가 릴리스 4.5.0으로 업그레이드되거나 4.5.0을 실행하는 동안 다시 시작될 때 이 트래픽이 중단될 수 있습니다.

    게이트웨이 시작 시 NAT 항목이 SEND_TO_WAN 방향의 흐름(fc->nat_tup)에 이미 캐시되어 있을 수 있지만 "gwd_cloud_read"에서 NAT 항목을 삭제하는 경합 조건이 있을 수 있습니다. NAT 항목이 삭제된 경우에도 흐름은 NAT를 적용하기 위해 캐시된 nat_tup을 사용합니다. 반면에 다른 흐름은 새 NAT 항목으로 할당된 동일한 소스 포트를 가져올 수 있습니다.

  • 해결된 문제 70586: VMware SD-WAN Edge의 라우팅된 인터페이스가 802.1x에 대해 구성된 경우(RADIUS 인증 사용), 해당 인터페이스에 연결된 클라이언트는 다른 인터페이스가 플래핑될 때마다(다시 말해 802.1x가 아닌 모든 인터페이스가 빠르게 연속해서 종료 및 시작됨) 자동으로 인증 해제되고, 클라이언트가 Edge 연결을 해제하고 다시 연결할 때까지 모든 트래픽이 삭제됩니다.

    Edge는 플래핑된 인터페이스가 실제로 802.1x 클라이언트가 인증된 인터페이스인지 확인하지 않기 때문에 모든 인터페이스 플래핑을 802.1x 인터페이스 플래핑으로 취급하고 그에 따라 작동합니다.

    이 수정 사항을 적용하지 않고 이 문제를 해결할 수 있는 유일한 방법은 클라이언트가 물리적으로 연결을 끊었다가 다시 연결하여 다시 인증되도록 하는 것입니다.

  • 해결된 문제 70590: 릴리스 4.3.0을 사용하여 VMware SD-WAN Gateway에서 진단 번들을 생성하려는 시도가 실패할 수 있습니다.

    릴리스 4.3.0을 실행하는 게이트웨이에서 생성된 진단 번들은 Orchestrator에 구성된 크기 제한을 초과하는 진단 번들로 인해 실패합니다. 시간이 지남에 따라 커지는 감사 로그로 인해 진단 번들이 과도하게 커집니다.

    이 수정 사항을 적용하지 않을 경우 게이트웨이에서 진단 번들을 성공적으로 생성하는 유일한 방법은 운영자 사용자가 게이트웨이에 로그인하는 것이며, Orchestrator에서 진단 번들을 트리거하기 전에 운영자 사용자는 게이트웨이의 /var/log/audit 디렉토리 아래에 있는 감사 로그 파일을 삭제해야 합니다.

  • 해결된 문제 70855: VMware SD-WAN Gateway는 VMware SD-WAN Orchestrator에서 시작된 트래픽을 삭제하며, 결과적으로 Orchestrator의 게이트웨이 구성 업데이트가 실패할 수 있습니다.

    게이트웨이 로드가 높으면(예: NAT 개체 개수가 800K 이하인 게이트웨이에서 160만 개 이하의 흐름) 시스템의 패킷 버퍼 수가 고갈되고 이로 인해 Orchestrator 트래픽이 게이트웨이에서 삭제되는 경우가 있습니다. 게이트웨이가 이 상태가 되면 패킷 버퍼를 사용할 수 있게 되어도 Orchestrator 트래픽이 항상 삭제됩니다.

    이 수정 사항을 적용하지 않을 경우 이 문제에 대한 유일한 해결 방법은 게이트웨이를 다시 시작하는 것입니다.

  • 해결된 문제 70919: Wi-Fi를 사용할 수 있는 릴리스 4.2.1 GA를 쓰는 VMware SD-WAN Edge 사용자는 Edge의 Wi-Fi에 연결하지 못하고 SSID가 브로드캐스트되지 않을 수 있습니다.

    Edge가 Wi-Fi를 브로드캐스트하지 않는 경우 로그를 확인할 때 wlan0 인터페이스(Orchestrator UI의 WLAN1)가 감지되지 않습니다. 이것은 과도한 트래픽이 발생하는 Wi-Fi 카드의 펌웨어에서 예외가 발생하여 Wi-Fi가 실패하기 때문에 발생합니다.

    커널 로그에서 사용자는 다음과 유사한 메시지를 볼 수 있습니다:

    이 문제에 대한 업데이트 적용은 펌웨어 장애를 감지하고 Wi-Fi 커널 모듈을 다시 로드하는 스크립트입니다. 모듈 다시 로드의 일부로, 스크립트는 펌웨어를 다시 시작하고 사용할 디바이스를 준비하는 Wi-Fi 디바이스의 PCIe 재설정도 수행합니다. 장애 감지 및 후속 복구는 30~40초 정도 걸릴 수 있으며 이 시간 동안에는 Wi-Fi를 사용할 수 없습니다. 이것은 문제 발생을 방지하는 완전한 수정이 아니라 방어적인 수정으로 이해되어야 합니다.

    이 스크립트가 없으면 Edge를 재부팅하거나 전원을 껐다 켜서 Wi-Fi를 복원해야 합니다.

  • 해결된 문제 70933: 구성 프로필이 마이그레이션되면 고가용성이 사용되는 VMware SD-WAN Edge를 여러 번 다시 시작할 수 있습니다.

    구성 프로필을 마이그레이션하는 중에는 디바이스 설정 구성만 대기 Edge에 즉시 동기화됩니다. 나머지 구성은 대기 Edge의 하트비트에 대한 응답으로만 동기화되어 있습니다. 대기 Edge에서 하트비트를 수신하기 전에 최신 구성을 적용하기 위해 활성 Edge가 다시 시작되면 활성 Edge와 대기 Edge 간에 구성 불일치가 발생하여 두 HA Edge의 구성을 동기화하기 위해 여러 Edge가 다시 시작될 수 있습니다.

  • 해결된 문제 70954: VMware SD-WAN Edge에 Zscaler CSS(클라우드 보안 서비스)에 대한 필수 링크로 구성된 비즈니스 정책이 있고 해당 필수 링크에 대한 인터페이스가 실패하는 경우 여러 데이터부 서비스 장애가 발생할 수 있습니다.

    Edge는 필수 인터페이스가 삭제될 때 Zscaler로의 트래픽을 삭제해야 하지만 서비스 장애가 발생합니다.

  • 해결된 문제 71052: VMware SD-WAN Gateway에 연결하는 고객 엔터프라이즈의 수가 285보다 크면 게이트웨이에서 데이터부 서비스 장애가 발생합니다.

    게이트웨이 릴리스 4.3.0부터 고객 엔터프라이즈 수준에서 패킷 및 흐름 관련 정보를 추적하기 위해 새 카운터를 추가하여 고객을 모니터링하는 게이트웨이의 기능이 향상되었습니다. 이 문제는 285개의 고객 엔터프라이즈 이후에 고객 엔터프라이즈에 초기화된 카운터 수가 고갈되고, 새 고객에 대한 카운터 초기화가 실패하여 게이트웨이의 데이터부 서비스 실패 및 서비스의 강제 다시 시작을 유발합니다.

  • 해결된 문제 71189: 릴리스 4.5.0에서 다운그레이드한 후 다시 4.5.0으로 업그레이드하면 VMware SASE Orchestrator가 IPv6 옵션을 사용하도록 설정할 때 라우팅된 인터페이스 구성을 저장하지 않습니다.

    4.5.0에서 다운그레이드했다가 다시 4.5.0으로 업그레이드한 후 IPv6 옵션을 사용하도록 설정하려고 하면 Orchestrator에서 "<인터페이스 이름>에 대해 IPv4 wanoverlay를 사용하지 않도록 설정한 경우 IPv6 wanoverlay를 사용하지 않도록 설정해야 함" 오류가 발생합니다.

    이 수정 사항을 적용하지 않을 경우 구성을 저장하기 전에 "WAN 오버레이 사용(Enable WAN Overlay)" 확인란을 선택했다가 선택 취소합니다.

  • 해결된 문제 71314: 고가용성 토폴로지가 있는 사이트에서 여러 HA 페일오버 이벤트가 확인되며 이로 인해 VMware SD-WAN Edge 서비스가 해제되어 고객 트래픽 품질에 영향을 미칠 수 있습니다.

    이 문제는 일관되지 않지만 일단 발생하면 HA Edge가 HA 프로세스와 인터페이스 상태 변경을 처리하는 프로세스 간에 교착 상태 문제가 발생하는 링크 플래핑으로 인한 분할 브레인 문제와 관련되어 있습니다. 교착 상태로 인해 데이터부 서비스에서 각 HA Edge에 대해 삼중 데이터부 서비스 장애가 발생하고(이로 인해 HA 페일오버 이벤트가 발생함) 데이터부 서비스가 해제됩니다. 데이터부 서비스가 사용하지 않도록 설정된 Edge는 관리 서비스가 작동 상태로 유지될 때 트래픽을 전달하고, 구성을 변경할 수 있습니다. 동적 다중 경로 최적화는 더 이상 사용되지 않습니다. 즉, 모든 트래픽이 클라우드로 직접 전송되므로 트래픽 우선 순위가 지정되지 않고, 링크 조절이 없고, 오류 수정이 수행되지 않으며, 취소될 때까지 높은 우선 순위의 고객 트래픽에 부정적인 영향을 미칩니다.

    이 수정 사항을 적용하지 않으면 원격 작업(Remote Actions) > Edge 재부팅(Reboot Edge)을 사용하여 결과적으로 HA 페일오버를 발생하면서 각 HA Edge의 데이터부 서비스를 복원할 수 있습니다.

  • 해결된 문제 71465: VMware SASE Orchestrator UI에서 게이트웨이를 통한 NSD(비 SD-WAN 대상)를 구성하는 경우 BGP의 UI에 BGP 설정을 구성할 때 IPv6 필터를 생성하는 옵션이 표시됩니다.

    주요 문제는 릴리스 4.5.x의 게이트웨이를 통한 NSD에 대해 IPv6이 지원되지 않는다는 것입니다. [BGP 편집기(BGP Editor)] 페이지는 Edge 및 프로필의 구성(Configure) > 디바이스 설정(Device Settings) 페이지의 BGP 구성, 구성(Configure) > 네트워크 서비스(Network Services) 페이지의 [게이트웨이를 통한 NSD(NSD via Gateway)], [구성(Configure)] > [고객(Customer)] 페이지의 [파트너 게이트웨이 전달(Partner Gateway Handoff)]에 공통적으로 표시됩니다. IPv6 변경은 Edge 또는 프로필의 구성(Configure) > 디바이스 설정(Device Settings) 페이지의 BGP 구성에 대해 수행되며, 이러한 변경은 지원되지 않는 [게이트웨이를 통한 NSD(NSD via Gateway)] 및 [파트너 게이트웨이 전달(Partner Gateway Handoff)] 페이지에 표시됩니다.

  • 해결된 문제 71720: 운영자 사용자가 사용하는 VMware SASE Orchestrator의 [게이트웨이 모니터링(Gateway Monitoring)] 페이지에 VMware SD-WAN Gateway에서 발생하는 핸드오프 대기열 손실 개수가 정확하게 표시되지 않을 수 있습니다.

    게이트웨이가 초과 구독되면 Orchestrator에 보고되고 해당 특정 게이트웨이에 대한 핸드오프 대기열 손실 개수(Handoff Queue Drops) 그래프의 UI 게이트웨이(Gateway) > 모니터링(Monitor) 페이지에 기록되어야 하기 때문에 전달 대기열이 삭제됩니다. 이 경우 게이트웨이는 여전히 Orchestrator에 핸드오프 대기열 손실 개수를 보고하지만 삭제 계정의 변경으로 인해 Orchestrator는 초과 용량 삭제를 보고하지 않으며 이로 인해 게이트웨이에서 용량이 삭제되더라도 핸드오프 대기열 손실 개수(Handoff Queue Drops) 그래프가 일관된 값 0을 표시합니다.

  • 해결된 문제 71785: 릴리스 4.3.0 이상을 실행하는 Edge에서 SNMP 워크가 제대로 작동하지 않을 수 있습니다.

    Edge가 릴리스 4.3.0으로 업그레이드되면 SNMP에서 사용하는 일부 IP가 차단되고, 포트 161에서 트래픽을 허용하도록 방화벽 설정을 변경해야 합니다.

  • 해결된 문제 71788: 고가용성 토폴로지로 배포된 고객의 경우 사이트에서 고객의 트래픽 중단을 포함하는 예기치 않은 HA 페일오버가 발생할 수 있습니다.

    이 문제는 간단히 재현할 수 없는 일관되지 않은 문제이지만 발생할 경우 HA Edge의 주기적인 처리기 스레드가 활성 및 대기 Edge 간의 흐름 동기화 중에 180ms 이상 실행되며, 이로 인해 교착 상태가 발생하고 활성 Edge의 뮤텍스 Mon 스레드에서 SIGKILL 메시지가 트리거되어 코어 및 Edge 재부팅이 발생합니다.

  • 해결된 문제 71977: VMware Edge Network Intelligence를 사용하는 고객의 경우 VMware SD-WAN Edge에 대해 분석(Analytics)을 사용하도록 설정하면 여러 데이터부 서비스가 실패하고 실패할 때마다 Edge 서비스가 다시 시작될 수 있습니다.

    이 문제는 사용자가 분석(Analytics)을 사용하도록 설정하고 Edge에서 동적으로 생성된 세션 수가 허용되는 최대 제한을 초과하는 경우에 트리거됩니다. 서비스 실패로 인해 고객 트래픽이 중단되고 3번 연속 실패가 발생하면 해당 Edge에서 데이터부 서비스가 종료됩니다. 고객 트래픽은 계속 통과되고 Orchestrator를 통해 Edge를 구성할 수 있지만 고객 트래픽은 DMPO(동적 다중 경로 최적화)의 혜택을 받지 못합니다. DMPO가 부족한 것은 트래픽 우선 순위 지정, 링크 조절 또는 오류 수정이 없기 때문에 고객 트래픽 품질이 저하될 수 있음을 의미합니다.

    데이터부 서비스를 복구하려면 사용자가 Edge를 재부팅해야 합니다. 이 작업은 원격 작업(Remote Actions) > Edge 재부팅(Reboot Edge)을 사용하여 Orchestrator를 통해 수행할 수 있지만 이로 인해 고객 트래픽이 추가로 2~3분 넘게 중단되므로 서비스 기간에만 수행해야 합니다.

  • 해결된 문제 72100: VMware SD-WAN Edge 610쌍이 해당 배포에 사용되는 향상된 고가용성 토폴로지를 사용하는 사이트에서 대기 Edge 610의 WAN 링크를 통해 터널이 설정되지 않습니다.

    이 문제는 대기 Edge를 통해 터널이 설정되지 않는 Edge 모델 610의 경우에만 표시됩니다. HA를 사용하도록 설정하기 전에 GE1 인터페이스의 VLAN에 IP 주소가 없는 경우 HA를 사용하도록 설정하면 SD-WAN 서비스가 하드웨어 스위치 포트를 GE1에 매핑하지 않습니다. 그 결과로 대기 Edge에서 패킷이 삭제됩니다.

    이 수정 사항을 적용하지 않을 경우 이 문제에 대한 해결 방법은 인터페이스 GE1이 하드웨어 스위치의 포트에 매핑되도록 VLAN에 IP 주소를 추가하는 것입니다.

  • 해결된 문제 72270: 고가용성으로 배포된 Edge의 경우 펌웨어 업그레이드도 포함하는 소프트웨어 업그레이드로 인해 HA Edge가 예기치 않게 업그레이드되고 재부팅되며, 고객 트래픽 중단과 OSPF 또는 BFD 경로 학습이 트리거될 수 있습니다.

    CPLD 펌웨어 업그레이드가 포함된 빌드로 업그레이드하는 Edge 3x00 모델의 경우도 마찬가지입니다. 기본적으로 대기 Edge가 먼저 업그레이드된 다음, 활성 Edge로 페일오버되므로 활성 Edge를 업그레이드할 수 있지만 활성 Edge는 페일오버를 대기하거나 페일오버가 없을 경우 업그레이드하기 전에 5분 동안 지연이 발생합니다. 또한 대기 Edge는 OS 커널을 포함하는 펌웨어를 업그레이드합니다. 이 작업은 5분 이상 걸릴 수 있으며, 대기 및 활성 Edge가 동시에 업그레이드되고 재부팅되고, 고객 트래픽이 중단되고 OSPF 또는 BFD 경로가 강제로 사용 가능하게 해제되는(자체적으로는 다른 작업에 지장을 초래함) 시나리오가 생성됩니다. 이 수정 사항은 한 번에 하나의 Edge만 업그레이드되도록 대기 타이머를 확장합니다.

  • 해결된 문제 72358: VMware SASE Orchestrator DNS 이름의 IP 주소가 변경되면 해당 Orchestrator에 연결된 각 VMware SD-WAN Gateway의 관리 서비스가 해당 주소를 올바르게 다시 확인하지 못합니다.

    게이트웨이의 관리 서비스는 Orchestrator DNS 이름의 DNS 확인을 주기적으로 수행하여 최근에 변경되었는지 여부와 최근에 변경되었다면 올바른 호스트에 연결할 수 있는지 검토합니다. 확인 코드에 문제가 있어서 이러한 모든 확인 검사가 실패하고 게이트웨이가 이전 주소를 계속 사용하게 됩니다.

    이 수정 사항을 적용하지 않으면 운영자는 Orchestrator의 IP 주소를 변경하지 않아야 하며, 변경해야 하는 경우 연결된 모든 게이트웨이를 재활성화해야 합니다.

  • 해결된 문제 72425: 사용자가 로컬 VMware SD-WAN Edge에서 수신된 경로를 볼 수 있더라도 OSPF 경로가 원격 사이트에 애드버타이즈되지 않습니다.

    이 문제는 OSPF NSM(Neighbor State Machine) 이벤트 및 경로 추가를 처리하는 동안 Edge의 경합 상태 때문에 발생합니다. 문제 상태에서는 Edge가 OSPF NSM 상태 이벤트를 처리하지 않았기 때문에 RIB(라우팅 정보 기반)에 OSPF 경로를 추가하는 동안 Edge에서 OSPF 인접 항목 정보를 알고 있는 것입니다. 이로 인해 Edge는 인접 항목 IP가 0인 OSPF 경로를 추가하게 됩니다. 인접 항목 IP가 0인 경우 Edge는 Orchestrator와 경로를 동기화하지 않거나 게이트웨이에 애드버타이즈하지 않으며 이로 인해 경로가 OFC(오버레이 흐름 제어) 또는 게이트웨이에 표시되지 않는 것입니다.

  • 해결된 문제 72498: VMware SD-WAN Edge가 사용 가능한 메모리 양이 적은 모델(예: Edge 510, 520, 610s)에서 점점 더 많은 양의 메모리를 사용하는 것을 확인할 수 있습니다. Edge가 서비스 다시 시작을 시작하여 메모리를 지우고 이로 인해 고객 트래픽이 5-10초 정도 중단될 수 있습니다.

    이 문제는 메모리 누수로 인해 발생합니다. 동적 Edge 간을 사용하도록 설정하고 Edge가 네트워크의 다른 Edge와 함께 많은 수의 터널을 동적으로 구축 및 해체하는 네트워크 배포에서, Edge는 오래된 IKE를 정리하여 터널을 해체하지 않으며 이로 인해 시간이 경과하면서 메모리 사용 속도가 느려지고 사용량이 줄어들어 Edge가 위험 수준에 도달할 수 있게 됩니다. 결과적으로 Edge 서비스가 다시 시작되어 메모리가 지워질 수 있습니다.

    이 수정 사항을 적용하지 않으면 사용자는 유지 보수 기간에 Edge 서비스를 미리 다시 시작하여 메모리를 지울 수 있습니다. 하지만 Edge 메모리가 천천히 다시 누수되기 시작합니다.

  • 해결된 문제 72567: 사용자가 fixed_link 비즈니스 정책을 통해 정방향 경로에서 언더레이(WAN 오버레이가 없는 MPLS)를 통해 비대칭 라우팅을 구성한 다음, 역방향 경로에서 오버레이(예: Hub Edge)를 통해 비대칭 라우팅을 의도적으로 구성하면 흐름이 중단되고 해당 흐름에 대한 트래픽이 실패합니다.

    이것은 Edge에 흐름을 언더레이 외부로 강제로 내보내는 비즈니스 정책이 있으므로 클라우드 흐름이 기본적으로 비대칭으로 라우팅(INTF_ROUTED)되는 경우에 해당합니다. 원격 Edge는 허브 Edge(오버레이)를 통해 응답을 다시 라우팅합니다. 원격 Edge는 흐름을 로컬에서 시작된 새로운 흐름으로 인식하고 QoS 동기화를 전송하여 흐름 라우팅 매개 변수를 업데이트합니다. 이로 인해 흐름 라우팅이 중단됩니다. 이 버그 수정에서는 구성된 link_mode를 덮어쓰지 않도록 QoS 동기화가 거부됩니다.

  • 해결된 문제 72688: VMware SD-WAN Edge가 데이터부 서비스를 임의로 다시 시작하며 다시 시작되면서 서비스가 중단됩니다.

    암호 해독 스레드에 고정된 패킷이 다른 암호 해독 스레드로 부동 상태가 되면 소유하지 않는 스레드에서 거부됩니다. 패킷을 거부하는 프로세스에서 연결된 QAT 암호화 참조가 잘못 해제되어 데이터부 서비스에서 예외가 발생하고 실패 및 다시 시작이 발생합니다.

  • 해결된 문제 72841: VMware SD-WAN Orchestrator에서 "게이트웨이 실행 중" 이벤트를 생성하는 데 일관성이 없습니다. 게이트웨이 상태가 오프라인(OFFLINE)에서 연결됨(CONNECTED)으로 변경될 때마다 "게이트웨이 실행 중" 이벤트가 모든 인스턴스에 기록되지 않습니다.

    이 문제는 일관되지 않게 발생하지만 이 문제가 발생하면 2개가 넘는 게이트웨이가 존재하며 두 게이트웨이 모두에 대해 updateStateChange가 동시에 트리거됩니다. 상태 변경이 동시에 발생하는 게이트웨이가 더 많이 있을수록 문제가 발생할 가능성이 더 높습니다.

  • 해결된 문제 72859: VMware SD-WAN Edge에서 데이터부 서비스 장애가 발생하고 결과적으로 다시 시작되어 고객 토폴로지에 따라 10~15초 동안 고객 트래픽이 중단되거나 고가용성 페일오버가 발생할 수 있습니다.

    이 문제는 Edge가 프로토콜이 정의되지 않았거나 예기치 않은 패킷 조각을 수신할 때 발생합니다. 이 경우 Edge는 패킷을 삭제하지만 패킷을 삭제하기 전에 Edge가 조회를 수행하고 Edge 서비스는 실제로 실패하더라도 이 조회가 항상 성공할 것으로 예상합니다. 이 조회가 실패하면 Edge 데이터부 서비스에서 문제가 트리거되며, 서비스가 실패한 후 다시 시도합니다. 이 문제는 실패한 패킷 조회 시 데이터부 서비스가 실패하지 않도록 하는 NULL 검사를 포함하여 해결되었습니다.

  • 해결된 문제 72925: 엔터프라이즈 모니터링을 위해 SNMP 폴링을 수행하고, 4.x 소프트웨어 릴리스를 실행하는 하위 모델 VMware SD-WAN Edge(예: Edge 모델 510, 520 또는 610)를 배포하는 고객의 경우 SNMP 폴링을 처리하는 데 예외적으로 오랜 시간이 소요되며 시간 초과될 수도 있습니다.

    이 문제가 발생하면 510, 5x0 및 6x0 시리즈에서 Edge를 사용할 때 네트워크 모니터링을 위한 SNMP 폴링의 효율성이 크게 줄어듭니다. 이 문제는 릴리스 4.x SNMP 에이전트가 디버그 명령 목록을 탐색하는 데 불필요하게 긴 시간이 소요되기 때문에 발생합니다. 이 작업은 SNMP 프로세스에 실제로 필요하지 않습니다.

  • 해결된 문제 72939: 사용자는 VMware SD-WAN Gateway의 부실 흐름 수가 해당 게이트웨이 규격에 대해 지원되는 최대 흐름 수에 도달할 때까지 지속적으로 증가하는 것을 볼 수 있으며, 따라서 해당 게이트웨이에 연결된 사용자를 중단시키는 새 흐름을 더 이상 생성하지 않습니다.

    증가하는 부실 흐름 수는 비 SD-WAN 대상에서 파트너 게이트웨이 핸드오프로 트래픽을 전송하는 사이트에 연결됩니다. "gw_nvs_to_pg_pkt" 및 "gw_send_nvs_pkt"라는 두 가지 함수가 추가되었습니다. 여기서 흐름 수는 조회 후에 해제되지 않습니다.

    이 수정 사항을 적용하지 않을 경우 유일한 해결 방법은 게이트웨이 서비스를 다시 시작하는 것입니다.

  • 해결된 문제 73251: RADIUS를 통해 인증해야 하는 사용자는 조각화된 트래픽이 VMware SD-WAN Edge에서 전송되지 못하기 때문에 인증을 받지 못할 수 있습니다.

    RADIUS 트래픽은 항상 조각화되며 이 문제는 무선 링크에서 인증을 시도하는 사용자에게 더 큰 영향을 미칩니다. 이 문제가 발생하면 조각화된 패킷 수가 영향을 받는 특정 인터페이스에서 DPDK가 처리할 수 있는 양을 초과하게 됩니다. 이 버그 수정은 트래픽 중단을 방지하기 위해 조각화 수를 사전에 재설정합니다.

  • 해결된 문제 73320: VMware SD-WAN Edge 인터페이스가 DHCP 주소 유형으로 구성되고 인터페이스에 할당된 IP 주소가 업데이트되면 NAT 실패로 인해 일부 직접 흐름이 실패할 수 있습니다.

    DHCP 리스가 만료되면 인터페이스에 대한 IP 주소가 제거됩니다. 새 IP가 인터페이스에 할당되기 전에 이 일시적인 시간 동안 새 흐름에 대한 NAT 항목이 "0.0.0.0"을 사용하여 소스 NAT IP로 생성되고 패킷이 삭제됩니다. 유효한 IP 주소가 인터페이스에 할당되면 기존 NAT 항목이 삭제되지 않고 유효한 IP로 새 NAT 항목이 생성되지 않아 트래픽이 삭제됩니다.

  • 해결된 문제 73830: SCCM(System Center Configuration Manager) 애플리케이션 트래픽이 VMware SD-WAN Edge에서 BITS(Business Intelligence Service) 트래픽으로 잘못 분류되고 있으며 SCCM 트래픽용으로 설계된 비즈니스 정책 또는 방화벽 규칙을 사용하는 고객은 해당 트래픽이 영향을 받는 것을 확인할 수 있습니다.

    Edge의 DPI(심층 패킷 검사) 엔진이 SCCM 애플리케이션 패킷을 BITS 트래픽으로 잘못 분류하고 있으며 해당 트래픽을 조절하거나 방화벽 규칙에서 트래픽을 허용하도록 설계한 비즈니스 정책 또는 방화벽 규칙이 있는 경우 SCCM 트래픽이 차단되어 고객 작업이 중단됩니다. 이 문제에 대한 수정 사항에서는 이러한 잘못된 분류가 방지되도록 기본 4.5.1 이상 애플리케이션 맵을 수정합니다.

  • 해결된 문제 73987: VMware SD-WAN Edge는 진단 번들을 생성하려고 하면 데이터부 서비스 장애가 발생할 수 있습니다.

    문제를 일으키는 진단 번들의 주요 부분은 Edge에 "vcdgbdump -r remote_routes"에 대한 로그가 필요한 경우입니다. 이 시나리오에서 많은 수의 원격 경로가 있고 해당 경로를 사용하는 트래픽이 실행 중이며 진단 번들 수집이 트리거되면 잠금 경합이 발생할 수 있습니다.

  • 해결된 문제 74225: VMware SD-WAN Gateway 또는 SD-WAN Edge에는 트래픽 문제가 발생하고 로그에 MAC 주소가 없는 패킷이 확인될 수 있습니다.

    게이트웨이 또는 Edge가 문제 #62552에 대한 수정 사항(00:00:00:00:00 MAC 주소를 사용하여 패킷을 전송하는 게이트웨이 또는 Edge 문제도 해결함)을 포함하는 빌드를 실행하더라도 게이트웨이/Edge 데이터부 프로세스 내에 소스 및/또는 대상 MAC 주소가 0인 패킷을 보낼 수 있는 위치가 있었습니다. 이러한 위치에서 ARP 상태 시스템은 소스 및 대상 MAC 주소의 유효성을 검사하지 않았습니다.

    이 문제가 발생할 것이라는 사실을 확실히 알 수 있는 유일한 방법은 0개의 MAC 주소, 특히 tcpdump를 사용하는 MAC 주소에 대한 로그를 확인하는 것입니다.

  • 해결된 문제 74306: VMware SD-WAN Edge 뒤에서 Skype 호출을 수행하면 예상보다 통화 품질이 저하될 수 있습니다.

    기본적으로 VMware SD-WAN 서비스는 호출 패킷을 포함하여 모든 Skype 및 MS Teams 패킷을 APP_CLASS_INTERNET_INSTANT_MESSAGING(10) 클래스로 분류합니다. 인스턴트 메시징 클래스의 우선 순위가 낮기 때문에 대역폭 및 링크 품질에 대한 호출이 영향을 받을 수 있습니다. 이 수정 사항은 Skype 및 MS Teams와 일치하는 패킷을 APP_CLASS_BUSINESS_COLLABORATION(5)으로 변경합니다. 즉, 호출 시 필요한 높은 우선 순위/실시간 품질 수준 처리가 수신됩니다.

    이 수정 사항을 적용하지 않을 경우 해결을 위해 Skype 및 MS Teams가 비즈니스 공동 작업으로 분류되도록 애플리케이션 맵을 사용자 지정해야 했습니다.

  • 해결된 문제 74316: Edge에 서비스 다시 시작 또는 전체 재부팅이 있더라도 VMware SD-WAN 스포크 Edge가 할당된 모든 또는 일부 허브 Edge 클러스터에 연결하지 못할 수 있습니다.

    특정 클러스터 멤버-슈퍼 게이트웨이 오버레이 플래핑 시나리오에서 클러스터 멤버의 끝점 정보 없이 클러스터 할당 매핑을 생성하는 클러스터 재할당 논리에 문제가 있습니다. 그 결과, 허브 클러스터 멤버에 할당된 스포크 Edge가 나중에 허브 클러스터 멤버의 끝점 정보를 수신하지 못하여 스포크 Edge와 허브 클러스터 간에 오버레이가 발생하지 않습니다.

    이 수정 사항을 적용하지 않을 경우 일시적으로 해당 조건을 수정하는 유일한 방법은 게이트웨이 액세스 권한이 있는 사람이 슈퍼 게이트웨이에서 클러스터 재할당을 수동으로 트리거하는 것입니다.

  • 해결된 문제 74446: 게이트웨이 핸드오프 대기열 삭제 카운터는 VMware SD-WAN Orchestrator UI에서 확인할 때 트래픽 스파이크를 식별하기 위한 용도로 사용되지 않습니다.

    게이트웨이 핸드오프 대기열 삭제가 충분히 세분화되지 않아 트래픽 스파이크를 식별할 수 없습니다. 이 문제에 대한 수정 사항은 새로운 워터마크 카운터 wmark_1min 및 wmark_5mins를 추가합니다. 이러한 워터마크는 각각 1분 및 5분 내에서 핸드오프 대기열의 최대 깊이를 제공합니다.

  • 해결된 문제 74450: VMware SD-WAN Orchestrator는 Telegraf 또는 Prometheus와 같은 외부 애플리케이션으로 워터마크 카운터를 내보내지 않습니다.

    이 티켓은 74446과 연결되며, 이 버그 수정은 게이트웨이 핸드오프 대기열 손실 개수에 대한 워터마크 카운터를 생성합니다. 이 티켓은 Telegraf 또는 Prometheus와 같은 애플리케이션에서 해당 메트릭을 수집할 수 있도록 합니다.

  • 해결된 문제 75117: 사용자는 진단 번들 로그를 참조하면 많은 수의 DNS 캐시 최대 제한에 도달함을 확인할 수 있습니다. 중요도가 더 높은 다른 로그 항목을 밀어내는 캐시 항목의 항목을 추가하지 못했습니다.

    VMware SD-WAN 하드웨어 Edge에서 DNS 쿼리가 32K를 초과하면 DNS 캐시 로깅이 연속적으로 발생하여 다른 로그 항목이 저장되지 못합니다. 이로 인해 사용자가 진단 번들에서 로그를 확인하여 다른 문제를 해결하는 데 방해가 됩니다.

  • 해결된 문제 75121: 고객이 백홀 흐름에 대해 연결할 수 없는 경로를 확인했으며 이로 인해 패킷이 삭제될 수 있습니다.

    백홀 및 인터페이스 흐름 경로 조회 코드에서 연결할 수 없는 경우에도 첫 번째 경로를 선택하는 문제가 발생했습니다. 이러한 연결할 수 없는 경로는 패킷을 잘 전송하지 못하기 때문에 패킷이 삭제되었습니다. 해결을 위해 모든 유형의 흐름에 대한 경로 연결 가능성을 확인해야 합니다.

  • 해결된 문제 75186: VMware SASE Orchestrator 또는 VMware SD-WAN Gateway에서 소프트웨어 결합을 설정하면 결합 인터페이스 MAC 주소가 시스템 전체에서 고유하지 않아 네트워크에서 MAC 주소 충돌이 발생할 수 있습니다.

    이 문제는 시스템이 소프트웨어 결합을 사용하도록 설정된 동일한 서브넷에 배포된 경우에만 발생합니다. 소프트웨어 결합 인터페이스의 MAC 주소는 /etc/machine-id에서 파생됩니다. 이 파일은 릴리스 4.2.1 이전의 Orchestrator 및 게이트웨이 버전에서 배포하는 동안에는 무작위로 지정되지 않습니다.

    Orchestrator 또는 게이트웨이와 4.2.1 이전의 소프트웨어 이미지에서 동일한 서브넷에 배포된 시스템에 대해 소프트웨어 결합을 사용하는 고객은 VMware 지원 팀에 문의하여 문제를 해결하십시오.

  • 해결된 문제 75309: 사용자는 VMware SD-WAN 스포크 Edge의 특정 그룹에 대한 멀티캐스트 트래픽 손실을 확인할 수 있습니다.

    트래픽이 허브 Edge에서 소싱된 경우 특정 그룹에 대한 멀티캐스트 트래픽이 스포크 Edge에서 수신되지 않습니다. IGMP 그룹이 스포크 Edge의 IGMP 그룹 테이블에 채워지지 않아 트래픽이 손실됩니다. 이 문제는 igmp에 대한 스포크 Edge의 진단 번들 로그에서 확인될 수 있습니다.

  • 해결된 문제 75578: 원격 진단 [인터페이스 상태(Interface Status)]를 실행하면 출력에 고가용성 지원 인터페이스의 속도 및 모드가 표시되지 않습니다.

    원격 진단의 인터페이스 상태에 HA 지원 인터페이스의 속도 및 모드가 표시되지 않습니다. 대부분의 Edge 플랫폼에서 두 Edge를 연결하는 HA 인터페이스는 일반적으로 GE1입니다.

  • 해결된 문제 75772: VMware SD-WAN Edge에서 분석(Analytics)이 활성 상태인 Edge Network Intelligence를 사용하는 고객의 경우 메모리 누수가 발생하며 이러한 메모리 누수를 지우기 위해 Edge가 다시 시작될 수 있습니다.

    분석(Analytics)을 사용하도록 설정하고 Edge 인터페이스에서 DHCP를 사용하도록 설정한 경우 클라이언트 연결 이벤트로 인해 메모리 사용량이 증가합니다. 충분한 기간 동안 메모리 사용량이 위험 임계값에 도달할 수 있으며 정상 메모리 수준을 복원하기 위해 Edge에서 Edge 서비스를 방어적으로 다시 시작할 수 있습니다. 메모리 누수 문제와 마찬가지로 초기 메모리 설치 공간이 작아질수록(예: Edge 510, 520 또는 610) Edge가 더 취약해져서 다시 시작되기 쉽습니다.

  • 해결된 문제 75827: VMware SD-WAN Gateway에 데이터부 서비스 장애가 발생하여 다시 시작될 수 있습니다.

    로그에서 de2e_info_reply_msg_recieved를 표시하는 게이트웨이 프로세스 실패를 확인할 수 있습니다. 근본 원인은 게이트웨이 프로세스에서 처리되지 않는 NULL 포인터 예외로, 이로 인해 예외가 트리거되고 서비스 장애가 발생하고 다시 시작됩니다.

  • 해결된 문제 75890: 이러한 허브 Edge와 스포크 Edge 간에 경로가 없는 경우에도 VMware SD-WAN 스포크 Edge의 루프백 IP 주소가 데이터 센터 허브 Edge를 통해 지역 허브 Edge에서 2분 정도 연결 가능한 것으로 표시됩니다.

    경로는 2분 동안 true로 유지되며 2분 후에는 피어에 연결할 수 없는 경로를 정리하는 과정의 일부로 정리됩니다. 이 문제는 루프백 IP 주소에서만 발생하며 이 시나리오에서는 다른 모든 스포크 Edge IP 주소가 False로 올바르게 표시됩니다.

  • 해결된 문제 75968: 사용자가 VMware SD-WAN Gateway에 대한 로컬 IP 주소 핸드오프을 구성한 다음, 해당 핸드오프을 제거하면 게이트웨이에서 핸드오프가 제거되지 않아 터널 경로가 종료됩니다.

    게이트웨이가 새 터널을 구축할 수 없기 때문에 이 문제로 인해 심각한 중단이 발생할 수 있습니다.

    이 수정 사항을 적용하지 않으면 사용자는 게이트웨이를 다시 시작하여 문제를 해결해야 합니다.

  • 해결된 문제 75989: VMware SD-WAN Gateway의 Telegraf 에이전트가 vcg_metrics.sh에서 수집된 메트릭을 내보내지 못할 수 있습니다.

    게이트웨이의 Telegraf 로그에 "vcgCommand timeout" 오류가 표시됩니다. 즉, 지정된 시간 초과 내에 스크립트를 실행할 수 없습니다.

  • 해결된 문제 75992: 일부 Edge가 3.4.x Edge 버전을 실행하고 다른 Edge가 4.3.x Edge 버전을 실행하는 여러 VMware SD-WAN Edge가 있는 고객 엔터프라이즈의 경우 서비스 및 트래픽 중단이 발생할 수 있습니다.

    게이트웨이 버전 4.3.0을 실행하는 VMware SD-WAN Gateway를 사용하고 3.4.x 및 4.3.x 버전을 혼합하여 실행하는 Edge를 사용하는 일부 고객 배포에서 3.4.x를 실행하는 Edge가 네트워크 주소는 0이 아니지만 마스크는 0인 일부 잘못된 경로로 확인되었습니다. 이러한 경로가 FIB에 설치되면 라우팅 문제가 발생합니다.

  • 해결된 문제 76005: VMware SD-WAN Edge에서 WAN 링크가 플래핑된 후 NAT 1:1 규칙이 적용되지 않을 수 있습니다.

    1:1 NAT 규칙 일치를 검색할 때 특정 인터페이스가 종료된 경우 Edge에서 건너뜁니다. 따라서 인터페이스가 종료된 후에 흐름이 생성되면 인터페이스가 실행된 후에도 Edge가 흐름을 수용하지 않습니다.

  • 해결된 문제 76165: VMware SD-WAN Edge에 데이터부 서비스 장애가 발생하여 다시 시작될 수 있습니다.

    Edge가 많은 수의 경로(예: ~20K 경로)가 있는 엔터프라이즈의 일부인 경우 진단 번들을 수집하면 로그를 생성하는 동안 Edge CPU가 고갈되고 CPU 고갈로 인해 서비스 실패가 발생할 수 있습니다.

  • 해결된 문제 76315: 운영자 사용자는 VMware SD-WAN Gateway가 전송하는 모든 흐름의 처음 일부 패킷을 삭제하는 것을 확인할 수 있습니다.

    삭제 이유는 gwrouting_vpn_unreachable로 표시됩니다. 이 문제는 관리 프로토콜의 QoS(서비스 품질) 동기화 메시지의 처리 지연으로 인해 발생하며, 모든 흐름의 처음 일부 패킷이 잘못 분류되고 삭제됩니다.

  • 해결된 문제 76564: 고가용성 토폴로지로 구성된 사이트의 경우 VMware SD-WAN Orchestrator UI를 사용하여 VMware SD-WAN Edge의 WAN 인터페이스를 사용하거나 사용하지 않도록 설정하면 고객 트래픽에 지장을 주는 "분할 브레인" 활성/활성 상태가 사이트에 발생할 수 있습니다.

    Edge의 WAN 설정이 변경되어 Edge의 네트워크 서비스가 다시 시작되면 Orchestrator가 활성 Edge를 종료된 것으로 잘못 인식하게 만드는 일시적인 HA 패킷 손실이 발생하여 활성/활성 "분할 브레인" 상태를 유발하는 활성 Edge로 대기 Edge를 승격합니다.

  • 해결된 문제 76586: 허브/스포크 토폴로지를 사용하는 고객의 경우 허브 Edge에서 WAN 오버레이 지원 인터페이스에 대해 응답을 수신하면 VMware SD-WAN 스포크 Edge가 '직접(Direct)'에서 '게이트웨이(Gateway)'로 전환되고, 흐름이 끊기면서 해당 흐름에 대한 고객 트래픽이 중단되는 것을 확인할 수 있습니다.

    이것은 고정 링크 비즈니스 정책을 통해 정방향 경로에서 언더레이(WAN-오버레이가 없는 MPLS)를 통해, 역방향 경로에서 오버레이(Hub Edge)를 통해 흐름을 비대칭으로 라우팅하려는 시나리오로, 이로 인해 흐름이 끊어집니다.

    이러한 흐름 끊김은 원격 끝 경로가 허브 Edge(오버레이)를 통해 다시 응답할 때 원격 Edge가 이 흐름을 로컬에서 시작된 새 흐름으로 보고, 흐름 라우팅 매개 변수를 업데이트하기 위한 QoS 동기화 요청을 전송하여 흐름 라우팅이 중단되기 때문에 발생합니다. 구성된 링크 모드를 덮어쓰지 않도록 QoS 동기화 요청이 거부됩니다.

  • 해결된 문제 76726: VMware SD-WAN Gateway에서 데이터부 서비스 장애가 발생하고 코어가 생성될 수 있습니다.

    게이트웨이 서비스 실패 및 코어의 원인은 Edge와 게이트웨이 간의 관리 프로토콜 ctrl 패킷 교환 때문입니다. 어설션으로 인해 게이트웨이가 실패할 수 있으며 이로 인해 여러 고객의 작업이 중단될 수 있습니다. 이 문제는 어설션을 제거하고 적절한 오류 처리를 수행하여 해결되었습니다.

  • 해결된 문제 77357: 일본에 배포된 VMware SD-WAN Edge 3400 또는 3800이 잠기고 자연스럽게 재부팅될 수 있습니다.

    Edge 3400 및 3800에는 시스템의 BMC(Baseboard Management Controller)에 일본의 100V 전기 공급 장치와 일치하는 잘못된 전압 주의 임계값(100V)이 설정되어 있습니다. 이 지역의 Edge 3400 또는 3800에 대한 결과는 연속적인 일련의 전원 공급 경보이며, 경보 볼륨이 충분히 자주 발생하면 Edge가 잠기고 재부팅됩니다.

    참고: 이 수정 사항으로 문제를 성공적으로 해결했지만, 수동으로 설정한 전압 임계값이 CPLD 업그레이드를 통해 지워졌기 때문에 수정 사항이 지속되지 않는 Edge 문제 51291에 대한 후속 조치입니다. 그렇지 않으면 증상과 설명은 동일하지만 여기에 나오는 수정 사항은 후속 Edge 업그레이드 후에도 전압 임계값이 지속되도록 합니다.

  • 해결된 문제 78003: 허브/스포크 토폴로지를 사용하는 고객의 경우 VMware SD-WAN 스포크 Edge에서 허브 Edge로의 고정 터널이 형성되지 않을 수 있습니다.

    일반적으로 스포크 Edge에 많은 수의 동적 Edge 간 터널이 이미 설정된 경우 스포크에서 고정 터널에 대한 최대 터널 수 검사가 실시되며, 이 검사는 스포크에서 허브로의 고정 터널 형성을 방지합니다.

  • 해결된 문제 78252: 대규모 엔터프라이즈에 배포할 때 VMware SD-WAN Edge에서 SIGXCPU 메시지가 표시되면서 데이터부 서비스 장애가 발생할 수 있습니다.

    이 문제는 우선 순위가 낮은 BGP/OSPF 작업자 스레드가 다른 높은 우선 순위 스레드가 대기 중인 개체에 대해 잠금을 유지하면서 실행되고 이로 인해 우선 순위가 반전되어 SIGXCPU 메시지가 표시되면서 Edge 서비스가 실패하기 때문에 발생합니다.

  • 해결된 문제 78276: VMware SD-WAN Edge의 이름에 ASCII가 아닌 문자가 포함되어 있으면 VMware SD-WAN Gateway에서 debug.py -qos_net을 실행하지 못합니다.

    한 가지 예는 중국어 문자를 사용하는 경우이지만, 이 문제는 ASCII가 아닌 모든 문자에 적용되며, ASCII가 아닌 문자를 포함하도록 Edge 이름을 변경하고 Edge를 재부팅할 때 확인될 수 있습니다. 그러면 게이트웨이가 Edge에 연결됩니다. 다음 CLI 명령을 실행하여 'debug.py --list 3’ Edge의 논리 ID를 가져옵니다. 그런 후 다음 게이트웨이 CLI 명령을 실행합니다. 'debug.py -qos_net [logical ID] all stats'. 그러면 명령이 실패한 것으로 표시됩니다.

  • 해결된 문제 78391: Speedtest 애플리케이션 분류가 적용된 트래픽이 제대로 작동하지 않습니다.

    speedtest.net 및 fast.com 둘 다에는 기본 애플리케이션 맵에 누락된 speedtest 서버 IP 주소가 새로 추가되었기 때문에 이러한 애플리케이션을 처리하는 비즈니스 정책이 적용되지 않습니다.

    릴리스 4.5.1로 업그레이드하지 않으면 운영자는 VMware SASE Orchestrator의 애플리케이션 맵 편집기를 사용하여 필요한 speedtest IP를 기존 애플리케이션 맵에 추가할 수 있습니다.

  • 해결된 문제 78637: VMware SD-WAN Gateway에서 SIGXCPU 메시지가 표시되면서 데이터부 서비스 장애가 발생하고 그 결과 서비스가 다시 시작될 수 있습니다.

    게이트웨이는 코어도 생성합니다. 이 문제는 게이트웨이가 선택적 TLV 길이가 0인 패킷을 수신하는 경우 게이트웨이에서 무한 루프가 발생하며 이로 인해 SIGXCPU와 결과 서비스가 다시 시작되고 코어가 생성됩니다.

  • 해결된 문제 78678: 고가용성 토폴로지를 사용하여 배포된 사이트에서 활성 Edge의 동기화 메시지를 처리하는 동안 대기 역할을 수행하는 VMware SD-WAN Edge가 재부팅될 수 있습니다.

    대기 Edge가 많은 수의 흐름 동기화 메시지를 처리하는 경우 SD-WAN 서비스가 버퍼 오버플로 조건을 감지하고 대기 Edge의 재부팅을 트리거할 수 있습니다.

  • 해결된 문제 79132: 허브/스포크 토폴로지에서 스포크로 구성된 VMware SD-WAN Edge의 경우 VMware SASE Orchestrator UI에서 [모니터링(Monitor)] &gt; [Edge]를 확인할 때 공용 링크에 잘못된 다운로드 대역폭 용량이 표시됩니다.

    스포크 Edge의 공용 링크에서 링크 통계가 기본 게이트웨이 대신, 스포크의 연결된 허브 Edge를 기준으로 측정된 값으로 로드됩니다. 그러면 Orchestrator에 업로드되고 다운로드 대역폭에 대해 표시됩니다.

    이 문제는 스포크 Edge가 스포크/허브 터널을 설정한 후 스포크 Edge의 기본 게이트웨이가 다시 시작될 때 트리거됩니다. 따라서 이 수정 사항을 적용하지 않고 이 문제를 방지하는 유일한 방법은 게이트웨이가 스포크 및 허브 Edge와의 터널을 설정한 후에 다시 시작되지 않도록 하는 것입니다.

  • 해결된 문제 79261: Office 365/Microsoft 365 애플리케이션 트래픽이 VMware SD-WAN Edge에서 Tencent Meeting(VooV Meeting) 애플리케이션 트래픽으로 잘못 분류됩니다.

    이로 인해 비즈니스 또는 방화벽 정책에 따라 Office 365/Microsoft 365 트래픽을 라우팅하고 우선 순위를 지정하는 고객이 해당 트래픽을 Tencent Meeting으로 분류하여 완전히 다른 규칙을 준수하도록 하지 못할 수 있습니다. 4.5.1 기본 애플리케이션 맵에서 수정된 잘못된 Tencent용 애플리케이션 맵 서브넷의 문제로 추적됩니다. 4.5.1을 사용하지 않는 고객은 Orchestrator 애플리케이션 맵 편집기를 통해 애플리케이션 맵을 편집하여 Tencent 서브넷을 수정하는 운영자가 해당 문제를 수정할 수 있습니다.

  • 해결된 문제 79437: 인터페이스에 대해 SR-IOV를 사용하도록 설정한 Intel X710 NIC를 사용하여 서버에 배포되는 VMware SD-WAN Gateway가 배포되지 않을 수 있습니다.

    이 오류가 발생하면 운영자는 X710 SR-IOV 인터페이스가 DPDK에서 제거되고 debug.py --dpdk_ports_d를 실행할 때 표시되지 않는 것을 확인할 수 있습니다. 또한 /opt/vc/etc/dpdk.json은 SR-IOV 인터페이스를 표시하지 않습니다. 게이트웨이를 4.5.1 릴리스에 배포하면 이 문제가 발생하지 않습니다.

  • 해결된 문제 79572: 고가용성 토폴로지로 배포된 사이트의 경우 사용자가 HA를 해제하면 독립형 VMware SD-WAN Edge가 비활성화되고 VMware SASE Orchestrator와의 연결이 끊기고 트래픽 전달이 완전히 중지될 수 있습니다.

    고가용성을 해제하면 대기 Edge가 구성을 적용하고 비활성화된 상태로 전환됩니다. 그러나 경합 상태로 인해 대기 Edge가 Orchestrator에 하트비트를 전송할 수 있고 이로 인해 Orchestrator가 활성 Edge에 비활성화 순서를 전송하게 됩니다. 이 문제가 발생하는 경우 모든 고객 트래픽이 즉시 삭제되고 Edge 중 하나가 다시 활성화될 때까지 재개되지 않기 때문에 고객에게 상당한 영향을 미치게 됩니다.

    이 수정 사항을 적용하지 않은 경우 고객은 a) 이 문제가 발생할 경우 Edge를 재활성화할 수 있는 옵션이 있는 유지 보수 기간에 HA를 해제하거나, b) 고객 배포에서 대기 Edge의 전원을 끄고 물리적으로 제거한 다음, 대기 Edge가 해당 문제를 트리거하는 가상 하트비트를 전송할 수 없을 때만 HA를 해제해야 합니다.

  • 해결된 문제 80006: VMware SASE Orchestrator 또는 VMware SD-WAN Gateway를 업그레이드할 때 시스템이 FIPS 모드(mode=compliant)이면 업그레이드 스크립트가 FIPS 모듈을 업그레이드하지 못합니다.

    시스템 업그레이드 중에 FIPS 패키지가 특수 시스템 위치(/var/lib/velocloud.fips)로 복사되지만 시스템 설치 관리자가 이를 선택하지 않습니다. 이 문제의 경우 FIPS 저장소가 설치 전 스크립트에서 업데이트되지 않으므로 시스템 업그레이드 단계에서 새 패키지를 사용할 수 없습니다.

    이 문제는 구성 요소를 릴리스 4.5.1로 업그레이드할 때는 발생하지 않습니다. 그러나 이 수정 사항을 적용하지 않은 상태로 Orchestrator 또는 게이트웨이를 릴리스로 업그레이드하는 운영자는 FIPS 모듈을 수동으로 업그레이드해야 합니다.

  • 해결된 문제 80010: SD-WAN 연결 가능(SD-WAN Reachable)도 구성된 허브/스포크 토폴로지를 사용하는 고객 엔터프라이즈의 경우 스포크-허브 경로가 지점 간에 수행된 경우 허브 경로를 통한 스포크-게이트웨이 경로(공용 WAN 링크 사용)가 실행되지 않습니다.

    스포크 Edge가 연결된 허브를 통해 게이트웨이에 연결하기 위한 패스스루인 SD-WAN 연결 가능 기능은 스포크 Edge 및 허브 Edge가 지점 간 링크로 연결되는 경우(즉, 스포크의 IP 주소가 허브의 연결된 경로와 일치함)에는 지원되지 않습니다. 이 문제에 대한 수정 사항은 이 기능을 추가합니다.

  • 해결된 문제 80196: VMware SD-WAN Gateway에서 SIGXCPU 메시지를 나타내며 데이터부 서비스 장애가 발생할 수 있으며 게이트웨이는 15~30초 동안 게이트웨이 트래픽에 영향을 미치면서 복구를 위해 서비스를 다시 시작합니다.

    이 문제는 처리량 용량에 비해 해당 게이트웨이의 처리량이 높기 때문에 대규모 배포(예: 4K Edge 및 6K 터널)에서 발생할 가능성이 더 높습니다. 높은 속도의 트래픽이 게이트웨이에 도달하면 일부 경우에 게이트웨이에서 스레드 잠금이 발생하고 다시 시작하는 동안 코어가 생성됩니다. 코어에서 사용자는 다음을 확인할 수 있습니다. "신호 SIGXCPU를 발생하면서 프로그램이 종료되었습니다. CPU 시간 제한을 초과했습니다."

  • 해결된 문제 80479: VMware SD-WAN Gateway에서 데이터부 서비스 장애가 발생할 수 있으며 게이트웨이는 15~30초 동안 게이트웨이 트래픽에 영향을 미치면서 복구를 위해 서비스를 다시 시작합니다.

    이 문제는 VMware SD-WAN Edge가 E2E(Edge-Edge)를 사용하도록 설정한 게이트웨이에 연결되어 있고 루프백 인터페이스 경로가 애드버타이즈된 경우에 발생할 수 있습니다. 사용자가 이 Edge에 대해 E2E를 해제하면 경로 시작이 트리거되지만 루프백 경로가 삭제되지 않고 경로의 프로필 플래그를 업데이트합니다. 다음으로, 사용자가 루프백 경로에 대한 애드버타이즈를 제거하면 FIB에서 경로가 삭제되지만 게이트웨이의 E2E 테이블에는 오래된 경로가 유지됩니다. 루프백 경로가 다시 애드버타이즈되고 FIB에 추가될 경우 해당 플래그만 다시 업데이트하는 E2E를 사용하도록 설정하면 해당 경로(오래된 경로)가 게이트웨이의 E2E 테이블에 있더라도 실제 경로 ref_count는 올바르지 않습니다. 마지막으로 터널이 해체되면 게이트웨이에서 데이터부 서비스 장애가 트리거됩니다.

    이 수정 사항을 적용하지 않으면 운영자는 Edge에 대한 프로필을 변경하기 전에 경로가 취소되었는지 확인해야 합니다.

  • 해결된 문제 80496: SD-WAN 터널을 통해 VMware SD-WAN Edge에서 원격 Edge의 분기 루프백 IP 주소로 수행하는 Ping이 작동하지 않을 수 있습니다.

    조각화를 유발할 정도로 패킷 크기가 충분한 ping에 대해 문제가 확인됩니다. 큰 패킷 크기를 사용하여 Edge에서 원격 분기 Edge의 루프백 IP 주소로 ping을 시작하면 조각화된 ICMP 응답이 ping을 시작하는 Edge에 도달하지만 다음 조각이 삭제되기 때문에 ping 애플리케이션에 도달하지 못합니다.

  • 해결된 문제 80897: VMware SD-WAN Edge가 VMware SD-WAN 파트너 게이트웨이에 연결된 고객 엔터프라이즈의 경우 고객 트래픽의 성능이 저하될 수 있습니다.

    성능 저하는 기본 보안 고정 경로를 사용할 수 있지만 Edge가 이러한 경로의 레이블에 보안 레이블을 제대로 지정하지 않은 경우 Edge로 경로를 분산하는 파트너 게이트웨이에서 라우팅 문제가 발생한 것에 따른 결과입니다. 그 결과, Edge는 예상된 동작이 항상 비보안 경로보다 보안 경로를 선호할 때 모든 경로가 동일하게 처리되기 때문에 비기본 및 비보안 경로를 보안 경로에 애드버타이즈할 수 있습니다.

    참고: 이 문제를 해결하려면 파트너 게이트웨이와 고객 Edge를 모두 이 수정 사항이 포함된 빌드로 업그레이드해야 합니다.

  • 해결된 문제 81196: 사용자는 공장 기본 암호를 사용하여 비활성화된 VMware SD-WAN Edge의 로컬 UI에 로그인할 수 없습니다.

    사용자는 예약 설정(Reset Setting) >구성 재설정(Reset Configuration)을 사용하여 로컬 UI를 통해 또는 Edge에 대해 원격 작업(Remote Actions) > 비활성화(Deactivate)를 선택하여 VMware SASE Orchestrator에서 Edge를 "비활성화"할 수 있습니다. 사용자가 Edge를 "비활성화"한 후에는 모든 구성을 지우고 로컬 UI의 로그인 자격 증명을 기본값으로 되돌려야 하지만 그렇게 하지 않습니다. 자격 증명은 비활성화 전과 동일하게 유지되며, 사용자가 로컬 UI 기본 자격 증명을 다른 값으로 변경한 경우 해당 새 값은 Edge 비활성화 이후에도 유지됩니다. 로컬 UI 자격 증명이 업데이트되지 않으면 비활성화 전과 후의 자격 증명이 기본값으로 유지되기 때문에 사용자에게 아무 문제도 발생하지 않습니다.

  • 해결된 문제 81221: 고객이 VMware SD-WAN Edge에 대해 1:1 NAT 규칙을 구성하고 해당 Edge가 재부팅될 때 규칙이 더 이상 작동하지 않습니다.

    재부팅 후 Edge는 NAT 규칙이 적용되는 Edge 인터페이스 주소로 NAT 주소를 할당하므로 해당 규칙과 일치하는 트래픽에 대해 터널이 구축되지 않습니다.

    이 수정 사항을 적용하지 않고 이 문제를 해결할 수 있는 유일한 방법은 전체 NAT 테이블을 플러시하고 올바른 NAT 규칙 작업을 다시 설정하는 원격 진단 "NAT 플러시"(Flush NAT)를 실행하는 것입니다.

  • 해결된 문제 81224: 고가용성 토폴로지를 사용하여 배포된 사이트에서 HA 페일오버가 발생하면 OSPF 경로 태그가 HA 페일오버 후 전파되지 않을 수 있습니다.

    HA 페일오버에서 OSPF 외부 LSA(링크 상태 애드버타이즈)에 경로 태그가 없으므로 라우팅이 잘못되고 고객 트래픽에 부적절한 영향을 미치게 됩니다.

  • 해결된 문제 81517: VMware SD-WAN Edge 모델 6x0을 사용하는 향상된 고가용성 토폴로지로 배포된 사이트에서 HA 링크 상태가 제대로 업데이트되지 않습니다.

    HA 링크는 고급 HA Edge 쌍을 연결하는 링크이며, 이 링크가 제대로 업데이트되지 않으면 사이트에 문제가 있을 수 있습니다.

  • 해결된 문제 81575: Intel x710 SR-IOV 기반 NIC를 사용하는 VMware OVA 기반 VM을 사용하여 배포된 VMware SD-WAN Gateway의 경우 게이트웨이 소프트웨어 업그레이드 후 연결 문제가 발생할 수 있습니다.

    이 문제는 iavf Linux Virtual Function Drivers가 게이트웨이 업그레이드 시 올바르게 설치되지 않았고 그에 따라 x710 SR-IOV 기반 NIC가 업그레이드된 게이트웨이에서 작동하지 않기 때문에 발생합니다. 이 문제는 Virtio 또는 VMNet 기반 NIC를 사용하는 게이트웨이에는 영향을 주지 않습니다.

  • 해결된 문제 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를 수행하는 옵션이 없었습니다.

  • 해결된 문제 81920: Intel x710 SR-IOV 기반 NIC를 사용하는 KVM 기반 VM을 사용하여 배포된 VMware SD-WAN Gateway의 경우 게이트웨이 소프트웨어 업그레이드 후 연결 문제가 발생할 수 있습니다.

    이 문제는 iavf Linux Virtual Function Drivers가 게이트웨이 업그레이드 시 올바르게 설치되지 않았고 그에 따라 x710 SR-IOV 기반 NIC가 업그레이드된 게이트웨이에서 작동하지 않기 때문에 발생합니다. 이 문제는 Virtio 또는 VMNet 기반 NIC를 사용하는 게이트웨이에는 영향을 주지 않습니다.

  • 해결된 문제 82182: Edge 릴리스 5.0.0.0을 실행하는 VMware SD-WAN Edge 모델 510 또는 510-LTE의 경우 사용자가 Edge의 서비스 다시 시작하려고 하면 Edge가 재부팅될 수도 있습니다.

    Edge가 재부팅 프로세스를 진행하는 동안 2~3분 동안 고객 트래픽이 중단됩니다. Edge 510/510-LTE에 Edge 서비스를 다시 시작하는 동안 중지하지 못할 수 있는 Wi-Fi 디바이스 중단 모니터링 스크립트가 있으며 이로 인해 재부팅이 트리거됩니다.

    이 수정 사항을 적용하지 않으면 사용자가 Edge 서비스를 다시 시작해야 하지만 이러한 모델에서 Edge 서비스는 이러한 문제가 발생할 수 있다는 사실을 이해한 경우에 유지 보수 기간에만 다시 시작해야 합니다.

  • 해결된 문제 82188: VMware SD-WAN LTE 모델(Edge 510-LTE, 610-LTE)의 경우 IPv6 설정이 해제되면 CELL 인터페이스를 통한 터널이 실패할 수 있습니다.

    [디바이스 설정(Device Settings)]의 IPv6 확인란을 끄면 CELL 인터페이스의 내부 상태가 UNKNOWN(알 수 없음)으로 전환됩니다. CELL 인터페이스에 대해 IPv6 설정이 켜짐으로 전환된 경우에도 업데이트되지 않습니다. 이로 인해 CELL 인터페이스를 통한 터널이 실패합니다. LTE Edge가 트래픽에 대해 CELL 인터페이스만 사용하면 Edge가 오프라인으로 전환되며, 모든 Edge 트래픽이 삭제되어 고객의 작업에 큰 지장을 줄 수 있습니다.

    이 수정 사항을 적용하지 않으면 사용자는 IPv6 설정을 해제한 후 Edge 서비스를 다시 시작해야 합니다. Edge가 대역폭에 대해 CELL 인터페이스만 사용하기 때문에 오프라인 상태인 경우 로컬 사용자는 Edge의 전원을 껐다 켜서 복구해야 합니다.

  • 해결된 문제 82314: VMware SD-WAN Gateway가 업그레이드될 때 Intel x710 PCIe 패스스루 기반 NIC를 사용하는 경우 연결이 끊어지면서 예외가 발생할 수 있습니다.

    게이트웨이가 업그레이드될 때 업그레이드의 일부가 커널 변경이고 i40e 드라이버 설치에 실패하며 게이트웨이에서 사용할 수 없습니다. i40e 드라이버를 사용할 수 없기 때문에 모든 x710 PCIe 패스스루 기반 NIC가 게이트웨이에서 제대로 작동하지 않아 성능 저하 또는 연결 끊어짐이 발생합니다. 이 문제는 Virtio 또는 VMNet 기반 NIC를 사용하는 게이트웨이에는 영향을 주지 않습니다.

  • 해결된 문제 82522: 높은 처리량의 트래픽이 VMware SD-WAN Edge에 도달하면 Edge에서 실제 처리량이 감소된 것으로 확인될 수 있습니다.

    처리량이 높은 경우 Edge의 NDP(Neighbor Discovery Protocol) 스레드는 연결할 수 있는 것으로 표시되고 추가 처리가 필요하지 않은 NDP 항목에 대해서도 잠금을 두 번 획득합니다. 이러한 중복 잠금은 추가 처리를 발생하므로 처리량이 감소되도록 합니다.

  • 해결된 문제 82790: Azure 환경에 배포된 VMware SD-WAN Gateway에서 게이트웨이 인터페이스 카운터를 Wavefront 모니터링 서비스로 내보내지 않습니다.

    Azure는 DPDK가 비활성화된 환경으로, DPDK 인터페이스 카운터(처리량 비율, PPS 및 삭제 카운터)만 Wavefront 서비스로 내보내집니다. 이로 인해 DPDK가 비활성화된 Azure와 같은 플랫폼에서 모니터링 기능이 줄어듭니다.

  • 해결된 문제 83029: 독립 실행형 VMware SD-WAN Edge 또는 하나 이상의 PPPoE 링크가 사용되는 고가용성 토폴로지로 배포된 사이트의 경우, 해당 PPPoE 링크에 대한 Edge 인터페이스가 플래핑되거나 HA 사이트가 페일오버의 영향을 받은 후 PPPoE 끝점 IP가 변경되면 PPPoE 링크에서 트래픽이 전달되지 않습니다.

    PPPoE 링크를 사용하는 사이트에서는 PPPoE 끝점 IP가 변경되면 고객 트래픽이 전달되지 않습니다. 이 문제는 새 PPPoE 끝점 IP 주소가 수신된 후 삭제되지 않은 Edge에 있는 PPPoE 끝점의 이전 IP 주소를 사용하는 오래된 기본 경로가 있기 때문에 발생합니다.

    이 버그 수정 사항을 적용하지 않으면 현장 사용자는 각 PPPoE 케이블의 연결을 끊었다가 다시 연결하여 강제로 재협상을 수행하거나 Edge를 재부팅하여 강제로 재협상해야 합니다.

  • 해결된 문제 83402: 여러 WAN 링크가 있는 VMware SD-WAN Edge에서 하나 이상의 WAN 링크가 트래픽 전달을 중지할 수 있습니다.

    트래픽 전달을 중지하는 WAN 링크에서 DHCP 획득 주소가 갱신되지 않고 WAN 인터페이스의 주소가 손실됩니다. 이 문제는 DHCP를 사용하여 IP 주소를 가져오는 여러 인터페이스가 있고 DHCP 서버가 클라이언트와 다른 네트워크에 있는 경우에 발생합니다. DHCP 갱신 유니캐스트 패킷의 송신 인터페이스는 경로 조회를 통해 결정됩니다. 다양한 인터페이스를 통해 다양한 메트릭 값이 학습된 여러 기본 경로가 있기 때문에 DHCP 요청 패킷이 다른 인터페이스에서 전송될 수 있습니다.

    이 수정 사항을 적용하지 않으면 현장 사용자는 Edge에서 영향을 받는 WAN 링크를 분리했다가 다시 연결하여 해당 IP 주소를 강제로 다시 가져와야 합니다.

  • 해결된 문제 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 서버로 전송되는 큰 패킷이 삭제될 수 있습니다.

  • 해결된 문제 84359: VMware SD-WAN Edge 인터페이스가 플래핑되면 여러 IPv4 주소를 할당할 수 있습니다.

    인터페이스가 DHCP 클라이언트 플래핑(빠르게 연속해서 종료되었다가 실행됨)으로 구성되면 전체 DHCP 클라이언트 프로세스가 다시 수행되고 매번 다른 IP 주소를 획득하는 시나리오가 있을 수 있습니다. 이 경우 이전 IP 주소는 지워지지 않고 오래된 상태가 됩니다.

    이 수정 사항을 적용하지 않으면 이 문제를 해결하는 유일한 방법은 사용자가 "ip address del" 명령을 사용하여 Linux 셸을 통해 인터페이스에서 IP 주소를 수동으로 삭제하는 것입니다.

  • 해결된 문제 84825: 단일 단계에서 VMware SD-WAN Edge에 대량 라우팅 구성을 적용하면 Edge에서 데이터부 서비스 오류가 반복적으로 발생하여 Edge 서비스가 반복적으로 다시 시작되어 각 오류로부터 복구될 수 있습니다.

    독립형(비 HA) Edge에서 이 문제가 발생하는 경우 단일 Edge 서비스를 다시 시작하면 최대 15초 동안 트래픽이 중단되지만 Edge 서비스 다시 시작을 반복하면 최대 60초 이상이 중단되므로 고객 트래픽에 상당한 영향을 미칩니다. 고가용성 토폴로지가 있는 사이트에서 Edge 서비스가 다시 시작되어 고객 트래픽도 중단되는 페일오버가 반복적으로 발생합니다.

    이 문제는 많은 수의 인접 항목 및 경로 맵을 포함하는 대량 라우팅 구성이 단일 단계로 Edge에 적용되는 경우에 발생합니다. Edge 시스템은 이러한 구성을 명령 규격으로 변환하고 짧은 기간 내에 라우팅 프로토콜에 적용하면서 스트레스가 매우 커지고 이로 인해 Edge 서비스 실패 및 다시 시작이 반복됩니다.

    수정 사항을 적용하지 않은 Edge 빌드에서 이 문제의 위험을 완화하려면 고객 사용자는 다음을 수행해야 합니다.

    • 단일 단계에서 대규모 구성을 적용하는 대신, 각 섹션이 별도로 적용된 여러 개의 작은 섹션으로 구성을 구분해야 합니다.

    • 라우팅 필터 수를 최소화해야 합니다.

    • Edge는 유지 보수 기간에만 고의로 다시 시작해야 하며, 다시 시작하는 동안 전체 Edge 구성이 한 번에 적용되어 이 문제가 발생할 위험이 크게 증가하므로 여러 라우팅 필터가 구성된 경우 일반적으로 Edge 서비스를 다시 시작하지 않아야 합니다.

  • 해결된 문제 84847: 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 서비스를 다시 시작하는 것입니다.

  • 해결된 문제 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 측 NAT: [source] 내부 주소: 10.0.2.25/32 외부 주소: 7.0.2.25/32

    고정 경로: 7.0.2.25/32 [애드버타이즈] 다음 홉: 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를 사용하여 방화벽 규칙 조회가 수행되도록 합니다. 두 번째 방화벽 규칙 조회는 오류로 수행됩니다.

    이 수정 사항이 없으면 사용자는 흐름의 첫 번째 반환 패킷을 허용하는 추가 방화벽 규칙을 생성해야 합니다.

  • 해결된 문제 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에서 문제를 해결하는 유일한 방법은 Edge의 서비스를 다시 시작하는 것입니다.

    참고: 2022년 8월 22일까지의 4.5.1 릴리스 정보 개정판에서는 이 문제가 알려진 문제로 나열되었습니다. #86808에 대한 수정 사항이 릴리스 4.5.1의 원래 GA 빌드에 포함되어 있고 릴리스 4.5.1 빌드에는 이 문제가 없었으므로 이것은 올바르지 않은 것입니다.

Orchestrator의 해결된 문제

Orchestrator 버전 R451-20220831-GA에서 해결됨

Orchestrator 버전 R451-20220831-GA는 2022년 9월 6일에 릴리스되었으며 업데이트된 3번째 릴리스 4.5.1용 Orchestrator 롤업 빌드입니다. 이 빌드는 2022년 8월 11일에 릴리스된 원래 3번째 롤업 빌드 R451-20220810-GA를 대체합니다. R451-20220831-GA는 R451-20220810-GA에 대해 해결된 새 문제를 추가하지 않지만 VMware 엔지니어링 팀에 필요한 성능 및 문제 해결 변경 사항을 포함합니다.

중요:

고객은 R451-20220831-GA 빌드만 사용해야 하며 R451-20220810-GA를 사용하지 않아야 합니다.

빌드 R451-20220831-GA는 두 번째 Orchestrator 롤업, 버전 R451-20220612-GA 이후의 아래와 같은 중요한 문제를 해결합니다.

  • 해결된 문제 80735: 사용자가 하나 이상의 VMware SD-WAN Edge에도 할당된 프로필의 구성을 변경하면 프로필 수준의 BGP 필터가 제거됩니다.

    이전에 사용자가 BGP 필터의 세부 정보를 볼 수 있었던 위치의 VMware SASE Orchestrator UI에서 "오류: 잘못된 필터 참조"가 표시됩니다. BGP에 의존하는 고객 네트워킹에 미치는 영향은 중요하며 BGP 필터를 복원하는 유일한 방법은 필터를 수동으로 복원하는 것입니다.

  • 해결된 문제 83507: 새 빌드로 업데이트된 VMware SASE Orchestrator는 동일한 이전 버전의 MySQL 서버 소프트웨어를 계속 사용합니다.

    Orchestrator 빌드 프로세스가 사용 중인 SQL Server 버전을 고정하고 있어서 MySQL 서버 소프트웨어에 최신 버그 수정이 포함되지 않으므로 Orchestrator 수준 데이터베이스 문제가 발생할 수 있습니다.

  • 해결된 문제 88120: VMware SASE Orchestrator에서 클래식 UI와 새 UI의 [모니터링(Monitor)] &gt; [Edge] &gt; [개요(Overview)] 페이지를 확인하면 [라이브 모드(Live Mode)]로 표시할 때 링크 상태가 불일치합니다.

    특정 불일치는 새 UI에 나타나며 WAN 링크가 [안정(Stable)] 상태를 표시해야 할 때 [대기(Standby)] 상태를 표시할 수 있습니다. 클래식 UI는 링크 상태를 올바르게 표시합니다.

  • 해결된 문제 90067: VMware SASE Orchestrator를 4.5.1 또는 5.0.0으로 업그레이드하면 운영자에게 높은 CPU 사용량 및 로드 문제가 발생할 수 있습니다.

    업그레이드하는 동안 Orchestrator의 중요한 시스템 속성인 edge.learnedRoute.maxRoutePerCall이 손실됩니다.이 속성은 Orchestrator에서 한 번에 수신할 수 있는 라우팅 프로토콜 이벤트 수를 제한합니다. 이 속성이 없으면 라우팅 프로토콜 이벤트로 Orchestrator가 플러딩되어 Orchestrator가 높은 로드 상태가 되며 Orchestrator의 성능에 영향을 미칠 수 있습니다. 이 버그 수정 사항은 Orchestrator 업그레이드가 수행되어도 시스템 속성 edge.learnedRoute.maxRoutePerCall이 유지됩니다.

  • 해결된 문제 91179: WAN 링크가 핫 대기(Hot Standby)로 구성된 VMware SD-WAN Edge의 경우 핫 대기 링크의 상태가 대기일 때 VMware SASE Orchestrator의 새 UI에서 핫 대기 링크(활성)에 대한 잘못된 상태를 표시합니다.

    Orchestrator의 클래식 UI에서 링크에 대한 올바른 상태(유휴)가 표시되므로 이는 새 UI에만 국한됩니다. 이 문제는 새 UI가 핫 대기 WAN 링크의 상태 변경에 대한 올바른 업데이트를 받지 못하기 때문에 발생합니다.

  • 해결된 문제 92082: VMware Cloud Web Security를 사용하는 고객의 경우 컨텐츠 필터링 규칙이 구성된 도메인을 준수하지 않는 것을 확인할 수 있습니다.

    컨텐츠 필터링 규칙은 사용자가 범주에 대해서도 [모두(ALL)]를 선택한 경우 제공된 구성된 도메인을 재정의합니다. 또는 사용자가 범주에 대해 [없음(NONE)]을 선택하는 경우 마법사는 기본적으로 이 선택 항목이 모든 범주를 의미하는 것으로 인식하므로 도메인도 적용되지 않습니다. 이 문제는 컨텐츠 필터링 마법사 및 API의 문제로 인해 발생합니다. 사용자가 하나 이상의 범주를 구성하는 경우 도메인이 적용됩니다.

    이 수정 사항이 없는 Orchestrator에서 사용자는 도메인과 함께 특정 범주를 구성해야 합니다. 그러면 Orchestrator는 컨텐츠 필터링에서 도메인을 적용합니다.

Orchestrator 버전 R451-20220612-GA에서 해결됨

Orchestrator 버전 R451-20220612-GA는 2022년 6월 13일에 릴리스되었으며 두 번째 릴리스 4.5.1용 Orchestrator 롤업입니다.

이 Orchestrator 롤업 빌드는 첫 번째 Orchestrator 롤업, 버전 R451-20220520-GA 이후의 아래와 같은 중요한 문제를 해결합니다.

  • 해결된 문제 86848: 고객 관리자가 네이티브(사용자 이름/암호) 방법을 사용하여 VMware SASE Orchestrator의 고객 엔터프라이즈에 로그인하지 못한 경우 Orchestrator는 UI의 [모니터링(Monitor)] &gt; [이벤트(Events)] 페이지에 실패한 시도를 로그하지 않습니다.

    Orchestrator는 모든 사용자 계정에 대한 적절한 책임을 보장하고 모든 관리자가 비정상적인 로그인 활동을 감지할 수 있도록 성공 여부와 관계없이 모든 로그인 시도를 로그해야 합니다. 이 문제는 실패한 사용자 이름/암호 인증 시도에 대해 'enterpriseld' 메타데이터를 포함하지 않은 Orchestrator로 인해 발생합니다. 네이티브(사용자 이름/암호) 인증을 사용하는 고객 사용자에게만 영향을 미치며 SSO(싱글 사인온)를 사용하는 고객 엔터프라이즈는 이 문제의 영향을 받지 않습니다.

  • 해결된 문제 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 피어에 연결할 수 없습니다.

Orchestrator 버전 R451-20220520-GA에서 해결됨

Orchestrator 버전 R451-20220520-GA는 2022년 5월 24일에 릴리스되었으며 첫 번째 릴리스 4.5.1용 Orchestrator 롤업입니다.

이 Orchestrator 롤업 빌드는 초기 GA 버전 R451-20220517-GA 이후의 아래와 같은 중요한 문제를 해결합니다.

  • 해결된 문제 84214: 운영자 사용자가 VMware SASE Orchestrator UI의 게이트웨이 페이지에 있는 경우 슈퍼 게이트웨이 역할에 대해 특정 게이트웨이를 할당하지 못할 수 있습니다.

    게이트웨이에 이미 슈퍼 및 대체 슈퍼 게이트웨이의 역할이 모두 할당되어 있고, 운영자가 게이트웨이(Gateways) > 게이트웨이 구성(Configure Gateways) 화면의 고객 사용량 목록에서 엔터프라이즈의 슈퍼 게이트웨이 할당을 편집하려고 하면 UI가 슈퍼 게이트웨이에 대한 연결된 데이터를 올바르게 찾지 못하고 콘솔에서 오류가 발생하면서 슈퍼 게이트웨이 할당 대화 상자가 표시되지 않습니다.

  • 해결된 문제 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 및 올바른 경로 설정에 대해 선택되도록 하는 것입니다.

  • 해결된 문제 89349: 4.5.1 Orchestrator 빌드 R451-20220517-GA를 사용하는 VMware SASE Orchestrator에 로그인하는 사용자의 로그인 페이지에는 베타 라이센스 계약이 표시됩니다.

    Orchestrator에 로그인할 때 사용자는 VMware SASE 검증 GA 빌드가 아닌 베타 빌드를 사용하고 있는 것과 같은 혼동을 줍니다. R451-20220517-GA Orchestrator 빌드는 베타 라이센스 계약이 실수로 남아 있고 해당 표시가 순전히 표면적인 것에 불과하다는 점을 제외하고는 정품 GA 빌드입니다.

Orchestrator 버전 R451-20220517-GA에서 해결됨

아래 문제는 Orchestrator 버전 R450-20220502-GA 이후에 해결되었습니다. 

참고:

릴리스 5.1.0에는 또는 4.5.0 릴리스 정보에 나열된 모든 Orchestrator 수정 사항이 포함되어 있습니다.

  • 해결된 문제 45078: VMware SD-WAN Orchestrator에서 고객에 대한 VNF를 구성할 때 VNF 상태가 프로필 수준에서 한 가지 방식으로 구성된 다음, Edge 재정의를 사용하여 사이트 수준에서 다른 방식으로 구성된 경우 Edge 재정의(Edge Override)가 나중에 비활성화되면 사이트는 계속해서 Edge 재정의(Edge Override) 설정을 사용하며 예상된 대로 프로필 설정으로 되돌아가지 않습니다.

    이 문제는 Edge 재정의(Edge Override)를 사용하여 사이트에 대해 반대 설정이 구성되고, 나중에 Edge 재정의가 비활성화되지만 반대 설정이 유지되는 구성 프로필에서 VNF 삽입 매개 변수를 구성할 때 발생합니다.

  • 해결된 문제 53751: cidrIp 및 cidrPrefix가 없는 VLAN에서 고정 경로 설정의 연결된 경로 유효성 검사가 실패합니다.

    이 문제는 사용자가 cidrIp 및 cidrPrefix 없이 VLAN을 생성할 때 발생합니다.

  • 해결된 문제 54015: VMware SASE Orchestrator에서 특수 문자 및 스크립트를 사용하여 ICMP 프로브 이름을 구성할 수 있습니다.

    '<script>alert('test');</script>' 및 'test<script>alert('test');</script>' 스크립트를 ICMP 프로브 이름에 대한 입력으로 사용하여 ICMP 프로브를 구성하면 "저장하는 동안 안전하지 않은 문자 "<" 및 ">"가 필드에서 확인되었습니다." 오류가 표시됩니다. 반환해야 할 사항은 다음과 같습니다. {"error":{"code":-32603,"message":"script injection error"}}.

  • 해결된 문제 59784: 사용자가 액세스 권한이 없는 VMware SASE Orchestrator의 화면에 액세스하려고 하면 무한 회전자가 있는 빈 화면이 표시됩니다.

    단순히 기본 페이지를 로드하지 않고 고객 엔터프라이즈의 특정 금지 섹션을 가리키는 링크인 "딥 링크"를 통해 금지된 화면/경로(예: 읽기 전용 역할이 있을 때 디바이스 설정(Device Settings))에 액세스하려고 하면 사용자가 자동으로 "액세스 거부(Access Denied)" 화면으로 리디렉션되지 않습니다.

  • 해결된 문제 62624: 파트너 게이트웨이가 사용 중인 동안 [파트너 게이트웨이(Partner Gateway)] 확인란의 선택을 취소하려고 하면 고객 이름이 표시됩니다.

    게이트웨이가 하나 이상의 고객 및 고객 프로필에서도 사용될 때 사용자가 VMware SD-WAN Orchestrator UI에서 특정 게이트웨이에 대한 [파트너 게이트웨이(Partner Gateway)] 확인란의 선택을 취소하면 Orchestrator는 프로필 및 Edge 이름만 표시하고 게이트웨이를 사용하는 고객 이름은 표시하지 않습니다.

  • 해결된 문제 67209: VMware SASE Orchestrator에서 CSS(클라우드 보안 서비스)를 구성할 때 클라우드 이름이 구성된 CSS와 일치하지 않습니다.

    클라우드 이름과 CSS가 일치하지 않을 경우 고객에게 혼동을 줄 수 있습니다.

  • 해결된 문제 67912: [네트워크 서비스(Network Services)] 페이지와 VMware SASE Orchestrator의 [Edge 모니터링(Edge Monitoring)] 페이지를 확인할 때 터널 전체 상태가 다르게 표시됩니다.

    사용자가 [Edge 모니터링(Edge Monitoring)] 페이지로 이동하고 터널의 전반적인 상태를 확인하면 [클라우드 보안 서비스(Cloud Security Service)(CSS)] 섹션에서 터널의 전반적인 상태를 확인할 때 [네트워크 서비스 모니터링(Network Services Monitoring)] 페이지에서와 다른 상태가 확인되며 이로 인해 해당 터널의 실제 상태로 혼동을 줄 수 있습니다.

  • 해결된 문제 68387: 사용자가 네이티브가 아닌 유형(즉, 사용자 이름/암호는 사용하지 않고 SSO 또는 인증 RADIUS 사용)을 사용하여 새 운영자 사용자 또는 고객 관리자를 생성하려고 할 때 VMware SASE Orchestrator에서는 여전히 새 사용자에 대한 암호를 입력하도록 요구합니다.

    사용자가 새 고객 또는 운영자 사용자를 생성하려고 하면 Orchestrator UI가 암호 필드를 지우지 않습니다. 백엔드에서는 먼저 사용자 유형이 네이티브가 아닌지 확인하는 대신, 암호 강도 검사를 실행하고 오류를 발생시킵니다.

  • 해결된 문제 68463: VMware SASE Orchestrator에서 새 UI를 사용하고 QoE 섹션을 살펴보면 잘못된 그래프 값이 표시됩니다.

    이전 UI에서 QoE를 진행하면 [지연 시간 정상(Latency Fair)]이 그래프에 표시됩니다. 이 경우 새 UI(동일한 Edge 및 시간)를 확인하면 [지터 정상(Jitter Fair)]이 표시됩니다. 이 문제는 QoE가 새 UI에 잘못 매핑되기 때문에 발생합니다.

    이 수정 사항을 적용하지 않으면 유일한 해결 방법은 이전 Orchestrator UI를 사용하여 올바른 QoE 값을 확인하는 것입니다.

  • 해결된 문제 69181: 사용자가 VMware SASE Orchestrator의 [디바이스 설정(Device Settings)] &gt; [게이트웨이 전달(Gateway Handoff)] 섹션에서 IPsec 게이트웨이로 시작되는 보조 Edge를 구성하는 경우 IPsec 게이트웨이로 시작되는 보조 Edge와의 IPsec 터널이 설정되지 않습니다.

    debug.py --gateways를 볼 때 IPsec 구성이 적용되어 존재하는 것을 볼 수 없습니다.

  • 해결된 문제 69514: "PDF에 대한 Blob 데이터를 업데이트하지 못했습니다." 오류가 표시되며 보고서 생성이 실패할 수 있습니다.

    사용자가 오프라인 보고서를 생성하려고 하면 내부 오류를 나타내며 보고서 생성이 실패합니다. 이 문제가 차트 생성 라이브러리의 잘못된 버전으로 인해 발생했습니다.

  • 해결된 문제 69534: VMware Edge Network Intelligence를 사용하는 고객의 경우 Orchestrator의 새 UI에서 고객 기본 모니터링 페이지의 아무 곳이나 클릭하면 '애플리케이션 분석(Application Analytics)' 및 '분기 분석(Branch Analytics)'에 대한 링크가 사라집니다.

    사용자가 페이지를 다시 로드할 때 동일한 페이지의 아무 곳이나 클릭할 때까지 해당 링크가 다시 나타나고 그 이후에 다시 사라집니다. 이로 인해 사용자는 페이지를 다시 로드할 수 있는 경우가 아니면 [애플리케이션 분석(Application Analytics)] 및 [분기 분석(Branch Analytics)] 모니터링 데이터를 볼 수 없습니다.

  • 해결된 문제 69869: VMware SASE Orchestrator에서 새 UI를 사용하는 경우 선택한 세그먼트가 고객에게 위임되지 않은 경우에도 고객 관리자가 고객의 BFD 구성을 편집할 수 있습니다.

    고객 엔터프라이즈에는 두 개의 세그먼트가 있고 첫 번째 세그먼트는 고객 관리자가 편집할 수 있으며 다른 세그먼트는 고객 엔터프라이즈에 위임되지 않습니다. 고객 관리자가 편집 가능한 세그먼트에서 편집할 수 없는 세그먼트로 전환할 때 BFD를 구성하는 기능이 차단되지 않습니다.

  • 해결된 문제 69932: VMware SASE Orchestrator에서 새 UI를 사용할 때 운영자 또는 파트너 관리자가 고객 간을 여러 번 전환하면 애플리케이션 전환기(SD-WAN/Cloud Web Security/Secure Access/Edge Network Intelligence 선택)가 UI에서 사라질 수 있습니다.

    또한 고객 간을 전환할 때 고객은 이전 고객에 대한 설정을 표시할 수 있습니다(예: 해당 고객에 대해 해당 서비스를 사용하도록 설정하지 않은 경우 Cloud Web Security를 사용할 수 있도록 설정).

  • 해결된 문제 69981: VMware SASE Orchestrator에서 [모니터링(Monitor)] &gt; [Edge] 페이지와 [모니터링(Monitor)] &gt; [네트워크 서비스(Network Services)] 페이지를 확인할 때 터널 전체 상태가 다르게 표시됩니다.

    사용자가 모니터링(Monitor) > Edge 페이지를 참조하고 터널의 전반적인 상태를 기록한 다음, 이 상태를 모니터링(Monitor) > 네트워크 서비스(Network Services) 페이지에 표시된 상태와 비교할 때 [CSS(클라우드 보안 서비스)] 섹션에서 터널의 전반적인 상태가 모니터링(Monitor) > Edge 페이지에 표시된 상태와 일치하지 않을 수 있습니다.

  • 해결된 문제 70018: 릴리스 4.3.0 이상을 실행하는 VMware SD-WAN Orchestrator에서 재해 복구 쌍을 구성하지 못할 수 있습니다.

    근본 원인으로 인해 Orchestrator에서 DR을 수행하는 데 필요한 사용 가능한 디스크 공간을 확보하지 못하며, "디스크 공간이 부족하여 DB를 복사할 수 없음"이라는 오류 메시지를 표시하며 DR 연결이 실패할 수 있습니다.

  • 해결된 문제 70350: 권한이 없는 경우에도 VMware SASE Orchestrator의 새 UI에서 모든 사용자가 OSPF 설정을 구성할 수 있습니다.

    새 UI에는 디바이스 설정(Device Settings) > OSPF 구성에 대한 사용자 권한 확인이 포함되지 않습니다.

  • 해결된 문제 70528: 고객에 대한 사용자 지정 복합 역할은 VMware SASE Orchestrator 인증 페이지의 [세션 추적(session tracking)] 섹션에 표시되지 않으며 세션 제한에 대해 구성할 수 없습니다.

    이 문제는 사용자 지정 복합 역할 기능이 도입된 4.5.0 버전을 실행하는 Orchestrator에서 발생합니다. 사용자 지정 역할을 생성한 후에는 고객이 새 역할에 대한 세션 제한을 구성할 수 없습니다.

  • 해결된 문제 71242: [게이트웨이를 통한 NSD(비 SD-WAN 대상)(Non SD-WAN Destination (NSD) via Gateway)]를 구성하는 동안 사용자는 VMware SASE Orchestrator UI에서 BFD를 구성할 수 없습니다.

    구성(Configure) > 네트워크 서비스(Network Services)를 통해 [게이트웨이를 통한 NSD(NSD via Gateway)]를 구성할 때 BFD 대화상자를 열면 UI에 BFD 매개 변수를 구성하는 옵션이 제공되지 않습니다.

  • 해결된 문제 71778: DR(재해 복구) 토폴로지에서 배포된 VMware SASE Orchestrator를 릴리스 4.5.0으로 업그레이드하면 운영자가 NSD(비 SD-WAN 대상) 개체에 대해 게이트웨이를 수동으로 전환할 수 없습니다.

    게이트웨이를 전환하기 위한 API 호출이 4.5.0에서 요청 유효성 검사를 적용하기 시작했습니다. 그러나 Orchestrator UI 클라이언트가 API에 필요한 매개 변수를 제공하지 않았습니다.

  • 해결된 문제 71898: RADIUS 서비스를 구성할 때 구성 필드를 비워 두고 사용자가 구성을 저장하려고 하면 VMware SASE Orchestrator UI에서 일반 오류가 발생합니다.

    "예기치 않은 오류가 발생했습니다."라는 오류 메시지는 수정해야 하는 사항에 대한 인사이트를 사용자에게 제공하지 않습니다. 또한 수정해야 하는 구성 필드는 강조 표시되지 않습니다.

  • 해결된 문제 72039: VMware SASE Orchestrator의 [구성(Configure)] &gt; [디바이스(Device)] 페이지에서 작업하는 경우 세그먼트를 인식하는 기능과 세그먼트에 무관한 기능을 기준으로 기능을 정렬할 수 없습니다.

    일부 디바이스 설정은 세그먼트 및 세그먼트에 대해 구성해야 하는 항목에 대해 적용되며, 단순히 UI를 정렬하여 해당 설정을 쉽게 사용할 수 있게 표시하는 방법은 없습니다.

  • 해결된 문제 72444: 사용자가 VMware SD-WAN Edge에 대해 IPv4 및 IPv6 BGP 인접 항목을 구성한 다음, 켜짐/꺼짐 슬라이딩 버튼을 사용하여 BGP 설정을 해제하려고 하면 구성이 저장되지 않고 VMware SASE Orchestrator UI에 "변경 내용 없음"이 표시됩니다.

    사용자가 BGP 설정을 구성하지만 BGP를 해제하기도 하는 드문 경우에 BGP 설정에 대한 사용자 작업은 저장되지 않습니다.

  • 해결된 문제 73234: DCC(동적 비용 계산)가 사용되지 않고 많은 수의 학습된 경로가 있는 고객 엔터프라이즈의 경우 BGP가 시작되거나 다시 시작된 후에 VMware SASE Orchestrator가 BGP 경로를 애드버타이즈하는 데 시간이 오래 걸릴 수 있습니다.

    이 문제는 수백 개 이상의 학습된 경로가 있는 엔터프라이즈에 영향을 미치며 경로 수가 훨씬 더 많은 경우(예: ~2K개 경로) Orchestrator가 모든 경로를 애드버타이즈하는 데 10분 이상 걸릴 수 있습니다. 이 문제에 대한 수정 사항은 DCC가 없는 경우 경로 컨버전스의 속도를 향상시킵니다.

  • 해결된 문제 74251: VMware SD-WAN Edge는 Orchestrator API를 통해 구성된 LAN 측 NAT 규칙의 포트 번호를 적용하지 않습니다.

    이 문제는 Orchestrator UI를 통해 LAN 측 NAT 규칙을 구성하는 사용자에게는 영향을 주지 않습니다. LAN 측 NAT 규칙의 일부로 구성된 포트가 VMware SASE Orchestrator에서 Edge로 제대로 푸시되지 않습니다. LAN 측 NAT 규칙이 updateConfigurationModule API 메서드를 통해 구성되고 문자열 값이 "insidePort" 또는 "outsidePort"에 대해 전달된 경우 이전에는 Orchestrator API가 요청을 허용했습니다. 그러나 Edge는 해당 문자열 값을 수용하지 않으며 정수를 요구합니다. Orchestrator API 유효성 검사 논리가 문자열 값을 거부하도록 수정되었습니다(이제 API 참조에 이미 설명된 것과 일관된 방식으로 동작함).

  • 해결된 문제 74592: 더 긴 기간(예: 1년)에 대한 링크 통계 쿼리가 VMware SASE Orchestrator에서 결과를 반환하는 데 시간이 오래 걸립니다.

    코드의 타임스탬프 형식을 보장하기에 충분한 검사가 Orchestrator에서 수행되지 못하며 enterpriseLogicalID도 없기 때문에 쿼리하는 데 시간이 오래 걸립니다.

  • 해결된 문제 75186: VMware SASE Orchestrator 또는 VMware SD-WAN Gateway에서 소프트웨어 결합을 설정하면 결합 인터페이스 MAC 주소가 시스템 전체에서 고유하지 않아 네트워크에서 MAC 주소 충돌이 발생할 수 있습니다.

    이 문제는 시스템이 소프트웨어 결합을 사용하도록 설정된 동일한 서브넷에 배포된 경우에만 발생합니다. 소프트웨어 결합 인터페이스의 MAC 주소는 /etc/machine-id에서 파생됩니다. 이 파일은 릴리스 4.2.1 이전의 Orchestrator 및 게이트웨이 버전에서 배포하는 동안에는 무작위로 지정되지 않습니다.

    Orchestrator 또는 게이트웨이와 4.2.1 이전의 소프트웨어 이미지에서 동일한 서브넷에 배포된 시스템에 대해 소프트웨어 결합을 사용하는 고객은 VMware 지원 팀에 문의하여 문제를 해결하십시오.

  • 해결된 문제 75431: VMware SASE Orchestrator의 새 UI에서 NSD(비 SD-WAN 대상) 구성을 검사하는 경우 '로컬 인증 ID'(FQDN 정보)가 누락됩니다.

    모니터링(Monitor) > 네트워크 서비스(Network Services) > 게이트웨이를 통한 비 SD-WAN 대상(Non SD-WAN Destinations via Gateway)으로 이동한 후 세부 정보(Details)를 선택하면 FQDN 정보가 포함된 '로컬 인증 ID(Local Auth ID)' 필드가 표시되지 않습니다. 이 정보가 클래식 UI에는 올바르게 표시됩니다.

  • 해결된 문제 75656: 경우에 따라 VMware SD-WAN Edge의 라우팅 이벤트를 처리한 후 VMware SD-WAN Orchestrator가 빈 승인(응답 없음과 같은 잘못된 문제)으로 응답하고 이로 인해 Orchestrator의 로드가 증가합니다.

    Orchestrator가 Edge의 라우팅 이벤트에 빈 승인을 전송하면 Edge는 경로를 지속적으로 재시도하므로 Orchestrator의 로드가 증가합니다.

  • 해결된 문제 75879: 경우에 따라 VMware SASE Orchestrator가 VMware SD-WAN Edge의 라우팅 이벤트에 응답하지 않으므로 Orchestrator의 로드가 증가합니다.

    Orchestrator가 Edge의 라우팅 이벤트에 응답하지 않으면 Edge는 경로를 지속적으로 재시도하므로 Orchestrator의 로드가 증가합니다. 이는 이 문제에 대한 영구적인 수정 사항입니다.

  • 해결된 문제 75895: 일부 CSS 터널 이벤트에 대해 Edge CSS(클라우드 보안 서비스) 터널 경고 생성을 건너뛸 수 있습니다.

    고객의 Edge에 클라우드 보안 서비스가 구성되어 있고 Edge에서 동시에 터널 실행/종료 이벤트가 있는 경우 VMware SASE Orchestrator가 모든 이벤트에 대한 경고를 생성하지 못할 수 있습니다.

  • 해결된 문제 76001: [모니터링(Monitor)] &gt; [Edge] 페이지의 그래프 날짜가 VMware SASE Orchestrator의 클래식 UI와 새 UI 사용자 인터페이스에서 약간 다를 수 있습니다.

    사용자가 클래식 UI와 새 UI 모두에서 [Edge 모니터링(Monitor Edges)] 목록 페이지로 이동한 다음, Edge를 선택하고 [전송(Transport)] 탭(클래식 UI) 또는 [링크(Links)] 탭(새 UI)을 보는 경우 시간이 정확하게 일치하지 않을 수 있습니다.

  • 해결된 문제 76008: VMware SASE Orchestrator에서 엔터프라이즈를 복제할 때 선택한 운영자 프로필이 원래 상위 엔터프라이즈에 할당되지 않은 경우 복제 작업이 실패합니다.

    복제 중인 엔터프라이즈에 할당되지 않은 소프트웨어 이미지가 새 엔터프라이즈에 할당되면 오류를 나타내며 API 호출이 실패합니다.

    이 수정 사항을 적용하지 않는다면 이 문제의 해결 방법은 처음에 새 엔터프라이즈에 복제된 엔터프라이즈와 동일한 소프트웨어 이미지를 할당한 다음에 원하는 운영자 프로필로 변경하는 것입니다.

  • 해결된 문제 76016: VMware SASE Orchestrator를 릴리스 4.3.0 이상으로 업그레이드한 후 파트너 게이트웨이 핸드오프가 설정되면 파트너 관리자는 핸드오프 내부의 모든 하위 구성 요소(예: BGP/BFD/고정 경로)를 Orchestrator UI 또는 API에서 삭제할 수 없습니다.

    이 문제는 Orchestrator 백엔드에서 하위 구성 요소 구성을 삭제하기 위한 논리의 회귀로 인해 발생했습니다. 이전에는 파트너 관리자가 파트너 게이트웨이를 수정한 경우 클라우드 게이트웨이 핸드오프 구성에 영향을 주지 않는 혼합 게이트웨이 풀(클라우드 + 파트너 게이트웨이)에 대한 수정 사항이 추가되었습니다. 그러나 이 버그 수정에서는 하위 구성 요소 삭제와 관련된 경우를 고려하지 않았습니다.

    이 수정 사항을 적용하지 않을 경우 두 가지 해결 방법이 있습니다. a) 파트너가 운영자 사용자(예: VMware 지원)에게 아무 문제 없이 삭제를 수행하도록 요청할 수 있습니다. MSP 사용자에게만 영향을 줍니다. 또는 b) 수정된 구성을 사용하여 파트너 게이트웨이에 대한 전체 핸드오프를 제거했다가 다시 생성할 수 있습니다.

  • 해결된 문제 76078: VMware SASE Orchestrator를 4.5.0으로 업그레이드하면 일부 역할 권한이 제거됩니다. 역할 사용자 지정 패키지에 해당 권한 목록이 포함되어 있으면 패키지가 Orchestrator에 적용되지 않습니다.

    Orchestrator를 하위 릴리스에서 4.5.0으로 업그레이드한 후 4.5.0에서 제거된 권한 목록을 해당 패키지에서 사용할 수 있는 경우 Orchestrator가 기존 역할 사용자 지정 패키지를 적용하지 않습니다.

  • 해결된 문제 76442: 고객이 할당한 게이트웨이 풀에서 게이트웨이를 제거한 후 고객의 파트너 게이트웨이 핸드오프 구성을 업데이트할 때 가상 API 검증 오류가 발견되었습니다.

    이전에 핸드오프 설정이 구성된 파트너 게이트웨이가 게이트웨이 풀에서 제거되면 Orchestrator는 고객 수준 핸드오프 설정에서 해당 게이트웨이에 대한 핸드오프 설정을 지우지 않습니다. 그 결과 API 클라이언트가 오래된 게이트웨이 설정을 고의로 제거하지 않으면 API를 통해 고객 수준 핸드오프 설정을 업데이트하려는 후속 시도가 실패합니다.

    이 수정 사항을 적용하지 않으면 고객은 다음을 수행하여 이 문제를 해결할 수 있습니다. 고객 게이트웨이 핸드오프 설정을 업데이트할 때 API 클라이언트는 설정에 표시되는 모든 게이트웨이가 현재 고객 게이트웨이 풀에 있는지 미리 확인할 수 있습니다.

  • 해결된 문제 76508: VMware SASE Orchestrator가 업그레이드되면 BGP를 사용하는 고객의 경우 [네트워크 서비스(Network Services)] &gt; [BGP 인접 항목 상태(BGP Neighbor State)]에서 Edge BGP 경로가 실제로 [설정됨(ESTABLISHED)] 상태일 때 VMware SD-WAN Edge에서는 [제거됨(REMOVED)] 상태가 표시될 수 있습니다.

    이 문제가 발생하면 [원격 진단(Remoted Diagnostics)] > [BGP 문제 해결(Troubleshoot BGP)] > [BGP 요약 표시(Show BGP Summary)]를 사용하여 실제 Edge BGP 상태를 확인할 수 있습니다. 이 문제는 Edge에서 [BGP 인접 항목 요약(BGP Neighbor Summary)] 특성에 대해 잘못된 세그먼트 ID를 Orchestrator로 전송하고 [BGP 인접 항목 요약(BGP Neighbor Summary)]에 제거됨(REMOVED) 상태를 추가하는 방식으로 4.5.0 Orchestrator 코드가 변경되었기 때문에 발생합니다. [BGP 인접 항목 요약(BGP Neighbor Summary)]은 이전 레코드를 비교하고 BGP 인접 항목 주소 및 세그먼트 ID로 구성된 고유한 키를 기준으로 연결이 설정됨(ESTABLISHED)인지 아니면 제거됨(REMOVED)인지를 계산합니다. 부정확한 세그먼트 ID로 인해 Orchestrator UI에 제거됨(REMOVED) 레코드가 최신 상태로 표시됩니다.

    이 수정 사항을 적용하지 않은 상태에서 Orchestrator에서 이 문제가 발생하는 경우 BGP를 반송하고 경로를 다시 설정하면 영향을 받는 모든 Edge에 대한 BGP 상태가 수정됩니다.

  • 해결된 문제 77515: 수퍼유저 역할이 있는 파트너 관리자가 [구성(Configure)] &gt; [고객(Customer)] 페이지에서 고객에게 소프트웨어 이미지를 할당한 경우 변경 내용을 저장하려고 하면 오류가 발생하고 작업이 실패합니다.

    파트너 사용자가 이벤트 ‘할당된 소프트웨어 이미지 목록을 수정함(Modified the assigned software image list)’을 로깅하여 '할당된 소프트웨어/펌웨어 이미지(Assigned Software/Firmware Images)'를 업데이트하는 경우 ’removedSoftwareImages’에서 해당 이벤트에 대해 소프트웨어/펌웨어 이미지를 제거하지 않으면 특정 운영자에 대해 VELOCLOUD_CONFIGURATION_MODULE에 있는 모든 imageUpdate 모듈의 이미지를 처리하고 나열했습니다. 실제로 파트너 사용자가 작업을 수행함으로 인해 오류가 발생하고 고객의 기본 소프트웨어 이미지를 변경할 수 없을때 이 프로세스의 논리가 중단됩니다.

  • 해결된 문제 78684: Azure 유형으로 게이트웨이를 통한 비 SD-WAN 대상(Non SD-WAN Destination via Gateway)을 사용하는 고객 엔터프라이즈의 경우 재동기화하면 구성의 고정 경로가 예상대로 전파되지 않을 수 있습니다.

    Orchestrator UI에서 서브넷을 추가하거나 제거하면 매개 변수 집합이 API를 통해 전달됩니다. 하지만 재동기화하는 동안 매개 변수가 API에 필요한 매개 변수와 유사하지 않습니다. 이로 인해 재동기화 옵션이 올바르게 작동하지 않습니다. 이 문제가 Azure 환경에서 서브넷이 업데이트된 경우에도 발생하면 다른 구성 위치로 제대로 전파되지 않을 수 있습니다.

  • 해결된 문제 79981: 영어가 아닌 버전의 UI를 보는 글로벌 고객에게 VMware SASE Orchestrator UI의 지역화된 버전에 사용되는 일부 사용자 인터페이스 용어가 명확하지 않습니다.

    인터페이스 용어 번역이 4.5.1 Orchestrator에서 개선되었습니다. 이러한 개선 사항은 고객 피드백에 따라 구현되었으며 글로벌 고객을 위해 사용자 인터페이스 번역을 전반적으로 개선했습니다.

  • 해결된 문제 80197: 사용자가 Zscaler에 대한 새 CSS(클라우드 보안 서비스) 터널(GRE)을 생성할 때 VMware SD-WAN Edge 관점 및 Zscaler 관점에서 이러한 터널이 성공적으로 배포되고 터널 이벤트가 표시되지만 VMware SASE Orchestrator에 터널 상태가 표시되지 않습니다.

    자동화된 배포를 위한 기본 터널링 프로토콜 옵션은 IPsec입니다. 사용자가 GRE 옵션을 선택하고 자동화된 배포를 'True'로 전환하면 기본 옵션이 GRE로 저장되어 비 SD-WAN 대상 레코드를 건너뛰고 누락된 터널 이벤트가 모니터링됩니다.

    이 수정 사항이 없으면 사용자는 [터널링 프로토콜(Tunneling Protocol)] 확인란을 계속 전환하지 않고 CSS 제공자를 생성해야 합니다.

  • 해결된 문제 80930: 사용자가 IPsec 터널이 구성된 [Edge를 통한 NSD(비 SD-WAN 대상)(Non SD-WAN Destinations (NSD) via Edge)]을 사용하는 고객 엔터프라이즈에 새 비즈니스 정책을 추가하면 중복된 IPsec 터널 항목이 생성될 수 있습니다.

    이 문제가 발생하면 비즈니스 정책이 추가될 때 Orchestrator UI의 [구성(Configure)] > [디바이스 설정(Device Settings)] > [분기-Edge를 통한 비 SD-WAN 대상(Branch to Non SD-WAN Destination via Edge)] 섹션에서 중복된 항목이 확인될 수 있습니다. 이러한 중복 항목을 삭제해야 하며 이 문제가 발생하면 구성 세부 정보를 다시 입력해야 합니다.

  • 해결된 문제 80963: [Edge] &gt; [모니터링(Monitor)] &gt; [QoE] 탭에서 시간 간격 범위를 변경하면 선택한 시간 간격 범위에 따라 한 타임스탬프에 반영된 샘플이 변경되어 새 타임스탬프로 전환될 수 있습니다.

    샘플 크기의 반올림 문제로 인해 [QoE] 탭에서 쿼리된 더 긴 시간 범위 동안 타임스탬프가 더 일찍 전환됩니다. 예를 들어 오전 10시 2분에 발생한 이벤트는 작은 시간 범위(예: 1시간) 동안 제대로 표시되지만 더 큰 시간 범위(예: 6시간)에 대해 쿼리할 때 샘플이 일찍(10:00 A.M.) 표시되어 사용자에게 혼란을 줄 수 있습니다.

  • 해결된 문제 81835: VMware SASE Orchestrator UI의 [모니터링(Monitor)] &gt; [Edge] &gt; [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로 수정할 수 없는 경우 수퍼유저 또는 운영자가 사용자의 새 암호를 수동으로 입력한 다음, 영향을 받는 사용자와 공유합니다. 이러한 사용자가 다시 로그인한 후에 다른 암호를 재구성할 수 있도록 하는 것이 유일한 옵션입니다.

  • 해결된 문제 82839: 사용자가 VMware SASE Orchestrator에서 Zscaler Cloud Security Service 터널에 대해 IPsec 자동화 삭제 작업을 수행하는 경우 해당 Zscaler 위치와 연결된 모든 VPN 자격 증명도 삭제되며 위치 자체도 삭제됩니다.

    IPsec 자동화 삭제 작업은 Zscaler 위치에서 연결된 VPN 자격 증명만 삭제해야 합니다. 해당 Zscaler 위치에 연결된 다른 모든 VPN 자격 증명은 영향을 받지 않은 상태를 유지해야 합니다.

  • 해결된 문제 83165: 운영자 사용자는 고객과 파트너에게 동일한 게이트웨이 풀이 있더라도 동일한 게이트웨이 풀이 없다는 이유로 VMware SASE Orchestrator에서 고객을 의 파트너로 전송할 수 없습니다.

    이 문제는 API 호출 network/getNetworkEnterpriseProxies가 게이트웨이 풀 세부 정보를 반환하지 않고, Orchestrator가 파트너 및 고객에게 동일한 게이트웨이 풀이 없다고 판단하도록 하고 할당을 거부하기 때문에 발생합니다.

  • 해결된 문제 83699: VMware SASE Orchestrator의 새 UI에서 VMware SD-WAN Gateway가 중지 모드로 설정된 경우 사용자가 교체용 게이트웨이를 새로 선택하면 Orchestrator는 교체 게이트웨이에 대한 구성 변경을 허용하지 않습니다.

    이 문제는 중지된 게이트웨이를 대체하는 새 게이트웨이를 선택하는 Orchestrator의 새 UI 부분을 통해 비 SD-WAN 대상 마이그레이션 프로세스를 활성화한 후에 발생합니다. 새 게이트웨이가 교체용 게이트웨이로 지정된 경우 교체용 게이트웨이의 구성을 변경하려고 하면 운영자에게 다음과 유사한 오류 메시지가 표시됩니다. "GATEWAY_SERVICE_STATE_INVALID: 교체용 게이트웨이로 이미 사용되고 있으므로 게이트웨이의 상태를 null로 변경할 수 없음."

Cloud Web Security의 해결된 문제

버전 R451-20220517-GA에서 해결됨

아래 문제는 버전 R450-20220502-GA 이후에 해결되었습니다.

  • 해결된 문제 69211: Cloud Web Security 서비스에 URL 필터링에 대한 규칙을 추가할 때 [소스 선택(Select Source)] 및 [대상 선택(Select Destination)]에 대한 도메인 이름 프롬프트가 UI에 완전히 표시됩니다.

    도메인이 제대로 구성되었는지 확인하려면 도메인을 완전히 표시해야 합니다.

  • 해결된 문제 69346: 사용자는 Secure Access 트래픽과 연결된 Cloud Web Security 정책을 삭제할 수 있습니다.

    사용자가 Cloud Web Security UI 및 [구성(Configure)] 탭으로 이동한 후 Secure Access 트래픽과 연결된 보안 정책을 선택하고 삭제하도록 선택하면, 실패하고 오류가 발생되어야 하는 상황에서 시도가 성공합니다.

  • 해결된 문제 69959: VMware Cloud Web Security 서비스가 전환될 때 트래픽 손실이 확인됩니다.

    사용자가 Cloud Web Security를 활성화 또는 비활성화하면 프로브가 실행 중인 경우에도 Cloud Web Security에 대한 기본 경로가 False로 표시되고, CWS 경로의 연결 가능성이 업데이트되지 않을 수 있기 때문에 결과적으로 트래픽이 삭제됩니다.

  • 해결된 문제 70005: VMware Cloud Web Security를 사용하는 경우 사용자는 기존 보안 정책을 편집하고 빈 이름으로 바꾼 후 저장할 수 있습니다.

    사용자는 빈 이름으로 보안 정책을 생성할 수 없지만 기존 정책을 편집하여 이름을 비워 두도록 구성할 수 있으며 Orchestrator는 변경을 허용하고 오류를 발생시키지 않습니다.

  • 해결된 문제 71073: VMware Cloud Web Security 서비스를 사용하는 고객의 경우 CASB가 고객 엔터프라이즈에 대해 꺼짐으로 구성된 경우에도 고객 관리자에게 해당 기능이 포함된 VMware SASE Orchestrator UI가 표시됩니다.

    이 문제는 고객 관리자에게만 영향을 미칩니다. 운영자 및 파트너 관리자에게는 올바른 UI 화면이 표시됩니다.

  • 해결된 문제 74013: VMware SASE Orchestrator는 Advanced에서 Standard로 변경된 CASB 라이센스에 맞게 조정되지 않습니다.

    고객이 Advanced CASB 라이센스로 시작하고 해당 라이센스와 관련된 규칙을 나중에 Standard CASB 라이센스로 전환하도록 구성하는 경우 사용자는 Advanced CASB 라이센스에서 생성된 규칙을 변경하고 변경 내용을 적용할 수 있습니다.

  • 해결된 문제 86083: VMware Cloud Web Security 서비스를 사용하는 고객의 경우 Cloud Web Security 이벤트 로그에 중요한 세부 정보가 없습니다.

    이벤트 로그에 다음 세부 정보가 포함되지 않습니다.

    • 구성 변경의 경우 이벤트에 사용자 이름이 포함되지만 변경된 내용은 포함되지 않습니다.

    • Cloud Web Security 규칙이 삭제되면 Orchestrator는 삭제된 데이터를 이벤트에 포함하지 않습니다.

    • 인증을 설정하거나 해제해도 이벤트에 대한 타임스탬프가 포함되지 않습니다.

    • CASB 이벤트의 경우 애플리케이션 이름이 아닌 애플리케이션 ID만 포함됩니다.

Secure Access의 해결된 문제

버전 R451-20220517-GA에서 해결됨

아래 문제는 버전 R450-20220502-GA 이후에 해결되었습니다.

  • 해결된 문제 70493: 고객이 VMware Secure Access 서비스 구성을 편집하고 Cloud Web Security 정책의 연결을 비활성화/제거하면 구성 저장이 실패합니다.

    Cloud Web Security 정책이 제거되는 Secure Access 서비스 구성 편집이 "잘못된 CWS 정책" 오류를 나타내며 실패합니다.

  • 해결된 문제 71078: 고객 서브넷 비트가 수정되면 Secure Access 배포 편집이 실패하여 Secure Access 서비스가 사용할 수 없게 렌더링되는 것을 확인할 수 있습니다.

    이 수정 사항이 없으면 고객은 기존 SA 서비스를 삭제한 후 새 고객 서브넷으로 다시 생성하여 배포가 성공적으로 수행되도록 할 수 있습니다.

  • 해결된 문제 70098: VMware Secure Access 서비스 배포는 완료되지만 UEM 또는 라우팅 트래픽에서 구성을 가져오지 못합니다.

    VMware Gateway는 제어부 구성의 일부로 'ras' 구성을 수신합니다. 그러나 게이트웨이와 연결된 모든 Secure Access 서비스에 대해 구성이 비어 있는 것으로 표시됩니다. 이 문제는 터널 서비스 상태 점검을 위한 Secure Access 엔터프라이즈 개체의 최근 변경으로 인한 구문 분석 오류 때문에 발생합니다.

알려진 문제

릴리스 4.5.1의 미해결 문제

Edge/게이트웨이의 알려진 문제

  • 문제 14655:

    SFP 어댑터를 연결하거나 연결을 해제하면 디바이스가 Edge 540, Edge 840 및 Edge 1000에서 응답을 중지하고 물리적 다시 부팅을 요구할 수 있습니다.

    해결 방법: Edge를 물리적으로 다시 부팅해야 합니다. 이 작업은 원격 작업(Remote Actions) > Edge 다시 부팅(Reboot Edge)을 사용하여 Orchestrator에서 수행하거나 Edge를 껐다가 다시 켜는 방법으로 수행할 수 있습니다.

  • 문제 25504:

    고정 경로 비용이 255보다 크면 경로 순서가 예기치 않게 지정될 수 있습니다.

    해결 방법: 0 ~ 255 사이의 경로 비용을 사용하십시오.

  • 문제 25595:

    WAN 오버레이에서 고정 SLA 변경 사항이 제대로 적용되려면 다시 시작해야 할 수 있습니다.

    해결 방법: WAN 오버레이에서 고정 SLA를 추가 및 제거한 후 Edge를 다시 시작하십시오.

  • 문제 25742:

    언더레이로 인한 트래픽은 게이트웨이에 연결되지 않은 개인 WAN 링크의 용량보다 낮은 경우에도 VMware SD-WAN Gateway의 최대 용량으로 제한됩니다.

  • 문제 25758:

    VMware SD-WAN Edge가 다시 부팅될 때까지 한 USB 포트에서 다른 USB 포트로 전환되면 USB WAN 링크가 제대로 업데이트되지 않을 수 있습니다.

    해결 방법: 한 포트에서 다른 포트로 USB WAN 링크를 이동한 후에 Edge를 다시 부팅합니다.

  • 문제 25855:

    파트너 게이트웨이의 대규모 구성 업데이트(예: 200BGP 지원 VRF)로 인해 VMware SD-WAN Gateway를 통한 일부 트래픽에 대해 약 2-3초 동안 지연 시간이 증가할 수 있습니다.

    해결 방법: 사용할 수 있는 해결 방법이 없습니다.

  • 문제 25921:

    허브에 연결된 분기 Edge가 3,000개 있는 경우 VMware SD-WAN Hub 고가용성 페일오버가 예상보다 오래(최대 15초) 걸립니다.

  • 문제 25997:

    전환된 포트로 변환한 라우팅된 인터페이스에서 트래픽을 올바르게 전달하려면 VMware SD-WAN Edge를 다시 부팅해야 할 수 있습니다.

    해결 방법: 구성을 변경한 후에 Edge를 다시 부팅합니다.

  • 문제 26421:

    클러스터에 대한 터널을 설정하려면 모든 분기 사이트에 대한 기본 파트너 게이트웨이를 VMware SD-WAN Hub 클러스터에도 할당해야 합니다.

  • 문제 28175:

    NAT IP가 VMware SD-WAN Gateway 인터페이스 IP와 겹치면 비즈니스 정책 NAT가 실패합니다.

  • 문제 31210:

    VRRP: VMware SD-WAN Edge가 LAN 인터페이스에서 실행되는 비 글로벌 CDE 세그먼트에서 기본인 경우 ARP가 LAN 클라이언트에서 VRRP 가상 IP 주소로 확인되지 않습니다.

  • 문제 32731:

    OSPF를 통해 애드버타이즈된 조건부 기본 경로는 경로가 해제되어 있을 때 제대로 철회되지 않을 수 있습니다. 경로를 다시 사용하도록 설정했다가 비활성화하면 성공적으로 취소됩니다.

  • 문제 32960:

    활성화된 VMware SD-WAN Edge에 대한 로컬 웹 UI에 인터페이스 "자동 협상(Autonegotiation)" 및 "속도(Speed)" 상태가 잘못 표시될 수 있습니다.

  • 문제 32981:

    DPDK 지원 포트에서 속도 및 전이중을 하드 코딩하면 DPD를 해제해야 하므로 구성을 적용하려면 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을 사용하여 현재 전송 중인 기존 흐름이 중단될 수 있습니다.

  • 문제 40096:

    활성화된 VMware SD-WAN Edge 840을 다시 부팅하면 링크 표시등이 켜지고 VMware SD-WAN Orchestrator가 포트를 [실행 중(Up)]으로 표시하더라도 Edge에 연결된 SFP 모듈이 트래픽 전달을 중지하게 될 수 있습니다.

    해결 방법: 포트에서 SFP 모듈을 뽑았다가 다시 꽂습니다.

  • 문제 40421:

    인터페이스가 전환된 포트로 구성된 VMware SD-WAN Edge를 통과하는 경우 Traceroute에 해당 경로가 표시되지 않습니다.

  • 문제 42278:

    특정 유형의 피어 구성 오류가 있을 때 VMware SD-WAN Gateway가 계속해서 비 SD-WAN 피어에 IKE 초기화 메시지를 보낼 수 있습니다. 이 문제로 인해 게이트웨이에 대한 사용자 트래픽이 중단되지는 않습니다. 그러나 게이트웨이 로그가 IKE 오류로 채워질 수 있으며, 이로 인해 유용한 로그 항목이 모호해질 수 있습니다.

  • 문제 42388:

    VMware SD-WAN Edge 540에서 VMware SD-WAN Orchestrator의 인터페이스를 비활성화했다가 다시 사용하도록 설정한 후에 SFP 포트가 감지되지 않습니다.

  • 문제 42488:

    스위치 또는 라우팅된 포트에 대해 VRRP를 사용하도록 설정된 VMware SD-WAN Edge에서 케이블이 포트에서 연결이 끊기고 Edge 서비스가 다시 시작되면 LAN 연결 경로가 애드버타이즈됩니다.

    해결 방법: 이 문제에 대한 해결 방법은 없습니다.

  • 문제 42872:

    허브 클러스터가 연결된 허브 프로필에서 프로필 분리를 사용하도록 설정하면 RIB(라우팅 정보 기반)의 허브 경로가 해지되지 않습니다.

  • 문제 43373:

    여러 VMware SD-WAN Edge에서 동일한 BGP 경로를 학습한 경우 오버레이 흐름 제어에서 이 경로가 기본 설정에서 적격 종료로 전환되면 Edge는 애드버타이즈 목록에서 제거되지 않고 계속 애드버타이즈됩니다.

    해결 방법: VMware SD-WAN Orchestrator에서 분산 비용 계산을 사용하도록 설정합니다.

  • 문제 44995:

    OSPF 경로가 허브 클러스터에서 철회되는 경우 VMware SD-WAN Gateway와 VMware SD-WAN 스포크 Edge에서 해지되지 않습니다.

  • 문제 45189:

    소스 LAN 측 NAT가 구성된 경우, NAT 서브넷에 대한 고정 경로 구성 없이도 VMware SD-WAN 스포크 Edge에서 허브 Edge로의 트래픽이 허용됩니다.

  • 문제 45302:

    VMware SD-WAN Hub 클러스터에서 한 허브에서 허브와 할당된 스포크 Edge 사이에 공통되는 모든 VMware SD-WAN Gateway와의 연결이 5분 넘게 끊어지면 드문 경우에 스포크가 5분 후에 허브 경로를 보존하지 못할 수 있습니다. 이 문제는 허브가 게이트웨이와 다시 연결될 때 자체적으로 해결됩니다.

  • 문제 46053:

    인접 항목이 업링크 인접 항목으로 변경될 때 BGP 기본 설정이 오버레이 경로에 맞춰 자동으로 수정되지 않습니다.

    해결 방법: Edge 서비스를 다시 시작하면 이 문제가 해결됩니다.

  • 문제 46137:

    3.4.x 소프트웨어를 실행하는 VMware SD-WAN Edge는 Edge가 GCM에 대해 구성된 경우에도 AES-GCM 암호화로 터널을 시작하지 않습니다.

  • 문제 46216:

    피어가 AWS 인스턴스인 게이트웨이 또는 Edge를 통한 비 SD-WAN 대상에서 피어가 2단계 키 재생성을 시작하면 1단계 IKE도 삭제되고 키 재생성이 강제로 다시 실행됩니다. 즉, 터널이 손상되었다가 다시 구축되면 터널 재구축 중에 패킷 손실이 발생합니다.

    해결 방법: 터널 소멸을 방지하려면 게이트웨이/Edge를 통한 비 SD-WAN 대상 또는 CSS IPsec 키 재생성 타이머를 60분 미만으로 구성합니다. 이로 인해 AWS가 키 재생성을 시작하지 못합니다.

  • 문제 46391:

    VMware SD-WAN Edge 3800의 경우, 각각 SFP1 및 SFP2 인터페이스에 다중 속도 SFP(1/10G)에 문제가 있으며 해당 포트에서 사용하면 안 됩니다.

    해결 방법: KB 문서 VMware SD-WAN 지원 SFP 모듈 목록(79270)에 따라 단일 속도 SFP를 사용하십시오. 다중 속도 SFP는 SFP3 및 SFP4에서 사용할 수 있습니다.

  • 문제 46918:

    3.4.2 릴리스를 사용하는 VMware SD-WAN 스포크 Edge가 클러스터 허브 노드의 개인 네트워크 ID를 올바르게 업데이트하지 않습니다.

  • 문제 47084:

    VMware SD-WAN Hub Edge에는 4000 스포크 Edge가 연결된 경우 750개보다 많은 PIM(프로토콜 독립 멀티캐스트) 인접 항목을 설정할 수 없습니다.

  • 문제 47664:

    허브 VPN을 통한 분기 간 방식이 사용하도록 설정되지 않은 허브 및 스포크 구성에서 L3 스위치/라우터의 요약 경로를 사용하여 분기 간 트래픽을 유턴하려고 하면 라우팅 루프가 발생합니다.

    해결 방법: 분기 간 VPN을 설정하도록 클라우드 VPN을 구성하고 "VPN에 대해 허브 사용"을 선택합니다.

  • 문제 47681:

    VMware SD-WAN Edge의 LAN 측 호스트가 Edge의 WAN 인터페이스와 동일한 IP를 사용하는 경우 LAN 호스트에서 WAN으로의 연결이 작동하지 않습니다.

  • 문제 48166:

    Ciena 가상화 OS를 사용하는 경우 KVM의 VMware SD-WAN 가상 Edge가 지원되지 않으며 Edge에서 데이터부 서비스 장애가 반복적으로 발생합니다.

  • 문제 48175:

    비 글로벌 세그먼트에 글로벌 세그먼트에 구성된 인터페이스와 동일한 IP 범위에 구성된 인터페이스가 있는 경우, 릴리스 3.4.2를 실행하는 VMware SD-WAN Edge가 비 글로벌 세그먼트에서 OSPF 인접 메뉴를 형성합니다.

  • 문제 48502:

    일부 시나리오에서 인터넷 트래픽을 백홀하는 데 사용되는 VMware SD-WAN Hub Edge가 백홀 반환 패킷의 잘못된 처리로 인해 데이터부 서비스 장애가 발생할 수 있습니다.

  • 문제 48530:

    VMware SD-WAN Edge 6x0 모델은 삼중 속도(10/100/1000Mbps) Copper SFP의 자동 협상을 수행하지 않습니다.

    해결 방법: Edge 520/540은 삼중 속도 Copper SFP를 지원하지만 이 모델은 2021년 1사분기까지 판매 종료되는 것으로 표시되었습니다.

  • 문제 48597: 피어에 대한 두 경로 중 하나가 종료된 경우 멀티 홉 BGP 인접 관계가 유지되지 않음

    여러 경로가 있고 경로 중 하나가 종료된 피어에 대해 멀티 홉 BGP 인접 관계가 있는 경우 해당 BGP 인접 관계가 종료되고 사용 가능한 다른 경로를 사용해도 실행되지 않는다는 알림이 표시됩니다. 여기에는 로컬 IP-루프백 인접 관계 사례도 포함됩니다.

    해결 방법: 이 문제에 대한 해결 방법은 없습니다.

  • 문제 48666:

    IPsec 전면 게이트웨이 경로 MTU 계산은 61바이트의 IPsec 오버헤드를 고려하지 않으므로 LAN 클라이언트로 더 많은 애드버타이즈가 진행되고 후속 IPsec 패킷이 조각화됩니다.

    해결 방법: 이 문제에 대한 해결 방법은 없습니다.

  • 문제 50518:

    PKI를 사용하도록 설정한 VMware SD-WAN Gateway에서 6,000개보다 많은 PKI 터널이 게이트웨이에 연결하려고 하면 인바운드 SA가 삭제되지 않기 때문에 터널이 모두 표시되지는 않을 수 있습니다.

    참고: PSK(사전 공유 키) 인증을 사용하는 터널에는 이 문제가 발생하지 않습니다.

  • 문제 51436: LTE 모뎀을 사용하여 VMware SD-WAN Edge를 배포하는 동안 향상된 고가용성 토폴로지를 사용하는 사이트의 경우 사이트가 "분할 브레인" 상태가 되면 HA 페일오버에 5-6분 정도 소요됩니다.

    분할 브레인 상태에서 복구하면서 LAN 포트는 활성 Edge에서 종료되며, 이러한 상황은 포트가 종료되고 사이트를 복구할 수 있게 될 때까지 LAN 트래픽에 영향을 미칩니다.

    해결 방법: 이 문제에 대한 해결 방법은 없습니다.

  • 문제 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을 활성화하는 것입니다.

  • 문제 63629: VMware SD-WAN Hub Edge 및 스포크 Edge에 다른 IP 패밀리 기본 설정(즉, IPv4/IPv6 이중 스택)이 있는 네트워크 토폴로지에서 피어에 예상보다 더 많은 대역폭이 할당된 것을 볼 수 있습니다.

    두 패밀리 IPv4 및 IPv6를 모두 사용하도록 설정하면 Edge는 두 개의 서로 다른 링크 개체를 내부적으로 생성합니다. 둘 다에 대해 대역폭 값을 하나만 추가해야 하는 경우 대역폭 값이 추가됩니다.

    해결 방법: 이 문제의 해결 방법은 허브/스포크 토폴로지에서 이중 스택을 사용하도록 설정한 경우 다른 터널 기본 설정을 사용하지 않는 것입니다.

  • 문제 64627: VMware SD-WAN Gateway에서 데이터부 서비스가 다시 시작되어 3-5초 동안 트래픽이 중단됩니다.

    VMware SD-WAN Edge의 WAN 링크에 많은 수의 하위 경로가 구성되어 있거나 VCMP(VeloCloud 관리부) 터널이 자주 플래핑되면 카운터가 고갈되고 최종적으로 게이트웨이의 데이터부 서비스가 다시 시작될 수 있습니다.

    해결 방법: 이 문제에 대한 해결 방법은 없습니다.

  • 문제 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를 비활성화해야 합니다.

  • 문제 69562: 파트너 게이트웨이-BGP 및 비 SD-WAN 대상-BGP가 동일한 로컬 ASN(자치 시스템 번호)을 갖는 경우 VMware SD-WAN Gateway에서 트래픽 장애가 발견됩니다.

    PG-BGP와 NSD-BGP 모두 동일한 로컬 ASN을 가지며 NSD-BGP 학습 경로가 PG-BGP로 재배포되면 ASN이 애드버타이즈 전에 경로에서 두 번 앞에 추가됩니다. 이로 인해 AS 경로가 더 짧아지므로 다른 BGP 경로가 이 경로보다 선호될 수 있으며, 이로 인해 트래픽이 잘못된 경로와 일치하게 될 수 있습니다.

    해결 방법: 이 수정 사항을 적용하지 않을 경우 이 문제의 해결 방법은 PG-BGP 및 NSD-BGP에 대해 다른 ASN을 사용하는 것입니다.

  • 문제 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에 연결하는 모든 게이트웨이를 재활성화해야 합니다.

  • 문제 75593: BGP를 사용하는 고객 배포에서는 업링크 BGP 경로에 대한 예기치 않은 경로 기본 설정으로 인해 최적이 아닌 라우팅 때문에 성능 저하 문제가 발생할 수 있습니다.

    이 문제는 경로 접두사가 비업링크에서 업링크로 업데이트되거나 그 반대로 업데이트될 때 고객 엔터프라이즈의 BGP 접두사 애드버타이즈 및 기본 설정 값이 제대로 업데이트되지 않아 비대칭 라우팅이 발생하기 때문에 발생합니다.

    해결 방법: 이 문제에 대한 수정 사항이 없는 고객은 BGP 업링크 커뮤니티를 사용하지 않도록 설정하고 사용하도록 설정하여 올바른 라우팅을 복원할 수 있습니다.

  • 문제 76837: BGP를 사용하는 고객은 피어 라우터가 네트워크 내의 VMware SD-WAN Edge로 트래픽을 전송하지 않는 것을 확인할 수 있습니다.

    이 문제를 해결하면 기본-시작을 통한 기본 경로가 Edge에 의해 애드버타이즈되지 않습니다. 이 문제는 기본 경로와 연결된 경로 맵 문자열이 잘리기 때문에 발생하며, Edge가 기본 경로와 해당 경로 맵의 항목과 일치하지 않게 되며 이로 인해 피어 라우터에서 트래픽이 삭제되거나 트래픽에서 블랙홀이 발생되는 잘못된 경로를 사용하여 전송됩니다.

    해결 방법: 사용자는 수정 사항이 포함된 Edge 버전으로 업그레이드할 수 있을 때까지 피어 라우터에서 기본 경로에 대한 고정 경로를 구성해야 합니다.

  • 문제 78050: PPTP 서버가 LAN 측에 있는 경우 데이터부 서비스 장애가 발생합니다.

    PPTP 서버가 LAN 측에 있고 인터넷의 PPTP 클라이언트가 인바운드 방화벽 규칙을 통해 연결하면 PPTP 제어 채널 조회 실패로 인해 Edge가 충돌할 수 있습니다. GRE 데이터 채널이 동일한 링크를 통해 PPTP 클라이언트로 다시 전송되도록 하려면 이 제어 채널 조회가 필요합니다.

    해결 방법: 이 문제는 PPTP 트래픽이 Edge에 표시되는 경우에만 발생합니다. PPTP 세션을 사용하지 마십시오.

  • 문제 81353: 낮은 버퍼로 인해 인터페이스의 Rx에서 패킷이 삭제될 수 있습니다.

    링 버퍼 설정은 Azure 플랫폼에서 사용되고 있는 비 dpdk 관리형 인터페이스의 일부가 아닙니다. NIC Rx 링 버퍼 대기열은 낮은 값으로 설정됩니다.

    해결 방법: 이 문제에 대해 사용 가능한 해결 방법은 없습니다. 재부팅하면 문제가 일시적으로 해결될 수 있습니다.

  • 문제 81859: VMware SD-WAN Edge 610-LTE를 활성화할 때 Edge가 활성화를 완료한 후 CELL 인터페이스가 실행되지 않을 수 있습니다.

    이 문제는 꾸준히 발생하지 않지만 일단 발생하면 큰 영향을 미칠 수 있습니다. Edge 610-LTE의 유일한 공용 링크가 모바일 CELL 링크인 경우 Edge가 실제로 종료되고 이 Edge에 대한 개입이 사용자가 Edge의 전원을 껐다 켜서 복구하는 방식으로 로컬에서 진행되어야 하기 때문입니다.

    해결 방법: 이 문제가 발생하고 610-LTE에 다른 유선 공용 WAN 링크가 있는 경우 사용자는 적절한 유지 보수 기간에 원격 작업(Remote Actions) > 서비스 다시 시작(Service Restart)을 사용하여 Orchestrator를 통해 Edge 서비스를 다시 시작하거나 Edge의 모뎀을 다시 시작하여 CELL 인터페이스를 복원해야 합니다.

    610-LTE가 인터넷에 대한 CELL 인터페이스만 사용하는 경우 Edge에 로컬인 사용자는 Orchestrator를 통해 Edge에 액세스할 수 없으므로 Edge 전원을 껐다 켜야 합니다.

    활성화하려는 610-LTE Edge가 인터넷에 대해 CELL만 사용하는 경우 활성화를 완료한 후 Edge가 종료되면 사용자가 Edge를 활성화하고 전원을 껐다 켜야 합니다.

  • 문제 82104: 드물게 고가용성 토폴로지에서 활성화된 VMware SD-WAN Edge가 VMware SASE Orchestrator와 통신하지 못해 사이트가 중단된 것으로 표시되고 Orchestrator를 통한 사이트에 대한 모든 개입이 불가능하게 됩니다.

    이 문제는 비정상적이고 잘못된 구성이 HA Edge에 적용되는 경우에만 발생합니다. 구성에 따르면 HA 포트가 VLAN이 0개(허용되지 않아야 함)이지만 [모든 VLAN(all VLANs)]이 설정된 [트렁크](허용되지 않아야 함)로 구성됩니다. 이 구성에서 오류를 발생시키고 사용자가 Edge에 대해 HA를 활성화하지 못하게 하는 대신 Orchestrator는 이를 허용하고 이 구성은 HA Edge에서 관리부 장애를 트리거하여 Orchestrator에 더 이상 하트비트를 전송하지 않으며 Orchestrator는 사이트를 종료된 것으로 표시합니다.

    해결 방법: 위에 설명된 구성을 사용하지 마십시오.

  • 문제 82415: VMware SD-WAN Gateway는 Intel® Ethernet Server Adapter X710, SR-IOV를 사용하여 KVM 이미지를 배포했으며 Bond0은 릴리스 4.5.1 또는 5.0.0.0으로 활성화된 경우 응답하지 않습니다.

    게이트웨이의 경우 배포된 경로가 표시되지 않고 debug.py 명령이 작동하지 않습니다.

    해결 방법: 이 수정 사항을 적용하지 않은 경우 운영자는 이 문제가 해결된 새 빌드가 롤아웃될 때까지 이 특정 게이트웨이 배포에 대해 이러한 빌드를 사용하지 않아야 합니다.

  • 문제 83083: 릴리스 4.3.1 이상으로 업그레이드된 VMware SD-WAN Gateway에서 천천히 진행되는 메모리 누수로 인해 게이트웨이 서비스가 다시 시작되고 메모리가 지워질 수 있습니다.

    게이트웨이 다시 시작은 게이트웨이 서비스가 다시 시작하는 데 소요되는 30~45초 동안 고객 트래픽이 중단될 수 있습니다. 운영자 사용자가 게이트웨이에서 debug.py --flow_dump all all all 명령을 실행할 때마다 게이트웨이에 일부 메모리가 누수됩니다. 이 디버그 명령을 충분한 횟수만큼 실행하면 게이트웨이의 메모리 사용량이 위험 수준에 도달하고 게이트웨이 서비스 다시 시작을 트리거하여 메모리를 지웁니다.

    해결 방법: 게이트웨이에서 debug.py --flow_dump all all all 명령을 실행하지 마십시오. 이 디버그 명령의 사용을 피할 수 없는 경우 메모리 사용량을 모니터링하고 유지 보수 기간을 스케줄링하여 예약되지 않은 다시 시작 전에 서비스를 선점적으로 다시 시작하여 메모리를 지웁니다.

  • 문제 83212: VMware SASE Orchestrator에서 [모니터링(Monitor)] &gt; [Edge] &gt; [전송(Transport)]을 살펴보면 링크 및 애플리케이션 통계 테이블 간에 불일치가 있습니다.

    애플리케이션 및 링크 통계가 일치해야 하지만 애플리케이션 통계에 링크 통계보다 높은 값이 표시됩니다. 이 문제는 스포크 Edge가 단일 WAN 링크를 사용하는 VMware SD-WAN Edge 허브 클러스터 토폴로지가 있는 경우에 가장 일반적으로 발생합니다. 이 단일 WAN 링크에서 손실이 발생하면 패킷이 다시 전송되고 애플리케이션 통계에서 두 번 고려되어 불일치가 표시됩니다.

    해결 방법: 이 문제에 대한 해결 방법은 없지만 이 문제가 발생하는 경우 애플리케이션 통계는 링크 통계와 비해 올바릅니다.

  • 문제 84501: NAS-IP 주소는 기본적으로 RADIUS 패킷에서 루프백 IP 주소로 설정됩니다.

    NAS-IP 주소는 Edge(인증자)에서 Radius 서버로 전송되는 RADIUS 패킷에서 기본적으로 루프백 IP 주소로 설정됩니다. NAS-IP 주소를 RADIUS 인증 설정으로 선택/구성된 소스 인터페이스 IP 주소로 설정합니다. [자동(Auto)]을 소스 인터페이스로 선택한 경우 루프백 IP가 기본적으로 NAS-IP로 설정됩니다.

    해결 방법: 5.0.1.0 릴리스로 업그레이드합니다.

  • 문제 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 이벤트 메시지는 가상이므로 무시해도 됩니다.

  • 문제 85154: 인스턴스 유형이 C4.xlarge인 AWS의 VMware SD-WAN Virtual Edge가 이전 Edge 릴리스에서 릴리스 4.5.1로 업그레이드된 후 이전 Edge 릴리스로 다시 다운그레이드되면 Edge는 Edge가 게이트웨이 및 Orchestrator를 사용하여 관리 터널을 형성하지 않는 비활성화 상태로 전환됩니다.

    이 문제의 원인은 Orchestrator가 일련 번호 불일치로 감지하는 상황으로 인해 Orchestrator에서 Edge를 잘못 비활성화하기 때문입니다.

    해결 방법: AWS Edge가 이 릴리스에 있으면 릴리스 4.5.1에서 다운그레이드하지 않는 것 외에는 해결 방법이 없습니다.

  • 문제 85459: LAN 측 NAT 규칙이 구성된 후 Edge LAN 측 클라이언트에서 Edge로 또는 원격 분기 Edge 클라이언트에서 Edge로 SSH를 수행하려는 시도가 작동하지 않을 수 있습니다.

    Edge의 SSH 프로세스에서 수신되는 SSH 응답 패킷 패킷은 Edge의 데이터부 서비스를 통과하며 LAN 측 NAT 규칙이 구성된 후에 SSH 응답 패킷이 LAN 측 NAT 규칙을 사용하여 SSH 트래픽을 생성한 원래 클라이언트가 아닌 다른 대상으로 이동하면 Edge에 대한 SSH 시도가 작동하지 않을 수 있습니다.

    해결 방법: 유일한 해결 방법은 NAT 규칙을 제거하는 것입니다.

  • 문제 87982: 개인 PPPoE WAN 링크가 있는 Metanoia-type SFP 모듈을 사용하는 VMware SD-WAN Edge가 BGP 피어링을 설정하고 다른 사이트에 연결하지 못할 수 있습니다.

    개인 PPPoE 링크를 사용하여 VLAN 태그가 지정된 패킷이 Edge에 의해 손상되고 결과적으로 대상에 도달하지 않습니다. 이 문제는 공용 PPPoE 링크에 영향을 주지 않습니다.

    해결 방법: 해결 방법은 PPPoE 링크에 대한 트래픽에 VLAN 태그를 지정하지 않거나 링크를 공용으로 설정하는 것입니다.

  • 문제 88604: 고가용성 토폴로지를 사용하는 사이트의 경우 WAN 인터페이스가 종료되었다가 VMware SD-WAN 대기 Edge에서 다시 실행되면 이벤트가 VMware SASE Orchestrator에 기록되지 않습니다.

    대기 Edge가 트래픽을 전달하는 고급 HA 배포에 특히 영향을 미치는 대기 Edge 인터페이스 이벤트는 사용자에게 표시되지 않습니다.

    해결 방법: 이 문제에 대한 해결 방법은 없습니다.

  • 문제 88796: VMware SASE Orchestrator 또는 VMware SD-WAN Gateway를 배포하고 vSphere에서 OVA를 사용하는 경우 배포의 일부로 설정된 OVF 속성(암호, 네트워크 정보 등)이 이미지에 적용되지 않으며 배포 후에 시스템에 액세스할 수 없습니다.

    이것은 OVF/vApp 속성을 사용하여 OVA에서 배포된 새 시스템에만 영향을 줍니다(ISO 파일 사용과 비교). 이 문제는 최근 업데이트에서 cloud-init에 대한 업스트림 변경으로 인해 발생합니다.

    해결 방법: 이 수정 사항을 적용하지 않으면 운영자가 cloud-init user-data ISO 파일을 사용하여 시스템을 배포하는 것이 해결 방법입니다.

  • 문제 89235: 스포크에서 인터넷으로의 백홀 트래픽이 허브에서 삭제될 수 있습니다.

    '스포크의 백홀 트래픽'과 '스포크에서 애드버타이즈된 경로' 간의 타이밍 문제(사후 서비스 다시 시작, 정전 또는 구성 변경)로 인해 'nsch_drop_stale_pi' 카운터가 있는 허브에서 백홀 트래픽이 삭제됩니다.

    해결 방법: 흐름을 플러시하여 문제를 해결합니다.

  • 문제 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의 펌웨어를 확인할 수 있습니다. 그러나 이 방법은 릴리스 4.5.1을 사용하는 Edge에서만 작동합니다.

    이 문제는 6x0 Edge를 플랫폼 펌웨어 1.3.1(R131-20221216-GA)로 업그레이드해야 해결되며, 여기에는 PIC 버전 v20N이 포함됩니다. 이렇게 하려면 릴리스 5.x(5.0.0 이상)를 사용하여 VMware SASE Orchestrator에 연결해야 하며 6x0 Edge를 먼저 Edge 핫픽스 빌드 R5012-20230123-GA-103475로 업그레이드해야 합니다. 6x0 Edge가 R5012-20230123-GA-103475로 업그레이드되면 사용자는 Edge의 소프트웨어 버전이 수정되는 것과 동일한 방식으로 6x0 Edge 플랫폼 펌웨어를 버전 R131-20221216-GA로 업데이트합니다.

    6x0 Edge를 플랫폼 펌웨어 1.3.1로 업그레이드하기 위한 자세한 내용 및 단계별 가이드는 다음 KB 문서를 참조하십시오. VMware SD-WAN 6X0 모델 Edge는 LED 없이 전원이 꺼질 수 있고 전원 주기를 작동 상태로 되돌려야 할 수 있습니다(88970). 이 KB 문서는 문제를 해결하는 데 필요한 새로운 Edge 및 플랫폼 소프트웨어를 반영하기 위해 2023년 1월 27일에 업데이트되었습니다.

    Orchestrator에 플랫폼 펌웨어 번들을 업로드하는 데 대한 자세한 내용은 VMware SD-WAN 운영자 가이드의 새 Orchestrator UI를 사용하는 플랫폼 펌웨어 및 공장 이미지 섹션을 참조하십시오.

    6x0 Edge의 플랫폼 펌웨어 업데이트에 대한 내용은 VMware SD-WAN 관리 가이드의 Edge 정보 보기 또는 수정 섹션을 참조하십시오.

    해결 방법: 문제 상태에서 Edge를 복구하려면 다음을 수행합니다.

    1. 전원에서 Edge의 연결을 끊습니다.

    2. 20초 동안 기다립니다.

    3. Edge를 전원에 다시 연결합니다.

    6x0 Edge의 플랫폼 펌웨어를 업그레이드하지 않으려면 사용자가 Edge의 전원이 일관되고 빠르거나 일관되게 플래핑되지 않도록 할 수 있습니다. 안정적인 전원을 보장하는 적절한 방법은 6x0 Edge를 UPS(무정전 전원 장치)에 연결하는 것입니다.

    Edge를 더 낮은 소프트웨어 릴리스(예: 릴리스 4.3.1 또는 4.5.1)로 유지하려는 경우 고객은 일시적으로 Edge를 R5012-20230123-GA-103475로 업그레이드하고, 플랫폼 펌웨어를 버전 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 버전을 수동으로 업데이트합니다.

  • 문제 91875: VMware SD-WAN Edge에서 WAN 링크를 백업으로 구성한 고객의 경우 링크가 활성 상태가 되는 데 필요한 조건이 없더라도 백업 WAN 링크가 간헐적으로 활성 상태가 되는 것을 볼 수 있습니다.

    이 문제는 Edge가 백업 WAN 링크가 필요하다고 잘못 생각하게 되고 Edge가 이 잘못된 터널을 감지하고 해체하기 위한 페일세이프가 없는 해당 링크에 대한 터널을 구축하도록 하는 Edge 프로세스의 경합 조건으로 인해 발생합니다.

    해결 방법: WAN 링크를 백업 링크로 사용하는 경우 이 문제에 대한 특정 수정 사항이 포함된 핫픽스 빌드 R451-20220714-GA-91875로 Edge를 업그레이드하는 것이 좋습니다.

  • 문제 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개 이상) 메트릭을 구성합니다.

  • 문제 93055: 고가용성 토폴로지로 배포된 고객 사이트의 VMware SD-WAN Edge에서 데이터부 서비스 장애가 발생하고 결과적으로 다시 시작되어 HA 페일오버가 트리거될 수 있습니다.

    고급 HA 토폴로지에서 HA 페일오버가 발생하면 활성 Edge에서 WAN 링크를 사용하는 트래픽이 중단될 수 있습니다. 이 문제는 릴리스 5.x 이전의 빌드로 제한됩니다.

    이 문제가 발생하면 로그에 다음과 유사한 내용이 표시됩니다.

    ERROR [edged 7205(7212)] Process edged (pid 3022) exited on signal SIGABRT: restarting after 3.0 seconds 
INFO [Thread-3 7205(15804)] edged: posted ERROR event EDGE_SERVICE_FAILED

    해결 방법: Edge에서 이 문제가 발생한 경우 고객은 이 문제에 대한 핫 픽스를 사용하여 Edge 빌드로 업그레이드할 수 있습니다. 핫 픽스 빌드는 R451-20221222-GA-93055이며 VMware SD-WAN 지원에 문의하여 파트너 또는 고객에게 업로드할 수 있습니다.

  • 문제 94980: 고가용성 토폴로지로 배포된 사이트의 경우 VMware SD-WAN 대기 Edge에서 데이터부 서비스 오류가 발생하고 HA Edge에 대해 PPPoE WAN 링크가 구성된 후 다시 시작될 수 있습니다.

    대기 Edge에서 생성된 코어를 검사할 때 PPPoE 링크가 구성된 후 vc_is_use_cloud_gateway_set 메시지가 표시됩니다.

    해결 방법: 이 작업의 위험을 관리하기 위해 유지 보수 기간에 PPPoE 링크를 구성하는 것 외에는 이 문제에 대한 해결 방법이 없습니다.

  • 문제 95399: 이 문제는 고객이 Orchestrator에서 이벤트를 모니터링할 때만 나타납니다. 이전에는 인터페이스가 종료되거나 실행 중일 때 인터페이스 실행 중(INTERFACE UP)/종료(DOWN) 이벤트가 트리거되었습니다. 현재는 보고되지 않습니다. 고객은 EDGE_INTERFACE_UP 또는 EDGE_INTERFACE_DOWN 이벤트를 볼 수 없습니다.

    이 문제는 4.5.1 릴리스에 dhclient가 추가되었기 때문에 발생합니다. 이러한 이벤트를 VMware SD-WAN Orchestrator로 보내도록 dhclient가 구성되지 않았습니다.

    해결 방법: 모니터링을 위해 링크 활성/링크 비활성 이벤트도 사용할 수 있습니다. 그러나 정확한 EDGE 인터페이스 실행 중(EDGE INTERFACE UP) 및 EDGE 인터페이스 종료(EDGE INTERFACE DOWN)는 모니터링에 사용할 수 없습니다.

  • 문제 97272: 고가용성 토폴로지로 배포되고 OSPF를 사용하는 사이트에서 HA Edge가 활성-활성 "분할 브레인" 상태가 되면 모든 트래픽이 삭제되는 것을 확인할 수 있습니다.

    대기 Edge에서 코어 라우터의 LSA(링크 상태 애드버타이즈) 사용 기간이 최대값(3600)으로 설정되어 모든 트래픽이 삭제되고 이로 인해 기본 경로가 제거됩니다. 제대로 작동하면 코어 라우터의 LSA 사용 기간은 활성 Edge와 동기화되지만 활성-활성 상태가 되면 대기 Edge도 활성 상태가 되고 코어 라우터로 LSA를 보냅니다. 활성 및 대기 Edge 모두 동일한 라우터 ID를 가지지만 코어 라우터에 다른 LSA 사용 기간을 전송하고 있습니다. 불일치가 확인되면 코어 라우터는 LSA 사용 기간을 최대값인 3600으로 설정하며 이에 따라 OSPF 기본 경로가 제거됩니다.

    해결 방법: HA 사이트에서 이 문제가 발생하는 경우 Edge를 이 문제에 대한 수정 사항을 포함하는 특수 핫 픽스 빌드 R451-20221123-GA-97272로 업그레이드할 수 있습니다. 이 빌드를 엔터프라이즈 또는 파트너 포털에 업로드하려면 VMware SD-WAN 지원에 문의하십시오. 이 문제에 대한 수정 사항이 없는 Edge에서는 활성-활성 상태가 해결되면 활성 Edge에서 OSPF를 다시 시작해야 합니다.

  • 문제 97321: Edge Network Intelligence 분석이 VMware SD-WAN Edge에서 활성화되면 Edge가 Edge 서비스 다시 시작을 트리거하여 10~15초 동안 고객 트래픽이 중단될 수 있습니다.

    Edge에서 분석을 사용하도록 설정하면 Edge에서 메모리 부족 상태가 발생한 후 "이중 사용 가능" 메모리 상태가 발생할 수 있습니다. Edge는 해당 서비스를 다시 시작하여 메모리를 복원합니다. 분석이 활성화된 동안 이 문제의 증상이 여러 번 발생할 수 있습니다.

    해결 방법: 이 문제에 대해 분석을 비활성화하는 것 이외의 해결 방법은 없습니다.

  • 문제 97997: default-originate를 통한 기본 경로는 Edge에서 시작되지 않습니다.

    default-originate와 연결된 route-map 문자열이 잘리고 어떤 route-map/접두사와도 일치하지 않습니다. 따라서 기본 경로가 시작되지 않습니다.

    해결 방법: 없습니다. 이 수정 사항을 포함하는 버전으로 업그레이드합니다.

  • 문제 98136: 동적 분기 간 VPN이 구성된 허브/스포크 토폴로지를 사용하는 고객 엔터프라이즈의 경우 SD-WAN 스포크 Edge 뒤에 있는 클라이언트 사용자에게 일부 트래픽이 최적의 경로를 사용하는 트래픽으로 인해 예기치 않은 지연 시간이 발생할 수 있습니다.

    이 문제가 발생하는 스포크 Edge 트래픽은 처음에는 스포크 Edge가 사용했던 프로필에 포함되지 않은 허브 Edge에 대한 비업링크 경로인 경로를 사용합니다. 트래픽이 관련되지 않은 다른 접두사로 전송되고 이 경우 비업링크 경로가 스포크 Edge에 설치되기 때문에 스포크 Edge에서 허브 Edge로 동적 분기 간 VPN 터널을 형성할 수 있습니다.

    이 비업링크 경로의 결과로 이 접두사로 향하는 모든 트래픽이 허브 Edge를 통과하기 시작하고 비업링크 경로가 업링크(업링크 커뮤니티로의 커뮤니티 변경)가 되지만 이전에 설치한 비업링크 경로는 해지되지 않으며 동적 분기 간 VPN 터널이 작동되는 한 트래픽은 허브 Edge 경로를 사용합니다.

    해결 방법: 동적 분기 간 VPN 터널이 해체될 때까지 기다립니다. 이후 허브 Edge로의 새 동적 분기 간 VPN 터널이 형성될 때 스포크 Edge에 업링크 경로가 설치되지 않습니다.

  • 문제 98979: VMware SD-WAN Edge에서 메모리 부족 상태로 인해 재부팅이 발생할 수 있습니다.

    런타임 동안 Edge에서 할당된 메모리 양과 후속 코어 생성에 따라 커널의 메모리 부족 상태가 트리거되어 커널 패닉이 트리거되고 재부팅이 발생할 수 있습니다. Edge 재부팅을 완료하는 데 약 2~3분이 걸리며 Edge가 재부팅을 완료할 때까지 고객 트래픽이 손상됩니다.

    해결 방법: 이 문제에 대한 해결 방법은 없습니다.

  • 문제 100005: Edge-610은 ifSpeed - OID 1.3.6.1.2.1.2.2.1.5에 대해 잘못된 값을 반환합니다.

    인터페이스 속도에 대해 쿼리하면 DPDK AF_PACKET 드라이버의 하드 코딩된 속도가 10G이기 때문에 Edge-610은 잘못된 값을 반환합니다.

    해결 방법: 이 문제에 대한 해결 방법은 없습니다.

Orchestrator의 알려진 문제

  • 문제 21342:

    세그먼트별로 파트너 게이트웨이를 할당할 때 VMware SD-WAN Edge 모니터링 목록의 운영자 옵션 "보기(View)" 게이트웨이 아래에 적절한 게이트웨이 할당(Gateway Assignments) 목록이 표시되지 않을 수 있습니다.

  • 문제 24269:

    QoE 그래프에 이 손실이 반영되지만 그래프로 나타내지 않은 [모니터링(Monitor)] > [전송(Transport)] > [손실(Loss)]에서 WAN 링크 손실이 확인되었습니다.

  • 문제 25932:

    VMware SD-WAN Orchestrator를 사용하는 경우에도 VMware SD-WAN Gateway를 게이트웨이 풀에서 제거할 수 있습니다.

  • 문제 32335:

    사용자가 계약에 동의하려고 하면 'EUSA(최종 사용자 서비스 계약)(End User Service Agreement(EUSA))' 페이지에서 오류가 발생합니다.

    해결 방법: 엔터프라이즈 이름에 선행 또는 후행 공백이 없는지 확인합니다.

  • 문제 32435:

    정책 기반 NAT 구성에 대한 VMware SD-WAN Edge 재정의는 프로필 수준에서 이미 구성된 튜플에 대해 허용되고 그 반대의 경우도 마찬가지입니다.

  • 문제 32856:

    비즈니스 정책이 허브 클러스터를 사용하여 인터넷 트래픽을 백홀하도록 구성되었지만 사용자는 릴리스 3.2.1에서 릴리스 3.3.x로 업그레이드된 VMware SD-WAN Orchestrator의 프로필에서 허브 클러스터의 선택을 취소할 수 있습니다.

  • 문제 32913:

    고가용성을 사용하도록 설정한 후 VMware SD-WAN Edge에 대한 멀티캐스트 세부 정보가 모니터링(Monitoring) 페이지에 표시되지 않습니다. 페일오버를 수행하면 문제가 해결됩니다.

  • 문제 33026:

    계약을 삭제한 후 ‘EUSA(최종 사용자 서비스 계약)(End User Service Agreement(EUSA))’ 페이지가 제대로 다시 로드되지 않습니다.

  • 문제 34828:

    릴리스 2.x를 사용하는 VMware SD-WAN 스포크 Edge 및 릴리스 3.3.1을 사용하는 허브 Edge 간에 트래픽을 전달할 수 없습니다.

  • 문제 35658:

    VMware SD-WAN Edge가 한 프로필에서 다른 CSS 설정이 지정된 다른 프로필로 전환되면(예: profile1의 IPsec에서 profile2의 IPsec으로) Edge 수준 CSS 설정은 이전 CSS 설정(예: GRE 대신 IPsec)을 계속 사용합니다.

    해결 방법: 이 문제를 해결하려면 Edge 수준에서 GRE를 비활성화했다가 다시 사용하도록 설정합니다.

  • 문제 35667:

    VMware SD-WAN Edge가 한 프로필에서 CSS 설정은 동일하지만 GRE CSS 이름(동일한 끝점)은 다른 프로필로 전환되면 일부 GRE 터널이 모니터링 시 표시되지 않습니다.

    해결 방법: 이 문제를 해결하려면 Edge 수준에서 GRE를 비활성화했다가 다시 사용하도록 설정합니다.

  • 문제 36665:

    VMware SD-WAN Orchestrator가 인터넷에 연결할 수 없는 경우 Google Maps API에 액세스해야 하는 사용자 인터페이스 페이지가 완전히 로드되지 않을 수도 있습니다.

  • 문제 38056:

    Edge-Licensing export.csv 파일에 지역 데이터가 표시되지 않습니다.

  • 문제 38843:

    애플리케이션 맵을 푸시할 때 운영자 이벤트가 없으며 Edge 이벤트는 사용이 제한됩니다.

  • 문제 39633:

    사용자가 대체 게이트웨이를 슈퍼 게이트웨이로 할당한 후에는 슈퍼 게이트웨이 하이퍼링크가 작동하지 않습니다.

  • 문제 39790:

    VMware SD-WAN Orchestrator는 VMware SD-WAN Edge의 라우팅된 인터페이스를 지원되는 32개의 하위 인터페이스보다 더 많이 유지하도록 허용하므로 사용자가 인터페이스에서 33개 이상의 하위 인터페이스를 구성하여 Edge의 데이터부 서비스 실패를 유발할 위험이 있습니다.

  • 문제 40341:

    Skype 애플리케이션을 백엔드에서 실시간 트래픽으로 올바르게 분류했지만 VMware SD-WAN Orchestrator에서 Skype 비즈니스 정책을 편집할 때 서비스 클래스에서 "트랜잭션"을 잘못 표시할 수 있습니다.

  • 문제 41691:

    구성(Configure) > Edge > 디바이스(Device) 페이지에서 DHCP 풀이 고갈되지 않더라도 사용자가 '주소 수(Number of addresses)' 필드를 변경할 수 없습니다.

  • 문제 43276:

    VMware SD-WAN Edge 또는 프로필에 파트너 게이트웨이가 구성된 경우 사용자는 세그먼트 유형을 변경할 수 없습니다.

  • 문제 47269:

    VMware SD-WAN 510-LTE 인터페이스가 LTE 인터페이스를 지원하지 않는 Edge 모델에 대해 표시될 수 있습니다.

  • 문제 47713:

    클라우드 VPN을 사용하지 않도록 설정한 상태에서 비즈니스 정책 규칙이 구성된 경우에는 클라우드 VPN을 사용하도록 설정할 때 NAT 구성을 다시 지정해야 합니다.

  • 문제 47820:

    프로필 수준에서 DHCP를 사용하지 않도록 설정한 상태로 VLAN을 구성했으며 DHCP를 사용하도록 설정한 해당 Edge에서 이 VLAN에 대한 Edge 재정의가 있지만 DNS 서버 필드 집합에 대한 항목이 없음(none)(IP 구성 안 함)으로 설정되면, 사용자는 [구성(Configure)] > [Edge] > [디바이스(Device)] 페이지에서 변경을 수행할 수 없으며, 실제 문제를 설명하거나 가리키지 않는 '잘못된 IP 주소 [](invalid IP address [])’ 오류 메시지가 표시됩니다.

  • 문제 48085:

    VMware SD-WAN Orchestrator를 통해 사용자는 인터페이스와 연결된 VLAN을 삭제할 수 있습니다.

  • 문제 48737:

    릴리스 4.0.0의 새 사용자 인터페이스를 사용하는 VMware SD-WAN Orchestrator의 사용자가 [모니터링(Monitor)] 페이지에서 시작 및 종료 시간 간격을 변경한 후 탭 간을 이동하면 Orchestrator는 시작 및 종료 간격 시간을 새 값으로 업데이트하지 않습니다.

  • 문제 49225:

    VMware SD-WAN Orchestrator는 32개의 총 VLAN 제한을 적용하지 않습니다.

  • 문제 49790:

    VMware SD-WAN Edge가 릴리스 4.0.0으로 활성화되면 활성화가 이벤트(Events)에 두 번 게시됩니다.

    해결 방법: 중복 이벤트를 무시합니다.

  • 문제 50531:

    VMware SD-WAN Orchestrator의 4.0.0 릴리스 버전에서 새 UI에 액세스할 때 서로 다른 권한의 두 운영자가 동일한 브라우저 창을 사용하고 더 낮은 권한의 운영자가 높은 권한의 운영자 다음에 로그인을 시도하는 경우 권한이 더 낮은 운영자에게는 "사용자에게 권한이 없습니다."라는 여러 오류가 표시됩니다.

    참고: 더 낮은 권한의 운영자에 대한 권한 에스컬레이션은 수행되지 않으며 오류 메시지만 표시됩니다.

    해결 방법: 다음 운영자는 로그인하기 전에 해당 페이지를 새로 고쳐 오류가 표시되지 않도록 하거나, 각 운영자가 다른 브라우저 창을 사용하여 이 표시 문제를 방지할 수 있습니다.

  • 문제 51722: 릴리스 4.0.0 VMware SD-WAN Orchestrator에서 시간 범위 선택기는 [모니터링(Monitor)] &gt; [Edge] 탭의 통계에서 2주보다 크지 않습니다.

    통계 집합의 보존 기간이 "2주 전"보다 긴 경우에도 시간 범위 선택기는 [모니터링(Monitor)] > [Edge] 탭의 [2주 전(Past 2 Weeks)]보다 큰 옵션을 표시하지 않습니다. 예를 들어, 경로 통계는 기본적으로 2주 동안만 보존되지만(구성 가능) 흐름 및 링크 통계는 기본적으로 365일 동안 보존됩니다(구성 가능). 이 문제는 사용자가 해당 통계의 보존 기간과 일치하는 기간을 선택할 수 있도록 허용하지 않고, 모든 모니터링 탭에서 가장 짧은 통계 유지 기간을 따르도록 합니다.

    해결 방법: 시간 범위 선택기에서 "사용자 지정(Custom)" 옵션을 사용하여 2주일보다 오래된 데이터를 볼 수 있습니다.

  • 문제 60039: VMware SD-WAN Edge 모델이 변경된 경우 RMA 재활성화가 작동하지 않습니다.

    Edge 모델도 변경되는 사이트에 대해 RMA 재활성화를 수행할 때 VMware SD-WAN Orchestrator가 모델 변경을 저장하지 못하여 재활성화 링크가 작동하지 않게 됩니다. 이로 인해 Edge 모델이 변경된 RMA 재동기화에만 영향을 미치며, Edge 모델이 동일하게 유지되는 RMA 재동기화는 예상대로 작동됩니다.

    해결 방법: 사이트에 다른 Edge 모델을 사용하는 경우 사용자는 새 Edge를 생성하고 모든 Edge 관련 설정을 수동으로 적용해야 합니다.

  • 문제 60522: VMware SASE Orchestrator UI에서 세그먼트를 제거하려고 하면 많은 오류 메시지가 표시됩니다.

    이 문제는 프로필에 세그먼트를 추가하고 세그먼트를 여러 VMware SD-WAN Edge와 연결할 때 발견될 수 있습니다. 사용자가 프로필에서 추가된 세그먼트를 제거하려고 하면 많은 오류 메시지가 표시됩니다.

    해결 방법: 이 문제에 대한 해결 방법은 없습니다.

  • 문제 88910: 릴리스 4.5.1을 실행하는 VMware SASE Orchestrator에서 사용자는 [원격 진단(Remote Diagnostics)] &gt; [WAN 링크 속도 테스트(WAN Link Speed Test)]를 사용하여 VMware SD-WAN Edge에 대해 WAN 링크 속도 테스트를 실행할 수 없습니다.

    WAN 링크 속도 테스트 진단을 사용하려고 하면 인터페이스에 대한 드롭다운 메뉴가 없으므로 사용자는 속도 테스트용 인터페이스를 선택할 수 없습니다.

    해결 방법: 사용자가 WAN 링크에 대한 대역폭 테스트를 강제로 적용하려는 경우 해결 방법으로 해당 WAN 링크에 대한 대역폭 측정 방법을 변경할 수 있습니다. 그러면 자동으로 다시 테스트됩니다. 이 작업은 다음과 같이 수행할 수 있습니다.

    1. 특정 Edge에 대한 Orchestrator UI에서 구성(Configure) > 디바이스(Device)로 이동한 후 아래로 스크롤하여 WAN 설정(WAN Settings)으로 이동합니다.

    2. WAN 링크가 다시 테스트되도록 하려면 다시 측정할 링크에 대해 편집(Edit)을 선택한 다음, 고급(Advanced)을 선택하여 추가 설정을 표시합니다.

    3. 대역폭 측정(Bandwidth Measurement) 메뉴에서 현재 설정된 대역폭 측정 방법을 다른 방법으로 변경합니다(예: 링크가 버스트 모드(Burst Mode)를 사용하는 경우 [느린 시작(Slow Start)]으로 변경 또는 그 반대로). 그런 후 링크 업데이트(Update Link)를 클릭한 후 디바이스 페이지 맨 위에 있는 변경 내용 저장(Save Changes)을 클릭합니다.

    4. WAN 링크에서 측정이 수행되면 측정 방법을 다시 원래 방법으로 변경하여 해당 WAN 링크에 대해 가장 정확한 측정을 보장합니다. 이렇게 하면 추가 대역폭 테스트가 트리거됩니다.

Cloud Web Security의 알려진 문제

  • 문제 62934: VMware Cloud Web Security를 사용하는 엔터프라이즈의 경우, 클라이언트 사용자가 시크릿 모드에서 Chrome 브라우저를 열고 파일을 다운로드하려고 하면 다운로드가 성공하지 못할 수 있습니다.

    시크릿 모드를 사용하려면 타사 쿠키를 사용하도록 설정해야 합니다. 타사 쿠키를 설정하고 작업을 다시 시도하십시오. 다운로드가 실패하면 사용자에게 “오류가 발생했습니다. 관리자에게 문의하십시오.” 화면이 표시되거나 사용자 지정 웹 서버의 파일에 대해 “이 페이지가 작동하지 않습니다.” 화면이 표시됩니다. 경우에 따라 일부 웹 서버 또는 파일에서 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 뒤의 리소스에서 시작된 트래픽을 나타내도록 합니다.

  • 문제 65001: VMware Cloud Web Security를 사용하는 고객의 경우 VMware Orchestrator를 사용할 때 파일 해시 확인을 설정/해제하도록 검사 엔진을 구성할 수 없습니다.

    사용자가 Orchestrator를 사용하여 “알 수 없는 파일 다운로드에 대한 작업(Action for Unknown File Download)” 및 “알 수 없는 문서 다운로드에 대한 작업(Action for unknown document Download)”에 대해 Cloud Web Security 검사 엔진의 파일 해시 확인 매개 변수를 구성하는 경우 해당 변경 내용이 검사 엔진으로 전송되지 않고 적용되지 않습니다.

    해결 방법: 이 문제에 대한 해결 방법은 없습니다.

Secure Access의 알려진 문제

  • 문제 64541: VMware Secure Access를 사용하는 고객의 경우 Workspace ONE UEM 구성의 옵션을 사용하여 조직 그룹 내의 터널 호스트 이름을 구성할 때 사용자가 [예(Yes)]를 선택하면 호스트 이름을 수동으로 구성할 필요가 없이 UEM 콘솔에서 호스트 이름이 자동으로 생성됩니다.

    사용자는 호스트 이름이 자동으로 생성되지 않고 수동으로 구성하는 옵션을 사용할 수 있습니다.

    해결 방법: 해결 방법은 UEM 콘솔에서 수동으로 설정하는 것입니다.

check-circle-line exclamation-circle-line close-line
Scroll to top icon