VLAN-udvidelsen blev testet rent: værter på begge steder kan se hinanden, fildeling virker, og printere svarer. Så bemærker nogen på det mindre sted, at hver download bruger det andet steds internetlinje, og sagen ankommer som en klage over båndbredde. Broen gjorde præcis, hvad den blev bedt om. Den transporterede frames mellem to bygninger og havde aldrig en holdning til, hvilken router de frames skulle bruge til internettet.

Broen bærer frames, ikke beslutninger

En lag 2-udvidelse får to lokaliteter til at ligne ét broadcast-domæne, så ARP-anmodninger, DHCP-broadcasts og trafik i samme subnet krydser alle tunnelen. Det er hele den tjeneste, den leverer. Intet i broen undersøger en destinationsadresse, sammenligner den med et steds uplink eller styrer trafik mod den nærmeste udgang. Hver klient træffer stadig sin egen lokale eller fjerne beslutning med den adresse og maske, den blev konfigureret med.

Sæt to routere på det delte subnet, og begge bliver plausible gateways, uanset om en af dem er tæt på den klient, der bruger den.

Hvordan en klient vælger sin gateway

Den IPv4-beslutning, der er beskrevet i RFC 1122, er enkel. En destination inde i klientens tilsluttede subnet nås direkte med ARP, og en destination uden for den går til den konfigurerede standardgateway. Derfor kan trafik i samme subnet mellem stederne krydse broen uden nogen routerindblanding, og derfor afhænger internettrafik fuldstændigt af den gatewayadresse, klienten modtog. De to adfærdsmønstre er uafhængige, og en fungerende fildeling beviser kun det første.

Hvis en klient på det lille sted blev konfigureret med det store steds router, krydser dens internetframes først tunnelen og forlader den derfra.

Ændring af VPN-apparatets egen standardrute flytter ikke den klients gateway, fordi klienten slet ikke bruger apparatet som router. Apparatet har også brug for en separat rute til sin fjerne peer, så tunnelen, der bærer disse frames, forbliver oppe, og at blande de to er, hvordan en bro-udvidelse nedlægger sin egen transport.

Lad DHCP udtrykke den tilsigtede udgang

Valgmulighed 3 i et DHCP-svar giver en liste over routeradresser på klientens subnet i præferenceorden, og klienter tager normalt den første, der svarer. Mekanismen er fin; ejerskabet er, hvor design går galt. Notér, hvad en faktisk lease leverer på hvert sted, i stedet for at antage, at den nærmeste DHCP-server udleverer den nærmeste gateway.

Kør én koordineret allokator, eller to der udtrykkeligt er konfigureret til samme politik, og giv politikken en ejer. En anden uafhængig allokator tilføjet på det fjerne sted skaber ikke lokalitet, den skaber to myndigheder for samme broadcast-domæne.

Tildel ikke én gatewayadresse til to uafhængigt aktive routere blot for at få begge steders indstillinger til at se ens ud. En delt virtuel adresse over et broforbundet segment er et design til redundans på første hop med egne krav, og en hjemmelavet version giver ARP-konflikter, der ligner periodisk pakketab. Hvis applikationen ikke reelt har brug for et delt lag 2-segment, er adskilte routedepræfikser med lokale standardgateways enklere at drive og lettere at forklare under en hændelse.

Test de fire ting hver for sig

Bed om fire observationer, ikke én. Tag en ny DHCP-lease på hvert sted, og notér den router og maske, den fik. Nå en tjeneste i samme subnet på det andet sted, og bekræft, at vejen er broen og ikke en routet omvej. Hent noget fra det offentlige internet på hvert sted, og bekræft, hvilket uplink der bar det. Slip derefter tunnelen, og se hvad der brækker, for et sted, der mister al forbindelse, når broen fejler, var afhængigt af den fjerne gateway, uden at nogen lagde mærke til det.

De fire resultater fortæller, om du har en bro mellem stederne, en lokal udgang eller en tilfældig backhaul, og de tager ti minutter at indsamle.

Designprincippet er uglamourøst: broen afgør nåbarhed, DHCP afgør gatewayen, og rutetabellen på apparatet afgør tunnelens egen vej. Hold de tre i separate samtaler, for en enkelt ændring, der forsøger at rette alle tre, ødelægger normalt to.

Relaterede artikler