Sillatut toimipisteet tarvitsevat edelleen päätöksen paikallisesta internet-ulostulosta

VLAN-laajennus meni puhtaasti läpi: molempien toimipisteiden isännät näkevät toisensa, tiedostojen jakaminen toimii ja tulostimet vastaavat. Sitten joku pienemmällä toimipisteellä huomaa, että jokainen lataus käyttää toisen toimipisteen internet-linjaa, ja tiketti saapuu kaistanleveysvalituksena. Silta teki täsmälleen sen, mitä siltä pyydettiin. Se kuljetti kehyksiä kahden rakennuksen välillä eikä sillä ollut koskaan mielipidettä siitä, mitä reititintä niiden kehysten pitäisi käyttää internetiin.

Silta kuljettaa kehyksiä, ei päätöksiä

Kerroksen 2 laajennus saa kaksi sijaintia näyttämään yhdeltä broadcast-verkkotunnukselta, joten ARP-pyynnöt, DHCP-lähetykset ja saman aliverkon liikenne kulkevat kaikki tunnelin läpi. Se on koko palvelu, jonka se tarjoaa. Mikään sillassa ei tarkasta kohdeosoitetta, vertaa sitä toimipisteen uplinkiin tai ohjaa liikennettä lähempään ulostuloon. Jokainen asiakas tekee edelleen oman paikallisen tai etäpäätöksensä käyttäen osoitetta ja maskia, jolla se määritettiin.

Laita kaksi reititintä tuohon jaettuun aliverkkoon, ja molemmista tulee uskottava yhdyskäytävä, riippumatta siitä, onko kumpikaan lähellä sitä käyttävää asiakasta.

Miten asiakas valitsee yhdyskäytävänsä

RFC 1122:ssa kuvattu IPv4-päätös on yksinkertainen. Kohde asiakkaan kytketyn aliverkon sisällä tavoitetaan suoraan ARP:lla, ja sen ulkopuolella oleva kohde menee määritettyyn oletusyhdyskäytävään. Siksi saman aliverkon liikenne toimipisteiden välillä voi kulkea sillan läpi ilman minkäänlaista reitittimen osallistumista, ja siksi internet-liikenne riippuu täysin yhdyskäytävän osoitteesta, jonka asiakas sai. Kaksi käyttäytymistä ovat riippumattomia, ja toimiva tiedostojen jakaminen todistaa vain ensimmäisen.

Jos pienen toimipisteen asiakas määritettiin suuren toimipisteen reitittimellä, sen internet-kehykset kulkevat ensin tunnelin läpi ja poistuvat sieltä.

VPN-laitteen oman oletusreitin muuttaminen ei siirrä tuon asiakkaan yhdyskäytävää, koska asiakas ei käytä laitetta reitittimenä lainkaan. Laite tarvitsee myös erillisen reitin kaukaiselle vastaparilleen, jotta näitä kehyksiä kuljettava tunneli pysyy pystyssä, ja näiden kahden sekoittaminen on se tapa, jolla siltalaajennus kaataa oman kuljetuksensa.

Anna DHCP:n ilmaista aiottu ulostulo

Vaihtoehto 3 DHCP-vastauksessa tarjoaa luettelon asiakkaan aliverkon reititinosoitteista etusijajärjestyksessä, ja asiakkaat ottavat yleensä ensimmäisen, joka vastaa. Mekanismi on kunnossa; omistajuus on se, missä suunnitelmat menevät pieleen. Kirjaa, mitä todellinen vuokraus kussakin toimipisteessä tarjoaa, sen sijaan että olettaisit lähimmän DHCP-palvelimen antavan lähimmän yhdyskäytävän.

Aja yhtä koordinoitua jakajaa tai kahta, jotka on nimenomaisesti määritetty samaan käytäntöön, ja anna käytännölle omistaja. Etätoimipisteelle lisätty toinen itsenäinen jakaja ei luo paikallisuutta, se luo kaksi valtuutta samalle broadcast-verkkotunnukselle.

Älä anna yhtä yhdyskäytäväosoitetta kahdelle itsenäisesti aktiiviselle reitittimelle vain siksi, että molempien toimipisteiden asetukset näyttäisivät samanlaisilta. Jaettu virtuaaliosoite sillatun segmentin yli on ensimmäisen hypyn redundanssisuunnittelu omine vaatimuksineen, ja käsin rakennettu versio tuottaa ARP-ristiriitoja, jotka näyttävät ajoittaiselta pakettihäviöltä. Jos sovellus ei todella tarvitse jaettua kerroksen 2 segmenttiä, erilliset reititetyt etuliitteet paikallisilla oletusyhdyskäytävillä ovat yksinkertaisempia ylläpitää ja helpompia selittää häiriön aikana.

Testaa neljä asiaa erikseen

Pyydä neljä havaintoa, älä yhtä. Ota tuore DHCP-vuokraus kussakin toimipisteessä ja kirjaa saatu reititin ja maski. Tavoita saman aliverkon palvelu toisessa toimipisteessä ja varmista, että polku on silta eikä reititetty kierto. Hae jotain julkisesta internetistä kussakin toimipisteessä ja varmista, mikä uplink sen kuljetti. Pudota sitten tunneli ja katso, mikä hajoaa, sillä toimipiste, joka menettää kaiken yhteyden, kun silta pettää, oli riippuvainen kaukaisesta yhdyskäytävästä kenenkään huomaamatta.

Nuo neljä tulosta kertovat, onko sinulla toimipisteiden välinen silta, paikallinen ulostulo vai tahaton paluureitti, ja niiden kerääminen vie kymmenen minuuttia.

Suunnitteluperiaate ei ole glamouria: sillan muodostus päättää tavoitettavuudesta, DHCP päättää yhdyskäytävästä ja laitteen reititystaulu päättää tunnelin omasta polusta. Pidä nämä kolme erillisissä keskusteluissa, sillä yksi muutos, joka yrittää korjata kaikki kolme, rikkoo yleensä kaksi.