2 dhcp в одному влані

[andr1y 4]

Хтось стикався з також проблемою - появився незрозумілий дхцп сервер в мережі і користувачі від мого получали ір, маску, шлюз, а від того лєвого тільки днс сервери, відповідно в них інтернет не працював. Поки я розібрався в проблемі, то пройшло кілька годин, бо не міг і подумати що таке буває - від одного сервера ір від другого днси. Користувачі по кілька разів перевантажували компи, але доки я не відключив порт на свічі з маком того dhcp проблема не зникла. А побачив я це все коли подивився trafshow на одному з користувачів там були постійні звернення 192.168.1.1 , 53 і дзвінки в техпідтримку типу - скайп працює а сторінки не вантажаться. Треба помаленьку переходити на авторизацію на порті, але все рівно цікаво як таке могло статися.

[NiTr0 583]

dhcdrop в помощь

[KaYot 3 606]

Вообще-то ситуация странная. Серверов может быть много, но ответ клиент всегда получает от одного, в полном объеме.

С этим можно и нужно бороться, блокируйте сторонние dhcp на ближайших умных свичах(длинки начиная с древних 3026 отлично с этим справляются).

[natiss 16]

DHCP - не для "паровозов" из мыльниц.

от dhcdrop пользы не много.

[max_m 92]

Находишь мак с которого идет левое дхцп и дропаеш на умных свичах и походу смотришь с какого сегмента приходит данный мак затем находиш злоумышленника и даешь по шапке . Что то подобное у нас было только у нас авторизация по ПППоЕ все поделено на сегменты и из одного неуправляемого сегмента у клиентов возникли траблы, авторизация проходит но выйти никуда не может оказалось что у одного из клиентов настроен дхцп который как не странно перебивал ПППоЕ все запросы начинали уходить по Ип полученному по ДХЦП вместо ПППоЕ. Проблему временно решали отключением на интерфейсе у рабочего клиента протокола TCP/IP пока не нашли проблему благо дело сегмент не большой состоял из 3-х мыльниц, так как мак ДХЦП был известен просто меняли неуправляемую мыльницу на RB 250 до тех пор пока на одном из портов не обнаружили мак ДХЦП, потом пришли настучали по шапке пригрозили расторжением договора и все .

[natiss 16]

 потом пришли настучали по шапке пригрозили расторжением договора и все . 

а может сразу всех, чтобы и не мучаться?

Кстати , никто не сталкивал с тем, что мыльницы могут зависать так, что не пропускают dhcp, хотя dns прекрасно работает.

[KaYot 3 606]

Бывало такое, броадкаст в любой форме переставал иногда ходить.

[natiss 16]

Бывало такое, броадкаст в любой форме переставал иногда ходить.

это печально

[max_m 92]

 потом пришли настучали по шапке пригрозили расторжением договора и все . 

а может сразу всех, чтобы и не мучаться?

Кстати , никто не сталкивал с тем, что мыльницы могут зависать так, что не пропускают dhcp, хотя dns прекрасно работает.

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

По поводу dhcp не встречал такого, может из-за того что пользуемся TP-Link TL-SF1008 практически безглючные устройства, есть пару недостатков, к примеру этой зимой столкнулись с тем что около 6 свичей замерзло пришлось отогревать одеть чехол и все заработало ...

[KaYot 3 606]

 потом пришли настучали по шапке пригрозили расторжением договора и все . 

а может сразу всех, чтобы и не мучаться?

Кстати , никто не сталкивал с тем, что мыльницы могут зависать так, что не пропускают dhcp, хотя dns прекрасно работает.

А в чем проблема? Если клиент самовольно натыкал у себя на устройстве всякой фигни не спросивши не прочитав хотя бы инструкцию по настройке своего девайса, включил в порт Lan вместо WAN приходящую часть со стороны провайдера, в сеть флудит всякой пакостью, а потом звонит в ТП с претензией что у него не работает инет, вопрос как поступать с таким клиентом ?

А никак. Клиент не виноват что у вас не хватает денег на самый простой свич с функцией dhcp screening или поддержкой acl.

[max_m 92]

 потом пришли настучали по шапке пригрозили расторжением договора и все . 

а может сразу всех, чтобы и не мучаться?

Кстати , никто не сталкивал с тем, что мыльницы могут зависать так, что не пропускают dhcp, хотя dns прекрасно работает.

А в чем проблема? Если клиент самовольно натыкал у себя на устройстве всякой фигни не спросивши не прочитав хотя бы инструкцию по настройке своего девайса, включил в порт Lan вместо WAN приходящую часть со стороны провайдера, в сеть флудит всякой пакостью, а потом звонит в ТП с претензией что у него не работает инет, вопрос как поступать с таким клиентом ?

А никак. Клиент не виноват что у вас не хватает денег на самый простой свич с функцией dhcp screening или поддержкой acl.

Виноват, в том что не читает инструкций.

В частном секторе не реально сразу все завести на управляемом железе как экономически так практически. Со времемне когда появятся клиенты окупят хоть половину затрат на оборудование тогда можно будет заложить в проэкт затрат управляемое железо, а на пока так, пришла оптика в улицу в ящике RB250 на нем acl (Netbios drop, DHCP drop) сегментирование, а дальше от 2-х до 3-х мыльниц в ветку паровозиком. Других вариантов пока нет, либо посоветуйте что из управляемого оборудования портов на 8 есть и максимальным потребление питания до 6W и малыми габаритами и ценой до 700 гр. TP-link

TL-SL2210 можно не предлогать не подходит не габаритами не питанием при старте жрет много не функционалом.

[NiTr0 583]

dhcdrop прекрасно справляется со своими задачами. Ложит глюкнувший (срущий в wan своими dhcp, как wl-520gc к примеру после месяца аптайма) или криво включеный роутер, или выдает ип умника, расшарившего туннельное подключение на LAN сетевуху. Да, не панацея, но все же полезная вещь.

[Гайджин 574]

прикольность случая как раз том, что произошло то, чего быть не может.

[natiss 16]

 

TL-SL2210 можно не предлогать не подходит не габаритами не питанием при старте жрет много не функционалом.

 

верно TL-SL2210 - не коммутатор, там и фильтров то никаких нет

[natiss 16]

dhcdrop прекрасно справляется со своими задачами. Ложит глюкнувший (срущий в wan своими dhcp, как wl-520gc к примеру после месяца аптайма) или криво включеный роутер, или выдает ип умника, расшарившего туннельное подключение на LAN сетевуху. Да, не панацея, но все же полезная вещь.

Вы оптимист.

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

А если у вас порвался паровоз на какое-то время и все абоненты получили настройки от левого сервера? Да, dhcdrop умеет форсировать, но лучше бы он этого не умел. При использовании dhcdrop вам надо фильтровать его на сервере. Думаете указали "хорошие" маки и все хорошо?

[NiTr0 583]

прикольность случая как раз том, что произошло то, чего быть не может.

Я что-то подобное тоже к слову наблюдал. Если не ошибаюсь, винда шлет сначала DHCP Discover, получает DHCP offer с ип, адресом шлюза и т.д., потом - шлет повторно запрос интересующих опций типа днс, маршрутов и т.п.

 

верно TL-SL2210 - не коммутатор, там и фильтров то никаких нет

Коммутатор, коммутатор. Да, без ACL, без SNMP, без прочих плюшек - но таки коммутатор, не хаб, и даже управляемый (хоть и кастрированный).

 

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

Скрипт раз в N минут. Абону ведь не понравится, что его роутер постоянно ребутится...

 

А если у вас порвался паровоз на какое-то время и все абоненты получили настройки от левого сервера?

Ничего страшного, потом получат от правильного. В любом случае, лучше, чем вообще без каких-либо действий, не?

 

При использовании dhcdrop вам надо фильтровать его на сервере. Думаете указали "хорошие" маки и все хорошо?

Достаточно выдавать ип только известным хостам. И все.

[Гайджин 574]

прикольность случая как раз том, что произошло то, чего быть не может.

Я что-то подобное тоже к слову наблюдал. Если не ошибаюсь, винда шлет сначала DHCP Discover, получает DHCP offer с ип, адресом шлюза и т.д., потом - шлет повторно запрос интересующих опций типа днс, маршрутов и т.п.

Вы бы на досуге с RFC-2131 и RFC-2132 ознакомились бы.

[Ромка 565]

dhcdrop в помощь

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

dhcdrop прекрасно справляется со своими задачами. Ложит глюкнувший (срущий в wan своими dhcp, как wl-520gc к примеру после месяца аптайма) или криво включеный роутер, или выдает ип умника, расшарившего туннельное подключение на LAN сетевуху. Да, не панацея, но все же полезная вещь.

Ещё бывает что клиент пробует использовать роутер в качестве WiFi точки доступа (кабель от провайдера в Lan порт), при этом не отключив как правило по умолчанию включенный DHCP сервер на Lan порту.

[natiss 16]

Коммутатор, коммутатор. Да, без ACL, без SNMP, без прочих плюшек - но таки коммутатор, не хаб, и даже управляемый (хоть и кастрированный).

Хаха. Без снмп... Ото насмешили. Он такой же управляемый, как кто-то "проффесор". Мыльница на 8 портов + сфп очъко -не более!

Это недоразумение даже не показывает mac-адреса.

 

Скрипт раз в N минут. Абону ведь не понравится, что его роутер постоянно ребутится...

Да хоть каждую минуту. Скрипт быстренько получил весь пул, роутер мгновенно перегрузился и 60-70% времени спокойно делает свое черное дело.

Ничего страшного, потом получат от правильного. В любом случае, лучше, чем вообще без каких-либо действий, не?

Да ничего страшного, если вообще никогда не получат )) Ну подумаешь, истерика будет, делов то

 

Достаточно выдавать ип только известным хостам. И все.

Смело. Но негуманно.

[antondemidov 0]

DHCP Snooping на управляемых. А при цепочке из мыльниц dhcp - это дело смелое, да.

[NiTr0 583]

Хаха. Без снмп... Ото насмешили. Он такой же управляемый, как кто-то "проффесор". Мыльница на 8 портов + сфп очъко -не более!

Это недоразумение даже не показывает mac-адреса.

Показывает маки, если правильно попросить. С извращением, да, но показывает.

+ умеет мониторить/тушить порты, умеет вланы в полном объеме (конфигурируемые на лету удаленно), и т.д. - достаточно, чтобы называть его управляемым коммутатором, не?

 

Да хоть каждую минуту. Скрипт быстренько получил весь пул, роутер мгновенно перегрузился и 60-70% времени спокойно делает свое черное дело.

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

Не говоря уже о том, что роутер (ввиду дохлого проца) гораздо позже отсылает ответ дхцп, и в 99% случаев абоны не замечают, что кто-то еще гадит.

 

Да ничего страшного, если вообще никогда не получат )) Ну подумаешь, истерика будет, делов то

Ваши предложения, как решить ситуацию без полной замены оборудования? Или просто "баба Яга против"?

 

Достаточно выдавать ип только известным хостам. И все.

Смело. Но негуманно.

Негуманно выдавать ип всем подряд. Ибо накой - неведомо, лишний головняк и себе, и клиентам.

[natiss 16]

Показывает маки, если правильно попросить. С извращением, да, но показывает.

Буду признателен, если поделитесь этим откровением

+ умеет мониторить/тушить порты, умеет вланы в полном объеме (конфигурируемые на лету удаленно), и т.д. - достаточно, чтобы называть его управляемым коммутатором, не?

в паровозе он склонен к зависанию, поэтому выключать порты - игра в орлянку

я бы не сказал, что В ПОЛНОМ ОБЪЕМЕ, тем более реализация веб-интерфеса... это кошмар, я такого больше нигде не видел, вланы классифицируются не по VID а по номеру на коммутаторе

 

Мгновенно, да... Минута-полторы

Я тоже так думал, пока не столкнулся с таким роутером в живую. Перегрузка - потеря 2-3 пакетов в при стандартном ping. Возможно он "мягко" перегружает сервис. Причем, собака, раздавал адреса из рабочего диапазона с неправильным шлюзом.

. На это время ни вафля на роутере не работает, ни траффик через него не бегает. К слову, линки тоже несколько раз моргают.

Теоретически то так, но кто сказал, что он является рабочим шлюзом абонента? Просто подключен к сеточке....

Не говоря уже о том, что роутер (ввиду дохлого проца) гораздо позже отсылает ответ дхцп, и в 99% случаев абоны не замечают, что кто-то еще гадит

Это теория. А практика "паровоза" такова, что "задние вагоны" скорее получат адрес от такого роутера чем от "тягача".

Ваши предложения, как решить ситуацию без полной замены оборудования? Или просто "баба Яга против"?

Да никак. Продолжать использовать dhcdrop, но быть осторожнее в плане понимания его, как панацея.

 

Негуманно выдавать ип всем подряд. Ибо накой - неведомо, лишний головняк и себе, и клиентам.

Но и выдавливать из абонента его MAC-адрес, или заставлять его настраивать TCP/IP вручную не гуманно. Согласны?

Помоему с точки зрения клиента гораздо меньше "головняка", если нет никаких привязок.

Понятно, что в идеале это Fiber Directly To Ass, VLAN per user и option 69 , но в паровозе всё печальнее...

[NiTr0 583]

Буду признателен, если поделитесь этим откровением

dynamic binding

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

 

в паровозе он склонен к зависанию, поэтому выключать порты - игра в орлянку

я бы не сказал, что В ПОЛНОМ ОБЪЕМЕ, тем более реализация веб-интерфеса... это кошмар, я такого больше нигде не видел, вланы классифицируются не по VID а по номеру на коммутаторе

А никто и не говорит об объеме. Много чего не поддерживает, но управляется кое-как - факт. Да и работает при эдак 100 клиентах в сегменте относительно стабильно.

 

Я тоже так думал, пока не столкнулся с таким роутером в живую. Перегрузка - потеря 2-3 пакетов в при стандартном ping. Возможно он "мягко" перегружает сервис. Причем, собака, раздавал адреса из рабочего диапазона с неправильным шлюзом.

Не встречал еще такого.

 

Теоретически то так, но кто сказал, что он является рабочим шлюзом абонента? Просто подключен к сеточке....

Ну всякое бывает. Но обычно желающих просто что-то в сетку ткнуть, лишь бы стояло и светилось - мало.

 

Это теория. А практика "паровоза" такова, что "задние вагоны" скорее получат адрес от такого роутера чем от "тягача".

Не замечал. Хотя ессно медных длинных "гирлянд" уже давно нет.

 

Да никак. Продолжать использовать dhcdrop, но быть осторожнее в плане понимания его, как панацея.

Дык никто и не говорил о панацее. Но выявлять источники беспокойства позволяет.

 

Но и выдавливать из абонента его MAC-адрес, или заставлять его настраивать TCP/IP вручную не гуманно. Согласны?

Смена сетевух - раз в N месяцев/лет в зависимости от "везучести". Хотя можно конечно выдавать из другой подсети адреса тем, у кого левый мак, аутентифицировать их принудительно по логину-паролю и пускать в инет лишь после этого - но это может создать и неудобства, а то и при некоторых ошибках стать серьезной дырой...

 

Помоему с точки зрения клиента гораздо меньше "головняка", если нет никаких привязок.

Понятно, что в идеале это Fiber Directly To Ass, VLAN per user и option 69 , но в паровозе всё печальнее...

Ну если нельзя аутентифицировать абонента по порту - тогда нужно его аутентифицировать по нескольким другим признакам. Одного логина-пароля причем недостаточно ИМХО (легко увести, легко пользоваться всем колхозом и т.п.), как и одного мака.

[muff 114]

Кстати, инфа о настройке и использовании dhcpdrop.

[natiss 16]

Раз пошла такая "пьянка"

http://myfreebsd.ru/network/dhcdrop-i-legalnyj-dhcp-server

 

А смена сетевух по-любому проблема. Как ни крути...