Glava9-Protokoli Za Rutiranje

Проф.д-р Тони Јаневски, Комутација и рутирање

Глава 9-1

Глава 9

Протоколи за рутирање

Во оваа глава ќе бидат опфатени протоколите за рутирање кои се базирани на

алгоритмите за рутирање изложени во претходната глава, глава 7. Притоа, ќе биде

даден акцент на BGP протоколот како најраспространет протокол за рутирање меѓу

автономни системи, како и на RIP и OSPF протоколите за рутирање во рамките на

конкретен автономен систем. На крајот од главата ќе биде даден осврт и на

протоколите за мултикаст рутирање.

9.1 Надворешен Gateway Протокол

Терминот Exterior Gateway Protocol (EGP) се користи за да се обележат

протоколите кои се користат за пренос на рутирачката информација помеѓу два

автономни системи. Обично ист надворешен протокол се користи во повеќето TCP/IP

мрежи. познат како Border Gateway Protocol (BGP), тој се развивал низ четири

(прилично различни) верзии. Секоја верзија е нумерирана, што дава зголемување на

формалното име на тековната верзија: BGP-4. Понатаму кога збориме за BGP, мислиме

на BGP-4.

Кога пар на автономни системи се согласуваат да разменат рутирачка

информација, секој мора да назначи рутер кој ќе го објави BGP во свое име. На двата

рутери е дадено да бидат peer еден на друг. Бидејќи рутерот кој го објавува BGP мора

да комуницира со peer во друг автономен систем, има смисла да избереме уред кој е во

Проф.д-р Тони Јаневски, Комутација и рутирање

Глава 9-2

близина на работ на автономниот систем. Оттука, BGP терминологијата го нарекува

уредот како border gateway (гранична порта) или border router (граничен рутер). Сликата

9.1 ја илустрира идејата. На сликата, рутерот R1 собира информација за мрежите во

автономниот систем 1 и дава извештај за таа информација на рутерот R2 користејќи

BGP, додека рутерот R2 репортира информација од автономниот систем 2.

Автономен систем 1

Автономен систем 2

.

. . ..BGP

(Border Gateway Protocol)

R1 R2

Слика 9.1 Концепт на BGP рутирачкиот протокол

9.1.1 Поважни BGP карактеристики

Карактеристично за BGP е што не е ниту едноставен distance-vector протокол,

ниту пак едноставен link-state протокол. Тој може да се окарактеризира со следново:

Затоа што BGP е дизајниран како надворешен gateway протокол, неговата

примарна улога е да овозможи да еден автономен систем комуницира со друг.

Доколку еден автономен систем има повеќе рутери кои комуницираат со peer во

еден надворешен систем, BGP може да се користи за координација меѓу

рутерите во групата за да се гарантира дека истите пропагираат доследна

информација.

BGP му допушта на автономниот систем да ги огласи дестинациите кои се

достапни во него или преку него, и истото да го дознае од друг автономен

систем.

Како и distance-vector протоколите, така и BGP испорачува следна-hop

информација за секоја дестинација.

Поддршка. За разлика од повеќето distance-vector протоколи кои ги огласуваат

точно рутите во локалната рутирачка табела, BGP остава изборот да го направат

локалните мрежни администратори. Поконкретно, рутер кој користи BGP може

Проф.д-р Тони Јаневски, Комутација и рутирање

Глава 9-3

да се конфигурира така да се распознава меѓу сет на дестинации достапни од

компјутери внатре во автономниот систем и сет од дестинации огласени на

други автономни системи.

BGP го користи TCP за сите комуникации. На тој начин имаме доверлив пренос

на пакетите кои носат рутирачка информација, бидејќи TCP работи на тој начин

што бара потврди за испратените пакети.

BGP дава информации на други АС за достапни мрежи во него и обратно.

За да се намали контролниот сообраќај по линковите, BGP не вклучува целосна

рутирачка информација во секоја порака за ажурирање. Имено, целосната

рутирачка информација се разменува еднаш, а потоа наредните пораки носат

само дополнителни промени наречени делти (deltas).

Има поддршка за адресирање без класи, т.е. BGP подржува CIDR адреси.

9.1.2 BGP типови пораки

BGP peer нивоата извршуваат три основни функции: првата функција ги содржи

иницијалните peer добивки и автентичност. Две peer нивоа воспоставуваат TCP

конекција и вршат размена на порака која гарантира дека двете страни се согласни да

комуницираат. Втората функција ја дава првичната цел на протоколот - секоја страна

испраќа позитивни или негативни информации за дестинациите. Тоа значи, испраќачот

може да огласи дека една или повеќе дестинации се дофатливи со додавање на следен

hop за секоја од нив, или испраќачот може да декларира дека една или повеќе

претходно огласени дестинации не се повеќе достижни. Третата функција обезбедува

потврда дека peer нивоата и мрежните конекции меѓу нив функционираат коректно. За

да се извршуваат трите функции опишани погоре, BGP дефинира четири основни

типови на пораки, прикажани на табелата 9.1.

Табела 9.1 Основни типови на пораки во BGP-4

Тип на Код Тип на Порака Опис

1 OPEN иницијализација на конекцијата

2 UPDATE огласување или отфрлање на рути

3 NOTIFICATION одговор на порака со грешки

4 KEEPALIVE одржување на конекцијата

Проф.д-р Тони Јаневски, Комутација и рутирање

Глава 9-4

Заглавие на BGP Пораката

Секоја BGP порака започнува со фиксирано заглавие кое го означува типот на

пораката. Сликата 9.2 го илустрира форматот на заглавјето.

Маркер

Должина (во број октети) Тип на пораката

0 16 24 31

Слика 9.2 Заглавие на BGP порака

16-октетното маркер (MARKER) поле содржи вредност дека двете страни се сложуваат

да го означат почетокот на пораката. 2-октетното должина (LENGTH) поле ја означува

вкупната должина на пораката мерена во октети. Минималната должина на пораката е

19 октети (за порака која не содржи податоци после заглавието), и максимална

дозволена должина од 4096 октети. На крај, 1-октетното тип на порака (TYPE) поле

содржи една од четирите вредности за типот на пораката прикажани во табелата 9.1.

BGP OPEN порака

Веднаш штом две BGP peer нивоа воспостават TCP конекција, секое од нив

испраќа OPEN порака за да го објави бројот на својот автономен систем и да ги

воспостави останатите операциски параметри. Во продолжение на стандардното

заглавие, OPEN пораката содржи вредност за “hold timer” кој се користи за да се

специфицира максималниот број на секунди што може да поминат помеѓу приемот на

две успешни пораки. Сликата 9.3 го илустрира форматот.

Верзија (VERSION) полето ни ја дава верзијата на протоколот што се користи

(овој формат е за верзија 4). Уникатниот број на автономниот систем (AUTONOMOUS

SYSTEM NUM) му го дава на автономниот систем бројот на системот на испраќачот.

Време на чекање (HOLD TIME) полето го дава максималното време за кое приемникот

Проф.д-р Тони Јаневски, Комутација и рутирање

Глава 9-5

треба да ја чека пораката од испраќачот. Потребно е приемникот да стартува тајмер со

користење на оваа вредност.

Опционални параметри (опционално)

Должина на параметрите

BGP идентификатор

Време на чекање (Hold Time)

Уникатен број на автономниот систем

Верзија

0 8 16 31

Слика 9.3 Формат на BGP OPEN порака

Тајмерот се ресетира секогаш кога доаѓа порака; доколку тајмерот истече, приемникот

смета дека испраќачот не е повеќе достапен (и престанува со препраќање на датаграми

до тој рутер). BGP идентификатор (IDENTIFIER) полето содржи 32-битна целобројна

вредност која го идентифицира испраќачот. Последното поле е опционално.

PARM.LEN ни ја дава големината во октети, а Optional Parameters ја содржи листата на

опционални параметри.

BGP UPDATE порака

Кога BGP peer нивоата креираат TCP конекција, испраќаат OPEN порака и

потврда за истата. Peer нивоата користат UPDATE пораки за да огласат новите

дестинации кои се на дофат или да ги повлечат претходните објави кога некоја

дестинација постанува недофатна. Сликата 9.4 го илустрира форматот на UPDATE

пораките.

Проф.д-р Тони Јаневски, Комутација и рутирање

Глава 9-6

Отфрлени дестинации (променлива големина)

Должина на полето со отфрлени дестинации (во октети)

0 16 31

Атрибути кон новите дестинации (променлива големина)

Нови дестинациони мрежи (променлива големина)

Должина на полето со нови дестинации (во октети)

Слика 9.4 Формат на BGP UPDATE порака

Како што е прикажано на сликата 9.4, секоја UPDATE порака е поделена на два дела:

првиот дел ги прикажува претходно објавените дестинации што се отфрлени, а вториот

дел ги дава новите дестинации што се огласени. Полето должина на полето со

отфрлени дестинации (WITHDRAWN LEN) е 2-октетно поле кое ни ја дава големината

на Withdrawn Destinations полето што следи. Доколку ниту една дестинација не е

повлечена, WITHDRAWN LEN е нула. Полето должина на полето со нови дестинации

(PATH LEN) ни ја дава големината на Path Attributes кои се поврзани со новите

дестинации кои се објавени. Доколку нема нови дестинации тогаш оваа вредност е

нула.

Компримирани парови IP адреса/маска

И Withdrawn Destinations и Destination Networks полињата содржат листа на IP

мрежни адреси. За прилагодување на бескласното адресирање, BGP мора да испрати

адресна маска со секоја IP адреса. Наместо испраќање на адресата и маската како

одделни 32-битни величини, BGP користи компресирана форма за да се редуцира

големината на пораката. Сликата 9.5 го илустрира форматот. Сликата покажува дека

BGP не испраќа bit-на маска. Наместо тоа, ја декодира информацијата за маската во

октетот што стои пред секоја адреса. Октетот на маската содржи бинарен integer што го

означува бројот на бити “1” во маската.

Адресата што го следи октетот на маската е исто така компримирана - само

октетите покриени со маската се вклучени. Оттука, IP адресата е со должина еден октет

ако должината на маската има вредност 8 или помалку, два октети ако маската има

Проф.д-р Тони Јаневски, Комутација и рутирање

Глава 9-7

должина од 9 до 16, три октети има IP адресата ако маската е со должина 17 до 24 и

сите четири октети од IP адресата се пренесуваат ако маската има должина од 25 до 32.

Можна и вредност нула на октетот на маската (тоа е во случај кога не ја следи ниту

една адреса). Вредноста нула е корисна бидејќи кореспондира на default-ната рута.

IP адреса (од 1 до 4 октети, зависно од IP mask)

Должина на IP mask

0 8 31

Слика 9.5 BGP компресиран формат на дестинациона IP адреса

BGP атрибути на патеката

Велиме дека BGP не е едноставен distance-vector протокол бидејќи објавува

повеќе отколку само следен hop. Дополнителна информација е содржана во Path

Attributes полето на пораката за ажурирање. Испраќачот може да ги користи додатоците

на патеката за да означи: следен hop за огласените дестинации, листа на АС на патеката

до дестинациите, и дали информацијата за патеката е дознаена од некој друг автономен

систем или е испорачана од автономниот систем на испраќачот.

Важно е да се спомне дека додатоците на патеката се направени да се редуцира

големината на UPDATE пораката. Тие се важни од три причини: прво, информацијата

за патеката му дозволува на приемникот да направи проверка за рутирачки loop-ови.

Испраќачот може да специфицира точна патека преку сите автономни системи до

дестинацијата. Доколку еден автономен систем се појавува повеќе од еднаш во листата,

мора да постои рутирачки loop. Второ, информацијата за патеката му дозволува на

приемникот да имплементира попречување. На пример, приемникот може да ја провери

патеката за да се увери дека информацијата не минува преку недоверливи автономни

системи. Трето, информацијата за патеката допушта да приемникот го знае изворот на

сите рути. Во продолжение при допуштање на испраќачот да назначи дали

информацијата доаѓа одвнатре од автономниот систем или од друг систем, додатоците

за патеката допуштаат испраќачот да назначи дали информацијата доаѓа со надворешен

gateway протокол како BGP или со внатрешен gateway протокол. Оттука, секој

Проф.д-р Тони Јаневски, Комутација и рутирање

Глава 9-8

приемникот може да одлучи дали да ги прифати или отфрли рутите што настануваат во

автономните системи.

BGP KEEPALIVE порака

Две BGP peer нивоа периодично разменуваат KEEPALIVE пораки за да ја

тестираат мрежната конекција и да потврдат дека двете нивоа продолжуваат да

функционираат. KEEPALIVE пораката е составена од стандардно заглавие без

дополнителни податоци. Оттука, вкупната големина на пораката е 19 октети

(минималната BGP големина на пораката).

Има две причини зошто BGP користи keepalive пораки. Прво, периодичната

размена на пораки е потребна затоа што BGP го користи TCP за транспорт, и TCP не

вклучува механизам да континуално тестира дали крајната точка на конекцијата е

достапна. Како и да е, TCP дава грешка на апликацијата доколку не можат да се

испратат податоците што апликацијата ги испраќа. Оттука, се додека страните

периодично испраќаат keepalive, тие ќе знаат дали TCP конекцијата паѓа. Второ,

keepalive е кратка порака за разлика од другите пораки и го штеди опсегот.

BGP одредува hold timer кога ја отвара конекцијата. Истиот го специфицира

максималното време за кое BGP чека без да прими порака. Hold timer-от е нула кога не

се користат keepalive пораки. Доколку е поголем од нула вообичаено се поставува

KEEPALIVE интервалот на околу една третина од hold timer-от.

Информација од гледна точка на приемниот рутер

За разлика од повеќето протоколи кои пропагираат рутирачка информација,

Надворешниот Gateway Протокол не го дава сетот на дестинации до кои може да

досегне рутерот што ја праќа информацијата. Наместо тоа, надворешните протоколи

мора да обезбедат информација што е коректна од надворешна перспектива, а не од

сопствена перспектива (на разгледуваниот рутер). Сликата 9.6 ни ја илустрира идејата.

На сликата, рутерот R2 е доделен да комуницира со BGP во име на автономниот

систем. Кога се праќа рутирачка информација за следниот hop, тој известува дека

мрежата 1 е достапна преку R1, и дека мрежите 3 и 4 се достапни преку рутерот R3, а

мрежата 2 е достапна преку рутерот R2.

Проф.д-р Тони Јаневски, Комутација и рутирање

Глава 9-9

R1

R3

R2

R4

Net 5

Net 4

Net 3

Net 2Net 1

Koristi BGP

Do peer na drug avtonomen sistem

Slika 9.6 Primer za avtonomen sistem

BGP NOTIFICATION порака

BGP подржува и NOTIFICATION тип на порака која се користи за контрола или

кога ќе дојде до некоја грешка. Грешките се перманентни, и кога еднаш BGP ќе

детектира проблем, испраќа notification порака и потоа ја затвара TCP конекцијата.

Сликата 9.7 го илустрира форматот на пораката.

Товар (Data)Код на грешка Подкод на грешка

0 31168

Слика 9.7 Формат на BGP NOTIFICATION порака

Во оваа порака 8-битното поле означено како код на грешка (ERR CODE) дава една од

можните причини за грешка, наведени во следнава табела 9.2. Секој од кодовите за

грешка има и под-код (sub-code) кој го допрецизира типот на грешката.

Проф.д-р Тони Јаневски, Комутација и рутирање

Глава 9-10

Табела 9.2 Можни вредности на ERR CODE полето во BGP NOTIFICATION пораката

ERR CODE Значење

1 Грешка во заглавието

2 Грешка во OPEN пораката

3 Грешка во UPDATE пораката

4 Истечен Hold Timer

5 Финална грешка на уредот

6 Прекин (на конекцијата)

9.2 RIP (Routing Information Protocol) протокол

Два рутери кои се во еден ист автономен систем, по дефиниција, се внатрешни

(interior) еден на друг. На слика 9.8 со цел да се увидат некои законитости за мрежите

во автономните системи.

R2

R3 R4

R1

Net 1

Net 5Net 4

Net 3

Net 2

Slika 9.8 Primer na mala mre`a sostavena od 5 Ethernet мрежи i 4 ruteri

Рутирањето на сликата е едноставно затоа што постои само една патека меѓу

било кои две точки. Администраторот може мануелно да ги конфигурира рутите во

сите host-ови и рутери. Доколку настане некоја промена мора да се реконфигурираат

рутите во сите уреди.

Проф.д-р Тони Јаневски, Комутација и рутирање

Глава 9-11

Недостатоците на мануелниот систем се очигледни: неприлагодливост на брзи

промени. За да се воочи што се случува кога додаваме уште еден рутер, и добиваме

сценарио прикажано на слика 9.9.

R2

R3 R4

R1

Net 1

Net 5Net 4

Net 3

Net 2

Slika 9.9 Dodavawe na R5 voveduva alternativen pat pome|u mre`ite 2 i 3

R5

Во Интернет архитектурата во која има повеќе физички патишта,

администраторите одбираат еден од нив да биде примарен. Доколку рутерите вдолж

примарниот пат паднат, рутите мора да се променат и да го пренасочат сообраќајот

преку алтернативниот пат. Менувањето на рутите мануелно е и губење на време и

склоност кон грешки, па затоа е потребна автоматизација и во рамките на еден

автономен систем.

Повеќето мали автономни системи избираат еден протокол, и го користат него

само за интерно пропагирање на рутирачката информација. Бидејќи не постои еден

стандард, го користиме терминот Interior Gateway Protocol (IGP) како општ опис кој се

однесува на секој алгоритам што внатрешните рутери го користат кога разменуваат

податоци за мрежната достапност и рутирачката информација. На пример, последната

генерација на core рутери користеле протокол именуван како SPREAD како нивен IGP.

Некои автономни системи го користат BGP како свој IGP. Сликата 9.10 илустрира два

автономни системи, каде секој од нив користи IGP да пропагира рутирачка

информација меѓу своите внатрешни рутери.

Проф.д-р Тони Јаневски, Комутација и рутирање

Глава 9-12

.

. . ...BGP

R1 R2

IGP2IGP1

IGP1 IGP2

Слика 9.10 Концептуален приказ на BGP (меѓу автономни системи) и IGP (интерно во автономен систем)

На сликата 9.10, IGP1 се однесува на внатрешниот рутер протокол кој се

користи во AS1, додека IGP2 на протоколот користен во AS2. Сликата ни ја илустрира

следнава идеја: еден рутер може да користи два различни протоколи истовремено, еден

за комуникација надвор од автономниот систем и еден за комуникација во него. Во

принцип, рутери кои користат BGP за огласување на достапноста вообичаено, потребно

е да користат и IGP за добивање на информација во нивниот AС.

Еден од најраспространетите IGP е RIP протоколот, или Routing Information

Protocol. Тој претставува имплементација на distance-vector рутирањето за локалните

мрежи. Тој ги дели учесниците на активни и пасивни. Активните учесници ги

огласуваат своите рути на останатите, додека пасивните учесници ги ослушаат RIP

пораките и ги користат истите за ажурирање на своите рутирачки табели, но не ги

огласувааат рутите. Само рутер може да го користи RIP во активен режим, додека host-

от мора да работи во пасивен режим.

Рутер кој го користи RIP во активен режим, испраќа пораки за ажурирање на

секои 30 секунди. Ажурирањето содржи информација земена од моменталната датабаза

на рутерот. Секое ажурирање содржи сет на парови каде секој пар содржи IP мрежна

адреса и integer растојание до таа мрежа. RIP користи hop count metric за мерење на

растојаниjата. Во RIP, дефинирано е растојанието на рутерот да биде еднакво на 1 hop

за директно поврзана мрежа; 2 hop-а до мрежа која е достижна преку еден рутер, итн.

RIP специфицира неколку правила за потврдување на перформансите и

доверливоста. Сумирано, тоа би било: за да се заштити од осцилации вдолж патеката,

RIP специфицира дека постоечките рути треба да бидат запаметени се до појавување на

Проф.д-р Тони Јаневски, Комутација и рутирање

Глава 9-13

нова рута со помала вредност (во смисла да не се менува веќе постоечка рута со нова

која има иста вредност).

Што се случува доколку падне првиот рутер што ја огласува рутата?

RIP дефинира да сите ослушувачи мора да направат пауза со рутите кои ги

дознаваат преку RIP. Кога рутерот воспоставува рута во својата табела, тој стартува

тајмер за таа рута. Тајмерот мора да се рестартира секогаш кога рутерот прима друга

RIP порака која ја огласува рутата. Рутата станува невалидна доколку поминат 180

секунди без таа рута да биде огласена повторно.

RIP мора да се справува со три вида на грешки предизвикани од основниот

алгоритам. Прво, бидејќи алгоритмот не ги детектира јасно рутирачките loop-ови, RIP

мора да претпостави учесници на кои ќе им верува или да биде претпазлив за да не

дојде до вакви loop-ови. Второ, за заштита од нестабилност RIP мора да користи мала

вредност за максималната можна дистанца (RIP го користи 16 како бесконечна

дистанца, односно максимална вредност за растојанието). Трето, distance-vector

алгоритмот користен од RIP може да креира мало приближување или број на

неодреденост, каде што неусогласеноста се зголемува бидејќи рутирачката порака за

ажурирање се пропагира бавно преку мрежата. На наредната слика е претставен

проблемот на бавна конвергенција.

R1

R1

R3

R2 R3

R2Мрежа 1

Мрежа 2

a)

b) Слика 9.11 Проблем на бавна конвергенција: а) три рутери, секој со рута до мрежа 1; б) конекцијата до

мрежа 1 е исчезната, но R2 предизвикува јамка (loop) огласувајќи ја истата

За да се разбере проблемот разгледуваме множество рутери. Сликата 9.11a ни ги

прикажува рутите за мрежата 1 од рутерите R1, R2 и R3. Како што е прикажано на

сликата 9.11а, R1 има директна врска до мрежата 1, па така има и рута во својата табела

со растојание 1, кое ќе биде вклучено во периодичните информации од тој рутер до

Проф.д-р Тони Јаневски, Комутација и рутирање

Глава 9-14

соседните рутери. R2 ја дознава рутата од R1, и огласува рута со растојание 2 и,

аналогно R3 ја дознава рутата од R2 и ја огласува истата со растојание 3.

Сега претпоставуваме дека конекцијата на R1 со мрежата 1 паѓа. R1 веднаш ќе

ја ажурира својата рутирачка табела за да ја направи растојание 16 (бесконечност). Во

следната емисија, R1 ќе извести рута со поголема вредност. Но, R2 огласува рути

веднаш штом конекцијата на R1 ќе падне. Ако е така, R1 ќе ја прими пораката од R2 и

ќе го следи вообичаениот distance-vector алгоритам: забележува дека R2 огласува рута

до мрежата 1 со помала вредност, и смета дека е потребно 3 hop-ови да се стигне до

мрежата 1 (2 за R2 дa стигне до мрежата 1 плус 1 за да стигне од R1 до R2), и R1

воспоставува нова рута со R2 земен како следен hop. Тaка, доколку R1 или R2 примат

датаграм за мрежа 1, тие ќе го рутираат истиот меѓусебе се додека на истече времето на

живот на датаграмот. Следните емисии на RIP од два рутера не го решаваат брзо

проблемот. Во следната рунда на рутирачка размена, R1 ја емитира содржината на

својата рутирачка табела. Кога ќе дознае дека рутата на R1 до мрежата 1 има растојание

3, R2 пресметува нова дистанца за својата рута правејќи ја со вредност 4. во третата

рунда, R1 прима извештај од R2 кој вклучува зголемено растојание, и тогаш ја

зголемува дистанцата во својата табела на 5. Така двата рутера продолжуваат со броење

до максималната вредност на RIP.

Решавање на проблемот со бавна конвергенција

За примерот од сликата 9.11 можно е да се реши проблемот со бавна

конвергенција со користење на техника позната како split horizon update. Со користење

на оваа техника, рутерот не пропагира информација за враќање на рутата преку истиот

интерфејс од која рутата дошла. Во примерот, split horizon го штити рутерот R2 од

огласување на рутата до мрежата 1 назад до рутерот R1, така да ако R1 ја изгуби

врската до мрежата 1, мора да престане да ја огласува рутата кон R2. Со оваа техника

нема појава на рутирачки loop за дадениот пример. Наместо тоа, после неколку рунди

од ажурирањето, сите рутери ќе се согласат дека мрежата е недостапна. Треба да се

напомене дека оваа техника не заштитува од loop-ови во сите можни топологии.

Друга техника која се користи за решавање на проблемот на бавна

конвергенција е hold down. Таа го принудува рутерот да ја игнорира информацијата за

мрежата за фиксен временски период следејќи го приемот на пораката што ја прави

Проф.д-р Тони Јаневски, Комутација и рутирање

Глава 9-15

мрежата недостапна. Типично, hold down периодот е сетиран на 60 секунди. Идејата е

да се чека доволно долго за да се осигури дека сите уреди ги примиле лошите вести и

не примиле погрешно стара порака. Недостаток на оваа техника е што доколку настанат

рутирачки loop-ови, тие (пораките) може да бидат сочувани за време на hold down

периодот.

Последната техника за решавање на проблемот со бавна конвергенција е позната

како poison reverse. Еднаш кога исчезнува конекцијата, рутерот огласува конекција која

го памти записот за неколку периоди на ажурирање, и внесува бесконечна вредност во

нејзиното емитирање. За поголема ефективност, мора да биде во комбинација со

тригерирани ажурирања. Тие го принудуваат рутерот да испрати порака кога прима

лоши вести, наместо да чека на следниот период за емисија. Со ова се минимизира

времето во исчекување на добри вести.

9.2.1 RIP1 формат на порака

Има два типа на RIP пораки: пораки за рутирачката информација и пораки кои

се користат за побарување на информација. Двата типа користат ист формат составен

од фиксно заглавје следено од опционална листа на мрежа и distance парови. Сликата

9.12 го прикажува форматот на пораката кој се користи со верзијата 1 на протоколот,

позната како RIP1.

0 8 16 31 COMMAND (1-5) VERSION (1) MUST BE ZERO

FAMILY OF NET 1 MUST BE ZERO

IP ADDRESS OF NET 1

MUST BE ZERO

MUST BE ZERO

DISTANCE TO NET 1

FAMILY OF NET 2 MUST BE ZERO

IP ADDRESS OF NET 2

MUST BE ZERO

MUST BE ZERO

DISTANCE TO NET 2

. . . Слика 9.12 Формат на RIP верзија 1 порака

Проф.д-р Тони Јаневски, Комутација и рутирање

Глава 9-16

Рутерот или host-от може да побараат од друг рутер рутирачка информација со

испраќање на request команда. Рутерите одговараат на барањето со response команда.

Полето Version го содржи бројот на верзијата на протоколот.

RIP1 е исто така карактеристичен и по начинот на кој ги пренесува мрежните

адреси. Како што е прикажано на сликата 9.12, секоја мрежна адреса во записот на RIP

може да има адреса до 14 октети. Секако, на IP адресите им се потребни само 4; RIP

назначува дека останатите октети мора да бидат нула. Полето означено со FAMILY OF

NET и го дава типот на протокол под кој мрежната адреса треба да биде преведена.

RIP ја користи одредбата дека адресата 0.0.0.0 е назначена за default-на рута.

Последното поле во секој запис на RIP пораката, DISTANCE TO NET i, содржи

целобројна вредност на растојанието до дадена мрежа. Растојанието е мерено во број на

hop-ови.

9.2.2 RIP2 Формат на Порака

Форматот на пораката кој се користи со RIP2 е екстензија на RIP1 форматот, со

дополнителна информација која ги покрива неискористените октети на адресното поле.

Форматот на RIP2 пораката е прикажан на слика 9.13.

0 8 16 31 COMMAND (1-5) VERSION (1) MUST BE ZERO

FAMILY OF NET 1 ROUTE TAG FOR NET 1

IP ADDRESS OF NET 1

SUBNET MASK FOR NET 1

NEXT HOP FOR NET 1

DISTANCE TO NET 1

FAMILY OF NET 2 ROUTE TAG FOR NET 2

IP ADDRESS OF NET 2

SUBNET MASK FOR NET 2

NEXT HOP FOR NET 2

DISTANCE TO NET 2

. . . Слика 9.13 Формат на RIP 2 порака - пораката содржи subnet маска за секоја

адреса и информација за следен-hop

Проф.д-р Тони Јаневски, Комутација и рутирање

Глава 9-17

RIP 2 прикачува 16-битно ROUTE TAG поле на секој запис. Рутерот мора да го

испорача истиот tag и кога прима и кога испраќа. Оттука, tag-от обезбедува начин за

пропагација на дополнителна информација како што е потеклото на рутата.

RIP пораките не содржат поле за големина. Наместо тоа, RIP претпоставува дека

преносниот механизам ќе му ја каже на приемникот големината на дојдовната порака.

RIP2 пораките го користат UDP за да му ја пренесат на приемникот големината на

пораката. RIP работи на UDP портот 520.

9.2.3 Недостатоци на RIP хоп метриката

Користењето на RIP како внатрешен рутирачки протокол, го лимитира

рутирањето на два начина. Прво, RIP го ограничува рутирањето на hop-count мерење.

Второ, бидејќи користи мала вредност на hop-ови за бесконечност, RIP ја ограничува

големината на секоја мрежа која го користи. Во основа, RIP ја ограничува

распространетоста (span) на една мрежа до max. 16. Тоа значи дека мрежа која го

користи RIP може да има најмногу 15 рутери помеѓу било кои два host-а.

9.2.4 Комбинирање на RIP и BGP

Веќе напоменавме дека еден рутер може да ги користи и Interior Gateway

Protocol за собирање на рутирачка информација во својот автономен систем, и Exterior

Gateway Protocol за огласување на рути на другите автономни системи. Во принцип,

треба да е едноставно да се конструира софтвер кој би ги комбинирал двата протокола,

правејќи да е возможно прифаќањето на рутите и нивно огласување без човечка

интервенција.

Технички, IGP протоколите, како што е RIP, се рутирачки протоколи. Рутерот ги

користи овие протоколи за да ја ажурира рутирачката табела базирана на

информацијата што тој ја добива од останатите рутери во автономниот систем.

RIP е имплементиран како UNIX програм, наречен routed (од route+d = route

daemon, каде што daemon е процес кој се извршува во позадина на UNIX оперативен

систем), кој огласува информација од локалната рутирачка табела и ја менува истата

Проф.д-р Тони Јаневски, Комутација и рутирање

Глава 9-18

кога прима ажурирани податоци. RIP има доверба во рутерите внатре во автономниот

систем за коректноста на рутирачките информации.

Спротивно на тоа, надворешните протоколи како што е BGP немаат доверба во

рутерите на другите автономни системи. Следствено, надворешните протоколи не ги

огласуваат сите можни рути од локалната рутирачка табела.

Рутирање меѓу Автономни Системи

Видовме дека EGP како што е BGP, допушта на автономниот систем да огласува

информација за достапноста на друг систем. Исто така би било корисно да се обезбеди

и рутирање помеѓу автономните системи (inter-autonomous routing) со кое рутерите би

избирале патеки со најмала вредност. Да се стори тоа, потребно е да постои

дополнителна доверба. Проширувањето во поглед на доверба од еден автономен систем

на повеќе е доста комплексно.

Групирањето на автономни системи побарува проширување на рутирачките

протоколи. Кога се известуваат растојанија, вредностите мора да се зголемат кога

минуваат преку граница од една на друга група. Техниката наречена metric

transformation, ги дели вредностите на растојанијата на три категории (три различни

граници). Ефектот од ваквата поделба е очигледен: за дадена дестинациона мрежа,

секоја патека која лежи целосно во еден автономен систем е гарантирано да има помала

вредност отколку патека која излегува надвор од автономниот систем.

Механизмот создаден да обезбеди интерфејс меѓу автономните системи и кој ги

распознава повеќето протоколи (како IGP и BGP) е познат како gated. (доаѓа од gate+d

што значи gate deamon). Gated може да прими RIP пораки и да ја модифицира

локалната рутирачка табела исто како routed програмот. Исто така може да огласува од

неговиот автономен систем со користење на BGP. Со него се овозможува систем

администраторот да назначи точно кој gated мрежи може да ги огласи и како да ги

извести растојанијата до овие мрежи. Оттука, gated е значаен бидејќи ни дава дека е

возможно да се направи автоматизиран механизам за поврзување на IGP со BGP без да

се жртвува заштитата. Gated ја имплементира и метричката трансформација. Оттука

можно е да се користи gated меѓу два автономни системи исто како и на границата

помеѓу две групи на рутери (каде секој партиципира во IGP).

Проф.д-р Тони Јаневски, Комутација и рутирање

Глава 9-19

9.3 ОSPF (Open Shortest Path First) рутирачки протокол

OSPF претставува interior gateway протокол кој го користи link state алгоритмот,

поконкретно Dijkstra алгоритмот. Самото име дава дека спецификацијата е достапна во

јавната литература што го прави отворен стандард за кој не е потребно да се плаќа

лиценца. Има неколку специфични карактеристики:

• OSPF вклучува type of service рутирање. Може да се инсталираат повеќе рути до

дадена дестинација, по една за секој приоритет или тип на сервис.

• OSPF обезбедува load balancing (баланс на сообраќајното оптеретување).

Доколку се дадени повеќе рути до една дестинација, OSPF го дистрибуира

сообраќајот еднакво по сите рути.

• OSPF дозволува партиција на мрежите и рутерите во подмножества наречени

области (areas), со цел полесно управување.

• OSPF назначува дека сите размени помеѓу рутерите треба да бидат

автентицирани. Тука идејата е да се овозможи само доверливите рутери да

пропагираат рутирачка информација.

• За максимална флексибилност, OSPF дозволува да се даде опис на виртуелна

мрежна топологија. На пример, може да конфигурираме виртуелен линк меѓу

два рутера дури и ако физичката конекција меѓу двата рутера побарува

комуникација преку транзитна мрежа.

• OSPF им допушта на рутерите да разменуваат рутирачка информација добиена

од друга, надворешна страна.

Протоколот OSPF има двослојна хиерархија во дадена мрежа, како што е

прикажано на слика 9.14. Разликуваме т.н. зони или области (areas): локални зони и

скелетна (backbone) мрежа. Во секоја локална зона се вршат link-state огласувања

ограничени на рутерите во локалната област. Секоја локална зона има зонски

(граничен) рутер преку кој се рутира целиот сообраќај од Интернет кон хостовите во

локалната зона и обратно. Зонските гранични рутери (area border рутери) се поврзани

во скелетна мрежа и комуницираат со другите гранични рутери (од другите локални

зони). За поврзување на граничните рутери постојат и други рутери во скелетната

(backbone) мрежа кои користат OSPF само во рамките на скелетната мрежа. Вака

Проф.д-р Тони Јаневски, Комутација и рутирање

Глава 9-20

формираната двонивовска мрежна структура рутирана со OSPF на две одвоени нивоа

претставува еден автономен систем. Автономниот систем има граничен рутер (boundary

router) преку кој се поврзува со други автономни системи во Интернет.

Слика 9.14 Двослојна хиерархија на OSPF

9.3.1 OSPF формат на порака

Секоја OSPF порака започнува со фиксно, 24-октетно заглавје, како што е

прикажано на слика 9.15.

Полето VERSION ја дава верзијата на протоколот. Полето TYPE го

идентифицира типот на пораката. Одделните типови на пораки кај OSPF се дадени во

табела 9.3.

0 8 16 24 31

VERSION (1) TYPE MESSAGE LENGTH

SOURCE ROUTER IP ADDRESS

AREA ID

CHECKSUM AUTHENTICATION TYPE

AUTHENTICATION (octets 0-3)

AUTHENTICATION (octets 4-7)

Слика 9.15 Фиксно 24-октетно OSPF заглавје на пораката

Проф.д-р Тони Јаневски, Комутација и рутирање

Глава 9-21

Табела 9.3 Типови на пораки кај OSPF

Тип Значење

1 Hello (за тестирање на достапноста)

2 Опис на датабазата

3 Барање за статус на линкот

4 Ажурирање на статусот на линкот

5 Потврда на статусот на линкот

Полето означено како SOURCE ROUTER IP ADDRESS ја дава адресата на испраќачот,

а полето означено како AREA ID го дава 32-битниот идентификациски број за областа.

Бидејќи секоја порака може да вклучи автентикација, полето AUTHENTICATION

TYPE ја дава автентикациската шема што се користи (моментално, 0 значи нема

автентикација, а 1 значи користење на едноставен password).

OSPF испраќа hello пораки на секој линк периодично за да воспостави врска и ја

тестира достапноста на соседите.

Рутерите разменуваат OSPF database description пораки за да ја иницијализираат

нивната мрежна тополошка датабаза. Во размената, еден рутер служи како master,

додека другиот е slave. Slave-от ја потврдува секоја database description порака со

одговор.

9.4 Протоколи за мултикаст рутирање

Преносот на еден пакет од еден извор до повеќе специфицирани дестинации е

посложено да се реализира во Интернет отколку уникаст преносот (т.е. точка-точка).

Рутирањето поврзано со мултикаст пренос на информации преку Интернет се нарекува

мултикаст рутирање. Има три генерални апликации на мултикаст за кои е од интерес

мултикаст рутирањето:

• Еден кон повеќе (one to many) – примери: видео во живо, дигитална ТВ,

кеширање, обуки, корпоративна комуникација;

• Повеќе кон еден (many to one) – примери: аукции, гласање, собирање на

податоци;

Проф.д-р Тони Јаневски, Комутација и рутирање

Глава 9-22

• Повеќе кон повеќе (many to many) – примери: distance-learning, колаборации,

мултимедиско конференцирање, игри со повеќе играчи, chat групи.

За да може даден датаграм (пакет) да се дистрибуира истовремено до повеќе

дестинации потребно е дасе креираат т.н. мултикаст групи. За креирање на мултикаст

групи се користи IGMP (Internet Group Management Protocol). Денес постои и IGMP

v2 (верзија 2 на IGMP).

Хостовите се приклучуваат или одјавуваат од мултикаст група преку IGMP

комуникација со мултикаст рутерите. Притоа, секој хост кој ќе се приклучи на

мултикаст група добива т.н. мултикаст адреса покрај IP адресата која веќе ја има за

дадениот мрежен интерфејс (која ја користи за уникаст комуникација). Кај IP

адресирањето, за мултикаст е дефинирана класа D на IP адреси (види глава 6). Значи,

хостовите кои се приклучени на дадена мултикаст група располагаат со една уникаст

адреса и со соодветна мултикаст адреса, зависно од групата. Може еден хост (со даден

интерфејс) да членува во даден момент во повеќе мултикаст групи, при што ќе има

асоцирано соодветно неколку мултикаст IP адреси истовремено.

За мултикаст се користи мултикаст рутирачка табела која содржи многу повеќе

информации од стандардната (уникаст) рутирачка табела.

Доколку пак рутерот не поддржува мултикаст, тогаш се применува

енкапсулација на мултикаст датаграмите во вообичаени уникаст датаграми кои се

тунелираат од еден мултикаст рутер до друг. Енкапсулација значи даден IP датаграм да

се стави како товар во нов IP пакет со ново заглавие. На крајот од тунелот, рутерот кон

кој се адресирани пакетите од тунелот, ги декапсулира (го отфрла додаденото

заглавие), по што ги рутира со иницијалното заглавија на датаграмите.

Цел на мултикастот е да се пронајде т.н. мултикаст дрво (или дрва) кои

поврзуваат рутери кои имаат локални членови во мултикаст групата. Дрвото најчесто

има корен кој претставува извор на информациите кои се мултикастираат. При

креирањето на мултикаст дрва, не се користат сите линкови меѓу рутерите, туку само

некои. Постојат неколку типови на мултикаст дрва:

• Дрво базирано на изворот (source-based tree): различно мултикаст дрво по

извор:

– Shortest Path Tree (SPT) – дрво составени од најкратки патеки од

изворот до членовите на групата

Проф.д-р Тони Јаневски, Комутација и рутирање

Глава 9-23

– Reverse Path Forwarding (RPF) - се заснова на информацијата во

рутерот за најкраткиот пат од него до изворот

• Заеднички дрва (shared trees): истото дрво се користи од сите членови на

мултикаст групата: Minimal Spanning, и Central-based trees

На слика 9.16 е прикажан пример на мултикаст дрво од типот Shortest Path Tree. Дрвото

е создадено од коренот со додавање на гранки кои се најкратки патеки до

дестинационите мрежи во секој рутер по патот (каде што се наоѓаат приемниците, т.е.

дестинационите хостови – членови на мултикаст групата).

Слика 9.16 Пример на мултикаст дрво: Shortest Path Tree

Самите мултикаст протоколи за рутирање се засновани на истите принципи на

кои се засновани и уникаст протоклите за рутираењето, т.е. на истите алгоритми (кои

беа изложени во глава 8). Во литературата најчесто се сретнуваат следниве мултикаст

протоколи за рутирање:

• Distance Vector Multicast Routing Protocol (DVMRP)

• Multicast extensions to OSPF (MOSPF)

• Protocol Independent Multicast (PIM), кој пак може да биде во два мода:

– Густ мод - Dense mode (DM) – во овој мод се претпоставува дека речиси

сите рутери ќе бидат вклучени во мултикаст дрвото

– Редок мод - Sparse mode (SM) – во овој мод се претпоставува дека мал

број рутери ќе бидат вклучени во мултикаст дрвото

Како пример на мултикаст рутирачки протокол ќе го разгледаме PIM, бидејќи

останатите два се засноваат на веќе добро познатите distance-vector и link-state

алгоритми за рутирање.

R1

R2

R3

R4

R5

R6 R7

2

1

6

3 4

5

i

Рутер со приклучени членови на мултикаст групата

Рутер без приклучени членови на мултикаст групата

Линк за forwarding, i е број по кој дадениот линк е додаден од алгоритмот

Легенда: Извор (source)

Проф.д-р Тони Јаневски, Комутација и рутирање

Глава 9-24

Слика 9.17 PIM мултикаст рутер во редок мод (sparse mode)

На примерот на мултикаст рутирање со PIM sparse mode (слика 9.17) постои т.н.

централен рутер (во случајов тоа е рутерот R6). Сите рутери (тоа се рутерите кои

имаат хостови од мултикаст групата на директно закачените мрежи на нив) кои

сакаат да се приклучат во мултикаст дрвото праќаат т.н. join порака до централниот

рутер. Централниот рутер за дистрибуира информацијата за новите членови на

мултикаст дрвото понатаму до останатите рутери во дрвото.

R1

R2

R3

R4

R5

R6

R7

join

join

join

Сите информации се мултикастираат од централен рутер Централен рутер (Rendezvous Point)