› › Interní směrovací protokoly (IGP). EGP – protokoly externí brány

Interní směrovací protokoly (IGP). EGP – protokoly externí brány







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


Abyste pochopili předmět konverzace, měli byste si nejprve přečíst články o směrovačích a směrování zde poblíž, jinak riskujete, že se nedostanete dovnitř.
Řekněme, že máme jednoduchou mřížku, jako je tato:

Dva routery a pět sítí


Ve výchozím nastavení, s danou topologií sítě, bude mít „levý“ router ve své směrovací tabulce položky pouze pro tři sítě přímo k němu připojené: 192.168.1.0/24 , 172.20.0.0/16 A 192.168.100.0/30 . Podobně „správný“ router bude vědět pouze o sítích: 192.168.2.0/24 , 10.0.0.0/8 A 192.168.100.0/30 . A pokud se pokusíme ze sítě 172.20.0.0/16 získat přístup k síti 192.168.2.0/24, nedostaneme odpověď. Samozřejmě můžeme routerům dát statické trasy nebo standardní trasy (aka výchozí trasy).
Vypadá to jako skvělé řešení, ne? Co se ale stane, když máme tuto topologii sítě před sebou:


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


Pokud v předchozím příkladu bylo možné přidat výchozí trasy na jeden řádek nebo přidat dvě statické trasy dvěma příkazy, udělejte to na každém zařízení a vše by fungovalo, pak je situace zde složitější. Výchozí trasy jsou zde málo použitelné a pokud řešíte problém se směrováním pomocí statických cest, pak budete muset na každém zařízení zaregistrovat šest statických cest, což není tak málo.

Co když máme síť několika desítek routerů, z nichž každý má tucet sítí? Registrovat spoustu statických tras? Samozřejmě že ne. Zde je třeba použít dynamické směrovací protokoly.

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

Kromě skutečnosti, že dynamické směrovací protokoly osvobozují síťové inženýry od nutnosti ručně zapojovat stovky statických cest, umožňují dynamické směrovací protokoly také zvýšit odolnost proti chybám sítě tím, že mají záložní 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 zařízení, pak bude vše fungovat. Ale před první nehodou, pokud některá z vazeb mezi routery zmizí, okamžitě zaznamenáme poruchu v síti. Pokud používáte dynamické směrování, tento problém nenastane. V případě nehody budou použity záložní trasy.

Nyní trocha 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, E.G.P.). Protokoly interní brány jsou navrženy pro směrování v rámci autonomních systémů, protokoly externí brány jsou určeny pro směrování mezi autonomními systémy. V tomto případě autonomní systém znamená nějaké velká síť, pod jednotnou kontrolou. Například síť velkého podniku.


Aplikace IGP a EGP


Zástupci rodiny protokolů IGP jsou protokoly: RIP-1, RIP-2, IGRP, OSPF, EIGRP. NA E.G.P. existuje jeden protokol - BGP.

Při použití dynamických směrovacích protokolů jsou všechny cesty umístěné ve směrovací tabulce dodávány s dalšími informacemi nazývanými metrika. Tato metrika umožňuje směrovačům vypočítat nejkratší cestu do požadované sítě. V souladu s tím, jak se metrika vypočítává, lze všechny protokoly dynamického směrování rozdělit na vektor vzdálenosti ( Vektor vzdálenosti), protokoly zohledňující stav kanálů ( Link-state) a hybridní.

Ve vzdálenosti vektor směrování punkcí, počet mezilehlé uzly. Čím méně mezilehlých uzlů, tím výhodnější bude trasa.


Nějaká topologie sítě


Mějme tuto topologii sítě. Ze sítě 1 do sítě 2 vedou dvě různé trasy, červená a zelená. V případě použití dálkového vektorového směrovacího protokolu bude výhodnější vyhrazená trasa zelená, protože obsahuje méně mezilehlých uzlů na cestě do cílové sítě. Klasické příklady protokolů pro směrování vektorů vzdálenosti jsou RIP-1 A RIP-2.

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

Podívejme se na dva dynamické směrovací protokoly – Interior Gateway Protocol (IGP) a Exterior Gateway Protocol (EGP).

Autonomní systém (AS) - jinak známý jako směrovací doména - je soubor směrovačů pod společnou správou. Typickými příklady jsou vnitřní síť společnosti a síť poskytovatelů internetu. Protože internet je založen na konceptu autonomního systému, jsou vyžadovány dva typy směrovacích protokolů: interní a externí směrovací protokoly. Tyto protokoly:

    Protokoly interní brány ( IGP) používá se pro intra-autonomní systémové směrování - intra-autonomous system routing.

    Protokoly externí brány ( E.G.P.) používá se pro směrování mezi autonomními systémy - průvodce mezi autonomními systémy.

Obrázek je zjednodušeným znázorněním rozdílu mezi IGP a EGP. Koncept autonomního systému bude podrobněji vysvětlen dále v této části.

Charakteristika směrovacích protokolů IGP a EGP

IGP se používají k provádění směrování v rámci směrovací domény, tzn. ty sítě, které jsou pod kontrolou jedné organizace. Autonomní systém se obvykle skládá z mnoha samostatných sítí, ve vlastnictví společností, školy a další instituce. IGP slouží k provádění směrování v rámci autonomního systému a také slouží k směrování provozu v rámci jednotlivých sítí samotných. CENIC například provozuje autonomní systém kalifornských škol, vysokých škol a univerzit. CENIC využívá IGP k provádění směrování v rámci svého autonomního systému k propojení všech těchto institucí. Každá vzdělávací instituce také používá IGP ke směrování provozu v rámci své vlastní samostatné sítě. IGP používaný každou entitou poskytuje lepší definici cesty v rámci jejích vlastních směrovacích domén, stejně jako IGP používaný CENIC poskytuje lepší cesty v rámci samotného autonomního systému. Mezi IGP pro IP patří RIP, IGRP, EIGRP, OSPF a IS-IS.

Směrovací protokoly, přesněji řečeno algoritmy používané těmito směrovacími protokoly, používají metriku k určení nejlepší způsob do sítě. Metrikou používanou směrovacím protokolem RIP je počet skoků, což je počet směrovačů, kterými musí paket projít, aby dosáhl jiné sítě. OSPF používá šířku pásma k určení nejkratší cesty.

Na druhé straně EGP jsou navrženy pro použití mezi různými autonomními systémy, které jsou pod kontrolou různých správ. BGP je jediný v současnosti životaschopný EGP a je směrovacím protokolem používaným internetem. BGP je směrovací vektorový protokol, který může používat mnoho různých atributů k měření tras. Na úrovni ISP jsou často důležitější problémy než jen výběr nejrychlejší cesty. BGP se obvykle používá mezi ISP a někdy mezi společností a ISP.

Interní směrovací protokoly (IGP)

Dynamické protokoly jsou rozděleny do dvou skupin:

  • 1) EGP (External Gateway Protocol) - externí směrovací protokol pro použití mezi autonomními systémy (AS).
  • 2) IGP (Interior Gateway Protocol) - interní směrovací protokol pro použití v rámci AS.

Interní směrovací protokoly popsané v této podkapitole zajišťují synchronizaci směrovačů a tras nakonfigurovaných mezi nimi uvnitř lokální síť. Rozhodnutí formulovat nejlepší trasu je založeno na metrikách shromážděných výměnou informací se sousedními síťovými bránami. V závislosti na metrikách a principech konstrukce trasy se protokoly IGP dále dělí na protokoly vzdálenostních vektorů (DVA) a protokoly stavu spojení (LSP).

Distance vector protocols (DVA)

V algoritmech vektoru vzdálenosti každý směrovač periodicky vysílá po síti vektor, jehož součástí jsou vzdálenosti (měřené v jedné nebo jiné metrice) od daného směrovače do všech sítí, které jsou mu známy. Pakety směrovacího protokolu se běžně nazývají reklamy na dálku, protože je používá směrovač k tomu, aby ostatním směrovačům oznámil, co ví o konfiguraci sítě.

Poté, co router od určitého souseda obdrží vektor vzdáleností k sítím, které zná, zvětší složky vektoru o vzdálenost od sebe k tomuto sousedovi. Vektor navíc doplňuje informacemi o dalších jemu známých sítích, o kterých se dozvěděl přímo (pokud jsou připojeny k jeho portům) nebo z podobných reklam jiných routerů. Router odešle aktualizovanou hodnotu vektoru svým sousedům. Nakonec se každý směrovač učí prostřednictvím sousedních směrovačů informace o všech sítích přítomných ve složené síti a vzdálenostech k nim.

Nevýhodou vektorových algoritmů vzdálenosti je, že fungují dobře pouze v relativně malém prostoru počítačové sítě. Směrovače si totiž neustále vyměňují vzdálenostní vektory, což vede k zanášení komunikačních linek vysílací provoz PROTI velké sítě. Další nevýhoda tohoto algoritmu spočívá v tom, že ne vždy správně reaguje na změny v konfiguraci sítě, protože směrovače přenášejí pouze zobecněné informace - vektor vzdáleností, což vede k tomu, že směrovače neobsahují konkrétní představu o topologii připojení. .

Protokoly založené na algoritmu vektoru vzdálenosti:

  • 1) RIP je protokol, který funguje na tranzitních úsecích jako směrovací metrika. Maximální částka povolených skoků v RIP je 15 (metrika 16 znamená „nekonečně velká metrika“). Každý router RIP standardně vysílá své vlastní plný stůl směrování jednou za 30 sekund, poměrně silně zatěžující nízkorychlostní komunikační linky;
  • 2) EIGRP je směrovací protokol vyvinutý společností Cisco na základě protokolu IGRP stejné společnosti. Při výpočtu metriky se používá minimální šířka pásma (šířka pásma) pro danou trasu (a nikoli součet cen (nákladů) jako v případě OSPF), což umožňuje přesněji určit ziskovější cestu (trasu).

Pojďme tedy začít.

Články a videa o tom, jak nakonfigurovat hory OSPF. Popisů principů fungování je mnohem méně. Obecně jde o to, že OSPF lze jednoduše nakonfigurovat podle manuálů, aniž byste věděli o algoritmech SPF a nepochopitelných LSA. A všechno bude fungovat a dokonce s největší pravděpodobností bude fungovat perfektně - k tomu je určeno. To znamená, že to není jako u vlanů, kde jste museli znát teorii až po formát záhlaví.
Ale to, co odlišuje inženýra od IT, je to, že rozumí tomu, proč jeho síť funguje tak, jak funguje, a ví, o nic horší než samotný OSPF, jakou cestu protokol zvolí.
V rámci článku, který má v tuto chvíli již 8 000 znaků, se nebudeme moci ponořit do hlubin teorie, ale zvážíme základní body.
Je to velmi jednoduché a jasné, mimochodem se o OSPF píše na xgu.ru nebo na anglické Wikipedii.
OSPFv2 tedy funguje nad IP a konkrétně je určen pouze pro IPv4 (OSPFv3 nezávisí na protokolech vrstvy 3, a proto může pracovat s IPv6).

Podívejme se, jak to funguje na příkladu této zjednodušené sítě:

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

1) stejná nastavení musí být nakonfigurována v OSPF Ahoj Interval na těch routerech, které jsou vzájemně propojené. Ve výchozím nastavení je to 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 od souseda neobdrží žádné Hello, je považován za nedosažitelný a PANIK 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 jednu podsíť,
4) OSPF umožňuje snížit zatížení CPU routerů rozdělením autonomního systému do zón. Tak tady to je čí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 je vybrána z rozhraní aktivních v době spuštění procesu OSPF). Ale zase dobrý inženýr má vše pod kontrolou, takže většinou vznikne rozhraní Loopback, kterému je přidělena adresa s maskou /32 a ta je přiřazena k Router ID. To může být výhodné pro údržbu a odstraňování problémů.
6) Velikost MTU musí odpovídat

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 zvedá: router posílá Hello pakety na multicastovou adresu 224.0.0.5 ze všech rozhraní, kde běží OSPF. TTL takových zpráv je jedna, takže je obdrží pouze routery umístěné ve stejném segmentu sítě. R1 přechází do stavu INIT.

Balíčky obsahují 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
Aktuálně nás zajímají první čtyři, přesněji řečeno pouze Router ID a Neighbors.
Zpráva Hello z routeru R1 nese jeho Router ID a neobsahuje sousedy, protože je ještě nemá.
Po přijetí této multicastové zprávy router R2 přidá R1 do své sousední tabulky (pokud se všechny potřebné parametry shodují).

A odešle novou zprávu Hello na R1 pomocí Unicast, která obsahuje Router ID tohoto routeru a seznam Neigbors uvádí všechny jeho sousedy. 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 přijme tuto zprávu Hello od R2, projde 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:
- Jaké funkce a nastavení protokolu?
- Jsou tato nastavení globální nebo spojená s konkrétním rozhraním?
Pokud příkaz neznáte nebo jste zapomněli, takové úvahy vás s největší pravděpodobností dovedou do správného kontextu, kde můžete jednoduše pomocí nápovědy příkazový řádek, můžete hádat nebo si zapamatovat, jak nastavit, co je v úloze požadováno.
Zkuste tímto způsobem přemýšlet, než půjdete na Google nebo na jakýkoli web, který hledá příkazy.

Ve skutečné síti se při výběru rozsahu inzerovaných podsítí musíte řídit předpisy a okamžitými potřebami.

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 rozhraní FE0/0.2 msk-arbat-gw1, které je obráceno k serverům, pak bychom viděli, že zprávy Hello každých 10 sekund odlétají do neznáma. Na Hello není s kým reagovat, 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

Tento příkaz je nutné zadat pro všechna rozhraní, která rozhodně nemají sousedy OSPF (včetně těch směrem k internetu).
V důsledku toho budete mít obrázek jako tento:


*Nedokážu si představit, jak jsi se ještě nespletl*

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í přejdeme k nejzajímavější části – testování.
Na nastavení 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


Petrohrad, Kemerovo, Krasnojarsk a Vladivostok jsou přímo propojeny.
msk-arbat-gw1#sh IP cesta

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 ​​prostřednictvím 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




Každý o každém ví všechno.
Která trasa je přepravována z Moskvy do Krasnojarsku? Tabulka ukazuje, že krs-stolbi-gw1 je připojen přímo a totéž lze vidět ze stopy:



1 172.16.2.130 35 ms 8 ms 5 ms


Nyní roztrháme rozhraní mezi Moskvou a Krasnojarskem a uvidíme, jak dlouho bude trvat, než bude spojení obnoveno.
Neuplynulo ani 5 sekund, než 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í aktualizace z 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
Zadejte escape sekvenci k potratu.
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 znovu komunikují, vymění si databáze, přepočítají nejkratší cesty a zapíší je do routovací tabulky.
Video toto vše objasňuje. doporučuji seznámit se.

Jako kdokoli dobrý protokol OSPF podporuje ověřování – dva sousedé mohou ověřit pravost přijatých zpráv OSPF před navázáním sousedských vztahů. Nechte to zapnuté samostudium- docela jednoduché.

EIGRP

Nyní přejdeme k dalšímu velmi důležitému protokolu.

Co je tedy na EIGRP dobrého?
- snadná konfigurace
- rychlé přepnutí na předem vypočítané náhradní trasa
- vyžaduje méně prostředků routeru (ve srovnání s OSPF)
- sumarizace tras na libovolném routeru (v OSPF pouze na ABR\ASBR)
- vyvažování provozu na nerovných trasách (OSPF pouze na stejný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 s první prezentací EIGRP před mnoha lety a je obvykle chápáno jako „EIGRP vzal to nejlepší z protokolů link-state a distance-vector“. To absolutně není pravda. EIGRP nemá charakteristické rysy stav odkazu. Bylo by správné říci „EIGRP je pokročilý směrovací protokol pro 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á osiřelé trasy (nebo trasy s rostoucí metrikou). Všechny ostatní protokoly pasivně čekají na aktualizace 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 žádá si 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 pouze do doby, než byly zavedeny stub routery. S nimi (stejně jako s několika opravami algoritmu DUAL) je to téměř horší než OSPF.

- "Stejně jako protokoly LS, EIGRP udržuje tabulku topologie tras, které jsou vyměňovány." Je úžasné, jak je to špatně. EIGRP vůbec netuší, co je za jeho bezprostřední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 pořád úplně š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ě, ve kterých se nachází, sousedé, které vidí) prostřednictvím paketu (nebo několika) nazývaného LSA (v OSPF) nebo LSP (IS-IS)
- LSA se šíří 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 nepřibližuje, takže proč se proboha „chová jako LS“, není jasné.

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ů) dává EIGRP výhodu oproti RIP – může obsahovat informace o záložní (aktuálně nepoužívané) trase.

Nyní trochu blíže k teorii práce:

Každý proces EIGRP udržuje 3 tabulky:
- Tabulka sousedů, která obsahuje informace o „sousedech“, tzn. další routery přímo připojené k aktuálnímu a účastnící se výměny tras. Můžete jej zobrazit pomocí příkazu zobrazit ip sousedy eigrp
- Tabulka topologie sítě, která obsahuje informace o směrování přijaté od sousedů. Podívejme se jako tým zobrazit topologii ip eigrp
- Směrovací tabulka, na základě které router rozhoduje o přesměrování paketů. Zobrazit přes 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 Cioara: „Mám dojem, že tvůrci EIGRP, když se kriticky podívali na svůj výtvor, usoudili, že vše je příliš jednoduché a funguje dobře. A pak přišli s metrickým vzorcem, aby každý řekl: "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í v příkazech zobrazit rozhraní, zobrazit topologii ip eigrp a další 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 se ze všech 4 možných členů vzorce standardně používají 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 (přitom ne zapomínají, že se stále počítají podle vlastních vzorců). Je důležité si zapamatovat následující: metrika se počítá podle nejhorší ukazatel šířku pásma po celé délce trasy.

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

Pojďme si definovat pojmy používané v rámci EIGRP. Každá trasa v EIGRP je charakterizována dvěma čísly: Dosažitelná vzdálenost a Inzerovaná vzdálenost (místo Inzerovaná vzdálenost můžete někdy vidět Hlášenou vzdálenost, to je totéž). Každé z těchto čísel představuje metriku nebo cenu (čím více, tím horší) dané trasy různé body rozměry: FD je „ode mě do cíle“ a AD je „od souseda, který mi řekl o této trase do cíle“. Odpověď na logickou otázku „Proč potřebujeme znát náklady od souseda, když je již zahrnuta v FD?“ je o něco nižší (prozatím se můžete zastavit a polámat si hlavu, pokud chcete).

Pro každou podsíť, o které EIGRP ví, je na každém routeru z řad jeho 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 záložní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 záložní cesty (OSPF je má, ale jsou obsaženy takříkajíc v „raw formě“ v tabulce topologie; ještě je musí zpracovat algoritmus SPF), což mu dává výkonnostní výhoda: jakmile protokol zjistí, že hlavní cesta (přes následníka) je nedostupná, okamžitě se přepne na záložní cestu. 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á k zamezení směrovacích smyček.

Napadl vás předchozí odstavec? Materiál je obtížný, takže znovu použiji příklad. Máme tuto síť:

Z pohledu R1 je R2 nástupcem pro podsíť 192.168.2.0/24. Aby se R4 stal FS pro tuto podsíť, vyžaduje, 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šechno se sbíhá, AD R4 je menší než FD trasy, stává se FS. *pak mozek řekne: „BDASH“*. Nyní se podíváme na R3 - oznámí svou síť 192.168.1.0/24 svému 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řenáší informaci, že má přístup přes R4 do podsítě 192.168.1.0/24 dále do R1. R1 se přísně dívá na FD trasy a AD, kterými se R2 chlubí (které, jak je snadno pochopitelné z diagramu, bude jednoznačně větší než FD, protože ho také zahrnuje) a odežene ho, aby zasahovat do nejrůznějších nesmyslů. Tato situace je zcela nepravděpodobná, ale za určitých okolností může nastat, například když je mechanismus rozděleného horizontu vypnutý. A nyní k pravděpodobnější situaci: představte si, že R4 není připojen k síti 192.168.2.0/24 přes FastEthernet, ale přes 56k modem (zpoždění pro vytáčené připojení je 20 000 usec), podle toho ho to stojí ((10000000/56 )*256 )+(2000*256)= 46226176. To je více než FD pro tuto trasu, takže R4 se nestane proveditelným nástupcem. To ale neznamená, že EIGRP tuto cestu vůbec nevyužije. Přepnutí na něj bude trvat déle (o tom později).

sousedství
Směrovače nemluví o trasách jen tak s nikým – než si mohou začít vyměňovat informace, musí vytvořit sousedící vztahy. Po zapnutí procesu příkazem routeru eigrp s uvedením čísla autonomního systému příkazem network řekneme, která rozhraní se budou účastnit a zároveň informaci o tom, které sítě chceme distribuovat. Okamžitě se přes tato rozhraní začnou odesílat pakety hello na adresu multicast 224.0.0.10 (standardně každých 5 sekund pro ethernet). Všechny směrovače s povoleným EIGRP přijímají tyto pakety, pak každý přijímající směrovač dělá následující:
- zkontroluje adresu odesílatele paketu hello s adresou rozhraní, ze kterého byl paket přijat, a ujistí se, že jsou ze stejné podsítě
- porovnává hodnoty K-koeficientů získané z balíčku (jinými slovy, které proměnné se používají při výpočtu metriky) se svými vlastními. Je jasné, že pokud se budou lišit, budou metriky pro trasy počítány podle jiných pravidel, což je nepřijatelné
- zkontroluje číslo autonomního systému
- volitelné: pokud je nakonfigurováno ověřování, kontroluje konzistenci jeho typu a klíčů.

Pokud je příjemce se vším spokojen, přidá odesílatele do seznamu svých sousedů a zašle mu (již v Unicastu) 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éž. Pro výměnu tras používá EIGRP Reliable Transport Protocol (RTP, nezaměňovat s Real-time Transport Protocol, který se používá 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 byl 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 připojeni, a pokud se změní topologie, aktualizují pakety obsahující pouze informace o změnách (částečná aktualizace).

Nyní se vraťme k předchozímu schématu s modemem.

R2 z nějakého důvodu ztratil kontakt s 192.168.2.0/24. Nemá žádné záložní cesty do této podsítě (tj. žádný FS). Jako každý zodpovědný router EIGRP chce obnovit konektivitu. Za tímto účelem začne posílat speciální zprávy (dotazovací pakety) všem svým sousedům, kteří naopak sami nenajdou požadovanou cestu, zeptají se všech svých sousedů atd. Když vlna požadavků dosáhne R4, říká: „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 paketu s odpovědí 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 proveditelný nástupce, ale nakonec získáme komunikaci s podsítí.

A nyní je nebezpečný okamžik: možná jste si toho již všimli a po přečtení tohoto fanouškovského mailingu jste opatrní. Selhání 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 bude routerů, tím více prostředků bude vynaloženo na všechny tyto požadavky a odpovědi. Ale to není všechno tak špatné. Je možná horší situace: představte si, že routery zobrazené na obrázku jsou pouze součástí velkého a distribuovaná síť, tj. některé se mohou nacházet mnoho tisíc kilometrů od naší R2, na špatných kanálech atd. 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 možná někde na Aljašce stále existují žádosti. 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á, běží. Zde je však vše naopak: pasivní znamená „vše je v pořádku“ a aktivní stav znamená, že tato podsíť je nedostupná a router aktivně hledá jinou cestu, posílá dotaz a čeká na odpověď. Takže zaseknutý aktivní stav může trvat až 3 minuty! Po uplynutí této doby router přeruší 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: sečtení tras a takzvaná konfigurace pahýlu.

Obecně lze říci, že existuje ještě jedna cesta ven a nazývá se filtrování tras. To je ale tak objemné téma, že by bylo lepší napsat o něm samostatný článek, ale tentokrát už máme půlku knihy. Takže je to na vás.

Jak jsme již zmínili, v EIGRP lze sumarizaci tras provádět na jakémkoli routeru. Pro ilustraci si představme, že podsítě od 192.168.0.0/24 do 192.168.7.0/24 jsou připojeny k našemu trpělivému R2, což velmi pohodlně sečte až 192.168.0.0/21 (pamatujte na binární matematiku). Router inzeruje tuto souhrnnou trasu a všichni ostatní vědí: pokud cílová adresa začíná 192.168.0-7, je to pro něj. Co se stane, když jedna z podsítí zmizí? Router bude posílat pakety dotazů s adresou této sítě (konkrétní například 192.168.5.0/24), ale sousedé místo toho, aby svým jménem pokračovali v zlomyslné poště, okamžitě odpoví střízlivým přehráváním s tím, že toto je vaše podsíť, na to přijdete.

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 budete muset vrátit. Router nakonfigurovaný jako stub nebude předávat provoz mezi podsítěmi, které zná z EIGRP (jinými slovy, které jsou označeny písmenem D v show ip route). Jeho sousedé mu navíc nebudou posílat pakety dotazů. Nejběžnějším případem použití jsou topologie hub-and-spoke, zejména s redundantními linkami. Vezměme si tuto síť: vlevo jsou pobočky, vpravo hlavní web, hlavní kancelář atd. Pro odolnost proti chybám, redundantní odkazy. EIGRP běží 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 také podsíť za R2 (nebo R3) kvůli zvýšeným objemům provozu a jejich důsledkům. Právě pro 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“, pak teprve zpět. S lehkým srdcem je tedy můžeme nakonfigurovat jako pahýly, což nás za prvé ušetří výše nastíněného problému s „křivou cestou“ a za druhé záplavy dotazovacích paketů v případě ztráty trasy. .

Existovat různé režimy provoz 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
statické Inzerujte statické trasy
souhrn Inzerujte souhrnné trasy

Ve výchozím nastavení, pokud jednoduše zadáte příkaz eigrp stub, je povolen režim připojení a souhrnu. Zajímavostí je režim pouze pro příjem, ve kterém router neinzeruje žádné sítě, pouze poslouchá, co mu říkají jeho sousedé (v RIPu je příkaz pasivního rozhraní, který dělá to samé, ale v EIGRP protokol zcela vyřadí na vybraném rozhraní, které neumožňuje vytvoření sousedství).

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

  • Autentizaci souseda lze nakonfigurovat v EIGRP
  • Půvabný koncept vypnutí
Cvičení EIGRP

Lift mi Up koupil továrnu v Kaliningradu. Vyrábí se tam mozky výtahů: mikroobvody, software. Továrna je velmi velká - tři body po městě - tři routery spojené do kruhu.

Ale smůla - už mají EIGRP spuštěný 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 lokálních síťových adres se servery, tiskárnami, přístupovými body – což nebyla úloha na pár hodin – bylo odloženo na později a v plánu IP jsme rezervovali 172.16 podsíť pro budoucnost pro Kaliningrad .32.0/20.

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


Jak je tento zázrak nakonfigurován? Na první pohled nekomplikované:

router eigrp 1
síť 172.16.0.0 0.0.255.255
síť 10.0.0.0

V EIGRP může být zadána reverzní maska, čímž bude indikován užší rozsah, nebo nebude specifikována, pak bude vybrána standardní maska ​​pro tuto třídu (16 pro třídu B - 172.16.0.0 a 8 pro třídu 8 - 10.0.0.0)

Tyto příkazy jsou zadávány na všech směrovačích Autonomní systém. AC je určeno číslem v příkazu eigrp routeru, to znamená, že v našem případě máme AC č. 1. Tento údaj by měl 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 umístěny 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 sečtou, když je předají svým sousedům.
To znamená, že například msk-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íť je umístěna za msk-balt-gw1.
Co se ale stane, když najednou balt-gw1 přijme paket s cílem 10.0.50.243, o kterém nic neví? Pro tento případ je vytvořena tzv. Blackhole route:
10.0.0.0/8 je souhrn, 00:42:05, Null0
Výsledný paket bude vhozen do této černé díry. To se provádí, aby se zabránilo směrovacím smyčkám.
Oba tyto routery si tedy vytvořily své vlastní černé díry a ignorovaly oznámení ostatních lidí. Ve skutečnosti v takové síti tato tři zařízení nebudou moci vzájemně pingovat, dokud... dokud nezakážete automatické shrnutí.

První věc, kterou byste měli udělat při konfiguraci EIGRP, je:

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řenosu trasy mezi různými protokoly

Naším úkolem je zorganizovat přenos tras mezi těmito protokoly: z OSPF do EIGRP a naopak tak, aby každý znal cestu do jakékoli podsítě.
Tomu se říká redistribuce trasy.

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 EIGRP k 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

Tady jsou ty s označením E2 – nové importované trasy. E2 - znamená, že se jedná o externí cesty 2. typu (External), to znamená, že byly zavedeny do procesu OSPF zvenčí

Nyní od OSPF k EIGRP. Tohle je 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
….

Zdá se, že se to dělá jednoduchým způsobem, ale jednoduchost je povrchní - přerozdělování je plné mnoha jemných a nepříjemných momentů, kdy je přidán alespoň jeden nadbytečný odkaz mezi dvě různé domény.
Obecná rada – snažte se pokud možno vyhnout přerozdělování. Funguje zde hlavní životní pravidlo – čím jednodušší, tím lepší.

Výchozí trasa

Nyní je čas zkontrolovat váš přístup k internetu. Z Moskvy to funguje dobře, ale pokud se podíváte například z Petrohradu (nezapomeňte, že jsme smazali všechny statické trasy):
PC>ping linkmeup.ru

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 výchozí trase kromě msk-arbat-gw1, na které je staticky nakonfigurován.
Abychom tuto situaci napravili, musíme v Moskvě vydat jeden příkaz:
msk-arbat-gw1(config)#router ospf 1
msk-arbat-gw1(config-router)#default-information pocházejí

Poté se informace o tom, kde se nachází brána poslední instance, lavinovitě sypou po síti.

Internet je nyní k dispozici:

PC>tracert linkmeup.ru

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ů

1) Příkaz vyvolá seznam sousedů a stav komunikace s nimi zobrazit ip ospf souseda

msk-arbat-gw1:

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 spouštění dynamických směrovacích protokolů a jejich vztahů.

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á sumarizace adres:
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 škubnout různá rozhraní a uvidíte, co se děje v ladění, jaké zprávy létají.

Problém č. 7
Konečně komplexní problém.
Na posledním zasedání Lift mi Up bylo rozhodnuto, že i kaliningradská síť by měla být převedena na OSPF.
Přechod musí být dokončen bez přerušení spojení. Bylo rozhodnuto, že nejlepší možností by bylo zvýšit OSPF na tři routery Kaliningrad a poté, co bylo ověřeno, že se všechny informace o kaliningradských trasách rozšířily po zbytku sítě a naopak, deaktivujte EIGRP. pro logo webu. Přidat štítky

Síť Lift mi 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 Up“.
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. Souhlasím, ruční přidávání tras do všech sítí v každém uzlu 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:

  • Pojďme pochopit teorii dynamických směrovacích protokolů.
  • Do sítě zavádíme „Lift mi Up“. protokol OSPF
  • Konfigurace přenosu (přerozdělení) tras mezi OSPF a EIGRP
  • V této verzi přidáváme sekci „Úkoly“. Následující ikony je pomohou identifikovat v celém článku:
Úroveň obtížnosti se bude lišit. Všechny problémy budou mít odpovědi, které lze zobrazit na. V některých z nich budete muset přemýšlet, v jiných budete muset číst dokumentaci, v jiných budete muset porozumět topologii a možná se i podívat na informace o ladění. Pokud úlohu nelze implementovat v RT, učiníme o tom zvláštní poznámku.

Teorie dynamického směrovacího protokolu

Nejprve pochopme pojem „dynamické směrování“. Dosud jsme používali tzv. statické směrování, to znamená, že jsme na každý směrovač ručně psali směrovací tabulku. Použití směrovacích protokolů nám umožňuje vyhnout se tomuto zdlouhavému, monotónnímu procesu a lidským chybám. Jak název napovídá, tyto protokoly jsou navrženy tak, aby samy sestavovaly směrovací tabulky, automaticky na základě aktuální konfigurace sítě. Obecně je to nezbytná věc, zvláště když vaše síť nemá 3 routery, ale například 30.
Kromě pohodlí existují i ​​další aspekty. Například, odolnost proti chybám. Mít síť s statické směrování, bude pro vás nesmírně obtížné organizovat záložní kanály- není nikdo, kdo by hlídal dostupnost konkrétního segmentu.

Pokud se například v takové síti přeruší spojení mezi R2 a R3, pak pakety z R1 budou nadále směřovat 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 popsané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 přidávat redundantní cesty ručně jejich výpočtem.

Implementace dynamického směrování to 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 s minimální pravděpodobností chyby a informace o změnách jsou okamžitě sdíleny napříč všemi zařízeními. Přesně totéž lze říci o změnách globální topologie.

Všechny směrovací protokoly lze rozdělit do dvou velké skupiny: externí ( E.G.P.- 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 v obecném smyslu, autonomní systém (směrovací doména) je skupina směrovačů pod společnou správou.
V případě naší aktualizované AS sítě to bude 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, nebudeme se dotýkat protokolů RIP a IGRP kvůli jejich úctyhodnému stáří, 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. Co se stane, když na routeru spustíte několik protokolů současně? Může se stát, že každý protokol bude mít svůj vlastní názor na to, jak nejlépe dosáhnout konkrétní sítě. Co když máme také nakonfigurované statické trasy? Komu dá router přednost a čí trasu přidá do routovací tabulky? Odpověď na tuto otázku je spojena s novým pojmem: administrativní vzdálenost (na náš vkus spíše průměrná kopie anglického administrativního odstupu, ale lepší nemohli vymyslet). Administrativní vzdálenost je celé číslo od 0 do 255, vyjadřující „míru spolehlivosti“ routeru v této trase. Čím menší AD, tím větší důvěra. Zde je známka takové důvěry z pohledu společnosti Cisco:

ProtokolAdministrativní vzdálenost
Připojené rozhraní0
Statická trasa1
Souhrnná trasa protokolu EIGRP (Enhanced Interior Gateway Routing Protocol).5
Protokol BGP (External Border Gateway Protocol)20
Interní EIGRP90
IGRP100
OSPF110
Intermediate System-to-Intermediate System (IS-IS)115
Routing Information Protocol (RIP)120
Exterior Gateway Protocol (EGP)140
Směrování na vyžádání (ODR)160
Externí EIGRP170
Interní BGP200
Neznámý255

V dnešním článku se podíváme na 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 je lepší než 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 o tom se v populárních článcích nijak zvlášť nemluví. Zde je jen jeden z problémů: SIA

Pojďme tedy začít.

OSPF

Články a videa o tom, jak nakonfigurovat hory OSPF. Popisů principů fungování je mnohem méně. Obecně jde o to, že OSPF lze jednoduše nakonfigurovat podle manuálů, aniž byste věděli o algoritmech SPF a nepochopitelných LSA. A všechno bude fungovat a dokonce s největší pravděpodobností bude fungovat perfektně - k tomu je určeno. To znamená, že to není jako u vlanů, kde jste museli znát teorii až po formát záhlaví.
Ale to, co odlišuje inženýra od IT, je to, že rozumí tomu, proč jeho síť funguje tak, jak funguje, a ví, o nic horší než samotný OSPF, jakou cestu protokol zvolí.
V rámci článku, který má v tuto chvíli již 8 000 znaků, se nebudeme moci ponořit do hlubin teorie, ale zvážíme základní body.
Je to velmi jednoduché a jasné, mimochodem se o OSPF píše na xgu.ru nebo na anglické Wikipedii.
OSPFv2 tedy funguje nad IP a konkrétně je určen pouze pro IPv4 (OSPFv3 nezávisí na protokolech vrstvy 3, a proto může pracovat s IPv6).

Podívejme se, jak to funguje na příkladu této zjednodušené sítě:

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

1) stejná nastavení musí být nakonfigurována v OSPF Ahoj Interval na těch routerech, které jsou vzájemně propojené. Ve výchozím nastavení je to 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 od souseda neobdrží žádné Hello, je považován za nedosažitelný a PANIK 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 jednu podsíť,
4) OSPF umožňuje snížit zatížení CPU routerů rozdělením autonomního systému do zón. Tak tady to je čí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 je vybrána z rozhraní aktivních v době spuštění procesu OSPF). Ale zase dobrý inženýr má vše pod kontrolou, takže většinou vznikne rozhraní Loopback, kterému je přidělena adresa s maskou /32 a ta je přiřazena k Router ID. To může být výhodné pro údržbu a odstraňování problémů.
6) Velikost MTU musí odpovídat

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 zvedá: router posílá Hello pakety na multicastovou adresu 224.0.0.5 ze všech rozhraní, kde běží OSPF. TTL takových zpráv je jedna, takže je obdrží pouze routery umístěné ve stejném segmentu sítě. R1 přechází do stavu INIT.

Balíčky obsahují 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
Aktuálně nás zajímají první čtyři, přesněji řečeno pouze Router ID a Neighbors.
Zpráva Hello z routeru R1 nese jeho Router ID a neobsahuje sousedy, protože je ještě nemá.
Po přijetí této multicastové zprávy router R2 přidá R1 do své sousední tabulky (pokud se všechny potřebné parametry shodují).

A odešle novou zprávu Hello na R1 pomocí Unicast, která obsahuje Router ID tohoto routeru a seznam Neigbors uvádí všechny jeho sousedy. 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 přijme tuto zprávu Hello od R2, projde 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:
- Jaké funkce a nastavení protokolu?
- Jsou tato nastavení globální nebo spojená s konkrétním rozhraním?
Pokud příkaz neznáte nebo jste zapomněli, takové úvahy vás s největší pravděpodobností zavedou do správného kontextu, kde můžete jednoduše hádat nebo si zapamatovat, jak nakonfigurovat, co je v úloze požadováno, pomocí nápovědy na příkazovém řádku.
Zkuste tímto způsobem přemýšlet, než půjdete na Google nebo na jakýkoli web, který hledá příkazy.
Ve skutečné síti se při výběru rozsahu inzerovaných podsítí musíte řídit předpisy a okamžitými potřebami.

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 rozhraní FE0/0.2 msk-arbat-gw1, které je obráceno k serverům, pak bychom viděli, že zprávy Hello každých 10 sekund odlétají do neznáma. Na Hello není s kým reagovat, 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

Tento příkaz je nutné zadat pro všechna rozhraní, která rozhodně nemají sousedy OSPF (včetně těch směrem k internetu).
V důsledku toho budete mít obrázek jako tento:


*Nedokážu si představit, jak jsi se ještě nespletl*

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í přejdeme k nejzajímavější části – testování.
Na nastavení 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

Petrohrad, 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 ​​prostřednictvím 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



Každý o každém ví všechno.
Která trasa je přepravována z Moskvy do Krasnojarsku? Tabulka ukazuje, že krs-stolbi-gw1 je připojen přímo a totéž lze vidět ze stopy:


msk-arbat-gw1#traceroute 172.16.128.1

1 172.16.2.130 35 ms 8 ms 5 ms

Nyní roztrháme rozhraní mezi Moskvou a Krasnojarskem a uvidíme, jak dlouho bude trvat, než bude spojení obnoveno.
Neuplynulo ani 5 sekund, než 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í aktualizace z 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
Zadejte escape sekvenci k potratu.
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 znovu komunikují, vymění si databáze, přepočítají nejkratší cesty a zapíší je do routovací tabulky.
Video toto vše objasňuje. doporučuji seznámit se.

Po nastavení OSPF na routerech v sibiřském kruhu se všechny sítě, které se nacházejí za routerem, do centrála v Moskvě (msk-arbat-gw1), pro Chabarovsk jsou dostupné na dvou trasách (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 pouze v případě, že by se něco stalo s kanálem do Krasnojarsku.

Jako každý dobrý protokol podporuje OSPF autentizaci – dva sousedé mohou ověřit pravost přijatých zpráv OSPF před navázáním sousedských vztahů. Necháme na vás, abyste se učili sami – je to docela jednoduché.

EIGRP

Nyní přejdeme k dalšímu velmi důležitému protokolu.

Co je tedy na EIGRP dobrého?
- snadná konfigurace
- rychlé přepnutí na předem vypočítané náhradní trasa
- vyžaduje méně prostředků routeru (ve srovnání s OSPF)
- sumarizace tras na libovolném routeru (v OSPF pouze na ABR\ASBR)
- vyvažování provozu na nerovných trasách (OSPF pouze na stejný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 s první prezentací EIGRP před mnoha lety a je obvykle chápáno jako „EIGRP vzal to nejlepší z protokolů link-state a distance-vector“. To absolutně není pravda. EIGRP nemá žádné výrazné rysy stavu propojení. Bylo by správné říci „EIGRP je pokročilý směrovací protokol pro 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á osiřelé trasy (nebo trasy s rostoucí metrikou). Všechny ostatní protokoly pasivně čekají na aktualizace 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 žádá si 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 pouze do doby, než byly zavedeny stub routery. S nimi (stejně jako s několika opravami algoritmu DUAL) je to téměř horší než OSPF.
- "Stejně jako protokoly LS, EIGRP udržuje tabulku topologie tras, které jsou vyměňovány." Je úžasné, jak je to špatně. EIGRP vůbec netuší, co je za jeho bezprostřední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 pořád úplně š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ě, ve kterých se nachází, sousedé, které vidí) prostřednictvím paketu (nebo několika) nazývaného LSA (v OSPF) nebo LSP (IS-IS)
- LSA se šíří 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 nepřibližuje, takže proč se proboha „chová jako LS“, není jasné.

Jediná věc, kterou EIGRP dělá, je uchovávání informací přijatých od souseda (RIP okamžitě zapomene, co nelze v tuto chvíli použít). V tomto smyslu je to obdoba BGP, která také vše ukládá do tabulky BGP a odtud vybírá nejlepší trasu. Tabulka topologie (obsahující všechny informace přijaté od sousedů) dává EIGRP výhodu oproti RIP – může obsahovat informace o záložní (aktuálně nepoužívané) trase.


Nyní trochu blíže k teorii práce:

Každý proces EIGRP udržuje 3 tabulky:
- Tabulka sousedů, která obsahuje informace o „sousedech“, tzn. další routery přímo připojené k aktuálnímu a účastnící se výměny tras. Můžete jej zobrazit pomocí příkazu zobrazit ip sousedy eigrp
- Tabulka topologie sítě, která obsahuje informace o směrování přijaté od sousedů. Podívejme se jako tým zobrazit topologii ip eigrp
- Směrovací tabulka, na základě které router rozhoduje o přesměrování paketů. Zobrazit přes 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 Cioara: „Mám dojem, že tvůrci EIGRP, když se kriticky podívali na svůj výtvor, usoudili, že vše je příliš jednoduché a funguje dobře. A pak přišli s metrickým vzorcem, aby každý řekl: "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í v příkazech zobrazit rozhraní, zobrazit topologii ip eigrp a další 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 se ze všech 4 možných členů vzorce standardně používají 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 (přitom ne zapomínají, že se stále počítají podle vlastních vzorců). Je důležité si zapamatovat následující: metrika se počítá podle nejhorší ukazatel propustnosti 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 se skutečně přenášejí při výměně tras. Ale jak vidíme z celého vzorce, o MTU tam není žádná zmínka. Faktem je, že tento indikátor se bere v úvahu ve zcela specifických případech: pokud například router musí zahodit jednu z tras, které jsou ekvivalentní v jiných charakteristikách, vybere si tu s nižší MTU. I když, ne všechno je tak jednoduché (viz komentáře).

Pojďme si definovat pojmy používané v rámci EIGRP. Každá trasa v EIGRP je charakterizována dvěma čísly: Dosažitelná vzdálenost a Inzerovaná vzdálenost (místo Inzerovaná vzdálenost můžete někdy vidět Hlášenou vzdálenost, to je totéž). Každé z těchto čísel představuje metriku nebo cenu (čím více, tím horší) dané trasy z různých měřicích bodů: FD je „ode mě do cíle“ a AD je „od souseda, který mi řekl o této trase do schůzky na místě." Odpověď na logickou otázku „Proč potřebujeme znát náklady od souseda, když je již zahrnuta v FD?“ je o něco nižší (prozatím se můžete zastavit a polámat si hlavu, pokud chcete).

Pro každou podsíť, o které EIGRP ví, je na každém routeru z řad jeho 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 záložní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 záložní cesty (OSPF je má, ale jsou obsaženy takříkajíc v „raw formě“ v tabulce topologie; ještě je musí zpracovat algoritmus SPF), což mu dává výkonnostní výhoda: jakmile protokol zjistí, že hlavní cesta (přes následníka) je nedostupná, okamžitě se přepne na záložní cestu. 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á k zamezení směrovacích smyček.

Napadl vás předchozí odstavec? Materiál je obtížný, takže znovu použiji příklad. Máme tuto síť:

Z pohledu R1 je R2 nástupcem pro podsíť 192.168.2.0/24. Aby se R4 stal FS pro tuto podsíť, vyžaduje, 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šechno se sbíhá, AD R4 je menší než FD trasy, stává se FS. *pak mozek řekne: „BDASH“*. Nyní se podíváme na R3 - oznámí svou síť 192.168.1.0/24 svému 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řenáší informaci, že má přístup přes R4 do podsítě 192.168.1.0/24 dále do R1. R1 se přísně dívá na FD trasy a AD, kterými se R2 chlubí (které, jak je snadno pochopitelné z diagramu, bude jednoznačně větší než FD, protože ho také zahrnuje) a odežene ho, aby zasahovat do nejrůznějších nesmyslů. Tato situace je zcela nepravděpodobná, ale za určitých okolností může nastat, například když je mechanismus rozděleného horizontu vypnutý. A nyní k pravděpodobnější situaci: představte si, že R4 není připojen k síti 192.168.2.0/24 přes FastEthernet, ale přes 56k modem (zpoždění pro vytáčené připojení je 20 000 usec), podle toho ho to stojí ((10000000/56 )*256 )+(2000*256)= 46226176. To je více než FD pro tuto trasu, takže R4 se nestane proveditelným nástupcem. To ale neznamená, že EIGRP tuto cestu vůbec nevyužije. Přepnutí na něj bude trvat déle (o tom později).

Sousedství
Směrovače nemluví o trasách jen tak s nikým – než si mohou začít vyměňovat informace, musí vytvořit sousedící vztahy. Po zapnutí procesu příkazem routeru eigrp s uvedením čísla autonomního systému příkazem network řekneme, která rozhraní se budou účastnit a zároveň informaci o tom, které sítě chceme distribuovat. Okamžitě se přes tato rozhraní začnou odesílat pakety hello na adresu multicast 224.0.0.10 (standardně každých 5 sekund pro ethernet). Všechny směrovače s povoleným EIGRP přijímají tyto pakety, pak každý přijímající směrovač dělá následující:
- zkontroluje adresu odesílatele paketu hello s adresou rozhraní, ze kterého byl paket přijat, a ujistí se, že jsou ze stejné podsítě
- porovnává hodnoty K-koeficientů získané z balíčku (jinými slovy, které proměnné se používají při výpočtu metriky) se svými vlastními. Je jasné, že pokud se budou lišit, budou metriky pro trasy počítány podle jiných pravidel, což je nepřijatelné
- zkontroluje číslo autonomního systému
- volitelné: pokud je nakonfigurováno ověřování, kontroluje konzistenci jeho typu a klíčů.

Pokud je příjemce se vším spokojen, přidá odesílatele do seznamu svých sousedů a zašle mu (již v Unicastu) 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éž. Pro výměnu tras používá EIGRP Reliable Transport Protocol (RTP, nezaměňovat s Real-time Transport Protocol, který se používá 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 byl 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 připojeni, a pokud se změní topologie, aktualizují pakety obsahující pouze informace o změnách (částečná aktualizace).

Nyní se vraťme k předchozímu schématu s modemem.

R2 z nějakého důvodu ztratil kontakt s 192.168.2.0/24. Nemá žádné záložní cesty do této podsítě (tj. žádný FS). Jako každý zodpovědný router EIGRP chce obnovit konektivitu. Za tímto účelem začne posílat speciální zprávy (dotazovací pakety) všem svým sousedům, kteří naopak sami nenajdou požadovanou cestu, zeptají se všech svých sousedů atd. Když vlna požadavků dosáhne R4, říká: „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 paketu s odpovědí 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 proveditelný nástupce, ale nakonec získáme komunikaci s podsítí.

A nyní je nebezpečný okamžik: možná jste si toho již všimli a po přečtení tohoto fanouškovského mailingu jste opatrní. Selhání 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 bude routerů, tím více prostředků bude vynaloženo na všechny tyto požadavky a odpovědi. Ale to není všechno tak špatné. 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ých kanálech atd. 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 možná někde na Aljašce stále existují žádosti. 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á, běží. Zde je však vše naopak: pasivní znamená „vše je v pořádku“ a aktivní stav znamená, že tato podsíť je nedostupná a router aktivně hledá jinou cestu, posílá dotaz a čeká na odpověď. Takže zaseknutý aktivní stav může trvat až 3 minuty! Po uplynutí této doby router přeruší 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: sečtení tras a takzvaná konfigurace pahýlu.

Obecně lze říci, že existuje ještě jedna cesta ven a nazývá se filtrování tras. To je ale tak objemné téma, že by bylo lepší napsat o něm samostatný článek, ale tentokrát už máme půlku knihy. Takže je to na vás.

Jak jsme již zmínili, v EIGRP lze sumarizaci tras provádět na jakémkoli routeru. Pro ilustraci si představme, že podsítě od 192.168.0.0/24 do 192.168.7.0/24 jsou připojeny k našemu trpělivému R2, což velmi pohodlně sečte až 192.168.0.0/21 (pamatujte na binární matematiku). Router inzeruje tuto souhrnnou trasu a všichni ostatní vědí: pokud cílová adresa začíná 192.168.0-7, je to pro něj. Co se stane, když jedna z podsítí zmizí? Router bude posílat pakety dotazů s adresou této sítě (konkrétní například 192.168.5.0/24), ale sousedé místo toho, aby svým jménem pokračovali v zlomyslné poště, okamžitě odpoví střízlivým přehráváním s tím, že toto je vaše podsíť, na to přijdete.

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 budete muset vrátit. Router nakonfigurovaný jako stub nebude předávat provoz mezi podsítěmi, které zná z EIGRP (jinými slovy, které jsou označeny písmenem D v show ip route). Jeho sousedé mu navíc nebudou posílat pakety dotazů. Nejběžnějším případem použití jsou topologie hub-and-spoke, zejména s redundantními linkami. Vezměme si tuto síť: vlevo jsou pobočky, vpravo hlavní web, hlavní kancelář atd. Pro odolnost proti chybám, redundantní odkazy. EIGRP běží 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 také podsíť za R2 (nebo R3) kvůli zvýšeným objemům provozu a jejich důsledkům. Právě pro 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“, pak teprve zpět. S lehkým srdcem je tedy můžeme nakonfigurovat jako pahýly, což nás za prvé ušetří výše nastíněného problému s „křivou cestou“ a za druhé záplavy dotazovacích paketů v případě ztráty trasy. .

Existují různé režimy provozu stub routeru, které se nastavují pomocí příkazu 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
statické Inzerujte statické trasy
souhrn Inzerujte souhrnné trasy
Ve výchozím nastavení, pokud jednoduše zadáte příkaz eigrp stub, je povolen režim připojení a souhrnu. Zajímavostí je režim pouze pro příjem, ve kterém router neinzeruje žádné sítě, pouze poslouchá, co mu říkají jeho sousedé (v RIPu je příkaz pasivního rozhraní, který dělá to samé, ale v EIGRP protokol zcela vyřadí na vybraném rozhraní, které neumožňuje vytvoření sousedství).

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

  • Autentizaci souseda lze nakonfigurovat v EIGRP
  • Půvabný koncept vypnutí
Cvičení EIGRP
Lift mi Up koupil továrnu v Kaliningradu. Vyrábí se tam mozky výtahů: mikroobvody, software. Továrna je velmi velká - tři body po městě - tři routery spojené do kruhu.

Ale smůla - už mají EIGRP spuštěný 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 lokálních síťových adres se servery, tiskárnami, přístupovými body – což nebyla úloha na pár hodin – bylo odloženo na později a v plánu IP jsme rezervovali 172.16 podsíť pro budoucnost pro Kaliningrad .32.0/20.

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

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

V EIGRP může být zadána reverzní maska, čímž bude indikován užší rozsah, nebo nebude specifikována, 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)

Tyto příkazy jsou vydávány na všech směrovačích autonomního systému. AC je určeno číslem v příkazu eigrp routeru, to znamená, že v našem případě máme AC č. 1. Tento údaj by měl 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 umístěny 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 sečtou, když je předají 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 za klgr-balt-gw1 se nachází celá tato síť.
Co se ale stane, když najednou balt-gw1 přijme paket s cílem 10.0.50.243, o kterém nic neví? Pro tento případ je vytvořena tzv. Blackhole route:
10.0.0.0/8 je souhrn, 00:42:05, Null0
Výsledný paket bude vhozen do této černé díry. To se provádí, aby se zabránilo směrovacím smyčkám.
Oba tyto routery si tedy vytvořily své vlastní černé díry a ignorovaly oznámení ostatních lidí. Ve skutečnosti v takové síti tato tři zařízení nebudou moci vzájemně pingovat, dokud... dokud nezakážete automatické shrnutí.

První věc, kterou byste měli udělat při konfiguraci EIGRP, je:
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řenosu trasy mezi různými protokoly

Naším úkolem je zorganizovat přenos tras mezi těmito protokoly: z OSPF do EIGRP a naopak tak, aby každý znal cestu do jakékoli podsítě.
Tomu se říká redistribuce trasy.

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


Tady jsou ty s označením E2 – nové importované trasy. E2 - znamená, že se jedná o externí cesty 2. typu (External), to znamená, že byly zavedeny do procesu OSPF zvenčí

Nyní od OSPF k EIGRP. Tohle je 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
….


Zdá se, že se to dělá jednoduchým způsobem, ale jednoduchost je povrchní - přerozdělování je plné mnoha jemných a nepříjemných momentů, kdy je přidán alespoň jeden nadbytečný odkaz mezi dvě různé domény.
Obecná rada – snažte se pokud možno vyhnout přerozdělování. Funguje zde hlavní životní pravidlo – čím jednodušší, tím lepší.

Výchozí trasa

Nyní je čas zkontrolovat váš přístup k internetu. Z Moskvy to funguje dobře, ale pokud se podíváte například z Petrohradu (nezapomeňte, že jsme smazali všechny statické trasy):
PC>ping

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 výchozí trase kromě msk-arbat-gw1, na které je staticky nakonfigurován.
Abychom tuto situaci napravili, musíme v Moskvě vydat jeden příkaz:
msk-arbat-gw1(config)#router ospf 1
msk-arbat-gw1(config-router)#default-information pocházejí

Poté se informace o tom, kde se nachází brána poslední instance, lavinovitě sypou po síti.

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ů

1) Příkaz vyvolá seznam sousedů a stav komunikace s nimi zobrazit ip ospf souseda
msk-arbat-gw1:

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 spouštění dynamických směrovacích protokolů a jejich vztahů.

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á sumarizace adres:
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 vyzkoušet různá rozhraní a uvidíte, co se děje v ladění, jaké zprávy létají.

Autoři

Maratský eukariot
Maxim alias gluck

Rád bych vyjádřil svou vděčnost Dmitriji JDimovi za úpravy a neocenitelné komentáře a neodolatelně Nataše Samoilenko za poskytnuté úkoly. Antonu Avtushkovi za programování blogu. A dívce se slavným jménem Nina za logo webu.

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

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



Oblíbené v kategorii:
Jak zkombinovat vrstvy ve Photoshopu do jedné nebo je spojit do skupiny Jak zkombinovat několik vrstev ve Photoshopu
Jak sloučit vrstvy ve Photoshopu do jedné nebo je spojit do skupiny...
číst
Přeneste kontakty do nového telefonu Android
Přeneste kontakty do nového telefonu Android
číst
Samsung Galaxy se restartuje sám – Solutions Galaxy note 4 se restartuje sám
Samsung Galaxy se sám restartuje – řešení Galaxy Note...
číst
Klíčové vlastnosti Kaspersky Rescue Disk
Klíčové vlastnosti Kaspersky Rescue Disk
číst

poslední články
MacBook se nepřipojí k wifi MacBook nevidí...
číst
Jak vydělat peníze na WebMoney
číst
Tablet "Supra": recenze zákazníků
číst
Umístění lodí v reálném čase
číst
Nejlepší programy pro Android Záznam hovorů z...
číst
Odebírání nesledujících na Twitteru
číst
Připojení k internetu na notebooku: všechny možné...
číst
Samsung Galaxy S IV je nová vlajková loď...
číst
Horní