[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 'EET/2.0/no 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 'EET/2.0/no DST' instead
BREN forums • View topic - 32-bit/4-byte ASN

32-bit/4-byte ASN

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

Re: 32-bit AS numbers

Postby vedrin » 18 Feb 2009, 13:58

Здравейте,

Споделям за ваша информация че към настоящия момент вече се анонсират общо 21 префикса с 32-битови ASN в AS_PATH в глобалните IPv{4|6} {unicast|multicast} routing таблици, както следва:

- IPv4 unicast (19 префикса от общо 277700):

poseidon#show bgp ipv4 unicast regexp _23456_
BGP table version is 7590741, local router ID is 194.141.252.13
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
*> 64.127.137.0/24 62.40.125.141 0 140 140 20965 1299 1239 19151 18508 23456 i
*> 84.205.64.0/24 62.40.125.141 0 140 140 20965 3549 1273 1103 1125 23456 12654 i
*> 84.205.80.0/24 62.40.125.141 0 140 140 20965 3549 1273 1103 1125 23456 12654 i
*> 91.196.186.0/24 62.40.125.141 0 140 140 20965 3549 15703 43531 23456 i
*> 91.207.218.0/23 62.40.125.141 0 140 140 20965 1299 3356 13249 6886 23456 i
*> 91.208.44.0/24 62.40.125.141 0 140 140 20965 1213 23456 i
*> 93.89.236.0/22 62.40.125.141 0 140 140 20965 1299 12301 23456 i
*> 94.199.136.0/21 62.40.125.141 0 140 140 20965 1299 174 23456 i
*> 169.222.0.0/24 62.40.125.141 0 140 140 20965 1299 6939 6939 7091 715 23456 i
*> 192.26.93.0 62.40.125.141 0 140 140 20965 1299 2914 4697 23456 i
*> 193.5.68.0/23 62.40.125.141 0 140 140 20965 1299 6830 8758 23456 i
*> 193.31.7.0 62.40.125.141 0 140 140 20965 3549 5539 23456 i
*> 195.47.195.0 62.40.125.141 0 140 140 20965 1299 8495 8495 23456 i
*> 195.128.230.0 62.40.125.141 0 140 140 20965 1299 3356 13249 6886 23456 35748 i
*> 195.128.231.0 62.40.125.141 0 140 140 20965 1299 3356 13249 6886 23456 35748 i
*> 196.1.15.0 62.40.125.141 0 140 140 20965 1299 174 3741 23456 i
*> 197.255.248.0/22 62.40.125.141 0 140 140 20965 1299 174 3741 23456 i
*> 202.255.47.0 62.40.125.141 0 140 140 20965 3549 2516 7667 23456 i
*> 205.233.128.0 62.40.125.141 0 140 140 20965 1299 10026 7657 23754 23754 9439 23456 i

- IPv4 multicast (0 префиксa от общо 7909):

poseidon#show bgp ipv4 multicast summary
BGP router identifier 194.141.252.13, local AS number 6802
BGP table version is 108151, main routing table version 108151
7909 network entries using 956989 bytes of memory
7909 path entries using 379632 bytes of memory
103017/785 BGP path/bestpath attribute entries using 7829292 bytes of memory
1 BGP rrinfo entries using 24 bytes of memory
45712 BGP AS-PATH entries using 1239254 bytes of memory
2119 BGP community entries using 105626 bytes of memory
4 BGP extended community entries using 112 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
92321 BGP filter-list cache entries using 1107852 bytes of memory
BGP using 11618781 total bytes of memory
BGP activity 829574/541771 prefixes, 1014035/719295 paths, scan interval 60 secs

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
62.40.114.12 4 20965 0 0 0 0 0 never Idle (Admin)
62.40.114.19 4 20965 0 0 0 0 0 never Idle
62.40.125.141 4 20965 2362703 183458 108151 0 0 8w2d 7909

- IPv6 unicast (2 префиксa от общо 1502):

poseidon#show bgp ipv6 unicast regexp _23456_
BGP table version is 132287, local router ID is 194.141.252.13
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
*> 2001:DF0:2::/48 2001:798:2C:10AA::9 0 140 140 20965 1299 2914 4697 23456 i
*> 2001:4810:2000::/35 2001:798:2C:10AA::9 0 140 140 20965 1299 3257 29748 33437 23456 i

- IPv6 multicast (0 префикса от общо 46):

poseidon#show bgp ipv6 multicast summary
BGP router identifier 194.141.252.13, local AS number 6802
BGP table version is 1186, main routing table version 1186
47 network entries using 6815 bytes of memory
47 path entries using 3572 bytes of memory
103014/44 BGP path/bestpath attribute entries using 7829064 bytes of memory
1 BGP rrinfo entries using 24 bytes of memory
45705 BGP AS-PATH entries using 1239038 bytes of memory
2118 BGP community entries using 105618 bytes of memory
4 BGP extended community entries using 112 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
92298 BGP filter-list cache entries using 1107576 bytes of memory
BGP using 10291819 total bytes of memory
BGP activity 829574/541771 prefixes, 1014035/719295 paths, scan interval 60 secs

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
2001:798:1B:10FF::1 4 20965 0 0 0 0 0 never Idle
2001:798:2C:10AA::9 4 20965 292387 183343 1186 0 0 8w2d 46
2001:798:2C:10FF::2 4 20965 0 0 0 0 0 never Idle (Admin)

Поздрави,
Ведрин
Last edited by vedrin on 18 Feb 2009, 17:07, edited 2 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, 14:02

Здравейте,

Вероятно ще ви бъде полезно да прегледате приложения документ, който Станислав вчера намери. Той съдържа в достатъчно ясна и сбита форма онова, което трябва да знаете за "4-octet Autonomous System (AS) Numbers for Cisco IOS" (знам че доста от вас разчитат на подобни устройства, а пък информацията така или иначе е доста генерична и може да е полезна и за щастливците, които не са зависими от Cisco).

В допълнение към него, както и към списъка от потенциални проблеми, който започнах по-горе, ще цитирам и няколко пасажа от друг документ:

1) It is strongly recommended that an Autonomous System will only start using the 4-octet AS information when all BGP speakers, within that Autonomous System, have been upgraded to support 4-octet AS numbers. Making sure that all BGP speakers support 4-octet AS numbers guarantees that each BGP speaker has a valid 4-octet AS number view of the BGP table. If within the Autonomous System, some nodes are OLD speakers, and other nodes are NEW BGP speakers, then the BGP table view can be dramatically different between an OLD and NEW BGP speaker. Not following this guideline may result in BGP routing loops, due to incomplete AS-Path information on the OLD BGP speakers.

[мой коментар: следването на тази препоръка най-вероятно би довело дотам че на AS6802 ще й бъде необходимо повече време за прехода към пълното поддържане на 32-битови ASN, поради наличието на разнородно оборудване (част от AS6802) в различните PoPs, често администрирано от независими организации със собствени бюджетни, счетоводни и управленски правила и ограничения; това всъщност е свързано с друг много по-голям проблем, а именно родилните мъки на академичната мрежа в България, които продължават вече около 16 години]

2) Under certain conditions, it may not be possible for a NEW BGP speaker to reconstruct the entire AS path information from the AS_PATH and the AS4_PATH attributes of a route. This occurs when two or more routes that carry the AS4_PATH attribute are aggregated by an OLD BGP speaker, and the AS4_PATH attribute of at least one of these routes carries at least one 4-octet AS number (as oppose to a 2-octet AS number that is encoded in 4 octets). When such aggregation results in creating a route that is less specific than any of the component routes, loss of the AS path information does not create a risk of a routing loop. In all other cases, loss of the AS path information does create a risk of a routing loop.

3) AS-Path filtering has some considerations when an Autonomous System contains OLD BGP speakers. Initially there will only be a very low number of true 4-octet AS numbers found on the Internet, hence the BGP table of the OLD BGP speakers reflects very well on the Internet. However, due to the incremental increase adoption of true 4-octet AS numbers, the BGP table on an OLD BGP speaker may become gradually more and more incorrect, because the OLD BGP speaker does not understand either 4-octet AS numbers and the new optional transitive BGP attributes AS4-PATH and AS4-AGGREGATOR. Due to the gradually growing incorrectness of the BGP table on the OLD BGP speaker, AS-Path filtering will become increasingly troublesome.

4) An additional aspect gradually complicating AS-Path filtering on an OLD BGP speaker as time moves forward, is the well known AS# AS_TRANS "23456". This well known AS number can be found within the AS-Path list of a BGP route identifying an incompatible 4-octet AS#. In essence, the OLD BGP speaker does not understand the full set of information available and cannot filter based upon 4-octet Autonomous System Numbers.

5) In an environment where an Autonomous System that has OLD BGP speakers peers with two or more Autonomous Systems that have NEW BGP speakers and uses AS_TRANS (rather than having a globally unique AS number), use of Multi-Exit Discriminators by the Autonomous System with the OLD speakers may result in a situation where Multi-Exit Discriminator will influence route selection among the routes that were received from different neighboring Autonomous Systems.

6) NetFlow Support: In a classical 2-octet Autonomous System environment, there will be a gradually growing inconsistency by the adoption of true 4-octet Autonomous System Numbers. This inconsistency gets reflected because all true AS# 4-octet data gets consolidated and the traffic matrix is lost. A NEW BGP speaker will get support of 4-octet AS numbers through an extension in NetFlow v9 to support it.

За тези, които се интересуват, пълния текст на документа, от който са направени горните извадки, е достъпен тук:

http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6554/ps6599/white_paper_c11-516826.html

Както сами виждате, задават се бурни времена за глобалната маршрутизация (моделите сочат че най-късно между началото и средата на 2011 г. всички 16-битови ASN ще бъдат изчерпани) и лошото е че независимо какво предприемате (например бързо преминаване към операционна система, която поддържа 32-битови ASN или забавяне на тази промяна), във всички случаи бурята ще ви засегне по един или друг съпоставимо неприятен и твърде продължителен начин.

Не бих се изненадал ако вследствие на сериозните и продължителни проблеми с маршрутизацията, които със сигурност предстоят в съвсем близко бъдеще, цялата идея за 32-битови ASN в крайна сметка бъде изоставена, а старите 16-битови ASN станат много ценни (например вследствие на политическо решение или пък на пазарен принцип). Това последното със сигурност някои "играчи" отдавна са го осъзнали и вероятно ще наблюдаваме ускоряване на процеса на разграбване на ограничения ресурс, който все още е наличен.

На фона на всичко това може да се окаже че изключително високата и направо разточителна гъстота на (16-битови) автономни системи на глава от населението в България е всъщност една прекрасна инвестиция. :)

Поздрави,
Ведрин
Attachments
white_paper_C11_516823.pdf
Explaining 4-octet Autonomous System (AS) Numbers for Cisco IOS
(283.42 KiB) Downloaded 365 times
Last edited by vedrin on 18 Feb 2009, 17:29, edited 2 times 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, 14:03

Vedrin Jeliazkov wrote:
> > Zdraveite,
> >
> > Spodeliam za vasha informacia che kqm nastoiashtia moment veche se anonsirat
> > obshto 21 32-bitovi AS v globalnite IPv{4|6} {unicast|multicast} routing
> > tablici, kakto sledva:
> >
> > - IPv4 unicast (19 prefix-a ot obshto 277700):
> >
> >
Аз ще направя малко разходка из глобалната BGP таблица и ще покажа
конкретни 32-битови ASN и префиксите, за които те са "origin".

Ведрине, имам една забележка. Регулярният израз, който си използвал:

... regexp _23456_

няма да ти даде броят префикси, който имат "origin" 32-битов ASN и са
агрегирани към 16-битов идентификатор на AS, а ще ти даде тях и тези
префикси, които имат в своя AS път транзитна автомна система, която има
32-битов ASN, но той е агрегиран към AS23456. Това обяснява силно
завишения резултат - 19. Ако трябва да се видят само префиксите, които
имат "origin" AS23456, това следва да става с израза:

... regexp _23456$

Искам да ви покажа как изглеждат неагрегираните към AS23456 AS пътища за
префикси. Използвал съм Quagga 0.99.9 и две BGP колекторни сесии от
университети във Великобритания, които използват Juniper и имат
активирана поддръжка на 32-битови ASN. Първо ще дам пример с извличането
на информация за една такава AS - AS3.2 (моля, обърнете вниманието на
структурата на регулярния израз - имате "освобождаване" на точката с \ -
това е задължително, иначе филтъра не работи за описаната цел):

bgpd@lcpe-gw> show ip bgp regexp _2\.3$

BGP table version is 0, local router ID is 62.44.127.19
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
* 192.26.93.0 192.168.12.2 0 65520 4777 2497 2914 4697 2.3 i
* 192.168.12.3 0 65510 34225 1299 2914 4697 2.3 i


Всъщност какво би станало, ако напишете регулярния израз от горния
пример без освобождаване на точката, т.е. така:

... regexp _2.3$

Така ще получите всички префикси, които имат "origin" AS номера 2[0-9]3
и 2.3 (всъщнсот от 2[0-9]3 ще получите само 243, защото само тя е
използвана за "origin" към момента от всичк, които отговарят на шаблона).

Ако искам да получа всички подавани към мен 32-битови ASN (все едно дали
в AS пътя има или няма 32-битов ASN на танзит), мога да използвам
следния регуларен израз (може да се напише по-добре, но го показвам по
този начин за да е по-интуитивен за разбиране):

bgpd@lcpe-gw> show ip bgp regexp _[0-65535]\.[0-65535]$

BGP table version is 0, local router ID is 62.44.127.19
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete

* 64.127.137.0/24 192.168.12.2 0 65520 4777 2516 19151 18508 6.6 i
* 192.168.12.3 0 65510 34225 41692 19151 18508 6.6 i
* 169.222.0.0/24 192.168.12.2 0 65520 4777 2497 7091 715 2.4 i
* 192.168.12.3 0 65510 34225 41692 6939 7091 715 2.4 i
* 192.26.93.0 192.168.12.2 0 65520 4777 2497 2914 4697 2.3 i
* 192.168.12.3 0 65510 34225 1299 2914 4697 2.3 i
* 193.31.7.0 192.168.12.2 0 65520 4777 2516 1273 5539 3.3 i
* 192.168.12.3 0 65510 34225 41692 5539 3.3 i
* 196.1.15.0 192.168.12.2 0 65520 4777 2516 3741 5.1 i
* 192.168.12.3 0 65510 34225 41692 35244 174 3741 5.1 i
* 197.255.248.0/22 192.168.12.2 0 65520 4777 2516 3741 5.1 i
* 192.168.12.3 0 65510 34225 41692 35244 174 3741 5.1 i
* 202.255.47.0 192.168.12.2 0 65520 4777 2516 7667 2.6 i
* 192.168.12.3 0 65510 34225 1299 3356 2516 7667 2.6 i



В същшия момент получавам и префикси, в чиито AS пътища или "origin' се
съдържа 32-битов ASN или , но са агрегирани към AS23456 (т.е. имам
хибридна таблица - едновремено в общата таблица имам неагрегирани и
агрегирани "origin"-и):

bgpd@lcpe-gw> show ip bgp regexp _23456_

BGP table version is 0, local router ID is 62.44.127.19
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete

* 91.196.186.0/24 192.168.12.2 0 65520 4777 2516 6461 15703 43531 23456 i
* 192.168.12.3 0 65510 34225 41692 15703 43531 23456 i
* 91.207.218.0/23 192.168.12.2 0 65520 42109 41965 41877 20771 174 2914 35320 3.21 23456 e
* 192.168.12.3 0 65510 34225 41692 35320 3.21 23456 ?
* 195.128.230.0 192.168.12.2 0 65520 42109 41965 41877 20771 174 2914 35320 3.21 23456 35748 e
* 192.168.12.3 0 65510 34225 41692 35320 3.21 23456 35748 i
* 195.128.231.0 192.168.12.2 0 65520 42109 41965 41877 20771 174 2914 35320 3.21 23456 35748 e
* 192.168.12.3 0 65510 34225 41692 35320 3.21 23456 35748 i


Дори без смяна на регулярния израз се вижжда, че има само два префикса,
които имат "origin" AS23456, а в другите два случая става въпрос за
транзит през 32-битов ASN, агрегиран към 16-битовия агрегиращ ASN.
Интересно е да се коментира наличието на EGP първоизчотник и лошата
практика за "incomplete" източник (този с питанката), но това ще излезе
доста от темата за 32-битови ASN.

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

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

Re: 32-bit AS numbers

Postby vedrin » 18 Feb 2009, 14:03

Здравейте,

Допълненията на Веселин са полезни, но отиват встрани от това, което исках да илюстрирам по-горе. Нека първо уточним че наличието на определен ASN в AS_PATH означава че този ASN се анонсира в глобалната routing таблица, независимо дали той е origin или транзитен за съответния префикс. Поради това използвах _23456_ а не _23456$. Наистина щеше да бъде по-коректно ако бях писал за брой префикси, а не за брой ASN (съжалявам за тази допусната от мен неточност -- вече я поправих по-горе).

В крайна сметка обаче това което в случая е най-съществено е именно броя префикси, които съдържат AS23456 в AS_PATH, защото този брой е доста добра мярка за разминаването в мирогледите на един "стар" и един "нов" BGP маршрутизатор. Това разминаване в момента е пренебрежимо малко (само 17 префикса за IPv4 unicast и 2 за IPv4 multicast), но ще става все по-голямо и ще създава все повече проблеми в идните месеци и години, както обясних по-горе. Неприятното е че дори дадена автономна система да си е написала прекрасно домашното на тази тема (не се съмнявам че AS5421 i AS6802 ще го сторят), глобалната маршрутизация ще страда от грешките на други автономни системи по света, каквито може да се очаква че ще има в по-голямо от обичайното количество докато трае продължителния преходен период.

Благодаря на Веселин че ни показа как изглежда AS_PATH с 32-битов ASN в него -- трябва да призная че за пръв път виждам такъв. :) От друга страна обаче явно маршрутизатора, на който са правени експериментите разполага с доста агрегиран вид на глобалната routing таблица, тъй като не вижда доста префикси. Към настоящия момент общия брой IPv4 unicast префикси с AS23456 в AS_PATH е спаднал от вчерашните 19 на 17, като от тези 17, в 15 от случаите AS23456 е origin. Дали тези 17 появи на 23456 съответстват на един, два или повече 32-битови ASN "старите" маршрутизатори не знаят и никога няма да разберат...

poseidon#show bgp ipv4 unicast regexp _23456_
BGP table version is 7753781, local router ID is 194.141.252.13
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
*> 64.127.137.0/24 62.40.125.141 0 140 140 20965 1299 1239 19151 18508 23456 i
*> 91.196.186.0/24 62.40.125.141 0 140 140 20965 3549 15703 43531 23456 i
*> 91.207.218.0/23 62.40.125.141 0 140 140 20965 1299 3356 13249 6886 23456 i
*> 91.208.44.0/24 62.40.125.141 0 140 140 20965 1213 23456 i
*> 93.89.236.0/22 62.40.125.141 0 140 140 20965 1299 12301 23456 i
*> 94.199.136.0/21 62.40.125.141 0 140 140 20965 1299 174 23456 i
*> 169.222.0.0/24 62.40.125.141 0 140 140 20965 1299 6939 6939 7091 715 23456 i
*> 192.26.93.0 62.40.125.141 0 140 140 20965 1299 2914 4697 23456 i
*> 193.5.68.0/23 62.40.125.141 0 140 140 20965 1299 6830 8758 23456 i
*> 193.31.7.0 62.40.125.141 0 140 140 20965 3549 5539 23456 i
*> 195.47.195.0 62.40.125.141 0 140 140 20965 1299 8495 8495 23456 i
*> 195.128.230.0 62.40.125.141 0 140 140 20965 1299 3356 13249 6886 23456 35748 i
*> 195.128.231.0 62.40.125.141 0 140 140 20965 1299 3356 13249 6886 23456 35748 i
*> 196.1.15.0 62.40.125.141 0 140 140 20965 1299 174 3741 23456 i
*> 197.255.248.0/22 62.40.125.141 0 140 140 20965 1299 174 3741 23456 i
*> 202.255.47.0 62.40.125.141 0 140 140 20965 3549 2516 7667 23456 i
*> 205.233.128.0 62.40.125.141 0 140 140 20965 1299 10026 7657 23754 23754 9439 23456 i

poseidon#show bgp ipv4 unicast regexp _23456$
BGP table version is 7753849, local router ID is 194.141.252.13
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
*> 64.127.137.0/24 62.40.125.141 0 140 140 20965 1299 1239 19151 18508 23456 i
*> 91.196.186.0/24 62.40.125.141 0 140 140 20965 3549 15703 43531 23456 i
*> 91.207.218.0/23 62.40.125.141 0 140 140 20965 1299 3356 13249 6886 23456 i
*> 91.208.44.0/24 62.40.125.141 0 140 140 20965 1213 23456 i
*> 93.89.236.0/22 62.40.125.141 0 140 140 20965 1299 12301 23456 i
*> 94.199.136.0/21 62.40.125.141 0 140 140 20965 1299 174 23456 i
*> 169.222.0.0/24 62.40.125.141 0 140 140 20965 1299 6939 6939 7091 715 23456 i
*> 192.26.93.0 62.40.125.141 0 140 140 20965 1299 2914 4697 23456 i
*> 193.5.68.0/23 62.40.125.141 0 140 140 20965 1299 6830 8758 23456 i
*> 193.31.7.0 62.40.125.141 0 140 140 20965 3549 5539 23456 i
*> 195.47.195.0 62.40.125.141 0 140 140 20965 1299 8495 8495 23456 i
*> 196.1.15.0 62.40.125.141 0 140 140 20965 1299 174 3741 23456 i
*> 197.255.248.0/22 62.40.125.141 0 140 140 20965 1299 174 3741 23456 i
*> 202.255.47.0 62.40.125.141 0 140 140 20965 3549 2516 7667 23456 i
*> 205.233.128.0 62.40.125.141 0 140 140 20965 1299 10026 7657 23754 23754 9439 23456 i

При IPv4 multicast и IPv6 {unicast|multicast} няма промяна в сравнение с вчера.

BTW, Веселине, може би би било интересно и за други да покажеш също как изглежда съдържанието на AS4_PATH и AS4_AGGREGATOR за тези пътища.

Използвам случая също да ви предложа една идея. Би било полезно да се направи публично достъпна статистика, анализираща степента на навлизане в употреба на 32-битови ASN. Такава може и да има някъде по света (не съм проверявал), но е добра и сравнително лесна за решаване задача за някой с интереси в тази област. Хубаво би било тази статистика да се генерира автоматично въз основа на видяното от поне един добре свързан BGP маршрутизатор, който поддържа IPv4 и IPv6, unicast i multicast адресните фамилии. За начало би могло да се анализира броя на префиксите, които съдържат AS23456 и да се записва история. Разбира се, идеята може да се разшири и с други видове статистики/наблюдения, които евентуално да помагат при откриването на проблеми около въвеждането в експлоатация на 32-битови ASN по света (например в стила на Ghost Route Hunter). Ако статистиката е достъпна през web интерфейс, би било чудесно. Има ли ентусиасти за подобно начинание? :)

Поздрави,
Ведрин
Last edited by vedrin on 18 Feb 2009, 17:56, 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, 14:03

Vedrin Jeliazkov wrote:
> > BTW, Vesseline, moje bi bi bilo interesno i za drugi da pokajesh sqshto kak
> > izglejda sqdqrjanieto na AS4_PATH i AS4_AGGREGATOR atributite za tezi
> > pqtishta.
> >
> >
За всички едва ли е нужно. По-скоро ще покажа за един

192.26.93.0/24

-> AS_PATH: 65520 4777 2497 2914 4697 23456
-> AS4_PATH: 65520 4777 2497 2914 4697 2.3
-> AS4_AGGREGATOR: 4697 61.213.160.174

AS4_AGGREGATOR отчита граничния маршрутизатор на коя AS (и с какво
Router ID) извършва агрегацията от 32-битов към 16-битов идентификатор.

Възможно ли е да пренесем дискусията във форума? Добре е тези неща да
могат да се четат публично от доставчиците на свързаност у нас. Докато
ние можем да се справим с проблема без да се замисляме много много, за
един доставчик въвеждането на 32-битови ASN ще е кървава революция.

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

Re: 32-bit AS numbers

Postby vedrin » 18 Feb 2009, 14:20

vedrin wrote:Използвам случая също да ви предложа една идея. Би било полезно да се направи публично достъпна статистика, анализираща степента на навлизане в употреба на 32-битови ASN. Такава може и да има някъде по света (не съм проверявал), но е добра и сравнително лесна за решаване задача за някой с интереси в тази област. Хубаво би било тази статистика да се генерира автоматично въз основа на видяното от поне един добре свързан BGP маршрутизатор, който поддържа IPv4 и IPv6, unicast i multicast адресните фамилии. За начало би могло да се анализира броя на префиксите, които съдържат AS23456 и да се записва история. Разбира се, идеята може да се разшири и с други видове статистики/наблюдения, които евентуално да помагат при откриването на проблеми около въвеждането в експлоатация на 32-битови ASN по света (например в стила на Ghost Route Hunter). Ако статистиката е достъпна през web интерфейс, би било чудесно. Има ли ентусиасти за подобно начинание?


Хрумна ми също че за реализацията на гореспоменатата идея би било интересно да се използват поне два отделни BGP маршрутизатора (единия "стар", а другия "нов"), които разполагат с пълната BGP таблица за различните адресни фамилии и имат еднакви множества от съседи. Така би могло да се направят интересни автоматични съпоставки между видяното от тях, които биха били полезни при анализа на възникващите проблеми. Може би би било много удачно за целта да се използва последната версия на Xorp, като само единия от маршрутизаторите бъде конфигуриран да обработва 32-битови ASN.
--
Vedrin Jeliazkov
User avatar
vedrin
 
Posts: 174
Joined: 16 Feb 2009, 20:30
Location: Sofia

Re: 32-bit AS numbers

Postby npetevn » 18 Feb 2009, 22:55

vedrin wrote:Хрумна ми също че за реализацията на гореспоменатата идея би било интересно да се използват поне два отделни BGP маршрутизатора (единия "стар", а другия "нов"), които разполагат с пълната BGP таблица за различните адресни фамилии и имат еднакви множества от съседи. Така би могло да се направят интересни автоматични съпоставки между видяното от тях, които биха били полезни при анализа на възникващите проблеми. Може би би било много удачно за целта да се използва последната версия на Xorp, като само единия от маршрутизаторите бъде конфигуриран да обработва 32-битови ASN.


Идеята за статистиката е общополезна и важна, а желание и възможност за свършване на работата поне от моя страна има. Вариантът с двата маршрутизатора изглежда постижим в сравнително кратки срокове, като за подобна задача не са необходими почти никакви ресурси (стари но стабилни ibm-и и dell-ове биха свършили работа завидно добре). Резултатите обаче, както е ясно, ще бъдат много едностранчиви, така че не е ли възможно "удължаване" (при евентуално работещо решение) на проекта в рамките на GEANT и събиране на оценки от поне още няколко академични мрежи?
В същото направление, не е ли време и да се обмисли вдигането и поддържането на RIS (за момента такива би било много полезно да има поне в AS5421 и AS6802, заради броя на BGP съседите им). Веднъж пуснати, RIS-овете могат да се ползват за изготвяне на каквито поискаме статистически оценки (включително навлизането на 32-битовите ASN).
Николай Николов СУ
npetevn
 
Posts: 6
Joined: 18 Feb 2009, 10:49

Re: 32-bit AS numbers

Postby nina » 18 Feb 2009, 23:40

npetevn wrote:Резултатите обаче, както е ясно, ще бъдат много едностранчиви, така че не е ли възможно "удължаване" (при евентуално работещо решение) на проекта в рамките на GEANT и събиране на оценки от поне още няколко академични мрежи?


Възможно е да се направи в рамките на Network Monitoring дейността на GEANT3. Perfsonar (http://www.perfsonar.net/) се състои от два основни вида web services:

1) първия тип предоставя достъп до архиви с данни от измервания, които в случая биха могли да бъдат статистики за броя на префиксите с 32-битови ASN в AS_PATH и/или AS4_PATH (такъв точно архив в момента няма, но бихме могли да предложим да го разработим);

2) втория тип предоставя възможност да се правят измервания "on demand" (например SSH/Telnet MP Service, който позволява достъп до определени маршрутизатори според конфигурацията си; достъпът до самия SSH/Telnet MP service се контролира чрез authentication и authorisation на федеративен принцип, базиран на edugain http://www.edugain.org/)

Бихме могли да разширим съществуващия SSH/Telnet MP Service с measurement archive (MA) функционалност, чрез която да се събират статистиките за 32-битовите ASN или каквито и да е било други интересуващи ни параметри. Новосъздадения SSH/Telnet МА service би могло да бъде инсталиран в няколко други NRENs и така да постигнем желаното разширяване на идеята:

http://wiki.perfsonar.net/jra1-wiki/index.php/Test_Infrastructure

Информацията ще може да се визуализира с един общ клиент за всичките архиви -- perfsonarUI, който ще трябва за целта да бъде разширен с подобна функционалност:

http://perfsonar.acad.bg/perfsonar/perfsonar.jnlp

Бихме могли да предложим тази идея на партньорите от GEANT3 (проекта започва от 1 април 2009) и в случай че бъде одобрена би трябвало да има финансиране за работата, което обаче ще подлежи на одобрение от ръководството на БИОМ (страна в проекта).

Ако би се заел с (част от) тази работа ще изпратя съответното запитване към ръководителя на дейността.

Поздрави,
Нина
User avatar
nina
 
Posts: 29
Joined: 17 Feb 2009, 18:27

Re: 32-bit AS numbers

Postby vesso » 19 Feb 2009, 09:29

Както и да си ги говорим нещата, ясно е, че ще трябва да потърсим колаборация с доставчиците, защото BGP съседите ни не са само академични организации. Същото може да се каже и за транзитите ни. Положението за момента е следното. Имаме планирана среща с техническите лица на Спектрумнет (Петър Щинков и Татяна Димитрова), остава да я задвижа. На нея ще си говорим за по-нататъшната интеграция на IPv6 в DNS и последна миля за клиентите, но няма проблеми да повдигна въпроса и за 32-битовие ASN. По принцип те са отворени към нови идеи хора и ако видят ясна и обоснована оценка на прилагането на новия номерационен план на ASN, ще го внедрят. Гръбнакът на мрежата им от гледна точка на маршрутизация е не-Cisco и не мисля, че ще имат ядове да си настроят JunOS-а.

Имам идеята да говоря с Еволинк за тези неща. Това е по-интересно за AS6802, защото има напречна свързаност с AS8262. Исторически, Еволинк (тогава Лирекс Нет), бяха първият транзит, с който AS5421 установи напречна свързаност. Не виждам защо да не ги включим в някаква колаборация. Там проблемът е, че всичко е Cisco. Затова ще трябва да се подходи с доста убеждения, но поемам ангажимента да говоря със Светльо Христов и да направим поне среща по темата.

Нека не се лъжем - глобалната маршрутизация за това е глобална, защото всички транзити участват в нея. Следователно за да наложим нещо ново, трябва да го наложим на близкото си BGP обкръжение, то на своето и т.н. Като стимул в тази насока можем да задаваме в ЗОП изисквания към доставката на интернет свързаност, в които да се заявява обявяването в BGP сесиите на 32-битовите ASN. За целта е достатъчно да има един комерсиален доставчик, който да предлага това, за да не може условието за 32-битови ASN да се окаже недопустимо в търга (и да бъде атакувано). Именно затова трябва да накараме поне един български транзитен доставчик, да пусне тази функционалност. След това бизнес интересът ще накара и другите да прибавят тази функционалност, а това ще окаже натиск над техните транзиити и т.н. Примерно натискът за IPv6 оказан от наша страна върху транзитите успя. Указахме изискването за IPv6 транзит в ЗОП относно доставка на интернет свързаност за СУ и маса доставчици (дори Мегалан) си алокираха полагащия им се като LIR /32 префикс. Поемам ангажимента да направя разговор със Спектрумнет и после с Еволинк относно 32-битовите ASN (а те са LIR и тази тема касае клиентите им) и да ви уведомя за развитието.
vesso
 
Posts: 65
Joined: 17 Feb 2009, 21:09
Location: Sofia

Re: 32-bit AS numbers

Postby vesso » 19 Feb 2009, 09:41

Имам и конкретно предложение за изучаване на ефекта от използването на 32-битов ASN. БИОМ имат LIR статус и могат да алокират 32-битов ASN за техен "клиент". Може просто някакъв куп /24 префикси от 194.141.0.0/16 да се преалокира (чрез фокуси с обектите в RIPE DB) към друга AS и тя да е 32-битова. На всяка организация, BGP съсед с AS6802, която иска да изучава ефекта от използването на 32-битовите ASN, се дава по един /24 сегмент, с "origin" алокираната за целта от БИОМ AS, осигурява се "uplink" през БИОМ с агрегация в посока Интернет и гледаме получаваната при нас таблица, излъчвания от нас анонс и видимостта му по колекторите и route сървърите в Мрежата. След края на експеримента, ще върнем AS номера на RIPE NCC.

Ведрин и Светослав какво мислят по това предложение?
vesso
 
Posts: 65
Joined: 17 Feb 2009, 21:09
Location: Sofia

PreviousNext

Return to The Internet Protocol (IP)

Who is online

Users browsing this forum: No registered users and 1 guest

cron