Home » International » Russian » Описание устройства сети (Как устроена вирт. сеть в OpenVZ?)
| Описание устройства сети [message #36819] |
Wed, 22 July 2009 11:49  |
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  |
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 могут переполниться.
Надеюсь, я обстоятельно ответил на интересующие вас вопросы? 
|
|
|
|
| Re: Описание устройства сети [message #36839 is a reply to message #36819] |
Thu, 23 July 2009 07:34 |
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 |
maratrus
Messages: 1495
Registered: August 2007
Location: Moscow
|
Senior Member |
|
|
Здравствуйте еще раз,
Не стесняйтесь, спрашивайте, постараюсь ответить.
| Quote: |
зачем на venet0 в контейнере адрес 127.0.0.1 (такой же, как на loopback)
|
Этот адрес ставится по историческим причинам, связанным с cовместимости с одной из панелей управления (не помню какой ), то есть ей так удобней управлять 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 и тем более, его нет в ядре . Давайте отвлечемся от деталей реализации и рассмотрим эту проблему с общесетевой точки зрения.
Допустим у вас есть компьютер, в котором настроено два сетевых интерфейса 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 |
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 и тем более, его нет в ядре . Давайте отвлечемся от деталей реализации и рассмотрим эту проблему с общесетевой точки зрения.
Допустим у вас есть компьютер, в котором настроено два сетевых интерфейса 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 |
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 #36857 is a reply to message #36843] |
Fri, 24 July 2009 11:56 |
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 #36859 is a reply to message #36857] |
Fri, 24 July 2009 12:37 |
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 |
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. Это сделано намеренно, дабы фильтровать траффик, поступающий внутрь контейнера.
получается как бы незадокументированная фича  . Этот момент где-то настраивается? (В плане отключить проверку для опр-го VE с хранением этой настройки в конфиге VE, чтобы автоматом работал при миграции.) Не хотелось бы использовать устройства 2-го уровня, где на 100% работа для 3-го.
Про брижд и veth еще не читал, поэтому сказать пока ничего не могу 
[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 |
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 #36881 is a reply to message #36878] |
Mon, 27 July 2009 08:51 |
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 |
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 |
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 #36907 is a reply to message #36905] |
Wed, 29 July 2009 12:14 |
lithium
Messages: 78
Registered: April 2007
|
Member |
|
|
Смотрел на разницу между страницами, не догадался вниз пролистать
Спасибо за подсказку, но есть несколько неясных моментов:
Не нашел в 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 |
RXL_
Messages: 147
Registered: July 2009
Location: Moscow/Russia
|
Senior Member |
|
|
Я вот тоже думаю, что оригинальная документация слишком поверхностно освещает вопросы сети. Мне интересно было бы провести серию экспериментов на базе изучения док и скриптов, но может это будет изобретением велосипеда?
... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
|
|
|
|
|
|
|
|
| Re: Описание устройства сети [message #38729 is a reply to message #36819] |
Thu, 21 January 2010 14:56 |
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 |
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 |
|
|
|
Goto Forum:
Current Time: Sat Nov 09 03:49:22 GMT 2024
Total time taken to generate the page: 0.03372 seconds
|
OpenVZ Forum
Members
Search
Help
Register
Login
Home
