[phpBB Debug] PHP Notice: in file /viewtopic.php on line 945: date(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Europe/Helsinki' for 'EEST/3.0/DST' instead
[phpBB Debug] PHP Notice: in file /viewtopic.php on line 945: getdate(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Europe/Helsinki' for 'EEST/3.0/DST' instead
BREN forums • View topic - 32-bit/4-byte ASN

32-bit/4-byte ASN

IP маршрутизация, протоколи (BGP, OSPF и т.н.), регистри (IANA, RIPE и т.н.)

32-bit/4-byte ASN

Postby vesso » 18 Feb 2009, 11:01

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

Темата е отворена за дискусии с всички PI и PA оператори, които по дефиниция имат назначен от регионалния RIR (RIPE NCC) номер на автономна система.

Какво представляват 32-битовите номера на автономни системи (32-bit ASN) и защо е наложително използването им? Към момента основно се използва старото адресно пространство за номера на автономни системи, което има размер 2^12 бита. Това означава, че в него са използваеми 65536. Реално използваният им брой е по-малък. Разпределението на номерационния план на 16-битовите AS може да се види на страницата на органа за номерационен ресурсен контрол IANA:

http://iana.org/assignments/as-numbers/

Също на този адрес е показано и моментното състояние на блока от 32-битови AS. Видимо е, че 16-битовите номера на AS са пред изчерпване и е нужно да се намери спешно решение на проблема с недостига им. Това решение е използването на 32-битови номера на автономни системи. Адресното пространство в този случай е 2^32 или в него има 4294967296 свободни ASN. Реалният им брой е по-малък, защото от този блок 1023 номера са резервирани за локални или частни цели, а 3 са предназначени за специални цели. Следователно общият брой алокируеми за публична употреба номера на 32-битови ASN е 4294966271 .

Текуща статистика за използваемостта на 32-битовите ASN може да бъде намерена тук:

http://www.potaroo.net/tools/asn32/

Българските оператори на свързаност и крайните потребители, използват номерационни ресурси (IP адреси, ASN), раздавани от регионалния IP регисър за Европа - RIPE NCC. Съгласно политиката на този регистър за алокиране на номера на AS, в момента по подразбиране следва всеки заявител на такава, да получава номера от 32-битовия номерационен план. Самата форма за заявка се намира на адрес:

http://www.ripe.net/ripe/docs/asnsupport.html

Както се вижда от нея, алокирането на 16-битов номер на AS е допустима опция, която трябва да се обоснове. По подразбиране обаче винаги се назначава 32-битов ASN. Това означава, че рано или късно в Интернет следва да стане масово използването на 32-битови номера на AS и ние трябва да сме готови за това.

Целта на тази дискусия е да запознае мрежовите администратори и по-специално тези, които са и оператори на автономни системи, с процедурите за анонсиране и транзит на префикси с "origin" или транзит 32-битов ASN. Дискусията следва да е отворена и за мрежови администратори и оператори на AS, който са извън академичната общност в България, но които желаят да споделят опит или да получат такъв от дискусиите тук.
Last edited by vesso on 23 Feb 2009, 14:37, edited 2 times in total.
vesso
 
Posts: 65
Joined: 17 Feb 2009, 21:09
Location: Sofia

32-bit AS numbers

Postby vesso » 18 Feb 2009, 13:54

Здравейте колеги,

Бих искал да привлека вниманието ви върху нещо, което вече ни касае
доста пряко и особено тези от нас, които са мрежови оператори на
университети - оператори на автономни системи. Съгласно досегашната
практика, числовите идентификатори на автономните системи бяха
16-битови. Т.е. цялото числово пространство на автономните системи,
използваеми като "origin" в глобалната система за маршрутизация,
теоретично е от 0 до 65535. Числовите идентификатори на автономни
системи са глобален номерационен ресурс и се разпределят от IANA на
големи блокове по заявка на съответния RIR (RIR за територията на
България е RIPE: http://ripe.net). Разпределението на този ресурс от
страна на IANA до момента, можете да видите тук:

http://iana.org/assignments/as-numbers/

Както става ясно, поради големия брой PI оператори, адресното
пространство на 16-битовите автономни системи застрашително се запълва.
За да може да не се получи изчерпване на номерационния ресурс за
автономни системи, се преминава към ново пространство на числовите
идентификатори, което е 32-битово. В него всеки номер на автономна
система се записва като йерархична подредба на две шестнадесетични
числа. За повече информация, можете да погледнете Wiki страницата на
APNIC, посветена на 32-битовите AS номера (ASN):

http://wiki.icons.apnic.net/display/ASN/Home

Реализацията на 32-битовите ASN в BGP е обект на RFC4893:

http://www.ietf.org/rfc/rfc4893.txt


От януари 2009 година RIR RIPE има нова форма за заявка (ripe-445) на
автономна система:

http://www.ripe.net/ripe/docs/asnsupport.html

Най-важното в нея е, че вече по подразбиране се изисква да заявите 32
битов идентификатор на автономната система, над която желаете да
получите операторски права. Ако все още изисквате да получите 16-битов
номер на AS, трябва да напишете обяснение защо. Т.е. сериозно се гледа
на внедряването на 32-битовите ASN. Следователно те вече се употребяват
и трябва да започнем ако не да заявяваме такива, то поне да приемаме
префикси с подобен първоизточник.

Около маршрутизиращия софтуер нещата стоят така. JunOS поддържа много
добре 32-битови ASN. Cisco, въпреки съавторството на RFC4893 поддържат
частично тези идентификатори, само в някои версии на IOS и само за някои
от сериите маршрутизатори (по-вероятно е да нямате такава поддръжка).
Quagga по подразбиране няма поддръжка на 32-битови ASN, но има много
добра кръпка, която работи перфектно за версия 0.99.9. Кръпките са тук:

http://quagga.ncc.eurodata.de/

а ако някой желае, можем да отворим хранилището за направени от нас RPM
пакети за quagga 0.99.9 за EL4/EL5. Xorp поддържа 32-битови ASN. Само да
спомена, че преди малко повече от месец излезе 1.6.0 версията на Xorp.
Интересното в Xorp е, че третира всички номера на AS като 32 битови
(реално погледнато 16-битовите ASN са подмножество на 32-битовите). Може
би до април в СУ ще мигрираме към Xorp, ако имаме време да обучим
младите колеги на него.


Доколкото участниците в Академичната мрежа, опериращи своя AS, получават
пълната таблица от POP-а на GEANT2 в София, имам следния въпрос е към
колеките от ИПОИ-БАН. Обработват ли вашите гранични маршрутизатори
префикси с първоизточници 32-битови ASN? Дори да не сте направили
подобна настройка, ако сте си актуализирали JunOS би следвало да имате
тази поддържка, макар и неактивирана. Ако вие извършвате или ще
извършвате обработка на префикси с 32-битови ASN, бихме желали да знаем
това, за да започнем използване на съответния за цялта маршрутизиращ
софтуер върху граничните маршрутизатори на AS5421. Със сигурност и
колеги от другите университете, които оперират със своя AS, биха се
заинтересували от това.

Поздрави
Веселин
vesso
 
Posts: 65
Joined: 17 Feb 2009, 21:09
Location: Sofia

Re: 32-bit AS numbers

Postby vedrin » 18 Feb 2009, 13:55

Здравейте,

В допълнение към написаното от Веселин по темите с IPv6 и 32-битовите номера на автономни системи бих искал да споделя с вас някои допълнителни факти, които се надявам да ви бъдат полезни.

1) В България от 22 декември 2008 г. има трета автономна система (освен AS6802 и AS8717), която анонсира собствен /32 IPv6 префикс (2001:1ae0::/32) -- това е AS8262 (Натурела AKA Лирекс AKA Еволинк). Моментното състояние, както и малко история, се виждат доста добре тук:

http://www.sixxs.net/tools/grh/dfp/all/?country=bg

Хубавото е че вече се появяват възможности за резервна свързаност и това е само началото. :) Все пак, за отбелязване е и факта че IPv6 префиксите на SpectrumNet и Lirex често страдат от липса на видимост всред част от участниците в SixXS, което може да оказва лошо влияние на качеството на свързаността им понякога [към 2009-02-18 13:32:27 проблема с видимостта на 2001:1ae0::/32 (Lirex) изглежда отстранен, но продължава да съществува за 2a01:288::/32 (SpectrumNet)]. За ACAD-ския префикс не сме наблюдавали досега подобен проблем.

2) Относно снабдяването със собствен PI IPv6 префикс Веселин по принцип е прав че е за предпочитане, особено за онези от вас, които оперират собствена автономна система. Искам само да уточня че освен административен, в случая има и технически проблем, свързан с обстоятелството че много от граничните маршрутизатори по света са настроени да филтрират IPv6 префикси, които са по-специфични от /32. Разбира се, има изключения, но като цяло, както Веселин знае от собствен опит, това създава проблеми. Дори след като RIPE и останалите RIR-ове евентуално възприемат споменатата политика за директно раздаване на PI /48 може да се очаква че ще мине доста време докато въпросните филтри навсякъде по света бъдат променени, така че да пропускат например PI /48 префикси. Подобен проблем и днес съществува за някои по-специфични IPv4 префикси, въпреки че са официално обявени от RIR-овете като PI. Нещо повече, както е отбелязано в действащата в момента политика на RIPE (IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region) http://www.ripe.net/ripe/docs/ripe-441.html#9, цитирам "PI addresses are expensive to route as no use of aggregation can be made. They might not be globally routable." В крайна сметка колкото е по-специфичен един префикс, толкова е по-вероятно някой някъде нарочно или без да иска да го изфилтрира. :)

3) Относно IPv6 напъните на ДАИТС може да се разказва доста и ще оставя Наско и Лъчо да направят това, ако имат желание. Само ще спомена че след като Наско, Лъчо и аз преди години свършихме маса работа на гол ентусиазъм се стигна до предложението на академичната мрежа да бъде дарено известно количество интересно оборудване, ала по чисто политически причини донорите предпочетоха да го връчат на ДАИТС, където на практика то бе погребано. Много подобна е и историята за Blue Gene/P, който също наскоро намери своя последен дом на ул. Гурко номер 6. Подобни случки наистина са доста демотивиращи за онези, които вършат работата, но за съжаление такова е състоянието на нещата не само в IT сектора у нас.

4) Относно IPv6 способностите на Cisco наистина може доста да се коментира. Все пак обаче справедливостта изисква да не забравяме че водещ(ия) разработчик на IPv6 е Steve Deering, който по времето на тази разработка е работил в Cisco.

http://en.wikipedia.org/wiki/Steve_Deering
http://playground.sun.com/ipv6/bio/deering.html

5) Относно 32-битовите AS идентификатори (ASN) -- това е въпрос, който ще става все по-болезнено актуален в идните месеци, с появата на все повече 32-битови ASN в експлоатация. Доколкото ми е известно маршрутизаторите на AS6802, които в момента са в експлоатация, не поддържат 32-битови ASN. Разбира се, този проблем може да бъде сравнително лесно решен с въвеждането в употреба на нови устройства и/или обновяване на съответните операционни системи (част от нужното е в наличност и има с какво да се започне при наличие на време и желание). Трябва да се има предвид обаче че (по подобие на проблема с по-специфичните от /32 IPv6 префикси) може да се очаква да мине доста време преди транзита на 32-битови ASN навсякъде по света да стане напълно прозрачен и докато това не се случи собствениците на 32-битови ASN може да очакват проблеми с маршрутизацията. Моето лично мнение по тази тема, което съм споделял с колеги преди 2-3 години, е че прехода към 32-битови ASN ще внесе доста повече сътресения в Internet, отколкото прехода от IPv4 към IPv6 (ако последния въобще се състои). За това има много причини, но ще спомена само една от тях -- IPv4 -> IPv6 прехода е много внимателно планиран и е отчетено че ще има поне няколко десетки години период на съжителство. Прехода 16-bit -> 32-bit ASN е мислен и ще се прави на пожар, с всички възможни произтичащи от това усложнения и проблеми. Нека не забравяме че става дума за промяна във формата на BGP пакетите и протокола, която макар и малка е фатална, за тези които не я поддържат. Не съществува и достатъчно надежден начин да се транзитират 32-битови ASN през устройства, които не ги поддържат, а те са преобладаващото мнозинство в света, особено в "последната миля".

Поздрави,
Ведрин
Last edited by vedrin on 18 Feb 2009, 16:49, edited 5 times in total.
--
Vedrin Jeliazkov
User avatar
vedrin
 
Posts: 174
Joined: 16 Feb 2009, 20:30
Location: Sofia

Re: 32-bit AS numbers

Postby spasov » 18 Feb 2009, 13:55

Здравейте!
Накратко:

> > Доколкото участниците в Академичната мрежа, опериращи своя AS, получават
> > пълната таблица от POP-а на GEANT2 в София, имам следния въпрос е към
> > колеките от ИПОИ-БАН. Обработват ли вашите гранични маршрутизатори
> > префикси с първоизточници 32-битови ASN?

Не. Не сме имали питания, заявки и изобщо въпросът не е бил повдиган по
никакъв повод, дори и от GEANT2/DANTE.

Разполагаме с версия на Cisco IOS за нашия граничен маршрутизатор,
която според апокрифни източници би следвало да поддържа 32-bit ASN.
Дори въпросната версия бе пусната за кратко (около 10 мин.), (при
обновяване, не-свързано с 32-bit ASN), и след като прояви бъгавост, се
наложи да се върнем към (малко) по-стара версия.

Благодаря на Веско, че повдигна въпроса. Точно на място и на време.

Напълно съм съгласен и с мнението на Ведри, че проблема с 32-bit ASN е
по-сериозен (от този с IPv6) и ще трябва да се следи развитието му
отблизо и с готовност за реакция при необходимост.

Темата може да прерасне и в изготвяне на прпоръчителна спецификация
(може и във няколко вариянта - OSS, Proprietary) за минималните
изисквания при закупуване на техника за БИОМ. Когато (ако изобщо) накой,
някъде, от някое учреждение, свързано с нещо като БИОМ каже, че са му
останали някакви пари за харчене. (След като са били вече похарчени
много пари за много други неща, за които никои, никого, по никакъв повод
не се е допитал).
Но това е друга тема .... , която всъщност според мен е най-важната за
Академичната мрежа, и поради която избягвам да изказвам мнения ...засега.

Поздрави,
Станислав
spasov
Administrator
 
Posts: 36
Joined: 16 Feb 2009, 20:41

Re: 32-bit AS numbers

Postby vesso » 18 Feb 2009, 13:56

Vedrin Jeliazkov wrote:
> > Zdraveite,
> >
> > V dopqlnenie kqm napisanoto ot Vesselin po temite s IPv6 i 32-bit AS numbers
> > bih iskal da spodelia s vas niakoi dopqlnitelni fakti, koito se nadiavam da vi
> > bqdat polezni.
> >
> > 1) V Bulgaria ot niakolko meseca nasam ima treta avtonomna sistema (osven
> > AS6802 i AS8717), koiato anonsira sobstven /32 IPv6 prefix (2001:1ae0::/32) --
> > tova e AS (Naturela aka Lirex aka Evolink). Momentnoto sqstoianie na neshtata,
> > kakto i malko istoria, se vijdat dosta dobre tuk:
> >
> > http://www.sixxs.net/tools/grh/dfp/all/?country=bg
> >
> > Hubavoto e che veche se poiaviavat vqzmojnosti za rezervna svqrzanost i tova e
> > samo nachaloto ;-) Vse pak, za otbeliazvane e i fakta che IPv6 prefix-ite na
> > SpectrumNet i Lirex chesto stradat ot lipsa na vidimost vsred chast ot
> > uchastnicite v SixXS, koeto moje da okazva losho vlianie na kachestvoto na
> > svqrzanostta im poniakoga. Za ACAD-skia prefix ne sme nabliudavali dosega
> > podoben problem.
> >
> >
Проблемът с новите префикси и видимостта им е този, че някои
маршрутизатори правят филтрация по списъци с префикси, които няма ясен
критерий как да подбрани. Т.е. дори да имате /32 префикс, не е ясно дали
се приема от всички BGP участници в глобалната система за маршрутизация.
Пресен е примерът със 6bone. Нужно беше да им се пише, за да прибавят
префикса 2a01:288::/32 в списъка с допустими префикси на техните
гранични маршрутизатори. Имахме проблем и с ISC. Там също имаше
проблемен филтър.

Накратко, участниците в глобалната маршрутизация не са се научили да
изготвят филтри на база на регистрираните в IP регистрационните бази
route и route6 обекти и това е един от големите минуси. Следва поне ние,
като академична мрежа да започнем да внедряваме филтрация базирана на
route и route6 обектите в IP регистрите. Сигурно няма да стане от раз,
но не пречи да се направи един семинар по темата "съгласуване на
филтрите на BGP маршрутизаторите с информацията в IP регистрите". Имам
някакъв опит с IRRToolSet, който ползволява директно извличане на
обектите от RPLS базите на IP регистрите и форматирането им като филтри
за достъп в конфигурациите на IOS, JunOS, Quagga (с малко дооправяне и
за Xorp). Това е активна филтрация и е добре да я усвоим. Ако се изисква
помощ - давам я. Може да поговорим на някое от събиранията и за "fake
BGP prefix-и" и изобщо за сигурността в BGP и какви са методите а
нейното повишаване, какво значи удостоверен "origin", как в бъдеще ще
има електроннен подпис към префикса и т.н. Изобщо много интересни теми има.

Една от причините за забавянето на приемането на PI IPv6 алокации в
зоната на RIPE е постигане на съгласие за приемане на /48 префикси и
обработването им поне от LIR операторите, които често на транзити. Също
така не е беда, че в САЩ или Канада няма да се вижда нищо освен /32 от
Европа, защото в 90% от случаите междуконтиненталния транзит може да
подава /32 към САЩ и Канада и като трафика дойде в маршрутизаторите му в
Европа (примерно в Лондон, Амстердам или Франкфурт), да следва
подйерархията на /48 - това е йерархично маршрутизиране и не е проблем
да работи и в момента. Т.е. важно е да се постигне /48 пропагандиране в
близкия транзит, а в далечния все още може да се разчита на йерархична
маршрутизация. В момента APNIC и AfriNIC разрешават PI IPv6 и ако и RIPE
разреши тази практика, глобалната BGP таблица за IPv6 ще нарастне към 20
000 префикса за ужас на майсторите на маршрутизатори с чудовищна
фрагментация на паметта:) Разбира се те сигурно ще запазят
рестриктивната филтрация и ще разчитат на йерархична маршрутизация -
някой друг да им свърши работата.

> > 4) Otnosno IPv6 sposobnostite na Cisco, naistina moje dosta da se komentira.
> > Vse pak obache spravedlivostta iziskva da ne zabraviame che vodesht(ia)
> > razrabotchik na IPv6 e Steve Deering, koito po vremeto na tazi razrabotka e
> > rabotil v Cisco ;-)
> >
> > http://en.wikipedia.org/wiki/Steve_Deering
> > http://playground.sun.com/ipv6/bio/deering.html
> >
Това, че такъв човек е работил в Cisco, все още не значи нищо за този
производител. Има един куп RFC документи и IEEE, направени с участие на
Cisco, Microsoft и Sun, които не са намерили място в техни продукти.
Истината е, че Cisco изпуснаха влака с IPv6. Трудно е да се оправдае
стремежа на лобитата им да забавят развитието на нещата, особено с
лошата фрагментация и скъпата памет на устройствата им, която им пречи
да обработват големи BGP таблици (да не споменавам преминаването на
всеки пакет поне през 2 стека). Делян Делчев беше направил демо с
обработката на две пълни BGP таблици на 16 MB памер с OpenWRT на
Linksys.. При това при доста бързо пренареждане на таблицата при
влизането в нея на промени (пр. нов префикс). Трудно ми е да резбера
някой, който е изпуснал последния влак, напълнил е клиентите си със скъп
хардуер, който не може лесно да се смени и вместо да предлага някакъв
изход от това положение, бди над статуквото на този свой пазар. За Cisco
академиите какво мога да кажа, освен думите на Стоян Мишинев, че
съвместмостта на Cisco и академия е като тази между всепомитащо гюле и
напокалтим стълб. В момента Cisco сега се чудят как да спасят пазара си
на SAN комутатори, защото не можеш вече да продаваш комутатори за SAN на
принципа "ние сме Cisco", понеже Brocade предлагат по-евтини и
по-качествени комутатори и най-важното - продават на клиентите екстри,
които те си поръчат. Бъдеще на пазара в тази криза имат само гъвкави
производители. Така, че все едно какви хора са работили в даден
компания. Важни са резултатите. В Япония WIDE залегнаха над Foundry и
свои авторски проекти за маршрутизатори и не сгрешиха. Те не се плашат
нито от големи таблици, нито от голям поток пакети, нито от висок
трафик. Аз съм сигурен, че Ведрин може да направи много добър
маршрутизатор, с подръчен хардуер и софтуер:). Не мога да се меся в
политиката на БИОМ относно използваните решения, но поне мога да изкажа
лично мнение:)

> > 5) Otnosno 32-bitovite AS idetifikatori
> >
За момента проблемът с 32-битовте ASN и ограничената видимост се решава
чрез "агрегация" на 32-битовите ASN префикси към някакъв 16-битов ASN на
транзит. Общо взето решението далеч не е от най-елегантните, но работи и
ще се използва още доста време. Наистина, сегментът със 16-битови ASN
критично намалява и трябва да мислим за преминаване към 32-битови ASN. С
помощта на приятели във Великобритания пуснах една колекторна BGP сесия
на един Xorp базиран маршрутизатор. През нея получавам пълна BGP сесия,
в която има префикси с "origin" 32-битови ASN. Няма никакви проблеми с
обработката им (използвам Xorp 1.6.0, компилиран под CentOS 5.2,
архитектура на процесора x86_64/AMD64). За експеримента работя с памет
256 MB (DDR) и процесор Pentium III и дори с тези ресурси пренареждам
таблицата завидно бързо и синхронизирам получения mesh с RIB. Общо взето
Quagga с кръпката, за която писах преди, се държи също много добре.
Засега нямам никакви забележи относно производителността при работа с
32-битови ASN. Аз лично преброих 8 такива, но това на пръв преглед без
да изпипвам регулярните изрази за търсене.

Много бих се радвал, ако БИОМ направи транзит на префикси с 32-битови
ASN и ако се иска от мен помощ, подкрепа, сътрудничество и т.н, а съм
готов да я дам. Включително мога да направя и един webinar как се прави
агрегацията на 32-битови ASN към 16-битови, когато това се налага.

Поздрави
Весо
vesso
 
Posts: 65
Joined: 17 Feb 2009, 21:09
Location: Sofia

Re: 32-bit AS numbers

Postby vedrin » 18 Feb 2009, 13:56

Здравейте,

Ще си позволя едно малко продължение на темата с 32-битовите ASN, за да илюстрирам с конкретен пример един съвсем реален и за съжаление неизбежен проблем при съвместното съществуване на 16- и 32-битови ASN. По-долу условно ще наричам "стари" маршрутизаторите, които не знаят за съществуването на 32-битови ASN и "нови" -- тези които поддържат тази функционалност.

Осигуряването на транзит на 32-битови ASN през "старите" маршрутизатори (каквито може да се очаква още доста време да бъдат огромното мнозинство маршрутизатори по света) става с цената на грозна кръпка. Тя се състои в заменянето на всички 32-битови ASN в AS_PATH с добре известен и запазен за целта лесно запомнящ се 16-битов ASN -- 23456 (AS_TRANS). Предаването на действителния 32-битов ASN става чрез незадължителния транзитивен атрибут AS4_PATH, който не се интерпретира от "старите" маршрутизатори, но се предава през тях към "новите". Този компромис позволява донейде да се закърпи проблема с прозрачността в периода, през който ще продължава да има "стари" маршрутизатори, но си има свята доста висока цена. Като последица от гореспоменатата замяна, всеки нещастен собственик на "стар" маршрутизатор ще се сблъска с редица проблеми, всред които бих откроил невъзможността да филтрира смислено префикси по AS_PATH, тъй като всички 32-битови ASN ще присъстват там с една и съща стойност (23456). Тзи проблем ще става толкова по-голям за собствениците на "стари" маршрутизатори, колкото повече AS преминават към използване на 32-битови ASN. Би могло да се спекулира и за проблеми със сигурността в този случай, които биха имали глобално отражение върху Internet, включително непряко и върху щастливите собственици на "нови" маршрутизатори. Дори само заради гореизложения конкретен проблем е критично важно прехода от 16-битови към 32-битови ASN да се извърши бързичко, но за съжаление никой не е предложил смислено решение как би могло да стане това при мащабите на съвременния Internet.

Хубавото е че в случая ще страдат повече консерваторите, които по някакви причини не преминават към 32-битови ASN и това ще бъде доста добър стимул прехода да се осъществи сравнително бързо. Не съм сигурен обаче доколко този стимул ще е достатъчен и предварително е ясно че има да стават големи routing веселби през преходния период. :) Трагичното е че липсва дори елементарна информираност за мащабите на проблема, който е далеч по-критичен от прехода към изпозлване на IPv6 например. Подобно на прословутия "проблем 2000", за IPv6 се изливат тонове мастило, включително и от маркетингови и/или политически съображения, докато за 32-битовите ASN цари относителна тишина...

Според информацията, с която разполагам до момента, поддръжка на 32-битови ASN има в следните продукти:

- Cisco Systems IOS-XR 3.4 и следващи версии (само CRS)
- Cisco Systems IOS-NX ("Nexus")
- Cisco Systems IOS 12.2SRD за 7200 и 7600
- Cisco Systems IOS 12.5T за 1800/2800/3800, 7200, 7300
- Cisco Systems 12.2SB-Rel6 за 7200, 7300, 10000
- Cisco Systems 12.2SX за 6500
- Force 10 Networks FTOS 7.7.1.0 и следващи версии
- Juniper Networks’ JUNOS 9.1 и следващи версии
- Juniper Networks’ JUNOSe 4.1.0 и следващи версии
- OpenBGPD 3.9 и следващи версии
- Quagga 0.99.6 и следващи версии
- Redback SEOS (всички версии)

Както сигурно забелязвате, Cisco предлага поддръжка само за определени платформи (далеч не всички) и само в "early technology (T)" и "service
provider (S)" версии на IOS. Очаква се поддръжката да влезе в "mainstream" IOS-ите през първата половина на 2009, но липсва достатъчно информация по въпроса. Същевременно експериментите на Станислав с IOS 12.2SRD на 7206 платформа показаха проблеми, които е възможно да са свързани с bug-ове в нововъведенията за 32-битовите ASN, но не сме се задълбочавали да проверяваме внимателно това (отчасти и поради липса на време). Във всички случаи е ясно че в началото ще има много трески (за да не кажа клони) за дялане, докато нещата с това 16-32-битово ASN съжителство тръгнат криво-ляво горе-долу добре...

Ето примери и за други неща, които може да се очаква че ще се "счупят" при този преход (списъка няма претенции да е пълен):

- всякакви приложения за управление на адреси, които боравят с ASN;
- всякакви приложения за BGP анализ i traffic engineering;
- потенциален ефект върху MPLS-базирани VPN-и, които използват Route Distinguishers (за щастие в академичната мрежа няма такива, но например в проектираната и реализирана от Lirex/Evolink MPLS мрежа на държавната администрация би могло да срещнат трудности; това обаче може би е най-малкия проблем точно на тази мрежа) :)
- всички приложения, които използват Internet Route Registries (IRRs) за конфигуриране или публикуване на политики;
- всички routing политики, които използват ASN (например филтри по AS_PATH или communities).

На първо време би било добре да направите следните неща:

1) Да се уверите че техническия ви персонал е наясно какво представлява AS23456 и че е нормално да се среща на няколко места в един AS_PATH, без това да означава непременно че е налице цикъл в маршрутизацията;

2) Да огледате всичките си филтри, специално по отношение на AS23456 и да внесете корекции ако е нужно;

3) Да огледате всичките си приложения, които боравят с ASN и да предприемете необходимите мерки за тяхното обновяване;

4) Постепенно да започнете да въвеждате поддръжка за 32-битови ASN в маршрутизаторите си;

5) Когато всичките ви маршрутизатори започнат да поддържат надеждно 32-битови ASN, да преобразувате номера на своята автономна система в одобрения 0.XX 4-байтов формат (например AS6802 ще се преобразува в 0.6802 според asdot+ конвенцията за записване на 32-битови ASN (има и други два начина за представяне на 32-битовите ASN освен нея -- asplain (число от 0 до 4294967295) и asdot (комбинация от asplain (от 0 до 65535) и asdot+ (от 65536 нагоре), например 65536 се представя като 1.0))).

Поздрави,
Ведрин
Last edited by vedrin on 18 Feb 2009, 16:49, edited 10 times in total.
--
Vedrin Jeliazkov
User avatar
vedrin
 
Posts: 174
Joined: 16 Feb 2009, 20:30
Location: Sofia

Re: 32-bit AS numbers

Postby vedrin » 18 Feb 2009, 13:56

Здравейте отново,

vedrin wrote:- Cisco Systems IOS-XR 3.4 и следващи версии (само CRS)
- Cisco Systems IOS-NX ("Nexus")
- Cisco Systems IOS 12.2SRD за 7200 и 7600
- Cisco Systems IOS 12.5T за 1800/2800/3800, 7200, 7300
- Cisco Systems 12.2SB-Rel6 за 7200, 7300, 10000
- Cisco Systems 12.2SX за 6500
- Force 10 Networks FTOS 7.7.1.0 и следващи версии
- Juniper Networks’ JUNOS 9.1 и следващи версии
- Juniper Networks’ JUNOSe 4.1.0 и следващи версии
- OpenBGPD 3.9 и следващи версии
- Quagga 0.99.6 и следващи версии
- Redback SEOS (всички версии)


Пропуснах да спомена в този списък Xorp Release 1.5 (22 юли 2008 г.) както и по-новия и съвсем пресен 1.6 (7 януари 2009 г.) -- и двата имат вградена поддръжка на 32-битови ASN. Тя не е включена по подразбиране, но може да се задейства с "enable-4byte-as-numbers". Повече подробности за имплементацията:

http://www.xorp.org/releases/1.6/docs/kdoc/html/libxorp/AsNum.html

BTW, изполозвам случая да призова (за пореден път) към изучаване, експериментиране с и използване на Xorp. Вероятно би било полезно ако Веселин е в състояние да даде напътствия на евентуалните ентусиасти за подобно начинание. Хубаво е че Xorp поддържа и други интересни неща като IPv4 и IPv6 multicast и т.н. Чувал съм че е много популярен например в академичната мрежа на UK точно поради причини от подобен характер, а от друга страна JANET/UKERNA са доста добър пример за следване в доста отношения. :)

Поздрави,
Ведрин

PS: Някой от вас познава ли Павлин Радославов от екипа, разработващ Xorp и има ли контакти с него?

http://www.icir.org/pavlin/

Сигурно би било добра идея да се потърсят възможности за сътрудничество ако има по-сериозни ентусиасти-мрежари сред вас, които биха искали да се занимават и с поне мъничко наука в тази област. :)
Last edited by vedrin on 18 Feb 2009, 16:53, edited 3 times in total.
--
Vedrin Jeliazkov
User avatar
vedrin
 
Posts: 174
Joined: 16 Feb 2009, 20:30
Location: Sofia

Re: 32-bit AS numbers

Postby vedrin » 18 Feb 2009, 13:57

vedrin wrote:PS: Някой от вас познава ли Павлин Радославов от екипа, разработващ Xorp и има ли контакти с него?

http://www.icir.org/pavlin/

Сигурно би било добра идея да се потърсят възможности за сътрудничество ако има по-сериозни ентусиасти-мрежари сред вас, които биха искали да се занимават и с поне мъничко наука в тази област.


Ето ви и една снимка на Павлин (статиите му можете лесно да намерите (например с Google) и прочетете при наличие на време/желание):

http://www.icir.org/pavlin/pavlin.jpg

Поздрави,
Ведрин
Last edited by vedrin on 18 Feb 2009, 16:52, edited 1 time in total.
--
Vedrin Jeliazkov
User avatar
vedrin
 
Posts: 174
Joined: 16 Feb 2009, 20:30
Location: Sofia

Re: 32-bit AS numbers

Postby vedrin » 18 Feb 2009, 13:57

vedrin wrote:статиите му можете лесно да намерите (например с Google) и прочетете при наличие на време/желание


По-специално ви препоръчвам тази като отправна точка (макар че и останалите също представляват интерес):

http://www.xorp.org/papers/xorp-nsdi.pdf

Поздрави,
Ведрин
Last edited by vedrin on 18 Feb 2009, 16:55, edited 1 time in total.
--
Vedrin Jeliazkov
User avatar
vedrin
 
Posts: 174
Joined: 16 Feb 2009, 20:30
Location: Sofia

Re: 32-bit AS numbers

Postby vesso » 18 Feb 2009, 13:57

Vedrin Jeliazkov wrote:
> >
> >
> > Propusnah da spomena v tozi spisqk Xorp Release 1.5 (22 July 2008) kakto i
> > po-novia i sqvsem presen 1.6 (7 Jan 2009) -- i dvata imat vgradena poddrqjka
> > na 32-bitovi AS nomera. Tia ne e vkliuchena po podrazbirane, no moje da se
> > aktivira s "enable-4byte-as-numbers" konfiguracionnata mu opcia. Poveche
> > podrobnosti za realizaciata:
> >
> > http://www.xorp.org/releases/1.6/docs/k ... AsNum.html
> >
> > BTW, izpolzvam sluchaia da prizova (za poreden pqt) izuchavaneto,
> > experimentiraneto s i izpolzvaneto na Xorp. Veroiatno bi bilo polezno ako
> > Vesselin e v sqstoianie da dade napqtstvia na eventualnite entusiasti za
> > podobno nachinanie. Hubavo e che Xorp poddqrja i drugi interesni neshta kato
> > IPv4 i IPv6 multicast i t.n. Chuval sqm che e mnogo populiaren naprimer v
> > akademichnata mreja na UK tochno poradi prichini ot podoben harakter, a ot
> > druga strana JANET/UKERNA sa dosta dobqr primer za sledvane v dosta otnoshenia
> > ;-)
> >
> >
Бих могъл да организирам подробен практически курс за работа с Xorp,
вкл. работа с OLSPv1 и PIM-SM v6, използване на click в ядрата и т.н.
Използвам Xorp активно от 2 години и мога да кажа само добри думи за
него. По едно време имаше бъг и не можеха да се виждат големи извадки от
префикси през конзолата му, но общо взето от 1.5 версията всичко в тази
насока е наред. Мултикаст маршрутизацията в IPv6 се очертава да е
активно използвана, доколкото много IPv6 услуги за мултимедия се
насочват в разработката си към multicast пренос.

Въпросите, които изникват с подобен курс са доста. Най-вече кога и как
да се случи курса. Няма проблеми в Софийския университет да намерим
зала, да направим тренажор и за всеки да има компютър с работещ Xorp.
Проблемът е дали има интерес към тази платформа, дали хората са склонни
да пътуват, за да научат нещата. Xorp има ръководство, но там някои неща
са доста неясно обяснени, например какво е policy и как се прави е доста
неясно на прохождащи в този софтуер. А трябва да се обясняват и основи
на BGPv4-v4+/OSPFv2-v3/OLSPv1/PIM-SM. Т.е. нужно е да има лектор, който
да е в постоянна връзка с хората, които се обучават и да отговаря на
въпроси. За жалост дистанционно обучение по тази тема не може да се
направи, поне не виждам как да се направи ефективно в тази обстановка, в
която сме. Аз бих дал от свободното си време, но хората в този списък
следва да кажат искат или не такова обучение и каква е най-добрата
според тях форма, по която то да се проведе. Идеята на Ведрин да се
стъпи на Xorp като основна платформа за маршрутизация е прекрасна, но за
целта се искат и други знания. Например, преди да започнем курса, трябва
да сме сигурни, че тези, които ще го слушат могат да сглобят машина за
маршрутизатор върху UNIX или UNIX подобна операционна система и владеят
последната поне на ниво "напреднали" (и да са свикнали с правилната
мисъл, че една система е сигурно, ако се актуализира редовно софтуера и
ядрото). Добра отправна точка е да се свали LiveCD за Xorp, което
статртира наготово настроена FreeBSD среда за Xorp, да се огледа и
средата и софтуера. Ако някой иска, ще направя демо как Xorp се поставя
на CentOS, RHEL и прочие от RPM пакети, които съм компилирал (а мога да
науча и останалите да си правят такива). Да, Xorp работи и под Windows
2003 сървър, но аз отказвам твърдо да се занимавам с нещата на
най-големия доставчик на нямане в продуктите си. Добре е курсистите да
знаят как се активира маршрутизацията в ядрото на OS-а, какви са
параметрите за донастройката й, как се правят филтри, какво е click в
ядрото и прочие. Ако аз съм сигурен, че хората искат да се учат и това
няма да остане просто една идея, която да не види бях свят, бих се заел
с тази задача.

Готов съм да отговоря на всякакви въпроси свързани с темата "обучение на
Xorp".


Поздрави
Веселин
vesso
 
Posts: 65
Joined: 17 Feb 2009, 21:09
Location: Sofia

Next

Return to The Internet Protocol (IP)

Who is online

Users browsing this forum: No registered users and 2 guests

cron