isc dhcp и 2 подсети

10.128.0.0/23

В целом «поздравляю шарик ты балбес». Причем дважды. Вместо того что бы навести порядок в двух сотнях машин пытаешься повесить еще один костыль который увеличит хаос.
По делу: Наведите порядок, это не так сложно, даже на уровне логики, найти живые устройства со статиком и прописать их в конфиг dhcpd. А потом все-таки обойти хозяйство и привести его в порядок.

Не спасет: у устройств со статиком останется /24 и они не увидят «соседей»

10.128.0.0/23

Махом всю сеть менять я бы не стал.

Я бы посчитал сколько необходимо статики, сколько динамики. От сюда поменял диапазон выдаваемых адресов DHCP. Тех кому статика не обязательна, перевел в динамику. Статические, которые можно поменять, поменял, чтоб не конфликтовали. Которые нельзя, - прописал бы в DHCP, чтоб одни и те же получали. Это все можно делать постепенно.

Не спасет: у устройств со статиком останется /24 и они не увидят «соседей»

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

Можно сделать вторую сеть в виде алиаса и чтобы было все правильно, в isc dhcp создать shared-network, в нее вписать 2 сети. Но между старой и новой сетью трафик будет ходить через роутер ( да еще через один и тот-же интерфейс). А если на роутере еще и фильтрация какая настроена ? А оно нужно тебе ?

Сделать сетку /23 как предложил sin_a - тоже много работы - всех статиков придется перенастраивать иначе будет еще хуже чем в предыдущем варианте.

Вычислить статиков - не сложно (особенно на шлюзе). Запустив «ip mo neigh» можно проверять был ли выдан адрес через dhcp. Обнаруженных статиков добавлять в dhcpd как fixed-address.

Вообще, сеть вила 10.*.*.* должна быть с маской 255.0.0.0, ибо это сеть класса A по стандарту. Ну и ему достаточно на шлюзе сменить маску сети на 255.0.0.0, а динамические адреса выдавать хоть из любого диапазона 10.*.*.*, но с маской 255.0.0.0. Машины со статическим адресами и маской 255.255.255.0 будут видеть все остальные машины через шлюз, если у него там настроен NAT, прочие машины с динамическим IP адресами будут «общаться» на прямую. Потом постепенно будет переводить машины со статикой на маску 255.0.0.0 и выставлять нужный IP адрес из диапазона IP адресов, что не выдаёт DHCP сервер, хоть оставлять тот же, что и был, меняя только маску на /8.

Ник смените на Остер.

С чего это, сходи почитай про классы сетей и сеть начинающуюся на 10.*.*.*.

Я же не говорю, что всё нужно так оставить. Просто делаешь маску по стандарту с включённым NAT и всё работает, естсетсвенно часть пакетов временно будет идти через шлюз, пока он на машинах со статическим IP не сменит маску.

Без NAT, кстати тоже будет работать, но пакеты всё равно будут идти через шлюз, пока не будет изменена маска.

Удачи.

Дядя, хоть мозг включи для начала. Пример локалка 1.1.0.0/23 в ней находятся устройства с статикой 1.1.0.0/24 шлюз у всех 1.1.0.1. Теперь вопрос знатокам пакет от 1.1.1.33 (/23) к 1.1.0.55 (статика /24) куда полетит?

Тётя, от /23 пакет пойдёт напрямую к /24, а от /24 к /23 пакет пойдёт через шлюз. Это называется маршрутизация и всё работает даже без NAT, только на шлюзе маска, в данном случае должна быть /23.

Прямо фантастика какая-то, видимо выше твоего понимания.

Сходи на кошках виртуалках потренируйся, если не понимаешь.

Заодно почитай что такое маска и для чего она нужна.

При обмене пакетами пакет от отправителя к адресату и ответный от адресата к отправителю не обязательно должны идти одним и тем же путём.

Заодно почитай что такое шлюз и что такое default route, переведи дословно.

С чего это, сходи почитай про классы сетей

ЗЫ Я так понимаю что у вас везде выделено как минимум по белой C сети, а может даже A сети, ведь все зависит от цифирок по вашей логике.

У нас выделена сеть класса B (191.*.*.*/16), ибо в сети 800 с лишним машин.

пакет пойдёт через шлюз.

Который скажет «имел я вас всех базарьте напрямую».

Не хило....

и всё работает даже без NAT, только на шлюзе маска, в данном случае должна быть /23

Хоть НАТ, хоть не НАТ - все дерьмо. Статику обычно ставят на машины с сервисами, не они, а к ним обращаются. Все начинается с arp, с бродкаста.

Он и так будет «думать», что с ним «базарят» напрямую. Ещё раз говорю, сходи почитай что такое маршрутизация, что такое default route, что такое ip_forward.

Ну и тренируйся на кошках до просветления.

Если в случае использования имён хостов (дменных имён) их разрешение идёт идёт только только по Netbios, т.е. машины в прямой видимости, то да могут быть проблемы. Но DNS придумали не просто так, ну а если идёт обращение жёстко по IP, то тем более всё будет хорошо.

Опять таки, если учесть, что клиенты находятся в сети /8, а сервисы в сети /24, то клиенты смогут отослать запрос по имени, а далее ответ от сервиса придёт уже через шлюз.

Он и так будет «думать», что с ним «базарят» напрямую.

Шлюз отправит редирект. А вот /24 в данном случае будет в «замешательстве» «напрямую не могу, а меня просят ходить напрямую»

Ещё раз говорю, сходи почитай что такое маршрутизация, что такое default route, что такое ip_forward.

Вам того же советую.

Если это не нужно особо с кем-то согласовывать, просто увеличь свою подсеть на DHCP-сервере и в сетевом хозяйстве на один бит (24->23 и т.п.), статика пусть себе торчит своими адресами в старой половине, а на DHCP-сервере настрой выдачу динамики только из новой половины.
В результате, новая подсеть охватит и твои статические хосты и твою новую динамику.

А на будущее, выдавай DHCP-сервером все необходимые опции в твоей сети, чтобы использование статики стало тупо неудобным. Тогда подобные проблемы просто перестанут возникать.

у устройств со статиком останется /24 и они не увидят «соседей»

Устройства /24 за пределами своего диапазона никого «соседями» и не считают - им они пошлют свои пакеты через DG.

А вот /24 в данном случае будет в «замешательстве» «напрямую не могу, а меня просят ходить напрямую»

Подумай, в чём разница между шлюзом и обычным маршрутизатором, switch`ом.

Если /24 не видит адресата напрямую, то он отправит ответный пакет на шлюз, т.е. на маршрут по умолчанию, он потому и называется default route. А уже шлюз перенаправит пакет в /23.

Это и называется маршрутизация, я говорю именно о маршрутизации без NAT. А даже если бы был и NAT, то ровным счётом ничего бы не поменялось, только с точки зрения /24 все пакеты ходили бы в сети /24.

Вам того же советую.

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

Удачи.

Он не понимает что такое Default Route и вообще принципы маршрутизации, нужно руками поработать.

Если /24 не видит адресата напрямую, то он отправит ответный пакет на шлюз, т.е. на маршрут по умолчанию, он потому и называется default route. А уже шлюз перенаправит пакет в /23.

Только вот устройства, устройствам рознь. И кто-то не очень «зашибись» это «переживает». Поверьте я в целом-то с вами согласен, это рабочий (но хреновый) вариант о нем я в самом начале писал как плохой именно по этой причине. И тут дохрена нюансов от умных железок по дороге и т.д.

Он не понимает что такое Default Route и вообще принципы маршрутизации, нужно руками поработать.

Ну поучите. Я же не спорю что не такой же знаток как уважаемый vel.
ЗЫ Хотя от вас как знатока замечено не было.

Но DNS придумали не просто так

Ну, ну. Он, DNS, еще и мак-адреса раздает, и говорит через какой гейт к кому ходить. Круто.

У нас выделена сеть класса B (191.*.*.*/16), ибо в сети 800 с лишним машин.
Не хило....

Не не хило, а жирно, используется чуть более процента белого адресного пространства.

сеть вила 10.*.*.* должна быть с маской 255.0.0.0, ибо это сеть класса A по стандарту.

Еще один знаток! 93 год давно прошел.

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

Воощм из всего понаписанного решил сначала поступить как советует blexey. Если не прокатит, то придется кропотливо приводить сеть в порядок. Кароч мораль сей басни такова: делай все нормально с самого начала, меньше будет проблем потом.