OpenVZ Forum


Home » International » Russian » Описание устройства сети (Как устроена вирт. сеть в OpenVZ?)
Описание устройства сети [message #36819] Wed, 22 July 2009 11:49 Go to next message
lithium is currently offline  lithium
Messages: 78
Registered: April 2007
Member
Давно не работал с OpenVZ, взялся снова настраивать, и немного растерялся (не понимаю устройства виртуальной сети). В HN конфигурация такая:
eth0 - 10.3.128.50/24 (настроил я)
lo - 127.0.0.1
venet0 - без адреса.

К контейнере, которому был присвоен ip-адрес 10.3.128.55 (с помощью --ipadd 10.3.128.55):
lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

venet0    Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:127.0.0.1  P-t-P:127.0.0.1  Bcast:0.0.0.0  Mask:255.255.255.255
          UP BROADCAST POINTOPOINT RUNNING NOARP  MTU:1500  Metric:1
          RX packets:14 errors:0 dropped:0 overruns:0 frame:0
          TX packets:14 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:1628 (1.5 KiB)  TX bytes:1137 (1.1 KiB)

venet0:0  Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:10.3.128.55  P-t-P:10.3.128.55  Bcast:10.3.128.55  Mask:255.255.255.255
          UP BROADCAST POINTOPOINT RUNNING NOARP  MTU:1500  Metric:1


таблица маршрутизации (в том же контейнере):
# ip route list
192.0.2.0/24 dev venet0  scope host
169.254.0.0/16 dev venet0  scope link
default via 192.0.2.1 dev venet0


Шлюз по-умолчанию контейнера (из него же) не пингуется:
# ping 192.0.2.1
connect: Invalid argument


Тут я что-то растерялся. Откуда взялся адрес 192.0.2.1 (и что это вообще адрес), для чего создан интерфейс venet0:0 и почему venet0 без ip-адреса? Сеть работает, но напрягает отсутствие понимания как оно устроено. Wiki посмотрел, OpenVZ-Users-Guide.pdf тоже, google: "openvz устройство виртуальной сети" смотрел, но не нашел описания устройства виртуальной сети, как это написано в документации к VMWare, например. Кто-нибудь может дать ссылку на толковое описание как оно устроено и как работает? Не разницу между venet и veth, а именно как устроена виртуальная сеть, что за адреса 192.0.2.0/24 и как ходят пакеты?
P.S. Еще непонятно, как перебрасываются пакеты из контейнера (наверное, тут Point-to-point используется (пакеты идут через цепочку FORWARD на HN), хотя маска на внешнем интрефейсе /24 и адреса 10.3.128.55 и 10.3.128.50 из одной сети) и как они возвращаются назад (что-то вроде ARP-proxy?)

[Updated on: Wed, 22 July 2009 13:23]

Report message to a moderator

Re: Описание устройства сети [message #36829 is a reply to message #36819] Wed, 22 July 2009 15:33 Go to previous messageGo to next message
maratrus is currently offline  maratrus
Messages: 1495
Registered: August 2007
Location: Moscow
Senior Member
Здравствуйте,

попробую объяснить.

venet0 - это такой девайс, в который можно посылать пакеты, и для этого совершенно не обязательно иметь ip адрес на этом девайсе. А то, что пакеты действительно заставляют ходить через venet0, можно посмотреть в выводе команды "ip r l", из которого станет ясно, что все пакеты, предназанчающиеся вашим VE должны идти через venet0. Драйвер этого девайса анализирует каждый приходящий пакет, посколько ip пакет имеет source адрес, то по нему легко можно узнать, в какую VE пакет направляется и передать этот пакет соотвествующим образом. Тут, вроде, все ясно и прозрачно. Таким образом, HN играет роль самого обыкновенного роутера.
Если другой компьютер захочет "пообщаться" с вашей VE, то он пошлет arp who-has запрос, который попадет, в частности, и на HN, поскольку подобные запросы являются broadcast запросами; как только такой запрос попадет на HN, она смекает кого хочет видеть сторонняя нода и отвечает вместо VE. Действительно, подобная техника достигается за счет proxy; убедиться в этом можно, посмотрев команду "arp -n" на HN и найдя строчки, относящиеся к поднятым VE. Подобные строчки там появляются благодаря утилите vzctl, которая заносит их в табляцу с помощью команды "ip neigh add proxy $IP_ADDR dev eth0", кстати, routes, которые отображаются командой "ip r l" на HN также есть результат работы vzctl.
route по умолчанию, который вы наблдюдаете внутри VE не несет никакой опасности, более того, он полезен, поскольку говорит идти пакету через девайс venet0, который уже внутри себя определит, что пакет идет изнутри VE и отправит согласно routing правилам на HN. Кроме того, маршрут по умолчанию настоятельно рекомедуется иметь внутри VE, поскольку neighbour таблицы VE могут переполниться.
Надеюсь, я обстоятельно ответил на интересующие вас вопросы? Smile
Re: Описание устройства сети [message #36839 is a reply to message #36819] Thu, 23 July 2009 07:34 Go to previous messageGo to next message
lithium is currently offline  lithium
Messages: 78
Registered: April 2007
Member
> Надеюсь, я обстоятельно ответил на интересующие вас вопросы?
спасибо за ответ. Однако хотелось бы манаула с картинками. Все еще непонятно зачем на venet0 в контейнере адрес 127.0.0.1 (такой же, как на loopback), зачем было использовать шлюз по умолчанию 192.0.2.1, а не адрес eth0 в HN, например, и почему сам адрес 192.0.2.1 существует где-то в недрах OpenVZ, где происходит загадочная трансляция. Это может моя личная проблема, но это напоминает Windows. Linux всегда нравился тем, что можно разобраться как оно устроено, а тут какие-то темные моменты...
Re: Описание устройства сети [message #36840 is a reply to message #36839] Thu, 23 July 2009 08:14 Go to previous messageGo to next message
maratrus is currently offline  maratrus
Messages: 1495
Registered: August 2007
Location: Moscow
Senior Member
Здравствуйте еще раз,

Quote:

Все еще непонятно


Не стесняйтесь, спрашивайте, постараюсь ответить. Smile

Quote:

зачем на venet0 в контейнере адрес 127.0.0.1 (такой же, как на loopback)


Этот адрес ставится по историческим причинам, связанным с cовместимости с одной из панелей управления (не помню какой Smile ), то есть ей так удобней управлять VE-шками. Вообще говоря, управление ip адресами на venet интерфейсе должно осуществляться через утилиту vzctl с HN, она должна разбираться, какие адреса ставить на venet, какие удалять и т.д. В противном случае (если настройка была осуществлена изнутри контейнера) после перезагрузки VE конфигурация может смениться, так как она берется из конфигурационного файла контейнера. Разрешите задать встречный вопрос, это мешает вашим приложениям? Почему вы задали этот вопрос?

Quote:

зачем было использовать шлюз по умолчанию 192.0.2.1, а не адрес eth0 в HN, например, и почему сам адрес 192.0.2.1 существует где-то в недрах OpenVZ, где происходит загадочная трансляция.


Мне кажется, вы не уловили суть моего предыдущего поста. venet драйвер не является каким-то особенным сетевым драйвером, он использует то же API, что и стандартный сетевые драйвера. 192.0.2.1 - не загадочный ip адрес, существующий в недрах OpenVZ и тем более, его нет в ядре Smile. Давайте отвлечемся от деталей реализации и рассмотрим эту проблему с общесетевой точки зрения.
Допустим у вас есть компьютер, в котором настроено два сетевых интерфейса lo, venet0, причем, как обычно, через интерфейс lo пакеты наружу не отправишь, что естественно. Единственным способ отправить пакеты во внешний мир является интерфейс venet0, который мы знаем, что имеет ти point-to-point, то есть любой пакет, переданный через этот интерфейс всегда пройдет через определенный компьютер (HN в данном случае). Какими должны быть routing правила на рассматриваемом компьютере?
Вариантов не ососбо много, а вернее один единственный: если мы хотим коммуницировать с внешним миром, мы должны отправлять пакеты в интерфейс venet0. Теперь вопрос: так ли важен адрес следующего hop'а, указанного в default путе? Грубо говоря, модель сети устроена так, что мы ответственны только за следующий hop (не будем рассматривать всевозможные опции ip пакетов), но мы знаем, что следующий hop - это всегда определенный компьютер. Поэтому стоит ли тратить усилия и узнавать его ip адрес, а вернее ip адрес на каком-то другом физическом интерфейсе, если это не имеет никакого значения с точки зрения составления таблицы маршрутов?
Не спорю, вариант составления правил маршрутизации сегодня, может вызвать много вопросов. Если у вас есть рационализаторское предложение, то, конечно же, можете его выразить, обсудим, даже баг забьем для привлечения бОльшего количества обсуждаемых масс.
Re: Описание устройства сети [message #36841 is a reply to message #36840] Thu, 23 July 2009 08:59 Go to previous messageGo to next message
lithium is currently offline  lithium
Messages: 78
Registered: April 2007
Member
Quote:
Этот адрес ставится по историческим причинам, связанным с cовместимости с одной из панелей управления (не помню какой Smile ), то есть ей так удобней управлять VE-шками. Вообще говоря, управление ip адресами на venet интерфейсе должно осуществляться через утилиту vzctl с HN, она должна разбираться, какие адреса ставить на venet, какие удалять и т.д. В противном случае (если настройка была осуществлена изнутри контейнера) после перезагрузки VE конфигурация может смениться, так как она берется из конфигурационного файла контейнера.


Это понятно, просто смущает что один и тот же ip-адрес имеют сразу два интерфейса (в контейнере).

Quote:
Разрешите задать встречный вопрос, это мешает вашим приложениям? Почему вы задали этот вопрос?


Не мешает, просто мне нужно разобраться во внутренностях системы, которой я пользуюсь, и если что-то непонятно, то не могу спокойно работать (может комплекс какой-то). Хочется увидеть что-то вроде http://www.docum.org/docum.org/kptd/ -- после этой картинки (и подобной из iptables-tutorial) iptables стало понять очень просто. В будущем это очень помогает быстро решать проблемы -- когда знаешь как что работает.

Quote:
Мне кажется, вы не уловили суть моего предыдущего поста. venet драйвер не является каким-то особенным сетевым драйвером, он использует то же API, что и стандартный сетевые драйвера. 192.0.2.1 - не загадочный ip адрес, существующий в недрах OpenVZ и тем более, его нет в ядре Smile. Давайте отвлечемся от деталей реализации и рассмотрим эту проблему с общесетевой точки зрения.
Допустим у вас есть компьютер, в котором настроено два сетевых интерфейса lo, venet0, причем, как обычно, через интерфейс lo пакеты наружу не отправишь, что естественно. Единственным способ отправить пакеты во внешний мир является интерфейс venet0, который мы знаем, что имеет тип point-to-point, то есть любой пакет, переданный через этот интерфейс всегда пройдет через определенный компьютер (HN в данном случае). Какими должны быть routing правила на рассматриваемом компьютере?
Вариантов не ососбо много, а вернее один единственный: если мы хотим коммуницировать с внешним миром, мы должны отправлять пакеты в интерфейс venet0. Теперь вопрос: так ли важен адрес следующего hop'а, указанного в default путе? Грубо говоря, модель сети устроена так, что мы ответственны только за следующий hop (не будем рассматривать всевозможные опции ip пакетов), но мы знаем, что следующий hop - это всегда определенный компьютер. Поэтому стоит ли тратить усилия и узнавать его ip адрес, а вернее ip адрес на каком-то другом физическом интерфейсе, если это не имеет никакого значения с точки зрения составления таблицы маршрутов?


Это примерно понятно, я видел в выводах ifconfig упоминания про peer-to-peer, но непонятно, почему адреса 192.0.2.1 нет ни на одном интерфейсе? В цисках, насколько я помню, для P-t-P соединений с клиентами вместо использования адреса реального интерфейса создается виртуальный адрес, который не деактивируется, если будет отключен Ethetnet, например, (и из-за этого не отвалятся клиенты), но он был виден в настройках, то есть был определенный интерфейс с этим ip. А тут как бы есть ip-адрес, который принадлежит неизвестно какому интерфейсу.

Ну и также непонятно, venet0 в HN и контейнерах -- это один интерфейс или два разных? Почему в HN у него нет ip-адреса? И почему в контейнере для него запись "inet addr:127.0.0.1 P-t-P:127.0.0.1" в выводе ifconfig указывает на то, что адрес его соседа 127.0.0.1 -- это адрес loopback в HN или контейнере (или указывает на него самого)?

В выводе ifconfig для интерфейса venet0:0 написано "inet addr:10.3.128.55 P-t-P:10.3.128.55", то есть сосед он сам?
(Тут может я чего-то не понимаю в выводе iptables, я ppp соединения в Linux не настраивал, могу просто что-то путать, а чтобы посмотреть ничего под рукой нет).


Quote:
Не спорю, вариант составления правил маршрутизации сегодня, может вызвать много вопросов. Если у вас есть рационализаторское предложение, то, конечно же, можете его выразить, обсудим, даже баг забьем для привлечения бОльшего количества обсуждаемых масс.



Надо подумать, если будут мысли -- напишу в этой теме.
Re: Описание устройства сети [message #36843 is a reply to message #36841] Thu, 23 July 2009 10:28 Go to previous messageGo to next message
maratrus is currently offline  maratrus
Messages: 1495
Registered: August 2007
Location: Moscow
Senior Member
Quote:

Это примерно понятно, я видел в выводах ifconfig упоминания про peer-to-peer, но непонятно, почему адреса 192.0.2.1 нет ни на одном интерфейсе? В цисках, насколько я помню, для P-t-P соединений с клиентами вместо использования адреса реального интерфейса создается виртуальный адрес, который не деактивируется, если будет отключен Ethetnet, например, (и из-за этого не отвалятся клиенты), но он был виден в настройках, то есть был определенный интерфейс с этим ip. А тут как бы есть ip-адрес, который принадлежит неизвестно какому интерфейсу.


Зачем нужна такая логика в OpenVZ? Процесс HN и VE исполняются на ОДНОЙ машине. Пакету не нужно никуда идти, он будет доставлен, как только будет отправлен. Очень похоже на loopback интерфейс.

Quote:

Ну и также непонятно, venet0 в HN и контейнерах -- это один интерфейс или два разных?


Есть единый код, который управляет всей машинерией. Его задачей, в частности, является виртуализация интерфейсов. Поэтому внутри VE и на HN показываются разные результаты. Представляйте себе это как будто есть два списка: интерфейсы внутри VE, интерфейсы на HN. И драйвер добавляет соответсвующие структуры в РАЗНЫЕ списки.

Quote:

Почему в HN у него нет ip-адреса?


Мне кажется вам стоит повнимательней прочесть предыдущие посты.
Re: Описание устройства сети [message #36844 is a reply to message #36843] Thu, 23 July 2009 11:16 Go to previous messageGo to next message
lithium is currently offline  lithium
Messages: 78
Registered: April 2007
Member
> Зачем нужна такая логика в OpenVZ?

Я не говорил что такая логика, я приводил пример, когда все понятно.
По остальному буду думать, спасибо за помощь.
Re: Описание устройства сети [message #36857 is a reply to message #36843] Fri, 24 July 2009 11:56 Go to previous messageGo to next message
lithium is currently offline  lithium
Messages: 78
Registered: April 2007
Member
Попробовал перечитать -- все равно черный ящик. Сейчас столкнулся с первой проблемой.

Сеть 10.3.128.0/24, шлюз 10.3.128.105, HN 10.3.128.50, контейнер с OpenVPN 10.3.128.55, настроен по wiki, OpenVPN раздает клиентам адреса из сети 17.20.0.0/16, сообщая заодно маршрут на сеть 10.3.128.0/24, VPN работает, с VPN-сервера можно пинговать клиента и наоборот (в том числе адрес 10.3.128.50). На шлюзе по умолчанию добавил маршрут на сеть 172.20.0.0/24:

ip route add 172.20.0.0/16 via 10.3.128.55 dev eth1 (интерфейс LAN).

При попытке пинговать из сети адрес VPN-клиента получаем:
From 10.3.128.50: icmp_seq=1 Redirect Host(New nexthop: 10.3.128.105)

HN решила побыть маршрутизатором, ладно, добавим маршрут на неё (что уже вынуждает потом добавлять этот же маршрут на все HN для миграции контейнера):

ip route add 172.20.0.0/16 via 10.3.128.55 dev venet0
ip route flush cache

делаем пинг на клиента с HN или из сети 10.3.128.0./24 -- в ответ тишина. Куда деваются пакеты и в чем проблема -- вообще никаких мыслей.

UPD: Добавил к контейнере с OpenVZ
iptables -A FORWARD -j LOG
в /var/log/messages ничего, когда пингуешь адрес контейнера и добавляешь правило для INPUT:
vpn kernel: IN=venet0 OUT= <2>BUG: recent printk recursion!

[Updated on: Fri, 24 July 2009 12:05]

Report message to a moderator

Re: Описание устройства сети [message #36858 is a reply to message #36843] Fri, 24 July 2009 12:15 Go to previous messageGo to next message
lithium is currently offline  lithium
Messages: 78
Registered: April 2007
Member
На всякий случай таблицы машрутизации:

На HN:
# ip route list
10.3.128.51 dev venet0 scope link
10.3.128.55 dev venet0 scope link
10.3.128.0/24 dev eth0 proto kernel scope link src 10.3.128.50
169.254.0.0/16 dev eth0 scope link
172.20.0.0/16 via 10.3.128.55 dev venet0
default via 10.3.128.105 dev eth0

В контейнере:

172.20.0.2 dev tun0 proto kernel scope link src 172.20.0.1
192.0.2.0/24 dev venet0 scope host
169.254.0.0/16 dev venet0 scope link
172.20.0.0/16 via 172.20.0.2 dev tun0
default via 192.0.2.1 dev venet0


правила iptables пустые, все разрешено.
Re: Описание устройства сети [message #36859 is a reply to message #36857] Fri, 24 July 2009 12:37 Go to previous messageGo to next message
maratrus is currently offline  maratrus
Messages: 1495
Registered: August 2007
Location: Moscow
Senior Member
Здравствуйте,

начнем с конца
Quote:

в /var/log/messages ничего, когда пингуешь адрес контейнера и добавляешь правило для INPUT:
vpn kernel: IN=venet0 OUT= <2>BUG: recent printk recursion!


эта бага уже пофикшена
http://bugzilla.openvz.org/show_bug.cgi?id=1284

Quote:

делаем пинг на клиента с HN или из сети 10.3.128.0./24 -- в ответ тишина. Куда деваются пакеты и в чем проблема -- вообще никаких мыслей.


Я думаю, я знаю в чем проблема.
venet0 не подойдет, если вы хотите использовать вашу VE как маршрутизатор, поскольку venet0 не пропускает пакеты с source адресом, не равным ip адресу, поставленному на VE. Это сделано намеренно, дабы фильтровать траффик, поступающий внутрь контейнера.
Если хотите подобную функциональность - используйте veth в бридж моде (чтобы обойти ненужное прописывание маршрутов на HN).
Re: Описание устройства сети [message #36860 is a reply to message #36859] Fri, 24 July 2009 13:27 Go to previous messageGo to next message
lithium is currently offline  lithium
Messages: 78
Registered: April 2007
Member
Спасибо за ответ, а то у меня уже голова закипала, пока пытался понять в чем причина.

> эта бага уже пофикшена
> http://bugzilla.openvz.org/show_bug.cgi?id=1284

у меня yum check-update не показывает обновлений.

> venet0 не подойдет, если вы хотите использовать вашу VE как маршрутизатор, поскольку venet0 не пропускает пакеты с source адресом, не равным ip адресу, поставленному на VE. Это сделано намеренно, дабы фильтровать траффик, поступающий внутрь контейнера.

получается как бы незадокументированная фича Sad. Этот момент где-то настраивается? (В плане отключить проверку для опр-го VE с хранением этой настройки в конфиге VE, чтобы автоматом работал при миграции.) Не хотелось бы использовать устройства 2-го уровня, где на 100% работа для 3-го.

Про брижд и veth еще не читал, поэтому сказать пока ничего не могу Wink

[Updated on: Fri, 24 July 2009 13:28]

Report message to a moderator

Re: Описание устройства сети [message #36862 is a reply to message #36860] Fri, 24 July 2009 14:06 Go to previous messageGo to next message
maratrus is currently offline  maratrus
Messages: 1495
Registered: August 2007
Location: Moscow
Senior Member
Quote:

у меня yum check-update не показывает обновлений.


Оно пофикшено, но ядра еще не зарелижены.

Quote:

получается как бы незадокументированная фича


Прошу прощения, думал, что она задокументирована на страницах
http://wiki.openvz.org/Differences_between_venet_and_veth
http://wiki.openvz.org/Virtual_network_device
однако там упоминается только broadcast траффик. Поэтому можно об этом написать явно. Если есть возможность и желание, можете написать, будем премного благодарны.

Quote:

Этот момент где-то настраивается? (В плане отключить проверку для опр-го VE с хранением этой настройки в конфиге VE, чтобы автоматом работал при миграции.)


Нет, все сделано намеренно.

Quote:

Не хотелось бы использовать устройства 2-го уровня, где на 100% работа для 3-го.


Спорный вопрос. Работа-то для 3-го уровня, но зачем её исполнять на HN, а не внутри VE? И вообще, зачем HN знать что-либо про подсеть 17.20.0.0/16?

Quote:

Про брижд и veth еще не читал, поэтому сказать пока ничего не могу Wink


Читайте, спрашивайте. Чем интереснее будут вопросы (при наличии адекватных ответов), тем более полезным окажется данный тред для других людей.
Re: Описание устройства сети [message #36867 is a reply to message #36819] Sat, 25 July 2009 08:14 Go to previous messageGo to next message
Garic1 is currently offline  Garic1
Messages: 6
Registered: July 2009
Junior Member

Уважаемый Марат, еще раз спасибо за прозрачные объяснения. Все понятно, кроме одной детали, а вот venet0:0 зачем? есть же venet0
Re: Описание устройства сети [message #36868 is a reply to message #36867] Sat, 25 July 2009 10:26 Go to previous messageGo to next message
maratrus is currently offline  maratrus
Messages: 1495
Registered: August 2007
Location: Moscow
Senior Member
Quote:

Все понятно, кроме одной детали, а вот venet0:0 зачем? есть же venet0


Алиасы (venet0:0, venet0:1, venet0:2 и т.д.) используются для того случая, когда данная VE имеет более одного ip адреса, проставленного с помощью утилиты vzctl.
Re: Описание устройства сети [message #36877 is a reply to message #36862] Mon, 27 July 2009 06:47 Go to previous messageGo to next message
lithium is currently offline  lithium
Messages: 78
Registered: April 2007
Member
> Поэтому можно об этом написать явно. Если есть возможность и желание, можете написать, будем премного благодарны.

у меня с генерацией английского текста проблемы, лучше Вы Wink

> И вообще, зачем HN знать что-либо про подсеть 17.20.0.0/16?

ну... может оно и так... Попробую сегодня освоить veth.

P.S. По поводу ядра: может как-нибудь почаще релизы делать или беты выкладывать? Я помню, когда в свое время натолкнулся на баг с bonding, хоть мне и прислали ядро с исправлением, но официального ядра с ним я так и не дождался (сменил работу). Кажется Э. Раймонд писал, что лучше почаще делать релизы Wink.
Re: Описание устройства сети [message #36878 is a reply to message #36877] Mon, 27 July 2009 07:14 Go to previous messageGo to next message
maratrus is currently offline  maratrus
Messages: 1495
Registered: August 2007
Location: Moscow
Senior Member
Здравствуйте,

Quote:

у меня с генерацией английского текста проблемы, лучше Вы Wink


По вашей страничке на opennet.ru такого не скажешь Smile .
Хорошо, будет свободное время (и не вылетит из головы) - напишу.
Re: Описание устройства сети [message #36881 is a reply to message #36878] Mon, 27 July 2009 08:51 Go to previous messageGo to next message
lithium is currently offline  lithium
Messages: 78
Registered: April 2007
Member
> По вашей страничке на opennet.ru такого не скажешь

Если это про http://lithium.opennet.ru/publicfile-patch-en.html , то это был многодневный труд с участием translate.ru и знакомых. Я могу попробовать, а Вы исправите если что не так.

Сейчас попробовал осилить veth, в wiki (http://wiki.openvz.org/Virtual_Ethernet_device) после добавления девайса (vzctl set 101 --netif_add eth0 --save) написано сделать:

1. Настроить интерфейс на HN:
[host-node]# ifconfig veth101.0 0
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/veth101.0/forwarding
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/veth101.0/proxy_arp
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/eth0/forwarding
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/eth0/proxy_arp

2. настроить ip-адрес интерфейса в CT и шлюз по-умолчанию

3. Настроить маршрут на HN:
[host-node]# ip route add 192.168.0.101 dev veth101.0

Насколько я понял, настройки, которые делают эти команды работают до перезагрузки. Чтобы сделать настройки постоянными в случае 2-го пункта нужно исправить стандартные файлы настроек сети в CT (хотя, со шлюзом по умолчанию без ip-адреса я не уверен для CentOS). Пункты 2 и 3 как сделать постоянными с помощью штатных средств не смог догадаться. Попытался создать /etc/sysconfig/vz-scripts/<VEID>.start, но он выполняется в контейнере, а не в HN, а VEID.mount выполняется тогда, когда устройство еще не создано.
Re: Описание устройства сети [message #36882 is a reply to message #36881] Mon, 27 July 2009 09:19 Go to previous messageGo to next message
maratrus is currently offline  maratrus
Messages: 1495
Registered: August 2007
Location: Moscow
Senior Member
Quote:

Насколько я понял, настройки, которые делают эти команды работают до перезагрузки. Чтобы сделать настройки постоянными в случае 2-го пункта нужно исправить стандартные файлы настроек сети в CT (хотя, со шлюзом по умолчанию без ip-адреса я не уверен для CentOS). Пункты 2 и 3 как сделать постоянными с помощью штатных средств не смог догадаться. Попытался создать /etc/sysconfig/vz-scripts/<VEID>.start, но он выполняется в контейнере, а не в HN, а VEID.mount выполняется тогда, когда устройство еще не создано.


Посмотрите раздел "Making a veth-device persistent", в нем есть ссылка на более старую версию странички, где в разделе "Making a veth-device persistent" описан способ сделать такую конфигурацию постоянной. (замечания в текущей версии не совсем для меня понятны)
P.S. (!) Я вам предлагал воспользоваться не такой конфигурацией, а той, что описывается в разделе "Virtual Ethernet devices can be joined in one bridge". То есть единственный бридж, куда входят - физический интерфейс с HN и veth интерфейсы из VE.
Re: Описание устройства сети [message #36883 is a reply to message #36882] Mon, 27 July 2009 10:21 Go to previous messageGo to next message
lithium is currently offline  lithium
Messages: 78
Registered: April 2007
Member
> Посмотрите раздел "Making a veth-device persistent", в нем есть ссылка на более старую версию странички, где в разделе "Making a veth-device persistent" описан способ сделать такую конфигурацию постоянной. (замечания в текущей версии не совсем для меня понятны)

Если Вы про ссылку http://wiki.openvz.org/w/index.php?title=Virtual_Ethernet_de vice&diff=5990&oldid=5989 , то я ходил по ней несколько раз, но не смог понять к чему она была дана в wiki -- не вижу там никакой информации по вопросу. Само устройство остается после перезагрузки, но настройки в proc и маршрут пропадают.

> Я вам предлагал воспользоваться не такой конфигурацией, а той, что описывается в разделе "Virtual Ethernet devices can be joined in one bridge".

мне казалось что использование veth решит проблему с фильтрацией обратного адреса -- тут же все на втором уровне идет.
Бридж наверное не позволит сделать (насколько я могу судить после беглого просмотра) миграцию на лету (ради чего, все собственно и затевается, наряду с быстрым бэкапом и восстановлением). То есть мне в итоге нужно получить систему, позволяющую без дополнительных действий одной-двумя командами переместить контейнер на другую машину и так же быстро/просто восстанавливать его из бэкапа, без дополнительных манипуляций на HN.
Re: Описание устройства сети [message #36884 is a reply to message #36882] Mon, 27 July 2009 10:51 Go to previous messageGo to next message
lithium is currently offline  lithium
Messages: 78
Registered: April 2007
Member
По поводу добавления в wiki, фраза в начале статьи (перед "Contents"):

"Venet discards ip-packets from container with a source address which is not corresponding to ip-address(es) of the container"

будет нормально выглядеть?
Re: Описание устройства сети [message #36905 is a reply to message #36883] Wed, 29 July 2009 11:20 Go to previous messageGo to next message
maratrus is currently offline  maratrus
Messages: 1495
Registered: August 2007
Location: Moscow
Senior Member
http:// wiki.openvz.org/w/index.php?title=Virtual_Ethernet_device&am p;diff=5990&oldid=5989#Making_a_veth-device_persistent
Там приведен пример скрипта.

Quote:

По поводу добавления в wiki, фраза в начале статьи (перед "Contents"):

"Venet discards ip-packets from container with a source address which is not corresponding to ip-address(es) of the container"



Я бы еще упомянул и про обратную сторону, то есть если пакет идет из вне внутрь VE через venet интерфейс, то также происходит отсев.
Вы про статью "Сравнение venet и veth" говорите?
А вообще, пишите, не бойтесь, если нужно будет - знающие язык люди поправят. Вы и так делает "доброе дело".
Re: Описание устройства сети [message #36907 is a reply to message #36905] Wed, 29 July 2009 12:14 Go to previous messageGo to next message
lithium is currently offline  lithium
Messages: 78
Registered: April 2007
Member
Смотрел на разницу между страницами, не догадался вниз пролистать Sad

Спасибо за подсказку, но есть несколько неясных моментов:

Не нашел в pdf описание принципа работы файла /etc/vz/vznet.conf , скорее всего, он выполняется для всех VE, не приведет ли код выхода 1 в /usr/sbin/vznetaddroute к тому что остальные VE не запустятся, т.к. в pdf написано, что ненулевые коды выходы из скриптов для VE блокируют запуск VE.

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

Может быть кроме скриптов /etc/sysconfig/vz-scripts/<VEID>.start можно сделать аналоги, которые будут отрабатываться в контексте HN после старта контейнера. Туда можно было бы поместить и добавление маршрутов, и операции с интерфейсами для контейнера в HN, и загрузку модулей (тот же tun для OpenVPN), что сейчас приходится делать на HN из /etc/sysconfig/modules (в CentOS), что тоже не сильно портабельно, и другие подобные вещи. Ну и соотв-но перемещать эти скрипты при миграции и упаковывать их при бэкапе.

Мне кажется что в моем случае проще запустить NAT и venet, добавится возни с логами при разборе полетов, но решение получится легко перемещаемым между HN (что для меня является основным приоритетом).

По поводу устройства сети, навеяло чтение документации по OpenVPN. Насколько я понял, они используют tun-модуль и эмулируют P-t-P и Ethernet устройства, причем все получается достаточно понятно. Может взять у них идеи (и часть кода)? То есть нужен venet -- используется аналог tun, нужен veth -- аналог tap. Тут правда дополнительные сложности с виртуализацией...

> Вы про статью "Сравнение venet и veth" говорите?
нет, про "Virtual network device"

[Updated on: Wed, 29 July 2009 12:17]

Report message to a moderator

Re: Описание устройства сети [message #36913 is a reply to message #36907] Wed, 29 July 2009 20:17 Go to previous messageGo to next message
RXL_ is currently offline  RXL_
Messages: 147
Registered: July 2009
Location: Moscow/Russia
Senior Member
Я вот тоже думаю, что оригинальная документация слишком поверхностно освещает вопросы сети. Мне интересно было бы провести серию экспериментов на базе изучения док и скриптов, но может это будет изобретением велосипеда?

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
Re: Описание устройства сети [message #37614 is a reply to message #36819] Thu, 01 October 2009 06:08 Go to previous messageGo to next message
sen-doc is currently offline  sen-doc
Messages: 4
Registered: September 2009
Junior Member
Чтобы данная ветка была полная надо затронуть тему виртуального бриджа. Вот его параметры:
virbr0    Link encap:Ethernet  HWaddr 00:00:00:00:00:00
          inet addr:192.168.122.1  Bcast:192.168.122.255  Mask:255.255.255.0
          inet6 addr: fe80::200:ff:fe00:0/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1322 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 b)  TX bytes:199580 (194.9 KiB)


Моя хост-система CentOS 5.3
Скажите зачем и как создается бридж на хост машине. И причасна ли к этому опенвз?
P.S. Изначально стояла ксеновское ядро.
Re: Описание устройства сети [message #37670 is a reply to message #37614] Fri, 09 October 2009 12:34 Go to previous messageGo to next message
maratrus is currently offline  maratrus
Messages: 1495
Registered: August 2007
Location: Moscow
Senior Member
A nice article
http://wiki.openvz.org/Virtual_Ethernet_device
Re: Описание устройства сети [message #38729 is a reply to message #36819] Thu, 21 January 2010 14:56 Go to previous messageGo to next message
basman is currently offline  basman
Messages: 1
Registered: January 2010
Junior Member
У хоста xx.xx.xx.15, для виртуалок адреса с xx.xx.xx.16 по xx.xx.xx.19, вопрос, какой ip адрес нужно назначить venet0? Пока сервер в локалке был, по всей видимости он получал ip адрес по DHCP от роутера (и все отлично работало, пакеты ходили из локалки на виртуалки и обратно), теперь же в стойке, при старте долго думает, и выдает ругань на venet0 (что ip адрес не получен). Шлюз xx.xx.xx.1

upd:
venet на хосте присвоил ip xx.xx.xx.15 маску 255.255.255.255, шлюз xx.xx.xx.1, перезапустил сеть, прописал маршрут:
route add -host xx.xx.xx.16 gw xx.xx.xx.15 venet0
стал ходить пинг в виртуалку xx.xx.xx.16 и обратно из хоста и виртуалку. Снаружи xx.xx.xx.16 не пингуется.

[Updated on: Thu, 20 May 2010 13:33]

Report message to a moderator

Re: Описание устройства сети [message #38742 is a reply to message #38729] Sat, 23 January 2010 10:55 Go to previous message
RXL_ is currently offline  RXL_
Messages: 147
Registered: July 2009
Location: Moscow/Russia
Senior Member
Для venet0 адрес назначать не нужно совсем - это локальный интерфейс типа raw ip, доступен NE напрямую, не виден другим NE хостам и не нуждается в ip-адресе.

Вероятно вам нужна настройка типа бриджа.
http://wiki.openvz.org/Virtual_Ethernet_device#Virtual_Ether net_devices_can_be_joined_in_one_bridge

Внешние NE хосты должны как-то узнать о существовании ваших VE-хостов. Думаю, что не лишним будет ознакомиться с принципами передачи IP-пакетов по Ethernet-сетям и протоколом ARP.


Разово настроить руками - действия такие:

0. Пусть у нас есть сеть 10.0.0.0/24, физический интерфейс eth0 с адресом 10.0.0.1, VE 101 с адресом 10.0.0.101 и маршрутизатор 10.0.0.100.

1. Надо создать ethernet-мост, добавить в него физические интерфейсы и настроить адреса и маршрутизацию.

1.1. Создаем мост и добавляем в него физический интерфейс:

HN# brctl addbr br0
HN# brctl addif br0 eth0

1.2. Удалить все адреса (в том числе и inet6) с eth0 и назначить их br0:

HN# ip link set dev eth0 down
HN# ip address del 10.0.0.1/24 dev eth0
HN# ip -f inet6 address del fe80::280:48ff:fe5d:cb65/64 dev eth0
HN# ip link set dev eth0 up
HN# ip address add 10.0.0.1/24 dev br0
HN# ip link set dev br0 up

1.3. Прописываем дефолтный маршрут (он слетел на предыдущем шаге):

HN# ip route add default via 10.0.0.100

2. В VE добавляем интерфейс, запускаем (если еще не запущено) VE, добавляем этот интерфейс к мосту и конфигурим сеть VE:

HN# vzctl set 101 --netif_add eth0
HN# vzctl start 101
HN# brctl addif br0 veth101.0
HN# vzctl enter 101
VE101# ip address add 10.0.0.101/24 dev eth0
VE101# ip link set dev eth0 up
VE101# ip route del default
VE101# ip route add default via 10.0.0.100

Если сразу не заработает, подождите пару минут - это связано с работой моста и ARP.

Логично, что настроить надо через скрипты конфигурации, чтобы после перезагрузки или настройки восстановились.
Касательно включение интерфейса vethXXX.Y в мост, смотрите тут:
http://wiki.openvz.org/Virtual_Ethernet_device#syntax_vzctl_ version_.3E_3.0.22
Quote:
bridge is an optional parameter which can be used in custom network start scripts to automatically add the interface to a bridge.


... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.

[Updated on: Sat, 23 January 2010 17:55]

Report message to a moderator

Previous Topic: Вопрос по оптимизации
Next Topic: [SOLVED] /dev/null permissions
Goto Forum:
  


Current Time: Tue Oct 15 07:34:21 GMT 2024

Total time taken to generate the page: 0.04814 seconds