LINUX.ORG.RU
Форум — Admin  

Не работает нормально IPv6 в LXC

 , , ,


0

1

Короче, у меня тахая хрень:
У меня подняты LXC-контейнеры. Один выступает в качестве роутера, другие в качистве клиентов. Если пытаться контейнер пропинговать из вне, то мы получаем: 

root@servl:~# ping6 2001:470:c3de:e0::243 -c 1
PING 2001:470:c3de:e0::243(2001:470:c3de:e0::243) 56 data bytes
From 2001:470:c3de:e0::100 icmp_seq=1 Destination unreachable: Address unreachable

--- 2001:470:c3de:e0::243 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time
Если делать пинг из контейнера, то всё насинает работать. В чём проблема? Вот конфиг одного из контейнеров: 
# Template used to create this container: /usr/share/lxc/templates/lxc-debian
# Parameters passed to the template:
# For additional config options, please look at lxc.container.conf(5)
lxc.start.auto = 1
lxc.network.type = empty
lxc.rootfs = /var/lib/lxc/router/rootfs

# Common configuration
lxc.include = /usr/share/lxc/config/debian.common.conf

# Container specific configuration
lxc.mount = /var/lib/lxc/router/fstab
lxc.utsname = router-lxc
lxc.arch = amd64
lxc.autodev = 1
lxc.kmsg = 0

lxc.network.type = veth
lxc.network.flags = up
lxc.network.name = eth0
#lxc.network.veth.pair = router-lxc0
lxc.network.link = br0
lxc.network.hwaddr = 52:55:77:00:00:01

lxc.network.type = veth
lxc.network.flags = up
lxc.network.name = eth1
#lxc.network.veth.pair = router-lxc1
lxc.network.link = br1
lxc.network.ipv4 = 10.243.0.254/24
#lxc.network.ipv6 = 2001:470:c3de:e0::1/64
lxc.network.hwaddr = 52:55:77:00:00:2

★★★★★
← Копирование данных между VPS
bird6 в LXC →

У меня работает. В контейнере живет сервер openvpn c ipv6.

2001:470:c3de:e0::100 говорит, что нет таких - вот на нем и посмотри.

А кроме пинга есть еще tracepath6/traceroute6 и ip -6

а с ipv4 аналогичных проблем нет? Может проблема чуть ниже?

vel ★★★★★
()
Последнее исправление: vel (всего исправлений: 1)
Ответ на: комментарий от vel

С ipv4 нет. Только с ipv6. Проблему решил переназначением маков. Маки делал вот этим: 

#!/bin/bash

GetMAC()
{
  if [ -n "$1" ]; then
    OID="00:16:3e"
    RAND=$(echo $1 | md5sum | sed 's/\(..\)\(..\)\(..\).*/\1:\2:\3/')
    echo "$OID:$RAND"
  else
    echo "ERROR: please supply hostname to create MAC address from, e.g.:"
    echo "       $FUNCNAME myhost"
  fi
}

GetMAC $1
Также обновил ядро на сервере до 4.7.3.

ne-vlezay ★★★★★
() автор топика
Ответ на: комментарий от vel

В 4.7.0 походу в очередной раз ipv6 сломали. Я также заметил, что если в конфиге прописать lxc.network.ipv6 = 2001:470:c3de:e0::1, потом в контейнере сделать: 

ip -6 route add ::/0 via fd00:1002:1289:10::1 src 001:470:c3de:e0::1

То ответ на комманду будет: 

Invalid argument

Если прописать в без src, то всё нормально. Но если пингануть - получим ошибку о том, что хоста не существует.
На 4.7.3 всё вроде нормально.
Также были проблемы с периодическим отвалом хоста.

ne-vlezay ★★★★★
() автор топика
Ответ на: комментарий от Deleted

Там была двойка. Просто опечатка при перепичатывании.

ne-vlezay ★★★★★
() автор топика
Ответ на: комментарий от vel

У меня после того, как я ребутнул контейнер, аобще отвалилась ipv6 сеть.

ne-vlezay ★★★★★
() автор топика
Ответ на: комментарий от vel

Короче, в LXC реально есть баг. Как обойти?
Для этого нужна адреса на интерфейс повесить алиасами. Например: 

ifconfig eth0 add fd00:10:2:2/64
ifconfig eth0 add 2001:470:c3de:e0::240/128
Иначе по каким-то причинам контеинер не отправляет neighbor descovery?

ne-vlezay ★★★★★
() автор топика
Последнее исправление: ne-vlezay (всего исправлений: 2)
Ответ на: комментарий от ne-vlezay

вряд ли это баг lxc.

Иначе по каким-то причинам контеинер не отправляет neighbor descovery?

Не отправляет или он не доходит ? tcpdump обычно дает ответ на эти вопросы. У тебя есть мост и следовательно нужно убедиться, что через него ходит мульткаст и МАС-и все есть.

А что в /sys/devices/virtual/net/br0/bridge/multicast_snooping ?

для veth не пробовал отключать аппаратную поддержку контрольных сумм ( через ethtool )?

В lxc я несколько раз наступал на грабли с МАС-адресами. Нужно запомнить, что младшие 2 бита первого байта ethernet-адреса должны быть 00. Оно в каком-то варианте не ругалось на левые адреса, но и работало как-то очень странно. IMHO 52:55:77:00:00:02 как раз из такой серии.

vel ★★★★★
()
Последнее исправление: vel (всего исправлений: 1)
Ответ на: комментарий от vel

если головной контейнер перезагрузить - то сеть отваливается. Если с контейнера сделать пинг - то но появляется в сети. Я смотрел tcpdump - там явно видно, что клиенские контейнеры не отправляют nd. В нормальном состаянии, если роутер перезагружается, должно быть так: 

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type tEN10MB (Ethernet), capture size 262144 bytes
12:26:36.228943 IP6 :: > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
12:26:36.313899 IP6 :: > ff02::16: HBH ICMP6, multicast listener report v2, 3 group record(s), length 68
12:26:36.729954 IP6 :: > ff02::1:ff42:bd66: ICMP6, neighbor solicitation, who has fe80::216:3eff:fe42:bd66, length 24
12:26:37.239945 IP6 :: > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48
12:26:37.731969 IP6 fe80::216:3eff:fe42:bd66 > ff02::16: HBH ICMP6, multicast listener report v2, 4 group record(s), length 88
12:26:37.733863 IP6 fe80::216:3eff:fe42:bd66 > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
12:26:37.816940 IP6 fe80::216:3eff:fe42:bd66 > ff02::16: HBH ICMP6, multicast listener report v2, 4 group record(s), length 88
12:26:37.866936 IP6 fe80::216:3eff:fe42:bd66 > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
12:26:37.959916 IP6 fe80::216:3eff:fe42:bd66 > ff02::16: HBH ICMP6, multicast listener report v2, 5 group record(s), length 108
12:26:38.243944 IP6 :: > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has fd00:10:2::1, length 24
12:26:38.491936 IP6 fe80::216:3eff:fe42:bd66 > ff02::16: HBH ICMP6, multicast listener report v2, 5 group record(s), length 108
А у меня было: 
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type tEN10MB (Ethernet), capture size 262144 bytes
Понятно, что головной контейнер по каким-то причинам не делал опрос.Короче все заработало, когда я сделал: 
2001:470:c3de:e0::242 via fd00:10:2::5 dev eth1  metric 1024 
2001:470:c3de:e0::243 via fd00:10:2::2 dev eth1  metric 1024 
2001:470:c3de:e0::244 via fd00:10:2::4 dev eth1  metric 1024 
2001:470:c3de:e0::254 via fd00:10:2::3 dev eth1  metric 1024
На клиентах понятно, была прописанна немаршрутизируемая подсеть и маршрутизируемая /128. Если в lxc придётся ставить bird6 - то надо исаользовать режим multihop.

ne-vlezay ★★★★★
() автор топика
Ответ на: комментарий от vel 
root@lxc:~# cat /sys/devices/virtual/net/br0/bridge/multicast_snooping
1
root@lxc:~# cat /sys/devices/virtual/net/br1/bridge/multicast_snooping
1

и работало как-то очень странно

какие странности были?

ne-vlezay ★★★★★
() автор топика
Ответ на: комментарий от vel

в чистых netns проблема отсутствует

ne-vlezay ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Копирование данных между VPS
Admin
bird6 в LXC →