L2 VPN kontra L3-tunnel: fem kontroller innan du brygger en plats

Du brygger en plats för att något verktyg insisterar på att den måste ligga i samma nätverk, och tre veckor senare läser du switchloggar klockan två på natten. Den sortens magkänsla avgör alldeles för många Ethernet-over-IP-länkar. Bara en skillnad spelar egentligen roll här: om hela ramar färdas från ände till ände, eller bara IP-paket. Kör de fem kontrollerna nedan i ordning och stanna vid den första som fallerar.

Kontrollera vad applikationen faktiskt lägger på ledningen

Innan något produktnamn kommer in i diskussionen, fånga en minut av trafiken som måste korsa länken: tcpdump -i eth0 -nn -e 'not ip'. Flaggan -e skriver ut länkskiktets header, och det är precis den del en routad tunnel kastar. Om fångsten blir tom talar din applikation IP och en L3-tunnel transporterar den oförändrad. Om det ändå dyker upp ramar, notera EtherType, eftersom 0x0806 är ARP, 0x88cc är LLDP, och ett leverantörsvärde betyder oftast ett upptäcktsprotokoll utan IP-fallback. Det är punkten där ett vanligt tun gränssnitt inte längre räcker.

Upprepa fångsten på den bortre sidan också. En ram som bara finns inne i en hosts virtuella switch är ingen anledning att sträcka ut en broadcastdomän över ett WAN.

Kontrollera om upptäckten måste korsa länken

En routad tunnel har inget delat segment, så ingenting adresserat till en grupp når andra änden. ARP, DHCP-broadcast, mDNS på 224.0.0.251, SSDP och NetBIOS-namnförfrågningar förutsätter alla en länk som flera värdar hör samtidigt.

Fråga vilka av dem applikationen faktiskt är beroende av, och om det redan finns en proxy för dem. DHCP-relay, mDNS-spegling och statiska ARP-poster tar bort en beroendepunkt var, och var och en är ännu en tjänst som måste köras och övervakas. När två eller tre återstår är bryggning det ärliga svaret.

Kontrollera vad den extra headern kostar dig

Ramar behöver någonstans att bo, så allt du skickar får en andra headerstack runt sig. I ett VXLAN-overlay betyder det en yttre IP-header, en UDP-header och en 8-byte VXLAN-header, vilket knuffar en full 1,500-byte nyttolast förbi banans MTU på en vanlig 1,500-byte internetlänk. OpenVPN i tap läge lägger på sin egen overhead i samma riktning. Utan lägre MTU på insidan får du en länk som svarar på ping och stoppar vid den första stora överföringen.

Räkningen stannar inte vid header-byten. Broadcast och multicast som en switch hanterar i hårdvara går nu över WAN:et, och varje bryggd plats ärver samma adressplan, DHCP-område och beteende med dubblerade adresser. Det gör länken betydligt svårare att granska än en routad pool med ett prefix per plats.

Räkna innan du väljer. Ett upptaget segment replikerat till tre platser kan flytta mer broadcasttrafik än de filöverföringar det byggdes för.

Kontrollera vilken sorts L2 VPN du blir erbjuden

Själva termen är tvetydig, och tvetydigheten avgör vem som transporterar din trafik. Ibland beskriver den nyttolasten: Ethernet-ramar inuti IP, skickade över internet som vilken annan tunnel som helst, som VXLAN, ZeroTier och OpenVPN tap läge gör. Ibland beskriver den en köpt tjänst: en carrier Ethernet-krets eller en MPLS-pseudotråd som förbinder två platser inom ett leverantörsnät.

Båda ger dig ett segment, så applikationen kan inte skilja dem, men den operativa skillnaden är stor. Ett overlay lämnar ansvaret för MTU, kryptering och den underliggande vägen hos dig. En operatörtjänst tar över det och tar betalt för det, och den kommer inte alls att routa dina ramar över det publika internetet. Vilken du vill ha beror på om de två platserna delar en operatör eller bara delar ett företag.

Kontrollera den billigare lösningen innan du brygger

De flesta förfrågningar om en bryggd länk kommer från en enda trasig namnsökning, inte från ett protokoll som verkligen behöver ramar. Skicka först resolvern och sökdomänen genom den routade tunneln: dhcp-option DNS 10.8.0.1 tillsammans med dhcp-option DOMAIN internal.example i en OpenVPN-serverkonfiguration löser ett förvånansvärt antal av dem. En lokal vidarebefordrare på den bortre sidan gör samma jobb utan att flytta någon broadcasttrafik.

Om ett äldre verktyg fortfarande misslyckas, sätt det verktyget bakom en proxy eller en hoppvärd på målsegmentet. En enda TCP-vidarebefordrare är billigare att driva än ett bryggt WAN.

Stäng beslutet i ordning: bär trafiken en icke-IP EtherType, måste upptäckten korsa, kan MTU:n svälja de extra headrarna, är en leverantörskrets faktiskt tillgänglig, och misslyckades den routade lösningen av en anledning du kan namnge? Ett nej vid vilket steg som helst avslutar diskussionen till förmån för tunneln du redan har. Arkivera fångsten och EtherType-listan tillsammans med ändringsloggen, för nästa person kommer att ställa samma fråga och vill inte upprepa mätningen.