업데이트 날짜: 2023년 4월 25일 VMware SD-WAN™ Orchestrator 버전 R422-20220715-GA VMware SD-WAN™ Gateway 버전 R422-20220805-GA VMware SD-WAN™ Edge 버전 R422-20220805-GA 이 릴리스 정보의 추가 사항 및 업데이트 사항을 정기적으로 확인하십시오.

릴리스 정보에 있는 내용

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

• 권장 사용
• 호환성
• 중요 참고 사항
• 새 하드웨어 플랫폼 지원
• 개정 기록
• 해결된 문제
• 알려진 문제

권장 사용

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

호환성

릴리스 4.2.2 Orchestrator, 게이트웨이 및 허브 Edge는 릴리스 3.0.0 이상의 모든 이전 VMware SD-WAN Edge 버전을 지원합니다. 
참고: 즉, 3.0.0 이전 릴리스는 지원되지 않습니다.

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

Orchestrator	게이트웨이	Edge
		허브	분기/스포크
4.2.2	4.0.0	4.0.0	4.0.0
4.2.2	4.2.2	4.0.0	4.0.0
4.2.2	4.2.2	4.2.2	4.0.0
4.2.2	4.2.2	4.0.0, 4.0.2	4.2.2
4.2.2	4.0.0	4.2.2	4.0.0, 4.0.2
4.2.2	4.0.2	4.2.2	4.0.0, 4.0.2
4.2.2	4.0.0	4.2.2	4.2.2
4.2.2	3.4.6	3.4.6	3.4.6
4.2.2	4.2.2	3.4.4, 3.4.5, 3.4.6	3.4.6
4.2.2	4.2.2	4.2.2	3.4.4, 3.4.5, 3.4.6
4.2.2	4.2.2	3.4.4, 3.4.5, 3.4.6	4.2.2
4.2.2	3.3.2 P2 *	3.3.2 P2 *	3.3.2 P2 *
4.2.2	4.2.2	3.3.2 P2, 3.3.2 P3 *	3.3.2 P2 *
4.2.2	4.2.2	4.2.2	3.3.2 P2, 3.3.2 P3 *
4.2.2	4.2.2	3.3.2 P2, 3.3.2 P3 *	4.2.2
4.2.2	3.2.2 *	3.2.2 *	3.2.2 *
4.2.2	4.2.2	3.2.2 *	3.2.2 *
4.2.2	4.2.2	4.2.2	3.2.2 *
4.2.2	4.2.2	3.2.2 *	4.2.2
4.2.1	4.2.2	4.2.2	4.2.1
4.2.1	4.2.1	4.2.2	4.2.2
4.2.2	4.2.1	4.2.2	4.2.2
4.0.2	4.0.2	4.2.2	4.0.2

주의: VMware SD-WAN 릴리스 3.2.x, 3.3.x 및 3.4.x는 지원 종료되었습니다.

• 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 중에서 선택할 수 있습니다.

중요 참고 사항

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

Edge 쌍이 고가용성 토폴로지에 배포된 사이트에서 대기 Edge가 활성-활성 상태를 해결하기 위해 한 번 이상 재부팅되는 문제가 발생할 수 있습니다. 대기 Edge가 재부팅되면 고객 트래픽이 중단되고, 대기 Edge가 고객 트래픽을 전달하므로 고급 HA 토폴로지를 사용하는 사이트에 미치는 영향이 커질 수 있습니다. 이 문제는 이러한 릴리스 정보의 Edge/게이트웨이의 알려진 문제 섹션에서 문제 #85369로 추적되고 있습니다.

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

AS-PATH Prepending에 대한 BGPv4 필터 구성 구분 기호 변경

릴리스 3.x까지는 AS-PATH prepending에 대한 VMware SD-WAN BGPv4 필터 구성이 쉼표 및 공백 기반 구분 기호를 모두 지원합니다. 그러나 릴리스 4.0.0 이상부터 VMware SD-WAN에서는 AS-Path prepending 구성에서 공백 기반 구분 기호만 지원합니다.
3.x에서 4.x로 업그레이드하는 고객은 잘못된 BGP 최상의 경로 선택을 방지하기 위해 업그레이드 전에 AS-PATH prepending 구성을 편집하여 "쉼표를 공백으로 대체"해야 합니다.

Edge 3x00 모델에 대해 확장된 업그레이드 시간

Edge 3x00 모델(예: 3400, 3800 및 3810)에서 이 버전으로 업그레이드하는 데 평균 업그레이드 시간(3~5분)보다 오래 걸릴 수 있습니다. 이는 문제 53676을 해결하는 펌웨어 업그레이드 때문에 발생합니다. Edge 3400 또는 3800이 이전에 릴리스 3.4.5, 4.0.2 또는 4.2.1에서 펌웨어를 업그레이드한 경우 Edge는 예상대로 업그레이드됩니다. 자세한 내용은 해당 릴리스 정보의 해결된 문제 53676을 참조하십시오.

VMware SD-WAN Edge 모델 520, 540, 620, 640, 680, 3400, 3800 및 3810에서 자동 협상 기능을 비활성화할 경우의 제한 사항

VMware SD-WAN Edge 모델 620, 640 또는 680의 GE1 - GE4 포트, Edge 3400, 3800, 또는 3810의 GE3 또는 GE4 포트, 구리 인터페이스가 있는 SFP가 포트 SFP1 또는 SFP2에서 사용될 때 Edge 520/540에서 하드코드 속도 및 이중화에 대한 자동 협상 기능을 비활성화하는 경우 재부팅 후에도 링크가 작동되지 않는 것을 확인할 수 있습니다.

이 문제는 자동 협상이 링크의 양쪽에서 모두 사용되지는 않을 때 전송 및 수신할 적절한 와이어를 동적으로 감지할 수 없는(자동 MDIX) 제한이 있는 Intel Ethernet Controller i350을 사용하는 나열된 각 Edge 모델에서 발생합니다. 연결의 양쪽이 동일한 와이어에서 전송 및 수신 중인 경우 링크가 감지되지 않습니다. 피어 측도 자동 협상이 없으면 자동 MDIX를 지원하지 않으며 링크가 직선 케이블을 통해 진행되지 않을 경우, 링크가 작동하려면 교차 이더넷 케이블이 필요합니다.

자세한 내용은 KB 문서 VMware SD-WAN Edge 모델 520, 540, 620, 640, 680, 3400, 3800 및 3810(87208)에서 자동 협상 기능을 비활성화할 경우의 제한 사항을 참조하십시오.

새 하드웨어 플랫폼 지원

Edge 510N, Edge 610N, Edge 620N, Edge 640N, Edge 680N

VMware는 통합형 Wi-Fi가 포함되어 있지 않은 몇 가지 새로운 SD-WAN Edge 하드웨어 모델을 도입할 계획입니다. 여기에는 Edge 510N, 610N, 620N, 640N 및 680N이 포함됩니다. 이러한 Edge 모델은 이 릴리스에서 지원됩니다. VMware SD-WAN/SASE Orchestrator 설정에서 수행한 Wi-Fi 구성은 이러한 Edge 모델에 영향을 미치지 않습니다.

참고: 고가용성에서 Wi-Fi 지원 및 비 Wi-Fi 지원 Edge를 혼합해서 사용할 수 없음 

Edge 모델 510N, 610N, 620N, 640N 및 680N은 Wi-Fi 지원 모델과 동일한 것처럼 보이지만 동일한 모델의 Wi-Fi 지원 Edge 및 비 Wi-Fi 지원 Edge(예: Edge 640 및 Edge 640N)를 고가용성 쌍으로 배포하는 것은 지원되지 않습니다. 고객은 고가용성 쌍으로 배포된 Edge가 동일한 유형(Wi-Fi 지원 또는 비 Wi-Fi 지원 모두)인지 확인해야 합니다.

문서 개정 기록

2021년 9월 29일. 1차 개정판

2021년 12월 21일. 2차 개정판

• Orchestrator의 해결된 문제에 새로운 Orchestrator 빌드 R422-20211216-GA를 추가했습니다. 이 Orchestrator 빌드는 Log4j 버전 2.16.0으로 업데이트하여 CVE-2021-44228, Apache Log4j 취약점에 업데이트를 적용합니다. Apache Log4j 취약점에 대한 자세한 내용은 VMware Security Advisory VMSA-2021-0028.5를 참조하십시오.
• 중요 참고 사항 참고: VMware SD-WAN Edge 모델 520, 540, 620, 640, 680, 3400, 3800 및 3810에서 자동 협상 기능을 비활성화할 경우의 제한 사항. 이 참고는 나열된 Edge 모델의 일부 이더넷 포트에서 강제 속도를 구성할 때 발생할 수 있는 문제를 다룹니다.

2022년 1월 4일. 3차 개정판

• Edge의 해결된 문제 섹션에 새로운 Edge 빌드 R422-20211216-GA를 추가했습니다. 이 빌드는 릴리스 4.2.2의 새 Edge GA 빌드입니다.
• 이 Edge 빌드는 해당 섹션에 설명된 해결된 문제 #53951, #67060, #70919, #70954 , #72245, #72425, #73251, #72688을 포함합니다.

2022년 1월 21일. 4차 개정판

• Edge의 해결된 문제 섹션에 새로운 Edge 빌드 R422-20220119-GA를 추가했습니다. 이 빌드는 릴리스 4.2.2의 새 Edge GA 빌드입니다.
• 이 Edge 빌드는 해당 섹션에 설명된 해결된 문제 #58791, #68785, #70933, #72498, #75992, #77040, #77525, #77586을 포함합니다.
• Orchestrator의 해결된 문제에 새로운 Orchestrator 빌드 R422-20220112-GA를 추가했습니다. 이 Orchestrator 빌드는 Log4j 버전 2.17.0으로 업데이트하여 Apache Log4j 취약성 CVE-2021-44228(Log4j 버전 2.16.0을 사용하는 Orchestrator 빌드 R422-20211216-GA에서 처음 처리됨)과 CVE-2021-45046에 업데이트를 적용합니다. Apache Log4j 취약성 및 VMware 제품에 미치는 영향에 대한 업데이트된 정보는 VMware 보안 권고 VMSA-2021-0028.9를 참조하십시오.

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

• 문제가 4.2.2 GA 빌드에서 반복적으로 나타나므로 #55327을 Edge/게이트웨이 해결된 문제에서 Edge/게이트웨이 미해결 문제로 이동했습니다.

2022년 2월 18일. 6차 개정판

• Edge의 해결된 문제 섹션에 새로운 Edge 빌드 R422-20220210-GA를 추가했습니다. 이 빌드는 릴리스 4.2.2의 새 Edge GA 빌드입니다.
• 이 Edge 빌드는 해당 섹션에 설명된 해결된 문제 #48017, #55327, #57281, #66691, #72859, #72925, #78003, #78300, #78678, #81224를 포함합니다.

2022년 3월 2일. 7차 개정판

• 새 하드웨어 플랫폼 지원 아래에 중요 참고 사항 “참고: 고가용성에서 Wi-Fi 지원 및 비 Wi-Fi 지원 Edge를 혼합해서 사용할 수 없음“을 Edge 510N, Edge 610N, Edge 620N, Edge 640N 및 Edge 680N 섹션에 추가했습니다.

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

• Edge의 해결된 문제 섹션에 새로운 Edge 빌드 R422-20220310-GA를 추가했습니다. 이 빌드는 릴리스 4.2.2의 새 Edge GA 빌드입니다.
• Edge 빌드 R422-20220310-GA에는 이 섹션에 설명된 해결된 문제 #57597, #65695, #67745, #68923, #70586, #77625, #77642, #81221, #83212를 포함합니다.
• 호환성 섹션에서 릴리스 3.4.x 소프트웨어가 Orchestrator 및 게이트웨이에 대해 2022년 3월 30일에 EOGS(일반 지원 종료), 2022년 6월 30일에 EOTG(기술 지침 종료)에 도달하게 된다는 새 경고가 추가되었습니다. Orchestrator 및 게이트웨이에만 해당됩니다. 3.4.x Edge 소프트웨어는 2022년 12월 31일부터 지원 종료 기간이 시작될 예정입니다.

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

• Edge/게이트웨이의 알려진 문제 섹션에 문제 #84825를 추가했습니다.
• 이 티켓이 다수의 BGP match 및 set 필터로 구성된 HA 사이트를 수정함을 나타내는 부분을 제거하기 위해 해결된 문제 #58791을 추가로 편집했습니다. 문제의 해당되는 부분은 이 티켓으로 수정되지 않으며 문제 #84825로 추적됩니다.

2022년 3월 31일. 10차 개정판

• 최근의 Edge 롤업 빌드 422-20220310-GA에서 발견된 해결된 문제 #83212를 미해결 문제로 재분류했습니다.  #83212를 Edge/게이트웨이 알려진 문제 섹션으로 이동했습니다.

2022년 4월 13일. 11차 개정판

• 미해결 문제 #62701은 현재 모든 릴리스에서 해결되지 않은 상태로 남아 있으므로 Edge/게이트웨이 알려진 문제 섹션에 추가되었습니다.
• Edge/게이트웨이 해결된 문제의 원래 Edge 빌드 R422-20220310-GA 외에 게이트웨이 빌드 R422-20220310-GA가 포함되었습니다.
• 게이트웨이 빌드 R422-20220310-GA는 2022년 3월 15일 릴리스되었고, 현재 4.2.2의 기본 빌드이며 ESXi 버전 7.0에 대한 지원이 확인되었습니다. ESXi 버전 7.0의 VMware 하이퍼바이저를 사용하여 게이트웨이를 배포하거나 업그레이드하려는 고객은 이 버전 이상의 빌드만 사용해야 합니다.

2022년 4월 20일. 12차 개정판

• Edge 및 게이트웨이의 해결된 문제 섹션에 새로운 Edge/게이트웨이 빌드 R422-20220419-GA를 추가했습니다. 이 빌드는 릴리스 4.2.2의 새 Edge 및 게이트웨이 GA 빌드입니다.
• Edge/게이트웨이 빌드 R422-20220419-GA에는 이 섹션에 설명된 해결된 문제 #65466, #67336, #69194, #83946, #84825를 포함합니다.

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

• 해결된 문제 #67060이 잘못 추가된 중복 항목이므로 Edge 롤업 빌드 R422-20211216-GA의 해결된 문제 목록에서 제거되었습니다.  #67060에 대한 수정 사항은 원래 GA 빌드 R422-20210923-GA에 포함되어 있으며 4.2.2 릴리스 정보의 초기 게시에서 올바르게 문서화되었습니다.
• 지원 종료가 임박한 릴리스 4.0.x와 관련된 새로운 주의가 호환성 섹션에 추가되었습니다.

2022년 5월 12일. 14차 개정판.

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

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

• Edge 및 게이트웨이의 해결된 문제 섹션에 새로운 Edge/게이트웨이 롤업 빌드 R422-20220511-GA를 추가했습니다. 이것은 6번째 Edge/게이트웨이 롤업 빌드이며 릴리스 4.2.2에 대한 새로운 Edge/게이트웨이 GA 빌드입니다.
  Edge/게이트웨이 빌드 R422-20220511-GA에는 이 섹션에 설명된 해결된 문제 #67201을 포함합니다.

2022년 5월 27일. 16차 개정판

• Edge 및 게이트웨이의 해결된 문제 섹션에 새로운 Edge/게이트웨이 롤업 빌드 R422-20220518-GA를 추가했습니다. 이것은 7번째 Edge/게이트웨이 롤업 빌드이며 릴리스 4.2.2에 대한 새로운 Edge/게이트웨이 GA 빌드입니다.
  Edge/게이트웨이 빌드 R422-20220518-GA에는 이 섹션에 설명된 해결된 문제 #80814, #82485, #88757 및 #88796을 포함합니다.
• 문제 #88796을 새 Orchestrator의 알려진 문제로 추가했습니다. 이 티켓은 최신 게이트웨이 빌드에 수정 사항이 포함되어 있기 때문에 Orchestrator OVA에 해당될 때만 문제를 추적합니다.
• Edge/게이트웨이의 알려진 문제 섹션에 문제 #85369와 #85461을 추가했습니다.

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

• 중요 참고 사항이 추가됨: Edge 쌍에 대해 고가용성 토폴로지를 사용하는 고객 사이트의 지속적인 문제와 관련된 "고가용성 토폴로지를 사용하는 사이트의 잠재적 문제". 이 문제는 Edge/게이트웨이의 알려진 문제에 있는 #85369로 계속 추적됩니다.
• 호환성에서 릴리스 4.2.x Edge 소프트웨어의 수명 종료 날짜를 수정했습니다. Edge 소프트웨어는 별도의 항목으로 구분되며 이제 다음 내용을 표시합니다. "릴리스 4.2.x Edge는 2023년 6월 30일에 EOGS(일반 지원 종료)에 도달하고 2023년 9월 30일에는 EOTG(기술 지침 종료)에 도달하게 됩니다."  별도의 Orchestrator 및 게이트웨이 항목은 이전과 동일한 수명 종료 날짜를 유지합니다.
• 필드에서 이 문제가 발생한 고객에게 영향을 미칠 수 있는 다른 시나리오를 포함하도록 Edge/게이트웨이의 해결된 문제 섹션에서 해결된 문제 #53951을 수정했습니다.

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

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

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

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

2022년 7월 26일. 21차 개정판

• Edge 및 게이트웨이의 해결된 문제 섹션에 새로운 Edge/게이트웨이 롤업 빌드 R422-20220530-GA를 추가했습니다. 이것은 8번째 Edge/게이트웨이 롤업 빌드이며 릴리스 4.2.2에 대한 새로운 Edge/게이트웨이 GA 빌드입니다.
  Edge/게이트웨이 빌드 R422-20220530-GA에는 이 섹션에 설명된 해결된 문제 #83437 및 #87205를 포함합니다.

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

• Edge 및 게이트웨이의 해결된 문제 섹션에 새로운 Edge/게이트웨이 롤업 빌드 R422-20220805-GA를 추가했습니다. 이것은 9번째 Edge/게이트웨이 롤업 빌드이며 릴리스 4.2.2에 대한 새로운 Edge/게이트웨이 GA 빌드입니다.
• Edge/게이트웨이 빌드 R422-20220805-GA에는 문제 #52659, #59862, #80028, #85369, #87923, #89235, #90280, #90283, #93062 및 #94395에 대한 수정 사항이 포함되어 있으며 각 문제는 이 섹션에 설명되어 있습니다.

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

• Orchestrator의 해결된 문제 섹션에 새로운 Orchestrator 롤업 빌드 R422-20220715-GA를 추가했습니다. 이것은 세 번째 Orchestrator 롤업 빌드이며 릴리스 4.2.2에 대한 새로운 Orchestrator GA 빌드입니다.
• Orchestrator 빌드 R422-20220715-GA에는 이 섹션에 설명된 해결된 문제 #85883 및 #88796을 포함합니다.

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

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

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

• Edge/게이트웨이의 알려진 문제 섹션에 미해결 문제 #89217을 추가했습니다.
• 해결된 문제 #93383이 오류로 인해 생략되어 9번째 롤업 빌드 R422-20220805-GA에 대해 Edge/게이트웨이의 해결된 문제 섹션에 이 문제를 추가했습니다.

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

• Edge/게이트웨이의 알려진 문제 섹션에 미해결 문제 #86098, #94204, #96441, #96888, 및 #98136을 추가했습니다.

2022년 10월 3일. 27차 개정판.

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

2022년 10월 31일. 11차 개정판.

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

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

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

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

• 문제 해결에 필요한 수정된 Edge 버전 (R5012-20230123-GA-103475) 및 플랫폼 펌웨어 버전(R131-20221216-GA)을 반영하도록 알려진 문제 #89217을 수정했습니다. 또한 이 티켓은 #89217을 포함하며 6x0 Edge 업그레이드를 위한 단계별 지침이 포함된 KB 문서에 대한 링크를 추가합니다.
• 호환성 섹션에서 4.2.x에 대한 지원 종료와 관련된 가져오기 참고 사항을 수정하고 SD-WAN Edge 소프트웨어에 대해 새로 수정된 날짜를 반영하도록 릴리스 4.3.x를 추가했습니다.

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

• 모든 3.x 릴리스가 EOSL(서비스 수명 종료)에 도달한 것으로 표시하도록 호환성 섹션이 업데이트되었습니다. 또한 4.2.x Orchestrator 및 게이트웨이를 EOSL(서비스 수명 종료)로 표시하도록 4.x 섹션이 업데이트되었습니다. 추가 정보는 KB 문서 알림: VMware SD-WAN 릴리스 4.x(88319)의 지원 기간 종료에서 찾을 수 있습니다.

해결된 문제

해결된 문제는 다음과 같이 그룹화되어 있습니다.

• Edge/게이트웨이의 해결된 문제
• Orchestrator의 해결된 문제

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

Edge/게이트웨이 버전 R422-20220805-GA에서 해결됨

Edge/게이트웨이 버전 R422-20220805-GA는 2022년 8월 8일에 릴리스되었으며 9번째 릴리스 4.2.2용 Edge/게이트웨이 롤업입니다.

이 Edge/게이트웨이 롤업 빌드는 8번째 Edge/게이트웨이 롤업, 버전 R422-20220530-GA 이후의 아래와 같은 중요한 문제를 해결합니다.

• 해결된 문제 52659: VMware SD-WAN Edge가 DHCP 릴레이 에이전트로 구성된 경우 Edge는 DHCP NAK 패킷을 클라이언트에 전달하지 않습니다.

  DHCP 서버가 DHCP NAK 패킷을 전송하는 경우 DHCP 릴레이로 구성된 Edge는 패킷을 전달하지 않고 삭제합니다. 

• 해결된 문제 59862: 원격 진단 "인터페이스 상태"를 실행할 때 "테스트를 위해 데이터를 읽는 동안 오류 발생(Error Reading data for test)"이라는 메시지를 나타내며 테스트가 실패할 수 있습니다.

  이 문제는 USB 모뎀을 삽입했다가 제거한 경우 VMware SD-WAN Edge의 네트워크 구성 파일에 남아 있는 usb 모뎀 항목으로 인해 발생합니다. 이 문제에 대한 수정 사항을 적용하면 게스트 데이터가 정상적으로 처리되고 테스트가 제대로 실행됩니다. 이 수정 사항을 적용하지 않은 Edge에서 Edge를 재부팅하면 이상 항목이 지워지고 테스트가 제대로 실행됩니다.

• 해결된 문제 80028: 고가용성 토폴로지로 배포된 사이트의 대기 Edge에서 데이터부 서비스 장애가 발생하고 결과적으로 다시 시작될 수 있습니다.

  이 문제는 대기 Edge에서만 발생하며 활성 Edge에서는 발생하지 않습니다. 이 문제는 파이프라인에서 처리 중인 패킷이 아직 있는 동안 심층 패킷 검사 엔진이 정리를 호출하는 경합 조건으로 인해 발생하며 언제든지 발생할 수 있습니다. 대기 Edge가 트래픽을 전달하지 않으므로 표준 HA 구성을 사용하는 고객에게는 영향이 없지만 대기 Edge도 트래픽을 전달하는 고급 HA 배포에서 대기 Edge 서비스를 다시 시작하면 고객 트래픽이 일시적으로 중단되고 15초 동안 대기 Edge를 통해 전달됩니다. 

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

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

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

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

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

• 해결된 문제 89235: 허브/스포크 토폴로지를 사용하고 인터넷 백홀 정책을 사용하는 고객 엔터프라이즈에서 인터넷을 향하는 VMware SD-WAN 스포크 Edge의 백홀 트래픽이 허브 Edge에 의해 삭제될 수 있습니다.

  이 문제가 발생하면 클라이언트 사용자는 인터넷으로 향하는 트래픽에서 문제를 발견할 수 있습니다. 이 문제는 Edge 전원 주기(예: 정전 후), Edge 서비스 다시 시작 또는 구성 변경 후에 발생하며, 스포크 Edge에서 시작되는 백홀 트래픽과 스포크 Edge에서 애드버타이즈된 경로 간의 타이밍 문제로 인해 발생합니다.

  이 수정 사항이 없는 스포크 Edge에서 이 문제가 발생하면 사용자는 영향을 받는 스포크 Edge의 흐름을 플러시하여 백홀 트래픽의 정상적인 라우팅을 복원해야 합니다. 이 작업은 Orchestrator에서 원격 진단(Remote Diagnostics) > 흐름 플러시(Flush Flows)를 통해 수행할 수 있습니다.

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

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

• 해결된 문제 90283: VMware SD-WAN Edge에서 사용되는 WAN 링크에 대해 언더레이 계산이 켜진 경우 고객이 VoIP 및 화상 통화 호출에서 경험하는 오디오 및/또는 비디오 품질이 저하될 수 있습니다.

  로그를 확인할 때 사용자는 트래픽이 비대칭이고 경로 중 하나가 언더레이를 통해 전송되는 경우 양방향 트래픽에서 패킷 손실을 확인합니다. 즉, 흐름에 대한 경로가 한 방향의 비대칭이면 트래픽이 언더레이 경로를 가져오고, 역방향으로 오버레이 경로를 가져오며, 해당 WAN 링크에 대해 언더레이 계산(Underlay Accounting)이 켜져 있는 경우, 패킷 손실이 VoIP 및 화상 통화 호출 등의 일반적인 양방향 흐름에서 발생할 수 있습니다.

• 해결된 문제 93062: 사용자가 VMware Orchestrator에서 원격 진단 "인터페이스 상태(Interface Status)"를 실행하면 Orchestrator에서 해당 테스트에 대한 오류를 반환하고 완료되지 않거나 테스트가 라우팅된 인터페이스에 대한 결과를 반환하지 않습니다.

  "테스트 데이터를 읽는 중 오류 발생"이라는 오류 메시지가 표시됩니다. 테스트가 완료되면 라우팅된 인터페이스에 대한 결과가 비어 있고 속도 또는 전이중 모드에 대한 정보도 없습니다. 어느 방향으로든 인터페이스 상태가 끊어집니다.  이 문제는 DPKD 지원 포트를 생략하는 인터페이스 상태의 기반이 되는 디버그 명령과 관련이 있습니다.

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

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

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

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

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

___________________________________________________________________

Edge/게이트웨이 버전 R422-20220530-GA에서 해결됨

Edge/게이트웨이 버전 R422-20220530-GA는 2022년 6월 1일에 릴리스되었으며 8번째 릴리스 4.2.2용 Edge/게이트웨이 롤업입니다.

이 Edge/게이트웨이 롤업 빌드는 7번째 Edge/게이트웨이 롤업, 버전 R422-20220518-GA 이후의 아래와 같은 중요한 문제를 해결합니다.

• 해결된 문제 83437: 향상된 고가용성 토폴로지로 구성된 사이트의 경우 VMware SD-WAN HA Edge를 4.2.x 릴리스로 업그레이드하면 사이트에서 성능 저하를 확인할 수 있으며 HA Edge 중 하나에서 실제로 연결이 끊어질 때 하나 이상의 WAN 인터페이스가 실행 중(UP)으로 표시될 수 있습니다.

  이것은 HA Edge의 부팅 주기 동안 인터페이스가 설정되는 방식과 관련된 플랫폼 문제로, 일부 경우에 고급 HA 설정에서 하나의 HA Edge에 물리적으로 연결된 WAN 인터페이스가 두 장치 모두에 연결된 것으로 잘못 플래그가 지정될 수 있습니다. 이로 인해 영향을 받는 인터페이스의 WAN 링크 성능이 간헐적으로 100%까지 저하되고 해당 링크에서 모든 트래픽이 삭제됩니다.

  이 문제는 원격 진단(Remote Diagnostics)으로 이동하고 인터페이스 상태(Interface Status) 진단을 실행하여 식별할 수 있습니다. 영향을 받는 WAN 회로의 경우 출력에는 "링크 감지됨: true"가 표시되지만 속도는 "0mps, 반이중"으로 표시되면 이 사이트에서 이 문제가 발생한 것입니다.

  이 문제는 고급 HA Edge를 4.2.x 릴리스로 업그레이드할 때 가장 일반적으로 발생하지만, 4.2.x 릴리스로 이미 업그레이드된 고급 HA Edge에서도 발생할 수도 있으며 문제가 트리거될 때가 부팅 주기이므로 나중에 HA Edge가 재부팅됩니다.

  이 수정 사항이 없는 빌드를 사용하는 HA Edge의 경우 강제로 HA 페일오버를 수행하여 문제를 해결할 수 있습니다. 이 작업은 Orchestrator를 통해 원격 작업(Remote Actions)> 강제 HA 페일오버(Force HA Failover)를 사용하여 수행할 수 있습니다. 이렇게 하면 조건이 수정되지만 나중에 HA Edge가 재부팅될 때 동일한 문제가 되풀이되는 것을 방지하지는 못합니다.

• 해결된 문제 87205: 파트너 게이트웨이를 사용하여 VMware SD-WAN Edge를 배포하는 고객의 경우 Edge가 파트너 게이트웨이에서 새 경로를 학습하면 고객 트래픽이 중단될 수 있습니다.

  이 문제는 잘못된 비즈니스 정책과 일치하는 트래픽으로 인해 발생합니다. 예를 들어 파트너 게이트웨이로 향하는 DHCP 트래픽을 대신 인터넷 백홀 규칙과 일치시킬 수 있으며 이로 인해 고객 트래픽이 중단될 수 있습니다.

  이 수정 사항을 적용하지 않으면 원격 진단 "흐름 플러시(Flush Flows)"에서 Edge 흐름을 플러시하여 문제를 해결할 수 있습니다. 이 업데이트를 적용해도 향후에 Edge에서 파트너 게이트웨이로 새 경로를 학습할 때 이 문제가 발생할 수 있습니다.

___________________________________________________________________

Edge/게이트웨이 버전 R422-20220518-GA에서 해결됨

Edge/게이트웨이 버전 R422-20220518-GA는 2022년 5월 24일에 릴리스되었으며 7번째 릴리스 4.2.2용 Edge/게이트웨이 롤업입니다.

이 Edge/게이트웨이 롤업 빌드는 6번째 Edge/게이트웨이 롤업, 버전 R422-20220511-GA 이후의 아래와 같은 중요한 문제를 해결합니다.

• 해결된 문제 80814: 로컬 Edge 클라이언트 소스 IP 주소와 원격 클라이언트를 대상 IP 주소로 사용하고 다른 트래픽에 대해 “모두 거부(Deny All)” 규칙이 있는 표준 방화벽 허용 규칙이 구성된 VMware SD-WAN Edge에서 원격 클라이언트로부터 로컬 클라이언트로의 트래픽이 삭제됩니다.

  이 문제는 소스 호스트와 대상 호스트 간에 VLAN IP 주소가 일치하지 않는 경우에 발생합니다. 소스 및 대상 호스트가 서로 다른 VLAN에 속하는 경우 SD-WAN 서비스는 방화벽 조회 키에 있는 첫 번째 패킷의 소스/대상 IP 주소를 선호합니다. 따라서 오버레이 인바운드 흐름의 경우 불일치가 발생하고 트래픽에 [모두 거부(Deny All)] 방화벽 규칙이 적용됩니다.

  이 수정 사항을 적용하지 않는 경우 이 문제의 해결 방법은 패킷이 방화벽 규칙과 일치할 수 있도록 흐름의 첫 번째 IP 패킷 방향으로 규칙을 되돌리는 것입니다.

• 해결된 문제 82485: 초급 VMware SD-WAN Edge 모델(예: Edge 510, 510-LTE 또는 610)에서 사용자가 원격 진단 "경로 테이블 덤프"를 실행하는 경우 Orchestrator UI 페이지가 시간 초과되어 결과를 반환하지 않을 수 있습니다.

  16,000개보다 많은 경로가 있는 경우 Edge가 결과를 반환하는 데 30초 넘게 걸리므로 이 문제가 발생합니다. 30초는 페이지의 WebSocket에 대한 시간 제한이므로 결과가 반환되지 않습니다. 이 문제에 대한 수정 사항을 적용하면 시간 초과가 발생하지 않도록 경로 테이블 워크가 최적화됩니다.

• 해결된 문제 88757: Orchestrator UI에서 원격 진단 “경로 테이블 덤프”를 실행 중인 경우 시도 시간이 초과되어 페이지가 결과를 반환하지 않을 수 있습니다.

  WebSocket 시간 초과가 30초이고 많은 수의 경로가 있는 사이트에서는 디버그 명령이 Orchestrator로 모든 경로를 전달하는 데 걸리는 시간이 이 시간을 초과할 수 있으므로 경로 테이블 덤프 진단 시간이 초과될 수 있습니다. 이 수정 사항은 경로 덤프 프로세스의 시간 초과를 30초 미만으로 줄이고 WebSocket이 이 시간보다 먼저 시간 초과되지 않도록 하므로 경로 테이블 덤프가 결과를 반환하게 됩니다.

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

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

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

  참고: 이 수정 사항은 게이트웨이 OVA에만 사용할 수 있습니다. Orchestrator OVA에 영향을 미치므로 이 문제는 Orchestrator 섹션에서 동일한 티켓 #88796으로 추적됩니다.

___________________________________________________________________

Edge/게이트웨이 버전 R422-20220511-GA에서 해결됨

Edge/게이트웨이 버전 R422-20220511-GA는 2022년 5월 16일에 릴리스되었으며 6번째 릴리스 4.2.2용 Edge/게이트웨이 롤업입니다.

이 Edge/게이트웨이 롤업 빌드는 5번째 Edge/게이트웨이 롤업, 버전 R422-20220419-GA 이후의 아래와 같은 중요한 문제를 해결합니다.

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

  대기 Edge가 감지되면 활성 Edge는 모든 경로 정보를 대기 Edge와 동기화합니다.  하지만 많은 수의 경로 동기화 메시지가 있는 경우 Edge가 이러한 경로 동기화 메시지를 처리하는 방식으로 인해 대기 Edge에서 데이터부 서비스 실패 또는 스레드 우선 순위 반전이 발생하여 처리 중에 하트비트 처리가 지연되고 활성/활성 상태가 될 수 있습니다. 이 경우 기존 HA 토폴로지에서 대기 Edge가 고객 트래픽을 전달하지 않으므로 고객에게 미치는 영향은 최소화됩니다. 하지만 대기 Edge가 트래픽도 전달하는 고급 HA 배포에서는 재부팅으로 인해 일부 고객 트래픽이 중단될 수 있습니다. 이 수정 사항을 반영한 HA Edge에는 경로 정보 코드 처리 경로가 개선 되어 문제 발생을 방지합니다.

___________________________________________________________________

Edge 및 게이트웨이 버전 R422-20220419-GA에서 해결됨

Edge/게이트웨이 버전 R422-20220419-GA는 2022년 4월 20일에 릴리스되었으며, 아래에 있는 Edge 및 게이트웨이 버전 R422-20220310-GA 이후의 중요한 문제를 해결합니다.

• 해결된 문제 65466: 대규모 BGP 경로 교환을 처리하는 VMware SD-WAN Gateway 또는 VMware SD-WAN Edge에서 특정 디버그 명령을 실행하거나 진단 번들을 생성할 때 데이터부 서비스 장애가 발생하고 다시 시작될 수 있습니다.

  많은 수의 경로를 처리하는 Edge 또는 게이트웨이(예: 50K BGP 경로를 애드버타이즈하는 Edge 또는 Edge에서 +100K BGP 경로를 학습하는 게이트웨이)에서 디버그 명령 dispcnt(매개 변수 포함)도 실행되는 경우 이 문제가 발생할 수 있습니다.  dispcnt debug 명령은 용량 삭제를 모니터링하는 데 사용되며, 해당 디바이스의 CLI에서 파트너 운영자가 실행하거나 진단 번들을 생성하는 동안 사용자가 실행할 수 있습니다. 많은 수의 경로가 있는 Edge 또는 게이트웨이에서 이 명령을 실행하고 다른 이벤트(예: 경로 삭제)가 발생하여 원래 변수가 현재 오래된 메모리 위치를 가리키면 결과적으로 메모리에 대한 잘못된 액세스 때문에 데이터부 서비스 오류가 발생합니다.

• 해결된 문제 67336: 사용자가 Orchestrator의 [모니터링(Monitoring)] 페이지에서 VMware SD-WAN Edge를 확인할 때 전송 통계에는 해당 Edge의 애플리케이션 통계와 비교할 때 훨씬 더 낮은 값이 표시됩니다.

  이 문제는 사용자가 어떤 데이터 집합이 올바른지 알 수 없기 때문에 특정 Edge에 대한 정확한 처리량을 파악할 수 없게 합니다. 이 문제가 발생하면 전송 통계에는 언더레이 계산이 포함되지 않고, 애플리케이션 통계에는 포함되게 됩니다.

• 해결된 문제 69194: 사용자가 USB 모뎀을 한 USB 포트에서 VMware SD-WAN Edge의 다른 포트로 이동하면 Edge에서 데이터부 서비스 오류가 발생하고 결과적으로 다시 시작될 수 있습니다.

  USB 포트가 DPDK AF_PACKET 드라이버에 잘못 바인딩됩니다. 이 드라이버는 포트 제거를 지원하지 않으며 USB 동글이 한 포트에서 다른 포트로 이동될 때 Edge의 데이터부 서비스가 실패할 수 있습니다.

• 해결된 문제 83946: VMware SD-WAN Edge LAN 측 클라이언트는 트래픽 중단을 관찰할 수 있으며 RADIUS 인증을 사용하는 사이트의 경우 클라이언트 사용자가 인증 실패를 관찰할 수 있습니다.

  큰 패킷은 조각화되고 이러한 조각화된 패킷은 Edge에 의해 삭제될 수 있습니다. 일부 오류 시나리오에서 조각 IP ID 변환 중에 메모리 누수로 인해 패킷이 삭제되고, 조각화된 패킷에 대한 Edge 제한이 초과되면 조각화된 패킷이 Edge에서 추가로 삭제됩니다.

  무선 클라이언트에서 Edge로 RADIUS 인증을 사용하는 큰 패킷이 포함된 RADIUS를 사용하는 고객의 경우 이로 인해 인증이 실패할 수 있습니다. 예를 들어, WLC(무선 LAN 컨트롤러)에서 RADIUS 서버로 전송되는 큰 패킷이 삭제될 수 있습니다.

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

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

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

  • 단일 단계에서 대규모 구성을 적용하는 대신, 각 섹션이 별도로 적용된 여러 개의 작은 섹션으로 구성을 구분해야 합니다.
  • 라우팅 필터 수를 최소화해야 합니다.
  • Edge는 유지 보수 기간에만 고의로 다시 시작해야 하며, 다시 시작하는 동안 전체 Edge 구성이 한 번에 적용되어 이 문제가 발생할 위험이 크게 증가하므로 여러 라우팅 필터가 구성된 경우 일반적으로 Edge 서비스를 다시 시작하지 않아야 합니다.

___________________________________________________________________

Edge 버전 R422-20220310-GA에서 해결됨

Edge 버전 R422-20220310-GA는 2022년 3월 15일에 릴리스되었으며 Edge 버전 R422-20220210-GA 이후의 중요한 문제를 해결합니다.

게이트웨이 버전 R422-20220310-GA는 2022년 3월 15일 릴리스되었고, VMware 기반 하이퍼바이저를 사용할 때 ESXi 버전 7.0에 대한 지원이 추가되었습니다.

• 해결된 문제 57597: 배포의 일부로 인터넷 백홀을 사용하는 고객의 경우 4.x 소프트웨어 버전으로 업그레이드한 후 핸드오프 대기열 손실 개수 및 성능 저하가 발생할 수 있습니다.

  애플리케이션 동기화를 위해 Edge 소프트웨어 버전 4.0 이후에는 잠금이 새로 도입되었으며, 이 잠금으로 인해 IPv4 인터넷 백홀에서 성능 저하가 발생할 수 있습니다. 이 티켓의 수정 사항은 적절한 애플리케이션 동기화를 보장하면서 잠금을 제거하는 것입니다.

• 해결된 문제 65695: 고객은 연결된 서브넷으로 향하는 트래픽이 실패하는 것을 확인할 수 있습니다.

  이 문제는 '연결 가능' 상태가 False로 전환된 후에도 IPv4/IPv6 연결 서브넷이 오버레이에 재분산되는 것입니다. 상위 인터페이스가 중단되면 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 주소를 가져온 후 이 경로는 삭제되지 않습니다.

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

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

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

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

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

• 해결된 문제 77625: 고가용성 토폴로지로 배포된 사이트에서 VMware SD-WAN 대기 Edge가 여러 번 다시 부팅되는 것이 확인될 수 있습니다.

  HA 하트비트 패킷을 처리하는 동안 HA 스레드가 고갈되어 사이트가 활성/활성(분할 브레인) 상태로 전환됩니다. 활성-활성 상태에서 결정 기준이 활성 Edge로 이동하고 대기 Edge가 재부팅되어 다시 적절한 대기 상태로 강등됩니다. 하지만 이 경우 활성/활성 이벤트는 사이트를 복구하기 위해 대기 Edge가 재부팅될 때마다 여러 번 감지됩니다. 

  필드 문제에는 Edge 6x0(610, 620, 640, 680) 모델이 관련되어 있지만 이 문제는 플랫폼에 독립적이며 다른 Edge 모델에서 발생할 수 있습니다.

• 해결된 문제 77642: 고객이 VMware SD-WAN Edge에서 성능 저하로 이어지는 핸드오프 대기열 삭제 및 패킷 삭제 수가 증가를 확인할 수 있습니다.

  Edge 서비스에는 100% 활용률이 될 수 있는 비동기 흐름을 모니터링하는 스레드가 있으며 이로 인해 핸드오프 대기열이 삭제되어 성능이 저하될 수 있습니다.

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

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

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

___________________________________________________________________

Edge 버전 R422-20220210-GA에서 해결됨

Edge 버전 R422-20220210-GA는 2022년 2월 18일에 릴리스되었으며 Edge 버전 R422-20220119-GA 이후의 중요한 문제를 해결합니다.

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

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

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

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

• 해결된 문제 57281: VMware SD-WAN Edge는 Edge가 예외를 트리거하고 재부팅되는 상태가 될 수 있습니다.

  이 문제는 여러 허브가 사용되는 허브/스포크 토폴로지를 사용하는 고객 엔터프라이즈에서 발생할 수 있습니다. 예외는 흐름 제어의 대상 경로에 대한 잘못된 메모리 액세스로 인해 트리거되고 이러한 상황에 대한 적절한 온전성 검사가 부족하여 발생했습니다.

• 해결된 문제 66691: VMware SD-WAN Edge 모델 6x0(610/620/640/680)에서 자동 협상 상태가 올바르게 표시되지 않습니다.

  모든 Edge 6x0 모델에서 Intel x553 NIC가 사용되기 때문에 SFP1 및 SFP2에서는 자동 협상이 지원되지 않습니다. 그러나 GE1-GE6(구리 포트)에서는 자동 협상이 지원됩니다. 하지만 Edge의 ethtool은 ixgbe 드라이버의 결함으로 인해 모든 포트에 대해 자동 협상이 항상 켜져 있다는 사실을 전달합니다.

• 해결된 문제 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 프로세스에 실제로 필요하지 않습니다. 

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

  일반적으로 스포크 Edge에 이미 동적 Edge 간 터널이 많이 설정된 경우 고정 터널에 대한 스포크에서 최대 터널 수 검사에 도달했습니다. 이 검사는 스포크에서 허브로의 고정 터널 형성을 방지합니다.

• 해결된 문제 78300: VMware SD-WAN Edge가 백업용으로 구성된 WAN 링크를 사용하는 경우 사용자는 이 링크에 대해 터널이 작동 중이거나 종료되었음을 암시하는 Orchestrator 이벤트 또는 로그를 확인할 수 있습니다.

  설계상 백업 링크에 대해 터널이 설정되지 않습니다. 그러나 원격 끝(일반적으로 동적 Edge 간 터널)의 터널 요청은 스택을 통과할 때 링크 상태를 변경할 수 있습니다. 이 수정 사항은 백업 링크에 대해 터널 형성 또는 해체가 진행 중임을 나타내는 로그가 표시되지 않도록 주의해서 작성되었습니다.

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

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

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

  HA 페일오버에서 OSPF 외부 LSA(링크 상태 애드버타이즈)에 경로 태그가 없으므로 라우팅이 잘못될 수 있습니다.

___________________________________________________________________

Edge 버전 R422-20220119-GA에서 해결됨

Edge 버전 R422-20220119-GA는 2022년 1월 21일에 릴리스되었으며 Edge 버전 R422-20211216-GA 이후의 중요한 문제를 해결합니다.

• 해결된 문제 58791: BGP가 사용되는 고가용성 토폴로지로 배포된 사이트에서 VMware SD-WAN Edge가 반복적으로 페일오버되는 문제가 발생할 수 있습니다.

  이 문제는 HA 사이트에 512개를 초과하는 BGPv4 필터 접두사가 구성된 경우 Hub/스포크 토폴로지 내에 구성된 HA 사이트에 영향을 미칩니다.

  BGP가 구성된 여러 네트워크 명령과 함께 사용되고 대기 Edge가 실행되는 동안 모든 구성을 대칭적으로 구문 분석하고 모든 네트워크에 대해 명령 vtysh가 생성되므로 verp 스레드가 실행되지 않습니다. verp 스레드가 지연되어 하트비트 처리가 지연되며, 이로 인해 대기 Edge가 활성 Edge를 종료된 것으로 판단하고 대기 Edge가 활성화되어 분할 브레인 상태(활성-활성)가 됩니다. 분할 브레인 상태에서 복구하기 위해 대기 Edge가 다시 시작되며 순환이 반복됩니다.

  수정하지 않는 경우 BGP 필터 접두사 구성 수를 집계하고 전체 수를 512(인바운드 256개 및 아웃바운드 필터 256개)개 미만으로 줄여 문제를 해결할 수 있습니다.

  참고: 이 티켓 설명의 이전 버전에서는 BGP match 및 set 작업이 있는 HA 사이트에 대한 수정 사항이라고 설명했습니다. 문제의 해당되는 부분은 이 티켓으로 수정되지 않으며 문제 #84825로 추적됩니다.

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

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

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

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

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

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

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

• 해결된 문제 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에 설치되면 라우팅 문제가 발생합니다.

• 해결된 문제 77040: 고객이 게이트웨이를 통한 NSD 또는 Edge를 통한 NSD(비 SD-WAN 대상)를 배포할 때 SA(보안 연결)가 실패하면 NSD 유형과 관련된 메모리 누수가 발생할 수 있습니다.  따라서 게이트웨이를 통한 NSD의 경우 VMware SD-WAN Gateway에서 메모리 누수 발생이 확인될 수 있으며, Edge를 통한 NSD의 경우 VMware SD-WAN Edge에서 메모리 누수가 발생될 수 있으며 두 경우 모두 고객 트래픽이 중단되면서 서비스 다시 시작을 트리거할 수 있습니다.

  두 경우 모두 메모리가 충분히 누적되면 게이트웨이 또는 Edge는 방어 서비스 다시 시작을 트리거하여 총 메모리 소모를 방지하고 누적된 메모리를 정리합니다. 메모리 누수는 해당 Edge/게이트웨이 서비스가 20초마다 메모리를 증분시키는 ik_ds 구조를 자동으로 정리하지 않기 때문에 디바이스의 메모리가 부족해지기 때문입니다.

• 해결된 문제 77525: 고가용성 토폴로지를 사용하는 사이트의 경우 VMware SD-WAN HA Edge가 새 소프트웨어 이미지로 업그레이드되면 대기 Edge가 실패하고 실제로 그렇지 않더라도 VMware SD-WAN Orchestrator UI에 대기 Edge의 상태가 '활성(Active)'으로 잘못 표시될 수 있습니다.

  활성 Edge가 대기 Edge를 감지하면 대기 Edge의 소프트웨어 버전을 가져오려고 하며, 버전이 3.4.x 이상인 경우 활성 Edge는 네트워크 구성 파일을 대기 Edge에 복사합니다. 대기 Edge 소프트웨어 버전을 가져오는 동안 Edge의 HA 코드에서 처리되지 않는 예외가 발생할 수 있으며 이로 인해 HA 작업자 스레드가 중단되고 대기 Edge와의 추가 통신이 실패합니다. 이 시점에서 활성 및 대기 Edge 간의 관리 프로세스가 중단되고 소프트웨어 관리, 대기 Edge 상태 및 구성 변경을 포함하여 관리부와 관련된 모든 항목이 활성 및 대기 Edge 간에 동기화되지 않습니다. 이로 인해 대기 Edge가 활성으로 잘못 감지되고 Orchestrator에서 활성/활성 "분할 브레인" 상태로 나타나지만 대기 Edge가 여전히 적절한 역할을 수행하고 있기 때문에 그렇지 않습니다.

  HA 페일오버가 있고 대기 Edge가 활성 상태로 승격되면 Edge는 일치하지 않는 구성 및 소프트웨어 집합을 사용합니다. Orchestrator는 구성 불일치를 감지하고 이전에 누락된 대기 Edge의 소프트웨어 업그레이드를 완료하는 동안 업데이트된 구성을 이 Edge로 푸시합니다. 또한 Edge 소프트웨어 업그레이드에는 재부팅이 필요하기 때문에 고객은 새로 활성화된 Edge가 재부팅된 후 다시 대기 상태로 강등되는 동안 또 다른 페일오버를 확인하게 됩니다. 

  이 문제는 HA 사이트가 Edge의 소프트웨어를 업그레이드할 때 일관되게 발생하지 않습니다. 또한 이 문제는 대기 Edge가 해당 소프트웨어를 업그레이드해야 하는 경우 새 HA 사이트를 표시하거나 독립형 사이트를 고가용성으로 전환할 때에도 발생할 수 있습니다. 하지만 이러한 보조 시나리오는 HA Edge에서 소프트웨어 업그레이드가 진행될 경우와 비교하면 거의 드물게 발생합니다.

  수정 사항을 적용하지 않으면 이 문제가 확인된 고객은 Edge 서비스를 다시 시작하거나 HA 페일오버를 트리거하여 문제를 해결해야 합니다.

• 해결된 문제 77586: 릴리스 4.2.2 GA를 사용하고 OSPF를 사용하여 고가용성 토폴로지로 배포된 사이트에서 고객 트래픽이 중단될 수 있습니다.

  HA IP는 Edge 서비스에서 VMware SD-WAN 라우팅 프로토콜에 부여되고 OSPF 서비스는 LSA에서 해당 IP를 사용합니다(링크 상태 애드버타이즈). 보고된 필드에서 Edge가 4.2.1을 실행 중일 때 HA IP가 OSPF router-id로 선택되고, HA Edge를 4.2.2로 업그레이드한 후 router-id가 다른 인터페이스 IP로 변경됩니다. 그러나 HA IP LSA가 유지되고 애드버타이즈되고 있으며 이로 인해 SPF(최단 경로 우선) 계산이 중단되고 네트워크 중단이 발생할 수 있습니다.

  참고: 수정 사항을 적용하지 않으면 이 문제가 모든 플랫폼 및 모든 릴리스에서 확인될 수 있으며 이전에 명시된 필드 사례로 제한되지 않습니다.

___________________________________________________________________

Edge 버전 R422-20211216-GA에서 해결됨

Edge 버전 R422-20211216-GA는 2021년 12월 20일에 릴리스되었으며 Edge 버전 R422-20210923-GA 이후의 중요한 문제를 해결합니다.

• 해결된 문제 53951: VMware SD-WAN Edge에서 인터넷으로 직접 전송되는 트래픽이 실패하거나 VMware SD-WAN Orchestrator에 대한 연결이 끊기고 Edge가 종료된 것으로 표시될 수 있습니다.

  이 문제는 다음 두 가지 시나리오 중 하나에서 Edge에 영향을 줄 수 있습니다.

  1. 공용 WAN 링크를 사용하는 Edge의 경우 WAN 링크에 플래핑이 발생하면(링크가 종료되었다가 실행됨) 이 시나리오에서 고객에게 미치는 영향은 영향을 받는 링크로 조절되고 직접 트래픽으로 분류된 트래픽이 삭제된다는 것입니다. 이 문제는 특정 트래픽이 직접 전송되는 동안에만 강제로 하나의 WAN 링크를 사용하도록 비즈니스 정책 규칙이 구성된 사이트에 특히 영향을 미칩니다.
  2. PPPoE WAN 링크를 사용하여 Edge에서 HA를 사용하도록 설정하면 PPPoE 인터페이스 IP가 변경되고 이전 자체 경로가 삭제되지만 새 PPPoE IP 주소를 사용하면 새 자체 경로가 추가되지 않습니다. 그 결과 Orchestrator와 Edge 간의 통신이 더 이상 작동하지 않습니다.

  이 수정 사항을 적용하지 않을 경우 문제를 일시적으로 해결하는 방법은 Edge 서비스를 다시 시작하여 직접 트래픽이 영향을 받는 공용 WAN 링크에서 전송되도록 하거나, Edge를 재부팅하여 Orchestrator로 경로를 복구하는 것입니다(PPPoE 링크가 사용되는 경우).

• 해결된 문제 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가 실패하기 때문에 발생합니다.

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

  2021-08-26T01:05:21.397 WARNIN kern   kernel:[244841.443763] ath10k_pci 0000:01:00.0: SWBA overrun on vdev 1, skipped old beacon
  2021-08-26T01:05:21.539 INFO   kern   kernel:[244841.586338] ieee80211 phy0: Hardware restart was requested
  2021-08-26T01:05:24.207 WARNIN kern   kernel:[244844.254081] ath10k_warn: 17 callbacks suppressed
  2021-08-26T01:05:24.207 WARNIN kern   kernel:[244844.254091] ath10k_pci 0000:01:00.0: failed to receive control response completion, polling..
  2021-08-26T01:05:24.223 ERR    kern   kernel:[244844.270245] ath10k_pci 0000:01:00.0: firmware crashed! (구성 n/a)
  

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

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

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

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

• 해결된 문제 72245: VMware SD-WAN Hub Edge가 MPLS 네트워크에서 파생된 인터넷으로 사용되는 경우 연결된 스포크 Edge의 개인 인터페이스에서 공용 게이트웨이로의 관리(VCMP) 터널이 종료되거나 실행되지 않을 수 있습니다.

  스포크 Edge의 개인 인터페이스에서 공용 게이트웨이로의 관리(VCMP) 패킷은 허브 Edge를 통해 전송합니다. 이 시나리오에서 허브는 이 흐름을 직접 흐름으로 간주하고 공용 인터페이스를 통해 이러한 패킷을 인터넷으로 푸시합니다. 라우팅 문제로 인해 이러한 흐름은 "게이트웨이를 통한"으로 표시될 수 있으며 이로 인해 흐름에 영향을 주어 위에서 설명한 문제가 발생할 수 있습니다.

• 해결된 문제 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(오버레이 흐름 제어) 또는 게이트웨이에 표시되지 않는 것입니다.

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

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

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

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

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

버전 R422-20210923-GA에서 해결됨

아래 문제는 Edge 버전 R421-20210624-GA-57011-60130 및 게이트웨이 버전 R421-20210407-GA 이후에 해결되었습니다.

• 해결된 문제 34037: VMware SD-WAN Gateway에서 피어 터널이 삭제된 후 데이터부 서비스 장애가 발생할 수 있습니다.

  피어 터널이 비활성 상태가 되면 정리 프로세스에서는 fc-> vpi를 가져와 NULL에 할당합니다. 이 fc에 대한 참조가 아직 남아 있는 패킷이 파이프라인에 소스 남아 있는 것 같습니다. 해당 패킷을 처리하는 동안 NULL인 fc->vpi에 액세스되므로 게이트웨이 프로세스에서 예외가 발생하고 다시 시작됩니다.

• 해결된 문제 34626: VMware Edge에서 VMware SD-WAN Gateway로의 잘못된 제어 패킷으로 인해 게이트웨이에서 데이터부 서비스 장애가 발생하고 다시 시작될 수 있습니다.

  Edge에서 게이트웨이로의 흐름에 대해 Edge는 각 흐름에 대한 비즈니스 정책 작업을 동기화하기 위해 제어 메시지를 게이트웨이로 보냅니다. 제어 메시지에 잘못된 작업이 포함된 경우 잘못된 작업 집합을 사용하여 흐름의 데이터 패킷을 라우팅하려고 하면 게이트웨이가 다시 시작될 수 있습니다.

• 해결된 문제 40268: 사용자가 VMware SD-WAN Hub 또는 허브를 통한 Edge 간 구성을 변경하는 경우 스포크 Edge는 'False'로 표시된 경로를 설치합니다.

  스포크 Edge는 FALSE로 표시된 FIB에 경로를 설치하며(해당 경로의 허브에서 연결되는 터널이 없으므로) 이러한 경로는 지우기 전에 2분 동안 FIB에 유지됩니다.  이때 이러한 False 경로로 인해 일부 네트워크가 중단될 수 있습니다. 

• 해결된 문제 41837: 원래 IP 주소 대신 소스 및 대상의 NAT IP 주소가 VMware SD-WAN Edge의 로그에 출력됩니다.

  Edge 방화벽 로그에는 원본 소스 및 대상 IP 주소가 표시되어야 하지만 NAT 처리된 IP가 대신 출력되므로 방화벽 로그의 신뢰성이 크게 저하됩니다.

• 해결된 문제 43278: 사용자가 기본 경로 또는 접두사와 일치하도록 아웃바운드 BGP 필터를 구성한 다음, AS Path prepend를 설정하면 기본 경로 또는 접두사가 BGP 인접 항목에 애드버타이즈되지만 AS Path prepend가 발생하지 않습니다.

  접두사를 일치시키고 AS Path prepend를 설정하기 위한 BGP 아웃바운드 인접 항목 필터 집합이 BGP 고급 구성 “네트워크” 문을 사용하여 시작된 접두사에 작동하지 않습니다. 또한 인접 항목 "DR 시작"을 통해, BGP 고급 "조건부" 기본 경로 애드버타이즈(Advanced "Conditional" Default Route Advertise) 확인란을 통해 인접 항목으로 시작된 기본 경로에 대해서도 작동하지 않습니다.

  또한 VMware SD-WAN Edge에서 고정 경로 구성을 사용하는 경우 기본 경로 또는 "애드버타이즈"로 설정된 비 DR 고정 경로가 AS Path prepend가 설정된 BGP 인접 항목에 애드버타이즈되지 않습니다. 접두사의 유일한 AS는 Edge의 자체 AS입니다.

• 해결된 문제 44379: VMware SD-WAN Gateway에서 새 흐름을 생성하지 못할 수 있습니다.

  이 문제는 게이트웨이가 부팅 시 흐름 정리 이벤트를 시작하지 않아 게이트웨이를 통한 흐름이 결국 실패하기 때문에 발생합니다.

• 해결된 문제 44526: 서로 다른 두 사이트가 고가용성 토폴로지를 사용하는 동시에 VMware SD-WAN Edge를 허브로 배포하는 엔터프라이즈에서 각 사이트가 다른 허브 사이트를 해당 프로필의 허브로 사용합니다.  허브 사이트 중 하나가 HA 페일오버를 트리거하는 경우 두 허브 Edge가 서로 간에 터널을 다시 설정하는 데 30분까지 걸릴 수 있습니다. 

  HA 페일오버에서 두 허브 Edge가 동시에 서로 간에 터널을 시작하려고 하지만 둘 다 피어에 응답하지 않으면 두 허브 간의 패킷 교환이 발생하지만 IKE는 성공하지 못합니다. 이로 인해 자체적으로 해결되는 데 최대 30분까지 소요되는 것으로 확인된 교착 상태가 발생합니다. 이 문제는 간헐적이며 모든 HA 페일오버 후 발생하는 것은 아닙니다. 

  이 수정 사항을 적용하지 않을 경우 이 문제가 발생하지 않도록 하려면 고객은 반드시 두 HA 허브 사이트 중 하나가 다른 허브 사이트를 자체 허브로 사용하도록 구성해야 합니다. 예를 들어, 두 개의 HA 허브 사이트 Hub1과 Hub2가 있는 경우 Hub1은 해당 프로필에서 자체 허브로 Hub2를 포함할 수 있지만, Hub2는 해당 프로필에서 Hub1을 허브로 사용하면 안 됩니다.

• 해결된 문제 46489: 서로 다른 파트너 게이트웨이 지원 프로필이 여러 VMware SD-WAN Edge에 할당된 경우 Edge는 해당 프로필에 할당되지 않은 VMware SD-WAN 파트너 게이트웨이에 대한 오래된 라우팅 항목을 유지합니다.

  다른 파트너 게이트웨이 지원 프로필이 여러 Edge에 할당된 경우 Edge는 다른 게이트웨이에서 학습된 라우팅 항목을 유지하며 해당 경로는 오래된 항목으로 간주됩니다.  Edge가 해당 프로필에 대해 잘못된 경로로 트래픽을 전송하려고 하기 때문에 트래픽이 올바르게 라우팅되지 않게 됩니다.

• 해결된 문제 47244: DPDK가 사용하도록 설정되고 Copper SFP가 있는 활성화된 VMware SD-WAN Edge 6x0에서 케이블이 삽입되지 않은 경우에도 VMware SD-WAN Orchestrator UI에 Edge가 링크를 '실행 중'으로 표시합니다.

  이 문제로 인해 6x0 모델 라인의 Edge에 대한 특정 SFP 포트의 실제 상태를 사용자가 혼동할 수 있습니다.

  이 수정 사항을 적용하기 전에 문제를 해결할 수 있는 유일한 방법은 임의 케이블을 꽂은 다음, 해당 케이블을 영향을 받는 SFP 포트에서 분리하는 것입니다.

• 해결된 문제 48612: X710/XL710 네트워크 어댑터를 사용하는 VMware SD-WAN 가상 게이트웨이 및 Edge는 모든 Rx 패킷 VLAN 태그를 제거합니다.

  이 문제는 DPDK가 사용하도록 설정되어 있는 게이트웨이를 사용하는 고객에게는 심각한 영향을 미치게 됩니다. 이러한 고객들은 핸드오프 인터페이스에서 VLAN 태그가 지정된 트래픽을 처리할 수 없기 때문입니다. 이 문제는 PF(물리적 기능)에 opcode VIRTCHNL_OP_ADD_VLAN을 전송하여 VLAN 필터링 태그를 추가한 i40evf DPDK 드라이버의 문제로 확인되었지만, PF 드라이버가 VLAN 태그 필터링을 사용하도록 설정하는 명령의 일부로 VLAN 태그 제거를 사용하도록 설정했으며, 결과적으로 모든 VLAN 태그가 제거되었습니다.

• 해결된 문제 48958: VMware SD-WAN Gateway와 결합된 인터페이스 간에 연결이 끊어질 수 있습니다.

  VCMP(VeloCloud Management Protocol) 및 WAN 포트가 동일한 포트를 사용하도록 설정된 경우 파트너 게이트웨이 VLAN 전달 구성은 ARP 확인 실패로 인해 게이트웨이를 오프라인 상태로 전환할 수 있습니다. 이 수정 사항을 적용하면 VCMP와 WAN 포트가 동일할 때 VMware SD-WAN Orchestrator의 VLAN 전달 구성이 게이트웨이에서 거부됩니다.  이 수정 사항을 적용하지 않을 경우 해결 방법은 VCMP 및 WAN에 대해 동일한 포트를 할당하지 않는 것입니다.

• 해결된 문제 50223: 릴리스 3.4.x 이상을 사용하는 VMware SD-WAN Edge는 SNMP를 통해 물리적 LAN 인터페이스에 대한 정보를 전송하지 않습니다. 

  VMware SD-WAN이 net-snmp를 사용했던 3.4.x 이전 릴리스에서는 LAN 인터페이스가 SNMP를 통해 전송되었습니다. 릴리스 3.4.x에서는 명령 debug.py --interfaces에서 데이터를 가져오며 출력에 LAN 인터페이스에 대한 정보가 없는 고유한 snmpagent를 추가했습니다. 이 수정 사항은 snmpagent가 SNMP를 통해 데이터를 전송할 수 있도록 LAN 인터페이스를 해당 명령에 추가합니다.

• 해결된 문제 50422: VLAN 태그 지정 라우팅 인터페이스를 사용하는 경우 ARP를 통해 피어 MAC 주소가 잘못 학습될 수 있습니다.

  라우팅된 인터페이스에 VLAN 태그가 할당되었고 다음 홉이 태그 없는 ARP 요청을 전송하는 경우 태그 없는 MAC이 학습되고 먼저 학습된 항목에 따라 트래픽이 블랙홀 상태가 될 수 있습니다.

  이 수정 사항을 적용하지 않을 경우 유일한 해결 방법은 라우팅된 인터페이스에 VLAN 태그가 있는 경우 다음 홉에서 태그 없는 ARP 요청을 필터링하는 것입니다.

• 해결된 문제 52127: BGP 또는 OSPF를 사용하도록 설정된 VMware SD-WAN Edge에서 Edge가 전송에서 차단 소켓이 반환되기를 기다리는 동안 시간 초과가 발생한 후 데이터부 서비스 장애가 발생할 수 있습니다.

  일반적으로 다음 서명으로 확인됩니다.
  #0 0x00007f5c09f34754 in send () from deps/lib/libpthread.so.0
  #1 0x000000000092cc7a in vc_zeb_send_to_client (buf=0x7f5aa7fed580 "", length=<optimized out>, client=0x7f5ad402ec90) at /mnt/build/workspace/master-nightly-build/common/libs/drp/vc_zebra.c:188

  Edge 라우팅 및 데이터부 프로세스는 로컬 호스트의 TCP 소켓과 통신합니다. 일부 스레드의 런타임에 따라, 로컬 코어의 작업 대기열 시스템(ksoftirqd)이 열려 있는 소켓에 대한 패킷을 라우팅 프로세스로 전달하기 위한 최소 런타임을 수신하여 OSPF 및/또는 BGP 스레드에 대해 차단된 전송 호출을 진행할 수 있습니다.

  OSPF 및 BGP 스레드의 스레드 우선 순위는 현재 코어를 자발적으로 생성하지 않고 선점을 위해 커널 스케줄러를 사용하는 모든 코어에 대해 재분류되며 ksoftirqd를 통한 더 많은 런타임 및 공동 작업 선점을 허용합니다.

  참고: 이 동일한 문제는 이러한 릴리스 정보의 생략된 중복 티켓 39232에서도 확인됩니다.

• 해결된 문제 53283: 1:1 NAT도 구성된 경우 비즈니스 정책을 통해 지정된 링크 모드가 적용되지 않습니다.

  아웃바운드 트래픽의 경우 일치하는 1:1 NAT 규칙을 찾는 동안(구성된 경우) 비즈니스 정책을 통해 구성된 링크 모드가 무시되고 일치하는 첫 번째 1:1 NAT 규칙이 항상 선택됩니다. 예: 비즈니스 정책에 따르면 링크를 '필수'로 선택해야 하지만 1:1 NAT가 일치하는 첫 번째 1:1 NAT 규칙에 지정된 다른 링크가 선택됩니다. 이 수정 사항을 적용하지 않으면 문제를 해결하는 유일한 방법은 영향을 받는 VMware SD-WAN Edge에 대해 [원격 진단(Remote Diagnostic)] > [흐름 플러시(Flush Flows)]을 실행하는 것입니다.

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

  VMware SD-WAN Edge가 게이트웨이에서 수신된 트래픽 손실을 감지하면 손실된 패킷을 다시 전송하기 위해 게이트웨이에 NACK(부정 승인) 메시지를 전송합니다. 게이트웨이는 패킷을 재전송하기 위해 재전송 슬롯을 확인합니다. 이론적으로는 모든 슬롯이 확인되면 게이트웨이가 재전송을 중지해야 하지만, 게이트웨이는 NACK 메시지의 시퀀스 번호에 도달할 때까지 재전송 슬롯을 반복적으로 확인하며 게이트웨이의 모니터 스레드가 중단된 스레드로 감지하고 게이트웨이를 다시 시작할 수 있습니다.

• 해결된 문제 54001: SFP 인터페이스에서 Tx 대기열이 중단 후 VMware Edge가 트래픽을 전송할 수 없습니다.

  드문 경우지만 Edge가 잘못된 크기의 패킷(17바이트보다 작거나 1526바이트보다 큼)을 DPDK로 전송하면 전송 대기열이 중단되고 Edge에서 추가 트래픽을 전달할 수 없게 됩니다. Edge를 다시 부팅하면 문제가 일시적으로 해결되지만 잘못된 크기의 패킷이 Edge 서비스에서 DPDK로 전송되면 이 문제가 다시 발생될 수 있습니다. 이 수정 사항이 있는 수준으로 업그레이드해야만 이 문제가 방지됩니다.

• 해결된 문제 54136: 고가용성 토폴로지를 사용하는 사이트에서 VMware SD-WAN 활성 Edge는 데이터부 서비스를 다시 시작하여 HA 페일오버가 발생합니다.

  활성 Edge는 많은 수의 흐름(초당 190만 개 흐름)이 있을 때 많은 양의 메모리를 소비합니다.  메모리 사용량이 위험 수준에 도달하면 Edge가 다시 시작되어 메모리를 지우고 페일오버가 발생합니다.

• 해결된 문제 56218: 고가용성 토폴로지로 배포되거나 HA가 사용하도록 설정된 고객 사이트의 경우 Edge를 3.2.x에서 3.4.x로 업그레이드하면 대기 Edge가 종료될 수 있습니다.

  로컬 UI를 사용하여 WAN 설정을 구성한 후 HA를 사용하도록 설정되거나 HA Edge를 3.2.2에서 3.4.x로 업그레이드하면 HA 인터페이스(예: Edge 모델에 따라 LAN1 또는 GE1)가 대기 Edge에서 제거되고 VMware SD-WAN Orchestrator에서 HA 상태가 HA_FAILED로 설정됩니다.

• 해결된 문제 56346: VMware SD-WAN Edge의 모니터링(Monitor) > 시스템(System) 페이지를 표시할 때 핸드오프 대기열 손실 개수가 확인될 수 있습니다.

  VCRP(VeloCloud Route Protocol) 경로 이벤트 업데이트로 인해 VCMP(VeloCloud 관리부) 데이터 스레드에서 핸드오프 대기열 손실 개수가 발생합니다.  이러한 문제는 경로 업데이트가 수신될 때 해당 세그먼트의 모든 경로가 무효화되기 때문에 발생합니다. 이로 인해 데이터 경로에서 새로운 경로가 조회됩니다. 경로 조회의 일부로 호출되는 특정 기능은 비용이 많이 드는 해시 열거 작업을 수행하므로 VCMP 데이터 스레드 활용률이 40% 증가합니다.  현장에서 이 문제가 발견된 경우 핸드오프 대기열 손실 개수가 충분하지 않아 네트워크 성능에 영향을 주지 않습니다.

• 해결된 문제 56379: VMware SD-WAN Gateway에서 메모리가 고갈되어 데이터부 서비스 장애가 발생하고 다시 시작될 수 있습니다.

  VMware SD-WAN Hub Edge가 많은 수의 스포크 Edge(예: ~4000)로 확장되고, 확장된 이 허브 Edge의 경로에 대해 BGP가 플래핑되면 허브 Edge의 기본 게이트웨이가 단일 인스턴스의 모든 스포크 Edge에 업데이트 메시지를 전송합니다. 그러나 BGP 플래핑이 연속해서 여러 번 발생하면 여러 업데이트 메시지가 전송되기 전에 작성됩니다. 이러한 업데이트 메시지 누적으로 인해 메모리가 고갈되고 게이트웨이 다시 시작이 트리거될 수 있습니다.

• 해결된 문제 56483: VMware SD-WAN Orchestrator의 모니터링(Monitor) > 전송(Transport) 화면 아래에 있는 WAN 링크 실시간 모니터링에 패킷 손실, 지터 및 지연 시간이 표시되지 않습니다.

  사용자는 그래프가 직선으로 표시되므로 모니터링(Monitor) > 전송(Transport) 아래에서 특정 WAN 링크의 패킷 손실, 지터 또는 지연 시간에 대한 실시간 데이터를 얻을 수 없습니다. 또한 모니터링(Monitor) > Edge > 개요(Overview) 화면을 확인하면 손실, 지터 및 지연 시간에 대한 모든 값이 '0'으로 표시됩니다. 기록 통계는 모니터링(Monitor) > 전송(Transport)에 올바르게 표시되며, 이 문제는 "라이브 모드" 통계에만 영향을 줍니다. 

• 해결된 문제 56645: VMware SD-WAN Edge 610이 특정 Meraki Access Point에 연결된 경우 WAN 링크 플래핑이 자주 발생합니다.

  Edge 610이 Meraki M36 Access Point(또는 유사한 모델)에 연결되면 이더넷 링크에 링크가 자주 끊깁니다. 이 문제는 Edge 610의 드라이버 문제로 인해 발생합니다.

• 해결된 문제 56876: VMware SD-WAN Edge에서 메모리 관리와 관련된 문제가 발생하여 커널 패닉을 트리거함으로써 Edge가 재부팅될 수 있습니다.

  이 해결된 문제에는 커널 패닉을 트리거하는 Edge의 메모리 관리와 관련된 두 가지 시나리오에 대한 수정 사항이 포함되어 있습니다.

  Edge가 동적 분기 간을 사용하는 첫 번째 시나리오에서는 동적 터널이 생성되면 피어별 카운터를 저장하기 위해 소량이 메모리가 예약됩니다. 동적 터널이 삭제되면 다음번에 동일한 피어가 연결될 때 작동 시간을 최적화하기 위해 이 메모리가 정리되지 않습니다. 시간이 경과하면서 많은 수의 다른 대상에 연결되는 작은 Edge(예: Edge 500, 510, 520, 610)에서는 결과적으로 사용 가능한 메모리가 소진될 수 있으며 커널 패닉과 Edge 재부팅이 트리거될 수 있습니다.  이 수정 사항을 적용하지 않은 상태로 VMware SD-WAN Orchestrator에서 Edge의 모니터링(Monitor) > 시스템(System) 화면을 확인할 때 메모리 사용량이 상태 통계의 90%를 넘으면 사용자는 Edge의 서비스를 사전 대처용으로 다시 시작해야 합니다.

  동적 분기 간으로 인해 발생하는 메모리 누수를 해결하는 동안 malloc_trim(조각난 메모리를 정리하는 프로세스)가 제대로 호출되지 못하는 것이 확인되었으며, 이를 수정하기 위해 이 프로세스도 수정되었습니다. malloc_trim을 올바르게 호출하지 못할 경우 다른 문제가 발생할 수 있고 모든 Edge(더 작은 Edge만이 아님)에 영향을 줄 수 있으며, Edge가 동적 분기 간을 사용할 필요도 없고, 모니터링(Monitor) > 시스템(System)에 메모리 사용량이 90%를 초과하는 것으로 표시되지도 않습니다. 이 시나리오는 Edge에 많은 수의 흐름이 있는 경우 발생할 가능성이 훨씬 높습니다.

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

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

• 해결된 문제 57859: 방금 활성화된 VMware SD-WAN Edge는 VMware SD-WAN Bastian Orchestrator와 통신할 수 없으므로, Orchestrator에서 오프라인으로 표시됩니다.

  이 문제는 Bastian Orchestrator로 트래픽을 전송하기 위해 선택한 WAN 링크에 직접 트래픽을 전송하기 위해 할당된 IP 주소가 없는 경우에 발생합니다.

• 해결된 문제 58075: 고가용성을 사용하도록 설정한 VMware SD-WAN Edge에서 SNMP 탐색/쿼리가 시간 초과됩니다.

  SNMP 쿼리 출력은 일부 결과만 반환하며 결과적으로 HA 지원 Edge에서 시간 초과가 발생합니다.

• 해결된 문제 58259: 경우에 따라 Zscaler 피어를 사용하는 게이트웨이 측에서 VMware 비 SD-WAN 대상 터널이 종료되는 것을 확인할 수 있습니다.

  Zscaler 피어 끝이 2단계 SA(보안 연결)를 삭제하지만 VMware SD-WAN Gateway가 여전히 SA를 유지하는 경우가 있습니다. 이러한 경우 터널이 해체되고 고객이 트래픽을 전달할 수 없게 됩니다.

  이 수정 사항을 적용하지 않을 경우 해결 방법은 2단계 SA 테이블로 이동한 후 1단계 SA가 누락된 2단계 SA가 있는지 확인하는 phase2_sa_check.py 스크립트입니다. 하나를 찾으면 게이트웨이가 터널을 다시 설정합니다.

• 해결된 문제 58527: 원격 진단 "활성 흐름 나열(List Active Flows)"을 실행하는 경우 비즈니스 정책 이름 출력이 예상된 32자가 아닌 24자로 제한되고 비즈니스 정책 이름이 실제 32자에서 24자로 잘립니다.

  .edge.info에서 구성된 biz_policy 이름이 올바르게 나열됩니다(biz_policy_name 필드에서 전체 길이를 차지하는 경우에도). 그러나 user_flow_dump/flow_dump 출력에 biz_policy_name을 표시하는 동안 24자만 사용하여 정책 이름을 저장합니다. 따라서 실제 구성된 biz_policy가 완전히 표시되지 않습니다.

• 해결된 문제 58535: 고객이 상태 저장 방화벽을 구성했으며 네트워크 및 플러드 보호(Network & Flood Protection)에서 거부 목록도 구성한 경우 거부 목록(Denylist)은 자동으로 새 연결에 대해 가장 적극적인 설정으로 설정되고 상태 저장 방화벽은 모든 새 연결을 차단합니다.

  이 문제는 상태 저장 방화벽을 사용하는 고객에게 심각한 영향을 미치며 거부 목록(Denylist) 기능을 사용할 수 없게 됩니다. 거부 목록(Denylist) 기능을 사용하도록 설정하면 방화벽 이벤트가 다음 로그로 채워집니다. "FLOOD_ATTACK_DETECTED" and "Blacklisting source: xxx.xxx.x.x exceeded CPS limit : 0 per source".  여기서 IP 주소는 Edge 관리의 IP 주소이고 CPS는 초당 연결 수입니다. 새 연결 임계값(New Connection Threshold) 제한이 0%로 설정되어 모든 연결 시도가 거부 목록을 트리거함으로써 모든 연결이 차단됩니다.  새 연결 임계값(New Connection Threshold)의 기본값은 25%입니다.

• 해결된 문제 58567: VNF도 구성된 고가용성 토폴로지로 구성된 사이트에서는 VNF가 종료되므로 HA 페일오버가 자주 발생할 수 있습니다.

  Check Point VNF가 HA와 함께 배포되면 VMware SD-WAN Edge는 SNMP 쿼리를 사용하여 VNF 상태를 모니터링합니다. VNF 상태가 3번 연속 시도에서 종료된 것으로 표시되면 Edge는 종료될 VNF를 확인하고 HA 전환을 시작합니다. 이 문제는 일시적으로 Check Point VNF가 SNMP 쿼리에 응답하는 데 1초 넘게 걸릴 수 있기 때문에 Edge가 Check Point VNF의 상태와 관련하여 잘못된 결론에 도달할 수 있고 실행 중일 때 종료 상태로 표시하게 되며, 이러한 실수가 여러 번 발생하면서 HA 페일오버가 자주 발생하기 때문에 나타납니다.

  이 수정 사항을 적용하지 않을 경우 이 문제를 해결할 수 있는 유일한 방법은 VNF가 종료되었음을 확인하기 전에 SNMP 재시도 횟수를 3보다 큰 값으로 늘리는 것입니다. 이 설정은 “snmp_retries” 필드를 수정하고 VNF의 전원을 껐다 켜서 /opt/vc/etc/vnf/default.json에서 구성할 수 있습니다.

• 해결된 문제 58678: 동적 Edge 간(Dynamic Edge-to-Edge)에 사용하도록 설정하고 VMware SD-WAN Edge에서 잘못된 동적 Edge 간 제어 메시지를 수신하는 경우 Edge에서 데이터부 서비스 장애가 발생할 수 있습니다.

  피어 Edge에 대한 터널을 생성하기 위해 Edge는 VMware SD-WAN Gateway에서 동적 Edge 간 정보를 요청합니다. 게이트웨이의 응답 메시지가 손상될 경우 일부 필드에 대해 올바른 유효성 검사가 누락되어 Edge가 다시 시작될 수 있습니다.

• 해결된 문제 58688: VMware Edge Network Intelligence를 사용하는 경우 Edge Network Intelligence 데이터의 클라이언트 MAC 주소에 잘못된 임의 IP 주소가 연결됩니다.

  VMware SD-WAN Edge가 LAN 측 IP 주소 대신 WAN 측 공용 IP 주소를 잘못 전송합니다. 이로 인해 Edge Network Intelligence 데이터에 일치하지 않는 IP 및 MAC 연결이 표시됩니다.

• 해결된 문제 58830: VMware SD-WAN Edge가 파트너 게이트웨이에서 범용 NAT 서브넷을 사용하여 라우팅된 클라이언트에서 VCMP 서버로의 트래픽을 삭제합니다.

  Edge 라우팅 클라이언트에서 VCMP 트래픽으로의 ping이 실패합니다. Ping이 나열된 시나리오에서 실패합니다. 나열된 시나리오는 파트너 게이트웨이에서 Edge로 기본 고정 경로가 애드버타이즈되고, Edge 자체의 로컬 기본 고정 경로가 라우팅된 클라이언트 연결을 위해 언더레이 L3 스위치의 다음 홉을 가리키도록 구성되어 있습니다. 여기서 Edge는 “rfc1918 cloud route match”와 같은 오류를 나타내며 VCMP에서 ICMP 응답 패킷을 삭제합니다.

• 해결된 문제 59008: 여러 USB 링크에 대한 링크 internalID가 여러 VMware SD-WAN Edge 간에 동일할 수 있으므로 VMware SD-WAN Orchestrator에서 잘못된 USB 링크 통계를 유발할 수 있습니다.

  다른 Edge의 USB 링크에는 동일한 내부 ID가 할당될 수 있습니다. 따라서 일부 데이터가 누락될 수 있으므로 다양한 Edge에서 고객에 대해 수행되는 모니터링이 영향을 받습니다.

• 해결된 문제 59236: 향상된 고가용성 토폴로지를 사용하는 사이트의 경우 대기 Edge에 연결된 WAN 링크가 Metanoia SFP인 경우 터널이 구성되지 않으며 이 동작은 HA 페일오버 후에도 지속됩니다.

  고급 HA의 경우 WAN 포트가 대기 Edge에서 차단됩니다(즉, Edge는 해당 WAN 인터페이스에서 TX를 허용하지 않음). Metanoia SFP 인터페이스를 실행하기 위해 하드웨어 간에 패킷 교환이 필요합니다. Edge는 TX를 허용하지 않으므로 인터페이스 초기화가 실패합니다.

• 해결된 문제 59527: 고가용성 토폴로지로 구성되고 HA에 VNF도 배포된 사이트에서 HA 페일오버가 반복적으로 발생하여 고객 작업이 반복적으로 중단될 수 있습니다.

  VNF HA가 실행 중이고 모든 LAN 쪽 링크가 두 Edge에서 종료되면 이 문제가 트리거되고 HA 쌍의 Edge 중 하나 이상에서 LAN 연결이 복원될 때까지 이 문제가 계속 발생합니다.

• 해결된 문제 59629: 고가용성 토폴로지로 배포된 고객 사이트에서 VMware SD-WAN 대기 Edge가 여러 번 다시 시작되는 것이 확인될 수 있습니다.

  활성 및 대기 Edge 둘 다에서 HA 하트비트가 누락되고 두 Edge 모두 활성/활성("분할 브레인"이라고도 함)이 됩니다. 연결을 해제하기 위해 새로 승격된 활성 Edge(이전 대기 Edge)는 로깅 이벤트: "활성/활성 패닉"을 표시하면서 다시 시작됩니다.  이 문제에 대한 수정 사항에는 활성/활성 상태를 유발하는 누락된 하트비트로 표시될 수 있는 하트비트 처리 지연을 최소화하기 위해 HA Edge 하트비트 스레드의 우선 순위를 승격하는 작업이 포함됩니다.

• 해결된 문제 60006: 620 및 640과 같은 하드웨어 기반 VMware SD-WAN Edge에서 HA를 사용하도록 설정하면 대기 Edge가 재부팅될 수 있습니다.

  620 또는 640(이 문제가 발견되었던 모델)에서 HA를 사용하도록 설정하면 대기 Edge가 활성/활성 패닉을 감지하고 대기 Edge가 활성/활성 상태를 수정하기 위해 재부팅됩니다. 이 문제는 Edge 초기화 중 HA 인터페이스 초기화와 HA 상태 시스템 초기화 간의 경합 조건 가능성으로 인해 발생합니다. 즉, HA 인터페이스 드라이버 초기화가 완료되는 것보다 HA 상태 시스템 초기화가 훨씬 더 일찍 시작되므로 HA 상태 시스템은 피어 Edge에서 하트비트를 감지하지 못하고 활성 상태로 전환됩니다.  이 문제는 드물게 발생하므로 한 번 사이트에서 발생하더라도 같은 세션에서 또다시 발생할 확률은 낮습니다. 그러므로 사이트가 대기 Edge 재부팅을 끝없이 반복하지는 않을 것입니다.

• 해결된 문제 60010: 고가용성 토폴로지에 VNF가 배포된 VMware SD-WAN Edge를 사용하는 사이트의 경우 LAN 측 포트 플래핑 후 SSH를 통해 대기 Edge의 VNF에 액세스할 수 없습니다.

  대기 VNF의 LAN 측 인터페이스는 일반적으로 비활성화 상태입니다. LAN 측 포트 플래핑으로 인해 전달 상태가 되며, 이로 인해 브리지 인터페이스에서 MAC 주소 포트 매핑이 잘못되어 VNF에 액세스할 수 없게 됩니다.

• 해결된 문제 60073: VMware SD-WAN Edge의 PPPoE 인터페이스를 통한 DNS 패킷은 처리되지 않습니다.

  Edge의 PPPoE 인터페이스를 통해 이동하는 경우 DNS 패킷은 처리 및 삭제되지 않습니다. 이로 인해 PPPoE를 통한 DNS 기능이 영향을 받고 고객은 릴리스 4.2.0 이상으로 업그레이드한 후 CSS 터널이 설정되지 않는 것과 같은 문제가 확인됩니다.

• 해결된 문제 60130: 사이트에서 높은 패킷 손실 및 연결 문제가 간헐적으로 발생할 수 있습니다.

  이 문제의 원인은 MAC 주소 00:00:00:00을 전달하는 동안 Edge에 디바이스에 대한 ARP 확인이 성공했음을 알리는 ARP 해결을 확인하기 API 때문에 발생했습니다.  이 주소는 ARP 캐시에 유지되어 MAC이 0으로 나열된 디바이스용 패킷이 모두 삭제됩니다. 이 문제에서는 MAC 주소가 0인 성공적인 ARP의 많은 인스턴스가 전달되어 높은 패킷 손실 및 연결 문제가 발생할 수 있습니다.

  이 수정 사항은 흐름에서 캐시된 MAC 주소 값 관련 문제(문제의 가장 일반적인 원인)는 해결하지만, ARP가 자체 캐시하여 0개의 MAC을 반환하는 드문 시나리오는 해결하지 않습니다. 이 문제는 62552에서 해결될 것입니다. 이 문제는 수정 사항이 적용된 Edge 이미지를 사용하는 것 외에 다른 해결 방법이 없습니다.

• 해결된 문제 60184: 분기 VMware SD-WAN Edge는 비프로필 허브 Edge(동적 분기 간)에서의 업링크 커뮤니티로 표시된 경로를 설치하고, 다른 모든 경로보다 이러한 경로를 선호합니다.

  비프로필 허브 Edge는 동적 분기 간(Dynamic Branch-to-Branch)을 사용할 때 분기 Edge로 취급됩니다.  따라서 동적 터널이 실행 중일 때 설명된 대로 문제가 발생합니다. 유일한 해결 방법은 모든 프로필에 허브를 추가하는 것이지만, 허브 Edge가 20개 이상 있는 대규모 네트워크에서는 생성될 경로 수가 너무 많으므로 확장할 수 없습니다.

• 해결된 문제 60225: VMware SD-WAN Edge에 대한 원격 진단 "인터페이스 상태"를 실행할 때 SFP 인터페이스에 대한 VMware SD-WAN Orchestrator의 출력에 잘못된 속도 및 이중 정보가 표시됩니다.

  Orchestrator의 데이터가 SFP 인터페이스에 대해 올바르지 않습니다. 예를 들어 Edge에서 데이터를 직접 본다면 0Mbps/반이중이 표시되겠지만 1000Mbps에서는 전이중 또는 유사한 방식으로 표시됩니다.

• 해결된 문제 60367: 상태 저장 방화벽 규칙은 VLAN별 삭제 규칙이 적용된 경우에도 VMware SD-WAN Edge IP로 이동하는 흐름에서 첫 번째 패킷을 삭제하지 않습니다.

  VLAN별 상태 저장 방화벽 삭제 규칙이 있어도 Edge의 VLAN IP로 ping을 전송하는 데 성공합니다. VLAN 특정 상태 저장 방화벽 삭제 규칙을 사용하면 Edge의 VLAN 호스트로의 ping과 VLAN IP로의 ping 간에 동작이 일관되지 않습니다. Edge의 VLAN IP로의 Ping은 성공적으로 수행됩니다. 이 버그 수정은 Edge VLAN-IP 또는 VLAN 호스트로의 ping을 허용하지 않습니다.

• 해결된 문제 60523: SLA 검색을 사용하도록 설정한 경우 라우팅된 클라이언트 IP 주소에 대한 ping이 실패합니다.

  라우팅된 클라이언트 IP 주소에 대해 SLA 검색을 사용하도록 설정한 경우 Edge 데이터부 서비스에서 ICMP 응답 패킷을 처리하지 못합니다.  이 수정 사항을 적용하지 않고 이 문제를 해결할 수 있는 유일한 방법은 ICMP 프로브를 비활성화하는 것입니다.

  이 수정 사항을 적용하지 않을 경우 유일한 해결 방법은 ICMP 프로브를 비활성화하는 것입니다.

• 해결된 문제 60570: VMware SD-WAN Orchestrator에서 새 UI를 사용할 때 경로 상태에 잘못된 상태가 표시될 수 있습니다. 

  이것은 표시 문제일 뿐이며 실제 고객 트래픽에는 영향을 주지 않습니다. 이 문제의 예로 Edge 진단 번들 로그가 경로를 안정적으로 표시할 때 경로를 비활성으로 표시하는 새로운 UI를 들 수 있습니다.

• 해결된 문제 61361: 소프트웨어 업데이트를 적용하여 VMware SD-WAN Edge 3400, 3800 및 3810을 Edge 릴리스 3.4.5, 4.0.2, 또는 4.2.1로 업그레이드하면 업데이트 이후 Edge 모델이 즉시 부팅되지는 않을 수도 있습니다.

  릴리스 3.4.5, 4.0.2 및 4.2.1에는 CPLD(복합 프로그래밍 가능 논리 디바이스)에 대한 특정 펌웨어 업데이트가 포함되어 있으며, 업데이트가 재부팅을 트리거하여 때에 따라 [중지(stuck)] 상태가 되면 수동 전원 주기로 시스템을 다시 시작해야 합니다.

  이 수정 사항을 적용하지 않을 경우 로컬 사용자는 업데이트를 완료하기 위해 Edge의 전원을 수동으로 껐다 켜야 합니다.

• 해결된 문제 61387: VMware SD-WAN Gateway에서 데이터부 서비스 오류가 발생하며, 사용자가 해당 게이트웨이에 대한 진단 번들을 생성하려고 하면 다시 시작될 수 있습니다.

  이 문제는 게이트웨이 메모리 누수로 인해 게이트웨이의 메모리 활용률이 높아질 수 있습니다.  게이트웨이의 메모리 사용량이 충분히 높은 경우 진단 번들을 생성하면 해당 메모리 사용량이 위험 상태로 전환되고 데이터부 서비스 장애가 트리거되고 다시 시작됩니다.

• 해결된 문제 61433: 하나의 VMware SD-WAN Edge가 허브 클러스터에 대한 스포크이고 다른 스포크에 대한 허브에도 해당하는 계단식 허브/스포크 토폴로지에서 허브 클러스터 멤버 중 하나에서 언더레이 라우팅이 변경되면 이 스포크/허브 Edge에서 경로가 삭제될 수 있습니다.

  계단식 허브 토폴로지의 경우 허브 클러스터 멤버의 경로를 제거할 경우 VMware SD-WAN Gateway에서 허브 Edge 역할도 하는 스포크 Edge로 전송되는 메시지가 의도치 않게 삭제되었습니다. 해당 메시지는 게이트웨이에서 무시되어야 하는 심층 스포크의 업데이트로 인한 것이지만 이 문제로 인해 게이트웨이가 스포크/허브 Edge에 삭제 메시지를 전송하여 Edge가 해당 언더레이 경로(허브 클러스터에서 학습된)를 손실할 수 있습니다.

  이 빌드의 수정 사항이 없으면 계단식 허브 토폴로지와 관련된 이 문제에 대한 해결 방법은 없습니다. Edge를 허브 클러스터에 대한 스포크이면서 심층 스포크에 대한 허브로 만들지 않는 것이 좋습니다. 이 경우 이 문제가 발생할 수 있습니다.

• 해결된 문제 61502: VMware SD-WAN Edge를 활성화하는 동안 적용할 새 소프트웨어 이미지의 다운로드가 무기한 지연됩니다.

  네트워크 연결이 불안정하거나 특정 유형의 트래픽 조절이 수행되는 환경에서 새 소프트웨어 이미지의 HTTPS 다운로드가 중단될 수 있습니다. 이 수정 사항을 적용하지 않은 상태에서 이 시나리오가 발생하면 Edge의 전원을 껐다 켜고 몇 분 정도 기다려 주십시오. 다운로드는 자동으로 다시 시작되지만 처음부터 다시 시작됩니다.

• 해결된 문제 61596: 파트너 BGP가 보안 옵션으로 사용하도록 설정되고 고정 경로가 비보안으로 구성되거나 그 반대로 구성될 경우 성능 저하가 발생합니다.

  이러한 성능 저하는 비보안 고정 경로가 BGP 구성에서 보안 플래그를 선택할 때 IP 주소의 최대 길이를 잘못 계산하기 때문에 발생합니다. 처음에는 VMware SD-WAN Gateway가 경로 조회를 수행하고, 비보안 고정 경로를 찾으면 게이트웨이는 BGP가 사용하도록 설정되었는지 여부를 확인합니다.  BGP가 사용하도록 설정되면 게이트웨이가 암호화 집합을 확인하고 보안 BGP에 대한 암호화 집합을 선택합니다. 그러면 조각화가 진행됩니다. 보안 옵션이 비보안 옵션보다 더 보수적이기 때문입니다.

• 해결된 문제 61622: Google Drive 트래픽이 "기타 TCP/UDP(Other TCP/UDP)" 또는 "APP_UNKNOWN"으로 잘못 식별됩니다.

  이 트래픽은 "Google Documents(즉, Google Drive)"로 알 수 있습니다. 이 문제는 Google Drive에 대한 최신 서브넷/포트가 없는 DPI(심층 패킷 검사) 엔진으로 인해 발생합니다.

• 해결된 문제 61725: USB WAN 링크가 사용되는 고가용성 토폴로지 사이트의 경우 원격 진단 "HA 정보(HA Info)"를 실행하면 오류가 발생합니다.

  USB/LTE 모뎀이 현재 또는 이전에 VMware SD-WAN 대기 Edge에는 없고 활성 Edge에만 있는 경우 활성 Edge가 대기 Edge에서 USB/LTE 인터페이스 세부 정보를 가져오려고 하면 대기 Edge에 USB/LTE 인터페이스가 없기 때문에 Edge에서 오류가 발생합니다.

• 해결된 문제 61758: VMware SD-WAN Edge 520 또는 540을 사용하는 사이트에서 고객은 예상보다 낮은 처리량을 확인할 수 있습니다.

  고객은 520 또는 540을 사용하는 사이트의 예상되는 처리량에서 100Mbps 이상이 삭제된 것을 확인할 수 있습니다. 이 문제는 이전 Edge 데이터부 상위 프로세스에 대한 하위 프로세스에서 오래된 링 버퍼를 열고 있기 때문에 새로 실행된 Edge 프로세스가 링 버퍼를 열지 못하기 때문에 발생합니다.

• 해결된 문제 62197: VMware SD-WAN Gateway가 데이터부 서비스를 다시 시작할 수 있습니다.

  게이트웨이 자체에서 VMware SD-WAN Orchestrator로 경로를 동기화하는 동안 메모리 누수 문제가 발생합니다.  메모리 사용량이 위험 수준에 도달하면 게이트웨이의 데이터부 서비스가 다시 시작되어 메모리를 지우고, 해당 게이트웨이를 사용하는 고객 트래픽이 잠시 중단됩니다.

• 해결된 문제 62280: VMware SD-WAN Edge의 LAN 하위 인터페이스가 라우팅된 호스트에서 Edge로 연결된 클라이언트로의 traceroute에 표시되지 않습니다.

  traceroute가 Edge에 직접 연결되지 않은 호스트에서 Edge 간 토폴로지의 클라이언트로 수행되면 Edge의 인터페이스 IP가 o/p에 표시되지 않습니다. 이 문제는 호스트 경로의 Edge 인터페이스에서 VMware SD-WAN Gateway 구성이 수행되지 않은 경우에만 발생합니다.
  
  이 수정 사항을 적용하지 않을 경우 유일한 해결 방법은 해당 traceroute 호스트에 연결하는 Edge 인터페이스에서 게이트웨이 구성을 사용하도록 설정하는 것입니다.

• 해결된 문제 62552: 사이트에서 높은 패킷 손실 및 연결 문제가 간헐적으로 발생할 수 있습니다.

  이 문제의 원인은 MAC 주소 00:00:00:00을 전달하는 동안 Edge에 디바이스에 대한 ARP 확인이 성공했음을 알리는 ARP 해결을 확인하기 API 때문에 발생했습니다.  이 주소는 ARP 캐시에 유지되어 MAC이 0으로 나열된 디바이스용 패킷이 모두 삭제됩니다.  이 문제에서는 MAC 주소가 0인 성공적인 ARP의 많은 인스턴스가 전달되어 높은 패킷 손실 및 연결 문제가 발생할 수 있습니다.

  참고: 60130 문제와 해당 문제는 기본 동작과 원인이 동일하지만 각 티켓의 예상 수정 사항이 다릅니다. 60150에는 방어적인 해결 방법이 수정 사항으로 포함되며 62552에는 해당 문제의 재발을 방지하는 완전한 수정 사항이 포함됩니다.

• 해결된 문제 62620: 고가용성 토폴로지를 사용하여 배포된 사이트에서 HA 페일오버 후 일부 대상으로의 직접 트래픽이 작동하지 않을 수 있습니다.

  활성 VMware SD-WAN Edge의 흐름은 NAT 항목에 대해 할당된 포트와 함께 대기 Edge와 동기화되므로 페일오버가 발생해도 페일오버 이후 트래픽이 중단되지 않습니다. 대기 Edge에 할당된 포트는 흐름이 만료된 이후에도 해제되지 않습니다. 따라서 페일오버가 발생하면 NAT 포트가 소진되어 NAT가 실패할 수 있습니다. 결과적으로 Edge에서 패킷이 삭제될 수 있습니다.

• 해결된 문제 62685: LAN 측 NAT가 NAT 유형이 소스인 다른 LAN 서브넷에 대해 동일한 외부 IP로 구성된 경우 클라우드로 전송되는 트래픽이 작동하지 않습니다.

  LAN 측 NAT 규칙에 사용되는 외부 IP의 경우 고정 경로를 구성하고 원격 분기에 애드버타이즈합니다. 반환 트래픽이 올바른 LAN 서브넷으로 라우팅되려면 고정 경로의 다음 홉 대신, LAN 측 NAT 규칙에 구성된 내부 IP를 기준으로 경로를 조회해야 합니다. 클라우드의 반환 트래픽을 제외하고는 고정 경로의 다음 홉을 기준으로 경로가 조회되고 트래픽이 잘못된 LAN 서브넷으로 라우팅될 수 있습니다.

• 해결된 문제 62815: 운영자 사용자는 Edge의 VMware SD-WAN 기본 게이트웨이를 통과하는 SSH를 통해 VMware SD-WAN Edge에 액세스할 수 없습니다. 

  SSH 세션이 시간 초과됩니다.  Edge에서 흐름을 살펴보면 흐름이 생성되지만 패킷 카운터에는 아웃바운드가 아닌 인바운드 패킷만 표시됩니다.

• 해결된 문제 62890: Edge Network Intelligence 및 VMware SD-WAN Orchestrator에서 통계를 볼 때 애플리케이션 ID가 서로 다릅니다.

  애플리케이션을 학습하는 방법에는 다음 두 가지가 있습니다.
  1. 첫 번째 패킷에서 잘 알려진 SaaS 애플리케이션 IP 주소 및 포트의 데이터베이스를 통하여(예: Office 365) 또는 Orchestrator가 이전에 학습한 애플리케이션의 IP를 학습하여.
  2. 일련의 패킷이 DPI(상세 패킷 검사)를 사용하여 분석된 후.

  Edge Network Intelligence 애플리케이션 ID가 #2로 업데이트되지 않았습니다. 즉, Office365와 같은 첫 번째 패킷 애플리케이션이 표시되지만 DPI가 필요한 애플리케이션(예: AnyDesk)은 Edge Network Intelligence가 아닌 Orchestrator에 표시됩니다.

• 해결된 문제 63056: VMware SD-WAN Edge에서 커널 패닉이 발생하고 재부팅 및 코어가 발생할 수 있습니다.

  뮤텍스 mon 프로세스가 SIGXCPU를 나타내며 실패하고 코어가 트리거됩니다. 모든 스레드가 두 코어를 사용하도록 허용하면 Edge 데이터부 서비스 < > frr 통신이 Unix 도메인 소켓으로 이동되므로 과도한 커널 오버헤드 없이 더 나은 성능으로 TCP 소켓의 모든 이점을 얻을 수 있습니다.

• 해결된 문제 63141: Metonia ADSL2+ SFP 모듈을 사용 중인 고급 고가용성 토폴로지를 사용하는 사이트의 경우, 페일오버 시 ADSL2+ SFP 모듈이 실행되지 않습니다.

  HA Edge가 페일오버되거나 네트워크가 다시 시작되면 ADSL2+ 구성을 사용하는 Edge가 실행되지 않습니다.

• 해결된 문제 63359: 고가용성 토폴로지 및 OSPF로 구성되고 VMware SD-WAN Edge가 MGMT IP Edge 빌드를 사용하는 사이트의 경우 이러한 Edge가 3.4.x에서 4.2.x MGMT-IP 빌드로 업그레이드되면 업그레이드 이후 OSPF 연결이 끊어질 수 있습니다. 

  HA Edge가 4.2.x MGMT IP 빌드로 업그레이드되면 HA 시스템이 해당 라우터 ID를 169.254.2.2로 정의할 수 있습니다. 이것은 라우터 ID의 Edge 선택이 HA 인터페이스의 IP 주소를 고려하지 않아야 한다고 가정할 때 예상되는 동작이 아닙니다. 해당 라우터 ID가 OSPF 연결을 끊으면 경로 교환이 더 이상 발생하지 않으므로 연결이 완전히 끊어집니다.

  이 수정 사항을 적용하지 않을 경우 유일한 해결 방법은 Edge 서비스를 다시 시작하여 HA 페일오버를 트리거하는 것입니다. 다시 시작하면 올바른 라우터 ID가 강제로 다시 선택됩니다.

• 해결된 문제 63362: 고급 고가용성 토폴로지가 사용하는 사이트에서 대기 Edge가 재부팅되거나 전원 주기가 진행된 후에 DHCP/PPPoE 지원 인터페이스가 트래픽 전송을 중지합니다.

  향상된 HA 토폴로지에서 DHCP/PPPoE가 프록시 인터페이스에서 사용하도록 설정되면(즉, HA 링크 상태가 USE_PEER로 설정되면) 대기 Edge가 재부팅되거나 전원 주기를 거친 후 서버에서 주소를 가져오지 못합니다.
  
  이 수정 사항을 적용하지 않을 경우 유일한 해결 방법은 동적 주소를 고정 주소 유형으로 변경하거나 강제 HA 페일오버를 수행하여 서버에서 IP 주소를 가져오는 것입니다.

• 해결된 문제 63513: Edge Network Intelligence를 사용하는 고객의 경우 Edge 소프트웨어 업그레이드 후에 VMware SD-WAN Edge에 대해 표시되는 소프트웨어 버전이 업데이트되지 않습니다.

  Edge는 실제로 최신 Edge Network Intelligence 버전으로 업그레이드되었지만 이전 버전 번호를 VMware SD-WAN Orchestrator에 전달하므로 고객에게 이전 버전 번호가 표시됩니다. Edge를 업그레이드한 후 고객에게 이 문제가 발생합니다. Edge를 이전 릴리스에서 최신 릴리스로 업그레이드한 후에도 고객에게 Edge Network Intelligence에 대한 이전 릴리스 버전이 계속 표시될 수 있습니다.

• 해결된 문제 64205: VMware SD-WAN Gateway에 대한 VCMP 데이터의 핸드오프 대기열 손실 개수가 많아질 수 있으며 이로 인해 사용자 환경이 저하될 수 있습니다.

  지속적인 흐름 생성 이벤트가 있는 경우 VCMP(VeloCloud 관리 프로토콜) 데이터 스레드의 패킷 처리 속도가 느려집니다. 이 버그 수정 사항은 VCMP 제어 메시지를 다른 스레드로 리디렉션하고 일부 연속 로그 메시지를 제거하여 VCMP 데이터 스레드 로드를 줄입니다.

• 해결된 문제 64633: 게이트웨이를 통한 비 SD-WAN 대상(NSD)를 사용하여 AWS 피어의 VMC(VMware Cloud)에 연결하는 고객의 경우 매번 30초 이내로 지속되는 간헐적인 트래픽 삭제를 확인할 수 있습니다.

  이 문제는 AWS의 VMC(VMware Cloud)에서만 확인됩니다. 피어는 SA(보안 연결)가 만료되기 30초 전에 IKE 키 재지정을 시작하고, 키를 재지정할 때마다 피어는 이전 SA를 유지하며 VMware SD-WAN Gateway가 인바운드 SA를 삭제하여 만료될 때까지 이전 SA를 사용합니다. 인바운드 SA를 삭제하면 이 피어와의 트래픽이 삭제됩니다. 이 문제가 발생하는 빈도는 피어의 키 재지정 정책에 따라 좌우됩니다. 피어가 45분마다 키를 재지정하면 이 문제가 45분마다 발생하고, 12시간마다 키를 재지정하면 이 문제가 12시간마다 발생하게 됩니다. 피어가 새 SA로 전환될 때 트래픽은 30초 정도 경과된 후에 자동으로 복구됩니다.

• 해결된 문제 64961: VMware SD-WAN Edge에서 데이터부 서비스 장애가 발생하고, 옵션이 포함된 IP 패킷을 처리하는 경우 해당 서비스를 다시 시작할 수 있습니다.

  옵션이 있는 IP 패킷을 처리하면 옵션 필드의 잘못된 구문 분석으로 인해 데이터부 서비스가 실패할 수 있습니다(구문 분석이 옵션 목록의 끝을 지나 계속됨). 데이터부 서비스 실패가 뮤텍스 mon에 의해 트리거됩니다. 이 수정 사항을 적용하지 않을 경우 이 문제의 위험을 최소화하는 유일한 방법은 사용자 트래픽 IP 패킷에서 RR(레코드 경로) 및 NOP(옵션 없음) 이외의 옵션을 설정하는 것입니다.

• 해결된 문제 65037: 인증서에 SSL 일반 이름 필드에 특수 문자 또는 공백이 있는 경우 손상된 인증서로 인해 HTTPS/SSL 연결이 설정되지 않을 수 있습니다.

  VMware SD-WAN Edge는 트래픽이 속하는 애플리케이션을 식별할 수 있도록 통과하는 모든 사용자 트래픽을 검사합니다. 이 기능은 비즈니스 정책을 올바르게 적용하고 VMware SD-WAN Orchestrator가 Edge의 [모니터링(Monitoring)] 페이지에 애플리케이션별 통계를 표시하는 데 필요합니다. 그러나 애플리케이션 식별 코드의 문제로 인해 SSL 일반 이름에 특수 문자나 공백이 포함되고 이로 인해 SSL 일반 이름이 손상되는 경우 SSL 일반 이름의 바이트가 덮어쓰입니다.

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

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

• 해결된 문제 65219: i40evf 드라이버를 사용하는 KVM SR-IOV 유형 VMware SD-WAN Gateway는 1500바이트 이상의 고객 패킷을 삭제합니다. 

  크기가 1496바이트 미만인 데이터는 삭제되지 않습니다. 사용자가 게이트웨이 호스트에 대해 SSH를 수행하려고 하면 설명된 조건에 따라 중단이 발생합니다.

• 해결된 문제 65293: 릴리스 4.x를 사용하면 AWS에 배포되어 Amazon의 ENA(Elastic Network Adapter) 드라이버로 실행되는 VMware SD-WAN Gateway의 처리량 성능이 저하됩니다.

  이 문제는 게이트웨이를 3.x에서 4.x 빌드로 업그레이드하거나 게이트웨이를 4.x 빌드를 사용하는 새 배포에서 업그레이드하는 경우 발생합니다. 게이트웨이 DPDK v19.11은 릴리스 4.0.0 이상을 사용하며, 게이트웨이 DPDK v19.02부터는 Amazon의 ENA 드라이버는 LLQ(낮은 지연 시간 대기열)를 사용합니다. 그러나 LLQ가 효율적으로 작동하려면 ENA 참조 가이드에 따라 메모리에 대한 쓰기-결합 설정을 사용 설정해야 합니다.  메모리 매핑이 쓰기-결합되지 않으면 AWS에 배포된 게이트웨이의 CPU 사용량이 많아져 처리량에 상당한 영향을 미칩니다. 이 문제의 수정 사항은 AWS에 배포된 게이트웨이의 ENA 어댑터에서 쓰기-결합을 사용하도록 설정하는 것입니다.

• 해결된 문제 65432: LAN 측에서 VMware SD-WAN Edge에 연결된 클라이언트에서 VMware SD-WAN Gateway를 통해 DC 서버로 이어지는 traceroute가 게이트웨이 IP를 traceroute 출력에 표시하지 않습니다.

  LAN 클라이언트에서 게이트웨이를 통해 연결할 수 있는 DC로의 traceroute를 시작하는 즉시, traceroute는 게이트웨이 IP를 제외한 모든 홉을 표시합니다.

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

  Edge 서비스를 다시 시작하면 5~10초 동안 고객 트래픽이 중단됩니다. VCMP(VeloCloud 관리 프로토콜) 터널 생성 핸드셰이크 중에 예기치 않은 제어 메시지를 처리하는 동안 Edge 데이터부 서비스가 실패합니다. 이 문제는 네트워크 토폴로지, 흐름 수 또는 처리량 때문이 아닙니다. 드물게 임의로 발생하지만, 어떤 유형의 고객 엔터프라이즈에서도 발생할 수 있습니다.

• 해결된 문제 65539: 고객이 VMware SD-WAN Edge를 릴리스 4.2.x로 업그레이드한 경우 서로 다른 두 분기의 두 디바이스 간에 설정된 BGP 세션이 실행되지 않습니다.

  고객이 Edge를 낮은 버전에서 릴리스 4.2.x로 업그레이드하면 VCMP 터널을 통해 설정된 서로 다른 분기의 두 LAN 디바이스 사이에서 나타나는 BGP 세션이 실행되지 않습니다.

• 해결된 문제 65839: VMware SD-WAN Hub Edge 뒤의 클라이언트에서 스포크 Edge 뒤의 LAN으로 시작되는 흐름에서 기본 경로가 파트너 게이트웨이에서 애드버타이즈될 경우 스포크의 반환 트래픽이 파트너 게이트웨이를 통해 라우팅됩니다.

  예상되는 동작은 허브 Edge에서 시작되는 흐름이 허브 Edge에서도 반환되는 것입니다. 허브 Edge에서 스포크 Edge로 애드버타이즈되는 기본 경로 또는 Edge 간 경로가 없는 경우 반환 트래픽에 대한 스포크 Edge의 경로 조회가 파트너 게이트웨이 기본 경로와 일치하고 반환 트래픽이 허브 Edge 대신 파트너 게이트웨이로 라우팅됩니다.
  
  이 수정 사항을 적용하지 않을 경우 이 문제를 방지할 수 있는 유일한 방법은 허브 Edge에서 스포크 Edge에 대해 기본 경로 또는 Edge 간 경로를 애드버타이즈하는 것입니다.

• 해결된 문제 65985: 동적 Edge 간을 사용하는 고객의 경우 네트워크의 VMware SD-WAN Edge가 모든 터널을 갑자기 삭제한 다음, 네트워크의 다른 사이트에 대한 터널을 구축하지 못할 수 있습니다.

  사이트가 모든 터널을 삭제하면 Edge의 최대 터널 값이 손상되고 최대 터널 수로 음수 값을 표시합니다. 이 손상된 값으로 인해 Edge가 다른 Edge에 대해 새로운 동적 Edge 간 터널을 형성하지 못하게 됩니다. Edge가 네트워크의 다른 사이트와 통신할 수 없으므로 이로 인해 미치는 영향은 심각합니다.

  이 수정 사항을 적용하지 않을 경우 이 문제를 해결하는 유일한 방법은 HA 사이트에 대해 Edge 서비스 다시 시작 또는 HA 페일오버를 수행하는 것입니다.

• 해결된 문제 66355: 상태 저장 방화벽이 사용되도록 설정되고 하나 이상의 LAN 측 NAT(다대일) 규칙이 구성된 고객의 경우 VLAN 간 흐름이 작동하지 않습니다.

  다대일 LAN 측 NAT 규칙을 사용하면 TCP 상태가 VLAN 간 트래픽에 대해 제대로 유지되지 않으며 상태 저장 방화벽도 사용하도록 설정되면 패킷이 삭제됩니다.

• 해결된 문제 66366: 많은 수의 인접 항목이 있는 멀티캐스트를 사용하는 고객의 경우 VMware SD-WAN Edge에서 데이터부 서비스 장애가 발생하고 다시 시작되면서 고객 트래픽이 잠시 중단됩니다.

  PIM 인접 항목이 1600 이하일 때 "많은 수의 인접 항목"으로 인식됩니다. 이 문제가 발생하는 경우 허브 Edge 뒤에서 그룹에 대해 1600개 스포크 Edge에서 하나의 수신기로의 트래픽이 실행되는 동안 PIM 서비스가 실패하고 이로 인해 Edge 서비스도 실패한 후 다시 시작됩니다.

• 해결된 문제 66676: 비즈니스 정책 NAT가 구성되면 VMware SD-WAN Gateway의 반환 트래픽이 원래 소스 IP로 다시 NAT되지 않을 수 있습니다.

  코드에서 NAT 항목이 삽입되는 동안 이전 항목을 삭제해야 합니다. 그러나 해시 테이블 조회에 일부 키가 사용되지 않기 때문에 일부 인스턴스에서 이전 항목이 삭제되지 않게 되고 이로 인해 NAT 항목 삽입 오류가 발생했습니다.

• 해결된 문제 66714: 사용자가 VMware SD-WAN Edge에서 DCHP 옵션 150에 대해 호스트 이름을 사용할 수 없습니다.

  사용자가 DHCP 옵션 150에 대한 호스트 이름을 구성하는 경우 DHCP 클라이언트가 있는 Edge에서 IPv4 주소를 가져오려고 하면 Edge 로그에 호스트 이름을 잘못된 IP 주소로 나타내는 dnsmasq 오류 메시지가 표시되며, DHCP 클라이언트는 Edge의 DHCP 서비스에서 IP 주소를 가져오지 않습니다.  RFC 5859는 호스트 이름 대신 IPv4 주소를 사용하도록 설계되었지만 현재 다른 네트워킹 디바이스는 옵션 150에 대해 호스트 이름을 사용하도록 허용합니다. 따라서 다른 디바이스에서 호스트 이름을 사용하는 고객은 Edge의 DHCP 서비스가 중단되지 않도록 Edge 디바이스를 수용해야 합니다.

• 해결된 문제 66801: 고가용성 토폴로지 및 VNF를 사용하는 고객 사이트의 경우 고객이 VNF에 연결하지 못하여 관리 서버에서 신뢰 설정을 수행하지 못할 수 있습니다.

  라우팅된 인터페이스가 DHCP를 사용하도록 설정되어 있고 커널 경로 테이블에 기본 경로가 없는 경우 HA 사이트에서 이 문제가 발생합니다. 이 경우 커널은 "ICMP 대상에 연결할 수 없음(ICMP destination unreachable)"으로 응답합니다.

  이 수정 사항을 적용하지 않을 경우 이 문제를 방지하는 방법은 Edge가 "ICMP에 연결할 수 없음(ICMP Unreachable)"을 VNF VM으로 다시 전송하여 SSH 연결이 재설정되지 않도록 하고, 대기 Edge에 기본 경로를 추가하는 것입니다.

• 해결된 문제 67060: VMware SD-WAN Edge가 높은 메모리 활용률을 나타내며, 활용률이 충분히 높은 경우 Edge 서비스가 다시 시작될 수 있습니다.

  이 문제는 메모리가 누수되어 서비스가 느려지고 메모리 활용률이 계속 높아지기 때문에 발생합니다. 이 문제는 단일 흐름에 대해 여러 HTTP 요청 패킷이 전송되는 경우에 나타나며, 특히 Edge가 HTTP 요청 패킷을 구문 분석하는 동안 메모리 누수 문제가 발생합니다.

• 해결된 문제 67083: VMware SD-WAN Edge에서 데이터부 서비스 장애가 발생하고 서비스가 다시 시작되어 결과적으로 고객 트래픽이 잠시 중단될 수 있습니다.

  일부 시나리오에서 VCMP(VeloCloud 관리 프로토콜) 데이터 패킷이 잘못된 매개 변수로 처리되어(예: 데이터 패킷이 제어 패킷으로 잘못 분류됨) 예외가 트리거되고 서비스가 다시 시작됩니다.  

• 해결된 문제 67173: 여러 IBGP 인접 항목에서 동일한 경로가 학습되면 BGP 프로세스에서 선택된 두 번째 최적의 경로가 VMware SD-WAN Edge에서 사용되어 특정 고객 트래픽이 블랙홀 상태가 됩니다.

  FRR(Free Range Routing) 집합의 문제로 인해 IBGP는 Edge에 여러 개의 다음 홉을 전송하고, 두 번째 최적 경로(다음 홉 순서의 마지막)을 선택하여 FIB(전달 정보 기반)를 업데이트했습니다. 이 버그 수정에는 최상의 다음 홉만 Edge로 전송하는 BGP 프로세스의 명령이 포함되어 있습니다.

• 해결된 문제 67197: 고객 네트워크에서 멀티캐스트 그룹과 연결된 소스가 1,500개가 넘는 배포의 경우 멀티캐스트 서비스가 주기적으로 중단될 수 있습니다.

  멀티캐스트 그룹과 연결된 소스가 1,500개가 넘는 배포에서 연결 제거 업데이트를 처리할 때 소프트웨어 문제로 인해 예외 메시지와 함께 PIM 스택의 연결 제거 메시지 처리 논리가 실패합니다.

  이 수정 사항을 적용하지 않을 경우 이 문제를 방지할 수 있는 유일한 방법은 멀티캐스트 소스의 총수를 1,000개로 제한하는 것입니다.

• 해결된 문제 67259: PIM 프로세스가 여러 번 다시 시작되었을 때 멀티캐스트 트래픽 흐름이 중단되고 PIM 인접 항목이 나타나지 않습니다.

  1600개의 PIM 인접 항목이 있는 확장 설정에서 트래픽이 700개의 스포크 Edge에서 허브 Edge 뒤의 수신기로 실행되는 동안 PIM 프로세스를 여러 번 다시 시작할 경우, 한 번 다시 시작된 후 1600개의 PIM 인접 항목 중 570개 이상의 PIM 인접 항목만 나타났습니다. 이 문제를 해결하는 유일한 방법은 Edge 서비스를 다시 시작하는 것입니다.

• 해결된 문제 67790: BGP나 OSPF를 사용하고 인바운드 필터를 구성하여 특정 경로를 무시하는 고객 엔터프라이즈가 해당 엔터프라이즈에 DCC(동적 비용 계산)를 사용하도록 설정할 경우, 엔터프라이즈에 인바운드 필터가 더 이상 적용되지 않으며 트래픽이 해당 경로 사용을 시도합니다.

  DCC를 사용하도록 설정하기 전에는 BGP/OSPF 인바운드 필터에서 무시(IGNORE)로 설정된 경로가 FIB(전달 정보 기반)에 포함되지 않습니다.  이제 DCC를 사용하도록 설정하면 FIB에 이러한 경로가 포함되며, 트래픽이 해당 경로를 사용하려고 시도하여 고객 엔터프라이즈에 심각한 트래픽 중단을 유발할 가능성이 있습니다.

  이 수정 사항을 적용하지 않을 경우 유일한 해결 방법은 인바운드 필터가 제대로 적용되도록 OSPF/BGP를 다시 시작하는 것입니다.

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

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

• 해결된 문제 68994: VMware SD-WAN Gateway를 사용하여 VMware SD-WAN Edge에서 NSD(비 SD-WAN 대상) 터널을 배포하는 고객은 터널 플래핑을 확인할 수 있습니다.

  이 문제는 터널 설정 또는 IKE 키 재생성에서 확인됩니다. Edge 또는 게이트웨이가 IKESAID=0에 따라 SA(보안 연결)를 삭제하여 터널 플래핑이 발생됩니다. 터널이 자동으로 안정화되지만 이 작업을 수행하는 데 필요한 시간이 일관되지 않아서 고객 트래픽이 NSD에 더 영향을 미칠 수 있습니다.

• 해결된 문제 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 오류가 발생합니다.

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

  ERROR [oids (10028:MainThread:10028)] [VCE.Path]<update>: Path failed update buffer: KeyError('HOTSTANDBY_IDLE',)
  INFO  [oids (10028:MainThread:10028)] [VCE]<update_if_stale>: Current MIB buffer size: 217
  DEBUG [oids (10028:MainThread:10028)] [VCE.Link]<ip2octet>: Failed to convert IP to Octet for caller <class 'vcsnmp.oids.Link'>[publicIpAddress] on []: ValueError("invalid literal for int() with base 10: ''",), used default value[00 00 00 00] instead
  

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

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

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

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

• 해결된 문제 70310: 여러 세그먼트를 사용하는 고객의 경우 하나 이상의 세그먼트를 삭제하거나 비활성화하면 VMware SD-WAN Edge에서 데이터부 서비스 장애가 발생하고 해당 서비스를 다시 시작하면 고객 트래픽이 잠시 중단될 수 있습니다. 

  세그먼트가 삭제되어도 Edge는 이 삭제된 세그먼트와 연결된 메모리를 완전히 정리하지는 않습니다. 활성 Edge가 이러한 세그먼트를 참조하여 대기 Edge와 이벤트를 동기화하는 시나리오가 있습니다. 이 경우 이러한 세그먼트가 존재하지 않으므로 대기 Edge에서 서비스 장애가 발생합니다.

• 해결된 문제 70789: IPSec 재생 방지 감지로 인해 트래픽이 임의로 삭제될 수 있습니다.

  VMware SD-WAN Edge 또는 VMware SD-WAN Gateway가 캐시 항목 시퀀스 번호를 업데이트하는 두 개의 패킷을 수신하는 경우 첫 번째 패킷이 재생 창을 잘못 업데이트하여 IPsec 재생 방지 감지를 트리거함으로써 IPsec 패킷이 삭제될 수 있습니다.

Orchestrator의 해결된 문제

Orchestrator 빌드 R422-20220715-GA에서 해결됨

Orchestrator 빌드 R422-20220715-GA는 2022년 8월 10일에 릴리스되었으며 세 번째 릴리스 4.2.2용 Orchestrator 롤업입니다.

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

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

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

  이 수정 사항을 적용하지 않은 Orchestrator에서는 운영자가 cloud-init user-data ISO 파일을 사용하여 시스템을 배포하면 문제를 해결할 수 있습니다.

  참고: 이 항목은 Orchestrator OVA만 추적합니다. 이 문제의 게이트웨이 측은 빌드 R422-20220518-GA 이상으로 해결되었습니다.

• 해결된 문제 85883: VMware SD-WAN Edge가 기본 활성 WAN 링크와 VMware SD-WAN Orchestrator의 백업 WAN 링크를 사용하도록 미리 구성된 경우 백업으로 지정된 WAN 링크를 사용하여 Edge를 활성화하면 기본 WAN 링크가 연결된 후에도 Orchestrator가 이 링크 상태를 활성으로 계속 표시합니다.

  백업으로 구성된 WAN 링크가 구성된 상태로 사용되고 있기 때문에 이 문제는 표면적인 문제입니다. 즉, 기본 WAN 링크가 Edge에 연결된 후 백업 WAN 링크의 관리 터널이 해체되고 트래픽이 전달되지 않습니다. 이 문제는 Orchestrator가 WAN 링크의 실제 상태에 대해 사용자가 혼동할 수 있는 모니터링(Monitor) > Edge > 개요(Overview) 페이지에 WAN 링크의 백업 상태를 정확하게 표시하지 않는 것입니다.

___________________________________________________________________

Orchestrator 빌드 R422-20220112-GA

Orchestrator 빌드 R422-20220112-GA는 2022년 1월 21일에 릴리스되었으며 두 번째 릴리스 4.2.2용 Orchestrator 롤업 빌드입니다.

이 Orchestrator 빌드는 Log4j 버전 2.17.0으로 업데이트하여 Apache Log4j 취약성 CVE-2021-44228(Log4j 버전 2.16.0을 사용하는 Orchestrator 빌드 R422-20211216-GA에서 처음 처리됨)과 CVE-2021-45046에 업데이트를 적용합니다. Apache Log4j 취약성 및 VMware 제품에 미치는 영향에 대한 업데이트된 정보는 VMware 보안 권고 VMSA-2021-0028.9를 참조하십시오.

___________________________________________________________________

Orchestrator 빌드 R422-20211216-GA

Orchestrator 빌드 R422-20211216-GA는 2021년 12월 20일에 릴리스되었으며 첫 번째 릴리스 4.2.2용 Orchestrator 롤업 빌드입니다.

이 Orchestrator 빌드는 Log4j 버전 2.16.0으로 업데이트하여 CVE-2021-44228, Apache Log4j 취약점에 업데이트를 적용합니다. Apache Log4j 취약점에 대한 자세한 내용은 VMware Security Advisory  VMSA-2021-0028.5를 참조하십시오.

___________________________________________________________________

버전 R422-20210920-GA에서 해결됨

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

• 해결된 문제 20900: MaxMind 지리적 위치 서비스가 사용하도록 설정되고 MaxMind 서버에 연결할 수 없으면 새로운 VMware SD-WAN Edge 활성화가 작동하지 않습니다.

  Edge는 활성화하기 위해 VMware SD-WAN Orchestrator에 대한 HTTPS 연결을 생성합니다. 요청의 기본 시간 초과는 120초이고 프록시된 연결의 경우 60초입니다. Orchestrator가 Edge(IPv4 원격 주소)의 지리적 위치를 지정하려고 하면 활성화를 진행하기 위해 업로드가 MaxMind 서비스의 응답을 기다립니다. 따라서 60초 후에 NGINX가 업로드 서비스의 응답을 위해 중지된 후 연결을 닫습니다. 따라서 NGINX에서 504 시간 초과가 발생하므로 활성화가 실패합니다. 

  새 시스템 속성인 service.maxmind.timeout.seconds를 사용하는 경우 사용자 지정 시간 초과를 사용하여 Maxmind API 호출이 수행됩니다. 이 시간 초과에 도달하면 호출이 수행되면서 활성화 워크플로로 진행되고 Edge가 성공적으로 활성화됩니다.

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

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

• 해결된 문제 48706: Syslog 구성 아래에서 소스 인터페이스가 선택된 경우 구성(Configure) > Edge > 디바이스(Device) 탭에서 변경 내용을 저장하지 못할 수 있습니다.

  VMware SD-WAN Orchestrator에 표시되는 오류는 "제공된 소스 인터페이스가 세그먼트 <세그먼트 이름>의 세그먼트에 없습니다."(Provided source interface is not present in the segment on segment: <Segment Name>)입니다. 이 오류는 세그먼트 순서가 더 이상 순차적이지 않은 방식으로 여러 세그먼트를 생성 및 삭제하기 때문에 발생합니다.

• 해결된 문제 48791: Edge에 Edge 재정의(Edge Override)를 사용하여 구성된 인터페이스가 있는 경우 사용자는 프로필 간에 VMware SD-WAN Edge를 전환할 수 없습니다.

  예를 들어 고객이 두 개의 구성 프로필인 프로필 1 및 프로필 2를 사용하고 Edge를 프로필 1과 연결하는 경우를 가정합니다.  사용자가 Edge 재정의(Edge Override)를 사용하여 GE2를 라우팅되도록 구성하고 GE2에 대해 고정 경로를 추가하는 경우, 나중에 동일한 Edge를 프로필 2에 할당하려고 하면 라우팅된 GE2가 프로필 2에 없다는 오류가 표시됩니다. 이 문제는 사용자가 프로필에 속하는 Edge 재정의(Edge Override)를 사용하여 Edge 인터페이스를 구성할 때 Orchestrator가 Edge 재정의(Edge Override) 존재 여부를 검증하지 않으므로 VMware SD-WAN Orchestrator를 전환할 수 없기 때문에 발생합니다.

• 해결된 문제 52379: VMware SD-WAN Edge가 구성된 지연 간격 내에 복구되면 VMware SD-WAN Orchestrator는 'Edge 종료(Edge Down)' 경고 이메일을 전송합니다.

  관리자는 Edge가 해당 경고를 트리거하기 전에 특정 기간 동안 Edge 종료를 허용하도록 지연을 구성한 경우에도 네트워크에서 Edge가 종료된다는 잘못된 경고를 수신할 수 있습니다.

• 해결된 문제 52863: VMware SD-WAN Orchestrator UI는 비표준 BGP 타이머 구성을 허용하며 오류를 발생시키지 않습니다.

  고객 구성 페이지에서 파트너 전달 구성을 사용하도록 설정한 상태에서 사용자가 RFC 4271의 BGP 표준을 준수하지 않는 BGP 유지/보류 타이머를 Orchestrator에서 구성해도 Orchestrator는 구성을 저장하도록 허용합니다. 그러나 VMware SD-WAN Edge 자체에서 FRR는 표준을 준수하도록 유지/보류 값을 변경합니다. 예를 들어, 사용자가 Orchestrator에서 2초 유지/5초 보류를 구성할 경우 Edge FRR은 3x 유지 = (보류보다 작거나 같음)이 되도록 유지 값을 1초로 변경합니다.

• 해결된 문제 53525: VMware SD-WAN Orchestrator에서 새 UI를 사용하고 Edge 개요(Edge overview) 페이지를 보는 경우 링크(Links) 열에 링크의 상태(예: 백업(Backup), 대기(Standby))가 표시되지 않습니다.

  이 링크 상태 정보는 이전 UI에는 올바르게 표시되며 이 수정 사항을 적용하면 새 UI에서도 예상대로 표시됩니다.

• 해결된 문제 53652: 사용자 지정 애플리케이션 맵을 사용하는 고객 엔터프라이즈가 3.x에서 4.x로 업그레이드되면 업그레이드 전에 생성된 사용자 지정 애플리케이션에 대해 무작위 이름이 표시될 수 있습니다.

  기본 초기 애플리케이션 맵의 일부로 이미 존재하는 애플리케이션 ID(appId)로 사용자 지정 애플리케이션 맵을 구성할 때마다 VMware SD-WAN Orchestrator에는 항상 기본 초기 애플리케이션 맵의 표시 이름이 표시되고 고객이 정의한 이름이 재정의됩니다. 또한 Orchestrator를 하위 버전에서 상위 버전으로 업그레이드하고 상위 버전의 기본 초기 애플리케이션 맵 appid가 하위 버전에서 생성된 사용자 지정 애플리케이션의 appId와 충돌하는 경우도 마찬가지입니다.  Orchestrator 업그레이드 후 이러한 사용자 지정 애플리케이션에 상위 버전의 기본 초기 애플리케이션 맵 appid의 표시 이름에 해당하는 잘못된 표시 이름이 표시됩니다.

• 해결된 문제 53857: 릴리스 4.0.0을 기준으로 하는 KVM 이미지를 사용하는 VMware SD-WAN Orchestrator 배포는 실패합니다.

  실패 이유는 KVM 이미지에 잘못된 가상 디스크 크기가 있으며 볼륨이 필요한 크기로 확장되지 못하기 때문입니다.  배포에서 Orchestrator 스크립트는 Orchestrator 볼륨을 자동으로 확장하여 기본 디스크(물리적 볼륨)의 최대 크기의 80%를 차지하게 합니다.  이 경우 잘못된 가상 크기 때문에 이러한 확장은 Orchestrator 데이터베이스 요구 사항에 부적절하고 배포는 실패합니다.  이 버그 수정 없이 이전 빌드를 사용하여 Orchestrator를 배포할 수 있지만 볼륨을 수동으로 조정해야 합니다.

• 해결된 문제 53919: VMware SD-WAN Orchestrator UI에서 1시간과 같은 짧은 시간 범위에 대한 기간별 데이터(>2주)를 보는 경우 데이터가 있더라도 데이터가 반환되지 않으며 더 긴 시간 범위를 사용하는 경우 해당 데이터를 볼 수 있습니다.

  긴 시간 범위(예: 최근 31일)의 Edge 통계를 쿼리할 때 전체 시간 범위에 대한 데이터가 표시됩니다. 그러나 기간별 데이터를 확대하고 짧은 시간 범위를 쿼리하는 경우 이제 사용 가능한 데이터가 없음으로 표시됩니다.

• 해결된 문제 54546: VMware SD-WAN Orchestrator UI가 [모니터링(Monitor)] > [Edge(Edges)] 페이지에 [Edge] 터널을 통해 클라우드 보안 서비스 또는 Edge를 통한 비 SD-WAN 터널을 올바르게 표시하지 않습니다.

  이 문제는 CSS 또는 Edge를 통한 NSD 터널에 대해 USB 인터페이스를 통해 WAN 링크를 사용하는 VMware SD-WAN Edge가 여러 개 있을 때 발생할 수 있습니다. Orchestrator가 시간별로 터널 이벤트를 정렬하고 'datakey'당 최신 이벤트를 사용하여 유효 상태를 확인합니다. 키 값이 많은 항목에 대해 동일하기 때문에 일부 터널이 제외되었습니다. 이 문제는 잘못된 상태를 표시할 뿐이며 고객에게는 영향을 미치지 않습니다.

• 해결된 문제 55871: REST APIv2(/sdwan) HTTP에 대한 일부 API 호출로 인해 서버가 HTTP 500 오류를 생성합니다.

  고객 데이터가 API에서 예상하는 스키마를 정확하게 준수하지 않는 경우 API는 문서화된 API 스키마와 불일치하는 데이터를 반환하는 대신 HTTP 500 오류를 생성합니다. 이 동작은 이후에 다시 진행된 디자인 결정을 따른 것입니다. "GET /enterprises", "GET /enterprises/{enterpriseLogicalId}/edges" 및 "GET /enterprises/{enterpriseLogicalId}/clientDevices" 호출이 영향을 받는 것으로 알려져 있습니다.

• 해결된 문제 57046: VMware SD-WAN Orchestrator에서 고객을 생성할 때 운영자 액세스가 허용되지 않습니다. 그러나 Orchestrator가 4.0.x 릴리스로 업그레이드될 때 운영자 액세스를 확인하지 않고 시스템 패치에 의해 MODIFY_ENTERPRISE_CUSTOM_ROLES 및 VIEW_PATH_STATS 권한이 추가됩니다.

  예를 들어, 고객 설정은 운영자에게 위임된 사용 권한을 표시하지만 운영자에게는 네트워크 서비스 읽기 또는 Edge/프로필 수정 권한이 없습니다. 따라서 해당 고객의 엔터프라이즈에서 운영자가 수행할 수 있는 작업에 대해 잘못된 상태가 표시됩니다.

• 해결된 문제 57163: 고객이 CSS(클라우드 보안 서비스) 또는 Edge를 통한 비 SD-WAN 대상(NSD) 터널 경고에 대해 SNMP 트랩을 통한 알림을 수신할 수 없습니다.

  이 문제는 고객이 SNMP 트랩을 사용하여 CSS/Edge를 통한 NSD 터널 경고를 수신하려고 하지만 해당 이벤트에 대해 SNMP 트랩이 트리거되지 않는 경우에 발생합니다.

• 해결된 문제 58127: 사용자는 엔터프라이즈 보고와 관련된 몇 가지 문제를 확인할 수 있습니다.

  이러한 문제에는 표시되지 않아야 하는 보고서의 ID 필드, 생성된 보고서의 사용자 이름 누락, 50개의 보고서 제한 등이 포함됩니다.  이 티켓은 처음 두 문제를 해결합니다.  50개의 보고서 제한은 Orchestrator 성능 문제를 방지하기 위해 설계된 시스템 속성 구성입니다. Orchestrator 관리자가 보고서 한도를 늘릴 수 있지만 Orchestrator의 성능이 저하될 수 있습니다.

• 해결된 문제 58627: 경고를 수신하도록 구성된 사용자는 링크가 실제로 종료된 상태로 유지될 때 연결 경고(Link Up Alert)를 수신할 수 있습니다.

  경우에 따라 링크가 '종료(Down)'로 표시된 후 링크가 종료되기 전에 생성된 해당 링크에 대한 통계가 이벤트 후 최대 1분 동안 VMware SD-WAN Orchestrator로 전송되지 않을 수 있습니다.  Orchestrator가 이러한 지연 링크 통계를 수신하면 링크가 백업되는 것으로 착각하게 되므로 경고 설정이 적극적이면(예: 0분 지연) 연결(Link Up) 경고가 트리거됩니다.  이 수정 사항을 적용하면 Orchestrator는 링크 통계 지연을 링크가 현재 실행 중임을 의미하는 것으로 해석하지 않게 됩니다.

• 해결된 문제 59094: 작업자가 VMware SD-WAN Orchestrator를 업그레이드하려고 하면 업데이트 스크립트는 스키마 업데이트 요구 사항에 대한 적절한 경고 메시지를 제공하지 않습니다.

  작업자가 더 큰 테이블에 스키마 변경 사항을 적용하는 단계를 누락하면 Orchestrator 서비스에 오류가 발생할 수 있습니다.  또한 누락된 변경 사항을 쉽게 확인할 수 있는 방법이 없습니다. 이 버그 수정 사항은 백엔드 서비스가 다시 시작될 때 큰 테이블에 필요한 누락된 스키마 변경 내용을 재생성할 때 이 문제를 해결합니다.

• 해결된 문제 59689: 비정상적으로 많은 수의 엔터프라이즈 및 Edge가 있는 VMware SD-WAN Orchestrator에서 새 UI를 사용하는 경우 [모니터링(Monitor)] > [방화벽 로그(Firewall Logs)] 페이지가 느리게 로드되거나 응답을 완전히 중지할 수 있습니다.

  이 문제는 200개 이상의 고객 엔터프라이즈 및 수천 개의 Edge가 있는 호스팅된 Orchestrator에서 나타났습니다.

• 해결된 문제 60502: VMware SD-WAN Edge에서 학습된 BGP 경로가 "OFC 제한에 도달함(OFC cap reached)" 메시지를 표시하면서 VMware SD-WAN Orchestrator 및 VMware SD-WAN Gateway로 푸시되지 않을 수 있습니다.

  이 문제는 Edge가 2000개 이상의 경로를 처리하는 경우에 발생합니다. 이 경우 Edge는 라우팅 API에 2000개 경로 배치를 전송하고 이 업로드는 해당 배치를 처리하는 데 약 300초가 걸립니다.  그러나 NGINX는 60초의 시간 초과 후 호출을 거부하고, Edge는 거부를 수신하고 동일한 2000개 경로를 사용하여 라우팅 API를 다시 호출합니다. 업로드가 경로를 다시 처리하지만 NGINX는 시간 초과로 인해 해당 호출을 거부하고 이 루프는 계속 진행됩니다. 또한 Orchestrator는 동일한 배치를 반복해서 처리하고 경로를 절대 학습하지 않습니다.

• 해결된 문제 60608: VMware SD-WAN Edge 디바이스 설정의 "고정 경로 설정(Static Route Settings)" 섹션에서 인터페이스를 선택하는 드롭다운을 사용할 수 없습니다.

  사용자가 VMware SD-WAN Orchestrator UI의 Edge에 고정 경로를 추가하려고 하면 다음 홉의 IP 주소에 관계없이 인터페이스가 "적용되지 않음" 상태를 유지합니다.

• 해결된 문제 61000: VMware SD-WAN Orchestrator UI의 [파트너 개요(Partner Overview)] 페이지에서 새로 생성한 운영자 프로필을 선택할 수 없습니다.

  Orchestrator에 100개 이상의 운영자 프로필이 있을 때 사용자가 [파트너 개요(Partner Overview)] 페이지에서 일부 프로필을 선택하려고 하면 UI에 100개의 프로필만 표시됩니다. 이 수정 사항을 적용하지 않을 경우 이 문제를 해결하는 유일한 방법은 VMware SD-WAN 기술 지원 서비스에서 요청된 운영자 프로필을 할당하도록 하는 것입니다.

• 해결된 문제 61312: VMware SD-WAN Orchestrator는 경로가 더 이상 업데이트되지 않고 Orchestrator의 CPU 사용률이 100%에 가까워질 때 문제가 발생할 수 있습니다. 이 문제는 Orchestrator가 업그레이드된 후에 특히 두드러집니다.

  이 문제는 Edge가 Orchestrator의 라우팅 API에 2K 이상의 경로 업데이트를 보낼 때 확인됩니다. Orchestrator가 60초 이내에 특정 API 호출을 통해 전송된 경로 집합 전체를 처리하지 못하는 시나리오에서는 해당 호출에 대한 시간이 초과되어 API 호출이 완전히 거부됩니다. Edge는 이러한 거부를 수신하면 동일한 2K 이상의 경로를 Orchestrator에 다시 푸시하려고 시도하므로 Orchestrator의 vCPU 리소스를 오버로드하는 루프를 생성하게 되는 이전과 동일한 시나리오를 발생합니다. 이 문제가 있는 경우 경로 업데이트가 처리되지 못할 수 있습니다. 

  이 문제를 해결하기 위해 다음 두 개의 시스템 속성이 추가되었습니다.

  edge.learnedRoute.maxRoutePerCall 이 속성은 Edge에서 제한된 수의 경로만 처리하도록 보장합니다. 속성값이 '200'이면 Edge 요청당 200개 경로가 처리됩니다. 그러면 제시간에 Edge로 승인이 전송됩니다.

  vco.learnedRoute.simultaneous.maxQueue 이 속성은 구성된 수의 Edge만 한 번에 경로 요청을 대기할 수 있도록 합니다. 이 속성값이 '8'이면 한 번에 8개의 Edge만 경로 요청을 보낼 수 있으며, 구성된 값을 초과하는 Edge는 경로가 처리되기 전에 즉시 거부됩니다.

• 해결된 문제 61625: OSPF에서 애드버타이즈될 경로가 250개보다 많은 경우 VMware SD-WAN Hub Edge가 모든 경로를 애드버타이즈하지는 않습니다.

  경로 수가 300개이든 2,000개 이상이든 관계없이 250개 이하의 경로만 애드버타이즈됨으로 표시되고 나머지는 애드버타이즈 플래그가 FALSE로 설정됩니다. 이 문제는 최대 250개 크기를 초과하는 경로를 처리할 때 처리가 지연되기 때문에 발생하며 요청당 훨씬 더 작은 경로 배치를 처리하는 방식으로 해결되었습니다.

• 해결된 문제 61852: 새 UI의 [모니터링(Monitor)] > [방화벽 로그(Firewall Logs)] 페이지에 올바른 페이지 매기기 정보가 표시되지 않습니다.

  이 섹션에 대한 페이지 행 수가 잘못되었습니다.

• 해결된 문제 62145: VMware SD-WAN Orchestrator가 하위 릴리스에서 4.2.1로 업그레이드되면 마이그레이션이 실패하고 고유한 제약 조건 중단 오류가 발생합니다. 클라이언트 디바이스 테이블의 'logicalId' 필드에 있습니다.

  릴리스 4.2.1에는 마이그레이션 시 실행되는 장기 실행 작업이 있으며, 클라이언트 디바이스 테이블에 'logicalId'가 추가됩니다. 이 작업은 전제 조건 쿼리에 따라서만 수행됩니다. 이 전제 조건 쿼리가 잘못되어 logicalId 필드가 비어 있습니다. logicalId 필드에 제약 조건을 추가하면 둘 이상의 행에서 logicalId가 빈 문자열로 구성되었기 때문에 중복 오류가 발생했습니다.

  이 수정 사항을 적용하지 않을 경우 이 문제를 해결하는 유일한 해결 방법은 마이그레이션 중에 클라이언트 디바이스 테이블의 모든 행에 고유한 logicalId를 추가하는 보류 중인 장기 실행 쿼리를 수동으로 실행한 다음, 고유한 제약 조건 쿼리를 실행하는 것입니다.

• 해결된 문제 62624: 사용자가 VMware SD-WAN Orchestrator UI의 [게이트웨이(Gateways)] > [개요(Overview)] 페이지에서 [파트너 게이트웨이(Partner Gateway)] 확인란을 선택 취소하려고 하면 프로필 이름만 표시하는 오류가 팝업되고 어떤 고객이 해당 프로필을 소유하는지 표시하지 않습니다.

  사용자는 프로필만 볼 수 있으므로 이 게이트웨이를 사용하고 있는 고객을 알 수 없습니다. 즉 연결된 고객이 없으면 아무 작업도 수행되지 않습니다. 따라서 VMware SD-WAN Gateway의 상태를 변경해야 할 경우 심각한 문제가 됩니다.

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

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

• 해결된 문제 63556: 사용자는 VMware SD-WAN Orchestrator UI에서 둘 이상의 TACAC 서버를 추가할 수 있습니다.

  사용자가 둘 이상의 TACAC 서버를 추가할 수 있지만 이러한 구성은 유효하지 않습니다.  그 이유는 첫 번째 TACAC 서버가 실패하는 경우 두 번째 TACAC 서버가 작업을 인계 받지 않기 때문입니다.  이 수정 사항에 따라 둘 이상의 TACAC 서버를 추가하는 옵션이 제거됩니다.

• 해결된 문제 64039: 경우에 따라 고객에게 DHCP 서버가 비활성 상태로 표시될 수 있습니다.

  주소 유형에 값을 제공한 후 DHCP 서버를 사용하도록 설정하고 값을 지정한 후 [업데이트(Update)] 버튼을 클릭하면 문제가 발생할 수 있습니다. 사용자가 하위 인터페이스 팝업을 열면 DHCP 서버 아래의 모든 필드가 숨겨진 채로 DHCP 서버가 비활성으로 표시되는 것을 볼 수 있습니다.

• 해결된 문제 65253: 방화벽 규칙을 구성할 때 20개 이상의 그룹이 구성되면 VMware SD-WAN Orchestrator UI에서 [개체 그룹(Object Groups)]에 대한 드롭다운 목록을 사용할 수 없습니다.

  개체 그룹(주소 그룹, 포트 그룹)이 5개 이상 구성되어도 [개체 그룹(Object Group)] 드롭다운 목록은 브라우저 화면 하단에 나타납니다.  규칙을 20개 이상 적용하면 [개체 그룹(Object Group)] 목록이 화면에서 완전히 벗어납니다. 목록을 전부 보려면 브라우저를 많이 축소해야 하며 축소하면 텍스트가 작아져 사용할 수 없습니다.

• 해결된 문제 65526: VMware SD-WAN Orchestrator는 "오프라인/종료" 상태에 도달하지 않는 "성능 저하됨" 상태로 VMware SD-WAN Edge에 대한 경고 및 이벤트를 생성합니다.

  처음에 VMware SD-WAN Edge와 Orchestrator의 연결이 끊어지면(하트비트 검사 시) 이 상태를 "성능 저하됨" 상태라고 합니다.  Orchestrator에 대한 Edge 연결 끊기가 계속되면 Edge는 오프라인/종료로 표시되고, Orchestrator의 "Edge 종료(Edge Down)" 이벤트를 Orchestrator의 모니터링(Monitor) > 이벤트(Events) 페이지에 게시하고, 일치하는 경고가 고객의 경고 구성에 적절한 것으로 전송되는 경우가 두 번째 성능 저하됨 상태입니다.  그러나 Orchestrator는 성능 저하됨(Degraded) 상태에서 이벤트를 생성하고 Edge에 대한 경고를 전송하므로 고객에 대해 많은 수의 가상 Edge 종료 이벤트 및 경고 알림이 발생할 수 있습니다.

• 해결된 문제 66203: 게이트웨이 풀이 클라우드 호스팅 및 파트너 게이트웨이가 모두 포함된 고객에게 할당되면 파트너는 관리되는 게이트웨이에 대한 게이트웨이 전달 구성을 수정할 수 없습니다.

  이 문제는 파트너 관리자가 고객 페이지에 있는 [고객(Customer)] 탭에서 게이트웨이 전달 구성을 수정하려고 할 때 발생합니다.

• 해결된 문제 66597: 매우 많은 수의 Edge가 배포된 고객이 있는 VMware SD-WAN Orchestrator에서 고객이 사용 중인 게이트웨이 풀에 여러 개의 VMware SD-WAN Gateway를 추가할 때 많은 수의 Edge가 Orchestrator에서 종료된 것으로 표시될 수 있습니다.

  이 문제는 Orchestrator에 연결된 Edge가 최대 7000개인 고객이 있는 상황에서 발견되었습니다. 해당 고객에 대한 게이트웨이 풀이 변경되면 Orchestrator는 모든 Edge에 구성 변경 내용을 푸시하고 30초 동안 700개가 넘는 Edge에 대한 제어부 재계산으로 인해 'POOL_ENQUEUELIMIT' 오류를 나타내며 하트비트/통계 푸시가 실패합니다. 하트비트 장애로 인해 Edge는 Orchestrator에서 종료된 것으로 표시됩니다.

• 해결된 문제 66631: 대규모 고객 엔터프라이즈를 마이그레이션하려고 할 때 마이그레이션 도구가 작동하지 않습니다.

  대규모 고객 엔터프라이즈는 Edge가 100개 이상인 엔터프라이즈로 정의됩니다. 마이그레이션 도구는 전체 데이터 Blob을 문자열로 나타내고 파일에 쓰는 단계에서 실패합니다. 구성 내보내기를 수행할 때 마이그레이션 도구는 JSON.stringify를 사용하여 출력 데이터를 문자열로 나타내고 파일에 씁니다. 이 작업은 구성이 매우 큰 경우 실패합니다.

• 해결된 문제 67153: VMware SD-WAN Edge가 구성된 지연 간격 내에 시작되더라도 경고 이메일이 전송됩니다.

  VMware SD-WAN Orchestrator는 구성된 지연 간격 내에 이벤트가 발생한 경우에도 Edge 종료/실행 중 경고 알림을 전송합니다.

• 해결된 문제 71399: 또는 VMware SD-WAN Orchestrator가 DR(재해 복구) 구성에 배포된 경우 운영자 사용자는 대기 Orchestrator가 활성 Orchestrator와 동기화되지 못한 것을 확인할 수 있습니다.

   Orchestrator UI의 복제(Replication) 페이지의 활동 모니터에서 모든 동기화 작업이 실패한 것으로 확인됩니다. DR 동기화 실패는 활성 Orchestrator가 구성 데이터베이스를 대기 Orchestrator에 복사하지 못하는 초기 핸드셰이크에서 발생합니다.

알려진 문제

릴리스 4.2.2의 미해결 문제

알려진 문제는 다음과 같이 그룹화되어 있습니다.

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

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

• 문제 14655:

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

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

• 문제 25504:

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

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

• 문제 25595:

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

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

• 문제 25742:

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

• 문제 25758:

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

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

• 문제 25855:

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

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

• 문제 25921:

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

• 문제 25997:

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

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

• 문제 26421:

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

• 문제 28175:

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

• 문제 31210:

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

• 문제 32731:

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

• 문제 32960:

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

• 문제 32981:

  DPDK 지원 포트에서 속도 및 전이중을 하드 코딩하면 비활성화된 DPDK가 필요하므로 구성을 적용하려면 VMware SD-WAN Edge를 재부팅해야 할 수 있습니다.

• 문제 35778:

  단일 인터페이스에 여러 사용자 정의 WAN 링크가 있는 경우 해당 WAN 링크 중 하나에만 Zscaler에 대한 GRE 터널이 유지될 수 있습니다. 

  해결 방법: Zscaler에 대한 GRE 터널을 구축해야 하는 각 WAN 링크에 대해 다른 인터페이스를 사용합니다.

• 문제 35807:

  VMware SD-WAN Orchestrator에서 인터페이스를 비활성화했다가 다시 활성화하면 DPDK의 라우팅된 인터페이스가 완전히 비활성화됩니다. 

• 문제 36923:

  해당 클러스터에 허브로 연결된 VMware SD-WAN Edge에 대한 NetFlow 인터페이스 설명에서 클러스터 이름이 올바르게 업데이트되지 않을 수 있습니다.

• 문제 38682:

  DPDK 지원 인터페이스에서 DHCP 서버로 작동하는 VMware SD-WAN Edge가 연결된 모든 클라이언트에 대해 "새 클라이언트 디바이스(New Client Device)" 이벤트를 제대로 생성하지 못할 수 있습니다.

• 문제 38767:

  Zscaler에 대한 GRE 터널이 구성된 WAN 오버레이가 자동 감지에서 사용자 정의로 변경되면 다음에 다시 시작할 때까지 오래된 터널이 남아 있을 수 있습니다.

  해결 방법: Edge를 다시 시작하여 오래된 터널을 지웁니다.

• 문제 39134:

  시스템 상태 통계 "CPU 백분율(CPU Percentage)"이 VMware SD-WAN Edge의 모니터링(Monitor) > Edge > 시스템(System), VMware SD-WAN Gateway의 모니터링(Monitor) > 게이트웨이(Gateways)에서 올바르게 보고되지 않을 수 있습니다.

  해결 방법: 사용자는 CPU 백분율이 아닌 Edge 용량을 모니터링하기 위해 핸드오프 대기열 손실 개수를 사용해야 합니다.

• 문제 39374:

  VMware SD-WAN Edge에 할당된 VMware SD-WAN 파트너 게이트웨이의 순서를 변경하면 게이트웨이 1이 대역폭 테스트에 사용될 로컬 게이트웨이로 올바르게 설정되지 않을 수 있습니다.

• 문제 39608:

  원격 진단 "Ping 테스트"의 출력에 잘못된 컨텐츠가 잠시 표시되었다가 올바른 결과가 표시될 수 있습니다.

• 문제 39624:

  상위 인터페이스가 PPPoE로 구성된 경우 하위 인터페이스를 통한 Ping 작업이 실패할 수 있습니다.

• 문제 39659:

  각 VMware SD-WAN Edge에 하나의 WAN 링크가 있는 향상된 고가용성을 위해 구성된 사이트에서 대기 Edge에 PPPoE만 연결되어 있고 활성 Edge에 비 PPPoE만 연결되어 있는 경우, HA 케이블에 장애가 발생하면 분할 브레인 상태(활성/활성)가 가능할 수 있습니다.

• 문제 39753:

  동적 분기 간 VPN을 비활성화하면 동적 분기 간 VPN을 사용하여 현재 전송 중인 기존 흐름이 중단될 수 있습니다.

• 문제 40096:

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

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

• 문제 40421:

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

• 문제 42278:

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

• 문제 42388:

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

• 문제 42488:

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

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

• 문제 42872:

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

• 문제 43373:

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

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

• 문제 44832:

  하나의 Edge를 통한 비 SD-WAN 대상에서 다른 Edge를 통한 비 SD-WAN 대상으로 전송되는 트래픽(예: '헤어스피닝' 또는 'NAT 루프백')이 VMware SD-WAN Edge에서 삭제됩니다.

• 문제 44995:

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

• 문제 45189:

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

• 문제 45302:

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

• 문제 46053:

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

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

• 문제 46137:

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

• 문제 46216:

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

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

• 문제 46391:

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

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

• 문제 46918:

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

• 문제 47084:

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

• 문제 47355:

  로컬 언더레이 BGP, 허브 BGP 및/또는 파트너 게이트웨이에서 고정으로 구성된 BGP를 통해 동일한 경로가 학습될 경우 경로의 정렬 순서가 잘못되어 언더레이 BGP보다 허브 BGP가 선호됩니다.

• 문제 47664:

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

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

• 문제 47681:

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

• 문제 47787:

  VMware SD-WAN Gateway 경로를 통하는 트래픽이 허브 Edge에서 해당 스포크 Edge로 시작되면 백홀 비즈니스 정책으로 구성된 VMware SD-WAN 스포크 Edge는 해당 게이트웨이 경로를 통해 트래픽을 잘못 전송합니다.

• 문제 48166:

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

• 문제 48175:

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

• 문제 48530:

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

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

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

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

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

• 문제 48666:

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

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

• 문제 49172:

  두 개의 다른 VMware SD-WAN Edge에 대해 동일한 NAT 서브넷으로 구성된 정책 기반 NAT 규칙이 작동하지 않습니다.

• 문제 49738:

  경우에 따라 VMware SD-WAN 스포크 Edge가 여러 허브 Edge를 사용하도록 구성되면 스포크 Edge가 허브 목록에 구성된 허브 중 하나로의 터널이 형성되지 않을 수 있습니다.

• 문제 50518:

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

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

• 문제 51428: VMware SD-WAN Edge에 PIM으로 구성된 하위 인터페이스가 있는 사이트에서 멀티캐스트 트래픽 손실이 발견될 수 있습니다.

  PIM으로 구성된 하위 인터페이스를 즉석에서 다른 세그먼트로 이동하면 pimd(PIM을 관리하는 프로세스)가 다시 시작되고 사이트에서 간헐적으로 멀티캐스트 트래픽 손실이 발생할 수 있습니다.

  해결 방법: 먼저 하위 인터페이스를 비활성화한 다음, 하위 인터페이스를 다른 세그먼트로 이동합니다. 이동한 후에는 하위 인터페이스를 다시 사용하도록 설정합니다.

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

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

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

• 문제 52483: 인터페이스에 대해 언더레이 계산을 사용하도록 설정하면 VMware SD-WAN Edge가 오버레이를 전달하는 대신, 동일한 인터페이스로 트래픽을 다시 잘못 전달합니다.

  이 동작은 언더레이 계산 및 재귀 경로 확인 문제로 인해 발생합니다.

  해결 방법: 영향을 받는 인터페이스에 대해 언더레이 회계를 해제하십시오.

• 문제 53219: VMware SD-WAN Hub 클러스터를 재조정한 후 몇 개의 스포크 Edge에서 RPF 인터페이스/IIF를 올바르게 설정하지 못할 수 있습니다.

  영향을 받는 스포크 Edge에서 멀티캐스트 트래픽이 영향을 받습니다. 클러스터 재조정 후 일부 스포크 Edge가 PIM 가입을 전송하지 못하게 됩니다.

  해결 방법: 이 문제는 영향을 받는 스포크 Edge로 인해 Edge 서비스가 다시 시작될 때까지 지속됩니다.

• 문제 53337: 처리량이 3200Mbps를 초과하는 경우 VMware SD-WAN Gateway의 AWS 인스턴스에서 패킷 삭제가 확인될 수 있습니다.

  트래픽이 3200Mbps보다 많은 처리량을 초과하고 패킷 크기가 1300바이트인 경우 RX 및 IPv4 BH 핸드오프에서 패킷 삭제가 확인됩니다.

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

• 문제 53359: 일부 DDoS 공격 시나리오에서 BGP/BFD 세션이 실패할 수 있습니다.

  라우팅된 인터페이스에 연결된 클라이언트에서 LAN 클라이언트로 트래픽이 플러드되면 BGP/BFD 세션이 실패할 수 있습니다. 또한 높은 우선 순위의 실시간 트래픽이 오버레이 대상으로 플러드되는 경우에도 BGP/BFD 세션이 실패할 수 있습니다.

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

• 문제 53830: VMware SD-WAN Edge에서 DCC 플래그를 사용하도록 설정한 경우 BGP 보기의 일부 경로에 올바른 기본 설정이 구성되지 않고 값을 애드버타이즈하지 않아 Edge의 FIB에서 정렬 순서가 잘못될 수 있습니다.

  Edge에 많은 수의 경로가 있는 확장된 시나리오에서 DCC(분산 비용 계산)를 사용하도록 설정한 경우, 로그 bgp_view에 대한 Edge 진단 번들을 보면 일부 경로가 기본 설정 및 애드버타이즈 값으로 올바로 업데이트되지 않을 수 있습니다.  이 문제는 대부분의 경우 대규모 엔터프라이즈의 일부인 일부 Edge(100개 이상의 스포크 Edge가 허브 Edge 또는 허브 클러스터에 연결된 경우)에서 확인될 수 있습니다.  

  해결 방법: 이 문제는 영향을 받는 경로에 대한 VMware SD-WAN Orchestrator의 OFC 페이지에서 언더레이 BGP 경로를 재학습하거나 "새로 고침(Refresh)" 옵션을 수행하여 해결할 수 있습니다. 경로의 "새로 고침(Refresh)"을 실행하면 엔터프라이즈의 모든 Edge에서 경로가 다시 학습됩니다.

• 문제 53934: VMware SD-WAN Hub 클러스터가 구성된 엔터프라이즈에서 기본 허브의 LAN 측에 멀티 홉 BGP 인접 관계가 있는 경우, LAN 측에 장애가 발생하거나 모든 세그먼트에서 BGP가 비활성화되면 고객이 스포크 Edge에서 트래픽 삭제를 경험할 수 있습니다.

  허브 클러스터에서 기본 허브는 피어 디바이스와의 멀티 홉 BGP 인접 관계가 있어서 경로를 학습할 수 있습니다. BGP 인접 관계가 설정된 허브의 물리적 인터페이스가 종료되면 BGP 보기가 비어 있더라도 BGP LAN 경로가 0이 되지 않을 수 있습니다. 이로 인해 허브 클러스터 재조정이 발생하지 않을 수 있습니다. 이 문제는 BGP가 모든 세그먼트에 대해 비활성화되어 있고 하나 이상의 멀티 홉 BGP 인접 관계가 있는 경우에도 발생할 수 있습니다.

  해결 방법: LAN 측 장애(또는 BGP 비활성화)가 있는 허브를 다시 시작하십시오.

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

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

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

• 문제 59524: DHCP 릴레이가 Edge에서 구성되는 경우 VMware SD-WAN Edge에서 데이터부 서비스 장애가 발생하고 복구를 위해 다시 시작될 수 있습니다.

  이 문제는 DHCP 릴레이 패킷 할당이 실패할 수 있는 높은 스트레스 조건에서 발생할 수 있으며 Edge의 DHCP 릴레이 처리가 이 문제를 제대로 처리하지 못하고 지속적인 DHCP 할당 실패로 인해 Edge 서비스에서 예외가 트리거되고 다시 시작됩니다.

  해결 방법: 이 문제에 대한 해결 방법은 없지만 Edge 버전 4.3.0 이상에서 해결되었습니다.

• 문제 59920: VMware SD-WAN Edge에서 데이터부 서비스 장애가 발생하고 32개 이상의 경로에 사용되는 Edge 인터페이스의 구성이 변경되면 다시 시작될 수 있습니다.

  구성 변경에는 인터페이스를 삭제하거나 새 매개 변수로 인터페이스를 업데이트하는 것이 포함될 수 있습니다. 32개가 넘는 경로를 사용하여 인터페이스를 변경하면 Edge 서비스에서 예외가 트리거되어 다시 시작될 수 있습니다.

  해결 방법: 이 문제는 릴리스 4.3.0 이상에서 수정되었습니다. 4.2.2용 핫픽스 빌드의 가용성에 대해서는 VMware SD-WAN 지원에 문의하십시오. 이 문제에 대한 수정 사항 없는 빌드를 사용하는 Edge에서 사용자는 유지 보수 기간에만 Edge 인터페이스를 변경해야 합니다.

• 문제 61543: 동일한 내부 IP를 사용하는 서로 다른 인터페이스에 2개 이상의 1:1 NAT 규칙을 구성한 경우 하나의 인터페이스에서 인바운드 트래픽이 수신될 수 있으며 동일한 흐름의 아웃바운드 패킷을 다른 인터페이스를 통해 라우팅할 수 있습니다.

  외부에서 내부로의 NAT 흐름에서는 1:1 NAT 규칙이 외부 IP 및 패킷이 수신되는 인터페이스와 일치하는지 확인됩니다. 동일한 흐름의 아웃바운드 패킷의 경우 VMware SD-WAN Edge가 내부 IP를 비교하여 NAT 규칙이 일치하는지 다시 확인하며, "아웃바운드 트래픽(Outbound Traffic)"을 사용하도록 설정한 첫 번째 일치 규칙에 구성된 인터페이스를 통해 아웃바운드 트래픽을 라우팅할 수 있습니다.

  해결 방법: 이 문제는 특정 내부 IP 주소를 사용하여 1:1 NAT 규칙이 두 개 이상 구성되지 않도록 하는 것 외에 다른 해결 방법이 없습니다.

• 문제 61716: 릴리스 4.2.0 이상을 사용하는 VMware SD-WAN Edge는 경로 조회 실패로 인해 VMware SD-WAN Orchestrator에서 생성된 패킷을 삭제할 수 있습니다.

  관리 패킷을 관리하는 프로세스에는 트래픽을 전송하기 위한 기본 클라우드 경로를 선택한다는 엄격한 규칙이 있습니다. 릴리스 4.2.x에는 정렬 논리를 변경한 수정 사항이 포함되어 있으며, 이제 Edge는 클라우드 경로보다 BGP/OSPF를 통해 학습된 기본 경로를 선호합니다.  이 시나리오에서 경로 정렬 기본 경로는 이와 같이 언더레이 BGP를 가장 선호되는 경로로 사용합니다. 빠른 경로에서 경로 조회가 대상에 대한 클라우드 경로를 제공하지 않지만 언더레이 BGP 경로를 제공하기 때문에 Orchestrator 패킷이 삭제됩니다.

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

• 문제 62275: VMware SD-WAN Gateway에서 진단 번들을 생성하면 메모리 사용량이 급증하여 게이트웨이가 다시 시작되고, 진단 번들도 실패할 수 있습니다.

  많은 수의 링크가 있는 게이트웨이에서 진단 번들을 가져오는 경우 debug.py 디버깅 명령은 많은 메모리를 사용하여 모든 데이터를 보관하고 적절한 포맷 후 Edge 프로세스로 다시 보냅니다.  이 문제가 발생하는 동안 다른 메모리 처리 문제가 있는 경우 메모리 스파이크로 인해 게이트웨이의 메모리가 고갈되며, 다시 시작됨으로써 메모리가 지워질 수 있습니다.

• 문제 62552: 사이트에서 높은 패킷 손실 및 연결 문제가 간헐적으로 발생할 수 있습니다.

  이 문제의 원인은 MAC 주소 00:00:00:00을 전달하는 동안 Edge에 디바이스에 대한 ARP 확인이 성공했음을 알리는 ARP 해결을 확인하기 API 때문에 발생했습니다.  이 주소는 ARP 캐시에 유지되어 MAC이 0으로 나열된 디바이스용 패킷이 모두 삭제됩니다.  이 문제에서는 MAC 주소가 0인 성공적인 ARP의 많은 인스턴스가 전달되어 높은 패킷 손실 및 연결 문제가 발생할 수 있습니다.

  참고: 60130 문제와 해당 문제는 기본 동작과 원인이 동일하지만 각 티켓의 예상 수정 사항이 다릅니다. 60130에는 방어적인 해결 방법이 수정 사항으로 포함되며 62552에는 해당 문제의 재발을 방지하는 완전한 수정 사항이 포함됩니다.

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

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

• 문제 67458: 많은 수의 스포크 Edge가 있는 VMware SD-WAN Hub Edge를 릴리스 4.2.1 또는 4.2.2로 업그레이드하면 허브 Edge에 대해 다른 스포크 Edge로의 일부 터널이 실행되지 않습니다.

  스포크 Edge가 1000개 이상일 때 대량으로 인식됩니다. 이 문제는 일관되지 않지만 일반적으로 허브 Edge와 연결된 스포크 Edge 간에 VCMP(VeloCloud 관리 프로토콜) 터널 중 1/3 이하가 설정되지 않습니다. 이 문제는 반개 TD의 수가 허브 Edge의 상한을 초과하므로 
  허브 Edge가 MP_INIT를 무시하기 때문에 발생합니다.
   

  해결 방법: Edge 서비스를 다시 시작하면 전체 터널 연결이 복원됩니다.

• 문제 69324: 고가용성 토폴로지를 사용하여 배포된 고객 사이트의 경우 사이트에서 HA를 사용하도록 설정하면 두 VMware SD-WAN Edge가 모두 활성으로 표시됩니다. 

  활성 및 대기 항목이 실제로는 할당된 역할을 수행하며 VMware SD-WAN Orchestrator에 표시되는 잘못된 상태를 보고하기만 하므로 실질적인 분할 브레인 시나리오에 해당하지는 않습니다.  HA verp 명령이 적절한 활성 및 대기 상태를 표시하더라도 활성 및 대기 Edge 프롬프트가 둘 다 활성으로 표시됩니다.

  해결 방법: 이 문제를 해결하려면 사용자는 대기 Edge를 다시 시작하거나 재부팅해야 합니다.

• 문제 74291: 인터넷 액세스 및 기능 DNS가 있음에도 불구하고 고가용성 토폴로지의 VMware SD-WAN Edge가 페일오버 후 오프라인으로 표시될 수 있습니다.

  이 문제는 고가용성 페일오버 후 발생할 수 있으며 새로 승격된 활성 Edge의 토큰 오류로 인해 Orchestrator에 하트비트가 실패하게 됩니다. 하트비트가 없으면 Orchestrator는 Edge를 종료 상태로 표시하며 사용자는 Orchestrator를 통해 Edge의 구성을 업데이트할 수 없습니다.

  해결 방법: 수정 사항이 적용된 Edge 빌드가 없으면 로컬 UI를 통해 또는 활성 Edge의 전원 주기를 수행하여 로컬로 다른 페일오버를 강제로 적용하여 이 문제를 해결할 수 있습니다.

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

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

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

• 문제 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.0, 4.5.0 및 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 또는 5.0.0.x를 사용하는 경우 게이트웨이 IP 주소가 지정된 라우팅된 LAN 포트만 사용합니다. 
• 문제 86098: 대기 Edge에서 PPPoE WAN 링크가 사용되는 고급 고가용성 토폴로지를 사용하는 사이트의 경우 기본 프록시 경로가 활성 Edge에 설치되어 있지 않고 해당 링크를 사용하는 트래픽이 실패할 수 있습니다.

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

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

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

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

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

• 문제 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 이상)를 사용하여 6x0 Edge를 VMware SASE Orchestrator에 연결해야 하며 먼저 Edge 핫픽스 빌드 R5012-20230123-GA-103475로 6x0 Edge를 업그레이드해야 합니다. 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 버전을 수동으로 업데이트합니다.

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

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

  해결 방법: 고객에게는 a) 고정 Edge 빌드가 전달될 때까지 Edge에 대한 분석을 일시적으로 해제하거나 b) Edge의 메모리를 모니터링하는 두 가지 선택 옵션이 있습니다. 메모리 활용률이 40%에 도달하고 Orchestrator가 메모리 주의 이벤트를 기록하면 유지 보수 기간 동안 수동으로 Edge 서비스를 다시 시작하도록 스케줄링하여 메모리를 지우고 고객에게 미치는 영향을 최소화합니다.

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

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

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

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

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

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

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

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

  해결 방법: Edge에서 이 문제가 발생하는 경우 고객은 VMware 지원에 문의하여 도움을 받거나 Edge를 릴리스 4.5.1, 빌드 R451-20220916-GA 이상으로 업그레이드할 수 있습니다.

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

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

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

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

Orchestrator의 알려진 문제

• 문제 19566:

  고가용성 페일오버 후에 대기 VMware SD-WAN Edge의 일련번호가 Orchestrator에 활성 일련번호로 표시될 수 있습니다.

• 문제 21342:

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

• 문제 24269:

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

• 문제 25932:

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

• 문제 32335:

  사용자가 계약에 동의하려고 하면 'EUSA(최종 사용자 서비스 계약)(End User Service Agreement(EUSA))' 페이지에서 오류가 발생합니다.

  해결 방법: 엔터프라이즈 이름에 선행 또는 후행 공백이 없는지 확인합니다.

• 문제 32435:

  정책 기반 NAT 구성에 대한 VMware SD-WAN Edge 재정의는 프로필 수준에서 이미 구성된 튜플에 대해 허용되고 그 반대의 경우도 마찬가지입니다.

• 문제 32856:

  비즈니스 정책이 허브 클러스터를 사용하여 인터넷 트래픽을 백홀하도록 구성되었지만 사용자는 릴리스 3.2.1에서 릴리스 3.3.x로 업그레이드된 VMware SD-WAN Orchestrator의 프로필에서 허브 클러스터의 선택을 취소할 수 있습니다.

• 문제 32913:

  고가용성을 사용하도록 설정한 후 VMware SD-WAN Edge에 대한 멀티캐스트 세부 정보가 모니터링(Monitoring) 페이지에 표시되지 않습니다. 페일오버를 수행하면 문제가 해결됩니다.

• 문제 33026:

  계약을 삭제한 후 ‘EUSA(최종 사용자 서비스 계약)(End User Service Agreement(EUSA))’ 페이지가 제대로 다시 로드되지 않습니다.

• 문제 34828:

  릴리스 2.x를 사용하는 VMware SD-WAN 스포크 Edge 및 릴리스 3.3.1을 사용하는 허브 Edge 간에 트래픽을 전달할 수 없습니다.

• 문제 35658:

  VMware SD-WAN Edge가 한 프로필에서 다른 CSS 설정이 지정된 다른 프로필로 전환되면(예: profile1의 IPsec에서 profile2의 IPsec으로) Edge 수준 CSS 설정은 이전 CSS 설정(예: GRE 대신 IPsec)을 계속 사용합니다. 

  해결 방법: 이 문제를 해결하려면 Edge 수준에서 GRE를 비활성화했다가 다시 활성화합니다.

• 문제 35667:

  VMware SD-WAN Edge가 한 프로필에서 CSS 설정은 동일하지만 GRE CSS 이름(동일한 끝점)은 다른 프로필로 전환되면 일부 GRE 터널이 모니터링 시 표시되지 않습니다.

  해결 방법: 이 문제를 해결하려면 Edge 수준에서 GRE를 비활성화했다가 다시 활성화합니다.

• 문제 36665:

  VMware SD-WAN Orchestrator가 인터넷에 연결할 수 없는 경우 Google Maps API에 액세스해야 하는 사용자 인터페이스 페이지가 완전히 로드되지 않을 수도 있습니다.

• 문제 38056:

  Edge-Licensing export.csv 파일에 지역 데이터가 표시되지 않습니다.

• 문제 38843:

  애플리케이션 맵을 푸시할 때 운영자 이벤트가 없으며 Edge 이벤트는 사용이 제한됩니다.

• 문제 39633:

  사용자가 대체 게이트웨이를 슈퍼 게이트웨이로 할당한 후에는 슈퍼 게이트웨이 하이퍼링크가 작동하지 않습니다.

• 문제 39790:

  VMware SD-WAN Orchestrator는 VMware SD-WAN Edge의 라우팅된 인터페이스를 지원되는 32개의 하위 인터페이스보다 더 많이 유지하도록 허용하므로 사용자가 인터페이스에서 33개 이상의 하위 인터페이스를 구성하여 Edge의 데이터부 서비스 실패를 유발할 위험이 있습니다.

• 문제 40341:

  Skype 애플리케이션을 백엔드에서 실시간 트래픽으로 올바르게 분류했지만 VMware SD-WAN Orchestrator에서 Skype 비즈니스 정책을 편집할 때 서비스 클래스에서 "트랜잭션"을 잘못 표시할 수 있습니다.

• 문제 41691:

  구성(Configure) > Edge > 디바이스(Device) 페이지에서 DHCP 풀이 고갈되지 않더라도 사용자가 '주소 수(Number of addresses)' 필드를 변경할 수 없습니다.

• 문제 43276:

  VMware SD-WAN Edge 또는 프로필에 파트너 게이트웨이가 구성된 경우 사용자는 세그먼트 유형을 변경할 수 없습니다.

• 문제 44153:

  VMware SD-WAN Orchestrator는 '경고 및 알림(Alerts and Notifications)' 섹션에 구성된 이메일 주소로 경고 이메일을 일관되게 전송하지 않습니다.

• 문제 46254:

  VMware SD-WAN Edge 활성화 동안 VMware SD-WAN Orchestrator는 변경된 WAN 링크 MTU 또는 DHCP 구성 인터페이스에 대한 VLAN ID가 있는지 여부를 감지하지 않습니다.

• 문제 47269:

  VMware SD-WAN 510-LTE 인터페이스가 LTE 인터페이스를 지원하지 않는 Edge 모델에 대해 표시될 수 있습니다.

• 문제 47713:

  클라우드 VPN을 비활성화한 상태에서 비즈니스 정책 규칙이 구성된 경우에는 클라우드 VPN을 사용하도록 설정할 때 NAT 구성을 다시 지정해야 합니다.

• 문제 47820:

  프로필 수준에서 DHCP를 비활성화한 상태로 VLAN을 구성했으며 DHCP를 사용하도록 설정한 해당 Edge에서 이 VLAN에 대한 Edge 재정의가 있지만 DNS 서버 필드 집합에 대한 항목이 없음(none)(IP 구성 안 함)으로 설정되면, 사용자는 구성(Configure) > Edge > 디바이스(Device) 페이지에서 변경을 수행할 수 없으며, 실제 문제를 설명하거나 가리키지 않는 '잘못된 IP 주소 []’ 오류 메시지가 표시됩니다.

• 문제 48085:

  VMware SD-WAN Orchestrator를 통해 사용자는 인터페이스와 연결된 VLAN을 삭제할 수 있습니다.

• 문제 48737:

  릴리스 4.0.0의 새 사용자 인터페이스를 사용하는 VMware SD-WAN Orchestrator의 사용자가 모니터링(Monitor) 페이지에서 시작 및 종료 시간 간격을 변경한 후 탭 간을 이동하면 Orchestrator는 시작 및 종료 간격 시간을 새 값으로 업데이트하지 않습니다.

• 문제 49225:

  VMware SD-WAN Orchestrator는 32개의 총 VLAN 제한을 적용하지 않습니다.

• 문제 49790:

  VMware SD-WAN Edge가 릴리스 4.0.0으로 활성화되면 활성화가 이벤트(Events)에 두 번 게시됩니다.

  해결 방법: 중복 이벤트를 무시합니다.

• 문제 50531:

  VMware SD-WAN Orchestrator의 4.0.0 릴리스 버전에서 새 UI에 액세스할 때 서로 다른 권한의 두 운영자가 동일한 브라우저 창을 사용하고 더 낮은 권한의 운영자가 높은 권한의 운영자 다음에 로그인을 시도하는 경우 권한이 더 낮은 운영자에게는 "사용자에게 권한이 없습니다."라는 여러 오류가 표시됩니다.

  참고: 더 낮은 권한의 운영자에 대한 권한 에스컬레이션은 수행되지 않으며 오류 메시지만 표시됩니다.

  해결 방법: 다음 운영자는 로그인하기 전에 해당 페이지를 새로 고쳐 오류가 표시되지 않도록 하거나, 각 운영자가 다른 브라우저 창을 사용하여 이 표시 문제를 방지할 수 있습니다.

• 문제 51722: 릴리스 4.0.0 VMware SD-WAN Orchestrator에서 시간 범위 선택기는 [모니터링(Monitor)] > [Edge] 탭의 통계에서 2주보다 크지 않습니다.

  통계 집합의 보존 기간이 2주보다 긴 경우에도 시간 범위 선택기는 [모니터링(Monitor)] > [Edge] 탭의 "지난 2주(Past 2 Weeks)"보다 큰 옵션을 표시하지 않습니다.  예를 들어, 경로 통계는 기본적으로 2주 동안만 보존되지만(구성 가능) 흐름 및 링크 통계는 기본적으로 365일 동안 보존됩니다(구성 가능).  이 문제는 사용자가 해당 통계의 보존 기간과 일치하는 기간을 선택할 수 있도록 허용하지 않고, 모든 모니터링 탭에서 가장 짧은 통계 유지 기간을 따르도록 합니다.

  해결 방법: 시간 범위 선택기에서 "사용자 지정(Custom)" 옵션을 사용하여 2주일보다 오래된 데이터를 볼 수 있습니다.

• 문제 60039: VMware SD-WAN Edge 모델이 변경된 경우 RMA 재활성화가 작동하지 않습니다.

  Edge 모델도 변경되는 사이트에 대해 RMA 재활성화를 수행할 때 VMware SD-WAN Orchestrator가 모델 변경을 저장하지 못하여 재활성화 링크가 작동하지 않게 됩니다. 이로 인해 Edge 모델이 변경된 RMA 재동기화에만 영향을 미치며, Edge 모델이 동일하게 유지되는 RMA 재동기화는 예상대로 작동됩니다.

  해결 방법: 사이트에 다른 Edge 모델을 사용하는 경우 사용자는 새 Edge를 생성하고 모든 Edge 관련 설정을 수동으로 적용해야 합니다.