Border Gateway Protocol

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

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. Транспортно ниво (Transport layer)

UDP • TCP • DCCP • SCTP • RSVP • ECN

3. Мрежно ниво (Network layer)

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

2. Податочно ниво (Data Link Layer)

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

1. Физичко ниво (Physical layer)

Етернет • 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 пораки за одредиштате за коишто нудат можност за поврзување. Во протоколот, основниот опис за CIDR рутата се нарекува Network Layer Reachability Information (NLRI). NLRI ги вклучува претставките на очекуваните одредишта, должината на претставките, патеката на автономните системи до соодветното одредиште и атрибутите на наредниот hop, коишто можат да носат широк спектар на додатни информации коишто влијаат на политиката на прифаќање на насочувачот којшто е примач. BGP емитерите постојано најавуваат нови NLRI коишто нудат поврзување, но исто така и најавуваат и повлекувања на претставки за коишто емитерите не нудат повеќе можност за поврзување.

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

Во наједноставен случај сите насочувачи со единствен 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 Архивирано на 11 јануари 2011 г., Flash апликација која што претставува графичка визуелизација на BGP рути и ажурирања за било кој реален автономен систем на интернетот.
  • SSFnet Архивирано на 22 март 2009 г., SSFnet мрежниот симулатор вклучува и BGP имплементација развиена од страна на BJ Premore
  • C-BGP, BGP симулатор којшто може да изврши голем број на симулации со цел да го моделира AS на интернетот.[10]
  • BGP++, додаток кој има интегрирано GNU Zebra софтвер на ns-2 и GTNetS мрежни симулатори.
  • ns-BGP, BGP екстензија за ns-2 симулатор заснован на SSFnet имплементација
  • NetViews, Јава апликација која што ги надгледува и прикажува BGP активностите во реално време.

Опрема за тестирање[уреди | уреди извор]

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

Погледај[уреди | уреди извор]

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

  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“ (PDF). Архивирано од изворникот (PDF) на 2008-09-11. Посетено на 2011-01-10.

За додатно читање[уреди | уреди извор]

Надворешни врски[уреди | уреди извор]

Нормативна контрола
Преземено од „https://mk.wikipedia.org/w/index.php?title=Border_Gateway_Protocol&oldid=5143109“