Networking

[NSX] how ARP works between non-overlay and overlay

haewon83 2024. 6. 9. 16:52

 

ARP는 Ethernet Networking에서 통신을 위해 가장 중요한 요소 중 하나 입니다.

ARP가 동작하는 방식은 일반적인 상황에서 많이 알려져 있기 때문에 많은 분들이 Request/Reply가 동작하는 방식에 대해서 익숙할 것으로 생각합니다.

 

이 ARP가 NSX가 제공하는 Overlay 환경에서는 Broadcast와 같은 BUM Traffic을 줄여 Network을 효과적으로 사용할 수 있도록 하기 위해 다소 차이가 있습니다.

 

이에 일반적인 환경과 비교하여 Overlay 환경에서는 ARP가 어떻게 동작하는지 살펴보겠습니다.

 

VM1 정보 : IP1 / MAC1 / ESXi Host1

VM2 정보 : IP2 / MAC2 / ESXi Host2

 

Non-overlay IP networking

  • VM1이 IP2에 대한 MAC 주소 획득을 위해 Broadcast 전달
    • Source MAC 주소는 MAC1
    • Destination MAC 주소는 FF:FF:FF:FF:FF:FF
    • Source IP 주소는 IP1
    • Payload는 IP2의 MAC을 위한 Request
    • 만약 이 시점에 아직 Switch가 MAC1을 Learning 하지 않았다면, Switch의 L2 Forwarding Table에 MAC1 추가
  • L2 Network은 같은 Network 내에 다른 Port에 VM1로부터 전달된 Broadcast를 복사
  • IP2를 가진 VM2는 Broadcast로 전달된 ARP Request를 수신하고, unicast ARP message를 이용하여 VM1에게 ARP Reply 전달
    • Source MAC 주소는 MAC2
    • Destination MAC 주소는 MAC1
    • Source IP 주소는 IP2
    • Destination IP 주소는 IP1
    • VM2는 IP1에 대한 Entry를 이용하여 ARP Table Update
    • 만약 이 시점에 앚기 Switch가 MAC2를 Learning 하지 않았다면, Switch의 L2 Forwarding Table에 MAC2 추가
  • VM1이 VM2로부터 ARP Reply 수신
    • VM1은 IP2에 대한 Entry를 이용하여 ARP Table Update
  • VM1이 VM2에 ICMP Request 전달
    • Source MAC 주소는 MAC1
    • Destination MAC 주소는 MAC2
    • Source IP 주소는 IP1
    • Destination IP 주소는 IP2
    • Payload는 ICMP Request
  • VM2가 VM1으로부터 ICMP Request 수신하고 VM1에게 ICMP Reply 전달
    • Source MAC 주소는 MAC2
    • Destination MAC 주소는 MAC1
    • Source IP 주소는 IP2
    • Destination IP 주소는 IP1
    • Payload는 ICMP Reply

 

Overlay IP networking

  • VM1이 Power-on이 되면, VM1이 기동 중인 Transport Node인 ESXi Host1에 있는 L2 Forwarding Engine이 VM1의 MAC 주소를 확인
  • L2 MAC Forwarding Table을 업데이트
  • 업데이트 내용을 NSX Manager에게 전달하여, CCP의 L2 MAC Forwarding Table 업데이트
  • 각 Segment별로 LCP와 CCP의 ARP Table 업데이트 → LCP는 Local ARP Table, CCP는 CCP ARP Table
  • Transport Node의 L2 Engine은 ARP Suppression 기능이 있어, Forwarding Engine이 VM1에서 전달된 ARP Request를 확인하면, 
    • VM2의 IP2가 있는지 LCP(Local ARP Table)를 확인
    • 없으면, CCP에 IP2가 있는지 확인 요청
    • LCP 또는 CCP에서 IP2가 확인되면, ARP Suppression 기능은 IP2 대신에 VM1에 ARP Response를 전송 → Broadcast ARP Request가 ESXi Host1 밖으로 나갈 필요가 없어짐
    • 만약, IP2가 확인되지 않으면, ESXi Host1은 Broadcast ARP Request를 복제하여 내보냄
  • NSX Overlay Segment는 Default로 MTEP 사용(Hierarchical Two-Tier Replication) 
    • ESXi Host1은 ESXi Host1이 가지고 있는 TEP과 같은 Subnet에 있는 Remote TEP을 가진 Segment Active Logical Span 내의 모든 TEP에 Broadcast ARP Request를 복제
    • 그리고, 다른 Subnet에 위치한 Host의 TEP Table에 MTEP으로 표시된 모든 TEP에 Broadcast ARP Request를 복제 → 각 Remote TEP Subnet 별로 전체 TEP 중 하나의 TEP이 선택
    • 선택된 TEP을 가진 ESXi Host가 Broadcast ARP Request Packet을 받으면, TEP의 같은 Subnet 내에 위치한 Segment Active Logical Span 내의 모든 TEP에 Broadcast ARP Request를 복제
    • 만약 Segment가 Hierarchical Two-Tier Repliation이 아닌 Head End Replication 방식으로 설정되어 있다면, 단순하게 Source ESXi Host가 전체 TEP에 Packet을 복제

 

  • 다시 ARP Suppression으로 돌아가면, ARP Suppression 기능이 VM2 대신에 VM1에게 응답을 줬기 때문에, VM2는 VM1으로 부터 Request를 수신하지 못한 상태
    • VM1은 VM2의 IP를 알기 때문에 ICMP를 Unicast Request로 보낼 수 있지만, VM2의 경우에는 VM1의 IP1에 대한 ARP Entry가 없기 때문에 ICMP Request에 대해 바로 응답할 수 없는 상황
    • 이렇기 떄문에, VM2는 IP1의 MAC 주소를 확인하기 위해서 ARP Request 전송
    • 이 때 CCP는 이미 IP1의 ARP Entry를 학습하고 이를 모든 Transport Node에 Publish 한 상황
    • 따라서, ESXi Host2의 ARP Suppression 기능은 VM2의 ARP Request에 대신 응답 → Broadcast ARP Request가 ESXi Host2 밖으로 나갈 필요가 없어짐
  • 이제 CCP가 VM1과 VM2에 대한 Forwarding Entry를 모두 학습하고 Publish
## NSX Manager
nsx-mgr01> get logical-switch 3d482f26-343b-4a98-97bf-9de6e051d646 arp-table
Sat Jun 08 2024 UTC 13:04:49.076
   VNI                IP                        MAC                        TransportNode-ID
  71680           172.31.1.30            00:50:56:a6:c6:4b       efd788b6-2631-4517-bad0-c020bd0f4594
  71680           172.31.2.2             00:50:56:a6:06:cf       acade7f2-2374-49d5-8807-a159168caf33
  71680           172.31.1.50            00:50:56:a6:93:8d       efd788b6-2631-4517-bad0-c020bd0f4594
  71680           172.31.1.61            00:50:56:a6:ce:a5       efd788b6-2631-4517-bad0-c020bd0f4594

## Transport Node
[root@esxi-comp-01:~] nsxcli -c get logical-switch 3d482f26-343b-4a98-97bf-9de6e051d646 arp-table
Sat Jun 08 2024 UTC 13:04:47.546
             Logical Switch ARP Table
--------------------------------------------------
 
                Host Kernel Entry
==================================================
        IP                 MAC          Flags
 
                    LCP Entry
==================================================
        IP                 MAC
   172.31.1.30      00:50:56:a6:c6:4b
    172.31.2.2      00:50:56:a6:06:cf
   172.31.1.50      00:50:56:a6:93:8d
   172.31.1.61      00:50:56:a6:ce:a5