openstack: conmgure vm со статическим ip на eth1

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

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

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

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

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

Что мне не хватает?

2 ответа

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

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

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

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

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

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

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.

Другие вопросы по тегам