Konfiguracja TGW EVPN/VXLAN

Michał Iwańczuk

8. czerwca 2026

Reading time: 17 min

Zapraszam Cię do omówienia kolejnego kroku w ewolucji w systemie VCF 9.1 , jaką jest Rozproszona Brama Tranzytowa z EVPN/VXLAN (Distributed Transit Gateway z EVPN/VXLAN), w której węzły Edge całkowicie znikają z topologii, a ruch Północ-Południe (N/S) przepływa bezpośrednio z każdego hosta ESX przez tunel VXLAN do zewnętrznej bramy brzegowej (BGW).

Poniżej znajduje się kompletna konfiguracja z mojego środowiska testowego, w którym jako BGW wykorzystano system VyOS oraz cztery hosty ESXi w domenie homelab.int.

Czym jest DTGW z EVPN/VXLAN

DTGW (Distributed Transit Gateway) to nowa opcja łączenia środowiska VCF z siecią fizyczną, dostępna od wersji VCF 9.0. Wersja VCF 9.1 dodaje obsługę EVPN/VXLAN jako typu łącza nadrzędnego (uplink) zamiast tradycyjnego VLAN — jest to ten sam mechanizm BGP EVPN Type-5, który dobrze znamy z fizycznych struktur sieciowych takich producentów jak Arista, Cisco Nexus czy Juniper.

W skrócie, oto różnice w porównaniu do starego podejścia z NSX-T 3.0:

Różnice architektoniczne

NSX-T 3.0 / EVPN na T0	VCF 9.1 / DTGW EVPN/VXLAN
BGP EVPN jest inicjowany z węzła Edge	BGP EVPN jest inicjowany z Kontrolera Tras (Route Controller – VNA)
Ruch: VM $\rightarrow$ Edge $\rightarrow$ BGW	Ruch: VM $\rightarrow$ Host TEP $\rightarrow$ BGW (bez węzła Edge)
Tunele VXLAN kończą się na węźle Edge	Tunele VXLAN kończą się na każdym hoście ESX (TEP)
VRF na bramie T0	Instancje VRF zarządzane przez DTGW + Kontroler Tras
Wymagane zarządzanie cyklem życia węzłów Edge	Brak Edge — brak konieczności zarządzania cyklem życia Edge

Wymagania i ograniczenia

Wymagania (Requirements)	Ograniczenia w VCF 9.1 (Limitations in VCF 9.1)
VCF 9.1 / NSX 9.1	Brak usług Północ-Południe (SNAT, LB) — planowane w przyszłym wydaniu VCF
BGW obsługująca BGP EVPN Type-5 (MP-BGP)	Tylko warstwa L3 (Route Type-5) — brak rozszerzenia L2 (L2 extension) do struktury sieciowej
MTU sieci podkładowej (Underlay) min. 1600 (narzut VXLAN wynosi ~50 B)	Tryb Access Mode: Private wymaga ręcznej konfiguracji NAT po stronie BGW
Grupa portów DVS wymagana dla sieci peeringowej RC BGP	Identyfikator tabeli VRF w VyOS musi mieścić się w przedziale $<1-200$, jeśli planujesz używać NAT

Środowisko testowe

Element	Wartość (Value)	Uwagi (Note)
Hosty ESXi	`ESXi11 – ESXi14`	domena homelab.int
VLAN TEP Host	`10.231.104.0/24`	vmk Host TEP
VLAN BGP Peering	`10.231.106.0/24`	eth2.506 w VyOS
Peer VyOS (BGW)	`10.231.106.1`	BGP update-source
Peer RC (BGP VIP)	`10.231.106.10`	Pływający adres IP Kontrolera Tras (Route Controller floating IP)
ASN VyOS	`64515`	BGP system-as
ASN Route Controller	`64520`	remote-as w VyOS
L3VNI / VNI	`65000`	identyfikator VRF dzierżawcy (tenant VRF identifier)
VRF (VyOS)	`test`	tabela 65000
Subnet VM (External IP Block)	`10.231.200.0/24`	Adresy maszyn wirtualnych w trybie Public
RD VyOS (global)	`64515:10`
RD VyOS (VRF)	`10.231.106.1:10`	unikalny dla każdego VRF
Export RT VyOS	`64515:10`
Import RT VyOS	`64515:10 + 64520:10`	importuje również RT z Kontrolera Tras (RC)
Export RT RC	`64520:10`	konfigurowane w NSX External Connectivity
Import RT RC	`64515:10`	importuje RT z VyOS

Diagram

Weryfikacja łączności przed konfiguracją

Przed wdrożeniem Kontrolera Tras (RC) warto upewnić się, że hosty ESXi mają łączność z adresem, który zostanie użyty jako source-address dla VXLAN po stronie VyOS. Wykonaj test ping z vmk0 i vmk1 na adres bramy BGW.

[root@ESXi11:~] ping -I vmk10 10.231.106.1 -S vxlan
PING 10.231.106.1 (10.231.106.1): 56 data bytes
64 bytes from 10.231.106.1: icmp_seq=0 ttl=64 time=0.425 ms
64 bytes from 10.231.106.1: icmp_seq=1 ttl=64 time=0.424 ms
64 bytes from 10.231.106.1: icmp_seq=2 ttl=64 time=0.394 ms
3 packets transmitted, 3 packets received, 0% packet loss

[root@ESXi11:~] ping -I vmk11 10.231.106.1 -S vxlan
PING 10.231.106.1 (10.231.106.1): 56 data bytes
64 bytes from 10.231.106.1: icmp_seq=0 ttl=64 time=0.748 ms
64 bytes from 10.231.106.1: icmp_seq=1 ttl=64 time=0.820 ms
64 bytes from 10.231.106.1: icmp_seq=2 ttl=64 time=0.340 ms
3 packets transmitted, 3 packets received, 0% packet loss

Brak odpowiedzi na tym etapie oznacza, że tunele VXLAN nie będą działać, nawet jeśli sesja BGP przejdzie w stan Established. Wartość MTU została ustawiona na 9000; narzut VXLAN wynosi około 50 B, więc zapas jest optymalny.

Konfiguracja VyOS (BGW)

Interfejsy — VXLAN, bridge

Konfiguracja interfejsów sieciowych, tunelu VXLAN oraz mostka (bridge) w systemie VyOS.

# trunk VLAN on eth2, MTU 9000 (underlay)
set interfaces ethernet eth2 mtu '9000'
set interfaces ethernet eth2 vif 506 address '10.231.106.1/24'
set interfaces ethernet eth2 vif 504 address '10.231.104.1/24'

# VXLAN — VNI 65000 = tenant L3VNI
# source-address = BGP peering address
set interfaces vxlan vxlan65000 mtu '1500'
set interfaces vxlan vxlan65000 port '4789'
set interfaces vxlan vxlan65000 source-address '10.231.106.1'
set interfaces vxlan vxlan65000 vni '65000'

# bridge connects VXLAN to VRF "test"
set interfaces bridge br1 address '10.231.251.1/24'
set interfaces bridge br1 member interface vxlan65000
set interfaces bridge br1 vrf 'test'

Globalna sesja BGP i sesja z Kontrolerem Tras (Route Controller)

set protocols bgp system-as '64515'
set protocols bgp parameters router-id '10.231.106.1'
set protocols bgp parameters bestpath as-path multipath-relax

set protocols bgp address-family ipv4-unicast redistribute connected
set protocols bgp address-family ipv4-unicast redistribute static
set protocols bgp address-family ipv4-unicast import vrf 'test'

set protocols bgp address-family l2vpn-evpn advertise ipv4 unicast
set protocols bgp address-family l2vpn-evpn advertise-all-vni
set protocols bgp address-family l2vpn-evpn advertise-default-gw
set protocols bgp address-family l2vpn-evpn advertise-svi-ip
set protocols bgp address-family l2vpn-evpn default-originate ipv4

# sesja BGP z Route Controllerem (BGP VIP)
set protocols bgp neighbor 10.231.106.10 remote-as '64520'
set protocols bgp neighbor 10.231.106.10 update-source '10.231.106.1'
set protocols bgp neighbor 10.231.106.10 address-family ipv4-unicast default-originate
set protocols bgp neighbor 10.231.106.10 address-family ipv4-vpn route-server-client
set protocols bgp neighbor 10.231.106.10 address-family l2vpn-evpn soft-reconfiguration inbound

Kilka uwag dotyczących parametrów sąsiedztwa dla Kontrolera Tras (RC):

default-originate — VyOS rozgłasza trasę domyślną (default route) do Kontrolera Tras, który następnie dystrybuuje ją do hostów ESX.
soft-reconfiguration inbound — pozwala na resetowanie polityki BGP bez zrywania samej sesji, co jest bardzo przydatne podczas testów.
route-server-client — ułatwia propagację tras pomiędzy klientami BGP za pośrednictwem Kontrolera Tras.

VRF „test”

VyOS wymaga, aby identyfikator tabeli (table ID) mieścił się w zakresie 1–200, jeśli planujesz używać mechanizmu connection-mark do realizacji translacji NAT z poziomu VRF.

W tym przykładzie używam table '65000', co działa poprawnie dla samego routingu, ale warto rozważyć zmianę np. na 100, jeśli planujesz dodać NAT w przyszłości.

set vrf name test table '65000'
set vrf name test vni '65000'

set vrf name test protocols bgp system-as '64515'
set vrf name test protocols bgp parameters router-id '10.231.106.1'

set vrf name test protocols bgp address-family ipv4-unicast import vrf 'default'
set vrf name test protocols bgp address-family ipv4-unicast redistribute connected
set vrf name test protocols bgp address-family ipv4-unicast redistribute static

# RD and RT per-VRF — different from global!
set vrf name test protocols bgp address-family l2vpn-evpn rd '10.231.106.1:10'
set vrf name test protocols bgp address-family l2vpn-evpn route-target export '64515:10'
set vrf name test protocols bgp address-family l2vpn-evpn route-target import '64520:10'
set vrf name test protocols bgp address-family l2vpn-evpn route-target import '64515:10'
set vrf name test protocols bgp address-family l2vpn-evpn vni 65000

set vrf name test protocols bgp address-family l2vpn-evpn advertise ipv4 unicast
set vrf name test protocols bgp address-family l2vpn-evpn advertise-default-gw
set vrf name test protocols bgp address-family l2vpn-evpn advertise-svi-ip

Logika Route Target

Strona (Side)	Export RT	Import RT	Efekt (Effect)
VyOS (BGW)	`64515:10`	`64515:10`, `64520:10`	VyOS importuje trasy z Kontrolera Tras (RC) oraz własne
Route Controller (NSX)	`64520:10`	`64515:10`	RC importuje trasy z VyOS (trasę domyślną i sieci zewnętrzne)

Weryfikacja konfiguracji VyOS — VNI oraz bridge

Po zakończeniu konfiguracji VyOS upewnij się, że identyfikator VNI jest aktywny, a mostek jest prawidłowo skonfigurowany.

vyos@vyos:~$ show bgp l2vpn evpn vni
Advertise Gateway Macip: Enabled
Advertise SVI Macip: Enabled
Advertise All VNI flag: Enabled
BUM flooding: Head-end replication
VXLAN flooding: Enabled
Number of L2 VNIs: 1
Number of L3 VNIs: 1
Flags: * - Kernel
  VNI        Type RD                    Import RT                 Export RT                 Tenant VRF
  65000      L2   10.231.106.1:2        64515:10                  64515:10                  default
* 65000      L3   10.231.106.1:10       64515:10, ...             64515:10                  test

# * = Kernel = active in kernel table (L3 VNI)
# L2 VNI without asterisk = bridge with no VPC subnet assigned (normal before adding a VM)
vyos@vyos:~$ show evpn vni 65000
VNI: 65000
  Type: L3
  Tenant VRF: test
  Vlan: 1
  Bridge: br1
  Local Vtep Ip: 10.231.106.1
  Vxlan-Intf: vxlan65000
  SVI-If: br1
  State: Up
  VNI Filter: none
  System MAC: c2:8f:db:73:82:3c
  Router MAC: c2:8f:db:73:82:3c
  L2 VNIs:

Stan State: Up oraz Local Vtep Ip dopasowany do source-address interfejsu vxlan65000 — jest to adres, który pojawi się jako VTEP w ogłoszeniach BGP EVPN Type-5 wysyłanych do Kontrolera Tras.

vyos@vyos:~$ show bridge br1 detail
Interface br1 is up, line protocol is up
  Link ups:      13    last: 2026/05/07 10:28:54.00
  Link downs:    14    last: 2026/05/07 10:28:54.00
  vrf: test
  index 17 metric 0 mtu 1500 speed 0 txqlen 1000
  flags: <UP,LOWER_UP,BROADCAST,RUNNING,MULTICAST>
  Type: Ethernet
  HWaddr: c2:8f:db:73:82:3c   # this MAC == Router MAC in EVPN
  inet 10.231.251.1/24
  Interface Type Bridge
  Interface Slave Type Vrf
  Bridge VLAN-aware: no
  protodown: off
Adres MAC mostka br1 (c2:8f:db:73:82:3c) jest używany jako Router MAC w ogłoszeniach RT-5. Z tego powodu parametry RD (Route Distinguisher) po stronie VyOS oraz po stronie Kontrolera Tras (RC) muszą być różne — każda ze stron wymaga własnych, unikalnych wartości.

Weryfikacja konfiguracji VyOS — VNI oraz bridge

Krok 1 — Wdrożenie Kontrolera Tras (Route Controller)

Przejdź do NSX Manager $\rightarrow$ Network $\rightarrow$ EVPN $\rightarrow$ Route Controllers i kliknij Add Route Controller.

Wypełnij szczegóły:

Route Controller Name: evpn-test
Node Form Factor: small

Kliknij Add i uzupełnij dane dla węzła Node 1 — informacje o sieci zarządzania (Management Network) dla urządzenia wirtualnego:

Management IP, Gateway, DNS — wartości z Twojej sieci zarządzania.

Datastore, Cluster, Host — wybierz odpowiednie zasoby z vCenter.

Po wypełnieniu danych węzła kliknij Next (w laboratorium używam pojedynczego węzła). Na kolejnym ekranie skonfiguruj interfejs BGP:

Port Group — grupa portów DVS dla VLAN 506 (peering BGP), musi istnieć przed wdrożeniem.
Node 1 IP / Node 2 IP — adresy węzłów w sieci BGP.
BGP Floating IP — 10.231.106.10 — aktywny adres VIP Kontrolera Tras; ten adres wpisuje się w VyOS jako neighbor.
Prefix length — /24

Po kliknięciu Finish Kontroler Tras zostanie wdrożony automatycznie. Odczekaj 5–10 minut, a następnie zweryfikuj status.

Kliknij na BGP Neighbors:

Stan Idle na jednym z węzłów jest zjawiskiem normalnym — aktywny Kontroler Tras wykazuje stan Established, podczas gdy węzeł zapasowy (standby) pozostaje w stanie Idle. Jeśli aktywny węzeł również pokazuje status Idle lub Active, wykonaj operację Disable $\rightarrow$ Enable na sąsiedzie BGP w interfejsie NSX i odczekaj chwilę.

Zweryfikuj stan po stronie VyOS — parametr State/PfxRcd wyświetlany jako liczba (a nie jako „Active” / „Connect”) oznacza, że sesja została pomyślnie ustanowiona.

vyos@vyos:~$ show bgp l2vpn evpn summary
BGP router identifier 10.231.106.1, local AS number 64515 VRF default vrf-id 0

Neighbor        V         AS   MsgRcvd   MsgSent   TblVer  Up/Down  State/PfxRcd PfxSnt
10.231.106.10   4      64520      2991      3024       15    22:20:56            2     16  N/A

# State/PfxRcd as a number — session Established, RC receives 2 prefixes from VyOS
# other neighbors (10.231.107.11, .12 etc.) — Active = other segments, not this EVPN/VXLAN setup

Krok 2 — Połączenie zewnętrzne (Distributed VXLAN Connection)

Przejdź do Network $\rightarrow$ VPC Connectivity $\rightarrow$ Transit Gateway. Możesz zmodyfikować domyślny TGW lub dodać nowy.

Wypełnij formularz:

Type — Distributed VXLAN Connection
Route Controller — evpn-test (wdrożony w Kroku 1)
EVPN L3 VNI — 65000 — musi odpowiadać wartości vni 65000 w VyOS.
Route Distinguisher — 10.231.106.10:65000 — format BGP VIP : VNI; musi różnić się od RD po stronie VyOS (10.231.106.1:10).
Import Route Target — 64515:10 — importowanie tras eksportowanych przez VyOS.
Export Route Target — 64520:10 — VyOS musi importować tę wartość.

Zadanie tworzenia struktury zakończy się w ciągu kilku sekund.

Krok 3 — Konfiguracja DTGW

Przejdź do Network $\rightarrow$ VPC Connectivity $\rightarrow$ Transit Gateway. Możesz zmodyfikować domyślny TGW lub dodać nowy.

W formularzu edycji TGW:

Connectivity (Uplink Type) — zmień na Distributed VXLAN.
External Connectivity — wybierz rekord odpowiadający naszemu Kontrolerowi Tras (RC).

Po zapisaniu zmian otwórz profil połączeń VPC (VPC Connectivity Profile) powiązany z tym TGW i przejdź do jego edycji. Zdefiniuj pule adresowe:

External IP Address Block — 10.231.200.0/24 — pula routowalna z poziomu bramy BGW, używana do przypisywania adresów IP dla maszyn wirtualnych w trybie Public.
Private TGW IP Address Block — 172.26.0.0/16 — prywatna pula w ramach bramy TGW.

Tworzenie VPC oraz podsieci (Subnet)

Wirtualna Chmura Prywatna (VPC)

W kliencie vSphere przejdź do Virtual Private Clouds $\rightarrow$ New Virtual Private Cloud.
Name: test-vpc
Private VPC IP CIDR: 192.168.0.0/16
Advanced Settings $\rightarrow$ Connectivity Profile — upewnij się, że wybrany jest profil powiązany z DTGW.

Opcjonalnie — Domyślny profil usług VPC (Default VPC Service Profile)

Przed utworzeniem podsieci możesz zmodyfikować domyślny profil usług VPC (Default VPC Service Profile), aby serwer DHCP przekazywał informacje o serwerach DNS i NTP. Przejdź do VPC $\rightarrow$ Profiles $\rightarrow$ VPC Service Profiles $\rightarrow$ edytuj Default VPC Service Profile:

DNS Server: 10.231.106.1 (VyOS)
NTP Server: 10.231.106.1 (VyOS)

Podsieć (Tryb Public)

W widoku VPC kliknij New Subnet…

Subnet Name: public-sub-01

VLAN Extension: No (funkcja rozszerzenia L2, nie dotyczy architektury EVPN/VXLAN)

Access Mode: Public

IP Block: wybierz zakres z bloku adresów zewnętrznych 10.231.200.8/29

W ustawieniach zaawansowanych (Advanced Settings):

VPC Gateway Connectivity: Yes (wartość domyślna, pozostaw bez zmian)
DHCP: DHCP Server

Podłączenie maszyny wirtualnej i weryfikacja

Podłączenie karty vNIC do podsieci VPC

W ustawieniach maszyny wirtualnej, na karcie VPC Subnets, wybierz sieć test i zapisz zmiany.

Weryfikacja z poziomu systemu operacyjnego gościa (Guest OS)

Po uruchomieniu maszyny wirtualnej sprawdź adres przypisany przez DHCP oraz bramę domyślną.

Weryfikacja po stronie VyOS — trasy BGP EVPN

Po włączeniu maszyny wirtualnej, trasy typu /32 do każdej z maszyn powinny pojawić się w tabeli routingu VRF test w systemie VyOS, z adresem następnego skoku (next-hop) wskazującym na interfejs TEP hosta ESX, na którym uruchomiona jest dana maszyna:

vyos@vyos:~$ show bgp l2vpn evpn summary
BGP router identifier 10.231.106.1, local AS number 64515 VRF default vrf-id 0
RIB entries 9, using 1296 bytes of memory
Peers 1, using 29 KiB of memory

Neighbor        V         AS   MsgRcvd   MsgSent   TblVer  Up/Down  State/PfxRcd PfxSnt
10.231.106.10   4      64520      2991      3024       15    22:20:56            2     16  N/A

# State/PfxRcd = 2 — RC is advertising 2 prefixes (/32 for 2 VMs)
# PfxSnt = 16 — VyOS is advertising 16 prefixes (connected + default route)
vyos@vyos:~$ show ip route vrf test
B>* 10.231.200.3/32  [20/0] via 10.231.104.3, br1 onlink   # VM1 — TEP 10.231.104.3
B>* 10.231.200.11/32 [20/0] via 10.231.104.7, br1 onlink   # VM2 — TEP 10.231.104.7

# After vMotion VM1 to another host:
# B>* 10.231.200.3/32 [20/0] via 10.231.104.X, br1 onlink  — next-hop changes

Wpis typu /32 z adresem next-hop wskazującym na adres TEP hosta ESXi potwierdza, że Kontroler Tras prawidłowo raportuje lokalizację maszyn wirtualnych. Po wykonaniu operacji vMotion adres następnego skoku zmienia się automatycznie — jest to ten sam mechanizm GARP-to-RC, co w NSX-T 3.0, tyle że bez udziału węzła Edge.

Szczegóły RT-5 w BGP EVPN — mapowanie maszyn wirtualnych do interfejsów TEP

Pełna tabela BGP EVPN po stronie VyOS — widoczne są dwa parametry Route Distinguisher: lokalny VyOS oraz Kontroler Tras (RC):

vyos@vyos:~$ show bgp l2vpn evpn
BGP table version is 2, local router ID is 10.231.106.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
EVPN type-5 prefix: [5]:[EthTag]:[IPlen]:[IP]

   Network          Next Hop            Metric LocPrf Weight Path

Route Distinguisher: 64520:10          # routes from RC (VMs in VPC)
 *>  [5]:[0]:[32]:[10.231.200.3]       # /32 VM1
                    10.231.104.3                           0 64520 i
                    RT:64520:10 ET:8 Rmac:00:50:56:6a:68:38
 *>  [5]:[0]:[32]:[10.231.200.11]      # /32 VM2
                    10.231.104.7                           0 64520 i
                    RT:64520:10 ET:8 Rmac:00:50:56:65:18:e5

Route Distinguisher: 10.231.106.1:10   # local VyOS routes
 *>  [5]:[0]:[0]:[0.0.0.0]             # default route — advertised to RC
                    10.231.106.1             0         32768 ?
                    ET:8 RT:64515:10 Rmac:c2:8f:db:73:82:3c
 *>  [5]:[0]:[24]:[10.231.104.0]       # TEP VLAN
                    10.231.106.1             0         32768 ?
                    ET:8 RT:64515:10 Rmac:c2:8f:db:73:82:3c
 *>  [5]:[0]:[24]:[10.231.106.0]       # BGP peering VLAN
                    10.231.106.1             0         32768 ?
                    ET:8 RT:64515:10 Rmac:c2:8f:db:73:82:3c
 # ... remaining connected networks

Displayed 16 out of 16 total prefixes

Każdy wpis /32 w ramach RD 64520:10 reprezentuje jedną maszynę wirtualną w strukturze NSX VPC. Adres Next-hop (10.231.104.3, 10.231.104.7) to adres TEP hosta ESX. Router MAC (Rmac) to adres MAC interfejsu TEP. Po migracji vMotion Kontroler Tras aktualizuje rozgłoszenie za pomocą pakietu GARP — zmiana następnego skoku jest widoczna w ciągu kilku sekund.

Wynik polecenia pokazuje RD jako 64520:10 (z poziomu RC), a nie 10.231.106.10:65000. Parametr Route Distinguisher po stronie Kontrolera Tras jest ustawiany w formacie ASN_RC:VNI — wartość ta pochodzi z konfiguracji połączeń zewnętrznych (External Connectivity) w NSX.

Weryfikacja po stronie ESX — nsxcli

[root@ESXi11:~] nsxcli
esxi11.homelab.int> get gateway
  87b192f1-a8c4-40f7-b9e6-1e905aa259c8  Gateway (Logical Router) UUID
  bdc694b7-d236-47c3-93b0-8d2ba4f04608  Gateway (Logical Router) UUID

esxi11.homelab.int> get gateway 87b192f1-a8c4-40f7-b9e6-1e905aa259c8 forwarding
Mon May 11 2026 UTC 12:04:05.454
Flags: [U: Up], [G: Gateway], [S1|S2|S3: TGW Private|Public|External Route Scope]

                   Network                  Gateway          Type    Interface UUID
===================================================================================
0.0.0.0/0                             10.231.106.1          UGS3    2d08b262-...
10.231.200.8/29                        100.64.0.1           UGS2    a56ae99c-...
100.64.0.0/31                           0.0.0.0             UCI     a56ae99c-...

# S3 = External Route Scope (from RC/gateway)
# S2 = Public Route Scope (VM subnet)

Weryfikacja za pomocą net-vdr (ESX)

net-vdr to niskopoziomowe polecenie systemu ESX, które wyświetla wewnętrzne tabele routingu routera rozproszonego (Distributed Router):

[root@esxi11:~] net-vdr -Il --brief

DR Id      #Lifs   #Routesv4  State   DR UUID
-------    -----   ---------  -----   ---------
0x1        2       3          A       87b192f1-a8c4-40f7-b9e6-1e905aa259c8 (/transit-gateways/default)
0xa        3       4          A       bdc694b7-d236-47c3-93b0-8d2ba4f04608 (/vpcs/test-vpc,default)

[root@esxi11:~] net-vdr -Rl 87b192f1-a8c4-40f7-b9e6-1e905aa259c8
DR 87b192f1-... Route Table
Legend: [S1|S2|S3: TGW Private|Public|External Route Scope]

Destination      GenMask          Gateway          Flags    Ref  UpTime   HitCount
0.0.0.0          0.0.0.0          10.231.106.1     UGS3     1    314380   28
10.231.200.8     255.255.255.248  100.64.0.1       UGS2     1    314380   39
100.64.0.0       255.255.255.254  0.0.0.0          UCI      1    314380   5

# S3 = default route from RC/BGW (10.231.106.1 = VyOS)
# S2 = Public subnet 10.231.200.8/29

Test ping z hosta ESX do maszyny wirtualnej potwierdza prawidłowe działanie ścieżki danych.

[root@ESXi11:~] ping -I vmk0 10.231.200.3
64 bytes from 10.231.200.3: icmp_seq=0 ttl=61 time=1.8 ms
# ttl=61 = 3 hops (VM -> ESX TEP -> VyOS -> ping source)

Typowe problemy

Problem	Prawdopodobna przyczyna (Likely cause)	Gdzie szukać rozwiązania (Where to look)
Sąsiad BGP w stanie Idle	Błędny parametr remote-as, brak trasy do VIP Kontrolera Tras, problem z MTU	`show bgp neighbor 10.231.106.10`, wykonaj ping z adresu źródłowego (update-source)
Brak tras `/32` w VRF po uruchomieniu maszyny wirtualnej	Niezgodność Route Target (RT), błędny identyfikator L3VNI, Kontroler Tras (RC) nie otrzymuje powiadomień	`show bgp l2vpn evpn`, sprawdź logi w NSX Managerze
Maszyna wirtualna nie może wykonać testu ping na zewnątrz	Trasa domyślna nie jest propagowana do hosta ESX, brak konfiguracji NAT	`nsxcli: get gateway forwarding`, `show ip route vrf test`
Trasy RT-5 są widoczne, ale ruch nie przepływa	Problem z MTU w sieci podkładowej (Underlay), nieosiągalny adres VTEP, problem z enkapsulacją	Wykonaj ping z poziomu hosta ESXi do GW-VTEP, uruchom `tcpdump -i vxlan65000`
Stan BGP Active po stronie VyOS	Kontroler Tras (RC) wciąż się uruchamia, błędny adres BGP VIP	Wykonaj procedurę Disable $\rightarrow$ Enable dla sąsiada BGP w interfejsie NSX i odczekaj 2–3 minuty

Podsumowanie

Konfiguracja po stronie VCF jest stosunkowo prosta — wdrożenie Kontrolera Tras, określenie połączeń zewnętrznych oraz konfiguracja DTGW sprowadzają się do przejścia przez kilka ekranów w NSX Managerze. Prawdziwym wyzwaniem pozostaje konfiguracja po stronie bramy BGW. VyOS sprawdza się w testach znakomicie ze względu na szerokie możliwości diagnostyczne i debugowanie za pomocą narzędzi vtysh oraz FRR.

Oto kilka kluczowych kwestii, o których warto pamiętać:

Parametry Route Target muszą być skonfigurowane symetrycznie — to, co Kontroler Tras (RC) eksportuje (64520:10), VyOS musi importować i na odwrót.
Identyfikator L3VNI musi być identyczny po obu stronach.
Wartość MTU sieci podkładowej musi uwzględniać około 50 B narzutu protokołu VXLAN.
Adres źródłowy interfejsu VXLAN (source-address) musi być osiągalny z poziomów adresów TEP hostów ESX.
Utrzymuj identyfikator tabeli VRF w VyOS w zakresie 1–200, jeżeli planujesz stosowanie translacji NAT z użyciem reguł connection-mark.

Artykuł jest tłumaczeniem z bloga: Safekom.pl

Partnerem naszych artykułów jest Broadcom, dostawca rozwiązań VMware