NSX-V의 VXLAN - 언더레이 문제 해결

안녕하세요, 먼저 가사를 좀 보세요. 나는 때때로 원격으로 일하는 동료들을 부러워합니다. 인터넷이 연결된 세계 어느 곳에서나 일할 수 있는 기회, 언제든지 휴일, 프로젝트 및 마감일에 대한 책임, 8시부터 17시까지 사무실에 있지 않은 것은 좋은 일입니다. 직위와 업무 책임으로 인해 데이터 센터에서 장기간 부재할 가능성이 실질적으로 배제됩니다. 그러나 아래와 같은 흥미로운 경우가 가끔 발생하며, 내부 문제 해결사의 창의적 표현이 이만큼 가능한 위치는 거의 없다는 것을 알고 있습니다.

작은 면책 조항 - 이 글을 쓰는 시점에는 사건이 완전히 해결되지 않았지만 공급업체의 응답 속도를 고려하면 완전한 해결에는 몇 달이 걸릴 수 있지만 지금 제가 찾은 결과를 공유하고 싶습니다. 사랑하는 독자 여러분, 이렇게 서두른 점을 용서해 주시기 바랍니다. 하지만 물은 충분합니다. 케이스에 무슨 문제가 있나요?

먼저 소개를 하자면, VMWare 프라이빗 클라우드에서 클라이언트 솔루션을 호스팅하는 회사(제가 네트워크 엔지니어로 일하고 있는 회사)가 있습니다. 대부분의 새로운 솔루션은 NSX-V에서 관리하는 VXLAN 세그먼트에 연결됩니다. 이 솔루션이 나에게 얼마나 많은 시간을 주었는지는 추정할 수 없습니다. NSX ESG를 설정하는 방법을 동료들에게 교육하기도 했으며, 제가 참여하지 않고도 소규모 클라이언트 솔루션을 배포할 수 있었습니다. 중요한 참고 사항: 유니캐스트 복제를 지원하는 제어 평면이 있습니다. 하이퍼바이저는 서로 다른 물리적 Juniper QFX5100 스위치(Virtual Chassis에 조립됨)에 대한 두 개의 인터페이스와 원래 가상 포트 타이밍 정책을 기반으로 하는 경로에 의해 중복적으로 연결됩니다. 이는 완전성을 위한 것입니다.

고객 솔루션은 매우 다양합니다. Windows IIS는 모든 웹 서버 구성 요소가 단일 머신에 설치되는 방식으로, 로드 밸런싱된 Apache 웹 프런트엔드, Galera에 설치된 로드 밸런싱 MariaDB, GlusterFS를 사용하여 동기화되는 공유 서버 등 상당히 큰 규모의 시스템까지 지원합니다. 거의 모든 서버를 개별적으로 모니터링해야 하며, 모든 구성 요소에 공용 IP 주소가 있는 것은 아닙니다. 이러한 문제를 경험해 보셨고 더 나은 해결책을 알고 계시다면 조언을 부탁드립니다.
내 모니터링 솔루션은 방화벽(Fortigate)을 각 내부 클라이언트 네트워크(+SNAT 및 허용되는 트래픽 유형에 대한 엄격한 제한)에 "연결"하고 내부 주소를 모니터링하는 것으로 구성됩니다. 이러한 방식으로 모니터링의 특정 통합 및 단순화는 다음과 같습니다. 달성. 모니터링 자체는 PRTG 서버 클러스터에서 수행됩니다. 모니터링 계획은 다음과 같습니다.

VLAN으로만 운영했지만 모든 것이 매우 정상적이었고 시계처럼 예상대로 작동했습니다. NSX-V 및 VXLAN이 도입된 후 우리는 '기존 방식으로 모니터링을 계속할 수 있습니까?'라는 질문에 직면했습니다. 이 질문 당시 "가장 빠른" 솔루션은 NSX ESG를 배포하고 VXLAN 트렁크 인터페이스를 VTEP 네트워크에 연결하는 것이었습니다. 빠른 인용문 - GUI를 사용하여 클라이언트 네트워크를 구성하므로 SNAT 및 방화벽 규칙은 단일 vSphere 인터페이스에서 관리를 통합할 수 있고 통합할 수 있지만 제 생각에는 상당히 번거롭고 무엇보다도 문제 해결을 위한 도구 세트가 제한됩니다. NSX ESG를 "실제" 방화벽의 대체품으로 사용한 사람들은 동의할 것입니다. 아마도 그러한 솔루션은 더 안정적일 것입니다. 결국 모든 것은 한 공급업체의 프레임워크 내에서 발생합니다.

또 다른 솔루션은 VLAN과 VXLAN 간의 브리지 모드에서 NSX DLR을 사용하는 것입니다. 여기서는 모든 것이 명확하다고 생각합니다. VXLAN 사용의 이점은 단순히 손실됩니다. 이 경우에도 VLAN을 모니터링 설치에 연결해야 하기 때문입니다. 그런데 이 솔루션을 해결하는 과정에서 DLR 브리지가 동일한 호스트에 있는 가상 머신에 패킷을 보내지 않을 때 문제가 발생했습니다. 알아요, 알아요. NSX-V에 대한 책과 가이드에는 NSX Edge에 별도의 클러스터를 할당해야 한다고 직접 명시되어 있지만 이는 책에 나와 있습니다... 어떤 식으로든, 몇 달이 지나면 지원, 우리는 문제를 해결하지 못했습니다. 원칙적으로 나는 작업의 논리를 이해했습니다. 트래픽이 호스트를 떠나지 않고 논리적으로 연결되어야 하기 때문에 DLR과 모니터링되는 서버가 동일한 호스트에 있는 경우 VXLAN 캡슐화를 담당하는 하이퍼바이저 커널 모듈이 사용되지 않았습니다. VXLAN 세그먼트에 - 캡슐화가 필요하지 않습니다. 지원을 통해 우리는 업링크를 논리적으로 연결하고 브리징/캡슐화도 수행하는 가상 인터페이스 vdrPort를 결정했습니다. 여기서 수신 트래픽의 불일치가 발견되었으며 현재 사례에서 작업을 수행했습니다. 그러나 말했듯이 나는 다른 프로젝트로 옮겨졌고 지점이 처음에는 막 다른 골목이었고 그것을 개발하려는 특별한 욕구가 없었기 때문에 나는 이 사건을 끝내지 못했습니다. 제가 착각한 것이 아니라면 이 문제는 NSX 버전과 6.1.4 및 6.2 버전에서 관찰되었습니다.

그리고 – 빙고! 포티넷, 네이티브 발표 VXLAN 지원. 그리고 소프트웨어 VLAN-VXLAN 브리징이 아닌 지점 간 또는 VXLAN-over-IPSec뿐만 아니라 이 모든 것이 버전 5.4에서 다시 구현되기 시작했습니다. 공급 업체), 그러나 진정한 유니캐스트 제어 평면을 지원합니다. 솔루션을 구현할 때 또 다른 문제에 직면했습니다. 가상 머신 자체는 살아 있음에도 불구하고 주기적으로 확인되는 서버가 "사라졌다"고 모니터링에 나타났습니다. 그 이유는 VXLAN 인터페이스에서 Ping을 활성화하는 것을 잊어버렸기 때문입니다. 클러스터 재조정 프로세스 중에 가상 머신이 이동되었고, 머신이 이동된 새 ESXI 호스트를 표시하기 위해 Ping을 통해 vMotion이 완료되었습니다. 내 어리 석음이지만이 문제는 제조업체 (이 경우 Fortinet)가 제공하는 지원에 대한 신뢰를 다시 한 번 훼손했습니다. VXLAN과 관련된 모든 사례가 "설정에서 VLAN-VXLAN 소프트 스위치는 어디에 있습니까?"라는 질문으로 시작된다는 말은 아닙니다. 이번에는 MTU를 변경하라는 조언을 받았습니다. 이는 32바이트인 Ping용입니다. 그런 다음 UDP에 캡슐화된 VXLAN에 대한 정책에서 tcp-send-mss 및 tcp-receive-mss를 사용하여 "다뤄보세요". 휴, 미안해요. 끓고 있어요. 일반적으로 저는 이 문제를 스스로 해결했습니다.

테스트 트래픽을 성공적으로 출시한 후 이 솔루션을 구현하기로 결정했습니다. 그리고 생산 과정에서 하루나 이틀이 지나면 VXLAN을 통해 모니터링되는 모든 것이 점차적으로 중단되는 것으로 나타났습니다. 인터페이스 비활성화/활성화는 도움이 되었지만 일시적이었습니다. 지원이 느리게 진행된다는 점을 염두에 두고 저는 문제 해결을 시작했습니다. 결국 회사와 네트워크는 제 책임입니다.

문제 해결 진행 상황은 스포일러 아래에 있습니다. 글자와 자랑이 지겹다면 생략하고 사후분석으로 넘어가세요.

문제 해결 진행 상황계속 읽어주셔서 감사합니다. 계속해서 읽어보겠습니다!

따라서 모니터링은 한동안 작동하다가 저절로 작동이 중단됩니다. 이는 방화벽 정책에 문제가 없을 가능성이 높다는 것을 의미합니다. 그러나 Fortigate 버전 5.6+에서 시스템 프로세스 중단 문제가 발생했기 때문에 먼저 "디버그 흐름 진단"을 살펴보겠습니다. 예상대로 트래픽이 허용되고 인터페이스를 떠나며 예상대로 아무것도 응답하지 않습니다. 그래서 우리는 스택을 더 자세히 파헤칩니다. 아쉽게도 RFC1918이라 하더라도 주소를 숨겨야 하는데, 이해를 돕기 위해 프로세스에 대한 충분한 설명을 제공하고자 합니다. VXLAN 내부 서버의 주소는 x.x.x.15이고 Fortigate 인터페이스는 x.x.x.254이며 다른 모든 주소는 VTEP 네트워크에 속합니다.

VXLAN 캡슐화 패킷을 성공적으로 전송하려면 여러 테이블에 올바른 정보가 필요합니다. 오버레이의 경우 ARP 및 OVSDB이고, 언더레이의 경우 ARP 및 CAM입니다. Fortigate VXLAN FDB의 경우 OVSDB입니다. 거기서부터 시작해보자:

 fortigate (root) #diag sys vxlan fdb list vxlan-LS
mac=00:50:56:8f:3f:5a state=0x0002 flags=0x00 remote_ip=у.у.у.47 port=4789 vni=5008 ifindex=7

여기의 모든 것은 매우 간단합니다. 가상 머신의 MAC 주소는 주소 u.u.u.47을 사용하여 VTEP에 있어야 합니다. ESXI 클러스터의 내용과 설정을 살펴본 결과 가상 머신의 MAC과 VTEP 주소가 올바른 것으로 나타났습니다. fortik에서 CAM/ARP 테이블을 확인합니다. 다시 모든 것이 ESXI 호스트 설정과 일치합니다.

fortigate (root) #get sys arp | grep у.у.у.47
у.у.у.47 0 00:50:56:65:f6:2c dmz

테이블이 정확하고 트래픽이 떠나고 있습니다. Fortigate에 문제가 없을 수도 있습니까? 저는 의도적으로 Juniper의 트래픽 스위칭 분석을 건너뛰었습니다. 논리적으로 문제 해결의 다음 단계를 수행해야 하지만 제 네트워크는 간단합니다. VTEP용 VLAN이 하나만 있고 모든 구성 요소가 직접 연결되어 있습니다. 또한 DLR 브리지, VDR 및 트래픽 손실 사례가 기억납니다. ESXI 호스트를 스니핑하는 동시에 VMWare에 대한 사례를 생성할 예정입니다. 아래 MAC "97:6e"는 fortik에 속하며 vmnic1은 양방향 "--dir 47"에서 u.u.u.2 snifim 주소를 갖는 VTEP를 갖는 인터페이스입니다.

pktcap-uw --uplink vmnic1 --vni 5008  --mac 90:6c:ac:a9:97:6e --dir 2 -o /tmp/monitor.pcap

진행률 - 스니프에서 ARP 요청과 수신 응답을 볼 수 있습니다. 나는 ARP 응답만 제공하고 모든 것이 정확합니다. 언급하지는 않았지만 이번에는 모니터링 서버가 x.x.x.15 주소로 ping을 보내고 있습니다. ICMP 트래픽은 어디에 있습니까? 업링크가 두 개 있는 것으로 기억합니다. 여기서 소스 가상 포트가 동일하다고 주장할 수 있습니다(내 팀 구성 정책). 즉, 동일한 vNIC에 대해 동일한 업링크를 선택해야 하지만 호스트에 있기 때문에 다른 업링크를 확인하는 것은 문제:

pktcap-uw --uplink vmnic4 --vni 5008  --mac 90:6c:ac:a9:97:6e --dir 2 -o /tmp/monitor.pcap

Fortigate에서 요청이 오고 있지만 응답이 없습니다. 즉, 문제는 Fortigate에 있지 않습니다. 글쎄요, 그게 다입니다. 제 생각에는 VDR에서 트래픽 누락과 관련된 동일한 문제가 다시 발생하며 사례를 올바른 방향으로 안내하는 데 몇 달이 걸릴 것입니다. 며칠 후, 식은 후, 버티고 싶지 않아 프로세스 속도를 높이기 위해 지원을 위해 더 많은 냄새를 맡기로 결정했습니다. 그리고 "우연히" 내 시선은 이더넷 언더레이 캡슐화에 쏠렸습니다. 차르는 실제가 아니며 VTEP의 MAC 주소가 그의 IP와 일치하지 않습니다. 나는 0으로 재설정하고, 냄새를 맡고, 파헤칩니다. 사실입니다. 사실이 아닙니다. 비교하기 쉽도록 ARP 테이블을 나란히 제공하겠습니다. 위 그림에서 첫 번째 이더넷 캡슐화를 확인하세요.

fortigate (root) #get sys arp | grep у.у.у.47
у.у.у.47 0 00:50:56:65:f6:2c dmz
fortigate (root) #get sys arp | grep у.у.у.42
у.у.у.42 0 00:50:56:6a:78:86 dmz

따라서 결국 가상 머신을 마이그레이션한 후 Fortigate는 (올바른) VXLAN FDB에서 VTEP로 트래픽을 보내려고 시도하지만 잘못된 DST MAC를 사용하고 이를 수신하는 하이퍼바이저 인터페이스에 의해 트래픽이 삭제될 것으로 예상됩니다. 또한 4개 중 1개는 이 MAC가 머신 마이그레이션이 시작된 원래 하이퍼바이저에 속했습니다.

어제 Fortinet 기술 지원으로부터 편지를 받았습니다. 제 경우에는 버그 615586이 발견되었습니다. 저는 정말 기뻐해야 할지 슬퍼해야 할지 모르겠습니다. 한편으로는 문제가 설정에 있지 않고 다른 한편으로는 해결 방법입니다. 펌웨어 업데이트만 제공되거나 기껏해야 다음 업데이트와 함께 제공됩니다. ChSV는 지난 달에 발견한 또 다른 버그로 인해 발생했습니다. 그 당시에는 HTML5 GUI vSphere였습니다. 음, 공급업체의 현지 QA 부서만...

나는 다음과 같이 추측해 보겠습니다.

1 - 멀티캐스트 제어 평면은 설명된 문제에 영향을 받지 않을 가능성이 높습니다. 결국 VTEP MAC 주소는 인터페이스가 가입된 그룹의 IP 주소에서 얻어집니다.

2 - 네트워크 프로세서(CEF와 거의 유사)에서 세션을 오프로드할 때 발생하는 문제일 가능성이 높습니다. 각 패킷을 CPU를 통해 전달하면 올바른(적어도 시각적으로) 정보가 포함된 테이블이 사용됩니다. 이 가정은 인터페이스를 닫거나 열거나 일정 시간(5분 이상)을 기다리는 데 도움이 된다는 사실로 뒷받침됩니다.

3 - 명시적 장애 조치 등으로 팀 구성 정책을 변경하거나 LAG를 도입해도 문제가 해결되지 않습니다. 소스 하이퍼바이저의 MAC가 캡슐화된 패킷에 "고착"된 것으로 관찰되었기 때문입니다.

이에 비추어 제가 최근에 발견한 사실을 공유할 수 있습니다. 블로그, 기사 중 하나에서는 stetfull 방화벽과 캐시된 데이터 전송 방법이 버팀목이라고 명시했습니다. 글쎄요, 저는 이런 말을 할 만큼 IT 경험이 부족하고, 게다가 블로그 기사의 모든 진술에 즉시 동의하지도 않습니다. 하지만 뭔가 이반의 말이 일리가 있다는 것을 알 수 있었습니다.

관심을 가져주셔서 감사합니다! 나는 기꺼이 질문에 답하고 건설적인 비판을 듣겠습니다.

출처 : habr.com