Перейти к содержимому
Калькуляторы

Два dhcp-server в разных vlan

В разных местах имею следующий дизайн сети.

Стоит микротик, на нем два vlan , в каждом vlan свой dhcp-server с своим пулом адресов.

Ну например - гостевой и "для сотрудников".

Клиент переключается с одного vlan в другой... и без проблем получает от mikrotik dhcp пролонгацию адреса из пула, назначенного на другой интерфейс.

То есть к примеру на vlan10 пул 192.168.10.128-192.168.10.254  , vlan20 - пул 192.168.20.128 - 192.168.20.254

клиент в vlan10 получает 192.168.10.254 , переключает кабель в vlan20 и получает пролонгацию на адрес 192.168.10.254 к данному влан не относящемуся.

Если при этом сделать dhcp renew на клиенте, то от микротика приходит DHCP NAK.

 

Кто знает как бороться с такой фигней?

Ну кроме как жестко зафайрволить . ( клиент в этом случае будет тупить с таймаутами ответа dhcp )

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Вероятно у вас vlan не изолированы. Как минимум, на самом микротике. При правильной настройке vlan и dhcp клиент никак не сможет пролонгировать адрес из другой подсети.
Исключение иногда составляет Win-10. Она сразу быстро не получив ответа от dhcp-сервера пытается самовольно использовать прежний ip-адрес. Но тогда на сервере продления не происходит.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
В 13.12.2018 в 08:47, nkusnetsov сказал:

Вероятно у вас vlan не изолированы. Как минимум, на самом микротике. При правильной настройке vlan и dhcp клиент никак не сможет пролонгировать адрес из другой подсети.
Исключение иногда составляет Win-10. Она сразу быстро не получив ответа от dhcp-сервера пытается самовольно использовать прежний ip-адрес. Но тогда на сервере продления не происходит.

100% надежно изолированы.

я вас уверяю, что происходит именно то, о чём я говорю.

в списке dhcp leases видно конкретно прям mac address , ip address ,  dhcpserver , Active Mac Address , Active Ip Address.

И видно , что указанный mac засветился в другом dhcp server , с другим Active IP.

 

То есть это никакая не плохая изоляция

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

время лизы уменьшайте, иначе никак в таких условиях.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
16 минут назад, vurd сказал:

время лизы уменьшайте, иначе никак в таких условиях.

это вообще не вариант.

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

не ставить же лиз 2-3 секунды?

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
8 часов назад, LostSoul сказал:

это вообще не вариант.

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

не ставить же лиз 2-3 секунды?

 

Второй вариант проигнорировали?

И у вас какой-то кривой дизайн, если клиенты скачут с влана в влан, имхо.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

@LostSoul , покажите вывод:
1) /ip ad exp

2) /ip arp pr
3) /int vlan exp
4) /int br exp
5) /ip dhcp-s exp

либо supout.rif в личку

Ну и на всякий случай проверьте, не возник ли где-то на свитче dhcp-relay

Изменено пользователем nkusnetsov

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
8 часов назад, nkusnetsov сказал:

 , покажите вывод:

Вы конечно извините, но мне не требуется техническая поддержка в подобном виде.

В моих конфигурациях как надо.

У микротика имеется явная проблема в работе dhcp , связанная с этим моментом.

Интересует ответ от человека, уже нашедшего готовое решение.

А не желающие искать бревно в моем глазу.

 

Если когда-то появится лишнее время то соберу лабу и дам к ней доступ желающим по данному вопросу.

Сейчас на это нету времени.

Проще dhcp по разным микротикам раскидать и жить спокойно.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
On 12/15/2018 at 9:50 PM, LostSoul said:

Интересует ответ от человека, уже нашедшего готовое решение.

Так откуда готовое решение возьмется, если такой проблемы ни у кого нет ?

 

Изменено пользователем McSea

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

@LostSoul  Возможно вы не умеете настраивать микротик? 

 

З.Ы. 3-4 сервера DHCP живут более года на RB1100 все как часы. 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
17 минут назад, pingz сказал:

З.Ы. 3-4 сервера DHCP живут более года на RB1100 все как часы. 

У меня их несколько сотен штук живет "как часы".

Если вы не озадачивались этой ситуаций ( сохранение ip при смене vlan ) , это не значит что ее нету.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

@LostSoul 

Ну тогда дамп в студию! 

З.Ы. когда я, что-то не понимаю как работает останавливаюсь и собираю стенд для дампа, да долго, да не интересно, но потом все встает на свои места. 

З.З.Ы. серебряной пули не существует, это по секрету. 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В 90% случаев, проблема микротика находится с метре от экрана и пялится в winbox.
Часто вижу конфиги админов, вешающих IP и DHCP на slave-интерфейс со словами "работает же". При том, что микротик в логах честно пишет, что-то типа "temporary moving client ether1 from slave to master port bridge". А если микротик не смог исправить ошибку админа за него, начинаются вопли "ай, бага-бага! я всё правильно делаю, а не работает!"

Изменено пользователем nkusnetsov

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
5 минут назад, nkusnetsov сказал:

В 90% случаев, проблема микротика находится с метре от экрана и пялится в winbox.

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

@LostSoul , мне действительно интересна причина такого поведения устройства. Если не  нуждаетесь в техпомощи, покажите проблемный вариант, чтобы другие знали.
У меня не на железе, не на стенде описанная Вами ситуация не воспроизводится. При перемещении клиента в другой vlan адреса назначаются корректно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Я сталкивался со странным поведением DHCP. У вас DHCP сервер на самом влане, или на бридже, к которому этот вилан прицеплен? в моем случае бага была, на нескольких последних версиях. Лечилась только глубоким даунгрейдом или последней бета-версией.

 

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

Лично я был удивлен увидеть юникаст-юникаст-бродкаст комбо от клиента, когда юникаст недоступен в силу каких-то причин. А если в сетке релей, то там свои тонкости будут

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

это явно какая то проблема не связанная с микротиком.

 

у себя иногда делал подобное. никогда проблем не замечал.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

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

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Войти

Уже зарегистрированы? Войдите здесь.

Войти сейчас