IPv6-käytäntöreititys, kun kaksi ylälinkkiä jakaa osoitteen fe80::1

Sinulla on kaksi ylälinkkiä, ja ip -6 route show näyttää saman seuraavan hypyn molemmissa: default via fe80::1 dev uplink0 ja default via fe80::1 dev uplink1. Kyse ei ole päällekkäisten osoitteiden ristiriidasta, eikä paljaan seuraavan hypyn fe80::1 kopioiminen käytäntötauluun kerro ytimelle, mitä linkkiä tarkoitit. Varsinainen kysymys on kapeampi kuin oire antaa ymmärtää: tarvitseeko toinen taulu yhden linkin vai molemmat, ja mikä pitää ne reitit elossa uudelleenkäynnistyksen jälkeen. Kolme ehtoa, järjestyksessä tarkistettuna, ratkaisee suurimman osan.

Sama fe80::1 on kaksi eri naapuria

Link-local-osoitteet on rajattu yhteen linkkiin, joten fe80::1 ei ole yksi kahdesti tulostettu osoite; se on kaksi naapuria, jotka sattuvat jakamaan jälkiliitteen. Vyöhykeindeksi on tapa, jolla isäntä sanoo, kumpaa se tarkoittaa, joten fe80::1%uplink0 ja fe80::1%uplink1 ovat ytimelle eri kohteita, eikä tuo jälkiliite koskaan matkaa etäreitittimelle. RFC 4007 kuvaa tämän takana olevan vyöhykemallin, ja siksi käytäntötaulun on kuljetettava laite jokaisen link-local-seuraavan hypyn mukana.

VPN-kokoonpanon generaattori, joka kopioi numeerisen vyöhyke-ID:n isännästä mallipohjaan, kohtelee paikallista kontekstia kuin se olisi osa osoitetta, ja tiedosto, jonka se kirjoittaa, on väärä jokaisella koneella, jonka liittymien nimet tai indeksit poikkeavat. Käytäntötaulu ei myöskään sulata kahta linkkiä yhdeksi: reititetty VPN välittää paketteja verkkojen välillä, mutta se ei kuljeta etäisen Ethernet-naapurin link-local-identiteettiä tunnelin läpi, joten link-local-liikenne pysyy omalla linkillään.

Poista laite, ja reitistä tulee kirjoittamaton. ip -6 route add default via fe80::1 table 200 ei voi ratkaista yhdyskäytävää, ja iproute2 hylkää sen viestillä Error: Nexthop has invalid gateway. Lisää dev uplink0, ja komento onnistuu, koska laite kiinnittää seuraavan hypyn toiseen näistä kahdesta naapurista. Se, mitä laite ei voi kertoa sinulle, on se, onko uplink0 oikea linkki tälle taululle, ja toisesta isännästä kopioitu reitti tuo mukanaan sen isännän liittymien nimet, ja juuri siitä todelliset virheet syntyvät.

Ehto yksi: yksi linkki vai kaksi taulussa

Aloita siitä, mihin toinen ylälinkki on tarkoitettu. Jos molemmat linkit kantavat samaa liikennettä ja toinen on varalla, vaihtoehtoisen taulun pitäisi pitää molemmat yhdyskäytävät eri mittareilla: samat kohteet, yksi suosittu polku, yksi ilmeinen toinen valinta. Jos ylälinkit ovat olemassa siksi, että eri liikenteen on lähdettävä eri operaattoreiden kautta, tai siksi, että kyse on jaetusta tunnelista, jossa osa liikenteestä ohittaa VPN:n ja loput pysyvät sisällä, kaksi linkkiä ei kuulu lainkaan samaan tauluun. Ne kuuluvat kahteen tauluun, jotka sääntö valitsee, ja sääntö valitsee taulun, ei tunnelia: ohittava liikenne merkitään ennen reititystä, ja merkintä on se, mikä lähettää sen toiseen tauluun.

Jälkimmäisessä tapauksessa sääntö päättää, milloin taulua kysytään, ja reitti päättää, minne paketti menee sen jälkeen:

ip -6 rule add fwmark 0x2 table 201
ip -6 route add default via fe80::1 dev uplink1 metric 100 table 201
ip -6 route add 2001:db8:100::/48 dev uplink1 metric 100 table 201
ip -6 route show table 201

Kumpikaan objekti ei korvaa toista, ja pelkän oletusreitin sisältävä taulu voi silti epäonnistua yhdyskäytävänsä ratkaisemisessa. Jos lisäys hylätään tai reitti on olemassa mutta käyttökelvoton, laita kyseisen liittymän kytketty etuliite samaan tauluun tai merkitse hyppy onlink, kun etuliite reititetään muualle. Yllä olevassa lohkossa 2001:db8:100::/48 edustaa juuri tuota kytkettyä etuliitettä uplink1:ssä, ei mielivaltaista kohdetta. fwmark-sääntö kuluttaa vain merkinnän, joka jonkin muun on asetettava, joko edelleenlähetyspolun nftables- tai iptables-säännöstä tai pistokkeen SO_MARK:sta, joten ilman merkinnän lähdettä kopioitu lohko ei vastaa mitään.

Ehto kaksi: mittarit eivät havaitse kuollutta operaattoria

Mittari on mieltymys olemassa olevien reittien välillä, ei terveystarkistus. Kun operaattori katkeaa, ydin poistaa kyseisen laitteen reitit ja toinen oletusreitti ottaa vallan. Kun kaapeli pysyy kytkettynä ja sen takana oleva operaattori kuolee, taulussa mikään ei muutu: suosittu reitti on asennettu, naapuriin päästään kerroksessa 2, ja paketit lähtevät mustaan aukkoon. Jos tällä erolla on merkitystä kokoonpanollesi, automaattisen siirtymän on tultava jostakin, joka testaa polun ja poistaa reitin, oli se sitten reititysdaemon tai pieni skripti, joka poistaa ja asentaa merkinnän uudelleen.

Varmista valinta sen jälkeen, kun taulu on rakennettu, ja varmista se niin kuin ydin sen näkee. ip -6 route get 2001:db8:100::1 tulostaa reitin, jota käytettäisiin, mukaan lukien laitteen ja valitun lähdeosoitteen, ja se noudattaa käytäntösääntöjä. Väärään ylälinkkiin kuuluva lähdeosoite on tavallinen merkki siitä, että sääntö täsmäsi aiemmin kuin odotit.

Ehto kolme: päätä, kuka omistaa pysyvyyden

Komennolla ip -6 route add lisätty reitti säilyy uudelleenkäynnistykseen tai kunnes jokin huuhtoo sen. Reitittimen ilmoituksista opittu oletusreitti kantaa elinajan ja reititin voi vetää sen pois, kun taas käsin lisätty oletusreitti ei koskaan vanhene itsestään. Näiden kahden sekoittaminen samassa taulussa on tapa, jolla vanhentunut pysyvä reitti alkaa ohittaa tuoreen ilmoitetun, kauan sen jälkeen kun kuvaamasi ylälinkki lakkasi olemasta.

Valitse yksi omistaja taulua kohden. Jos verkkohallinta tai reititysdaemon hallitsee liittymää jo, kuvaile käytäntöreitti siellä ja jätä ydin rauhaan. Jos teet sen skriptillä, tee skriptistä idempotentti ja kirjoita purku samaan aikaan, koska tarvitset sitä ensimmäisen huonon muutoksen aikana:

ip -6 route flush table 201
ip -6 rule del fwmark 0x2 table 201

Reitittimessä, joka välittää muiden isäntien puolesta, tarkista net.ipv6.conf.all.forwarding ennen kuin syytät taulua. Kun edelleenlähetys on pois päältä, toiseen verkkoon osoitetut paketit pudotetaan, olipa taulu 201 kuinka oikea tahansa.

Kirjaa suunnittelu, jotta seuraava voi auditoida sen

Luettelo, joka tallentaa vain fe80::1, heittää pois ne kentät, joilla on merkitystä. Kirjaa kohde, seuraava hyppy, laite, taulu ja mittari yhteen, sekä mistä kukin reitti tuli — ilmoitettu, hallinnan luoma vai staattinen. Kun joku myöhemmin kysyy, kuljettaako toinen ylälinkki todella liikennettä, se kirjaus vastaa kysymykseen arvailematta.

Ennen kuin julistat taulun valmiiksi, vahvista naapuri komennolla ip -6 neigh show dev uplink0, lue ip -6 rule show uudelleen järjestysonnettomuuksien varalta ja testaa liikenteellä, joka vastaa sääntöä, eikä pingillä, joka ottaa oletusreitin. Kytke sitten yksi ylälinkki tarkoituksella alas ja katso, mille reitille ydin putoaa; vastauksen pitäisi vastata sitä, jonka kirjoitit muistiin.