LostSoul Опубликовано 11 декабря, 2018 · Жалоба В разных местах имею следующий дизайн сети. Стоит микротик, на нем два 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 ) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jffulcrum Опубликовано 12 декабря, 2018 · Жалоба authoritative - NO попробуйте Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nkusnetsov Опубликовано 13 декабря, 2018 · Жалоба Вероятно у вас vlan не изолированы. Как минимум, на самом микротике. При правильной настройке vlan и dhcp клиент никак не сможет пролонгировать адрес из другой подсети. Исключение иногда составляет Win-10. Она сразу быстро не получив ответа от dhcp-сервера пытается самовольно использовать прежний ip-адрес. Но тогда на сервере продления не происходит. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
LostSoul Опубликовано 14 декабря, 2018 · Жалоба В 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. То есть это никакая не плохая изоляция Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vurd Опубликовано 14 декабря, 2018 · Жалоба время лизы уменьшайте, иначе никак в таких условиях. но вообще. чисто по механике пролонгация осуществляется через юникаст запрос к серверу, если его дропнуть, то по идеи продления не будет. вы поснифайте с клиента, станет понятнее что можно сделать Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
LostSoul Опубликовано 14 декабря, 2018 · Жалоба 16 минут назад, vurd сказал: время лизы уменьшайте, иначе никак в таких условиях. это вообще не вариант. работа клиента не должна прерыватся ни на секунду. не ставить же лиз 2-3 секунды? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vurd Опубликовано 15 декабря, 2018 · Жалоба 8 часов назад, LostSoul сказал: это вообще не вариант. работа клиента не должна прерыватся ни на секунду. не ставить же лиз 2-3 секунды? Второй вариант проигнорировали? И у вас какой-то кривой дизайн, если клиенты скачут с влана в влан, имхо. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nkusnetsov Опубликовано 15 декабря, 2018 (изменено) · Жалоба @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 Изменено 15 декабря, 2018 пользователем nkusnetsov Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
LostSoul Опубликовано 15 декабря, 2018 · Жалоба 8 часов назад, nkusnetsov сказал: , покажите вывод: Вы конечно извините, но мне не требуется техническая поддержка в подобном виде. В моих конфигурациях как надо. У микротика имеется явная проблема в работе dhcp , связанная с этим моментом. Интересует ответ от человека, уже нашедшего готовое решение. А не желающие искать бревно в моем глазу. Если когда-то появится лишнее время то соберу лабу и дам к ней доступ желающим по данному вопросу. Сейчас на это нету времени. Проще dhcp по разным микротикам раскидать и жить спокойно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
McSea Опубликовано 16 декабря, 2018 (изменено) · Жалоба On 12/15/2018 at 9:50 PM, LostSoul said: Интересует ответ от человека, уже нашедшего готовое решение. Так откуда готовое решение возьмется, если такой проблемы ни у кого нет ? Изменено 16 декабря, 2018 пользователем McSea Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pingz Опубликовано 17 декабря, 2018 · Жалоба @LostSoul Возможно вы не умеете настраивать микротик? З.Ы. 3-4 сервера DHCP живут более года на RB1100 все как часы. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
LostSoul Опубликовано 17 декабря, 2018 · Жалоба 17 минут назад, pingz сказал: З.Ы. 3-4 сервера DHCP живут более года на RB1100 все как часы. У меня их несколько сотен штук живет "как часы". Если вы не озадачивались этой ситуаций ( сохранение ip при смене vlan ) , это не значит что ее нету. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pingz Опубликовано 17 декабря, 2018 · Жалоба @LostSoul Ну тогда дамп в студию! З.Ы. когда я, что-то не понимаю как работает останавливаюсь и собираю стенд для дампа, да долго, да не интересно, но потом все встает на свои места. З.З.Ы. серебряной пули не существует, это по секрету. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nkusnetsov Опубликовано 17 декабря, 2018 (изменено) · Жалоба В 90% случаев, проблема микротика находится с метре от экрана и пялится в winbox. Часто вижу конфиги админов, вешающих IP и DHCP на slave-интерфейс со словами "работает же". При том, что микротик в логах честно пишет, что-то типа "temporary moving client ether1 from slave to master port bridge". А если микротик не смог исправить ошибку админа за него, начинаются вопли "ай, бага-бага! я всё правильно делаю, а не работает!" Изменено 17 декабря, 2018 пользователем nkusnetsov Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
LostSoul Опубликовано 17 декабря, 2018 · Жалоба 5 минут назад, nkusnetsov сказал: В 90% случаев, проблема микротика находится с метре от экрана и пялится в winbox. Это не мой случай. Обучен и читать, и думать. И как работает ядро линукс и все его подсистемы тоже хорошо себе представляю. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nkusnetsov Опубликовано 17 декабря, 2018 · Жалоба @LostSoul , мне действительно интересна причина такого поведения устройства. Если не нуждаетесь в техпомощи, покажите проблемный вариант, чтобы другие знали. У меня не на железе, не на стенде описанная Вами ситуация не воспроизводится. При перемещении клиента в другой vlan адреса назначаются корректно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
maxkst Опубликовано 17 декабря, 2018 · Жалоба Я сталкивался со странным поведением DHCP. У вас DHCP сервер на самом влане, или на бридже, к которому этот вилан прицеплен? в моем случае бага была, на нескольких последних версиях. Лечилась только глубоким даунгрейдом или последней бета-версией. активируйте DHCP логи, по ним будет легко найти косяк, или баг, если такой имеется. Насчет юникаст-бродкаст к серверу, там тоже все не так просто, почитайте RFC и гляньте на фактические логи DHCP. Лично я был удивлен увидеть юникаст-юникаст-бродкаст комбо от клиента, когда юникаст недоступен в силу каких-то причин. А если в сетке релей, то там свои тонкости будут Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
tray4 Опубликовано 20 декабря, 2018 · Жалоба это явно какая то проблема не связанная с микротиком. у себя иногда делал подобное. никогда проблем не замечал. вот сейчас проверил. переткнул ноутбук из рабочего влана во влан гостевого вайфая, все работает ожидаемо, адрес переполучил из верной подсети. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
EugeneTV Опубликовано 20 декабря, 2018 · Жалоба Подобный случай видел только один раз, когда клиент прописан как static lease и в настройках лизы не указан DHCP сервер. Тогда да, микрот выдаст этот статик клиенту с нужным маком в любой физический или виртуальный интерфейс, независимо от привязанному к этому интерфейсу DHCP сервера. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 9 января, 2019 · Жалоба Вы не написали что подключено после микротика, если у вас 2 влана, то явно на каких-то устройствах дальше они разбираются на порты пользователей, возможно где-то там вланы объединяются, поэтому все и работает. Подобное встречалось на разных wi-fi точках, коммутаторах и прочих устройств. Там либо просто все данные объединялись, или работало только в одну сторону, или для определенных маков и т.п. Найти проблему оказывалось сложно, т.к. с одного и того же микротика в пределах влана данные не передавались в другой влан. Только физическое отключение устройств и тестовые переключения абонентов позволяли найти проблемное устройство или место сети. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...