LINUX.ORG.RU
ФорумAdmin

адреса из разных подсетей isc dhcp

 


0

1

Здравствуйте.

Можно ли осуществить и как, если можно? У меня есть 2 интерфейса vmbr0, vmbr1

/etc/dhcp/dhcpd.conf:

subnet a.a.0.0 netmask 255.255.240.0 {
range a.a.0.5-a.a.0.10;
....

host 1 {
hardware  ethernet aa:aa:aa:aa:aa;
fixed address a.a.32.5;
.....
}

host 2 {
hardware ethernet bb:bb:bb:bb:bb:bb;
fixed-address a.a.41.150;
...
}
}
subnet 10.0.0.0 netmask 255.255.255.0 {
range 10.0.0.10-10.0.0.30;
...
lhost1 {
hardware ethernet cc:cc:cc:cc:cc:cc;
fixed-address 10.0.0.35;
...
}
lhost2 {
hardware ethernet ee:ee:ee:ee:ee:ee;
fixed-address 10.0.0.36;
...
}
}

но в первой подсети надо выдавать еще адреса b.b.b.b isc-dhcp не выдает адреса при конфиге:

subnet a.a.0.0 netmask 255.255.240.0 {
...
host {
hardware ethernet ....;
fixed-address b.b.b.b;
option routers b.b.b.1;
option broadcast-address b.b.b.255;
...
}
}

а при конфиге

subnet 0.0.0.0 netmask 255.0.0.0 {
...
}
вообще не стартует.

Как можно так придумать?


Если у вас разные ip-адреса на разных интерфейсах, то пишите разные subnet в конфиге. Если на одном, то объединятей разные subnet в ″shared-network ИМЯ-СЕТИ {}″.

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

mky ★★★★★
()

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

Если да, то это штатное поведение, настраивается с помощью subnet в конфиге.

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

Ну и присоединяюсь к совету про логи.

Serge10 ★★★★★
()
Ответ на: комментарий от Serge10

Уточняю. На хост машине есть 2 моста vmbr0 - мир, vmbr1 - внутренняя сеть (есть необходимость) так сложилось, что в аренде есть 4 «/29» блока адресов. на хосте решено банально просто:

ip route add a.a.a.a/29 dev vmbr0
но помимо всего надо чтоб dhcp сервер раздавал их клиентам («статически»), т.к. нет особой возможности настраивать на клиентах статику.

Вот и стал вопрос чтоб dhcp на vmbr0 понимал хосты

host1 {
hardware...
fixed-address a.a.a.50;
}
host2 {
...
fixed-ddress a.a.a.51;
}
host3 {
...
fixed-address a.b.b.167;
}
host4 {
...
fixed-address c.c.c.47;
}
думаю «сходство» подсетей не имеет никакого значения...

alexni
() автор топика
Ответ на: комментарий от alexni

Я бы на Вашем месте поднял бы на vmbr0 4 VLANs и на каждый повесил бы свой блок адресов. Ну и соответствующим образом сконфигурировал бы dhcpd (через subnet).

Serge10 ★★★★★
()
Ответ на: комментарий от alexni

«На ходу» сеть не переподнимается

Это как? В любом дистрибутиве есть команды перезапуска сети, перезагружать сервер для этого ненужно. В крайнем случае, можно руками (с помощью команд ip или ifconfig) опустить интерфейс vmbr0 и сконфигурировать на нем нужные VLANs.

Serge10 ★★★★★
()
Ответ на: комментарий от alexni

«service networking restart» тушит сеть но не поднимает обратно.

И в логах нет никакой информации по этому поводу?

то же самое при использовании ifconfig, ip

В отличие от рестарта сети, эти команды позволяют работать с отдельными интерфейсами. А значит, никто не мешает Вам опустить интерфейс vmbr0 (Ваше подключение к серверу не пострадает, т. к. Вы подсоединяетесь через vmbr1), сконфигурировать и поднять необходимое число VLANs, после чего настроить и запустить dhcpd.

Serge10 ★★★★★
()
Ответ на: комментарий от Serge10

Это как? В любом дистрибутиве есть команды перезапуска сети

Хотя Proxmox использует ifupdown, там не поддерживается изменение конфигурации без перезагрузки. Нет, можно, конечно, но не стоит.

И DHCP-сервер гонять на гипервизоре тоже не стоит, лучше его виртуализировать.

anonymous
()
Ответ на: комментарий от anonymous

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

Я давно крутил в руках Proxmox (до появления systemd), но там в основе был обычный Debian и, соответственно, все там поддерживалось.

Нет, можно, конечно, но не стоит.

Хм, и почему, если не секрет?

И DHCP-сервер гонять на гипервизоре тоже не стоит, лучше его виртуализировать.

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

Serge10 ★★★★★
()
Ответ на: комментарий от anonymous

«Хотя Proxmox использует ifupdown, там не поддерживается изменение конфигурации без перезагрузки. Нет, можно, конечно, но не стоит.

И DHCP-сервер гонять на гипервизоре тоже не стоит, лучше его виртуализировать.»

dhcp не на гипервизоре (хотя подумываю туда его засунуть). А сеть, хоть и правда, Proxmox на Debian, не «переподнимается» без перезагрузки. Proxmox support по этому поводу разводят руками и говорят нечего на хосте сеть перегружать на ходу. чревато последствиями

alexni
() автор топика
Ответ на: комментарий от Serge10

если dhcp виртуализирован, то на киентах иногда проскакивают проблемы с получением адресов. как-то нашел обьяснение и решение посредством использования virtio на клиентах, но все равно бывают «заскоки»

alexni
() автор топика
Ответ на: комментарий от alexni

Там какой-то offload надо отключать на интерфейсах, это давняя проблема. Проявляется обычно на DHCP.

anonymous
()
Ответ на: комментарий от Serge10

все там поддерживалось.

Работало, но не поддерживалось.

Хм, и почему, если не секрет?

В документации сказано, что нужно перезагружать хост, иначе ССЗБ.

anonymous
()
Ответ на: комментарий от anonymous

В документации сказано, что нужно перезагружать хост, иначе ССЗБ.

Читать документацию - это правильно, тут не поспоришь.

Но неплохо бы еще понимать, что там пишут и почему. А иначе документация превращается в список мантр и заклинаний, а процессы администрирования мало чем от шаманства начинают отличаться :(.

Serge10 ★★★★★
()
18 октября 2018 г.
Ответ на: комментарий от alexni

но как факт - без рестарта не работает.

Я давно уже не ковырялся с Proxmox, но лет 7 назад там было все как в обычном Debian - вполне можно было сеть перезапустить без перезагрузки. Причем как целиком, так и отдельные интерфейсы.

Впрочем, я, честно говоря, вообще не понимаю, как можно запретить перезапуск сети без перезагрузки машины в Linux. По-моему, это просто технически невозможно. Если не сложно, расскажите, как этого добиваются в современном Proxmox.

Serge10 ★★★★★
()
Ответ на: комментарий от Serge10

Впрочем, я, честно говоря, вообще не понимаю, как можно запретить перезапуск сети без перезагрузки машины в Linux. По-моему, это просто технически невозможно. Если не сложно, расскажите, как этого добиваются в современном Proxmox.

На уровне предположения.
Начнем с того: Что есть «перезапуск сети» ? Скорее всего разговор о скриптах которые выполняют кучу разных команд. Так вот для того что бы вы «случайно» не потеряли связь с сервером, во многих дистрах завезли вариант когда и старый адрес остается, т.е. restart != stop-start. Этот момент уже много раз обсуждался, в том числе и здесь.
А вот запретить вам никто не может, отдельными командами делайте что хотите. Поэтому думаю что это общая рекомендация. Представьте как отвечать на кучу вопросов вида, «я вот рестартовал сеть и у меня не робит A,B,C, etc». И не смотря на ответ похожий «на шиндовый» в нем есть определенный смысл, не всегда он нужен, но в общем варианте меняем сетевые настройки, т.е. демоны «переезжают» и т.д. и .т.п

anc ★★★★★
()
Ответ на: комментарий от anc

А вот запретить вам никто не может, отдельными командами делайте что хотите.

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

Serge10 ★★★★★
()
Ответ на: комментарий от Serge10

Так что процедура вполне безопасна...

Ага, т.е. «дальней поездки» у вас еще не случалось? :) Чуть «дрогнула рука» и привет «чемодан вокзал» :) Но если быть честным, то ребут тоже может к этому привести. Личный пример, больше суток без сна, заканчиваю работу, финальный ребут что бы проверить что все работает, и в shutdown забываю ключик -r, но это я понял только приехав на место :) Еще пример из личного раздолбайства, при настройке накосячил с мониторингом смарта, прошло много времени, один из хардов начал лететь, но я об этом не знал, сервак в ребут, контроллер встал с предупреждением.

anc ★★★★★
()
Ответ на: комментарий от anc

Ага, т.е. «дальней поездки» у вас еще не случалось? :) Чуть «дрогнула рука» и привет «чемодан вокзал» :)

Не, у меня на серверах обычно IPMI или его брендовый аналог есть ;).

Но если быть честным, то ребут тоже может к этому привести.

Ребут вообще намного опасней, чем изменения в одном из сетевых интерфейсов, IMHO.

Serge10 ★★★★★
()
Ответ на: комментарий от Serge10

Не, у меня на серверах обычно IPMI или его брендовый аналог есть ;).

Это хорошо, когда оно везде есть.

Ребут вообще намного опасней, чем изменения в одном из сетевых интерфейсов, IMHO.

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

anc ★★★★★
()
Ответ на: комментарий от anc

При больших изменениях, как раз ребут имхо (не только мое) нужен, что бы убедиться что все заработает после ребута.

Это да.

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

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

Serge10 ★★★★★
()
Ответ на: комментарий от Serge10

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

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

anc ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.