forum.opennet.ru - "dhclient+несколько интерфейсов в одном сегменте" (8)

форумы

помощь

поиск

регистрация

майллист

вход/выход

слежка

"dhclient+несколько интерфейсов в одном сегменте"

Форум Открытые системы на сервере (DHCP / Linux)
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"dhclient+несколько интерфейсов в одном сегменте"	+/–
Сообщение от antrocon on 05-Фев-13, 12:50
Доброго времени суток! Есть хост-система под виртуализацию, centos 6.3 с 3-мя интерфейсами: 2 из них объеденены в bond mode=6, поверх бонда сделан бридж 'mgmt', бридж настроен на получение адреса по dhcp (на dhcp сделана резервация); 3-й интерфейс загнан в другой бридж 'trunk', без айпи адреса (под виртуалки с поддержкой vlan). Проблема в том, что первый раз (при старте системы или ifup/ifdown) mgmt получает айпи без проблем, а вот renew уже не получается - сервер отвечает dhcpack-ом предлагая правильный айпи, клиент делает arp who-has, получает _от себя же_ (с другого слейва в бонде или с 3-го отдельного интерфейса) реплай и в результате отклоняет адрес dhcpdecline. В результате на dhcp-серваке (MS) резервация корежится "bad_address"-ом, умирают dns-записи и вообще становится все печально... вот какую картину вижу wireshark-ом: 9 3.329744 Dell_ac:1b:01 Broadcast ARP 42 Who has 192.168.10.130? Tell 0.0.0.0 10 3.329903 Dell_ac:1b:05 Dell_ac:1b:01 ARP 60 192.168.10.130 is at 90:b1:1c:ac:1b:05 (duplicate use of 192.168.10.130 detected!) при всем при этом, Dell_ac:1b:01 - mac mgmt-бриджа, Dell_ac:1b:05 - mac 3-го интерфейса с бриджом (без айпи) под виртуалки. Первые 2 интерфейса включены в отдельный vlan на свитчах, 3-й интерфейс - в транковом режиме, передаются все vlan-ы. Подскажите пожалуйста, какого фига другие интерфейсы этой же машины "присваивают" айпи и как вообще такую ситуацию разрулить?
Ответить \| Правка \| Cообщить модератору

Оглавление

dhclient+несколько интерфейсов в одном сегменте, pavlinux, 14:33 , 05-Фев-13, (1)

dhclient+несколько интерфейсов в одном сегменте, antrocon, 15:42 , 05-Фев-13, (2)

dhclient+несколько интерфейсов в одном сегменте, pavlinux, 16:11 , 05-Фев-13, (3)

dhclient+несколько интерфейсов в одном сегменте, antrocon, 16:55 , 05-Фев-13, (4)

dhclient+несколько интерфейсов в одном сегменте, pavlinux, 18:33 , 05-Фев-13, (5)

dhclient+несколько интерфейсов в одном сегменте, antrocon, 19:02 , 05-Фев-13, (6)

dhclient+несколько интерфейсов в одном сегменте, ACCA, 20:39 , 05-Фев-13, (7)

dhclient+несколько интерфейсов в одном сегменте, antrocon, 11:41 , 07-Фев-13, (8)

Сообщения по теме [Сортировка по времени | RSS]

1. "dhclient+несколько интерфейсов в одном сегменте" +/–

Сообщение от pavlinux (ok) on 05-Фев-13, 14:33

> и как вообще такую ситуацию разрулить?
http://ru.wikipedia.org/wiki/%D0%A1%D0%B...
У сетевого устройства 2 уровня модели OSI, не может быть IP адреса,
то что это можно сделать в лине, не значит, что этим надо пользоваться.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "dhclient+несколько интерфейсов в одном сегменте" +/–

Сообщение от antrocon on 05-Фев-13, 15:42

>> и как вообще такую ситуацию разрулить?
> http://ru.wikipedia.org/wiki/п║п╣я┌п╣п╡п╬п╧_п╪п╬я│я┌
> У сетевого устройства 2 уровня модели OSI, не может быть IP адреса,
> то что это можно сделать в лине, не значит, что этим надо
> пользоваться.
хорошо, как тогда предложите использовать kvm-виртуализацию, если единственным способом прокинуть виртуальный интерфейс виртуалки в реальную сеть (без натов и прочего непотребства) - это включить его в бридж (более того - это метод by-design, http://www.linux-kvm.org/page/Networking#public_bridge )? а любой физический интерфейс, включенный в линухе в бридж - не может иметь своих сетевых настроек (они тупо игнорируются, даже если есть в конфиг-файле).
специально для Вас проверил такой вариант - бридж mgmt убрал, остался только bond0 из 2-х первых интерфейсов, он адрес по дхчп получает, и 3-й интерфейс в бридже без айпи. Ситуация абсолютно одинаковая - при обновлении адреса по дхчп вижу арп-ответ от 3-го интерфейса (т.е. от самого себя) и получаю dhcpdecline.

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

3. "dhclient+несколько интерфейсов в одном сегменте" +/–

Сообщение от pavlinux (ok) on 05-Фев-13, 16:11

Ну второй вариант, это собрать все виртуальные интерфейсы в бридж,
а наружу выводить через маршрутизацию.
Кстати, сделай
# ifconfig -a | grep HWaddr
и удивись.

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

4. "dhclient+несколько интерфейсов в одном сегменте" +/–

Сообщение от antrocon on 05-Фев-13, 16:55

> Ну второй вариант, это собрать все виртуальные интерфейсы в бридж,
> а наружу выводить через маршрутизацию.
мне этот вариант не подходит.
"бридж из физического интерфейса и виртуальных", как способ выброса виртуалок в реальную сеть - стандартный способ и для квм-а, и для hyper-v/vmware. в последних - это 100% работает, в kvm - тоже проблем до сегодня не имел (правда проще были инсталяции - 2-4 интерфейса в бондинг, сверху бридж без вланов).
> Кстати, сделай
> # ifconfig -a | grep HWaddr
> и удивись.
сделал, чему удивлятся? mac в dhcp-запросах - 90:B1:1C:AC:1B:01, этот мак висит на mgmt бридже (унаследован от bond0, который его выбрал как мак первого слейв интерфейса, все как положено), а реплаи идут от 90:B1:1C:AC:1B:05 - физический p3p1, бриджи+сабинтерфейсы trunk.* vlan*, на которых и в помине не было никакого айпи.

bond0     Link encap:Ethernet  HWaddr 90:B1:1C:AC:1B:01
bond1     Link encap:Ethernet  HWaddr 00:00:00:00:00:00
em1       Link encap:Ethernet  HWaddr 90:B1:1C:AC:1B:01
em2       Link encap:Ethernet  HWaddr 90:B1:1C:AC:1B:04
mgmt      Link encap:Ethernet  HWaddr 90:B1:1C:AC:1B:01
p3p1      Link encap:Ethernet  HWaddr 90:B1:1C:AC:1B:05
p3p2      Link encap:Ethernet  HWaddr 90:B1:1C:AC:1B:06
p3p3      Link encap:Ethernet  HWaddr 90:B1:1C:AC:1B:07
p3p4      Link encap:Ethernet  HWaddr 90:B1:1C:AC:1B:08
trunk     Link encap:Ethernet  HWaddr 90:B1:1C:AC:1B:05
trunk.10  Link encap:Ethernet  HWaddr 90:B1:1C:AC:1B:05
trunk.13  Link encap:Ethernet  HWaddr 90:B1:1C:AC:1B:05
trunk.50  Link encap:Ethernet  HWaddr 90:B1:1C:AC:1B:05
trunk.51  Link encap:Ethernet  HWaddr 90:B1:1C:AC:1B:05
trunk.52  Link encap:Ethernet  HWaddr 90:B1:1C:AC:1B:05
vlan10    Link encap:Ethernet  HWaddr 90:B1:1C:AC:1B:05
vlan13    Link encap:Ethernet  HWaddr 90:B1:1C:AC:1B:05
vlan50    Link encap:Ethernet  HWaddr 90:B1:1C:AC:1B:05
vlan51    Link encap:Ethernet  HWaddr 90:B1:1C:AC:1B:05
vlan52    Link encap:Ethernet  HWaddr 90:B1:1C:AC:1B:05

em1,em2 - slave bond0
mgmt - бридж из bond0, dhcp
bond1, p3p2-p3p4 - выключены
p3p1 - в бридже trunk (для виртуалок с транк-интерфейсом)
trunk.x - сабинтерфейсы по вланам
vlanX - бриджи по вланам для виртуалок
а вот, например, с поднятыми виртуалками:

bond0     Link encap:Ethernet  HWaddr 90:B1:1C:AC:1B:35
bond1     Link encap:Ethernet  HWaddr 00:00:00:00:00:00
em1       Link encap:Ethernet  HWaddr 90:B1:1C:AC:1B:35
em2       Link encap:Ethernet  HWaddr 90:B1:1C:AC:1B:38
mgmt      Link encap:Ethernet  HWaddr 90:B1:1C:AC:1B:35
p3p1      Link encap:Ethernet  HWaddr 90:B1:1C:AC:1B:39
p3p2      Link encap:Ethernet  HWaddr 90:B1:1C:AC:1B:3A
p3p3      Link encap:Ethernet  HWaddr 90:B1:1C:AC:1B:3B
p3p4      Link encap:Ethernet  HWaddr 90:B1:1C:AC:1B:3C
trunk     Link encap:Ethernet  HWaddr 90:B1:1C:AC:1B:39
trunk.10  Link encap:Ethernet  HWaddr 90:B1:1C:AC:1B:39
trunk.13  Link encap:Ethernet  HWaddr 90:B1:1C:AC:1B:39
trunk.50  Link encap:Ethernet  HWaddr 90:B1:1C:AC:1B:39
trunk.51  Link encap:Ethernet  HWaddr 90:B1:1C:AC:1B:39
trunk.52  Link encap:Ethernet  HWaddr 90:B1:1C:AC:1B:39
vlan10    Link encap:Ethernet  HWaddr 90:B1:1C:AC:1B:39
vlan13    Link encap:Ethernet  HWaddr 90:B1:1C:AC:1B:39
vlan50    Link encap:Ethernet  HWaddr 90:B1:1C:AC:1B:39
vlan51    Link encap:Ethernet  HWaddr 90:B1:1C:AC:1B:39
vlan52    Link encap:Ethernet  HWaddr 90:B1:1C:AC:1B:39
vnet0     Link encap:Ethernet  HWaddr FE:54:00:CD:44:28
vnet1     Link encap:Ethernet  HWaddr FE:54:00:2A:21:7F
vnet2     Link encap:Ethernet  HWaddr FE:54:00:B6:6A:28
vnet3     Link encap:Ethernet  HWaddr FE:54:00:39:8B:54
brctl show
bridge name    bridge id        STP enabled    interfaces
mgmt        8000.90b11cac1b35    no        bond0
trunk        8000.90b11cac1b39    no        p3p1
                            vnet2
vlan10        8000.90b11cac1b39    no        trunk.10
vlan13        8000.90b11cac1b39    no        trunk.13
vlan50        8000.90b11cac1b39    no        trunk.50
                            vnet0
                            vnet1
                            vnet3
vlan51        8000.90b11cac1b39    no        trunk.51
vlan52        8000.90b11cac1b39    no        trunk.52

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

5. "dhclient+несколько интерфейсов в одном сегменте" +/–

Сообщение от pavlinux (ok) on 05-Фев-13, 18:33

Уу-у-у-у, как всё замороченно, в такой каше ищи сам где накосячил.
Самое быстрое - всё сломать и строить заново: один езернет, один бонд, один бридж и
добалять по одному.

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

6. "dhclient+несколько интерфейсов в одном сегменте" +/–

Сообщение от antrocon on 05-Фев-13, 19:02

> Уу-у-у-у, как всё замороченно, в такой каше ищи сам где накосячил.
> Самое быстрое - всё сломать и строить заново: один езернет, один бонд,
> один бридж и
> добалять по одному.
я именно это и сделал в реплае №2: оставил только один бонд из em1+em2, бонд айпи получает по дхчп. плюс бридж trunk из физического p3p1, без айпи адресов.
результат - как в начале. при обновлении адреса получаю арп-реплай с мака p3p1 о том, что на нем уже висит этот айпи - обновление айпи проваливается.

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

7. "dhclient+несколько интерфейсов в одном сегменте" +/–

Сообщение от ACCA (ok) on 05-Фев-13, 20:39

> результат - как в начале. при обновлении адреса получаю арп-реплай с мака
> p3p1 о том, что на нем уже висит этот айпи -
> обновление айпи проваливается.
Простое (и общепринятое) решение - не использовать DHCP для конфигураци хоста. Ты с ним согласишься после первой же ночной поездки в датацентр после сбоя питания.
Разумеется, техника может победить здравый смысл - man arptables.

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

8. "dhclient+несколько интерфейсов в одном сегменте" +/–

Сообщение от antrocon on 07-Фев-13, 11:41

> Простое (и общепринятое) решение - не использовать DHCP для конфигураци хоста. Ты
> с ним согласишься после первой же ночной поездки в датацентр после
> сбоя питания.
подобные риски мне известны, но в моей ситуации значение падение этого интерфейса не блокирует работу остальных систем (отваливается только мониторинг и контроль хост-системы) + есть доступ к drac по другим каналам, поэтому я считал dhcp вполне подходящим инструментом для этого случая.
но, раз какого-либо логичного объяснения этому феномену никто не предложил - переделал на статику, оставив dhcp на случай перезаливки хоста кикстартом.
> Разумеется, техника может победить здравый смысл - man arptables.
тогда уж проще статику использовать, менее костыльное решение. меня собственно больше интересовала причина возникновения этой проблемы - какого фига другой интерфейс, на котором айпи не было никогда, вдруг отвечает, что айпи принадлежит ему.
Если больше идей нет - тогда всем спасибо за помощь и дискуссию!

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "dhclient+несколько интерфейсов в одном сегменте"	+/–
Сообщение от pavlinux (ok) on 05-Фев-13, 14:33
> и как вообще такую ситуацию разрулить? http://ru.wikipedia.org/wiki/%D0%A1%D0%B... У сетевого устройства 2 уровня модели OSI, не может быть IP адреса, то что это можно сделать в лине, не значит, что этим надо пользоваться.
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	2. "dhclient+несколько интерфейсов в одном сегменте"	+/–
	Сообщение от antrocon on 05-Фев-13, 15:42
	>> и как вообще такую ситуацию разрулить? > http://ru.wikipedia.org/wiki/п║п╣я┌п╣п╡п╬п╧_п╪п╬я│я┌ > У сетевого устройства 2 уровня модели OSI, не может быть IP адреса, > то что это можно сделать в лине, не значит, что этим надо > пользоваться. хорошо, как тогда предложите использовать kvm-виртуализацию, если единственным способом прокинуть виртуальный интерфейс виртуалки в реальную сеть (без натов и прочего непотребства) - это включить его в бридж (более того - это метод by-design, http://www.linux-kvm.org/page/Networking#public_bridge )? а любой физический интерфейс, включенный в линухе в бридж - не может иметь своих сетевых настроек (они тупо игнорируются, даже если есть в конфиг-файле). специально для Вас проверил такой вариант - бридж mgmt убрал, остался только bond0 из 2-х первых интерфейсов, он адрес по дхчп получает, и 3-й интерфейс в бридже без айпи. Ситуация абсолютно одинаковая - при обновлении адреса по дхчп вижу арп-ответ от 3-го интерфейса (т.е. от самого себя) и получаю dhcpdecline.
	Ответить \| Правка \| ^ к родителю #1 \| Наверх \| Cообщить модератору


	3. "dhclient+несколько интерфейсов в одном сегменте"	+/–
	Сообщение от pavlinux (ok) on 05-Фев-13, 16:11
	Ну второй вариант, это собрать все виртуальные интерфейсы в бридж, а наружу выводить через маршрутизацию. Кстати, сделай # ifconfig -a \| grep HWaddr и удивись.
	Ответить \| Правка \| ^ к родителю #2 \| Наверх \| Cообщить модератору


	4. "dhclient+несколько интерфейсов в одном сегменте"	+/–
	Сообщение от antrocon on 05-Фев-13, 16:55
	> Ну второй вариант, это собрать все виртуальные интерфейсы в бридж, > а наружу выводить через маршрутизацию. мне этот вариант не подходит. "бридж из физического интерфейса и виртуальных", как способ выброса виртуалок в реальную сеть - стандартный способ и для квм-а, и для hyper-v/vmware. в последних - это 100% работает, в kvm - тоже проблем до сегодня не имел (правда проще были инсталяции - 2-4 интерфейса в бондинг, сверху бридж без вланов). > Кстати, сделай > # ifconfig -a \| grep HWaddr > и удивись. сделал, чему удивлятся? mac в dhcp-запросах - 90:B1:1C:AC:1B:01, этот мак висит на mgmt бридже (унаследован от bond0, который его выбрал как мак первого слейв интерфейса, все как положено), а реплаи идут от 90:B1:1C:AC:1B:05 - физический p3p1, бриджи+сабинтерфейсы trunk.* vlan*, на которых и в помине не было никакого айпи. bond0 Link encap:Ethernet HWaddr 90:B1:1C:AC:1B:01 bond1 Link encap:Ethernet HWaddr 00:00:00:00:00:00 em1 Link encap:Ethernet HWaddr 90:B1:1C:AC:1B:01 em2 Link encap:Ethernet HWaddr 90:B1:1C:AC:1B:04 mgmt Link encap:Ethernet HWaddr 90:B1:1C:AC:1B:01 p3p1 Link encap:Ethernet HWaddr 90:B1:1C:AC:1B:05 p3p2 Link encap:Ethernet HWaddr 90:B1:1C:AC:1B:06 p3p3 Link encap:Ethernet HWaddr 90:B1:1C:AC:1B:07 p3p4 Link encap:Ethernet HWaddr 90:B1:1C:AC:1B:08 trunk Link encap:Ethernet HWaddr 90:B1:1C:AC:1B:05 trunk.10 Link encap:Ethernet HWaddr 90:B1:1C:AC:1B:05 trunk.13 Link encap:Ethernet HWaddr 90:B1:1C:AC:1B:05 trunk.50 Link encap:Ethernet HWaddr 90:B1:1C:AC:1B:05 trunk.51 Link encap:Ethernet HWaddr 90:B1:1C:AC:1B:05 trunk.52 Link encap:Ethernet HWaddr 90:B1:1C:AC:1B:05 vlan10 Link encap:Ethernet HWaddr 90:B1:1C:AC:1B:05 vlan13 Link encap:Ethernet HWaddr 90:B1:1C:AC:1B:05 vlan50 Link encap:Ethernet HWaddr 90:B1:1C:AC:1B:05 vlan51 Link encap:Ethernet HWaddr 90:B1:1C:AC:1B:05 vlan52 Link encap:Ethernet HWaddr 90:B1:1C:AC:1B:05 em1,em2 - slave bond0 mgmt - бридж из bond0, dhcp bond1, p3p2-p3p4 - выключены p3p1 - в бридже trunk (для виртуалок с транк-интерфейсом) trunk.x - сабинтерфейсы по вланам vlanX - бриджи по вланам для виртуалок а вот, например, с поднятыми виртуалками: bond0 Link encap:Ethernet HWaddr 90:B1:1C:AC:1B:35 bond1 Link encap:Ethernet HWaddr 00:00:00:00:00:00 em1 Link encap:Ethernet HWaddr 90:B1:1C:AC:1B:35 em2 Link encap:Ethernet HWaddr 90:B1:1C:AC:1B:38 mgmt Link encap:Ethernet HWaddr 90:B1:1C:AC:1B:35 p3p1 Link encap:Ethernet HWaddr 90:B1:1C:AC:1B:39 p3p2 Link encap:Ethernet HWaddr 90:B1:1C:AC:1B:3A p3p3 Link encap:Ethernet HWaddr 90:B1:1C:AC:1B:3B p3p4 Link encap:Ethernet HWaddr 90:B1:1C:AC:1B:3C trunk Link encap:Ethernet HWaddr 90:B1:1C:AC:1B:39 trunk.10 Link encap:Ethernet HWaddr 90:B1:1C:AC:1B:39 trunk.13 Link encap:Ethernet HWaddr 90:B1:1C:AC:1B:39 trunk.50 Link encap:Ethernet HWaddr 90:B1:1C:AC:1B:39 trunk.51 Link encap:Ethernet HWaddr 90:B1:1C:AC:1B:39 trunk.52 Link encap:Ethernet HWaddr 90:B1:1C:AC:1B:39 vlan10 Link encap:Ethernet HWaddr 90:B1:1C:AC:1B:39 vlan13 Link encap:Ethernet HWaddr 90:B1:1C:AC:1B:39 vlan50 Link encap:Ethernet HWaddr 90:B1:1C:AC:1B:39 vlan51 Link encap:Ethernet HWaddr 90:B1:1C:AC:1B:39 vlan52 Link encap:Ethernet HWaddr 90:B1:1C:AC:1B:39 vnet0 Link encap:Ethernet HWaddr FE:54:00:CD:44:28 vnet1 Link encap:Ethernet HWaddr FE:54:00:2A:21:7F vnet2 Link encap:Ethernet HWaddr FE:54:00:B6:6A:28 vnet3 Link encap:Ethernet HWaddr FE:54:00:39:8B:54 brctl show bridge name bridge id STP enabled interfaces mgmt 8000.90b11cac1b35 no bond0 trunk 8000.90b11cac1b39 no p3p1 vnet2 vlan10 8000.90b11cac1b39 no trunk.10 vlan13 8000.90b11cac1b39 no trunk.13 vlan50 8000.90b11cac1b39 no trunk.50 vnet0 vnet1 vnet3 vlan51 8000.90b11cac1b39 no trunk.51 vlan52 8000.90b11cac1b39 no trunk.52
	Ответить \| Правка \| ^ к родителю #3 \| Наверх \| Cообщить модератору


	5. "dhclient+несколько интерфейсов в одном сегменте"	+/–
	Сообщение от pavlinux (ok) on 05-Фев-13, 18:33
	Уу-у-у-у, как всё замороченно, в такой каше ищи сам где накосячил. Самое быстрое - всё сломать и строить заново: один езернет, один бонд, один бридж и добалять по одному.
	Ответить \| Правка \| ^ к родителю #4 \| Наверх \| Cообщить модератору


	6. "dhclient+несколько интерфейсов в одном сегменте"	+/–
	Сообщение от antrocon on 05-Фев-13, 19:02
	> Уу-у-у-у, как всё замороченно, в такой каше ищи сам где накосячил. > Самое быстрое - всё сломать и строить заново: один езернет, один бонд, > один бридж и > добалять по одному. я именно это и сделал в реплае №2: оставил только один бонд из em1+em2, бонд айпи получает по дхчп. плюс бридж trunk из физического p3p1, без айпи адресов. результат - как в начале. при обновлении адреса получаю арп-реплай с мака p3p1 о том, что на нем уже висит этот айпи - обновление айпи проваливается.
	Ответить \| Правка \| ^ к родителю #5 \| Наверх \| Cообщить модератору


	7. "dhclient+несколько интерфейсов в одном сегменте"	+/–
	Сообщение от ACCA (ok) on 05-Фев-13, 20:39
	> результат - как в начале. при обновлении адреса получаю арп-реплай с мака > p3p1 о том, что на нем уже висит этот айпи - > обновление айпи проваливается. Простое (и общепринятое) решение - не использовать DHCP для конфигураци хоста. Ты с ним согласишься после первой же ночной поездки в датацентр после сбоя питания. Разумеется, техника может победить здравый смысл - man arptables.
	Ответить \| Правка \| ^ к родителю #6 \| Наверх \| Cообщить модератору


	8. "dhclient+несколько интерфейсов в одном сегменте"	+/–
	Сообщение от antrocon on 07-Фев-13, 11:41
	> Простое (и общепринятое) решение - не использовать DHCP для конфигураци хоста. Ты > с ним согласишься после первой же ночной поездки в датацентр после > сбоя питания. подобные риски мне известны, но в моей ситуации значение падение этого интерфейса не блокирует работу остальных систем (отваливается только мониторинг и контроль хост-системы) + есть доступ к drac по другим каналам, поэтому я считал dhcp вполне подходящим инструментом для этого случая. но, раз какого-либо логичного объяснения этому феномену никто не предложил - переделал на статику, оставив dhcp на случай перезаливки хоста кикстартом. > Разумеется, техника может победить здравый смысл - man arptables. тогда уж проще статику использовать, менее костыльное решение. меня собственно больше интересовала причина возникновения этой проблемы - какого фига другой интерфейс, на котором айпи не было никогда, вдруг отвечает, что айпи принадлежит ему. Если больше идей нет - тогда всем спасибо за помощь и дискуссию!
	Ответить \| Правка \| ^ к родителю #7 \| Наверх \| Cообщить модератору