OSPF:n maksimimetriikka: haaran transitin välttäminen haaraa poistamatta

Kaksi toimistoa yhdistyvät haaran kautta, jonka pitäisi kuljettaa omaa liikennettään ja hyvin vähän muuta. Haara tarvitsee reitit molempiin kohteisiin, eikä kummankaan kohteen pitäisi suosia sitä niiden välisenä polkuna. Haaran poistaminen topologiasta ratkaisisi transitin ongelman ja rikkoisi vaatimuksen, koska haaran on edelleen päästävä molempiin kohteisiin ja molempien kohteiden on edelleen päästävä haaraan.

Haluat mieltymyksen, joka ilmaistaan reititysprotokollassa ja joka jättää haaran täysin tavoitettavaksi ja tekee siitä huonon valinnan kaikelle sen kautta kulkevalle. Käy ongelma läpi siinä järjestyksessä kuin reitittimet sen näkevät.

Aloita polusta, jota haluat välttää

Piirrä topologia niin kuin protokolla sen näkee, ei niin kuin kaavio sen näkee. Mitkä liitännät muodostavat naapuruuksia, mitkä ovat samassa alueessa ja mitkä noista naapuruuksista kuljettaisivat liikennettä kahden toimiston välillä, jos haaraa suosittaisiin? Nämä ovat kolme erillistä kysymystä, eikä kaavio vastaa luotettavasti yhteenkään niistä.

Etsi sitten vaihtoehtoinen polku. Jos toimistojen välinen ainoa reitti kulkee haaran kautta, mikään metriikka ei voi siirtää liikennettä pois siltä, koska liikenteellä ei ole minne mennä. Varareitti ei ole tämän suunnittelun yksityiskohta; se on edellytys. Toinen polku, joka on olemassa vain paperilla, ei riitä.

show ip ospf neighbor
show ip ospf interface brief
show ip route 10.40.0.0

Nämä kolme näkymää vastaavat eri kysymyksiin: kuka on naapuri, mitkä liitännät osallistuvat ja millä kustannuksella, ja minkä polun laite valitsee juuri nyt. Tunnelikäyttöönotto lisää neljännen: viiva kaaviossa ei ole todiste siitä, että naapuruus muodostui sen kautta, eikä muodostunut naapuruus ole todiste siitä, että edelleenlähetys seuraa samaa polkua. Tunneliratkaisuissa tämä aukko näkyy useimmin.

Mitä maksimimetriikka ilmoittaa

RFC 6987 kuvaa reitittimen, joka ilmoittaa ei-stub-linkkinsä suurimmalla linkin metriikalla, joka määritellään muotoon 0xffff. Reititin kuvaa edelleen itsensä ja linkkinsä; se vain hinnoittelee ne alueen yläpäähän, joten jokainen muu reititin laskee sen kautta kulkevan polun kalliiksi.

Tämä on router-LSA:n muutos, ei topologian poisto. Ero on tärkeä: router-LSA:n tyhjentäminen vetää takaisin itse topologiatiedon, mikä voi vetää takaisin myös ne suhteet, joita tarvitaan reitittimen ja sen takana olevien etuliitteiden saavuttamiseen. Ilmoituksen pitäminen ja sen hinnan nostaminen säilyttää nuo suhteet. Siinä on koko ero tämän tekniikan ja poistamisen välillä.

Myöskään RFC 6987 -mekanismilla ei ole mitään tekemistä aluetyyppien tai nimetyn reitittimen valinnan kanssa. Stub-alue estää yhden linkkitilan ilmoitusten luokan aluerajalla, ja stub-reititin hinnoittelee omat linkkinsä. Samankaltaisia sanoja, asiaankuulumatonta koneistoa.

Miksi tavoitettavuus säilyy ja transit ei

Muilla reitittimillä on edelleen reitti haaran yhdistettyihin etuliitteisiin, koska haara ilmoittaa ne edelleen ja linkit ovat edelleen olemassa. Se mikä muuttuu, on minkä tahansa haaran kautta muualle kulkevan polun kokonaiskustannus. Etuliitteet eivät liiku; vain reitittimen ylityksen hinta muuttuu.

Liikenteelle, jonka lähde tai kohde on haara itse, kallis linkki on edelleen ainoalla järkevällä polulla, joten sitä käytetään. Kahden toimiston väliselle liikenteelle vaihtoehtoinen polku voittaa nyt kustannuksissa, ja haara putoaa edelleenlähetyspäätöksestä katoamatta topologiasta. Kaksi suuntaa, kaksi eri vastausta, ja molemmat ovat mekanismi toimimassa.

Tämä on se käyttäytyminen, joka pitää todentaa eikä olettaa. Katso router-LSA, jonka haara tuottaa, sitten polku, jonka toinen reititin valitsee haaran takana olevalle kohteelle ja toisen toimiston kohteelle. Kahden vastauksen pitäisi erota, ja jos ne eivät eroa, metriikan muutos ei saavuta sitä päätöstä, jota luulet.

Viimeisen polun ongelma

Sama RFC on selkeä, ettei tekniikka kiellä käyttöä. Kun vaihtoehtoinen polku pettää, reitittimet palaavat haaran kautta kulkevalle kalliille polulle, koska se on edelleen kelvollinen polku ja protokolla suosii kallista reittiä reitin puuttumisen sijaan.

Onko tällainen paluu hyväksyttävää, on käytäntökysymys, johon sinun on vastattava ennen käyttöönottoa. Pienellä ylälinkillä oleva haara, joka yhtäkkiä kuljettaa toimistojen välistä liikennettä, voi olla huonompi kuin katkos, ja se voi olla juuri se, mitä haluat huoltokatkon aikana. Molemmat vastaukset ovat hyväksyttäviä; vaikeneminen ei.

Jos vaatimus on tiukka kielto eikä mieltymys, pelkkä metriikkasuunnittelu ei tuota sitä. Tarvitset edelleenlähetyksen pakotuksen, joka vastaa tarkoitusta, sekä määritellyn käyttäytymisen tapaukselle, jossa liikennettä saapuu silti. Polun ilmoittaminen käyttökelpoiseksi ja liikenteen pudottaminen sen jälkeen luo mustan aukon, jota on vaikeampi diagnosoida kuin reitityssilmukkaa.

OSPFv3:n osalta RFC käsittelee R-bittiä eri tapana sulkea pois transitiin osallistuminen. Älä oleta, että se perii saman viimeisen polun käyttäytymisen kuin maksimimetriikkatekniikka, äläkä kopioi asetuksia kahden osoiteperheen välillä ikään kuin ne olisivat sama ominaisuus.

Todista se normaaleissa ja vikaantuneissa olosuhteissa

Testaa kahdesti: kerran molempien polkujen ollessa käytettävissä ja kerran suositun polun ollessa poistettu. Ensimmäinen testi osoittaa mieltymyksen toimivan, ja toinen osoittaa, mitä verkko tekee, kun mieltymystä ei voida noudattaa. Toisen testin väliin jättäminen jättää tärkeän puoliskon tutkimatta.

show ip ospf database router 10.0.0.3
show ip route 172.20.8.0
traceroute 172.20.8.1

Tietokantanäkymä näyttää ilmoitetun metriikan, reittihaku näyttää valitun seuraavan hypyn ja jäljitys näyttää, minne paketit todella menivät. Kun nämä kolme täsmäävät, sinulla on todennettu suunnittelu eikä oikealta näyttävä kokoonpano.

Palauta sitten suosittu polku ja vahvista, että haara palaa kuljettamaan vain omaa liikennettään. Palautusvaihe kuuluu testiin eikä siivoamiseen, koska suunnittelu, joka toimii vain seuraavaan muutokseen asti, ei ole suunnittelu. Kirjoita molemmat tulokset muistiin, myös paluu, koska jälkimmäinen on vastaus, jota joku tarvitsee kolmelta aamuyöllä.