Назад | Перейти на главную страницу

Мост Linux сломан после обновления, нет идей / мест для поиска (теперь 4.20.0-arch1-1-ARCH) (работает в 4.19.13)

ОБНОВИТЬ:

Отойдя на некоторое время от проблемы, я понял, что есть одна вещь, которую я мог бы изучить или протестировать, чего у меня не было.

Возврат к более старой версии Linux позволил мне обойти эту проблему, НО по-прежнему вызывает вопрос: чего не хватает, чтобы эта функция работала в новых версиях Linux?

Linux nas 4.19.13-1-lts # 1 SMP вс, 30 декабря 07:38:47 CET 2018 x86_64 GNU / Linux

Orig:

Вопрос: Что еще я должен проверить, чтобы попытаться изолировать и исправить это, чтобы мостовая сеть с виртуальной машиной LXC снова работала?

Для устранения этой проблемы я отключил нормальный запуск контейнера LXC. Вместо этого я запускаю их вручную с дополнительным ведением журнала.

lxc-start --logfile = / var / log / lxc / debug. $ (date +% Y% m% d-% H% M% S) .log --logpriority = DEBUG -F -n имя контейнера

Хосты LAN могут пинговать / разговаривать с HOST HOST могут пинговать / разговаривать с хостами LAN

Два разных следа

На мосту: как и ожидалось

tcpdump -pi bridge port 67 or port 68 or icmp[icmptype] == icmp-echo or icmp[icmptype] == icmp-echoreply

(time) IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from (mac) (oui Unknown)...

Тем не менее, он не передается / не перенаправляется на физическое сетевое устройство:

tcpdump -i bridge_IF  port 67 or port 68 or icmp[icmptype] == icmp-echo or icmp[icmptype] == icmp-echoreply
(no dhcp packets)

Мост выглядит правильно

# brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.bridgemac          no              enpNs0
                                                        enpNs0
                                                        vethXXXXXX

Там все выглядит в основном так, как ожидалось.

(provided by iptables-nft)
ebtables -L
Bridge table: filter

Bridge chain: INPUT, entries: 0, policy: ACCEPT

Bridge chain: FORWARD, entries: 0, policy: ACCEPT

Bridge chain: OUTPUT, entries: 0, policy: ACCEPT

nft list ruleset
table bridge filter {
        chain INPUT {
                type filter hook input priority -200; policy accept;
        }

        chain FORWARD {
                type filter hook forward priority -200; policy accept;
        }

        chain OUTPUT {
                type filter hook output priority -200; policy accept;
        }
}
table ip filter {
        chain INPUT {
                type filter hook input priority 0; policy accept;
        }

        chain FORWARD {
                type filter hook forward priority 0; policy accept;
        }

        chain OUTPUT {
                type filter hook output priority 0; policy accept;
        }
}

Также элементы конфигурации sysctl и module.

# cat /etc/sysctl.d/*
net.bridge.bridge-nf-call-iptables=0
kernel.unprivileged_userns_clone=1

# lsmod | grep table
nf_tables             147456  2 nft_reject_ipv6,nft_reject
nfnetlink              16384  1 nf_tables
x_tables               49152  1 ip6t_REJECT

# cat /etc/modprobe.d/*
blacklist ip_tables
blacklist iptable_filter
blacklist iptable_nat
blacklist ip6_tables
blacklist ip6table_filter
blacklist x_tables
install br_netfilter

-

Пока вроде все должно работать, но это не так.

(container) # ip addr add x.x.x.x/y dev z
(container) # ping VMHOST
Works, ping reply.
(container) # ping ROUTER-GW
Nope, Destination Host Unreachable

ОДНАКО теперь происходит что-то действительно неожиданное (скорее, не происходит).

(VHMOST) # ping ROUTER-GW
Nope, Destination Host Unreachable
Also, the connection to the VMHOST (often) times out at this point.

Этот последний поворот, кажется, указывает на проблему в чем-то, что я до сих пор не проверял, я не уверен, связано ли что-нибудь в пространствах имен Linux с этой проблемой.

Просмотр журналов LXC не дает ничего очевидного, но я скопировал все, что, как мне казалось, МОЖЕТ быть связано. На самом деле ничего не говорит об этом, но мне интересно, не перепутались ли как-то пространства имен.

lxc-start VM TIMESTAMP.390 DEBUG    network - network.c:setup_hw_addr:2767 - Mac address "REDACTED" on "eth0" has been setup
lxc-start VM TIMESTAMP.393 INFO     conf - conf.c:mount_entry:2039 - No such file or directory - Failed to mount "/sys/fs/fuse/connections" on "/usr/lib/lxc/rootfs/sys/fs/fuse/connections" (optional)
lxc-start VM TIMESTAMP.510 INFO     utils - utils.c:lxc_mount_proc_if_needed:1239 - I am 1, /proc/self points to "1"
lxc-start VM TIMESTAMP.536 WARN     conf - conf.c:lxc_setup_devpts:1641 - Invalid argument - Failed to unmount old devpts instance
lxc-start VM TIMESTAMP.536 DEBUG    conf - conf.c:lxc_setup_devpts:1678 - Mount new devpts instance with options "gid=5,newinstance,ptmxmode=0666,mode=0620,max=1024"
lxc-start VM TIMESTAMP.537 INFO     conf - conf.c:setup_personality:1741 - Set personality to "0x0"
lxc-start VM TIMESTAMP.537 DEBUG    conf - conf.c:setup_caps:2550 - Dropped mac_admin (33) capability
lxc-start VM TIMESTAMP.537 DEBUG    conf - conf.c:setup_caps:2550 - Dropped mac_override (32) capability
lxc-start VM TIMESTAMP.537 NOTICE   conf - conf.c:lxc_setup:3745 - The container "VM" is set up

Linux salt 4.20.0-arch1-1-ARCH #1 SMP PREEMPT Mon Dec 24 03:00:40 UTC 2018 x86_64 GNU/Linux
# pacman -Qs lxc
local/lxc 1:3.1.0-1

Хех, переходя по всем ссылкам в письме, чтобы убедиться, что другие люди, которые попадают в это письмо, знают, что делать.

Подать заявление: https://marc.info/?l=linux-netdev&m=154696956604748&w=2

Исправлено для меня, это связано с fq pacing