Използвани практики по BGP префиксна филтрация и префиксно описание

Версия 1.1.0, 24 юли 2009

Веселин Колев, Софийски Университет "Св. Климент Охридски"

Адрес за кореспонденция: vesso AT vesselin.org

Първоизточник: http://www.vesselin.org

Лиценз на документа: CC Attribution-ShareAlike

 

Съдържание:

  1. Увод

  2. Основни понятия касаещи крайните потребители в зоната на RIPE NCC

  3. Добра обща практика по филтриране на BGP префикси

  4. Принципни проблеми с излъчване на префикси с тип origin "incomplete"

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

  6. Филтриране на BGP префикси, необявени като route/route6 обекти в RIPE DB

 

1. Увод

Към датата на написване на този материал, глобалната BGP таблица, описваща достижимите в IPv4 мрежови пространства, наброява около 280 000 префикса, а тази за IPv6 - около 2000. За момента е нормално таблицата, касаеща IPv6 мрежовите пространства да съдържа малък брой префикси, но големият обем на тази за IPv4 пространството е причина за задаване на въпроса наистина ли този обем е обоснован и може ли да бъде редуциран. Отговорът на този въпрос нито е лесен, нито еднозначен.

Най-често се приема, че тъй като IPv4 адресното пространство е много популярно и използвано, на раздаващите го регистри им се налага да извършват огромен брой сравнително малки адресни алокации за крайните потребители, а малки алокации за много крайни потребители, водят до голям брой BGP префикси. Да, подобен процес е със сигурност една причина за големия обем на глобалната BGP таблица, касаеща IPv4 адресното пространство, но тя със сигуртно не е единствената.

Истинският въпрос, който много рядко се задава, е какво се случва с адресните алокации за крайни потребители, след като те бъдат алокирани. Казано с други думи, дали крайният потребител създава оптимален брой префикси за алокацията си или те са неоправдано много. Регистрите, които извършват алокации могат да контролират в някаква степен сегментацията на майчиното пространството, което те парцелират за крайни потребители, но дали подобен самоконтрол налагат крайните потребители върху префиксното описание на своята алокация. Печалната истина, която може да се види при анализ на глобалната BGP таблица в IPv4 е, че неправилното префиксно описание, което крайните потребители извършват върху своите алокации, води до увеличаване на глобалната таблица с може би 40-50% (в най-лошия случай). Това неправилно описание се приема, в комуникацията по BGP сесии, от техните транзитни доставчици, които го препращат към своите транзити и така, докато тези лоши префикси не станат част от глобалната BGP таблица и не я увеличат напълно излишно. Излишното увеличаване на броя префикси води след себе си увеличаване на изчисленията, които маршрутизаторите извършват, използване на повече оперативна памет, по-голям разход на електроенергия, прави топологията в Интернет претрупана и излишно сложна и т.н.

Целта на тази публикация е запознае крайните потребители - оператори на автономни системи, със съществуващите практики за префиксна филтрация и намаляване на обема BGP префиксните описания, които те излъчват в глобалната BGP таблица (все едно дали това касае IPv4 или IPv6).

 

2. Основни понятия касаещи крайните потребители в зоната на RIPE NCC

В рамките на тази публикация под краен потребител ще разбираме организация, която управлява сама мрежовите си ресурси, в това число входящия и изходящ трафик към предоставените й адресни пространства, използвайки за тези си нужди автономна система и динамичен протокол за маршрутизация 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), ако вече не разполага такъв номер.

 

3. Добра обща практика по филтриране на BGP префикси

Целта на този раздел е да опише добрата обща практика по филтриране на BGP префикси.

 

4. Принципни проблеми с излъчване на префикси с тип origin "incomplete"

За съжалние, твърде често в глобалната 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 таблица.

 

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

В предния раздел е засегната темата за префиксното описание на адресните пространства, макар и в рамките на доста специфичната тема за origin типовете. Глобалната BGP таблица (за момента главно тази за IPv4) страда от прекомерно нарастване на включения в нея брой префикси, причина за което е недопустимата практика по префиксно описание на адресните пространства. Този раздел има за цел да опише не само недопустимата практика, но и останалите практики по префиксно описание на адресни пространства, алокирани за крайни потребители (без значение дали са LIR или не). Нужно е да се отчете, че показаното по-долу разделение на практиките на три типа е условно и е възможно в Интернет да бъдат намерени описания на друг набор практики. Направеното в този материал разделение на практиките, отчита преди всичко разбиранията за това в региона на управление на RIPE NCC.

 

6. Филтриране на BGP префикси, необявени като route/route6 обекти в RIPE DB

Тази филтрация засяга преди всичко транзитните доставчици, но е приложима и за случаите, в които крайни потребители договарят обмен на локален трафик между техните автономни системи, без това да включва транзит.

Ето класически пример за случая на транзит. Краен потребител с автономна система и собствено адресно пространство, който сам по себе си не е транзит, слючва договор с някой транзитен доставчик за интернет свързаност. За да се осъществи тя, между граничните маршрутизатори на крайния потребител и транзита да се изгражда 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:

 

Схема на префиксна филтрация на база информацията в RIPE DB

 

От резултата в примера се вижда и нещо друго. При такава схема на филтрация, ако крайният потребител не извърши коректно префиксно описание на своето адресно пространство, то ще се вижда само част от него, а ако няма route обекти, изцяло няма да се вижда. В горния пример потребителите в Интернет няма да виждат сегментите 10.0.4.0-10.3.255.255 и 10.6.0.0-10.255.255.255.

За момента такава практика може да се наложи изключително трудно, най-вече поради проблеми с квалификацията на персонала, отговарящ за управлението на BGP сесиите на транзитите и поради неосъзнаването на ползата от практиката от страна на всички доставчици в даден регион (напр. България). Освен това се иска едновременото й въвеждане от всички транзити в даден регион, което е трудно да се осъществи, поне на сегашния етап.

 

Този документ е с OpenPGP подписано съдържание
[информация] [електронен подпис] [TimeStamp: заявка|удостоверение]

Creative Commons - Признание 2.5 Valid CSS! Valid XHTML 1.1