Версия 1.1.0, 24 юли 2009
Веселин Колев, Софийски Университет "Св. Климент Охридски"
Адрес за кореспонденция: vesso AT vesselin.org
Първоизточник: http://www.vesselin.org
Лиценз на документа: CC Attribution-ShareAlike
Съдържание:
Основни понятия касаещи крайните потребители в зоната на RIPE NCC
Принципни проблеми с излъчване на префикси с тип origin "incomplete"
Добра, допустима и недопустима практика на префиксно описание на алокирани адресни пространства
Филтриране на BGP префикси, необявени като route/route6 обекти в RIPE DB
Към датата на написване на този материал, глобалната BGP таблица, описваща достижимите в IPv4 мрежови пространства, наброява около 280 000 префикса, а тази за IPv6 - около 2000. За момента е нормално таблицата, касаеща IPv6 мрежовите пространства да съдържа малък брой префикси, но големият обем на тази за IPv4 пространството е причина за задаване на въпроса наистина ли този обем е обоснован и може ли да бъде редуциран. Отговорът на този въпрос нито е лесен, нито еднозначен.
Най-често се приема, че тъй като IPv4 адресното пространство е много популярно и използвано, на раздаващите го регистри им се налага да извършват огромен брой сравнително малки адресни алокации за крайните потребители, а малки алокации за много крайни потребители, водят до голям брой BGP префикси. Да, подобен процес е със сигурност една причина за големия обем на глобалната BGP таблица, касаеща IPv4 адресното пространство, но тя със сигуртно не е единствената.
Истинският въпрос, който много рядко се задава, е какво се случва с адресните алокации за крайни потребители, след като те бъдат алокирани. Казано с други думи, дали крайният потребител създава оптимален брой префикси за алокацията си или те са неоправдано много. Регистрите, които извършват алокации могат да контролират в някаква степен сегментацията на майчиното пространството, което те парцелират за крайни потребители, но дали подобен самоконтрол налагат крайните потребители върху префиксното описание на своята алокация. Печалната истина, която може да се види при анализ на глобалната BGP таблица в IPv4 е, че неправилното префиксно описание, което крайните потребители извършват върху своите алокации, води до увеличаване на глобалната таблица с може би 40-50% (в най-лошия случай). Това неправилно описание се приема, в комуникацията по BGP сесии, от техните транзитни доставчици, които го препращат към своите транзити и така, докато тези лоши префикси не станат част от глобалната BGP таблица и не я увеличат напълно излишно. Излишното увеличаване на броя префикси води след себе си увеличаване на изчисленията, които маршрутизаторите извършват, използване на повече оперативна памет, по-голям разход на електроенергия, прави топологията в Интернет претрупана и излишно сложна и т.н.
Целта на тази публикация е запознае крайните потребители - оператори на автономни системи, със съществуващите практики за префиксна филтрация и намаляване на обема BGP префиксните описания, които те излъчват в глобалната BGP таблица (все едно дали това касае IPv4 или IPv6).
В рамките на тази публикация под краен потребител ще разбираме организация, която управлява сама мрежовите си ресурси, в това число входящия и изходящ трафик към предоставените й адресни пространства, използвайки за тези си нужди автономна система и динамичен протокол за маршрутизация BGP4 (а когато става дума за IPv6 - BGP4+). По-долу в този раздел са обяснени някои термини и понятия за улесняване на техническото изложение в следващите раздели.
Българските крайни потребители на адресни ресурси, получават номера на автономни системи и адресни алокации от регионалния регистър за Европа, Близкия и Среден Изток и част от Африка - RIPE NCC (http://ripe.net). Тази организация получава големи "парчета" адреси и номера на автономни системи от "главния" оператор на адресното пространство (IPv4 и IPv6) - IANA (http://iana.org). Нейната главна цел е да организира рационално и обосновано раздаването на получените от IANA ресурси на крайните потребители в географския район, в който оперира. RIPE разглежда крайните потребители в две категории: (i) LIR или "Локален Интернет Регистър" и (ii) "End User" или "краен потребител". Оттук и надолу в изложението ще приемаме, че краен потребител е този, който не е LIR. Разликата между категориите "LIR" и "краен потребител", най-общо казано, се състои в това, че LIR има директни отношения с RIPE (получава големи адресни алокации и блок с номера на автономни системи директно от RIPE, в количество, което му позволява ранга, определящ се от членска такса, има право на участие във взимане на отговорни решения и др.), а "крайният потребител" може да заявява малко количество независими ресурси от RIPE. Докато LIR овъзмездява директно RIPE за получените операторски права върху ресурси, то крайният потребител овъзмездява LIR организацията, която е служила като посредник за получаването на независим ресурс. В региона, в който RIPE NCC има оперативни функции, организацията на мрежовите субекти е такава, че всеки по-голям доставчик е LIR. Цялата оперативна база, описваща ресурсните алокации, заявителите им и др., се нарича "RIPE Database" (съкратено RIPE DB) и е публично достъпна за прочит чрез whois услуга.
Когато LIR или краен потребител получи адресна алокация от RIPE NCC, тя се описва в RIPE DB като обект от типа inetnum (за IPv4) или inet6num (за IPv6). Този обект има различни полета, но разликата между inetnum/inet6num за LIR и краен потребител е в стойността на полето status. В случай, че обектът отразява алокация за LIR, стойността на полето status е ASSIGNED PA, а когато алокацията е за краен потребител, стойността е ASSIGNED PI (възможни са и други стойности, които тук няма да се описват, виж документацията на RIPE).
След като организацията получи адресното пространство, за което има inetnum обект, тя трябва да обособи за последния един или повече route (за IPv4) или route6 (за IPv6) обекти в RIPE DB. Тези обекти описват мрежовото адресно пространство и маршрутите към него чрез BGP префикси. За да се създаде обаче route/route6 обект в RIPE DB, следва да се укаже номера на автономната система, която ще е първоизточник (origin) на префикса в глобалната BGP таблица. Обикновено това е номера на автономната система на организацията, получила адресното пространство и следователно освен адресно пространство, тя следва да заяви и номер на автономна система, който също да получи от RIPE (все едно дали директно или чрез LIR), ако вече не разполага такъв номер.
Целта на този раздел е да опише добрата обща практика по филтриране на BGP префикси.
Филтриране на префикси за частни и други адресни пространства в IPv4, които не бива да се маршрутизират глобално
Забележка: Крайните потребители трябва да филтрират всички споменати по-долу BGP префикси, освен ако за някои от тях нямат нарочна договорка със съседна автономна система. В случай, че такава договорка няма, транзитните доставчици, LIR или крайни потребители с автономна система, следва да филтрират от и към своите съседи всички BGP префикси представящи мрежови адресни пространства описани по-долу.
При излъчването на BGP префикси, които трябва да станат част от глобалната BGP таблица, трябва да се следва следната практика за максимална дължина на префикс:
/24 - за IPv4;
/48 - за IPv6.
Когато две или повече организации искат да договорят помежду си BGP обмен на префикси с по-големи дължини на мрежовите маски от посочените (най-често за специфични нужди), те трябва да организират специално BGP Community, което да се занимава с уреждане на разпространението на такива префикси между граничните им маршрутизатори. Ако такова BGP Community не е договорено или няма друг тип договорка за такива особени префикси, те следва да се филтрират в рамките на BGP сесиите.
Много често възникват спорове, защо точно BGP префикси с дължина на мрежовата маска над посочените горе, трябва да се филтрират? Първо, в IPv4 е установена практиката, че адресният регистър може да извърши еднократна алокация на мрежово адресно пространство за краен потребител, чиито префикс да е с максимална дължина на мрежовата маска 24 бита (за пример виж 192.175.48.0/24 с origin AS112, алокиран от ARIN). При това такава малка алокация се извършва изключително рядко (все още) и то само за специални цели, напр. anycast или експерименти. Следователно няма как да има оправдание за обособяване на префикси за IPv4 мрежи с дължина на мрежовата маска по-голяма от 24 бита. Второ, в IPv6 е възприето, че най-малкият алокируем мрежови ресурс за краен потребител ще бъде с дължина на мрежовата маска 48 бита (/48) и няма изгледи това да бъде променено в обозримо бъдеще.
Съгласно RFC1918, следните префикси и всички техни специфични субпрефикси отразяват частни адресни пространства в IPv4 подлежат на префиксна филтрация:
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
Към тях следва да се добави и 169.254.0.0/16 (виж RFC3330), който описва адресно пространство за автоконфигурация в IPv4, както и 192.0.2.0/24 (example.com/example.net). Тези пет префикса или техни субпрефикси не бива да се излъчват или приемат в рамките на BGP сесии, освен ако няма специална договорка между, но дори и при наличие на такава, излъчването следва да бъде строго ограничено, а не глобално.
Не е добра практика в BGP сесии между гранични маршрутизатори на автономни системи, да се излъчва маршрута по подразбиране (маршрут към 0.0.0.0/0). Най-малкото това означава дадена автономна система да се обяви за origin на цялото IPv4 адресно пространство. Следователно маршрута към 0.0.0.0/0 в повечето случаи трябва да се отхвърля, защото той не дава вярна информация.
Към отхвърлените маршрути следва да се добавят и тези за 0.0.0.0/8 и 127.0.0.0/8, а така също и за мултикастните сегменти в IPv4. Последните понякога са обект на маршрутизация но не и в unicast (за подробности виж RFC2858).
Ето примерни елементи за извършване на филтрация на BGP префикси, които касаят споменатите адресни пространства (конфигурационните елементи са специфични за Quagga, използваеми са и в IOS):
... ! ip prefix-list REJECTED_IPV4_PREFIXES seq 5 permit 0.0.0.0/0 ip prefix-list REJECTED_IPV4_PREFIXES seq 10 permit 0.0.0.0/0 ge 25 ip prefix-list REJECTED_IPV4_PREFIXES seq 15 permit 0.0.0.0/8 le 32 ip prefix-list REJECTED_IPV4_PREFIXES seq 20 permit 127.0.0.0/8 le 32 ip prefix-list REJECTED_IPV4_PREFIXES seq 25 permit 10.0.0.0/8 le 32 ip prefix-list REJECTED_IPV4_PREFIXES seq 30 permit 172.16.0.0/12 le 32 ip prefix-list REJECTED_IPV4_PREFIXES seq 35 permit 192.168.0.0/16 le 32 ip prefix-list REJECTED_IPV4_PREFIXES seq 40 permit 192.0.2.0/24 le 32 ip prefix-list REJECTED_IPV4_PREFIXES seq 45 permit 169.254.0.0/16 le 32 ip prefix-list REJECTED_IPV4_PREFIXES seq 50 permit 224.0.0.0/3 le 32 ! ...
След декларирането му, този prefix-list елемент може да се извиква в друг елемент по-нагоре в йерархията на конфигурацията, например route-map (конфигурационните елементи са специфични за Quagga, използваеми са и в IOS):
... ! route-map SOME_BORDER_IMPORT_IPV4 deny 10 match ip address prefix-list REJECTED_IPV4_PREFIXES ! ...
Филтриране на префикси с origin автономни системи за частно ползване
Забележка: Крайните потребители трябва да филтрират всички BGP префикси с orign номер на автономна система за частно ползване, освен ако за някои от тях нямат нарочна договорка (примерно извършване на експеримент) със съседна автономна система. Транзитните доставчици следва да филтрират от и към своите съседи всички BGP префикси с origin частни автономни системи.
Блокът с номера на автномни системи за частно ползване, 64512-65534, е описан от IANA в номерационния план на пространството на автономните системи. Филтрирането на BGP префиксите с origin частна автономна система може да стане чрез следния примерен конфигурационен код (конфигурационните елементи са специфични за Quagga, използваеми са и в IOS):
... ! ip as-path access-list PRIVATE_AS permit _(6451[2-9]|645[2-9][0-9]|64[6-9][0-9][0-9]|65[0-4][0-9][0- 9]|655[0-2][0-9]|6553[0-5])$ ! ...
който може да бъде включен в по-горен елемент от йерархията на конфигурацията, напрмер route-map:
... ! route-map SOME_BORDER_IMPORT_IPV4 deny 20 match as-path PRIVATE_AS ! ... ! route-map SOME_BORDER_IMPORT_IPV6 deny 20 match as-path PRIVATE_AS ! ...
С цел пълнота, трябва да се спомене, че IANA е специфицирала блок номера на автономни системи, 64496-64511 (за подробности виж RFC5398), който да се употребява за примери в документация. Би следвало и тези номера на автономни системи да не се използват за origin на никой BGP префикс в глобалната BGP таблица и да се направи превантивна филтрация, която би изглждала така (отново в термини на конфигурация на Quagga, приложими и към IOS):
... ! ip as-path access-list PRIVATE_AS permit _(6449[6-9]|64[5-9][0-9][0-9]|65[0-4][0-9][0-9]|655[0-2][0-9]|6553[0-5])$ ! ...
Доколкото блокът 64496-64511 е съседен на този за частно ползване - 64512-65534, то сумарно двата блока могат да се обединят в един голям блок 64496-65534 и именно това обстоятелство е отразено в представения току що елемент за филтрация.
Нужно е да се отбележи, че горната филтрация не засяга случаите, в които частната автономна система е транзитна за даден префикс. Това трябва да е така, защото ако се изгради филтър и за транзитите в AS пътя на префикса, всяка грешка на транзит в Интернет, при която той е обявил грешно своята автономна система за частна, ще води до загуба на направления, които имат коректен BGP origin, който не е частна автономна система.
В случай, че маршрутизатора, върху който се изгражда конфигурацията за филтрация на частни автономни системи, има поддръжка на 32-битови ASN (а това все повече става дефакто задължително), списъкът с номера на автономни системи, които следва да не бъдат origin на нито един префикс в глобалната BGP таблица (все едно IPv4 или IPv6), следва да се удължи. Удължаването става чрез прибавяне на блока от номера 65536 - 65551 (виж RFC5398):
... ! ip as-path access-list PRIVATE_AS permit _(6449[6-9]|64[5-9][0-9][0-9]|65[0-4][0-9][0-9]|655[0-4][0-9]|655[0-4][0-9]|6555[0-1])$ ! ...
За съжалние, твърде често в глобалната BGP таблица се срещат префикси, чиито origin е незавършен/непълен ("incomplete"). Най-честата причина, за наличието на такива префикси, е редистрибутирането им в BGP от друг протокол за маршрутизация, което е извършено в автономната им система първоизточник. Погледнато от гледна точка на глобалната маршрутизация, първоизточникът на префикса с origin "incomplete" не е ясен за протокола BGP, защото няма пълнотата на определяне, характерна за този протокол. Добрата практика изисква всички префикси в BGP таблиците да имат origin тип "igp" или "egp" (последният тип няма да бъде дискутиран тук, само трябва да се спомене, че той е характерен за стар софтуер за маршрутизация). IGP всъщност е идентификатор, който указва, че BGP префикса е научен от някой от протоколите, които се използват между маршрутизаторите вътре в автономната система (оттам IGP - Interior Gateway Protocols) за формирането на т.нар. "вътрешен меш", макар формирането на такъв да не е строго задължително. Пример за IGP протоколи са OSPF, IS-IS и RIP. Като такъв обаче може да се използва и BGP - iBGP. Когато един BGP префикс се пропагандира към маршрутизатори на транзитна автономна система (това е механизма за изграждане на глобалната BGP таблица), няма как IGP протоколи като посочените, освен iBGP, да се обявяват директно за първоизточници на префикси. Ако въпреки това маршрутизатор на една автономна система се опита да излъчи префикси към маршрутизатори на други автономни системи, направо взимайки информацията от различни от iBGP протоколи, тези префикси се получават върху споменатите маршрутизатори с origin тип "incomplete".
Ето пример как чрез Quagga да бъдат изведени префиксите от глобалната BGP таблица, които са с "origin incomplete" и са с първоизточник AS8866:
$ vtysh -c "sh ip bgp regexp _(8866)$" | grep "8866 ?"
Нужно е да се каже ясно, че префиксите с "origin incomplete" не бива да се филтрират! Те не са вредни за глобалната маршрутизация, но най-често представят следването на недобра практика от страна на първоизточника им. В какво се състои най-често тази практика и какво я причинява? Да предположим, че краен потребител е получил от регионалния си интернет регистър IPv4 адресния сегмент 1192.168.0.0-192.168.3.255. За нуждите на вътрешната маршрутизация в рамките на автономната си система, той неизбежно ще раздели този адресен сегмент на подсегменти и ще ги опише с префикси. Закономерно, последните ще станат част от т.нар. вътрешен меш, който ще се изгради на базата на някой IGP протокол. Ето едно примерно разделяне, което може да бъде реализирано за нуждите на вътрешната маршрутизация:
192.168.0.0/22 192.168.0.0/24 192.168.1.0/24 192.168.2.0/24 192.168.3.0/24
Тези префикси се пропагандират вътре в автономната система най-често с OSPF, по-рядко с BGP или IS-IS и най-рядко с RIP. Проблемът се появява тогава, когато граничният маршрутизатор на автономната система трябва да излъчи префикса 192.168.0.0/22 в BGP сесиите към транзитните доставчици (или към партньори за локален обмен на трафик). Обикновено се допускат две принципни грешки. Първата се състои в следното. Незнайно защо, операторите на автономната система, правят такива конфигурации на BGP софтуера си, че излъчват (редистрибутират) целия меш, формиран за вътрешни нужни, към транзитните автономни системи. Обикновено той се състои от силно специфични префикси, излъчването на които в глобалната BGP таблица не носи никаква полза, а напротив - увеличава я ненужно. Втората грешка най-често следва първата и се изразява в това, че ако вътрешният меш е формиран чрез протокол различен от iBGP, при излъчването на префиксите в BGP сесиите към транзитните автономни системи, не се извършва подмяна на типа на origin и той автоматично се указва като "incomplete". Всъщност именно втората грешка е източника на префикси с "origin incomplete" в глобалната BGP таблица. Ето онагледяване на двата вида грешки с пример от конфигурация на BGP софтуер, за случая на формиране на вътрешния за автономната система меш чрез протокола OSPF и последващото му редистрибутиране в BGP (примерната конфигурация е за Quagga, но може да се адаптира и за IOS):
... ! router bgp 64496 redistribute ospf route-map OSPF_EXPORTS_IPV4 ... ! access-list OSPF_EXPORTS_IPV4 permit 192.168.0.0/22 ! route-map OSPF_EXPORTS_IPV4 permit 10 match ip address OSPF_EXPORTS_IPV4 ! route-map OSPF_EXPORTS_IPV4 deny 1000 ! ...
Първата грешка се поражда от слабо специфичния селектор на префикси в деклрарирания access-list, който позволява да се обработват силно специфични префикси, идващи от OSPF. В рамките на тази обработка влизат всички специфични субпрекфикси на 192.168.0.0/22. Втората грешка произтича от това, че никъде няма конфигурационен елемент, който да смени origin типа. За да се поправи първия тип грешка, може да се увеличи специфичността на access-list декларацията:
... ! access-list OSPF_EXPORTS_IPV4 permit 192.168.0.0/22 exact-match ! ...
но тази поправка би действала само и единствено, ако в меша за вътрешни нужди присъства в точен вид префикса 192.168.0.0/22 - само той ще премине през селекцията. Но ако в редистрибутирания меш не се излъчва префикса 192.168.0.0/22, а се излъчват само негови субпрефикси, няма да се извърши селекция и няма да има редистрибутиране в BGP. Един много чист начин за избягване на първата грешка (но не винаги приложим) е декларирането на префикса като собствен за BGP конфигурацията:
... ! router bgp 64496 network 192.168.0.0/22 ... ! ...
което предотвратява и втория тип грешки за този този префикс, ако няма редистрибутиране на субпрефикси от OSPF меша. Споменатият начин не е приложим винаги и понякога може да не отговаря на добрата практика. Причината е, че операторът на автономната система може да изисква даден префикс да не се излъчва в BGP, ако първоизточника вътре в автономната система не функционира по някаква причина. А подобно ниво на автоматизация може да се получи само при редистрибутиране на вътрешния меш. Докато ако се следва предложената по-горе поправка в конфигурацията на BGP софтуера на граничния маршрутизатор, префиксът ще се излъчва винаги към транзитите, без оглед на това функционира или не първоизточника на префикса вътре в автономната система. Това може да породи паразитен трафик или да създаде други усложнения.
Отделно, само втората грешка може да се премахне, ако всички редистрибутирани в BGP префикси се обработят така, че origin типа им да бъде твърдо зададен като "igp". Ето примерна конфигурация, която прави това:
... ! router bgp 64496 redistribute ospf route-map OSPF_EXPORTS_IPV4 ... ! access-list OSPF_EXPORTS_IPV4 permit 192.168.0.0/22 exact-match ! route-map OSPF_EXPORTS_IPV4 permit 10 match ip address OSPF_EXPORTS_IPV4 set origin igp ! route-map OSPF_EXPORTS_IPV4 deny 1000 ! ...
В заключение по темата трябва да се каже, че добрата практика изисква избягването на излъчване на префикси с origin тип "incomplete" в глобалната BGP таблица.
В предния раздел е засегната темата за префиксното описание на адресните пространства, макар и в рамките на доста специфичната тема за origin типовете. Глобалната BGP таблица (за момента главно тази за IPv4) страда от прекомерно нарастване на включения в нея брой префикси, причина за което е недопустимата практика по префиксно описание на адресните пространства. Този раздел има за цел да опише не само недопустимата практика, но и останалите практики по префиксно описание на адресни пространства, алокирани за крайни потребители (без значение дали са LIR или не). Нужно е да се отчете, че показаното по-долу разделение на практиките на три типа е условно и е възможно в Интернет да бъдат намерени описания на друг набор практики. Направеното в този материал разделение на практиките, отчита преди всичко разбиранията за това в региона на управление на RIPE NCC.
Добра практика:
Добрата практика по префиксно описание на адресното пространство, алокирано за краен потребител от RIPE, изисква използването за целта на минимален брой BGP префикси. Обикновено за минимален брой префикси се счита един префикс, който се описва в RIPE DB като един route/route6 обект. Този префикс следва да се излъчва и към (най-малко) двата транзита на автономната система на потребителя. Следването на тази добра практика често се натъква на чисто практически проблеми, които са описани при допустимата практика в следващия абзац.
Допустима практика:
Допустимата практика по префиксно описание на адресното пространство, алокирано за краен потребител от RIPE, използва аргументирано два или повече брой BGP префикси. Какво следва да се разбира под аргументирано префиксно описание? Най-честият случай за извършване на такова е наличието на поне два канала за свързаност на адресното пространство към Интернет, като следва да се използват и двата канала, но единият да се използва с предимство от една част от адресите, а другия от друга част. Очевидно е, че в този случай следва към транзитите по двата канала да се излъчват различни като специфичност префикси. Ето и пример. Краен потребител с автономна система е получил от регионалния си регистър адресния сегмент 192.168.0.0-192.168.3.255. Потребителят има два транзитни доставчика, но изисква да използва приоритетно първия за входящия трафик за сегмента 192.168.2.0-192.168.3.255, а вторият приоритетно за останалия сегмент (192.168.0.0-192.168.1.255). Това, което трябва да се направи е да се обособят префиксите 192.168.0.0/22 и 192.168.2.0/23, и да се опишат като route обекти в RIPE DB. След това 192.168.0.0/22 и 192.168.2.0/23 трябва да се излъчат по BGP сесията към първия транзит, като за префикса 192.168.0.0/22 извърши т.нар. "prepend", колкото пъти е нужно. Към втория транзит се излъчва само префикса 192.168.0.0/22. По този начин специфичният префикс ще насочва входящия трафик за 192.168.2.0-192.168.3.255 само през първия канал, а трафика за всички останали приоритетно ще се получава през втория транзит. Ако някой от транзитите отпадне временно, то другия осигурява входящия канал към цялото адресно пространство.
Недопустима практика:
Недопустимата пректика се състои в описанието на адресното пространство, алокирано за краен потребител, чрез огромен брой префикси, които не носят никаква функционалност при маршрутизацията и единствено увеличават ненужно глобалната BGP таблица. Тази практика е всъщност основният виновник за толкова голямата глобална BGP таблица за адресния протокол IPv4 и може да направи същото с таблицата за IPv6 в бъдеще.
Тази филтрация засяга преди всичко транзитните доставчици, но е приложима и за случаите, в които крайни потребители договарят обмен на локален трафик между техните автономни системи, без това да включва транзит.
Ето класически пример за случая на транзит. Краен потребител с автономна система и собствено адресно пространство, който сам по себе си не е транзит, слючва договор с някой транзитен доставчик за интернет свързаност. За да се осъществи тя, между граничните маршрутизатори на крайния потребител и транзита да се изгражда BGP сесия (най-малко една, възможно е и повече в зависимост от конкретната ситуация) с конкретни параметри. Транзитът носи отговорност за нарастване на глобалната BGP таблица и би следвало да направи така, че да приема от своите крайни потребител и реизлъчва към останалите субекти в Интернет, само оптимален набор префикси, касаещи алокираното за клиента пространство (inetnum или inet6num). Обикновено това са тези префикси, които крайният потребител е описал като route/route6 обекти в RIPE DB. По този начин транзитът може да изгради префиксен BGP филтър, който да приема от граничните маршрутизатори на крайния потребител само тези префикси, които са регистрирани в RIPE DB с origin автономната система на потребителя.
На пръв поглед това изглежда доста трудна задача, защото за всеки нов префикс, за който крайния потребител е направил route/route6 обект, трябва да се предоговаря и съответно преправя BGP префиксния филтър при транзита. Този процес обаче може да се автоматизира чрез периодични запитвания към RIPE DB и автоматичното създаване на префиксни филтри за крайния потребител. За тази цел Internet Systems Consortium (ISC) поддържа пакета инструменти IRRToolSet. За да може да бъде използваем широко в Интернет, този пакет инструменти е реализиран под подходящ свободен лиценз, позволяващ изтегляне, компилиране, модифициране, разпространение и комерсиално използване. Конкретната задача за автоматично създаване на филтри на базата на route/route6 обекти, се решава с инструмента RtConfig и покрива основния използван софтуер за маршрутизация.
Нужно е да се спомене, че подобна форма на филтрация може силно да снижи обема на глобалната BGP таблица, но за да ефективна, би следвало всички транзити на даден краен потребител да я прилагат. Ако дори един от тях пропуска префиксите на крайния потребител без филтрация, то няма никакъв смисъл от филтрацията, която правят останалите, защото почти сигурно ще има излъчване на специфични префикси. Нещо повече, в този случай тези транзити, които съзнателно изпълняват ролята си на редуктори на обема на глобалната BGP таблица, ще генерират транзитен трафик през своите транзити, за да достъпват мрежови адресни пространства на свой краен потребител, което противоречи на всякаква логика на маршрутизацията.
Ето един илюстративен пример. Краен потребител с автономна система номер 64450 оперира с адресните пространства 10.0.0.0-10.255.255.255, за което в RIPE DB е съставил префиксното описание:
10.0.0.0/22 10.4.0.0/24 10.5.0.0/24
Предполага се, че крайният потребител няма големи познания относно BGP и маршрутизация и затова и описанието на route обектите не обхваща цялото пространство, с което оперира. Пак поради липсата на познания, той излъчва без филтрация свой вътрешен меш към транзита си - AS64451. Този меш се състои от следния набор префикси:
10.0.0.0/22 10.0.0.0/24 10.4.0.0/24 10.6.0.0/24
На изображението по-долу е представен случай на префиксна филтрация, съобразена с информацията в RIPE DB и извършена от транзита AS64451:
От резултата в примера се вижда и нещо друго. При такава схема на филтрация, ако крайният потребител не извърши коректно префиксно описание на своето адресно пространство, то ще се вижда само част от него, а ако няма route обекти, изцяло няма да се вижда. В горния пример потребителите в Интернет няма да виждат сегментите 10.0.4.0-10.3.255.255 и 10.6.0.0-10.255.255.255.
За момента такава практика може да се наложи изключително трудно, най-вече поради проблеми с квалификацията на персонала, отговарящ за управлението на BGP сесиите на транзитите и поради неосъзнаването на ползата от практиката от страна на всички доставчици в даден регион (напр. България). Освен това се иска едновременото й въвеждане от всички транзити в даден регион, което е трудно да се осъществи, поне на сегашния етап.
Този документ е с OpenPGP подписано съдържание
[информация] [електронен подпис] [TimeStamp: заявка|удостоверение]
