Доброго времени суток!Есть хост-система под виртуализацию, 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-ы.Подскажите пожалуйста, какого фига другие интерфейсы этой же машины "присваивают" айпи и как вообще такую ситуацию разрулить?
> и как вообще такую ситуацию разрулить?http://ru.wikipedia.org/wiki/%D0%A1%D0%B...
У сетевого устройства 2 уровня модели OSI, не может быть IP адреса,
то что это можно сделать в лине, не значит, что этим надо пользоваться.
>> и как вообще такую ситуацию разрулить?
> 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.
Ну второй вариант, это собрать все виртуальные интерфейсы в бридж,
а наружу выводить через маршрутизацию.Кстати, сделай
# ifconfig -a | grep HWaddr
и удивись.
> Ну второй вариант, это собрать все виртуальные интерфейсы в бридж,
> а наружу выводить через маршрутизацию.мне этот вариант не подходит.
"бридж из физического интерфейса и виртуальных", как способ выброса виртуалок в реальную сеть - стандартный способ и для квм-а, и для 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, dhcpbond1, 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:54brctl 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
Уу-у-у-у, как всё замороченно, в такой каше ищи сам где накосячил.
Самое быстрое - всё сломать и строить заново: один езернет, один бонд, один бридж и
добалять по одному.
> Уу-у-у-у, как всё замороченно, в такой каше ищи сам где накосячил.
> Самое быстрое - всё сломать и строить заново: один езернет, один бонд,
> один бридж и
> добалять по одному.я именно это и сделал в реплае №2: оставил только один бонд из em1+em2, бонд айпи получает по дхчп. плюс бридж trunk из физического p3p1, без айпи адресов.
результат - как в начале. при обновлении адреса получаю арп-реплай с мака p3p1 о том, что на нем уже висит этот айпи - обновление айпи проваливается.
> результат - как в начале. при обновлении адреса получаю арп-реплай с мака
> p3p1 о том, что на нем уже висит этот айпи -
> обновление айпи проваливается.Простое (и общепринятое) решение - не использовать DHCP для конфигураци хоста. Ты с ним согласишься после первой же ночной поездки в датацентр после сбоя питания.
Разумеется, техника может победить здравый смысл - man arptables.
> Простое (и общепринятое) решение - не использовать DHCP для конфигураци хоста. Ты
> с ним согласишься после первой же ночной поездки в датацентр после
> сбоя питания.подобные риски мне известны, но в моей ситуации значение падение этого интерфейса не блокирует работу остальных систем (отваливается только мониторинг и контроль хост-системы) + есть доступ к drac по другим каналам, поэтому я считал dhcp вполне подходящим инструментом для этого случая.
но, раз какого-либо логичного объяснения этому феномену никто не предложил - переделал на статику, оставив dhcp на случай перезаливки хоста кикстартом.> Разумеется, техника может победить здравый смысл - man arptables.
тогда уж проще статику использовать, менее костыльное решение. меня собственно больше интересовала причина возникновения этой проблемы - какого фига другой интерфейс, на котором айпи не было никогда, вдруг отвечает, что айпи принадлежит ему.
Если больше идей нет - тогда всем спасибо за помощь и дискуссию!