Re: Распределенная автономка

From

Dmitry Kiselev (2:5020/400)

To

Victor Sudakov (2:5054/37.63)

Date

2007-11-01T12:49:36Z

Area

RU.CISCO

From: Dmitry Kiselev <dmitry@dmitry.net>

Victor Sudakov wrote:

>>>>> neighbor ... allowas-in
>>>>>
>>>>> Хотя ситуация не вполне правильная. Лучше для каждого города свою автономку
>>>>> зарегистрировать, если города связаны между собой через другие AS.
>>>> Полностью Пашу поддерживаю. Гораздо проще один раз объяснить RIPE NCC 
>>>> суть проблемы и получить нужное кол-во ASN, чем регулярно иметь секс с 
>>>> маршрутами и фильтами.
>>> Я как раз недавно занимался этим вопросом в сходной ситуации (LIR -
>>> центральная контора в Москве, и несколько филиалов по России).  Номера
>>> AS для филиалов (пока для двух) RIPE выделил, но hostmaster задал
>>> каверзный вопрос:
>>>
>>> Are you aware that announcing the allocation as a whole and then
>>> announcing smaller assignments within the allocation using a different
>>> AS Number goes against the aggregation goal and will cause routing
>>> problems?
>>>
>>> Вот сижу думаю теперь, какие routing problems имелись в виду.
>>>
>>> Впрочем, по первой претензии тоже не вполне понятно. Будут ли more
>>> specific префиксы объявляться от имени AS головной конторы или от
>>> имени собственных AS - размер мировой таблицы от этого не изменится,
>>> так что им не нравится?
>>
>> Вопрос звучал в ключе: а зачем вы будите анонсить весь allocation одним 
>> префиксом? Видимо вы где-то об этом им писали. 
> 
> А что, его нельзя анонсить одним префиксом? Для меня новость. 
> Всегда считал, что если можно агрегировать - то лучше агрегировать.
> Просто у большинства филиалов есть прямой линк с центром по нашей
> собственной первичной сети - так зачем сети таких филиалов анонсить
> отдельно?

Если есть connectivity зачем тогда ASN для филиалов?

>> Routing problems могут 
>> быть только если allocation равен minimum allocation size для этой /8 и 
>> кто-то из операторов таки решил не принимать префиксы длиннее min alloc 
>> size. 
> 
> Не очень понял идею. А если allocation не анонсить одним куском, эти
> операторы таки примут более длинные префиксы?

Приймут если анонсируемые префиксы не длинней min alloc size для своей 
/8.  Вообще говоря, я не слышал о том, что бы кто-то применял такой 
метод на практике. Однако близится час когда fullview перестанет 
помещатся в "non-XL" FIBs и кое-кто начнет придумывать как из этого 
положения выкритуться. Фильтрация more specifics один из таких вариантов.

>> Проблема в целом надумана и NCC прекрасно об этом знает. Они хотят
>> убедится, что об этом знаете вы ;)  Мы, кстати, перестраховались и свой 
>> partitioned allocation одним куском /14 не анонсируем - порезали на три 
>> /16 и кучу мелких анонсирующихся филиалами.
> 
> То есть тоже пошли against aggregation goal? И кому от этого лучше?

Прищлось искать компромис между conservation и aggregation.

-- 
Dmitry Kiselev
--- ifmail v.2.15dev5.4
 * Origin: Volia ISP News Site (2:5020/400)
SEEN-BY: 400/814 450/1024 461/43 640 465/11 469/999 4625/8 4641/444 5000/5000
SEEN-BY: 5006/1 5007/1 5010/70 5011/13 5012/46 5015/28 5019/26 5020/175 400
SEEN-BY: 5020/545 982 1354 1521 1909 1922 2238 4441 5021/29 5025/3 5026/14
SEEN-BY: 5027/12 5030/1080 5034/13 5035/38 5036/1 5042/18 5045/7 5049/1
SEEN-BY: 5051/15 5054/1 4 8 9 28 30 35 36 37 67 75 81 89 5060/88 5061/15
SEEN-BY: 5062/10 5063/3 5066/18 5075/5 5077/70 5084/9 5085/13 5093/57 5095/20
SEEN-BY: 5096/18 6001/10 6009/1

PATH: 5020/400 545 5054/1 37