Archív autora

Hľadáte hodnoty EIGRP timer-ov?

11 januára, 2011

Zdravím Vás kolegovia.

Veľmi často sa v teórii na našich CCNA kurzoch stretávate s nutnosťou zistiť alebo overiť hodnoty časovačov alebo “timerov” v smerovacích protokoloch. RIP a OSPF problémové nie sú, EIGRP na druhej strane má niekoľko záľudností v tom ako časovače v tomto protokole fungujú.

Na nasledovnom obrázku je ukážka z našich prezentácií, na ktorom sú zhrnuté príklady fungovania časovačou v protokoloch RIP, OSPF a EIGRP.

ste si všimli, že EIGRP hold-down timer nie je používaný lokálne na smerovači, ale je spolu s hello paketom odoslaný k susedovi, a susedný smerovač bude vami nastavený hold-down timer používať na Vás!

Toto fungovanie, akokoľvek užitočné, malo v starších verziách IOS systému problém, že ste pomocou show príkazov nemali možnosť poriadne zistiť hodnoty hello a hold-down časovačov nastavených na rozhraniach.

Jediné čo sa dalo zistiť bol hello časovač pomocou príkazu “show ip eigrp interface detail”. Ukážku môžete vidieť na nasledovnom obrázku.

novšom však nájdeme tento príkaz dostatočne obohatený a môžeme tak vďaka tomuto príkazu zistiť aj hold-down timer.

Na predošlom obrázku si všimnite nastavovanie týchto časovačov pre každé rozhranie samostatne.

PS: Pre vaše potreby príkazy na nastavenie týchto časovačov sú “ip hello-interval eigrp 1 25” a “ip hold-time eigrp 1 100”. Tieto príkazy nastanie pre EIGRP v AS “1” časovače hello na 25 sekúnd a hold-down na 100 sekúnd.

Preto ak na teste CCNA2 dostanete EIGRP zadanie a nieto po Vás bude chcieť overiť EIGRP hodnoty časovačov, ak Vám spomenutý “show” príkaz nedá hodnotu hold-down časovača, musíte sa upokojiť bude s prehľadaním “show running-config”.

Druhá možnosť je pozerať meniace sa hodnoty na susednom smerovači v “show ip eigrp neighbour”  až dokiaľ sa hodnota hold-down suseda neinkrementuje na novú hold-down hodnotu. Ukážku si môžete pozrieť na nasledovnom obrázku.

Ďakujem Vám za pozornosť a dúfam, že ste si takto so mnou mohli zhrnúť problematiku hľadania hodnôt časovačov v EIGRP.

S pozdravom

Peter Havrila, CCNP, Inštruktor RCNA FIIT STU

Distance-Vector spravanie v OSPF?

2 januára, 2011

Väčšinu z Vás na našich kurzoch CCNA učíme o OSPF ako o link-state protokole, ktorý je založený na Dijkstrovom algoritme. Ako už väčšina z Vás po druhom semestri CCNA vie, na rozdiel od protokolov ako je RIP a EIGRP, protokol OSPF pozná celú topológiu a tak sa vie vyhnúť problémom s topologickými slučkami. V tomto článku Vám túto predstavu naštrbím.

Táto predstava, ktorá je v rámci CCNA vyučovaná je uplne správna a na certifikciu ju máte vedieť presne tak, ako Vás ju na OSPF prednáškach učime. Ale svet je troška vačší ako CCNA.

Menej ľudí vie, že protokol OSPF má aj svoju “distance-vector” tvár, ktorú na CCNA nespoznáte (na CCNP sa už s Oblasťami v OSPF stretnete v plnej miere, ale tieto pravidlá sa tam len nechaju “tušiť” a nie su súčastou učiva vyžadovaného na certifikácií).

Tento distance-vector charakter OSPF sa prejavuje keď začneme s OSPF riešiť väčšie siete, ktoré využívaju viacero OSPF oblastí (OSPF Area). Podstata celého problému je, že OSPF je link-state využívajúci Dijkstrov algoritmus iba v rámci jednej oblasti.

To znamená, že topologicky strom sa vypočítava len pre jednu oblast a jeho “vetvy” nesiahaju do iných oblastí. Z tohto dovodu ak máme medzi oblastami viacero hraničných smerovačov (ABR – Area Boarder Router), tak OSPF sa znova vracia “iba” k fungovaniu na úrovni distance-vector protokolom a je tu náchylnosť na smerovacie slučky.

Poďme pekne poporiadku…

Čo CCNA ľudia ešte len tušia a CCNP ludia uz vedia je, že OSPF si vymiena informácie pomocou vytvárania susedstva a následne pomocou takzvaných LSA (Link-State Advertisement) paketov. Týchto LSA-čok má OSPF viacero druhov (každý identifikovaný číslom), z ktorých by som rád spomenul iba nasledovné:

  1. Router LSA (informácie o pritomnosti smerovača v oblasti)
  2. Network LSA (informácie o prefixe alebo podsieti v oblasti)
  3. Inter-Area network summary LSA (informácie o prefixe mimo oblasti v ktorej sa tento LSA typ vyskytuje)

Teraz k tomu ako sa tieto LSA šíria. V rámci jedneho SPF (shortest path first) stromu, ktorý je výsledkom Dijkstrovho algoritmu, sa berú do úvahy iba LSA typu 1 a 2 (vetu nebrať doslovne, tiež nie je celou pravdou ale to je mimo tohto článku). Teda iba tie o smerovačoch a sieťach v jednej oblasti. LSA typu 3 však vznikajú inak.

LSA typu 3 generujú ABR smerovače keď chcú preniesť informáciu o prefixe alebo sumarizovanom prefixe z jednej oblasti do inej.

Pre lepšiu názornosť prejdime k diagramu:

Ak by sme ostali iba pri logike OSPF vyučovanej na CCNA úrovni, záplava LSA paketov by mohla sposobit slučku nakoľko R1,R3 a R4 by nevedeli pri vytváraní LSA typu 3 rozlíšiť, kde v sieti sa reálne prefixy a iných oblastí nachádzaju. Napríklad sieť 5.100.5.0/24 by mohla byť šírená ako LSA 2 v rámci Area 2. Potom by však smerovače R3 a R4 tento LSA prevzali, vygenerovali by pre tento prefix LSA typu 3 a preposlali do oblastí Area 1 a Area 0. Problém by však mohol nastat, ak by R1 ako ďaľší ABR smerovač tieto LSA typu 3 preposlal tiež medzi  oblastami 1 a 0. Nakoľko R1 vo svojom Dijkstrovom SPF strome nevie presne povedať, kde sa reálne táto cielová sieť nachádza, tak pre tuto sieť z Area 2 nevie smerovač R1 fungovať inak ako na distance-vector princípoch.

Takže ako OSPF pre ABS smerovačoch postupuje? Má na to tri pravidlá:

  1. ABR sa pokladá za ABR ak aspon jedno jeho rozhranie je v Area 0 a toto rozhranie nie je v stave DOWN. Ak je táto podmienka splnená tak uz vo svojich LSA typu 1 nastavuje príznak “B” (Border) a v rámci oblasti tým oznamuje ze je ABR smerovačom.
  2. Ak má ABR v Area 0 vytvorené aspoň jedno susedstvo v stave FULL, tak ABR očakáva LSA typu 3 LEN z Area 0 a ignoruje LSA typu 3 z iných oblastí!
  3. ABR akceptuje a použíje na smerovanie LSA typu 3 naučené z iných oblastí ako Area 0 len v prípade ak NEMA v Area 0 vytvorené žiadne susedstvo. Len v tomto prípade je prijatie týchto LSA typu 3 bezpečné.

Pre náš diagram siete to znamená, že prefix 5.100.5.0/24 sa bude šíriť ako LSA typu 2 v rámci Area 2. Smerovač R4 generuje LSA typu 3 pre tento prefix pre Area 0 (platí prve pravidlo). Smerovač R3 sám seba nepovažuje za ABR aj ked je v dvoch oblastiach a preto nevygeneruje LSA typu 3 pre náš prefix.

Na druhej strane smerovač R3 prijme a použije LSA typu 3, ktoré dostane z R1. Logicky sa tento smerovač dá považovať za smerovač vo vnútri dvoch oblastí, ale nie hraničný.

Trik na záver

Ako teraz vieme, siete 5.100.5.0/24 a 5.100.2.0/24 na smerovačoch R2 a R5 budú komunikovať cez Area 0. To znamena, že dáta prejdu trasu R5=R4=R6=R1=R2 a nevyužiju možnú skratku R5=R3=R2.

Ak by sme chceli túto srkatku využiť dá sa na Cisco smerovačoch urobiť trik, že vytvoríme LoopBack rozhranie, ktore v nastaveniach ospf priradíme do Area 0. Takto splníme prvu podmienku ABR smerovača a smerovač R3 začne generovat LSA typu 3 pre siete z oblastí 1 a 2.

Krasa tohto riešenie je v tom, že aj ked takto “okabátime” OSPF na R3, nevznikne nám smerovacia slučka nakolko smerovače R1 a R4 odignorujú LSA typu 3 od smerovača R3 koli pravudlu 2 (nakoľko R1 a R4 maju v Area 0 vytovrené sesedstvo v stave FULL)

Týmto sa lúčim a teším sa na Vaše komentáre, postrehy alebo na naše osobné stretnutie na niektorom z kurzov.

Domáca úloha

Smerovanie sa dá ešte upraviť pomocou vytvorenia OSPF virtuálnich liniek (virtual link) medzi R3 a R1 alebo R3 a R4. Skúste si, keď už nie v nejakom simulatore ako je GNS3, tak aspoň pomocou aplikovania spomenutých pravidiel na papiery povedať, ako budu potom smerované dáta medzi sieťami na R2 a R5.

Odpoveď sa doszviete onedlho v ďaľšom článku alebo v diskusii pod týmto článkom.

S pozdravom

Peter Havrila, CCNP

Instruktor RCNA FIIT STU

Adobe Reader 9 a tip pre znovu-otváranie PDF

26 októbra, 2010

Veľa z nás, technicky založených ľudí, veľmi často číta technickú literatúru vo formáte PDF. Ja osobne pokladám PDF formát za hlavný zdroj mojich vedomosti v oblasti počítačových sietí. Poslednou dobou som však mal malinkatý problém s pohodlím pri ich čítani.  Tento problém bol spôsobený mojim prechodom z používania Linuxu späť na Windows XP a s tým súvisiaci návrat k čitaniu PDF dokumentov pod Adobe Reader 9.

Aj ked ide o vlajkovú loď pre PDF súbory na platforme Windows a ja osobne nemám problém s jeho tažkopádnosťou, jedna vec mi vrtala v hlave už dlhšie pri jeho používaní. Pri tom ma ani nenapadlo skusiť hladať odpoveď na tento problémik a zároveň otázku: “Ako by bolo možné, aby si Adobe Reader pamätal pre každé moje PDF poslednú stranu, na ktorej som dané PDF prestal čítať, a pri novom otvorení tohto PDF mi zobrazil práve túto stránku”. Túto funkcionalitu som po prvý krát vobec objavil pri všetkých PDF readeroch na Linuxe a tak som s ňou bol zhíčkaný, že som ju jednoducho potreboval aj na Windows XP a z nejakého dôvodu ju Adobe Reader 9 implicitne nemá aktivovanú!

Naštastie a na moje velké prekvapenie, Adobe Reader 9 sa dá veľmi jednoducho nastaviť, aby práve túto schopnosť aktivoval. Stačí pre túto možnosť vojsť do nastavení (Edit -> Preferences), tam otvoriť časť “Documents” a zaškrknúť” políčko “Restore last view settings when reopening documents”.

Pre ilustráciu prikladám aj obrázok.

Odteraz mi príde čitanie toho množstva PDF súborov podstatne prehladnejšie.

Tento malý príspevok môže niekto pokladať za veľmi elementárny, ba až technologicky banálny, avšak nemôžete čakať vela druhý deň od spustenia našich blogov ;). Taktiež aspoň dvaja ludia v mojom kontakt liste túto informáciu uvítali.

Čo sa tíka dajakých zákulisných informácií ohladom ďaľších a zaujimavejších článkov, vo fáze prípravy sú informácie o pripravovaných nových kurzoch CCNA Security a MPLS+BGP, ktorý je orientovaný na dosiahnutie CCIP certifickácie. Taktiež kolegovia už varia zaujimavé články a technologické vychitávky, ktoré by mali byť zaujimavé práve pre našich študentov RCNA na FIIT STU v Bratislave.

Ostante naladení!

S pozdravom,
Peter Havrila, CCNP
Inštruktor RCNA FIIT STU

Blogy RCNA FIIT STU spustené

25 októbra, 2010

Vitajte na testovacej prevádzke blogového systému pre našich inštruktorov na RCNA FIIT STU v Bratislave.

V rámci týchto blogov by sme sa chceli s komunitou vznikajúcou okolo našej akadémie podeliť o zaujímavosti, technologické novinky, alebo postrehy z oblasti počítačových sietí. Prípadne, zákulisné informácie týkajúce sa diania na pôde RCNA FIIT STU (tie, samozrejme nájdete aj na oficiálnej stránke).  Tieto blogy sú samozrejme súčasťou našej hlavnej stránky http://cisco.fiit.stuba.sk/new, kde nájdete všetky potrebné informácie ohľadom poskytovaných kurzov a iné oficiálne informácie.

Na Vaše komentáre sa tešia hlavne moji kolegovia – inštruktori Adrián Chovan, Filip Burda a samozrejme aj ja, Peter Havrila.

Prajeme Vám príjemné čítanie.

S pozdravom.

Peter Havrila, CCNP, Inštruktor RCNA FIIT STU


%d blogerom sa páči toto: