Jump to content
Калькуляторы

DHCP - проверка перед выдачей

Замечена такая проблема: роутеры у некоторых клиентов перестают слать DHCP запросы. В основном Длинки, Тплинки и прочий шлак.

Тоесть клиент получает публичный адрес от нас с таймаутом 20 минут, и периодически подтверждает его, вроде каждые 10 минут. 

Месяцами работает, и вдруг ни с того ни с сего перестает подтверждать, но продолжает использовать (лечится ребутом этого клиента).

DHCP сервер походу живет собственной жизнью, и ваще не в курсе, что этот адрес нифига не освободился, и начинает раздавать его направо и налево, соответственно - конфликт и ниче не работает как минимум у одного из клиентов, как правило у второго.

В АРП таблице - два мака на одном адресе, печаль. Есть пара мыслей, как это лечить, но хотелось бы все варианты рассмотреть. Кто как решает такую проблему?

Share this post


Link to post
Share on other sites

Conflict Detection поставили у DHCP ?

 

Share this post


Link to post
Share on other sites
38 минут назад, morf сказал:

Conflict Detection поставили у DHCP ?

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

Share this post


Link to post
Share on other sites
24 минуты назад, maxkst сказал:

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

Был там такой косяк, но у ПК подключенных напрямую, причем с установленным Avast. Conflict Detection - в итоге решило эту проблему.

Share this post


Link to post
Share on other sites
46 минут назад, morf сказал:

Был там такой косяк, но у ПК подключенных напрямую, причем с установленным Avast. Conflict Detection - в итоге решило эту проблему.

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

Интересно, как CONFLICT DETECTION проверяет, используется адрес или нет, если на "кривом" клиенте все закрыто извне

Вопрос по клиентам пока остается открытым - сфигали они перестают лизу подтверждать?

Share this post


Link to post
Share on other sites
46 минут назад, maxkst сказал:

Интересно, как CONFLICT DETECTION проверяет

6.44

*) dhcpv4-server - use ARP for conflict detection;

 

Фэйспалм. А чем они до этого проверяли, пингом чтоли? 

Share this post


Link to post
Share on other sites
В 22.04.2020 в 18:14, maxkst сказал:

Есть пара мыслей, как это лечить, но хотелось бы все варианты рассмотреть. Кто как решает такую проблему?

Влан на пользователя и жесткая привязка IP адреса к этому влану.

Share this post


Link to post
Share on other sites
35 минут назад, Saab95 сказал:

Влан на пользователя и жесткая привязка IP адреса к этому влану.

Микросегментация руками) прикольно

Share this post


Link to post
Share on other sites
42 минуты назад, Saab95 сказал:

жесткая привязка IP адреса к этому влану

Любопытно, как это выглядит на микротике?

Share this post


Link to post
Share on other sites

@RN3DCX  1-2к строк конфиг со скриптами перезапуска интерфейсов.

 

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

 

@maxkst  вариант для ленивых ipoe + радиус. Cisco или juniper, за лень нужно платить.

Share this post


Link to post
Share on other sites
В 23.04.2020 в 19:44, fractal сказал:

Микросегментация руками) прикольно

Почему руками? На коммутаторах каждый порт абонента добавляется во влан, на микротике заводятся все вланы.

 

В 23.04.2020 в 19:51, RN3DCX сказал:

Любопытно, как это выглядит на микротике?

 

/interface vlan
add arp=reply-only interface=bridge_vlan name=vlan_222 vlan-id=222

/ip address
add address=10.10.3.1/32 network=10.10.3.222 interface=vlan_222

/ip pool
add name=dhcp_pool_222 ranges=10.10.3.222

/ip dhcp-server
add add-arp=yes address-pool=dhcp_pool_222 disabled=no interface=vlan_222 lease-time=5m name=dhcp_222

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

 

Кроме всего микротик позволяет агрегировать порты без всяких устаревших технологий. Допустим есть шина или звезда из коммутаторов, на каждом коммутаторе настроены вланы абонентов, и можно дотянуть до микротика начало шины, конец шины, можно из серединки там взять пару каналов, далее подключить все эти каналы в порты микротика, добавить эти порты в бридж, заблокировать пропуск трафика между портами бриджа и вуаля - все каналы используются почти равномерно, никакие там STP вообще не нужны.

 

Share this post


Link to post
Share on other sites
2 минуты назад, Saab95 сказал:

Почему руками? На коммутаторах каждый порт абонента добавляется во влан, на микротике заводятся все вланы.

а если за портом 200 клиентов? а если таких точек 500? да это убиться можно, тут либо нормальный конфигуратор из дешевых, либо дорогие штуки которые галочкой все это делают

Share this post


Link to post
Share on other sites

Это как за портом 200 клиентов? Дальше цепочка из тупых хабов что ли? =)

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

Share this post


Link to post
Share on other sites
7 часов назад, Saab95 сказал:

Это как за портом 200 клиентов? Дальше цепочка из тупых хабов что ли? =)

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

Микротик, а за ним к примеру 4 по 48 портовых свитча в одном домене, так что не придумывайте, как в этом случае быть? Или вы пачку микротов вешает? Кстати что Вы за провайдер то? И в каком городе? 

Share this post


Link to post
Share on other sites

И что мешает на этих 48 портовых свичах настроить влан на порт? Потом на микротике заведете 192 влана. Далее на микротике повесите 192 DHCP сервера, а далее уже каждый клиент окажется в своем влане.

Share this post


Link to post
Share on other sites
6 часов назад, Saab95 сказал:

Далее на микротике повесите 192 DHCP сервера

С одним общим пулом адресов?

Share this post


Link to post
Share on other sites

@maxkst я же выше писал 1-2к строк конфига 

З.ы. все статикой записать. Создать шаблон и это шаблон. Сеть сегментировать и использовать один и тот же шаблон.

Share this post


Link to post
Share on other sites
1 час назад, pingz сказал:

З.ы. все статикой записать. Создать шаблон и это шаблон. Сеть сегментировать и использовать один и тот же шаблон.

то есть DHCP клиенты есть, но все получают статику? динамических адресов вообще нет?

 

Я нахожу это логичным. Динамические адреса были нужны, когда в интернет выходили быстрыми перебежками. При безлимитных тарифах динамика вообще не актуальна, имхо

Share this post


Link to post
Share on other sites
1 минуту назад, pingz сказал:

по логике Саба так 

А есть другая логика?

Share this post


Link to post
Share on other sites

@maxkst asr, mx, se, у huawei скорей всего есть ipoe + радиус.

Либо тазик.

 

 

Share this post


Link to post
Share on other sites
1 час назад, pingz сказал:

asr, mx, se, у huawei скорей всего есть ipoe + радиус.

Либо тазик.

Я спросил про логику использования динамических адресов - а вы мне список оборудования

Share this post


Link to post
Share on other sites

@maxkst Я думал ты в курсе, ну поехали.

Саб тут как местный мем со своей историей и правдой.

 

В данный момент вам нужен vlan per user c динамической раздачей адресов.

Есть "технология" IPoE это скорее костыль от вендора, на сколько мне известно в RFC его нет. 

Каждый вендор как хочет так и собирает свой софт.

 

В mikrotik нет из коробки IPoE в привычном понимании.

Привычное понимание это, когда прилетает пакет от пользователя на коробку не важно qnq или vlan коробка создает интерфейс спрашивает у радиуса, какой IP для этого мака выдать. Радиус выдает все атрибуты ip, адрес шлюза, шейпер на коробку, фильтр. 

Все работает в автоматическом режиме. В биллинге есть записи какой ip был выдан клиенту и т.д.

 

 

В логике Саба: "Нужно больше микротиков"  если че он процитирует это сообщение и скажет так все и есть. 

 

Т.е. Если у вас 1к клиентов и при статическом конфиге допустим выходит 8 строк конфига 1 пользователя выходит 8к статических записей на коробке прописывает следующий шлюз.

Следующий шлюз угадайте кто? 

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

Следующий шлюз угадайте кто?

Правильно микротик с натом. 

 

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

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

Share this post


Link to post
Share on other sites

/ip dhcp-server set conflict-detection=yes number=0

А что значит этот number?

Share this post


Link to post
Share on other sites
В 30.04.2020 в 23:46, pingz сказал:

Саб тут как местный мем со своей историей и правдой.

Я походу стану следующим. Мы умудрились каким-то чудом довольно большую FTTH сетку построить на MT и до сих пор пока не налажали по-крупному.  Видимо потому что у нас тоже много микротиков, CTO решает проблемы путем разделения каждой железки/сервиса на две/два MT. Крутые инфесторы заметили наше поделие, и их не остановило отсутствие именитых брендов у нас в сетке от подписания серьезного контракта. 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now