systemd / systemd

The systemd System and Service Manager
https://systemd.io
GNU General Public License v2.0
12.96k stars 3.71k forks source link

systemd-network does not match the veth- interface #979

Closed DamienRobert closed 8 years ago

DamienRobert commented 9 years ago

This is similar to issue #395, but with systemd-224

On the host: $ ip a 4: ve-arch-test@if2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 8a:5f:a8:d4:9a:9e brd ff:ff:ff:ff:ff:ff link-netnsid 0 On the container: 2: host0@if4: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state LOWERLAYERDOWN group default qlen 1000 link/ether 92:50:d9:05:b8:47 brd ff:ff:ff:ff:ff:ff link-netnsid 0

Indeed networkd is not managing ve-arch-test, but according to networkctl80-container-ve.network it should!

$ networkctl 4 ve-arch-test ether off unmanaged

Here are some more infos: $ udevadm test-builtin net_setup_link /class/net/ve-arch-test calling: test-builtin === trie on-disk === tool version: 224 file size: 7049244 bytes header size 80 bytes strings 1762716 bytes nodes 5286448 bytes Load module index timestamp of '/etc/systemd/network' changed Parsed configuration file /usr/lib/systemd/network/99-default.link Created link configuration context. ID_NET_DRIVER=veth Assertion 'udev_device' failed at src/libudev/libudev-device.c:126, function udev_device_get_driver(). Ignoring. Config file /usr/lib/systemd/network/99-default.link applies to device ve-arch-test ID_NET_LINK_FILE=/usr/lib/systemd/network/99-default.link Unload module index Unloaded link configuration context.

$ udevadm info /sys/class/net/ve-arch-test P: /devices/virtual/net/ve-arch-test E: DEVPATH=/devices/virtual/net/ve-arch-test E: IFINDEX=4 E: INTERFACE=ve-arch-test E: SUBSYSTEM=net E: SYSTEMD_ALIAS=/sys/subsystem/net/devices/ve-arch-test E: TAGS=:systemd: E: USEC_INITIALIZED=326874353 [so it looks like the ID_NET_DRIVER=veth is missing]

$ uname -a Linux feanor 4.1.5-1-ARCH #1 SMP PREEMPT Tue Aug 11 15:41:14 CEST 2015 x86_64 GNU/Linux

This is with systemd-224. On my laptop the same setup works flawlessly, and indeed this time udevadm info /sys/class/net/ve-arch-test gives me 'ID_NET_DRIVER=veth'

If I copy 80-container-ve.network to /etc/systemd/network and remove the Driver=veth there, systemd-networkd configures ve-arch-test and the network works on the container. So this looks like a problem in udev somewhere, I'll be happy to give more infos.

poettering commented 9 years ago

hmm, ve-arch-test@if2 what kind of a strange name is that? where does the @ come from? how did you create the interface?

DamienRobert commented 9 years ago

No idea! I just use systemd-nspawn -bnM arch-test and systemd-nspawn creates the interface. On my laptop the interface has the same name, but the ID_NET_DRIVER=veth is set up correctly there.

poettering commented 9 years ago

if you doo ethtool -i on the interface, what does it say?

DamienRobert commented 9 years ago

(Meanwhile I have changed the name of the container)

$ ip a 4: ve-arch-contai@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether ba:7f:31:92:12:81 brd ff:ff:ff:ff:ff:ff link-netnsid 0 inet 169.254.169.115/16 brd 169.254.255.255 scope link ve-arch-contai valid_lft forever preferred_lft forever inet 10.0.0.1/28 brd 10.0.0.15 scope global ve-arch-contai valid_lft forever preferred_lft forever inet6 fe80::b87f:31ff:fe92:1281/64 scope link valid_lft forever preferred_lft forever

(The connection is active because I have removed the condition Driver=veth from 80-container-ve.network)

$ sudo ethtool -i 've-arch-contai@if2' ethtool: bad command line argument(s)

$ sudo ethtool -i ve-arch-contai driver: veth version: 1.0 firmware-version: expansion-rom-version: bus-info: supports-statistics: yes supports-test: no supports-eeprom-access: no supports-register-dump: no supports-priv-flags: no

So the veth driver is there, even through this is not reflected by udev. By the way about the strange name, from what I remember the '@foo' is used to declare aliases to an interface. I have no idea why there would be an alias there...

poettering commented 8 years ago

I figure the problem is with this line actually from your earlier dump:

Assertion 'udev_device' failed at src/libudev/libudev-device.c:126, function udev_device_get_driver(). Ignoring.

Not sure what's going on there... @teg you reworked that, any idea?

SjonHortensius commented 8 years ago

hmm, ve-arch-test@if2 what kind of a strange name is that? where does the @ come from? how did you create the interface?

OT: This is normal, I have the same names using network-macvlan or network-veth. Using Archlinux with latest everything

crequill commented 8 years ago

Same problem here with systemd 225. All was working fine with systemd 218. My containers has no more network with veth. Archlinux on host and containers. One container is working with macvlan interfaces but I have to configure them by hand: netctl refuses to see them.

Here is an example with veth: On the host : 18: ve-ognanrecoted: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 1a:e8:50:ad:9f:c9 brd ff:ff:ff:ff:ff:ff inet 192.168.66.1/32 scope global ve-ognanrecoted valid_lft forever preferred_lft forever inet6 fe80::18e8:50ff:fead:9fc9/64 scope link valid_lft forever preferred_lft forever

On the container: 2: host0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 36:15:87:7b:9a:dd brd ff:ff:ff:ff:ff:ff inet 192.186.66.10/24 scope global host0 valid_lft forever preferred_lft forever inet6 fe80::3415:87ff:fe7b:9add/64 scope link valid_lft forever preferred_lft forever

For netctl in container, interface host0 doesn't exist.

More infos in container: /sys/class/net see the host interfaces $ ls /sys/class/net/ enp3s1f0 enp3s1f1 enp8s2 lo ve-ognanrecoted

But ip see the veth interface: $ ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: host0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 36:15:87:7b:9a:dd brd ff:ff:ff:ff:ff:ff inet 192.186.66.10/24 scope global host0 valid_lft forever preferred_lft forever inet6 fe80::3415:87ff:fe7b:9add/64 scope link valid_lft forever preferred_lft forever

It's impossible to ping host from container or container from host. Network unreachable.

More infos from host: $ udevadm test-builtin net_setup_link /class/net/ve-ognanrecoted calling: test-builtin === trie on-disk === tool version: 225 file size: 6656088 bytes header size 80 bytes strings 1714568 bytes nodes 4941440 bytes Load module index timestamp of '/etc/systemd/network' changed timestamp of '/usr/lib/systemd/network' changed Parsed configuration file /usr/lib/systemd/network/99-default.link Created link configuration context. ID_NET_DRIVER=veth Assertion 'udev_device' failed at src/libudev/libudev-device.c:126, function udev_device_get_driver(). Ignoring. Config file /usr/lib/systemd/network/99-default.link applies to device ve-ognanrecoted ID_NET_LINK_FILE=/usr/lib/systemd/network/99-default.link Unload module index Unloaded link configuration context.

$ udevadm info /sys/class/net/ve-ognanrecoted P: /devices/virtual/net/ve-ognanrecoted E: DEVPATH=/devices/virtual/net/ve-ognanrecoted E: ID_NET_DRIVER=veth E: ID_NET_LINK_FILE=/usr/lib/systemd/network/99-default.link E: IFINDEX=18 E: INTERFACE=ve-ognanrecoted E: SUBSYSTEM=net E: SYSTEMD_ALIAS=/sys/subsystem/net/devices/ognanrecoted E: TAGS=:systemd: E: USEC_INITIALIZED=127718673102

Same message : Assertion 'udev_device' failed at src/libudev/libudev-device.c:126, function udev_device_get_driver(). Ignoring.

poettering commented 8 years ago

So, there was quite a fuckup with network namespaces in nspawn, which is fixed now in git. Closing this one hence, since I am confident this is fixed now. Feel free to file a new bug if the issue persists with the upcoming version of systemd.