Statické a dynamické směrování. Dynamický směrovací protokol OSPF

Síť Lift Me Up se spolu se svými zaměstnanci rozrůstá široko daleko. Údržba IT infrastruktury byla převedena na samostatnou speciálně vytvořenou organizaci „Link me Ap“.
Právě onehdy byly zakoupeny další čtyři pobočky v různých městech a investoři objevili nové dimenze pohybu výtahů. A síť se rozrostla ze čtyř routerů na deset najednou. Současně se počet podsítí nyní zvýšil z 9 na 20, nepočítaje spojení point-to-point mezi routery. A zde vyvstává otázka řízení celé této ekonomiky v plném růstu. Souhlasíte, ruční přidávání tras do všech sítí na každém z uzlů není moc zábavné.
Situaci komplikuje fakt, že síť v Kaliningradu již má vlastní adresování a běží na ní dynamický směrovací protokol EIGRP.
Takže dnes:

• Rozumíme teorii dynamických směrovacích protokolů.
• Implementace protokolu OSPF do sítě Lift Me Up
• Nakonfigurujeme přenos (přerozdělení) tras mezi OSPF a EIGRP
• V této verzi přidáváme sekci Úkoly. V průběhu článku je identifikují následující ikony:

Teorie dynamických směrovacích protokolů

Pokud se například v takové síti přeruší spojení mezi R2 a R3, pak pakety z R1 stejně půjdou do R2, kde budou zničeny, protože je není kam poslat.

Dynamické směrovací protokoly se během několika sekund (nebo dokonce milisekund) dozvědí o problémech v síti a znovu sestaví své směrovací tabulky a ve výše uvedeném případě budou pakety odesílány po aktuální trase.

Další důležitý bod - vyvažování dopravy. Dynamické směrovací protokoly tuto funkci podporují téměř ihned po vybalení a nemusíte ručně přidávat redundantní trasy jejich výpočtem.

No, zavedení dynamického směrování značně usnadňuje škálování sítě. Když přidáte nový prvek do sítě nebo podsítě na stávajícím routeru, stačí provést několik kroků, aby vše fungovalo a pravděpodobnost chyby byla minimální, zatímco informace o změnách jsou okamžitě distribuovány do všech zařízení. Přesně totéž lze říci o změnách globální topologie.

Všechny směrovací protokoly lze rozdělit do dvou velkých skupin: externí ( EGP- Exterior Gateway Protocol) a interní ( IGP- Protokol vnitřní brány). K vysvětlení rozdílů mezi nimi potřebujeme termín „autonomní systém“. V obecném smyslu je autonomní systém (směrovací doména) skupina směrovačů pod společnou kontrolou.
V případě naší aktualizované sítě bude AS vypadat takto:

V rámci autonomního systému se tedy používají interní směrovací protokoly a pro vzájemné propojení autonomních systémů se používají externí protokoly. Na druhé straně se interní směrovací protokoly dělí na vzdálenost-vektor(RIP, EIGRP) a Stav odkazu(OSPF, IS-IS). V tomto článku nebudeme kopat do mrtvol a nebudeme se dotýkat protokolů RIP a IGRP kvůli jejich pokročilému věku, stejně jako IS-IS kvůli absenci v PT.

Základní rozdíly mezi těmito dvěma typy jsou následující:
1) typ informací, které si směrovače vyměňují: směrovací tabulky pro Distance-Vector a topologické tabulky pro Link State,
2) proces výběru nejlepší trasy,
3) množství informací o síti, které si každý router „uchová v hlavě“: Distance-Vector zná pouze své sousedy, Link State má představu o celé síti.

Jak vidíme, počet směrovacích protokolů je malý, ale stále ne jeden nebo dva. A co se stane, když na routeru spustíte několik protokolů současně? Může se ukázat, že každý protokol bude mít svůj vlastní názor na to, jak se nejlépe dostat do konkrétní sítě. A když máme nakonfigurované i statické cesty? Komu dá router přednost a čí trasu přidá do routovací tabulky? Odpověď na tuto otázku souvisí s novým pojmem: administrativní vzdálenost (na náš vkus spíše průměrný pauzovací papír z anglického Administrative distance, ale lepší si nevymysleli). Administrativní vzdálenost je celé číslo od 0 do 255, vyjadřující „míru důvěry“ routeru v této trase. Čím menší AD, tím větší důvěra. Zde je označení takové důvěry z pohledu společnosti Cisco:

V dnešním článku si rozebereme OSPF a EIGRP. S prvním se setkáte všude a neustále a druhý je velmi dobrý v sítích, kde je přítomno pouze zařízení Cisco.
Každý z nich má své výhody a nevýhody. Můžeme říci, že EIGRP vítězí nad OSPF, ale všechny výhody jsou kompenzovány jeho proprietární povahou. EIGRP je proprietární protokol Cisco a nikdo jiný jej nepodporuje.
Ve skutečnosti má EIGRP mnoho nevýhod, ale ty nejsou široce zahrnuty v populárních článcích. Zde je jen jeden z problémů: SIA

Pojďme tedy začít.

OSPF

Zvažte jeho fungování na příkladu takové zjednodušené sítě:

Na úvod je třeba říci, že aby mohlo mezi routery vzniknout přátelství (sousedství), musí být splněny následující podmínky:

1) OSPF musí být nakonfigurován stejným způsobem ahoj interval na těch routerech, které jsou vzájemně propojené. Výchozí hodnota je 10 sekund v sítích pro vysílání, jako je Ethernet. Toto je druh zprávy KeepAlive. To znamená, že každých 10 sekund každý router odešle paket Hello svému sousedovi, aby řekl: „Ahoj, jsem naživu“
2) Musí být stejné Mrtvý interval na ně. Obvykle se jedná o 4 intervaly Hello – 40 sekund. Pokud během této doby není od souseda přijato Hello, je považováno za nedostupné a PANIC zahájí proces obnovy místní databáze a zasílání aktualizací všem sousedům,
3) Vzájemně propojená rozhraní musí být in stejná podsíť,
4) OSPF umožňuje snížit zatížení CPU routerů rozdělením autonomního systému do zón. Tak tady čísla zón musí také odpovídat
5) Každý router účastnící se procesu OSPF má svůj vlastní unikátní identifikátor - ID routeru. Pokud se o to nestaráte, router jej vybere automaticky na základě informací o připojených rozhraních (nejvyšší adresa se vybírá z rozhraní aktivních v době spuštění procesu OSPF). Ale zase dobrý inženýr má vše pod kontrolou, takže se většinou vytvoří rozhraní Loopback, kterému je přidělena adresa s maskou /32 a právě jemu je přiděleno Router ID. To je vhodné pro údržbu a odstraňování problémů.
6) Musí odpovídat velikosti MTU

1) V klidu. Stav OSPF - DOLŮ
V této krátké chvíli se na síti nic neděje – všichni mlčí.

2) Vítr se zvedne: router posílá Hello pakety na multicastovou adresu 224.0.0.5 ze všech rozhraní běžících na OSPF. Tyto zprávy mají TTL jednu, takže je obdrží pouze routery ve stejném segmentu sítě. R1 přechází do stavu INIT.

V balíčcích jsou obsaženy následující informace:

• ID routeru
• ahoj interval
• Mrtvý interval
• Sousedé
• maska ​​podsítě
• ID oblasti
• Priorita routeru
• Adresy DR a BDR routerů
• Heslo pro autentizaci

A odešle na R1 novou zprávu Hello, již v unicastu, která obsahuje Router ID tohoto routeru a všichni jeho sousedé jsou uvedeni v seznamu Neigbors. Mezi dalšími sousedy v tomto seznamu je Router ID R1, to znamená, že R2 jej již považuje za souseda.

3) Přátelství. Když R1 obdrží tuto zprávu Hello od R2, prolistuje seznam sousedů a najde v něm své vlastní Router ID, přidá R2 do svého seznamu sousedů.

Nyní jsou R1 a R2 vzájemnými sousedy - to znamená, že mezi nimi byl vytvořen vztah sousedství a router R1 přechází do stavu DVA CESTY.

Obecné rady pro všechny úkoly:

I když hned neznáte odpověď a řešení, zkuste se zamyslet nad tím, čeho se týká stav problému:
- Na jaké funkce, nastavení protokolu?
- Jsou tato nastavení globální nebo spojená s konkrétním rozhraním?
Pokud příkaz neznáte nebo jste ho zapomněli, takové uvažování vás s největší pravděpodobností zavede do správného kontextu, kde můžete jednoduše uhodnout nebo si zapamatovat, jak nastavit, co je v úloze požadováno prostřednictvím výzvy na příkazovém řádku.
Zkuste tímto způsobem přemýšlet, než půjdete na Google nebo na nějaký web hledat příkazy.

Než přejdeme k testování záložních odkazů a rychlosti, udělejme ještě jednu užitečnou věc.
Pokud bychom měli možnost zachytit provoz na FE0 / 0.2 rozhraní msk-arbat-gw1, které se dívá směrem k serverům, pak bychom viděli, že každých 10 sekund letí Hello zprávy do neznáma. Není s kým odpovědět Dobrý den, není s kým navazovat sousedské vztahy, takže nemá smysl pokoušet se odtud posílat zprávy.
Vypnutí je velmi jednoduché:
msk-arbat-gw1(config)#router OSPF 1
msk-arbat-gw1(config-router)#passive-interface fastEthernet 0/0.2

Takový příkaz je nutné zadat pro všechna rozhraní, která rozhodně nemají sousedy OSPF (včetně těch směrem k internetu).
Ve výsledku bude váš obrázek vypadat takto:

*Nevím, jak to, že jsi ještě nebyl zmatený*

Tento příkaz navíc zvyšuje bezpečnost – nikdo z této sítě se nebude vydávat za router a nepokusí se nás úplně zlomit.

Nyní pojďme k té zábavnější části – testování.
V konfiguraci OSPF na všech routerech v Sibiřském prstenu není nic složitého - můžete to udělat sami.
A poté by obrázek měl vypadat takto:
msk-arbat-gw1#sh ip soused OSPF

172.16.255.32 1 FULL/DR 00:00:31 172.16.2.2 FastEthernet0/1.4
172.16.255.48 1 FULL/DR 00:00:31 172.16.2.18 FastEthernet0/1.5
172.16.255.80 1 FULL/BDR 00:00:36 172.16.2.130 FastEthernet0/1.8
172.16.255.112 1 FULL/BDR 00:00:37 172.16.2.197 FastEthernet1/0.911

Petersburg, Kemerovo, Krasnojarsk a Vladivostok jsou přímo propojeny.

msk-arbat-gw1#zobrazit cestu IP

172.16.0.0/16 je variabilně podsíťován, 25 podsítí, 6 masek



S 172.16.2.4/30 přes 172.16.2.2



O 172.16.2.160/30 přes 172.16.2.130, 00:05:53, FastEthernet0/1.8
O 172.16.2.192/30 přes 172.16.2.197, 00:04:18, FastEthernet1/0.911





S 172.16.16.0/21 přes 172.16.2.2
S 172.16.24.0/22 ​​​​přes 172.16.2.18
O 172.16.24.0/24 přes 172.16.2.18, 00:24:03, FastEthernet0/1.5
O 172.16.128.0/24 přes 172.16.2.130, 00:07:18, FastEthernet0/1.8
O 172.16.129.0/26 přes 172.16.2.130, 00:07:18, FastEthernet0/1.8

O 172.16.255.32/32 přes 172.16.2.2, 00:24:03, FastEthernet0/1.4
O 172.16.255.48/32 přes 172.16.2.18, 00:24:03, FastEthernet0/1.5
O 172.16.255.80/32 přes 172.16.2.130, 00:07:18, FastEthernet0/1.8
O 172.16.255.96/32 přes 172.16.2.130, 00:04:18, FastEthernet0/1.8
přes 172.16.2.197, 00:04:18, FastEthernet1/0.911
O 172.16.255.112/32 přes 172.16.2.197, 00:04:28, FastEthernet1/0.911

msk-arbat-gw1#traceroute 172.16.128.1

1 172.16.2.130 35 ms 8 ms 5 ms

Nyní trháme rozhraní mezi Moskvou a Krasnojarskem a uvidíme, jak dlouho bude spojení obnoveno.
Za méně než 5 sekund se všechny směrovače dozvěděly o incidentu a přepočítaly své směrovací tabulky:
msk-arbat-gw1(config-subif)#do sh ip ro 172.16.128.0

Známý přes "OSPF 1", vzdálenost 110, metrika 4, typ intra area
Poslední aktualizovat od 172.16.2.197 na FastEthernet1/0.911, před 00:00:53
Bloky deskriptoru směrování:
* 172.16.2.197, z 172.16.255.80, 00:00:53 před, přes FastEthernet1/0.911
Metrika trasy je 4, podíl návštěvnosti je 1

Vld-gw1#sh IP cesta 172.16.128.0
Směrovací záznam pro 172.16.128.0/24
Známý přes "OSPF 1", vzdálenost 110, metrika 3, typ intra area
Poslední aktualizace z 172.16.2.193 na FastEthernet1/0, před 00:01:57
Bloky deskriptoru směrování:
* 172.16.2.193, z 172.16.255.80, 00:01:57 před, přes FastEthernet1/0
Metrika trasy je 3, podíl návštěvnosti je 1

Msk-arbat-gw1#traceroute 172.16.128.1
Chcete-li operaci zrušit, zadejte escape sekvenci.
Trasování trasy k 172.16.128.1

1 172.16.2.197 4 ms 10 ms 10 ms
2 172.16.2.193 8 ms 11 ms 15 ms
3 172.16.2.161 15 ms 13 ms 6 ms

To znamená, že nyní provoz dosahuje Krasnojarsku tímto způsobem:

Jakmile zvednete link, routery se znovu připojí, vymění si své báze, přepočítají nejkratší cesty a zadají je do routovací tabulky.
Video vše objasňuje. doporučuji seznámit se.

Po konfiguraci OSPF na routerech v sibiřském kruhu jsou všechny sítě, které se nacházejí za routerem na centrále v Moskvě (msk-arbat-gw1), přístupné do Chabarovsku dvěma cestami (přes Krasnojarsk a přes Vladivostok). Ale protože kanál přes Krasnojarsk je lepší, musíte změnit výchozí nastavení tak, aby Chabarovsk používal kanál přes Krasnojarsk, když je k dispozici. A do Vladivostoku přešel, jen kdyby se něco stalo s kanálem do Krasnojarsku.

Jako každý dobrý protokol podporuje OSPF autentizaci – dva sousedé mohou ověřit přijaté zprávy OSPF před navázáním sousedského vztahu. Necháme to na samostatné studium – je to celkem jednoduché.

EIGRP

Proč je tedy EIGRP dobrý?
- snadná konfigurace
- rychlé přepínání na předem vypočítané náhradní trasa
- vyžaduje méně prostředků routeru (ve srovnání s OSPF)
- sumarizace trasy na libovolném routeru (v OSPF pouze na ABR\ASBR)
- vyvažování provozu na nerovných trasách (OSPF pouze na ekvivalentních trasách)

Rozhodli jsme se přeložit jeden z blogových příspěvků Ivana Pepelnyaka, který se zabývá řadou populárních mýtů o EIGRP:
- "EIGRP je hybridní směrovací protokol." Pokud si dobře pamatuji, začalo to první prezentací EIGRP před mnoha lety a je obecně chápáno jako „EIGRP vzal to nejlepší z protokolů link-state a distance-vector“. To absolutně není pravda. EIGRP nemá žádné funkce stavu propojení. Správně by bylo říci „EIGRP je pokročilý směrovací protokol vzdálenost-vektor“.
- "EIGRP je protokol vzdálenostních vektorů." Není to špatné, ale také ne úplně pravda. EIGRP se liší od ostatních DV ve způsobu, jakým zpracovává ztracené trasy (nebo stoupající metrické trasy). Všechny ostatní protokoly pasivně čekají na aktualizace informací od souseda (některé, jako je RIP, dokonce blokují cestu, aby zabránily směrovacím smyčkám), zatímco EIGRP je aktivnější a požaduje informace sám.
- "EIGRP je obtížné implementovat a udržovat." Není pravda. Kdysi bylo obtížné správně implementovat EIGRP ve velkých sítích s nízkorychlostními spoji, ale přesně do okamžiku, kdy byly zavedeny stub routery. S nimi (stejně jako s několika opravami DUAL algoritmu) je to stejně dobré jako OSPF.
"Stejně jako protokoly LS, EIGRP uchovává tabulku topologie tras, které si vyměňuje." Je úžasné, jak je to nepravdivé. EIGRP vůbec netuší, co je za nejbližšími sousedy, zatímco protokoly LS znají přesně topologii celé oblasti, ke které jsou připojeny.
- "EIGRP je DV protokol, který funguje jako LS." Pěkný pokus, ale stále naprosto špatný. Protokoly LS vytvářejí směrovací tabulku pomocí následujících kroků:
- každý router popisuje síť na základě informací, které má k dispozici lokálně (její spojení, podsítě, na kterých se nachází, sousedé, které vidí) prostřednictvím paketu (nebo několika) nazývaných LSA (v OSPF) nebo LSP (IS-IS)
- LSA jsou distribuovány po síti. Každý router musí přijmout každé LSA vytvořené v jeho síti. Informace přijaté z LSA se zanesou do tabulky topologie.
- každý router nezávisle analyzuje svou topologickou tabulku a spouští algoritmus SPF pro výpočet nejlepších tras ke každému z ostatních routerů
Chování EIGRP se těmto krokům ani zdaleka nepodobá, takže není jasné, proč se proboha „chová jako LS“

Jediné, co EIGRP dělá, je ukládat informace přijaté od souseda (RIP okamžitě zapomene, co nelze použít tento moment). V tomto smyslu je to obdoba BGP, která také vše ukládá do BGP tabulky a vybírá nejlepší trasa odtamtud. Tabulka topologie (obsahující všechny informace přijaté od sousedů) poskytuje EIGRP výhodu oproti RIP – může obsahovat informace o alternativní (momentálně nepoužívané) trase.

Každý proces EIGRP udržuje 3 tabulky:
- Tabulka sousedů (neighbor table), která obsahuje informace o "sousedech", tzn. další routery přímo připojené k aktuálnímu a účastnící se výměny tras. Lze zobrazit pomocí příkazu zobrazit ip sousedy eigrp
- Tabulka topologie sítě, která obsahuje informace o trasách přijatých od sousedů. Sledujeme jako tým zobrazit topologii ip eigrp
- Směrovací tabulka (routing table), na základě které router rozhoduje o předávání paketů. Procházet zobrazit ip trasu

Metriky.
Pro posouzení kvality konkrétní cesty používají směrovací protokoly určité číslo, které odráží její různé charakteristiky nebo soubor charakteristik – metriku. Zohledněné charakteristiky mohou být různé – od počtu routerů na dané trase až po aritmetický průměr zatížení všech rozhraní na trase. Pokud jde o metriku EIGRP, cituji Jeremyho Cioaru: „Nabyl jsem dojmu, že tvůrci EIGRP poté, co se na svůj výtvor kriticky podívali, usoudili, že vše je příliš jednoduché a funguje dobře. A pak přišli s metrickým vzorcem, který by každého přiměl říct „WOW, to je opravdu složité a vypadá to profesionálně“. Podívejte se na úplný vzorec pro výpočet metriky EIGRP: (K1 * bw + (K2 * bw) / (256 - zatížení) + K3 * zpoždění) * (K5 / (spolehlivost + K4)), ve kterém:
- bw není jen šířka pásma, ale (10 000 000/nejmenší šířka pásma na trase v kilobitech) * 256
- zpoždění není jen zpoždění, ale součet všech zpoždění na cestě k desítky mikrosekund* 256 (zpoždění zobrazení rozhraní, zobrazení topologie ip eigrp a dalších příkazů se zobrazuje v mikrosekundách!)
- K1-K5 jsou koeficienty, které zajišťují, že jeden nebo druhý parametr bude „zahrnut“ ve vzorci.

děsivé? bylo by to, kdyby to všechno fungovalo tak, jak je napsáno. Ve skutečnosti jsou ze všech 4 možných členů vzorce standardně použity pouze dva: bw a delay (koeficienty K1 a K3 = 1, zbytek je nula), což to značně zjednodušuje – tato dvě čísla jednoduše sečteme (zatímco nezapomeňte, že se stále počítají podle jejich vzorců). Je důležité si zapamatovat následující: metrika se počítá podle nejhorší propustnost po celé délce trasy.
Pokud K5=0, použije se následující vzorec: Metrický = (K1 * ž.hm. + (K2 * ž.hm.) / (256 - zatížení) + (K3 * zpoždění)

Zajímavá věc se stala s MTU: poměrně často můžete najít informace, že MTU souvisí s metrikou EIGRP. Hodnoty MTU jsou skutečně přenášeny během výměny trasy. Ale jak vidíme z celého vzorce, o MTU tam není žádná zmínka. Faktem je, že tento indikátor je brán v úvahu ve spíše specifických případech: pokud například router musí zahodit jednu z tras, které jsou ekvivalentní z hlediska jiných charakteristik, vybere si tu s nižší MTU. I když, ne všechno je tak jednoduché (viz komentáře).

Pro každou podsíť, o které EIGRP ví, je na každém routeru z řad sousedů router Následník, přes který jde podle protokolu nejlepší (s nižší metrikou) cesta do této podsítě. Kromě toho může mít podsíť také jednu nebo více alternativních tras (sousední směrovač, kterým taková trasa prochází, se nazývá proveditelný nástupce). EIGRP je jediný směrovací protokol, který si pamatuje náhradní cesty (jsou v OSPF, ale jsou obsaženy takříkajíc v „raw formě“ v tabulce topologie – ještě je musí zpracovat algoritmus SPF), což dává je to plus v rychlosti: jakmile protokol zjistí, že hlavní trasa (přes nástupce) je nedostupná, okamžitě se přepne na alternativní. Aby se router stal proveditelným nástupcem trasy, jeho AD musí být menší než FD nástupce této trasy (proto potřebujeme znát AD). Toto pravidlo se používá, aby se zabránilo směrování kruhů.

Napadl vás předchozí odstavec? Materiál je obtížný, takže ještě jednou na příkladu. Máme následující síť:

Z pohledu R1 je R2 nástupcem pro podsíť 192.168.2.0/24. Aby se R4 stal FS pro tuto podsíť, potřebuje, aby jeho AD bylo menší než FD pro tuto trasu. Máme FD ((10000000/1544)*256)+(2100*256) =2195456, R4 má AD (z jeho pohledu je to FD, tedy kolik ho stojí dostat se do této sítě) = ( (10000000/100000)*256)+(100*256)=51200. Vše se sbíhá, R4 má méně AD než FD trasy, stává se FS. *tady je mozek takhle a říká: “FUCK”*. Nyní se podíváme na R3 - oznámí svou síť 192.168.1.0/24 sousedovi R1, který o tom zase řekne svým sousedům R2 a R4. R4 neví, že R2 ví o této podsíti a rozhodne se mu to říct. R2 předává informaci, že má přístup přes R4 do podsítě 192.168.1.0/24 dále do R1. R1 přísně kouká na FD trasy a AD, kterým se R2 chlubí (který, jak je z diagramu snadno pochopitelné, bude jednoznačně větší než FD, protože ho také obsahuje) a odveze ho tak, že ano nezahrávat se s nejrůznějšími nesmysly. Taková situace je poměrně nepravděpodobná, ale za určitých okolností k ní může dojít, například při vypnutí mechanismu „rozděleného horizontu“. A nyní k pravděpodobnější situaci: představte si, že R4 je připojen k síti 192.168. )+(2000*256)= 46226176. To je více než FD pro tuto trasu, takže R4 nebude proveditelným nástupcem. To ale neznamená, že EIGRP tuto cestu vůbec nevyužije. Jen přepnutí na něj trvá déle (o tom později).

Sousedství

Pokud je příjemce se vším spokojen, přidá odesílatele do seznamu svých sousedů a pošle mu (již unicast) aktualizační paket, který obsahuje seznam všech jemu známých tras (alias full-update). Odesílatel poté, co takový paket přijal, udělá totéž. K výměně tras používá EIGRP protokol Reliable Transport Protocol (RTP, nezaměňovat s protokolem Real-time Transport Protocol používaným v IP telefonii), což znamená potvrzení doručení, takže každý ze směrovačů po obdržení aktualizačního paketu odpoví ack paket (zkratka z acknowledgment - potvrzení). Takže sousedský vztah je navázán, routery se od sebe navzájem naučily komplexní informace o trasách, co dál? Poté budou pokračovat v odesílání paketů multicast hello, aby potvrdili, že jsou online, a v případě změny topologie budou aktualizovat pakety obsahující pouze informace o změnách (částečná aktualizace).

Nyní zpět k předchozímu schématu modemu.

R2 z nějakého důvodu ztratil kontakt s 192.168.2.0/24. Nemá žádné alternativní cesty do této podsítě (tj. žádný FS). Jako každý zodpovědný router s EIGRP se chce znovu připojit. Za tímto účelem začne rozesílat speciální zprávy (dotazové balíčky) všem svým sousedům, kteří zase nenajdou požadovanou trasu doma, zeptají se všech svých sousedů atd. Když vlna požadavků zasáhne R4, oznámí to: „Počkejte chvíli, mám cestu do této podsítě! Špatné, ale aspoň něco. Všichni na něj zapomněli, ale já si to pamatuji." To vše zabalí do odpovědního paketu a pošle sousedovi, od kterého obdržel požadavek (dotaz), a dále v řetězci. To vše samozřejmě zabere více času než pouhý přechod na Feasible Successor, ale nakonec získáme připojení k podsíti.

A nyní nebezpečný okamžik: možná jste již dali pozor a upozornili jste po přečtení momentu o tomto fanouškovském mailingu. Pád jednoho rozhraní způsobí v síti něco podobného jako broadcast storm (samozřejmě ne v takovém měřítku, ale přesto) a čím více routerů bude, tím více prostředků bude vynaloženo na všechny tyto požadavky a odpovědi. Ale pořád je to polovina problémů. Je možná horší situace: představte si, že routery zobrazené na obrázku jsou pouze součástí velké a distribuované sítě, tzn. některé se mohou nacházet mnoho tisíc kilometrů od naší R2, na špatné kanály A tak dále. Problém je tedy v tom, že po odeslání dotazu sousedovi musí router čekat na odpověď od něj. Nezáleží na tom, jaká je odpověď, ale musí přijít. I když router již obdržel kladnou odpověď, jelikož v našem případě nemůže tuto trasu zprovoznit, dokud nebude čekat na odpověď na všechny své požadavky. A žádosti, možná někde jinde na Aljašce, se potulují. Tento stav trasy se nazývá přilepený-in-aktivní. Zde se musíme seznámit s pojmy, které odrážejí stav trasy v EIGRP: aktivní \ pasivní trasa. Obvykle jsou zavádějící. Zdravý rozum říká, že aktivní znamená, že trasa je „aktivní“, povolená, funkční. Zde je to ale naopak: pasivní znamená „vše v pořádku“ a aktivní stav znamená, že daná podsíť je nedostupná a router aktivně hledá jinou cestu, posílá dotaz a čeká na odpověď. Takže zaseknutý aktivní stav (zaseknutý v aktivním stavu) může trvat až 3 minuty! Po uplynutí této doby router ukončí sousedský vztah se sousedem, od kterého nemůže čekat na odpověď, a může použít novou cestu přes R4.

Příběh, ze kterého mrazí krev v krvi síťového inženýra. 3 minuty výpadku nejsou vtip. Jak se můžeme v této situaci vyhnout infarktu? Existují dvě cesty ven: sčítání tras a tzv. stub-configuration.

Obecně lze říci, že existuje ještě jedna cesta ven a nazývá se filtrování tras. Ale toto je tak obsáhlé téma, že jsem připraven napsat o něm samostatný článek a tentokrát už jsme dostali polovinu knihy. Proto dle vašeho uvážení.

Druhou možností je konfigurace pahýlu. Obrazně řečeno, stub znamená „konec cesty“, „slepá ulička“ v EIGRP, tj. dostat se do nějaké podsítě, která není připojena přímo k takovému routeru se musíte vrátit. Router nakonfigurovaný jako stub nebude předávat provoz mezi podsítěmi, které se naučil z EIGRP (jinými slovy, které jsou označeny písmenem D v show ip route). Jeho sousedé mu také nebudou posílat pakety dotazů. Nejběžnějším případem použití jsou topologie hub-and-spoke, zejména ty s redundantními odkazy. Vezměme si takovou síť: vlevo - pobočky, vpravo - hlavní web, hlavní kancelář atd. Redundantní odkazy pro odolnost proti chybám. Spuštěn EIGRP s výchozím nastavením.

A nyní „pozor, otázka“: co se stane, když R1 ztratí spojení s R4 a R5 ztratí LAN? Provoz z podsítě R1 do podsítě hlavní kanceláře bude sledovat trasu R1->R5->R2(nebo R3)->R4. Bude to účinné? Ne. Trpí tím nejen podsíť za R1, ale i podsíť za R2 (nebo R3), kvůli nárůstu objemu provozu a jeho důsledkům. Právě pro takové a takové situace byl vynalezen útržek. Za routery ve větvích nejsou žádné další routery, které by vedly do jiných podsítí, to je „konec cesty“, jen dále dozadu. S lehkým srdcem je tedy můžeme nakonfigurovat jako pahýly, což nás za prvé ušetří problému s výše popsanou „křivou cestou“ a za druhé zahlcení paketů dotazů v případě ztráty trasy.

Existují různé režimy provozu routeru stub, nastavují se příkazem eigrp stub:

R1(config)#router eigrp 1
R1(config-router)#eigrp stub?
připojeno Inzerujte připojené trasy
leak-map Povolí dynamické prefixy založené na leak-mapě
pouze příjem Nastavte IP-EIGRP jako souseda pouze pro příjem
redistributed Inzerovat redistribuované trasy
Inzerujte statické trasy
souhrn Inzerujte souhrnné trasy

Důležité body v teorii EIGRP, které nebyly zahrnuty v článku:

• Autentizaci souseda lze nakonfigurovat v EIGRP
• koncept elegantního vypnutí

praxe EIGRP

Tady je ale smůla – EIGRP už na nich běží jako dynamický směrovací protokol. Navíc adresování koncových uzlů je z úplně jiné podsítě - 10.0.0.0/8. Změnili jsme všechny ostatní parametry (adresy odkazů, adresy rozhraní zpětné smyčky), ale několik tisíc adres lokální sítě se servery, tiskárnami, přístupovými body - práce ne na pár hodin - bylo odloženo na později a v plánu IP jsme vyhrazená podsíť 172.16 pro Kaliningrad pro budoucnost .32.0/20.

V současné době využíváme tyto sítě:

Jak je tento zázrak nastaven? Na první pohled nekomplikované:
router eigrp 1
síť 172.16.0.0 0.0.255.255
síť 10.0.0.0

V EIGRP lze nastavit obrácenou masku, čímž se označí užší rámečky, nebo nenastavit, pak bude vybrána standardní maska ​​pro tuto třídu (16 pro třídu B - 172.16.0.0 a 8 pro třídu A - 10.0.0.0)

Takové příkazy jsou zadávány na všech směrovačích autonomního systému. AS je určeno číslem v příkazu eigrp routeru, to znamená, že v našem případě máme AS #1. Toto číslo musí být stejné na všech routerech (na rozdíl od OSPF).

V EIGRP je ale vážný háček: ve výchozím nastavení je povolena automatická sumarizace tras ve formě třídy (ve verzích IOS až 15).
Porovnejme směrovací tabulky na třech kaliningradských směrovačích:

Síť 10.0.0.1/24 je připojena ke klgr-center-gw1 a ví o tom:
klgr-center-gw1:
10.0.0.0/8 je variabilně podsíťován, 2 podsítě, 2 masky
D 10.0.0.0/8 je souhrn, 00:35:23, Null0
C 10.0.0.0/24 je připojen přímo, FastEthernet1/0

Ale neví o 10.0.1.0/24 a 10.0.2.0/24/

Klgr-balt-gw1 ví o svých dvou sítích 10.0.1.0/24 a 10.0.2.0/24, ale síť 10.0.0.0/24 někam schoval.
10.0.0.0/8 je variabilně podsíťován, 3 podsítě, 2 masky
D 10.0.0.0/8 je souhrn, 00:42:05, Null0
C 10.0.1.0/24 je připojen přímo, FastEthernet1/1.2
C 10.0.2.0/24 je připojen přímo, FastEthernet1/1.3

Oba vytvořili cestu 10.0.0.0/8 s adresou dalšího skoku Null0.

Ale klgr-center-gw2 ví, že podsítě 10.0.0.0/8 jsou za oběma jeho WAN rozhraními.
D 10.0.0.0/8 přes 172.16.2.41, 00:42:49, FastEthernet0/1
přes 172.16.2.45, 00:38:05, FastEthernet0/0

Děje se něco velmi zvláštního.
Pokud však zkontrolujete konfiguraci tohoto routeru, pravděpodobně si všimnete:
router eigrp 1
síť 172.16.0.0
síť 10.0.0.0
automatické shrnutí

Za všechno může automatické sčítání. To je největší zlo EIGRP. Pojďme se blíže podívat na to, co se děje. klgr-center-gw1 a klgr-balt-gw1 mají podsítě od 10.0.0.0/8, standardně je shrnují, když jsou předány svým sousedům.
To znamená, že například klgr-balt-gw1 nepřenáší dvě sítě 10.0.1.0/24 a 10.0.2.0/24, ale jednu zobecněnou: 10.0.0.0/8. To znamená, že jeho soused si bude myslet, že celá tato síť stojí za klgr-balt-gw1.
Co se ale stane, když najednou na balt-gw1 dorazí paket s cílem 10.0.50.243, o kterém nic neví? V tomto případě se vytvoří tzv. Blackhole route:
10.0.0.0/8 je souhrn, 00:42:05, Null0
Přijatý paket bude vhozen do této černé díry. To se provádí, aby se zabránilo směrovacím smyčkám.
Takže oba tyto routery si vytvořily své vlastní blackhole routes a ignorují oznámení ostatních lidí. Ve skutečnosti v takové síti tato tři zařízení nebudou moci pingnout, dokud ... dokud nezakážete automatické shrnutí.

První věc, kterou byste měli udělat při nastavování EIGRP:
router eigrp 1
žádné automatické shrnutí

Na všech zařízeních. A všichni budou v pořádku:

Klgr-center-gw1:
C 10.0.0.0 je připojen přímo, FastEthernet1/0
D 10.0.1.0 přes 172.16.2.37, 00:03:11, FastEthernet0/0
D 10.0.2.0 přes 172.16.2.37, 00:03:11, FastEthernet0/0

klgr-balt-gw1
10.0.0.0/24 je podsíť, 3 podsítě
D 10.0.0.0 přes 172.16.2.38, 00:08:16, FastEthernet0/1
C 10.0.1.0 je připojen přímo, FastEthernet1/1.2
C 10.0.2.0 je připojen přímo, FastEthernet1/1.3

klgr-center-gw2:
10.0.0.0/24 je podsíť, 3 podsítě
D 10.0.0.0 přes 172.16.2.45, 00:11:50, FastEthernet0/0
D 10.0.1.0 přes 172.16.2.41, 00:11:48, FastEthernet0/1
D 10.0.2.0 přes 172.16.2.41, 00:11:48, FastEthernet0/1

Konfigurace přenosů trasy mezi různými protokoly

K jeho implementaci potřebujeme alespoň jeden spojovací bod, kde budou spuštěny dva protokoly současně. Může to být msk-arbat-gw1 nebo klgr-balt-gw1. Vyberme si to druhé.

Od do EIGRP d OSPF:
klgr-gw1(config)#router ospf 1
klgr-gw1(config-router)#redistribute eigrp 1 subnets

Podíváme se na trasy na msk-arbat-gw1:

msk-arbat-gw1#sh IP cesta
Kódy: C - připojeno, S - statické, I - IGRP, R - RIP, M - mobilní, B - BGP
D - EIGRP, EX - EIGRP externí, O - OSPF, IA - OSPF mezioblast
N1 - OSPF NSSA externí typ 1, N2 - OSPF NSSA externí typ 2
E1 - OSPF externí typ 1, E2 - OSPF externí typ 2, E - EGP
i - IS-IS, L1 - IS-IS úroveň-1, L2 - IS-IS úroveň-2, mj. - IS-IS mezioblast
* - výchozí kandidát, U - statická cesta pro uživatele, o - ODR
P - periodicky stahovaná statická cesta

Brána poslední instance je 198.51.100.1 do sítě 0.0.0.0

10.0.0.0/8 je variabilně podsíťován, 3 podsítě, 2 masky
O E2 10.0.0.0/8 přes 172.16.2.34, 00:25:11, FastEthernet0/1.7
O E2 10.0.1.0/24 přes 172.16.2.34, 00:25:11, FastEthernet0/1.7
O E2 10.0.2.0/24 přes 172.16.2.34, 00:24:50, FastEthernet0/1.7
172.16.0.0/16 je variabilně podsíťován, 30 podsítí, 5 masek
O E2 172.16.0.0/16 přes 172.16.2.34, 00:25:11, FastEthernet0/1.7
C 172.16.0.0/24 je přímo připojen, FastEthernet0/0.3
C 172.16.1.0/24 je přímo připojen, FastEthernet0/0.2
C 172.16.2.0/30 je přímo připojen, FastEthernet0/1.4
C 172.16.2.16/30 je přímo připojen, FastEthernet0/1.5
C 172.16.2.32/30 je přímo připojen, FastEthernet0/1.7
O E2 172.16.2.36/30 přes 172.16.2.34, 01:00:55, FastEthernet0/1,7
O E2 172.16.2.40/30 přes 172.16.2.34, 01:00:55, FastEthernet0/1,7
O E2 172.16.2.44/30 přes 172.16.2.34, 01:00:55, FastEthernet0/1,7
C 172.16.2.128/30 je přímo připojen, FastEthernet0/1.8
O 172.16.2.160/30 přes 172.16.2.130, 01:00:55, FastEthernet0/1,8
O 172.16.2.192/30 přes 172.16.2.197, 00:13:21, FastEthernet1/0.911
C 172.16.2.196/30 je přímo připojen, FastEthernet1/0.911
C 172.16.3.0/24 je přímo připojen, FastEthernet0/0.101
C 172.16.4.0/24 je přímo připojen, FastEthernet0/0.102
C 172.16.5.0/24 je přímo připojen, FastEthernet0/0.103
C 172.16.6.0/24 je přímo připojen, FastEthernet0/0.104
O 172.16.24.0/24 přes 172.16.2.18, 01:00:55, FastEthernet0/1,5
O 172.16.128.0/24 přes 172.16.2.130, 01:00:55, FastEthernet0/1.8
O 172.16.129.0/26 přes 172.16.2.130, 01:00:55, FastEthernet0/1.8
O 172.16.144.0/24 přes 172.16.2.130, 00:13:21, FastEthernet0/1.8

O 172.16.160.0/24 přes 172.16.2.197, 00:13:31, FastEthernet1/0.911
C 172.16.255.1/32 je přímo připojen, Loopback0
O 172.16.255.48/32 přes 172.16.2.18, 01:00:55, FastEthernet0/1,5
O E2 172.16.255.64/32 přes 172.16.2.34, 01:00:55, FastEthernet0/1,7
O E2 172.16.255.65/32 přes 172.16.2.34, 01:00:55, FastEthernet0/1,7
O E2 172.16.255.66/32 přes 172.16.2.34, 01:00:55, FastEthernet0/1,7
O 172.16.255.80/32 přes 172.16.2.130, 01:00:55, FastEthernet0/1.8
O 172.16.255.96/32 přes 172.16.2.130, 00:13:21, FastEthernet0/1.8
přes 172.16.2.197, 00:13:21, FastEthernet1/0.911
O 172.16.255.112/32 přes 172.16.2.197, 00:13:31, FastEthernet1/0.911
198.51.100.0/28 je podsíť, 1 podsíť
C 198.51.100.0 je přímo připojen, FastEthernet0/1.6
S* 0,0,0,0/0 přes 198,51,100,1

Nyní od OSPF k EIGRP. Je to trochu složitější:
klgr-gw1(config)#router eigrp 1
klgr-gw1(config-router)#redistribute ospf 1 metric 100000 20 255 1 1500

Bez zadání metriky (tato dlouhá sada čísel) se příkaz provede, ale nedojde k přerozdělení.

Importované trasy obdrží ve směrovací tabulce štítek EX a administrativní vzdálenost 170 místo 90 u interních:

klgr-gw2#sh IP cesta

Brána poslední instance není nastavena

172.16.0.0/16 je variabilně podsíťován, 30 podsítí, 4 masky
D EX 172.16.0.0/24 [170 /33280] přes 172.16.2.37, 00:00:07, FastEthernet0/0
D EX 172.16.1.0/24 přes 172.16.2.37, 00:00:07, FastEthernet0/0
D EX 172.16.2.0/30 přes 172.16.2.37, 00:00:07, FastEthernet0/0
D EX 172.16.2.4/30 přes 172.16.2.37, 00:00:07, FastEthernet0/0
D EX 172.16.2.16/30 přes 172.16.2.37, 00:00:07, FastEthernet0/0
D 172.16.2.32/30 [ 90 /30720] přes 172.16.2.37, 00:38:59, FastEthernet0/0
C 172.16.2.36/30 je přímo připojen, FastEthernet0/0
D 172.16.2.40/30 přes 172.16.2.37, 00:38:59, FastEthernet0/0
přes 172.16.2.46, 00:38:59, FastEthernet0/1
….

Výchozí trasa

Ping 192.0.2.2 s 32 bajty dat:

Odpověď z 172.16.2.5: Cílový hostitel je nedostupný.
Odpověď z 172.16.2.5: Cílový hostitel je nedostupný.
Odpověď z 172.16.2.5: Cílový hostitel je nedostupný.

Statistiky pingu pro 192.0.2.2:
Pakety: Odeslané = 4, Přijaté = 0, Ztracené = 4 (100% ztráta),

Je to proto, že ani spb-ozerki-gw1 ani spb-vsl-gw1 ani nikdo jiný v naší síti neví o jiné výchozí trase než msk-arbat-gw1, na které je staticky nakonfigurován.
K nápravě této situace stačí, abychom v Moskvě dali jeden příkaz:
msk-arbat-gw1(config)#router ospf 1
msk-arbat-gw1(config-router)#default-information pocházejí

Poté se sítí zaplaví informace o umístění brány poslední instance.

Internet je nyní k dispozici:
PC>tracert

Trasování trasy k 192.0.2.2 po maximálně 30 přeskocích:

1 3 ms 3 ms 3 ms 172.16.17.1
2 4 ms 5 ms 12 ms 172.16.2.5
3 14 ms 20 ms 9 ms 172.16.2.1
4 17 ms 17 ms 19 ms 198.51.100.1
5 22 ms 23 ms 19 ms 192.0.2.2

Užitečné příkazy pro odstraňování problémů

ID souseda Pri State Dead Time Address Interface
172.16.255.32 1 FULL/DROTHER 00:00:33 172.16.2.2 FastEthernet0/1.4
172.16.255.48 1 FULL/DR 00:00:34 172.16.2.18 FastEthernet0/1.5
172.16.255.64 1 FULL/DR 00:00:33 172.16.2.34 FastEthernet0/1.7
172.16.255.80 1 FULL/DR 00:00:33 172.16.2.130 FastEthernet0/1.8
172.16.255.112 1 FULL/DR 00:00:33 172.16.2.197 FastEthernet1/0.911

2) Nebo pro EIGRP: zobrazit ip sousedy eigrp
Sousedé IP-EIGRP pro proces 1
H Adresní rozhraní Hold Uptime SRTT RTO Q Seq
(s) (ms) Cnt Num
0 172.16.2.38 Fa0/1 12 00:04:51 40 1000 0 54
1 172.16.2.42 Fa0/0 13 00:04:51 40 1000 0 58

3) Pomocí příkazu zobrazit ip protokoly můžete zobrazit informace o spuštěných protokolech dynamického směrování a jejich vztahu.

Klgr-balt-gw1:
Směrovací protokol je "EIGRP 1"

Výchozí sítě označené v odchozích aktualizacích
Výchozí sítě přijaté z příchozích aktualizací
Metrická hmotnost EIGRP K1=1, K2=0, K3=1, K4=0, K5=0
Maximální počet skoků EIGRP 100
Maximální metrický rozptyl EIGRP 1
Redistribuce: EIGRP 1, OSPF 1
Je aktivní automatická sumarizace sítě
Automatické shrnutí adresy:
Maximální cesta: 4
Směrování pro sítě:
172.16.0.0

172.16.2.42 90 4
172.16.2.38 90 4
Vzdálenost: vnitřní 90 vnější 170

Směrovací protokol je "OSPF 1"
Seznam filtrů odchozí aktualizace pro všechna rozhraní není nastaven
Seznam filtrů příchozích aktualizací pro všechna rozhraní není nastaven
ID routeru 172.16.255.64
Je to autonomní systémový hraniční router
Redistribuce externích cest z,
EIGRP 1
Počet oblastí v tomto routeru je 1. 1 normální 0 stub 0 nssa
Maximální cesta: 4
Směrování pro sítě:
172.16.2.32 0.0.0.3 plocha 0
Zdroje informací o směrování:
Poslední aktualizace vzdálenosti brány
172.16.255.64 110 00:00:23
Vzdálenost: (výchozí je 110)

4) Pro ladění a pochopení fungování protokolů bude užitečné použít následující příkazy:
ladění událostí ip OSPF
ladit IP OSPF adj
ladění paketů EIGRP

Zkuste škubat různými rozhraními a uvidíte, co se děje v ladění, jaké zprávy létají.

Autoři

Chci vyjádřit svou vděčnost Dmitriji JDimovi za úpravy a neocenitelné komentáře, neodolatelnému Natashe Samoylenko za poskytnuté úkoly. Antonu Avtushkovi za naprogramování stránky pro blog. A dívka s pěkným jménem Nina pro logo webu.

P.S.
Náš nadcházející LinkMeUp podcast potřebuje znělku a hudbu na pozadí. Rádi pomůžeme a jméno skladatele bude oslavováno po staletí.

P.P.S.
Již nemáme dostatek možností Packet Tracer. Dalším krokem je přejít k něčemu vážnějšímu. Nějaké přání? Navrhuji uspořádat holivar v komentářích na téma IOU vs GNS.

Než se ponoříme do detailů a funkcí dynamického směrování, věnujte pozornost dvouúrovňovému modelu, v rámci kterého je uvažována celá sada internetových strojů. V rámci tohoto modelu je celý internet považován za soubor autonomních systémů (autonomní systém - AS). Autonomní systém je sada počítačů, které tvoří poměrně hustou komunitu, kde existuje mnoho cest mezi dvěma počítači, které do této komunity patří. V rámci této komunity lze hovořit o optimalizaci tras za účelem dosažení maximální rychlosti přenosu informací. Na rozdíl od tohoto hustého konglomerátu nejsou autonomní systémy vzájemně propojeny tak těsně jako počítače v autonomním systému. Výběr trasy z jednoho autonomního systému přitom nemusí být založen na rychlosti výměny informací, ale na spolehlivosti, spolehlivosti atd.

Rýže. 2.24

Samotná ideologie autonomních systémů vznikla v období, kdy ARPANET představoval hierarchický systém. V té době existovalo jádro systému, na které byly napojeny externí autonomní systémy. Informace z jednoho autonomního systému do druhého se mohly dostat pouze přes hlavní směrovače. Tato struktura je stále zachována v MILNET.

Na obrázku 2.24 jsou autonomní systémy propojeny pouze jedním spojem, což více odpovídá tomu, jak je ruský sektor připojen k internetu. V klasických internetových publikacích je interakce autonomních částí často reprezentována protínajícími se kruhy, zdůrazňujícími skutečnost, že z jednoho autonomního systému do druhého může existovat více cest.

Diskuse o tomto modelu internetu je nezbytná pouze pro vysvětlení existence dvou typů dynamických směrovacích protokolů: externího a interního.

Externí protokoly se používají k výměně informací o trasách mezi autonomními systémy.

Interní protokoly se používají k výměně informací o trasách v rámci autonomního systému.

V reálné praxi budování lokálních sítí, podnikových sítí a jejich napojení na poskytovatele potřebujete znát především pouze interní dynamické směrovací protokoly. Externí dynamické směrovací protokoly jsou potřeba pouze tehdy, když má být vybudován uzavřený velký systém, který bude s vnějším světem spojen pouze malým počtem zabezpečených datových kanálů.

Mezi externí protokoly patří protokol Exterior Gateway Protocol (EGP) a< Protocol Gateway>.

EGP je určen k propagaci sítí, které jsou dostupné autonomním systémům mimo tento autonomní systém. Podle tohoto protokolu brána jednoho AS předává bráně jiného AS informace o sítích, ze kterých se skládá jeho AS. EGP se nepoužívá pro optimalizaci trasy. Předpokládá se, že by se s tím měly vypořádat interní směrovací protokoly.

BGP je další externí směrovací protokol, který přišel po EGP. Ten už ve svých zprávách umožňuje u tras specifikovat různé váhy, a přispět tak k výběru nejlepší trasy. Přiřazení těchto vah však není určeno některými nezávislými faktory, jako je doba přístupu ke zdroji nebo počet bran na cestě ke zdroji. Předvolby nastavuje administrátor, a proto se někdy takové směrování nazývá politické směrování, což znamená, že odráží technickou politiku správy tohoto autonomního systému při přístupu z jiných autonomních systémů. informační zdroje. Protokol BGP používají téměř všichni ruští velcí poskytovatelé IP, například velké uzly sítě Relcom.

Mezi interní protokoly patří Routing Information Protocol (RIP), HELLO, Intermediate System to Intermediate System (ISIS), Shortest Path First (SPF) a Open Shortest Path First (OSPF).

Protokol RIP (Routing Information Protocol) je navržen tak, aby automaticky aktualizoval směrovací tabulku. K tomu se využívají informace o stavu sítě, které odesílají směrovače (routery). Podle protokolu RIP může být routerem jakýkoli stroj. Zároveň jsou všechny routery rozděleny na aktivní a pasivní. Aktivní směrovače hlásí trasy, které v síti podporují. Pasivní směrovače čtou tyto vysílané zprávy a opravují své směrovací tabulky, ale samy informace do sítě neposkytují. Brány obvykle fungují jako aktivní směrovače a běžné počítače (hostitelé) fungují jako pasivní směrovače.

Směrovací algoritmus RIP je založen na jednoduché myšlence: čím více bran musí paket projít, tím více času zabere dokončení trasy. Při výměně zpráv routery sdělují síti IP číslo sítě a počet "hopů" (hopů), které je třeba pomocí této cesty provést. Ihned je třeba poznamenat, že takový algoritmus je platný pouze pro sítě, které mají stejnou přenosovou rychlost v jakémkoli segmentu sítě. V reálném životě se často ukazuje, že je mnohem výhodnější používat optická vlákna se 3 bránami než jeden pomalý vytáčený telefonní kanál.

Další myšlenkou, která je navržena pro řešení problémů RIP, není zohlednění počtu skoků, ale zohlednění doby odezvy. Na tomto principu je postaven například protokol OSPF. Kromě toho OSPF také implementuje V RIP si každý router vyměňuje informace pouze se sousedy V důsledku toho budou informace o ztrátě trasy v síti oddělené několika skoky od místní sítě přijaty pozdě. Flooding tento problém řeší tak, že všechny známé brány upozorní na změny v sekci lokální sítě.

Bohužel ne mnoho systémů podporuje vícecestné směrování. Různé klony Unixu a NT, zaměřené především na protokol RIP. Abyste to viděli, stačí se podívat na software pro dynamické směrování. routed podporuje pouze RIP, gated podporuje RIP, HELLO, OSPF, EGP a BGP a Windows NT podporuje pouze RIP.

Proto budeme uvažovat o možnosti dynamické správy směrovací tabulky pouze přes protokol RIP.

Směrovače fungují v sítích s přepojováním paketů, kde již existují všechny možné cesty. Proces kladení cesty je buď prováděn ručně správcem (statické směrování), nebo je směrován automaticky. protokol (dynamické směrování).

Směrovače, které znají informace o cestě k některým sítím, si tyto informace vyměňují s jinými zařízeními. Po takovém aktualizace všechny směrovače budou mít konzistentní informace o směrování dostupné sítě. Proces výměny aktualizací je implementován směrovacími protokoly. Tím pádem, směrovací protokoly sdílejí síťové informace mezi směrovači.

Změny topologie nějakou dobu trvají ( čas konvergence nebo konvergence) Pro harmonizace informací ve směrovacích tabulkách všech směrovačů v síti. Doba konvergence je důležitým faktorem při výběru směrovacího protokolu.

Informace o směrování jsou shromažďovány podle určitých pravidel během implementace algoritmu dynamické výměny aktualizace(aktualizace, úpravy) mezi routery. Směrovací protokol musí vytvářet a udržovat směrovací tabulky, kde jsou uloženy cesty ke všem dostupným cílovým sítím, stejně jako upozorňovat ostatní routery na všechny jemu známé změny topologie sítě, tzn. vyřešit problém zjišťování sítě.

Sada sítí reprezentovaná směrovači pod běžnými formuláři administrativní kontroly autonomní systém(obr. 3.1). Příkladem autonomních systémů jsou sítě jednotlivých ISP. Autonomní systémy jsou číslovány (AS1, AS2, …AS107, …) a v některých protokolech (IGRP, EIGRP) se tato čísla používají při konfiguraci.

Rýže. 3.1.

Tento kurz pokrývá pouze směrování v rámci autonomního systému, kde jsou spuštěny protokoly vnitřní brány. IGP), které zahrnují RIP , RIPv2, EIGRP , OSPF , IS-IS . Směrování mezi autonomními systémy je prováděno externími směrovacími protokoly (Exterior Gateway Protocols - EGP). Příkladem externího směrovacího protokolu je BGP, který běží na AS hraničních směrovačích (obrázek 3.1).

Sada směrovacích protokolů je uvedena v tabulce. 3.1, ze kterého vyplývá, že dynamické směrovací protokoly fungující uvnitř autonomních systémů se zase dělí na protokoly vzdálenostních vektorů (distance-vector) A link-state protokoly.

Protokoly vektor vzdálenosti určit vzdálenost a směr, tzn. vektor spojení ve složené síti na cestě k cíli. Při použití protokolu vektor vzdálenosti směrovače odesílají celou nebo část směrovací tabulky sousedním (sousedním) směrovačům. V protokolech jako RIP A RIP-2 vzdálenost je vyjádřena v počet skoků (počet skoků) ve spojení na cestě ze zdrojového uzlu do cíle. Dochází k výměně aktualizací ( update ) nebo úprav pravidelně, i když nedojde k žádné změně v síti, která spotřebovává značné množství šířky pásma. Po obdržení aktualizovaných informací o směrování může směrovač přepočítat všechny známé cesty a aktualizovat směrovací tabulku.

Protokoly stav kanálu vytvořit úplný obrázek topologie sítě a vypočítat nejkratší cesty do všech cílových sítí. Pokud existuje několik cest se stejnou metrikou, vybere se první z vypočítaných cest. Distribuce aktualizací jsou vytvářeny pouze informace o směrování při změně topologie sítě. Protokoly stavu spojení (nebo odkazu) reagují na změny v síti rychleji než protokoly s vektorem vzdálenosti, ale vyžadují více výpočetních zdrojů.

Když paket zapouzdřený do rámce dorazí na vstupní rozhraní, router jej dekapsuluje a poté pomocí směrovací tabulky určí, na kterou cestu má paket směrovat, tzn. do kterého výstupního rozhraní odeslat příchozí paket. Výstupní rozhraní je spojeno s nejúčinnější cestou k cíli. Tento proces se nazývá přepínání nebo povýšení balík. Na výstupním rozhraní je paket zapouzdřen do nového rámce, zatímco router přidává informace k vytvoření rámce (viz materiály "Principy a prostředky vzájemné spolupráce").

Směrovače jsou schopny současně podporovat několik nezávislých protokolů s různými administrativní vzdálenosti (AD), které udávají úroveň spolehlivosti zdroje trasy. Čím menší AD, tím vyšší spolehlivost (viz tabulka 1.1). Směrovací tabulka je nastavena na cesty vytvořené protokoly s nejmenší administrativní vzdáleností.

Směrovací protokol určuje nejracionálnější (optimální) cestu na základě určitého kritéria - metriky. Při hodnocení se používá metrická hodnota možné způsoby do cíle. Tento kurz pokrývá následující směrovací protokoly:

Uvedené protokoly používají různé metrické parametry.

Různé směrovací protokoly používají různé algoritmy při výběru cesty, tzn. výstupní rozhraní a/nebo adresa dalšího skoku, na kterou má být paket odeslán. Algoritmus a metrika jsou určeny řadou úkolů, které je třeba vyřešit, jako je jednoduchost, stabilita, flexibilita, rychlost konvergence nebo konvergence. Konvergence je proces vyjednávání mezi routery v síti informace o dostupných trasách. Když se změní stav sítě, je nutné, aby výměna změn obnovila konzistentní síťové informace.

Každý algoritmus interpretuje volbu nejracionálnější cesty svým vlastním způsobem na základě metriky. Obvykle nižší metrická hodnota odpovídá lepší trase. Metrika může být založena na jednom nebo více parametrech cesty. Ve směrovacích protokolech se nejčastěji používají následující metrické parametry:

Nejznámější v Internetové sítě vzdálenost-vektor protokol je Routing Information Protocol (RIP), který používá jako metriku počet přechodů(hop count) na cestě do cíle.

Dalším jednoduchým vektorovým protokolem vzdálenosti je protokol Interior Gateway Routing Protocol ( IGRP), který byl vyvinut společností Cisco. Pro práci ve velkých sítích byl nahrazen protokolem Vylepšený IGRP (EIGRP), který zahrnuje mnoho funkcí protokolu typu link-state i distance-vector. Jedná se tedy ve skutečnosti o hybridní protokol. Vývojáři Cisco jej však označují jako vzdálený vektorový protokol.

Protokoly vzdálenostních vektorů (RIP, IGRP) pravidelně odesílají aktualizace informace o trase. U protokolu RIP je tato doba 30 sekund. Tím se aktualizují směrovací tabulky, které ukládají všechny informace o trasách v síti. Když dojde ke změně v síti, router, který takovou změnu detekuje, si okamžitě začne vyměňovat informace o směrování se sousedními routery. Tato výměna probíhá sekvenčně od routeru k routeru s určitým zpožděním určeným časem modifikace tabulky v každém routeru a také speciálním časovačem. Proto konvergence (konvergence) síť, kdy všechny směrovače mají konzistentní informace o síťových připojeních, jde pomalu, což je nevýhoda vzdálených vektorových protokolů.

Protokoly vzdálenostních vektorů RIP se tedy vyznačují pomalá konvergence, tj. dlouhý čas na koordinaci informací ve směrovacích tabulkách při změně topologie sítě.

Vektorový protokol vzdálenosti RIP používá počet skoků jako metriku k určení vzdálenosti ke konkrétnímu připojení ve složené síti. Pokud existuje více cest, pak RIP vybere cestu s nejmenším počtem směrovačů nebo skoků k cíli. Ne vždy je však zvolená trasa nejlepší způsob do cíle, protože zvolená trasa s nejmenším počtem zařízení může mít nižší přenosovou rychlost (menší šířka pásma, nižší propustnost) ve srovnání s alternativními trasami vytvořenými jinými protokoly. Navíc RIP nemůže směrovat pakety přesahující 15 skoků, takže se doporučuje pro malé až střední sítě. Distribuce aktualizací protokol první verze RIPv1 je vyráběn v režim vysílání( adresa 255.255.255.255 ).

První verze RIPv1 vyžaduje, aby všechna zařízení v podsíti používala stejnou masku podsítě. RIP nezahrnuje informace o masce podsítě v aktualizacích směrování. Tato metoda se nazývá směrování založené na třídách, který omezuje použití protokolu RIPv1 v moderních sítích.

RIPVersion 2 Distance Vector Protocol ( RIPv2) poskytuje beztřídní směrování CIDR(Classless Interdomain Routing), protože aktualizace směrování zahrnují informace o masce podsítě(o předponě). Zároveň podsítě s maskami s proměnnou délkou (Variable-Length Subnet Mask - VLSM). Aktualizace také obsahují informace o adresách výchozích bran. Distribuce aktualizací podle protokolu verze RIPv2 se provádí v multicast režimu (

Dynamické směrování

Statické směrování není vhodné pro velké a složité sítě, protože sítě obvykle obsahují redundantní spojení, více protokolů a smíšené topologie. Směrovače ve složitých sítích se musí rychle přizpůsobit změnám topologie a vybrat nejlepší trasu z mnoha kandidátů.

IP sítě mají hierarchickou strukturu. Z hlediska směrování je síť považována za soubor autonomních systémů. V autonomních subsystémech velkých sítí jsou výchozí cesty široce používány pro směrování do jiných autonomních systémů.

Dynamické směrování může být implementováno pomocí jednoho nebo více protokolů. Tyto protokoly jsou často seskupeny podle toho, kde se používají. Protokoly pro práci v rámci autonomních systémů se nazývají protokoly vnitřní brány (IGP) a protokoly pro práci mezi autonomními systémy se nazývají protokoly externí brány (EGP). Mezi protokoly IGP patří RIP, RIP v2, IGRP, EIGRP, OSPF a IS-IS. Protokoly EGP3 a BGP4 patří k EGP. Všechny tyto protokoly lze rozdělit do dvou tříd: protokoly vzdálenostních vektorů a protokoly stavu spojení.

Směrovače používají metriky k vyhodnocování nebo měření tras. Pokud existuje mnoho tras ze směrovače do cílové sítě a všechny používají stejný směrovací protokol, pak je cesta s nejnižší metrikou považována za nejlepší. Pokud jsou použity různé směrovací protokoly, pak se pro výběr cesty používají administrativní vzdálenosti, které jsou trasám přiřazeny operačním systémem směrovače.

RIP používá jako metriku počet skoků. EIGRP využívá komplexní kombinaci faktorů včetně šířky pásma a spolehlivosti linky.

Výsledky práce směrovacích protokolů se zapisují do směrovací tabulky, která se neustále mění při změně situace v síti. Zvažte typický řádek v tabulce směrování související s dynamickým směrováním

R 192.168.14.0/24 přes 10.3.0.1 00:00:06 Serial0

Zde R definuje směrovací protokol. R tedy znamená RIP a O znamená OSPF atd. Záznam znamená, že tato trasa má administrativní vzdálenost 120 a metriku 3. Tato čísla používá router k výběru trasy. Prvek 00:00:06 definuje čas aktualizace tohoto řádku. Serial0 je místní rozhraní, přes které bude router směrovat pakety do sítě 192.168.14.0/24 přes adresu 10.3.0.1.

Aby si dynamické směrovací protokoly vyměňovaly informace o statických cestách, musí být provedena další konfigurace.

Vektorové směrování vzdálenosti

Toto směrování je založeno na Belman-Fordově algoritmu. Po určitých okamžicích směrovač předá celou svou směrovací tabulku sousedním směrovačům. Jednoduché protokoly jako RIP a IGRP jednoduše vysílají informace o směrovací tabulce přes všechna rozhraní směrovačů, aniž by znaly přesnou adresu konkrétního sousedního směrovače.

Sousední směrovač při příjmu vysílání porovnává informace se svou aktuální směrovací tabulkou. Přidává trasy do nových sítí nebo tras do slavné sítě s nejlepší metrikou. Odstraňuje neexistující trasy. Router přidává své vlastní hodnoty k přijatým metrikám trasy. Nová směrovací tabulka se znovu rozšíří do sousedních směrovačů (viz obrázek 1).

font-size:12.0pt;line-height:125%">Obr. 1. Směrování vektorů vzdálenosti.

Protokoly stavu propojení

Tyto protokoly nabízejí lepší škálovatelnost a konvergenci než protokoly vzdálenostních vektorů. Protokol je založen na Dijkstrově algoritmu, často označovaném jako algoritmus s nejkratší cestou (SPF). Nejtypičtějším představitelem je protokol OSPF (Open Shortest Path First).

Router bere v úvahu stav propojení rozhraní ostatních routerů v síti. Router si buduje kompletní databázi všech stavů spojení ve své oblasti, to znamená, že má dostatek informací pro vytvoření vlastního mapování sítě. Každý router pak nezávisle spustí algoritmus SPF na svém vlastním mapování sítě nebo databázi stavu spojení, aby určil nejlepší cestu, která se zadá do směrovací tabulky. Tyto cesty do jiných sítí tvoří strom s místním routerem nahoře.

Směrovače oznamují stav svého připojení všem směrovačům v oblasti. Takové oznámení se nazývá LSA (link-state ads).

Na rozdíl od dálkových vektorových směrovačů mohou směrovače se stavem spojení vytvářet zvláštní vztahy se svými sousedy.

Dochází k počátečnímu přílivu paketů LSA k sestavení databáze stavu propojení. Trasy jsou dále aktualizovány pouze tehdy, když se změní stav připojení nebo pokud se stav nezměnil v určitém časovém intervalu. Pokud se stav propojení změnil, je částečná aktualizace odeslána okamžitě. Obsahuje pouze stavy odkazů, které se změnily, nikoli celou směrovací tabulku.

Administrátor, který se zabývá používáním odkazů, považuje tyto dílčí a občasné aktualizace za účinnou alternativu k vektorovému směrování vzdálenosti, které v pravidelných intervalech přenáší celou tabulku směrování.

Protokoly stavu spojení mají rychlejší konvergenci a nejlepší využitíšířku pásma ve srovnání s protokoly vzdálenostních vektorů. Jsou lepší než distanční vektorové protokoly pro sítě libovolné velikosti, ale mají dvě hlavní nevýhody: zvýšené nároky na výpočetní výkon routerů a složitou správu.

Konvergence.

Tento proces je společný, a individuální. Směrovače sdílejí informace mezi sebou, ale nezávisle přepočítávají své směrovací tabulky. Aby byly jednotlivé směrovací tabulky přesné, musí všechny směrovače stejně rozumět topologii sítě. Pokud se routery dohodly na topologii sítě, pak konvergují. Rychlá konvergence znamená rychlé zotavení z nefunkčních odkazů a dalších síťových změn. Směrovací protokoly a kvalita návrhu sítě se posuzují především podle konvergence.

Když jsou směrovače v procesu konvergence, síť je citlivá na problémy se směrováním. Pokud některé směrovače určily, že odkaz chybí, jiné se mylně domnívají, že odkaz existuje. Pokud k tomu dojde, bude individuální směrovací tabulka nekonzistentní, což může vést k zahození paketů a zacyklení směrování.

Není možné, aby všechny směrovače v síti detekovaly změny v topologii současně. V závislosti na použitém protokolu může konvergování všech směrovacích procesů v síti trvat dlouho. Ovlivňují to následující faktory:

Vzdálenost ve skocích k bodu změny topologie.

Počet směrovačů používajících dynamické protokoly.

Vliv některých faktorů lze snížit pečlivým návrhem sítě.

dynamické směrování. První setkání.

Dva routery a pět sítí

Složitější topologie sítě

Ale co když máme síť několika desítek routerů, každý s deseti sítěmi? Předepsat spoustu statických cest? Samozřejmě že ne. Zde je třeba použít dynamické směrovací protokoly.

Dynamické směrovací protokoly pravidelně vysílají informace uložené ve směrovací tabulce směrovače přes jeho rozhraní do jiných síťových směrovačů a také přijímají a zpracovávají podobné zprávy od jiných síťových směrovačů. Po přijetí takových zpráv z nich router extrahuje neznámé cesty a přidá je do své směrovací tabulky.

Kromě toho, že dynamické směrovací protokoly osvobozují síťové inženýry od nutnosti ručně zatloukat stovky statických cest, dynamické směrovací protokoly také zvyšují odolnost sítě tím, že poskytují redundantní cesty. Například pokud máme síť jako na obrázku výše. A nelenili jsme a přidali 6 statických tras na každém ze zařízení, pak bude vše fungovat. Ale před prvním selháním, pokud některý z odkazů mezi routery zmizí, okamžitě zaznamenáme poruchu v síti. Při použití dynamického směrování tento problém nenastane. V případě nehody budou použity záložní trasy.

Nyní trochu teorie. Všechny dynamické směrovací protokoly lze rozdělit na externí směrovací protokoly ( Protokol vnitřní brány, IGP) a vnitřní brána ( Protokol vnější brány, EGP). Protokoly interní brány jsou navrženy pro směrování v rámci autonomních systémů, protokoly externí brány pro směrování mezi autonomními systémy. V tento případ Autonomní systém je a velká síť, pod jednotnou kontrolou. Například síť velkého podniku.

Aplikace IGP a EGP

Při použití dynamických směrovacích protokolů jsou dodávány všechny cesty umístěné ve směrovací tabulce dodatečné informace nazývaná metrika. Tato metrika umožňuje směrovačům vypočítat nejkratší cestu do požadované sítě. Podle způsobu výpočtu metriky lze všechny dynamické směrovací protokoly rozdělit na vektor vzdálenosti ( vektor vzdálenosti), protokoly zohledňující stav kanálů ( stav odkazu) a hybridní.

Ve vzdálenostních vektorových směrovacích punkcích se jako metrika používá počet mezilehlých uzlů. Čím méně mezilehlých uzlů, tím výhodnější bude trasa.

Nějaká topologie sítě

Protokoly, které při své práci berou v úvahu stav kanálů, kupodivu berou v úvahu stavy kanálů a již na základě těchto stavů počítají hodnoty metriky.