Mikrotik DHCP server Option 82 нет что ли?

[sirmax]

Коллеги, не могу сообразить - что в Микротике  в DHCP  сервере option 82 отсутствует?

Или я что-то недогуглил? 


 

[SyJet]

Отсутствует

[sirmax]

1 час назад, SyJet сказал:

Отсутствует

Спасибо
Жаль, очень жаль =(

 

[seregaelcin]

В 17.06.2020 в 18:39, sirmax сказал:

Коллеги, не могу сообразить - что в Микротике  в DHCP  сервере option 82 отсутствует?

Или я что-то недогуглил? 


 

Недогуглили

/ip dhcp-server option
add code=82 name=option82 value=0x52

 

/ip dhcp-server
add add-arp=yes address-pool=Option82 disabled=no interface=<интерфейс> lease-time=1d name=Option82

 

/ip dhcp-server network
add address=192.168.1.0/24 dhcp-option=option82 dns-server=192.168.1.1 gateway=192.168.1.1 netmask=24

[LostSoul]

4 часа назад, seregaelcin сказал:

Недогуглили

ну вот вы догуглили.

как мне выдать ip-адрес  192.168.1.100   на устройство, запросившее его с 24 порта коммутатора, имеющего IP 10.0.0.6 ?

 

[seregaelcin]

во, вот с этого и нужно начинать

судя по всему параметры серквит и ремоте айди не изменяемые, наверно никак

[SyJet]

Если уж быть честным, микротик передает данные опции на внешний радиус. Не проверял, но пару лет назад это вроде как сделали

[sirmax]

С внешним радиусом все более менее ясно но хочется иметь работающую выдачу адресов без внешнего сервера. 

 

Похоже никак пока. Жаль.

[SyJet]

2 часа назад, sirmax сказал:

С внешним радиусом все более менее ясно но хочется иметь работающую выдачу адресов без внешнего сервера. 

 

Похоже никак пока. Жаль.

Конечно жаль :-) иначе радиуса не надо было бы

[LostSoul]

2 часа назад, SyJet сказал:

 Конечно жаль :-) иначе радиуса не надо было бы

Радиус есть и в виде пакета на микротик

[Saab95]

Когда меня спросили в другой теме о нечто подобном, я посоветовал перенастроить все коммутаторы на уникальный влан каждого абонентского порта. Сначала противились но после все же переделали и вопрос решился.

[LostSoul]

51 минуту назад, Saab95 сказал:

Когда меня спросили в другой теме о нечто подобном, я посоветовал перенастроить все коммутаторы на уникальный влан каждого абонентского порта. Сначала противились но после все же переделали и вопрос решился.

все эти адовы /32 маршруты чем потом собирать?

если рубить префиксами на железки то это неудобно чрезвычайно

 

ospf пробовал не понравилось

 

[sirmax]

12 часов назад, Saab95 сказал:

Когда меня спросили в другой теме о нечто подобном, я посоветовал перенастроить все коммутаторы на уникальный влан каждого абонентского порта. Сначала противились но после все же переделали и вопрос решился.

Что только не придумывают, только б  поддержку opt82 не впилить =)

Это может быть будет как-то работать если вы терменируете весь L2 в центре сети на 1-2 железках. И если у вас нормально построено все и есть возможность QinQ делать - иначе вланов всего 4к а портов в разы больше
 

 

16 часов назад, LostSoul сказал:

Радиус есть и в виде пакета на микротик

А вот так что б совсем одним микротиком обойтсь у Вас вышло?

У меня пока план в метароутере попробовать собрать но на уровне "потестить" пока что

 

[Saab95]

1 час назад, sirmax сказал:

Это может быть будет как-то работать если вы терменируете весь L2 в центре сети на 1-2 железках. И если у вас нормально построено все и есть возможность QinQ делать - иначе вланов всего 4к а портов в разы больше

А зачем тянуть все в центр? Ведь нормальные коммутаторы, которые могут QinQ собрать стоят дорого, всяко дороже микротика, особенно новой 2000 серии с кучей 10Г портов. И можно вполне нормально терминировать L2 на нем, не таща в центр.

 

12 часов назад, LostSoul сказал:

все эти адовы /32 маршруты чем потом собирать?

На микротике, естественно. Ничего плохого в OSPF нет, он нормально пережевывает 20-30 тысяч маршрутов даже на древних RB750 с малым объемом оперативной памяти.

Кроме всего если предположить что микротик в центре единый, или их несколько, то можно все забахать и статикой. В случае данной темы явно нет разницы что там влан на абонента или L3, все равно и в том, и в другом случае, все эти абоненты приземляться на этом же микротике и количество абонентских адресов будет неизменно.

[sirmax]

 

 

 

 

2 часа назад, Saab95 сказал:

А зачем тянуть все в центр? Ведь нормальные коммутаторы, которые могут QinQ собрать стоят дорого, всяко дороже микротика, особенно новой 2000 серии с кучей 10Г портов. И можно вполне нормально терминировать L2 на нем, не таща в центр.

 

Вам хоть блин кол на голове теши все равно будет терменировать на 100500 микротиках. Еще лучше каждому абоненту по микротику и терменировать прямо у него в квартире.  

Я такие схемы дом труба шатал. 

И не надо рассказывать что тут все кроме вас неправильно сеть строят - есть конкрентный вопрос по конкретной фиче в конкретном оборудовании.
Если вы не знаете ответ или  железка не позволяет - то не надо рассказывать про свои костыльные решения. Я хоть и не каждый день пишу но форум читаю регулярно, и Вас тоже. И все уже понял.

Еще раз специально для Сааб - в теме НЕ ОБУЖДАЕМ НИЧЕГО КРОМЕ ВОЗМОЖНОСТИ ВЫДАВАТЬ АДРЕСА НА ОСНОВЕ opt 82 НА ОДНОМ МИКРОТИКЕ БЕЗ ВНЕШНИХ ЖЕЛЕЗОК

(коллеги, извините за экспрессию, пригорело =) )




 

[starik-i-more]

20 часов назад, LostSoul сказал:

все эти адовы /32 маршруты чем потом собирать?

если рубить префиксами на железки то это неудобно чрезвычайно

 

ospf пробовал не понравилось

 

Я вот кстати недавно решил, что некрасиво загаживать OSPF кучей этих /32
и настроил их агрегацию через Area Ranges. 

Успел порадоваться.

 

Роутер проработал чуть меньше суток а потом завис. Не отвечал даже на ARP запросы.

Пришлось выключить Area Ranges и продолжить загаживать OSPF "этими адовыми /32"

 

Кто то сталкивался с подобным безобразием?

[SyJet]

35 минут назад, starik-i-more сказал:

Я вот кстати недавно решил, что некрасиво загаживать OSPF кучей этих /32
и настроил их агрегацию через Area Ranges. 

Успел порадоваться.

 

Роутер проработал чуть меньше суток а потом завис. Не отвечал даже на ARP запросы.

Пришлось выключить Area Ranges и продолжить загаживать OSPF "этими адовыми /32"

 

Кто то сталкивался с подобным безобразием?

После тысячи маршрутов - ibgp

[starik-i-more]

Маршрутов в OSPF было прим 450

После выключения Area Ranges их стало чуток больше - прим 500. Похоже что проблема именно в Area Ranges. Ну или в появлении второй area, к которой и применялся Area Ranges.

У кого то микроты висли при использовании multi area?

 

 

[Saab95]

В 22.06.2020 в 20:51, starik-i-more сказал:

У кого то микроты висли при использовании multi area?

У нас бывало и по 30-40 тысяч маршрутов в одной зоне, работало нормально. Городить кучу зон нужно лишь там, где есть выход на внешние сети, разбивать внутрянку по зонам нет никакого смысла. Никакие проблемы это не решит.

[SyJet]

5 часов назад, Saab95 сказал:

У нас бывало и по 30-40 тысяч маршрутов в одной зоне, работало нормально. Городить кучу зон нужно лишь там, где есть выход на внешние сети, разбивать внутрянку по зонам нет никакого смысла. Никакие проблемы это не решит.

После слов о 30-40тыс маршрутов - у любого должны отпасть иллюзии о вас. 

[Saab95]

Вообще количество маршрутов это не та штука, которая должна волновать администратора. Все работает и на маршруты никто не смотрит. Максимум зачем туда лазают, это когда есть сомнение нет ли дубликата адреса, тогда на одном роутере адрес выключают и смотрят, нет ли его в анонсах.

[starik-i-more]

В 25.06.2020 в 13:13, Saab95 сказал:

У нас бывало и по 30-40 тысяч маршрутов в одной зоне

Субъективно такое количество кажется чрезмерным. Тут вспоминается история про full view в OSPF.

 

Но возникает вопрос, какое количество маршрутов или LSA рекомендуют как best practice?

Я встречал какие-то рекомендации от Cisco (кажется из начала 2000-х) где расчет велся по количеству оперативки которое нужно для каждого маршрута. Естественно цифры там были по современным меркам совершенно смешные. Получается что сейчас для оценки допустимого количества маршрутов в OSPF вместо объема оперативки на роутере должны быть другие критерии.

[Saab95]

3 часа назад, starik-i-more сказал:

сейчас для оценки допустимого количества маршрутов в OSPF вместо объема оперативки на роутере должны быть другие критерии.

Вообще от оперативки никуда не делось, но и на RB750 старых где ее совсем мало, 30-40 тысяч маршрутов влезает.

Проблема тут может быть во времени загрузки маршрутов и цепочках. Самая распространенная ситуация тут при наличии длинных цепочек, медленных каналов связи и перезагружающемся роутере или оборванном канале.

 

Допустим есть роутер 1, 2 и 3. Между 1 и 2 по неким причинам обрывается связь, роутер 2 теряет маршруты и передает об этом роутеру 3, в итоге 2 и 3 не имеют маршрутов. Тут восстанавливается связь между 1 и 2 на маленькое время, роутер 2 начинает получать маршруты и связь обрывается. Роутер 3 получает все маршруты с роутера 2, но это не все маршруты сети. Поэтому на сети с большим количеством роутеров (даже не маршрутов), нужно особенно следить за исправностью каналов связи.

 

Есть опыт работы с сетями, где в OSPF порядка 2000-2500 роутеров в одной зоне. Иногда бывают интересные ситуации, но на цисках такую сеть вообще нельзя построить из-за ограничений в железе=)

[jffulcrum]

@starik-i-more В случае MT лимитом для OSPF будет являться одно ядро CPU, поскольку построение таблицы не параллелится. На первых CCR (1GHz) полярный лис наступал примерно при 3к маршрутов (в моменты перестроения топологии, разумеется). Добиться 30-40к маршрутов c МТ, вероятно, можно на x86 на железе уровня Xeon E5 1600-серии v3/4. Эмпирически предположу, что новый CCR2004 (когда его доведут до ума) потянет тысяч 10 маршрутов, может и 15.

[Saab95]

12 часов назад, jffulcrum сказал:

Добиться 30-40к маршрутов c МТ, вероятно, можно на x86 на железе уровня Xeon E5 1600-серии v3/4. Эмпирически предположу, что новый CCR2004 (когда его доведут до ума) потянет тысяч 10 маршрутов, может и 15.

Как же тогда BGP работает на CCR?

Я же писал что загрузка маршрутов при большом их количестве занимает длительное время, если это 2 штуки RB750, то порядка 20-30 секунд, если это CCR то около 10 секунд. Про ту проблему, которую тут указывают, можно узнать если на роутер цепляется порядка 200-300 ppp клиентов с получением этих маршрутов, ну и несколько устройств подключенных напрямую, в таких случаях CPU долгое время занят отдачей маршрутов подключенным роутерам.

 

На практике это особо не влияет на задержку и т.п.