Прејди на содржината

Корисник:Dragan 89

Од Википедија — слободната енциклопедија

Border Gateway Protocol (BGP) е протокол којшто ги подржува основните рутирачки одлуки на Интернет. Тој во него содржи табела од IP(Internet Protocol) мрежи или префикси кои што ја одредуваат мрежната достапност помеѓу автономните системи. Често се опишува како протокол на векторска патека. BGP не користи метрики на традиционален Interior Gateway Protocol(IGP), туку донесува рутирачки одлуки базирани на патеки, мрежни правила и политики. Поради оваа причина, тој посоодветно се декларира како проткол за достапност наместо протокол за рутирање.

BGP е создаден за да го замени Exterior Gateway Protocol(EGP) рутирачкиот протокол за да овозможи целосно децентрализирано рутирање со цел за да се овозможи отстранување на NFSNet Internet Backbone мрежата. Ова му овозможи на интернетот да стане вистиски децентрализиран систем. Од 1994 до ден денеска интернетот ја користи четвртата верзија на BGP. Сите предходни верзии се сметаат за застарени. Главното подобрување во четвртата верзија е подршката на Classless Inter-Domain Routing и употребата на route aggregation за да се намали големината на routing tables. Од Јануари 2006, четвртата верзија е кодифицирана во RFC 4271, која што помина низ 20 нацрти базирани на преходните RFC 1771 верзија 4. RFC 4271 верзијата поправи голем број на грешки и го приближи RFC многу поблиску во индустриската примена.

Повеќето од интернет корисниците не го гористат BGP директно. Бидејќи сите интернет сервис провајдери мора фа го користат BGP со цел за да воспостават врска едни со други, BGP го прави еден од позначајните протоколи на интернетот. Ако се спореди ова со Signalin System 7(SS7), ќе видиме дека голем број на приватни IP мрежи го користат BGP интерно.

Петте нивоа на TCP/IP моделот
5. Применето ниво (Application layer)

DHCP • FTP • IMAP4 • POP3 • SIP • SMTP • SSH • BGP • …

4. Преносно ниво

UDP • TCP • DCCP • SCTP • RSVP • ECN

3. Мрежно ниво

IP (IPv4 • IPv6) • ICMP • IGMP • RSVP • IPsec

2. Податочно ниво

ATM • DTM • Ethernet • FDDI • Frame Relay • GPRS • PPP • ARP • RARP • L2TP • PPTP

1. Физичко ниво

Етернет • ISDN • Модеми • PLC • SONET/SDH • G.709 • Wi-Fi • …

Кутијава:

Операции

[уреди | уреди извор]

Кај BGP соседите, врската се воспоставува со мануелна конфигурација помеѓу рутерите за да се креира TCP сесија на портата 179. BGP емитер периодично ке испраќа 19-бајтна порака со цела за да се одржи врската (стандардно на секои 60 секунди). Помеѓу протоколите, BGP е уникатен во користењето на TCP како негов транспортен протокол.

Кога BGP работи внатре во Автономни Системи, тој е именуван како Internal BGP (IBGP или Interior Border Gateway Protocol). Кога работи помеѓу автономни системи е именуван како External BGP (EBGP или Exterior Border Gateway Protocol). Во Cisco оперативните системи, IBGP рутите имаат административна должина од 200, што е помалку преферирано од EBGP или било кој друг внатрешно рутирачки протокол. Исто така и многу други имплементации на рутери префериираат EBGP.

Користи 20 бајти за секој хедер.

Преговори за екстензии

[уреди | уреди извор]

За време на OPEN BGP може да се преговара за[1] опционалните можности на сесијата, вклучувајки ги повеќепротоколните додатоци како и различни модови за обновување. Ако мултипротоколните екстензии на BGP[2] се преговараат за време на креирањето, емитерот на BGP може да стави префикс на Network Layer Reachability Information (NLRI) кој што го претставува со адресно фамилијарен префикс. Овие фамилии вклучуваат IPv4(стандардно), IPv6, IPv4/IPv6 Виртуелни приватни мрежи како и multicast BGP. Значително растечки, BGP се користи како генерализиран сигнален протокол за носење на информации за рутите кои и што не мора да бидат дел глобалната мрежа(Интернет), како што се Виртуелните Приватни Мрежи.[3]

Конечни автомати

[уреди | уреди извор]
BGP state machine

Со цел за да се донесе одлука во неговие операции со други BGP врски, BGP врската користи едноставни Finite State Machine(FSM) или таканарелени конечни автомати, кои што се состојат од од шест состојби: Idle; Connect; Active; OpenSent; OpenConfirm; и Established; За секоја peer-to-peer сесија, BGP имплементацијата чува променлива за состојбата која кажува во која од овие шест состојби се наоѓа сесијата. BGP протоколот дефинира порака која што секоја врска треба да ја размени со цел за да премине сесијата од една состојба во друга. Првата состојба е “Idle”. Во “Idle” состојбата BGP ги иницијализира сите ресурси, ги одбива сите обиди за влезни BGP конекции и иницира TCP конекција со врската. Втората состојба е “Connect”. Во Connect состојбата рутерот чека TCP поврзувањето да заврши и доколку е успешно преоѓа во состојбата “OpenSent”, доколку е неуспешно го ресетира ConnectRetry бројачот, и по истекување на времето преоѓа во состојбата “Active”. Во “Active” состојбата, рутерот го ресетира ConnectRetry бројачот и се враќа во “Connect” состојбата. Во “OpenSent” состојбата, рутерот испраќа порака Open и чека одговор. Се разменуваат Keepalive пораки и доколку е успешен приемот, рутерот преоѓа во состојбата “Established”. Во “Established” состојбата, рутерот може да испраќа/прима Keepalive, Update и Notification пораки до/од неговата врска.

  • Idle состојба:
    • Ги одбива сите влезни BGP конекции.
    • Иницира TCP конекција со неговата конфигурирана BGP врска.
    • Наслушува TCP конекција од неговата BGP врска.
    • Ја менува состојбата во Connect.
    • Ако се појави грешка во сотојбата на FSM процесот, BGP сесијата веднаш се прекинува и се враќа во состојбата Idle. Некои од причините поради кои рутерот не проаѓа од состојбата Idle во некоја друга состојба се:
      • TCP портата 179 не е отворена.
      • Случајна TCP порта преку 1023 не е отворена.
      • Адресата на врската не е соодветно конфигурирана во некој од рутерите.
  • Connect состојба:
    • Чека на успешни TCP преговори со врската.
    • BGP не поминува многу време во оваа состојба доколку TCP сесијата е успешно воспоставена.
    • Испраќа Open порака на врската и преминува во состојбата OpenSent.
    • Доколку се појави грешка, BGP преминува во Active состојбата. Некои од причините за настанување на грешки се:
      • TCP портата 179 не е отворена.
      • Случајна TCP порта преку 1023 не е отворена.
      • Адресата на врската не е соодветно конфигурирана во некој од рутерите.
  • Active состојба:
    • Доколку рутерот не воспоставил успешна TCP сесија, тогаш тој завршува во Active состојбата.
    • BGP FSM ке проба да ресетира друга TCP сесија со врската,и ако е успешно, тогаш ке испрати Open порака до врската.
    • Ако е повторно неуспешно, FSM се враќа во Idle состојбата.
    • Континуирани неуспеси можат да резултираат со циклично преминува на ритерот од Active во Idle состојбата. Некои од причините за ова се:
      • TCP портата 179 не е отворена.
      • Случајна TCP порта преку 1023 не е отворена.
      • Конфигурациска грешка на BGP.
      • Мрежна конгестија.
  • OpenSent состојба:
    • BGP FSM слуша Open порака од неговата врска.
    • Откако пораката ке биде примена, рутерот ја проверува валидноста на Open пораката.
    • Доколку постои некаква грешка тоа е поради тоа што некои од полињата на пораката Open не се поклопуваат со соодветната врска, пр. несоодветна BGP верзија, несоодветена MD5 лозинка, рутерот од другата страна на врската очекува друга My AS. Тогаш рутерот ке испрати Notification порака потенцирајки зошто настанала грешката.
    • Доколку не постои грешка, ке биде испратена Keepalive порака, ке бидат поставени различни бројачи и ке се премине во состојбата OpenConfirm..
  • OpenConfirm состојба:
    • Врската од едната страна наслушува Keepalive порака од врската од спротивната страна.
    • Доколку е примена Keepalive порака и ниту еден бројач не е истечен пред некзиното примање, BGP преминува во состојбата Established.
    • Доколку пројачот истече пред примањето на Keepalive пораката, или доколку се појави некаква грешка, рутерот повторно премунува во состојбата Idle.
  • Established состојба:
    • Во оваа состојба, врските си праќаат Update пораки за да си разменат информации за секоја рута која што е опфатена во BGP врската.
    • Доколку постои било каква грешка во Update пораката тогаш се испраќа Notification порака до врската, и BGP повторно преминува во Idle состојбата.


Основни BGP ажурирања

[уреди | уреди извор]

Откако BGP сесијата ке почне да работи, BGP емитерите ке разменат UPDATE пoраки за дестинациите за кои што нудат можност за поврзување. Во протоколот, основниот опис за CIDR рутата се нарекува Network Layer Reachability Information (NLRI). NLRI ги вклучува префиксите на очекуваните дестинации, должината на префиксите, патеката на автономните системи до соодветната дестинација и атрибутите на наредниот hop, кои што можат да носат широк спектар на додатни информации кои што влијаат на политиката на прифаќање на рутерот кој што е примач. BGP емитерите постојано најавуваат нови NLRI кои што нудат поврзување, но исто така и најавуваат и повлекувања на префикси за кои што емитерите не нудат повеќе можност за поврзување.

Можноста на BGP рутерот за поврзување и учење на рути.

[уреди | уреди извор]

Во наједноставен случај сите рутери сo единствен AS кои што учевтвуваат во BGP рутирањето, мора да бидат конфигурирани во full mesh: секој рутер мора да биде конфигуриран со статична рута до секој друг рутер. Ова предизвикува проблем за скалирање, поради раснењето на бројот на потребни конекции со бројот на потребните рути за вклучување. За олеснување на проблемот, BGP имплементира две опции: route reflectors (RFC 4456) и confederations (RFC 5065). Следнава дискусија за основно UPDATE процесирање се однесува на целосна IBGP mesh.

Основно процесирање на ажурирања

[уреди | уреди извор]

Дадена BGP рута може да прими NLRI како ажурирања од повеќе соседни рутери и може да испрати NLRI до истите. Концептуално, BGP си содржи своја “master” рутирачка табела, наречена Loc-RIB(Local Routing Information Base), одвоена од главната routing table на рутерот.За секој соседен рутер BGP процесот содржи концептуална Adj-RIB-In (Adjacent Routing Information Base, Incoming) која што содржи NLRI примен од соседот, и концептуален Adj-RIB-Out (Outgoing) за NLRI кој што треба да биде испратен до тој сосед.

Концептуално, во предходниот параграф, наведено е дека физичкото складирање на овие табели e одлученос од страна на имплементацијата на BGP кодот. Нивната структура не е видлива од страна на другите BGP рутери, иако тие можат да бидат увидени од страна на локалниот рутер со команди за управување. Многу чест случај е Adj-RIBs и Loc-RIB да се сочуваат во една иста податочна структура, со додатни информации прикачени на RIB записите. Додатните информации му кажуваат на BGP процесот работи како што се: дали индивидуалните записи припаѓаат на Adj-RIB за конкретен сосед и дали Loc-RIB записите ги исполнуваат условите да бидат запишани во рутирачката табела на процесот за управување на локалниот рутер.

Под eligible to be submitted, BGP ке ги достави оние рути за кои што смета дека се најдобри за процесот на рутирачката табела. Во зависност од имлементацијата на тој процес, BGP рутата немора да значи дека ке биде изберена. На пример, директно поврзан префикс кој што е откриен од страна на сопствениот хардвер на рутерот, најчесто се смета за најпрефериран. Се додека интерфејсот на директно поврзаната рута е активен, BGP рутата на дестинацијата нема да биде сместена во рутирачката табела. До неодамна, честа грешка беше да се каже дека BGP ги носи политиките. BGP всушност носи информации спред кои рутерот ке може да донесе одлука во однос на политиката. Некои од информациите кои што се носат кои што се експлицитно наменети за бидат искористени во донесување на одлука врз основа на политиката се communities(заедници) и multi-exit discriminators(MED) познати како (повеќе-излезни дискриминатори).

Избирање на рута(пат)

[уреди | уреди извор]

BGP стандардот дефинира неколку фактори кои што влијаат врз одлучувањето, поголемиот дел од нив се користат кај повеќе слични рутирачки процеси, за избирање на NLRI(Network Layer Reachability Information) за да одат до Loc-RIB(Routing Information Base). Првата одлука се однесува на проценувањето на NLRI дали неговиот нареден hop мора да биде достапен(или разрешлив). Со други зборови, наредниот hop мора да биде достапен со тоа што ке постои активна рута или пат до него, кои што веќе се наоѓаат во главната routing table на рутерот.

Следно, за секој сосед, BGP процесот применува различни стандарди и критериуми зависни од имплементацијата за да одлучи кои рути треба да одат во Adj-Rib-In. Соседот моќе да испрати повеќе применливи рути до дестинацијата, но првото ниви на преферирање е на нивото кај соседот. Само една рута за секоја дестинација ке биде сместена во концептуалната Аdj-RIB-In. Овој процес исто така ке ги избрише сите рути од Аdj-RIB-In кои што се повлечени од страна на соседот.

Секој пат кога Adj-RIB-In ке се промени, главниот BGP процес одлучува дали некоја од рутите на соседите повеќе се преферираат од некои од рутите кои што веќе се наоѓаат во Loc-RIB. Ако е така, тогаш ги заменува. Ако дадена рута е повлечена од страна на соседот, и не постои друга рута до таа дестинација, рутата се одстранува од Loc-RIB, и повеќе не се испраќа до главната рутирачка табела од страна на BGP. Доколку рутерот нема рута до некоја дестинација од некој извор којшто не е BGP, тогаш повлечената рута ке биде одстранета од главната рутирачка табела.

Communities (Заедници)

[уреди | уреди извор]

BGP заедниците се тагови за атрибути кои што можат да бидат применети на дојдовните и излезните префикси со цел за да се постигне некоја заедничка цел (RFC 1997). Додека вообичајно е да се каже дека BGP му дозволува на администраторот да ја креира политиката според која ISP ке управува со префиксите, стриктно зборувано, ова генерално и не е возможно. На пример, нема концепт кој ке му овозможи на еден AS да му забрани на друг AS да испраќа префикси само на корисниците од Северна Америка. Наместо тоа, ISP генерално објавува листа на добро познати или неслободни заедници со опис за секоја од нив, што во суштина станува договор за тоа како ке бидат управувани префиксите. ISP може да формулира дека корисниците со заедница XXX:500 ке бидат објавени до сите врски, додека на заедниците XXX:501 ке им биде забрането објавување спрема Северна Америка. Корисницие едноставно си ја подесуваат својата конфигурација за да ги вклучат соодветните заедници во секоја рута, и ISP e одговорен за тоа кој префикс на кого ке му биде објавен. Крајниот корисник нема техничка можност да придонесе кон точно превземање на акции кои што треба да бидат извршени од страна на ISP. Грешките во оваа подрачје се многу ретки и случајни.

Многу честа тактика кај крајните корисници е да користат BGP заедници (најчесто ASN: 70, 80, 90, 100) за да се контролира локалниот приоритет кој што ISP го доделува на обајвените рути наместо да се користи MED(ефектот е сличен). Исто така треба да се напомене дека атрибутот на заедницата е транзитивен, меѓутоа заедници применети од страна на корисниците многу ретко успеваат да бидат пропагирани подалеку од наредниот hop AS.

Надоградени Communities(Заедници)

[уреди | уреди извор]

Надоградениот атрибут на заедницата на BGP е додаден во 2006-та година со цел за да се прошири подрачјето на овие атрибути и да се овозможи нивно структурирање според типот на полето. Надоградениот формат се состои од еден или два октети за типот на полето проследено со седум или шест октети за содржината на соодветниот атрибут на заедницата. Дефиницијата на овој надограден атрибут на заедницата е документиран во RFC 4360. [4]

Употребa на multi-exit discriminators

[уреди | уреди извор]

MED-ови, дефинирани во главниот BGP стандард, примарно имаат намена за му ги покажат на соседниот AS предностите од тоа што неколку линкови се преферирани за дојдовниот сообраќај. Другата примена на MED-овите е за објавување на вредноста, типично базирана на задоцнувањето, на повеќе АS-ови кои што имаат присуство на IXP, кое што тие го имаат наметнато за испраќање на сообраќај до некоја дестинација.

Проблеми и недостатоци на BGP

[уреди | уреди извор]

Скалабилност на Internal BGP(IBGP)

[уреди | уреди извор]

Автономните системи со Internal BGP(IBGP) мора да ги има сите негови IBGP врски поврзани во full mesh(каде што сите се меѓусебно поврзани со директна врска). Оваа full-mesh конфигурација бара секој рутер да одржува сесија со секој друг рутер. Во поколеми мрежи, големиот број на сесии значително влијаат врз перформансите на рутерите, како недостаток на меморија или премногу операции за обработување на процесорот.

Route Reflectors, го намалуваат бројот на конекции кои што се потребни за автономните системи. Еден рутер (или 2 за редундантност ) можат да бидат направени како route reflectors: додека другите рутери во автономните системи треба само да бидат конфигурирани како врски до нив.

route reflectors[5] го намалуваат бројот на конекции кои што се потребни за автономните системи. Еден рутер (или 2 за редундантност ) можат да бидат направени како route reflectors: додека другите рутери во автономните системи треба само да бидат конфигурирани како врски до нив.

Confederations претставува колекција од автономни системи. Во пракса,[6] само еден од конфедерациските АС броеви може да биде виден од интернетот како целина. Конфедерациите се користат кај поголемите мрежи, каде што поголем АС може да биде конфигуруран за да опфати помал внатрешен АС.

Confederations можат да бидат употребувани заедно со route reflectors. И двете можат изложени на постојана осцилација, освен ако не постојат некои правила околу дизајнот, кои што влијаат врз BGP и внатрешните рутирачки протоколи.[7]

Како и да е, и овие алтернативи си носат свои проблеми, како на пример:

  • Осцилација на рута
  • Под-оптимално рутирање
  • Зголемување на времето на конвергенција на BGP.[8]

Додатно, route reflector и BGP confederations не се дизајнирани за да ја поедностават рутерската конфигурација на BGP. Но сепак, ова се едни од покористените алатки кај поискусните BGP мрежни архитекти. Овие алатки може да се комбинираат, на пример, како хиерархиски подредени route reflectors.

Нестабилност

[уреди | уреди извор]

Рутирачките табели управувани од BGP имплементацијата, континуирано се прилагодуваат за да ги претстават вистинските промени во мрежата, како што се прекини на врски, паѓање и повторно подигање на рутерите и сл. Во мрежата како целина, вакви работи почесто се случуваат, меѓутоа промените за конкретен рутер или врска би требало многу ретко да се случуваат. Доколку рутерот е лошо управуван или лошо конфигуриран, може автоматски да дојде во циклус на постојано паѓање и подигање. Ваквиот случај на постојано повлекување и повторно најавување, познато како route flapping, може да предизвика преоптеретени активности кај сите други рутери кои што добиваат известување за прекинатата врска, поради тоа што таа врска постојано ке биде повлекувана и додавана во нивните рутирачки табели. BGP e дизајниран на тој начин што додека се прави ажурирање на рутите, целиот сообраќај е прекинат. Во интернетот, промените во BGP може да предизвикаат прекини од неколку минути.

Карактеристика позната како route flap damping (RFC 2439) е вградена во многу BGP имплементации со цел за да ги ублажи ефектите од route flapping. Без да бидат пригушени зголемените активности може да дојде до прекуменрен процесирачки товар на рутерите, и да има негативен ефект врз целокупната стабилност на рутирањето. Со пригушувањето, флапирањето на рутата експоненцијално се распаѓа. При првиот случај кога рутерот ке биде невидлив и за брзо време се опоравува, пригушувањето не превзема акција веднаш, туку само го забележува бројот на паѓањата на BGP. По втората појава, BGP го избегнува тој конкретен префикс на одредено време, и им го мери времето на сите такви слични појави кои што ке проследат. Пригушувањето исто така може да гу ублажи и denial of service нападите.

Раст на рутирачката табела(routing table)

[уреди | уреди извор]
BGP table growth on the Internet.
Number of AS on the Internet.

Еден од најголемите проблеми со кои со соочува BGP, како целата интернет инфраструктура, е растот на рутирачката табела на интернетот. Ако глобалната рутирачка табела порасне до точка каде што некој постар и по неспособен рутер не може да одржи чекор со побарувањата на меморијата и процесорскиот товар за одржување на табелата, овие рутери повеќе нема да бидат ефикасни премини спрема деловите од интернетот кои што тие ги поврзуваат. Како додаток, па можеби и како уште позначаен проблем е тоа што на поголемите рутирачки табели им потребно зналително повеќе време да се стабилизираат после позначајна промена во мрежата, со што го прават мрежниот сервис неверодостоен па дури и недостапен.

До доцната 2001 година, глобалната рутирачка табела имаше експоненцијале пораст, со што преставуваше закана за глобален пад на поврзаноста. Со цел за да се спречи ова, интернет сервис провајдерите се стремеа кон тоа да ја држат глобалната рутирчка табела што е можно помала со употреба на Classless Inter-Domain Routing (CIDR) и route aggregation. Додека ова го намали растот на рутирачката табела на линеарно ниво, со ширењето на побарувачката за поврзување на крајните корисници, овој пораст повторно стана експоненцијален кон средината на 2004 година. Како што до Април 2010 година табелата веќе има вишок од 310,000 внесови.[9]

Проблем со балансирање на товарот

[уреди | уреди извор]

Друг фактор којшто предизвикува раснење на рутирачката табела е потребата од балансирањето на товарот од multi-homed мрежите. Не претставува тривијална задача да се балансира влезниот сообраќај на multi-homed мрежите мреку повеќе влезни патеки, што се должи на ограничување на процесот за избирање на рута на BGP. Мulti-homed мрежите, доколку ги објавуваат истите мрежни блокови преку сите BGP врски, резултатот може да биде една или повеќе од неговите дојдовни врски да биде преоптеретена додека другите да останат неискористени, затоа што надворешните врски како оптимална ке ја изберат најоптоварената патека. Како и повеќето од рутирачките протоколи, BGP протоколот не може да забележи преоптоварување.

За да се разреши овој проблем, BGP администраторите на multi-homed мрежите поголемите блокови на континуирани IP адреси ги делат во помали блокови, да предизвикаат различни блокови да изгледаат оптмално на различни патеки, со што надворешните мрежи ке избираат различна патека за да пристигнат до различен блок од таа multi-homed мрежа. Ваквите случаи ке го зголемат бројот на рутите како што веќе е видено во глобалната табела на BGP.

Побарувања на рутерот за користење на BGP за интернет

[уреди | уреди извор]

Рутерите, посебно помалите кои што се наменети за домашна или канцелариска употреба(Small Office/Home Office познати како SOHO), може и да не вклучуваат софтвер за BGP. Некои SOHO рутери едноставно не се способни да подржат BGP и да корисат BGP рутирачки табели од било која големина. Некои комерцијални рутери може да имаат потреба од извршна верзија на софтвер којшто содржи BGP, или пак лиценца која што ке може да го активира истиот. Едни од Open Source пакетите кои го користат BGP се: GNU Zebra, Quagga, OpenBGPD, Bird, XORP и Vyatta. Направи што се претставуваат како Layer 3 свичеви е помалку веројатно дека ке имаат подршка за BGP отколку направи кои што се преставени како рутери. Meѓутоа некои од високостандардни Layer 3 свичеви можат да имаат подршка за BGP.

Продукти кои што се претставени како свичеви може но и немора да имаат ограничувања на големината на BGP табелата, како што се 20,000 рутери, далеку помали од комплетна интернет табела заедно внатрешни рути. Како и да е овие направи можеби се најсоодветни за користење за BGP рутирање на помали делови од мрежата, како на пример confederation-AS што претставува една од повеќе помали компании кои се меѓусебно поврзани со BGP backbone-to-backbone, или пак помали компании кои испраќаат рути до ISP но можат да примат само една стандардна рута или пак помал број на групирани рути.

Доколку една имплементација на рутер зафаќа повеќе меморија по рута за разлика од друга имплементација, може да претставува легитимен избор на дизајн каде што се компензира процесирачката брзина со меморијата. Комплетна BGP табела како што е од Април, има вишок на 310,000 префикси. Поголемите ISP можат да додадат додатни 50% за внатрешна употреба или за рута кон своите корисници. Повторно во зависност од имплементацијата, може да се одржуваат посебни табели за секој поглед од врските на AS.

Бесплатни и Open Source имплементации на BGP

[уреди | уреди извор]
  • Bird Internet routing daemon, GPL рутирачки пакет наменет за Unix системите.
  • GNU Zebra, под GPL лиценца
  • OpenBGPD, BSD licence имплементација од OpenBSD тимот.
  • Quagga , наменето за Linux системи.
  • Vyatta, комерцијален open-source router/firewall/VPN - мрежен оперативен систем.
  • XORP, проширлива отворена платформа за рутери, заедно со рутирачки протоколи под GPL лиценца.
  • VNE, имплементација на софтверска библиотека на BGP под C#

BGP симулатори

[уреди | уреди извор]
  • BGPviz, Flash апликација која што претставува графичка визуелизација на BGP рути и ажурирања за било кој реален автономен систем на интернетот.
  • SSFnet, SSFnet мрежниот симулатор вклучува и BGP имплементација развиена од страна на BJ Premore
  • C-BGP, BGP симулатор кој што може да изврши голем број на симулации со цел да го моделира AS на интернетот.[10]
  • BGP++, додаток кој има интегрирано GNU Zebra софтвер на ns-2 и GTNetS мрежни симулатори.
  • ns-BGP, BGP екстензија за ns-2 симулатор заснован на SSFnet имплементација
  • NetViews, Јава апликација која што ги надгледува и прикажува BGP активностите во реално време.

Опрема за тестирање

[уреди | уреди извор]

Системи за тестирање на усогласеноста на BGP, како и за тестирање на издржливост на преоптоварување и притисок, од производители како што се:

Погледај

[уреди | уреди извор]

Грешка во Lua во package.lua, ред 80: module 'Module:Portal/images/c' not found

Референци

[уреди | уреди извор]
  1. ↑ Capabilities Advertisement with BGP-4, RFC 2842, R. Chandra & J. Scudder,May 2000
  2. ↑ Multiprotocol Extensions for BGP-4, RFC 2858, T. Bates et al.,June 2000
  3. ↑ BGP/MPLS VPNs., RFC 2547, E. Rosen and Y. Rekhter,April 2004
  4. ↑ IANA registry for BGP Extended Communities Types, IANA,2008
  5. ↑ BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP), RFC 4456, T. Bates et al., April 2006
  6. ↑ Autonomous System Confederations for BGP, RFC 5065, P. Traina et al., February 2001
  7. ↑ Border Gateway Protocol (BGP) Persistent Route Oscillation Condition, RFC 3345, D. McPherson et al., August 2002
  8. ↑ Terminology for Benchmarking BGP Device Convergence in the Control Plane, RFC 4098, H. Berkowitz et al., June 2005
  9. ↑ BGP Routing Table Analysis Reports
  10. ↑ Modeling the routing of an Autonomous System with C-BGP

За додатно читање

[уреди | уреди извор]

Надворешни линкови

[уреди | уреди извор]
Преземено од „https://mk.wikipedia.org/w/index.php?title=Корисник:Dragan_89&oldid=4437920“