Reittien uudelleenjako-Osa 1

ccie r/s ccnp R / S Sep 25, 2018

Johdanto reittien Uudelleenjakamiseen

kunnes on olemassa yksi reititysprotokolla, joka hallitsee niitä kaikkia, tarvitaan useita reititysprotokollia rauhanomaisesti rinnakkain samassa verkossa. Ehkä A-yhtiö johtaa OSPF: ää ja B-yhtiö EIGRP: tä, ja nämä kaksi yhtiötä yhdistyvät. OSPF: n tiedossa olevat reitit on mainostettava EIGRP: tä käyttävässä verkon osassa ja päinvastoin, kunnes uusi TIETOTEKNIIKKAHENKILÖSTÖ suostuu käyttämään vakiomuotoista reititysprotokollaa (jos suostuu).

tällainen skenaario on mahdollinen reittien uudelleenjaon ansiosta, ja se on tämän blogikirjoituksen painopiste. Muita syitä reittien uudelleenjakamiseen voivat olla: oman yrityksesi verkon eri osat ovat eri hallinnollisessa valvonnassa; haluat mainostaa reittejä palveluntarjoajallesi BGP: n kautta; tai ehkä haluat muodostaa yhteyden liikekumppanin verkostoon. Harkitse seuraavaa perustopologiaa.

yksinkertaisessa topologian näyttelyssä haluamme OSPF: n ja EIGRP: n mainostavan toisilleen tuntemiaan reittejä. Tätä käsitettä kutsutaan keskinäiseksi reittien uudelleenjaoksi. Koska reitittimellä R2 on yksi liitäntä OSPF: n autonomisessa järjestelmässä (AS) ja yksi liitäntä EIGRP AS: ssä, se vastaa reittijaon suorittamisesta.

Seed Metrics

ensisijainen haaste, johon törmäämme jakaessamme reittejä eri reititysprotokollien välillä, on eri lähestymistavat, joilla reititysprotokollat mittaavat niiden mittareita. Esimerkiksi OSPF käyttää kustannusmittaria, joka perustuu kaistanleveyteen, kun taas EIGRP käyttää oletusarvoisesti kaistanleveyteen ja viiveeseen perustuvaa mittaria, mutta saattaa myös harkita luotettavuutta ja/tai kuormitusta (ja käyttää jopa MTU-arvoa katkaisijana). Kysymys ei ole niin yksinkertainen kuin valuuttojen muuntaminen kahden maan välillä, koska siinä skenaariossa on suhde, joka kuvaa kahden valuutan suhdetta. Reittien uudelleenjaossa tällaista suhdetta ei kuitenkaan ole. Mitä teemme?

me ylläpitäjinä voimme määrittää metrijärjestelmän, joka on annettu yhdeltä AS: ltä tuleville reiteille, jotka jaetaan edelleen toiseen AS: ään. Jos emme vaivaudu määrittämään manuaalisesti metriikkaa, jota käytetään reittien uudelleenjakamiseen, käytetään siemenmittaria. Seuraavassa taulukossa on esitetty eri reititysprotokollien käyttämät siemenmittarit.

reititysprotokolla

Oletussiemenmittari

tutkimusajanjakso

Infinity

EIGRP

Infinity

OSPF

20 (tai 1, kun BGP-reittejä jaetaan uudelleen)

BGP

käyttää IGP: n metristä arvoa

edellä olevan taulukon perusteella voimme nähdä, että oletuksena OSPF: ään jaetulle reitille annetaan metriikka 20, ellei reittiä jaeta uudelleen OSPF: ään BGP: stä, jolloin reitille annettaisiin metrinen arvo 1. Mielenkiintoista, sekä RIP että EIGRP ovat oletuksena seed metrics infinity, mikä tarkoittaa, että kaikki reititysprotokollien uudelleenjaettu reitti pidetään saavuttamattomissa, oletuksena, ja siksi ei mainosteta muille reitittimille. BGP kuitenkin jakaa uudelleen interior gateway protocol (IGP) – protokollasta opitun reitin käyttäen kyseisen reitin alkuperäistä metrijärjestelmää.

Peruskokoonpanoesimerkki

varmasti, on paljon muutakin pohdittavaa koskien reittien uudelleenjakoa, kuten reitityssilmukat, joita voi tapahtua, kun meillä on useampi kuin yksi reititin yhdistämässä autonomisia järjestelmiämme, tai miten valikoivasti suodatamme tiettyjä reittejä uudelleenjaosta, mutta saamme kaiken tämän tulevissa blogikirjoituksissa. Nyt, Let ’ s saada käsitys siitä, miten suorittaa perus reitti uudelleenjako kokoonpano. Harkitse edellinen topologia, tällä kertaa verkko – ja rajapintatietoja lisätään:

tässä topologiassa reititin R2 opettelee reitit R1: stä OSPF: n kautta ja R3: sta EIGRP: n kautta, kuten seuraavassa R2: lla annetun Näytä ip-reittikomennon tulosteessa esitetään:

router R1 ja router R3 eivät kuitenkaan ole oppineet reittejä, koska router R2 ei vielä suorita reittien uudelleenjakoa. Tämä näkyy R1: llä ja R3: lla annetun Näytä ip-reittikomennon ulostulossa:

lisätään nyt reitityksen uudelleenjako asetukset reitittimeen R2. Vahvistaaksemme aikaisempaa väitettä, että EIGRP: hen uudelleen jaettujen reittien siemenmittari on ääretön, emme aluksi määritä mitään mittareita ja annamme siemenmittareiden vaikuttaa.

uudelleenjako-komento annettiin reitittimen konfigurointitilassa kullekin reititysprotokollalle, eikä metrijärjestelmää määritelty. On myös mielenkiintoista huomata, mitä kun annoimme edellämainitun EIGRP 1-komennon uudelleenjakoon, emme sisällyttäneet aliverkon avainsanaa komentoon, mikä aiheuttaa sekä classful että classfuless-verkkojen uudelleenjaon OSPF: ään. Kuitenkin, kuten nähdään lähtö alla, aliverkon avainsana lisättiin automaattisesti meille:

vaikka tämä tapa ottaa aliverkkojen avainsanan automaattisesti lisätään näkyy viimeaikaisissa versioissa Cisco IOS, jotkut vanhemmat versiot Cisco IOS eivät automaattisesti sisällä aliverkkojen avainsana, ja saatat joutua lisäämään sen manuaalisesti uudelleenjako komento.

Katsotaanpa nyt reitittimien R1 ja R3 IP-reititystaulukoista, mitä reittejä he ovat oppineet (ja eivät ole oppineet).

yllä oleva lähtö osoittaa meille, että reititin R2 onnistuneesti uudelleen reitit tiedossa EIGRP OSPF, jotka sitten oppinut reititin R1. Huomaa, että reitittimeen R1 kuuluvien reittien metriikka on 20, joka on OSPF: n siemenmetri. Router R3 ei kuitenkaan oppinut uusia reittejä, sillä kun router R2 jakoi reitit uudelleen EIGRP: hen, se käytti EIGRP: n seed metric of infinityä (eli saavuttamatonta). Tämän vuoksi kyseisiä reittejä ei mainostettu router R3: lle.

tämän ongelman ratkaisemiseksi meidän on määritettävä metri reiteille, jotka jaetaan uudelleen EIGRP: hen. On kolme ensisijaista tapaa, joilla voimme määrittää ei-oletusmittarin reiteille, jotka jaetaan uudelleen reititysprotokollaksi.

  1. Aseta oletusmittari kaikille reititysprotokollille, jotka jaetaan uudelleen tiettyyn reititysprotokollaan.
  2. Aseta metriikka osaksi uudelleenjako-käskyä.
  3. Aseta metri reittikartan avulla.

ensimmäisen vaihtoehdon havainnollistamiseksi määritetään metrijärjestelmän avulla kaikki reitit, jotka jaetaan uudelleen EIGRP: hen.

edellä mainitussa esimerkissä käytettiin Kontekstisensitiivistä ohjetta, jolla osoitettiin metrijärjestelmän jokainen komponentti reiteille, jotka jaettiin uudelleen EIGRP: hen. Lopullinen käsky oli kuitenkin default-metric 1000000 1 255 1 1500. Jos asetamme oletusmittarin OSPF: lle, olisimme voineet käyttää komentoa, kuten default-metric 30, osoittaaksemme OSPF: n hinnan 30 reitille, jotka jaetaan uudelleen OSPF: ään. Tässä esimerkissä määritimme kuitenkin vain oletusmittarin EIGRP: lle. Katsotaanpa nyt tarkistaa IP reititys taulukko router R3 nähdä, jos OSPF reitit on onnistuneesti mainostettu osaksi EIGRP.

onnistui! Router R3 on oppinut reitit peräisin OSPF AS. Tiedämme, että reitit tulivat alun perin EIGRP: n ulkopuolelta, koska niissä on EX-koodi.

toinen vaihtoehto metriikan asettamiseksi uudelleenjaetuille reiteille oli määrittää metriikka osana uudelleenjako-käskyä, jossa määritellään eri metriikka eri reititysprotokollille, jotka jaetaan uudelleen reititysprosessiin. Tämän lähestymistavan havainnollistamiseksi poistetaan edelliset oletusmittarikomennot reitittimestä R2 ja annetaan uudelleenjako-komento, joka määrittää annettavan metriikan.

jos nyt palaamme reitittimeen R3, saamme saman tuloksen kuin ennen:

kolmas vaihtoehto metrijärjestelmän asettamiseksi uudelleenjaetuille reiteille oli reittikartta. Reittikartat ovat erittäin tehokkaita ja niitä voidaan käyttää monenlaisiin konfiguraatioihin. Periaatteessa ne voivat täsmätä tiettyyn liikenteeseen ja asettaa yhden tai useamman parametrin (esim.next-hop IP-osoitteen) kyseiselle liikenteelle. Meidän asiayhteydessä kuitenkin, aiomme vain käyttää reitti-kartta määrittää metrinen arvo, ja me sitten soveltaa reitti-kartta uudelleenjako komento. Seuraava esimerkki näyttää, miten voimme poistaa edellisen rejective-komennon reitittimestä R2, luoda reittikartan ja antaa sitten uuden rejective-komennon, joka viittaa reittikarttaamme:

yllä olevassa esimerkissä, poistettuamme olemassa olevan uudelleenjako-komennon, loimme reittikartan nimeltä SET-METRIC-DEMO. Tämä oli hyvin yksinkertainen reittikartta, jonka ei tarvinnut vastata mitään liikennettä. Sitä käytettiin vain metrijärjestelmän asettamiseen. Kuitenkin, tulevassa blogikirjoitus, näemme, että reitti-kartta voidaan käyttää antaa meille enemmän valvoa reittien uudelleenjako. Nykyisessä esimerkissämme reittikarttaa sovellettiin sitten uuteen uudelleenjako-komentoomme. Jälleen, tämä antaa meille saman tuloksen näkökulmasta router R3: n IP reititys taulukko:

OSPF E1 vs. E2 Routes

ennen kuin päätämme tämän ensimmäisen blogikirjoituksen reittien Uudelleenjakosarjaamme, tarkastellaan vielä kerran reitittimen R1 IP-reititystaulukkoa:

huomaa, että jokainen OSPF: ään uudelleen jaetuista reiteistä näkyy router R1: n IP-reititystaulukossa E2-koodilla. Kuitenkin, siellä on myös mahdollisuus ottaa E1-koodi, jotka molemmat osoittavat, että reitti on peräisin ulkopuolelta reitittimen OSPF AS. Mitä eroa näillä koodeilla on?

E2-koodi ilmaisee, että reitillä on uudelleenjakoa suorittavan reitittimen osoittama metriikka, jota kutsutaan autonomiseksi Järjestelmäreitittimeksi (Asbr). Tämä tarkoittaa, että ei ole väliä kuinka monta ylimääräistä reitittimet sisällä OSPF koska meidän täytyy ylittää, jotta saada takaisin ASBR, metriikka pysyy samana kuin se oli, kun ASBR uudelleen. Kun reitit jaetaan uudelleen OSPF: ään, nämä reitit ovat oletuksena näitä ulkoisia tyypin 2 (E2) reittejä.

E1-koodi osoittaa, että reitin metriikka koostuu asbr: n määräämistä alkuperäisistä kustannuksista sekä asbr: n saavuttamiseen tarvittavista kustannuksista. Tämä viittaa siihen, että E1-reitti on yleensä tarkempi, ja itse asiassa se onkin. Vaikka, ottaa Koodi E1 ei tarjoa meille mitään etua yksinkertainen topologia kuin meillä, jossa reititin R1 on vain yksi polku päästä ASBR (eli R2), ja jossa on vain yksi tapa EIGRP reitit ruiskutetaan meidän OSPF AS (eli kautta reitittimen R2).

jos haluamme jakaa E1-reitit uudelleen OSPF: ksi E2-reittien sijaan, se voidaan toteuttaa uudelleenjako-komennolla. Seuraavassa esimerkissä poistamme OSPF-reititysprosessia varten olemassa olevan uudelleenjako-komennon reitittimessä R2, ja asetamme uudelleen uudelleenjako-komennon, jossa täsmennetään, että haluamme ulkoisen tyypin 1 (E1) mittareita sovellettavan uudelleenjaettuihin reitteihin.

katsotaanpa tarkistaa IP reititys taulukko reitittimen R1 nähdä, jos asiat ovat muuttuneet tämän uuden uudelleenjako komento annetaan reitittimeen R2.

huomaa yllä olevassa tulosteessa, että OSPF: ään uudelleen jaettujen reittien koodi on E1 eikä oletuskoodi E2. Huomaa myös, että tämän vuoksi näiden reittien metriikka on hieman korkeampi. Erityisesti router R2 jakoi EIGRP-opitut reitit edelleen OSPF: ään käyttäen OSPF: n siemenmittaria 20. Kuitenkin, on OSPF kustannukset 1 saada reitittimestä R1 reitittimeen R2. Koska uudelleen jaetut reitit oli määritetty E1-reiteiksi, näiden reittien kustannukset router R1: n näkökulmasta ovat router R1: n alun perin määräämät kustannukset, jotka olivat 20, sekä R1: n R2: een pääsystä aiheutuvat kustannukset, joka on 1, kokonaiskustannukset 21.

Yhteenveto

tässä blogikirjoituksessa pohdimme reittien uudelleenjaon tarvetta ja tutustuimme perusasetukseen. Keskustelimme reititysprotokollan siemenmetriikan (joka voi olla ääretön) vaikutuksesta reittien uudelleenjakoa tehtäessä, ja näimme kolme tapaa hallinnollisesti määrittää metriikka uudelleenjaetuille reiteille. Lopuksi vertasimme OSPF: n ulkoisen tyypin 1 (E1) ja ulkoisen tyypin 2 (E2) reittejä. Tulevassa blogikirjoituksessa rakennamme tämän topologian varaan ja pohdimme, miten voimme valikoivasti suodattaa reitit, joita jaetaan uudelleen. Sitten, vielä toinen blogikirjoitus, tarkastelemme suunnittelu kysymyksiä, jotka liittyvät topologioita useita kohtia uudelleenjako kahden autonomisen järjestelmän.

Toivottavasti nautitte tästä ensimmäisestä kurkistuksesta reittien uudelleenjaon maailmaan. Jos teit, auta levittämään sanaa jakamalla tämä viesti muille. Tässä linkki, jonka voit jakaa:

https://www.kwtrain.com/blog/route-redistribution-part-1

seuraavaan kertaan,

Kevin Wallace, CCIEx2 (R / S ja yhteistyö) #7945

Vastaa

Sähköpostiosoitettasi ei julkaista.