Сёння мы пачнем вывучэнне маршрутызацыі па пратаколе OSPF. Гэтая тэма, як і разгляд пратакола EIGRP, з'яўляецца найважнейшай ва ўсім курсе CCNA. Як бачыце, раздзел 2.4 называецца "Настройка, праверка і непаладкі адзінкавай зоны і мультызоны OSPFv2 для пратакола IPv4 (за выключэннем аўтэнтыфікацыі, фільтрацыі, ручнога падсумоўвання маршрутаў, пераразмеркавання, тупіковай вобласці, віртуальнай сеткі і LSA)".
Тэма OSPF досыць шырокая, таму яна зойме 2, магчыма, 3 відэаўрокі. Сённяшні ўрок будзе прысвечаны тэарэтычнаму боку пытання, я раскажу вам, што ўяўляе сабой гэты пратакол у агульных рысах і як ён працуе. У наступным відэа мы пяройдзем да рэжыму канфігурацыі OSPF з дапамогай Packet Tracer.
Дык вось, на гэтым уроку мы разгледзім тры рэчы: што такое OSPF, як ён працуе і што такое зоны OSPF. На папярэднім уроку мы казалі, што OSPF – гэта пратакол маршрутызацыі тыпу Link State, які даследуе каналы сувязі паміж маршрутызатарамі і які прымае рашэнні на аснове хуткасці гэтых каналаў. Доўгі канал з большай хуткасцю, гэта значыць з большай прапускной здольнасцю будзе ў прыярытэце ў параўнанні з кароткім каналам з меншай прапускной здольнасцю.
Пратакол RIP, з'яўляючыся дыстанцыйна-вектарным, абярэ шлях у адзін хоп, нават калі гэты канал мае нізкую хуткасць, а пратакол OSPF абярэ доўгі маршрут з некалькіх хопаў, калі сумарная хуткасць на гэтым маршруце будзе вышэй, чым хуткасць трафіку на кароткім маршруце.
Пазней мы разгледзім алгарытм прыняцця рашэнняў, пакуль вы павінны запомніць, што OSPF з'яўляецца пратаколам стану каналаў Link State. Гэты адчынены стандарт быў створаны ў 1988 году, так што ім мог скарыстацца кожны вытворца сеткавага абсталявання і любы сеткавы правайдэр. Таму OSPF нашмат папулярней, чым EIGRP.
Пратакол OSPF версіі 2 падтрымлівае толькі пратакол IPv4, а годам пазней, у 1989, распрацоўшчыкі абвясцілі аб выпуску 3 версіі, якая падтрымлівае IPv6. Аднак поўнафункцыянальная трэцяя версія OSPF для IPv6 з'явілася толькі ў 2008 году. Чаму выбралі менавіта OSPF? На апошнім уроку мы даведаліся, што гэты пратакол унутранага шлюза выконвае канвергенцыю маршрутаў нашмат хутчэй, чым RIP. Гэта бескласавы пратакол.
Калі вы падушыце, RIP з'яўляецца класавым пратаколам, гэта значыць ён не адпраўляе інфармацыю аб масцы падсеткі, і калі яму сустрэнецца IP-адрас класа А/24, ён яго не прыме. Напрыклад, калі вы прадставіце яму IP-адрас выгляду 10.1.1.0/24, то ён успрыме яго як сетка 10.0.0.0, таму што не разумее, калі сетка падзяляецца на падсеткі з выкарыстаннем больш за адной маскі падсеткі.
OSPF з'яўляецца бяспечным пратаколам. Напрыклад, калі два роўтары абменьваюцца OSPF - інфармацыяй, вы можаце наладзіць аўтэнтыфікацыю такім чынам, што падзяліцца інфармацыяй з суседнім роўтэрам можна будзе толькі пасля ўводу пароля. Як мы ўжо сказалі, гэта адчынены стандарт, таму OSPF выкарыстаюць шматлікія вытворцы сеткавага абсталявання.
У глабальным сэнсе OSPF уяўляе сабой механізм абмену аб'явамі аб стане канала Link State Advertisemen, або LSA. Паведамленні LSA генеруюцца роўтарам і ўтрымоўваюць у сабе шмат інфармацыі: унікальны ідэнтыфікатар роўтара router-id, дадзеныя аб сетках, вядомых роўтэру, дадзеныя аб іх кошце і гэтак далей. Уся гэтая інфармацыя патрэбна роўтэру для прыняцця рашэння аб маршрутызацыі.
Роўтар R3 пасылае сваю інфармацыю LSA роўтэру R5, а роўтар R5 дзеліцца сваёй LSA-інфармацыяй з R3. Гэтыя LSA уяўляюць сабой структуру дадзеных, якія фармуюць базу дадзеных стану каналаў Link State Data Base, або LSDB. Роўтар збірае ўсе атрыманыя LSA і змяшчае іх у сваю LSDB. Пасля таго, як абодва роўтара стварылі свае базы дадзеных, яны абменьваюцца паведамленнямі Hello, якія служаць для выяўлення суседзяў, і прыступаюць да працэдуры параўнання сваіх LSDB.
Роўтар R3 высылае роўтэру R5 паведамленне DBD, ці «апісанне базы дадзеных», а R5 адсылае сваё DBD роўтару R3. Гэтыя паведамленні ўтрымоўваюць азначнікі LSA, якія маюцца ў базах кожнага роўтара. Атрымаўшы DBD, роўтэр R3 пасылае запыт стану сеткі LSR роўтэру R5, у якім гаворыцца: "у мяне ўжо ёсць паведамленні 3,4 і 9, так што дашліце мне толькі 5 і 7".
Сапраўды гэтак жа паступае R5, паведамляючы трэцяму роўтэру: "у мяне ёсць інфармацыя 3,4 і 9, так што дашліце мне 1 і 2". Атрымаўшы запыты LSR, роўтэры адсылаюць зваротна пакеты абнаўленняў стану сеткі LSU, гэта значыць у адказ на свой LSR трэці роўтар атрымлівае LSU ад роўтара R5. Пасля таго, як роўтэры абновяць свае базы дадзеных, то ўсе яны, нават калі ў вас ёсць 100 роўтэраў, будуць мець аднолькавыя базы LSDB. Як толькі ў роўтэрах будуць створаны базы дадзеных LSDB, кожны з іх будзе ведаць аб усёй сетцы ў цэлым. Пратакол OSPF задзейнічае алгарытм Shortest Path First для стварэння табліцы маршрутызацыі, таму найважнай умовай яго карэктнай працы з'яўляецца сінхранізацыя LSDB усіх прылад у сеткі.
На прыведзенай схеме размешчаны 9 роўтэраў, кожны з якіх абменьваецца з суседзямі паведамленнямі LSR, LSU і гэтак далей. Усе яны злучаныя сябар з сябрам па тыпе p2p, ці «кропка-кропка» інтэрфейсамі, якія падтрымліваюць працу па пратаколе OSPF, і ўзаемадзейнічаюць сябар з сябрам з мэтай стварэння аднолькавых LSDB.
Як толькі базы будуць сінхранізаваныя, кожны роўтэр, выкарыстоўваючы алгарытм найкароткага шляху, фармуе сваю табліцу маршрутызацыі. У розных роўтэраў гэтыя табліцы будуць рознымі. Гэта значыць усе роўтэры выкарыстоўваюць аднолькавыя LSDB, але ствараюць табліцы маршрутызацыі, зыходзячы з уласных меркаванняў аб найкароткіх маршрутах. Для выкарыстання гэтага алгарытму OSPF мае патрэбу ў рэгулярным абнаўленні базы LSDB.
Такім чынам, для ўласнага функцыянавання OSPF павінен спачатку забяспечыць 3 умовы: знайсці суседзяў, стварыць і абнавіць LSDB і сфарміраваць табліцу маршрутызацыі. Для выканання першай умовы сеткаваму адміністратару, магчыма, спатрэбіцца ўручную наладзіць router-id, таймінгі ці wildcard mask. У наступным відэа мы разгледзім наладу прылады для працы з OSPF, пакуль што вы павінны ведаць, што гэты пратакол выкарыстоўвае зваротную маску, і калі яна не супадае, калі не супадаюць вашыя падсеткі, ці не супадае аўтэнтыфікацыя, суседства роўтэраў не зможа ўтварыцца. Таму пры ўхіленні непаладак працы OSPF вы павінны высветліць, чаму гэта самае суседства не ўтворыцца, гэта значыць праверыць супадзенне вышэйпаказаных параметраў.
Як адміністратар сеткі, вы не ўдзельнічаеце ў працэсе стварэння LSDB. Абнаўленне баз дадзеных адбываецца аўтаматычна пасля стварэння суседства роўтэраў, як і пабудова табліц маршрутызацыі. Усё гэта выконвае сама прылада, наладжанае на працу з пратаколам OSPF.
Давайце разгледзім прыклад. У нас маюцца 2 роўтара, якім я для спрашчэння прысвоіў ідэнтыфікатары RID 1.1.1.1 і 2.2.2.2. Як толькі мы злучым іх, канал link адразу ж пяройдзе ў стан up, таму што спачатку я наладзіў гэтыя роўтэры на працу з OSPF. Як толькі будзе ўтвораны канал сувязі, роўтэр А неадкладна аправіць другому пакет Hello. У гэтым пакеце будзе змяшчацца інфармацыя, што дадзены роўтар яшчэ нікога не "бачыў" на гэтым канале, таму што адсылае Hello ўпершыню, а таксама яго ўласны ідэнтыфікатар, дадзеныя аб падлучанай да яго сетцы і іншая інфармацыя, якой ён можа падзяліцца з суседам.
Атрымаўшы гэты пакет, роўтэр В скажа: "я бачу, што на дадзеным канале сувязі маецца патэнцыйны кандыдат на суседства па пратаколе OSPF" і пяройдзе ў стан ініцыялізацыі Init state. Пакет Hello - гэта не юнікаставае або бродкаставае паведамленне, гэта мультыкаставы пакет, які адсылаецца на мультыкаставы OSPF IP-адрас 224.0.0.5. Некаторыя людзі пытаюцца, якая маска падсеткі для мультыкаста. Справа ў тым, што мультыкаст не мае маскі падсеткі, ён распаўсюджваецца як радыёсігнал, які чуюць усе прылады, настроеныя на яго частату. Напрыклад, калі вы хочаце пачуць FM-радыё, якое вяшчае на частаце 91,0, то наладжваеце свой радыёпрымач на гэтую частату.
Сапраўды гэтак жа роўтэр У наладжаны на прыём паведамленняў для мультыкаставага адрасу 224.0.0.5. Слухаючы гэты канал, ён прымае пакет Hello, які даслаў роўтэр А, і адказвае яму сваім паведамленнем.
Пры гэтым суседства можа быць усталявана толькі ў тым выпадку, калі адказ У задавальняе набору крытэраў. Першы крытэр - частата адпраўкі паведамленняў Hello і інтэрвал чакання адказу на гэтае паведамленне Dead Interval павінны супадаць у абодвух роўтэраў. Звычайна Dead Interval роўны некалькім значэнням таймера Hello. Такім чынам, калі Hello Timer роўтара А складае 10 з, а роўтар У адправіць яму паведамленне праз 30 с пры тым што Dead Interval роўны 20с, суседства не адбудзецца.
Другі крытэр - абодва роўтара павінны выкарыстоўваць аднолькавы тып аўтэнтыфікацыі. Адпаведна, паролі аўтэнтыфікацыі таксама павінны супадаць.
Трэці крытэр - гэта супадзенне ідэнтыфікатараў зоны Arial ID, чацвёрты - супадзенне даўжыні прэфікса сеткі. Калі роўтар А паведамляе прэфікс /24, то роўтар У таксама павінен мець прэфікс сеткі /24. У наступным відэа мы разгледзім гэта падрабязней, пакуль што заўважу, што гэта не маска падсеткі, тут роўтэры выкарыстоўваюць адваротную маску Wildcard mask. І вядома, сцягі тупіковай зоны Stub area гэтак жа павінны супадаць, калі роўтэры знаходзяцца ў гэтай зоне.
Пасля праверкі гэтых крытэрыяў у выпадку іх супадзення роўтар У адпраўляе роўтэру А свой Hello-пакет. У адрозненне ад паведамлення А, роўтар У паведамляе, што ён убачыў роўтар А, і ўяўляецца сам.
У адказ на гэтае паведамленне роутер А зноў пасылае Hello роутеру Ў, у якім пацвярджае, што таксама ўбачыў роутер У, канал сувязі паміж імі складаецца з прылад 1.1.1.1 і 2.2.2.2, а сам ён з'яўляецца прыладай 1.1.1.1. Гэта вельмі важная стадыя ўсталявання суседства. У дадзеным выпадку выкарыстоўваецца двухбаковае злучэнне 2-WAY, але што адбудзецца, калі ў нас маецца світч з размеркаванай сеткай з 4-х роўтэраў? У такім "расшараным" асяроддзі адзін з роўтэраў павінен гуляць ролю вылучанага маршрутызатара Designated router DR, а другі – рэзервовага вылучанага маршрутызатара Backup designated router, BDR
Кожная з гэтых прылад сфармуе Full connection, ці стан поўнай сумежнасці, пазней мы разгледзім, што гэта такое, аднак злучэнне гэтага тыпу будзе ўсталявана толькі з DR і BDR, сябар з сябрам два ніжніх роўтара D і Ў усё роўна будуць мець зносіны па схеме двухбаковага злучэння "point-to-point".
Гэта значыць з DR і BDR усе роўтэры ўсталёўваюць стаўленне поўнага суседства, а сябар з сябрам – злучэнне тыпу point-to-point. Гэта вельмі важна, таму што пры двухбаковым злучэнні сумежных прылад усе параметры пакета Hello павінны супадаць. У нашым выпадку ўсё супадае, таму прылады без праблем утвараюць суседства.
Як толькі двухбаковая сувязь будзе ўсталяваная, роўтар А адсылае роўтэру Ў пакет Database Description, ці «апісанне базы дадзеных», і пераходзіць у стан ExStart - пачатак абмену, ці чаканне загрузкі. Database Descriptor уяўляе сабой інфармацыю, аналагічную зместу кнігі – гэта пералік усяго, што маецца ў базе дадзеных маршрутызацыі. У адказ роўтар У высылае сваё апісанне базы дадзеных роўтару А і пераходзіць у стан абмену дадзенымі аб каналах Exchange. Калі ў стане Exchange роўтэр выявіў, што ў яго базе дадзеных адсутнічае нейкая інфармацыя, то ён пяройдзе ў стан загрузкі LOADING і пачне абменьвацца з суседам паведамленнямі LSR, LSU і LSA.
Так, роўтэр А пашле суседу LSR, той адкажа яму пакетам LSU, на што роўтар А адкажа роўтару Ў паведамленнем LSA. Гэты абмен адбудзецца столькі разоў, колькі разоў прылады захочуць абмяняцца паведамленнямі LSA. Стан LOADING азначае, што поўнага абнаўлення базы дадзеных LSA яшчэ не адбылося. Пасля загрузкі ўсіх дадзеных абедзве прылады пяройдуць у стан поўнай сумежнасці FULL.
Заўважу, што пры двухбаковым злучэнні прылады знаходзіцца проста ў стане суседства, а стан поўнай сумежнасці магчымы толькі паміж маршрутызатарамі, DR і BDR Гэта азначае, што кожны роўтар паведамляе DR аб зменах у сетцы, і ўсе роўтэры даведаюцца пра гэтыя змены ад DR
Выбар DR і BDR з'яўляецца важным пытаннем. Разгледзім, як адбываецца выбар DR у агульным асяроддзі. Выкажам здагадку, у нашай схеме маецца тры роўтара і світч. Спачатку прылады OSPF параўноўваюць прыярытэт у Hello-паведамленнях, затым параўноўваюць Router ID.
Прылада з найвышэйшым прыярытэтам становіцца DR Калі прыярытэты двух прылад супадаюць, то з іх дваіх выбіраецца прылада з найвышэйшым Router ID, якое і становіцца DR
Рэзервовым вылучаным маршрутызатарам BDR становіцца прылада са другім па значнасці прыярытэтам або са другім па значнасці Router ID. Калі DR выйдзе з ладу, яго неадкладна заменіць BDR Ён пачне гуляць ролю DR, а сістэма абярэ іншы BDR
Спадзяюся, што вы разабраліся з выбарам DR і BDR, елі не, то я яшчэ вярнуся да гэтага пытання ў адным з наступных відэа і растлумачу гэты працэс.
Такім чынам, мы разгледзелі, што ўяўляюць сабой Hello, апісанне базы даных Database Descriptor і паведамленні LSR, LSU і LSA. Перш чым перайсці да наступнай тэме, давайце крыху пагаворым аб кошце OSPF.
У Cisco кошт маршруту вылічваецца па формуле стаўлення прапускной здольнасці Reference bandwidth, якая па змаўчанні прынята роўнай 100 мбіт/з, да кошту канала. Напрыклад, пры злучэнні прылад праз серыйны порт хуткасць роўная 1.544 мбіт/з, а кошт будзе роўная 64. Пры выкарыстанні Ethernet-злучэнні са хуткасцю 10 мбіт/з кошт роўная 10, а кошт злучэння FastEthernet са хуткасцю 100 мбіт/з будзе раўняцца 1.
Пры выкарыстанні Gigabit Ethernet мы маем хуткасць 1000 мбіт/з, аднак у дадзеным выпадку хуткасць заўсёды прымаецца роўнай 1. Такім чынам, калі ў вас у сетцы ёсць Gigabit Ethernet, вы павінны змяніць значэнне па змаўчанні Ref. BW на 1000. У гэтым выпадку кошт складзе 1, а ўся табліца будзе пералічана з павелічэннем значэнняў кошту ў 10 разоў. Пасля таго, як мы сфарміравалі суседства і пабудавалі базу дадзеных LSDB, мы пераходзім да пабудовы табліцы маршрутызацыі.
Пасля атрымання LSDB кожны з роўтэраў самастойна прыступае да фармавання спісу маршрутаў з дапамогай алгарытму SPF. У нашай схеме роўтэр А будзе ствараць такую табліцу для самога сябе. Напрыклад, ён падлічвае кошт маршруту А-R1 і вызначае яго роўнай 10. Каб спрасціць разуменне схемы, выкажам здагадку, што роўтар А вызначае аптымальны маршрут да роўтара В. Кошт злучэння А-R1 роўна 10, злучэнні А-R2 роўна 100, а кошт маршруту А-R3 роўная 11, гэта значыць суме маршруту А-R1(10) і R1-R3(1).
Калі роўтар А захоча дабрацца да роўтара R4, ён можа гэта зрабіць або па маршруце А-R1-R4, або па маршруце А-R2-R4, прычым у абодвух выпадках кошт маршрутаў будзе аднолькавы: 10+100 =100+10=110. Маршрут А-R6 будзе каштаваць 100 1 = 101, што ўжо лепш. Далей разглядаецца шлях да роўтара R5 па маршруце А-R1-R3-R5, кошт якога складзе 10+1+100 = 111.
Шлях да роўтара R7 можна пракласці па двух маршрутах: А-R1-R4-R7 ці А-R2-R6-R7. Кошт першага складзе 210, другога - 201, значыць, варта выбраць 201. Такім чынам, каб дасягнуць роўтар В, роўтэр А можа выкарыстоўваць 4 маршруты.
Кошт маршруту А-R1-R3-R5-B складзе 121. Маршрут А-R1-R4-R7-B будзе каштаваць 220. Маршрут А-R2-R4-R7-B каштуе 210, а А-R2-R6-R7- B мае кошт 211. Зыходзячы з гэтага, роўтэр А абярэ маршрут з найменшым коштам, роўным 121, і змесціць у табліцу маршрутызацыі менавіта яго. Гэта вельмі спрошчаная схема таго, як працуе алгарытм SPF. У рэчаіснасці ў табліцу змяшчаецца не толькі пазначэнні роўтэраў, праз які пралягае аптымальны маршрут, але і пазначэнні якія злучаюць іх портаў і ўся астатняя неабходная інфармацыя.
Разгледзім яшчэ адну тэму, якая датычыцца зон маршрутызацыі. Звычайна пры наладзе OSPF прылад кампаніі ўсе яны знаходзяцца ў адной агульнай зоне.
Што адбудзецца, калі прылада, злучанае з роўтарам R3, раптам выйдзе са строю? Роўтар R3 тут жа пачне рассылаць у адрас роўтэраў R5 і R1 паведамленне аб тым, што канал з дадзенай прыладай больш не працуе, і ўсе роўтэры пачнуць абменьвацца абнаўленнямі аб гэтай падзеі.
Калі ў вас ёсць 100 роўтэраў, то ўсе яны абновяць інфармацыю аб стане каналаў, таму што знаходзяцца ў адной агульнай зоне. Тое ж самае адбудзецца пры выхадзе са строю аднаго з суседніх роўтэраў - усе прылады ў зоне абмяняюцца абнаўленнямі LSA. Пасля абмену такімі паведамленнямі зменіцца сама тапалогія сеткі. Як толькі гэта адбудзецца, SPF пералічыць табліцы маршрутызацыі ў адпаведнасці з якія змяніліся ўмовамі. Гэта вельмі аб'ёмны працэс, і калі ў вас у адной зоне размешчана тысяча прылад, вам трэба кантраляваць памер памяці роўтэраў, каб ён быў дастатковым для захоўвання ўсіх LSA і велізарнай базы дадзеных стану каналаў LSDB. Як толькі ў нейкай частцы зоны адбываюцца змены, алгарытм SPF тут жа вырабляе пералік маршрутаў. Па змаўчанні LSA абнаўляецца кожныя 30 хвілін. Гэты працэс адбываецца на ўсіх прыладах не адначасова, аднак у любым выпадку абнаўленні выконваюцца кожным роўтарам з перыядычнасцю 30 мін. Чым больш сеткавых прылад. Тым больш патрабуецца памяці і чакай на абнаўленне LSDB.
Вырашыць гэтую праблему можна, калі падзяліць адну агульную зону на некалькі асобных зон, гэта значыць выкарыстоўваць мультызанаванне. Для гэтага ў вас павінен быць план ці схема ўсёй сеткі, якой вы кіруеце. Нулявая зона AREA 0 з'яўляецца вашай галоўнай зонай Main area. Гэта тое месца, дзе ажыццяўляецца злучэнне са знешняй сеткай, напрыклад, выхад у Інтэрнэт. Пры стварэнні новых зон вы павінны кіравацца правілам: у кожнай зоне павінен размяшчацца адзін памежны маршрутызатар ABR, Area Border Router. Памежны роўтар мае адзін інтэрфейс у адной зоне, а другі інтэрфейс - у іншай зоне. Напрыклад, роўтар R5 мае інтэрфейсы ў зоне 1 і зоне 0. Як я сказаў, кожная з зон павінна быць злучаная з нулявой зонай, гэта значыць мець памежны роўтар, адзін з інтэрфейсаў якога злучаны з AREA 0.
Выкажам здагадку, што злучэнне R6-R7 выйшла са строю. Пры гэтым абнаўленне LSA распаўсюдзіцца толькі па зоне AREA 1 і будзе дакранацца толькі гэтай зоны. Прылады ў зоне 2 і ў зоне 0 нават не будуць пра гэта ведаць. Памежны роўтар R5 выконвае сумаванне інфармацыі аб тым, што адбываецца ў яго зоне, і адпраўляе ў галоўную зону AREA 0 сумарную інфармацыю аб стане сеткі. Прыладам у адной зоне не трэба ведаць аб усіх зменах LSA усярэдзіне іншых зон, таму што роўтар ABR будзе перасылаць сумарную інфармацыю аб маршрутах з адной зоны ў іншую.
Калі вы не зусім разабраліся з канцэпцыяй зон, то зможаце пазнаць больш на наступных уроках, калі мы зоймемся наладай маршрутызацыі OSPF і разгледзім некалькі прыкладаў.
Дзякуй, што застаяцеся з намі. Вам падабаюцца нашыя артыкулы? Жадаеце бачыць больш цікавых матэрыялаў? Падтрымайце нас аформіўшы замову або парэкамендаваўшы знаёмым, 30% зніжка для карыстальнікаў Хабра на ўнікальны аналаг entry-level сервераў, які быў прыдуманы намі для Вас: (даступныя варыянты з RAID1 і RAID10, да 24 ядраў і да 40GB DDR4).
Dell R730xd у 2 разы танней? Толькі ў нас у Нідэрландах! Dell R420 – 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB – ад $99! Чытайце аб тым
Крыніца: habr.com