openstack: настройка виртуальной машины со статическим IP на eth1

openstack: настройка виртуальной машины со статическим IP на eth1

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

  • Через панель управления Havana я создал сеть с подсетью 10.16.1/24, отключил шлюз, включил DHCP с диапазоном 10.16.1.100,10.16.1.120.
  • Запустил 4 экземпляра, каждый с двумя сетевыми картами: eth0 для моего обычного публичного интерфейса и eth1 для подсети 10.16.1/24.
  • зашел в две ВМ и создал eth1.cfg, настроенный для dhcp
    авто eth1
    iface eth1 inet dhcp
    
  • вошел в две другие виртуальные машины и создал eth1.cfg, настроенный со статической информацией
    авто eth1
    iface eth1 inet статический
      адрес 10.16.1.2
      сетевая маска 255.255.255.0
    
    • ifup eth1 на каждой виртуальной машине

С каждой виртуальной машины, настроенной на DHCP, я могу пинговать другую виртуальную машину, настроенную на DHCP, но не статически настроенные виртуальные машины.

Из статически настроенных виртуальных машин я не могу пинговать ни одну другую виртуальную машину.

Я также попробовал создать маршрутизатор для сети и добавить интерфейс 10.16.1.254. Но это не дало видимых изменений. Я также не могу пинговать маршрутизатор ни с одной из виртуальных машин.

Что я упускаю?

решение1

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

Вы используете neutron или nova. Можете ли вы проверить, все ли службы neutron работают нормально?

neutron agent-list

Возможно, стоит включить DHCP, чтобы хотя бы проверить, работает ли сеть.

Также виртуальные машины размещены на одном и том же физическом гипервизоре или распределены по двум. Если они распределены по двум, то используете ли вы VLAN и настроили ли вы свой коммутатор для поддержки этого?

Стоит отметить, что статическая настройка IP-адресов, не зарезервированных Openstack, работала до Icehouse, но изменения в этой версии могут вызвать у вас проблемы.

На вычислительном узле, на котором размещена одна из виртуальных машин, если вы запустите

iptables -S | more

Найдите в выводе MAC-адрес вашей виртуальной машины, например, у меня это «FA:16:3E:D0:1A:5D».

Вы увидите примерно такой вывод:

-A neutron-openvswi-see719639-9 -s 192.168.0.83/32 -m mac --mac-source FA:16:3E:BB:75:7E -j RETURN
-A neutron-openvswi-see719639-9 -j DROP

Это означает, что он будет принимать только пакеты на этот MAC-адрес, предназначенные для 192.168.0 .83/32.

решение2

Я считаю, что это согласуется с моим предыдущим экспериментом с попыткой иметь статически настроенный IP-адрес в сети с поддержкой DHCP от Neutron. Насколько я помню, то, что вы пытаетесь сделать, работает, если DHCP был отключен для этой конкретной сети Neutron, но не будет работать, если он был включен.

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

Итак, один из вариантов — использовать сеть с отключенным DHCP = для вашей сети. Другой вариант — статически настроить виртуальную машину на тот же IP, который назначил neutron.

Еще один анекдот: в одном случае я соединил внешнюю сеть с сетью openstack через определенную VLAN. В этой сети были только статически настроенные физические серверы и не было DHCP-сервера. Сеть на стороне openstack я создал с DHCP=enabled. Я сделал это с помощью ограниченного диапазона распределения, чтобы выделить IP-адреса, которые не будут конфликтовать с существующими статическими IP-адресами в том же CIDR. Поскольку neutron управляет только мостовыми портами для виртуальных машин, это означало, что другие статически настроенные устройства в сети (вне управления openstack/neutron) могли взаимодействовать с виртуальными машинами с DHCP в этой сети. Но эта настройка не позволит вам развернуть смесь статических и DHCP-виртуальных машин/гостей в той же сети neutron с DHCP=enabled.

Связанный контент