Brobundna platser behöver fortfarande ett beslut om lokal internetutgång

VLAN-utökningen gick rent igenom: värdar på båda platserna ser varandra, fildelning fungerar och skrivare svarar. Sedan lägger någon på den mindre platsen märke till att varje nedladdning använder den andra platsens internetlinje, och ärendet kommer in som ett klagomål på bandbredd. Bron gjorde precis det den ombads att göra. Den transporterade ramar mellan två byggnader och hade aldrig en åsikt om vilken router dessa ramar borde använda för internet.

Bron bär ramar, inte beslut

En utökning på lager 2 får två platser att se ut som en enda broadcastdomän, så ARP-förfrågningar, DHCP-broadcasts och trafik i samma subnät går alla genom tunneln. Det är hela den tjänst den levererar. Ingenting i bron granskar en destinationsadress, jämför den med en plats uplänk eller styr trafik mot den närmaste utgången. Varje klient fattar fortfarande sitt eget lokala eller avlägsna beslut med den adress och mask den konfigurerades med.

Sätt två routrar på det delade subnätet och båda blir rimliga gateways, oavsett om någon av dem är nära klienten som använder den.

Hur en klient väljer sin gateway

IPv4-beslutet som beskrivs i RFC 1122 är enkelt. En destination inom klientens anslutna subnät nås direkt, med ARP, och en destination utanför går till den konfigurerade standardgatewayen. Därför kan trafik i samma subnät mellan platserna korsa bron utan något routerinblandning, och därför beror internettrafiken helt på den gatewayadress klienten fick. De två beteendena är oberoende, och en fungerande fildelning bevisar bara det första.

Om en klient på den lilla platsen konfigurerades med den stora platsens router, korsar dess internetramar först tunneln och går ut därifrån.

Att ändra VPN-enhetens egen standardrutt flyttar inte den klientens gateway, eftersom klienten inte använder enheten som router alls. Enheten behöver också en separat rutt till sin avlägsna peer så att tunneln som bär dessa ramar hålls uppe, och att blanda ihop de två är hur en bro-utökning tar ner sin egen transport.

Låt DHCP uttrycka den avsedda utgången

Alternativ 3 i ett DHCP-svar ger en lista över routeradresser i klientens subnät, i preferensordning, och klienter tar vanligtvis den första som svarar. Mekanismen är bra; ägarskapet är där design går fel. Notera vad en faktisk lease levererar på varje plats i stället för att anta att den närmaste DHCP-servern delar ut den närmaste gatewayen.

Kör en samordnad allokator, eller två som uttryckligen är konfigurerade för samma policy, och ge policyn en ägare. En andra oberoende allokator som läggs till på den avlägsna platsen skapar inte lokalitet, den skapar två myndigheter för samma broadcastdomän.

Tilldela inte en gatewayadress till två oberoende aktiva routrar bara för att inställningarna på båda platserna ska se identiska ut. En delad virtuell adress över ett brobundet segment är en design för redundans på första hoppet med egna krav, och en hemmagjord version ger ARP-konflikter som ser ut som intermittent paketförlust. Om applikationen inte verkligen behöver ett delat lager 2-segment är separata routade prefix med lokala standardgateways enklare att drifta och lättare att förklara vid en incident.

Testa de fyra sakerna var för sig

Be om fyra observationer, inte en. Ta en ny DHCP-lease på varje plats och notera routern och masken den fick. Nå en tjänst i samma subnät på den andra platsen och bekräfta att vägen är bron och inte en routad omväg. Hämta något från det publika internetet på varje plats och bekräfta vilken uplänk som bar det. Släpp sedan tunneln och se vad som går sönder, för en plats som förlorar all anslutning när bron fallerar var beroende av den avlägsna gatewayen utan att någon märkte det.

De fyra resultaten berättar om du har en bro mellan platserna, en lokal utgång eller en oavsiktlig backhaul, och det tar tio minuter att samla in dem.

Designprincipen är inte glamorös: bron avgör nåbarhet, DHCP avgör gatewayen, och routingtabellen på enheten avgör tunnelns egen väg. Håll de tre i separata samtal, för en enda ändring som försöker fixa alla tre förstör vanligtvis två.