[sisyphus] delayed network start in systemd-nspawn container

[sisyphus] delayed network start in systemd-nspawn container

[Eugene Prokopiev]

Здравствуйте!

Создаю и запускаю контейнер примерно так:

machinectl import-tar container.tar.xz box0
machinectl enable box0
cp /lib/systemd/system/systemd-nspawn\@.service
/etc/systemd/system/systemd-nspawn@box0.service
subst 's/veth/ipvlan=enp0s3/g' /etc/systemd/system/systemd-nspawn@box0.service
cp /etc/systemd/network/static.network
/var/lib/machines/box0/etc/systemd/network/static.network
subst 's/enp0s3/iv-enp0s3/g'
/var/lib/machines/box0/etc/systemd/network/static.network
subst 's/10.0.0.1/10.0.0.11/g'
/var/lib/machines/box0/etc/systemd/network/static.network
machinectl start box0

После этого можно ждать сколь угодно долго, но с других физических
хостов из сети 10.0.0.0/24 контейнер не будет пинговаться, пока не
сделать machinectl login box0 и пинг кого-нибудь (сразу удачный).
После machinectl reboot box0 (но только в том случае, если до ребута
делали логин) контейнер пингуется сразу, хотя через некоторое время
может снова пропасть из сети. Ну и из хост-системы (как я писал в
предыдущем письме) он вообще не пингуется.

Это у кого-нибудь воспроизводится?

-- 
WBR,
Eugene Prokopiev

Re: [sisyphus] delayed network start in systemd-nspawn container

[Eugene Prokopiev]

6 сентября 2015 г., 22:30 Alexey Shabalin написал:

> А теперь оборотная сторона такой молчаливости, с которой я сам сталкивался.
> Пока сервер сам не пошлёт пакет, коммутатор не выучил его mac-адресс и
> ничего к нему не будет посылать. И даже может забыть сервер, если он ничего
> не будет посылать.
> Настройте, например, ntp клиента (можно systemd-timesyncd), и проверьте
> исправиться ли поведение.

Как я понимаю, время не может идти по-разному в хост-системе и в
контейнерах, поэтому в них ntp-клиент не нужен. Я попробовал сделать
нечто не менее бессмысленное: таймер с пингом ближайшего
маршрутизатора раз в минуту - и это действительно помогло :)

Странно, что с таким вроде бы очевидным эффектом я никогда не
сталкивался - ни на железных, ни на виртуальных (в т.ч. на OpenVZ)
системах.

-- 
WBR,
Eugene Prokopiev

Re: [sisyphus] delayed network start in systemd-nspawn container

[Sergey Alembekov]

On 08.09.2015 20:50, Alexey Shabalin wrote:
>     Я попробовал сделать
>     нечто не менее бессмысленное: таймер с пингом ближайшего
>     маршрутизатора раз в минуту - и это действительно помогло :)
>
>     Странно, что с таким вроде бы очевидным эффектом я никогда не
>     сталкивался - ни на железных, ни на виртуальных (в т.ч. на OpenVZ)
>     системах.
>
> А я с молчаливыми серверами с таким постоянно сталкиваюсь - пропадает на
> свиче запись из arp-таблицы.
могу ошибаться, но не для этой ли цели существует gratuitous arp?


-- 
Regards, Sergey Alembekov
jid: rt@jabber.ru

Re: [sisyphus] delayed network start in systemd-nspawn container

[Eugene Prokopiev]

8 сентября 2015 г., 22:08 пользователь Alexey Shabalin
<a.shabalin@gmail.com> написал:

>>> А я с молчаливыми серверами с таким постоянно сталкиваюсь - пропадает на
>>> свиче запись из arp-таблицы.
>>
>> могу ошибаться, но не для этой ли цели существует gratuitous arp?
>>
> да, это и использую.

А что использовать для контейнеров systemd-nspawn? Таймер с
ping/arping все-таки кажется слишком странным решением.

-- 
WBR,
Eugene Prokopiev

Re: [sisyphus] delayed network start in systemd-nspawn container

[Eugene Prokopiev]

9 сентября 2015 г., 16:26 пользователь Alexey Shabalin
<a.shabalin@gmail.com> написал:
>
>
> 9 сентября 2015 г., 15:26 пользователь Eugene Prokopiev <enp@itx.ru>
> написал:
>>
>> 8 сентября 2015 г., 22:08 пользователь Alexey Shabalin
>> <a.shabalin@gmail.com> написал:
>>
>> >>> А я с молчаливыми серверами с таким постоянно сталкиваюсь - пропадает
>> >>> на
>> >>> свиче запись из arp-таблицы.
>> >>
>> >> могу ошибаться, но не для этой ли цели существует gratuitous arp?
>> >>
>> > да, это и использую.
>>
>> А что использовать для контейнеров systemd-nspawn? Таймер с
>> ping/arping все-таки кажется слишком странным решением.
>
>
> попробовать
> sysctl net.ipv4.conf.all.arp_notify=1

внутри контейнера:

# sysctl net.ipv4.conf.all.arp_notify=1
sysctl: setting key "net.ipv4.conf.all.arp_notify": Read-only file system

-- 
WBR,
Eugene Prokopiev

Re: [sisyphus] delayed network start in systemd-nspawn container

[Anton Farygin]

On 09.09.2015 16:49, Eugene Prokopiev wrote:
> 9 сентября 2015 г., 16:26 пользователь Alexey Shabalin
> <a.shabalin@gmail.com> написал:
>>
>>
>> 9 сентября 2015 г., 15:26 пользователь Eugene Prokopiev <enp@itx.ru>
>> написал:
>>>
>>> 8 сентября 2015 г., 22:08 пользователь Alexey Shabalin
>>> <a.shabalin@gmail.com> написал:
>>>
>>>>>> А я с молчаливыми серверами с таким постоянно сталкиваюсь - пропадает
>>>>>> на
>>>>>> свиче запись из arp-таблицы.
>>>>>
>>>>> могу ошибаться, но не для этой ли цели существует gratuitous arp?
>>>>>
>>>> да, это и использую.
>>>
>>> А что использовать для контейнеров systemd-nspawn? Таймер с
>>> ping/arping все-таки кажется слишком странным решением.
>>
>>
>> попробовать
>> sysctl net.ipv4.conf.all.arp_notify=1
>
> внутри контейнера:
>
> # sysctl net.ipv4.conf.all.arp_notify=1
> sysctl: setting key "net.ipv4.conf.all.arp_notify": Read-only file system
>

Снаружи конечно.

Re: [sisyphus] delayed network start in systemd-nspawn container

[Eugene Prokopiev]

8 сентября 2015 г., 22:08 пользователь Alexey Shabalin
<a.shabalin@gmail.com> написал:

>>>     Странно, что с таким вроде бы очевидным эффектом я никогда не
>>>     сталкивался - ни на железных, ни на виртуальных (в т.ч. на OpenVZ)
>>>     системах.
>>>
>>> А я с молчаливыми серверами с таким постоянно сталкиваюсь - пропадает на
>>> свиче запись из arp-таблицы.
>>
>> могу ошибаться, но не для этой ли цели существует gratuitous arp?
>>
> да, это и использую.

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

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

Проблема в том, что контейнер с ipvlan-интерфейсом не реагирует на
широковещательные arp-запросы, а точнее они просто не добираются до
контейнера - tshark показывает их только на интерфейсе в хост-системе
(в т.ч. и на ipvlan-интерфейсе). У ipvlan-интерфейсов есть Mode L2 или
L3, в хост-системе он явно выставлен в L2, может и в контейнере это
можно как-то сделать?

И видимо штатный способ подключения контейнеров к физическому сегменту
сети - это veth c хост-концами в бридж? Мне хотелось найти что-то
похожее на venet из OpenVZ, но пока нормальной работы добиться не
удается.

-- 
WBR,
Eugene Prokopiev

Re: [sisyphus] delayed network start in systemd-nspawn container

[Eugene Prokopiev]

10 сентября 2015 г., 16:23 пользователь Alexey Shabalin
<a.shabalin@gmail.com> написал:

> 10 сентября 2015 г., 16:05 пользователь Eugene Prokopiev <enp@itx.ru>

>> Проблема в том, что контейнер с ipvlan-интерфейсом не реагирует на
>> широковещательные arp-запросы, а точнее они просто не добираются до
>> контейнера - tshark показывает их только на интерфейсе в хост-системе
>> (в т.ч. и на ipvlan-интерфейсе). У ipvlan-интерфейсов есть Mode L2 или
>> L3, в хост-системе он явно выставлен в L2, может и в контейнере это
>> можно как-то сделать?
>>
>> И видимо штатный способ подключения контейнеров к физическому сегменту
>> сети - это veth c хост-концами в бридж? Мне хотелось найти что-то
>> похожее на venet из OpenVZ, но пока нормальной работы добиться не
>> удается.
>>
> попробуйте разные варианты --private-network

Пишут, что --network-ipvlan= implies --private-network. То же
относится к macvlan, но в случае macvlan широковещательные arp-запросы
добираются до контейнера и первоначальная проблема таким образом
решается.

-- 
WBR,
Eugene Prokopiev

Re: [sisyphus] delayed network start in systemd-nspawn container

[Anton Farygin]

On 08.09.2015 20:33, Eugene Prokopiev wrote:
> 6 сентября 2015 г., 22:30 Alexey Shabalin написал:
> Странно, что с таким вроде бы очевидным эффектом я никогда не
> сталкивался - ни на железных, ни на виртуальных (в т.ч. на OpenVZ)
> системах.

коммутатор должен словить мак-адрес клиента и прописать его в таблицу 
маршрутизации.

А всё остальное хоть чуть чуть, но фонит.