Closed aseering closed 10 years ago
Hi @aseering, thanks for reporting this.
Yes, you need an updated ip
command...
I'm working on a new project, "Plumber", that will have the same features as Pipework but without requiring host installation (and avoiding all those issues). Stay tuned ;-)
PS: nice github avatar :D
Thanks :-)
I look forward to Plumber!
@aseering I can confirm that the RDO kernel + iproute enabled functionality for ip netns
commands.
OK, closing this ticket since there's nothing else to do here :-)
(Except for me to find some time to hack on Plumber...)
Hi Jérôme,
I am having troubles using pipework on CentOS 6.6. I have installed iproute from OpenStack and updated all packages.
When I start a container with the following command, it runs without any error, but it cannot access network through eth0: pipework eth0 $(docker run -d mycontainer /bin/bash) 10.4.1.121/24
Network settings inside the container: 13: eth0: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP link/ether 02:42:ac:11:00:04 brd ff:ff:ff:ff:ff:ff inet 172.17.0.4/16 scope global eth0 inet6 fe80::42:acff:fe11:4/64 scope link valid_lft forever preferred_lft forever 15: eth1@if2: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UNKNOWN link/ether 2a:4c:97:76:61:d6 brd ff:ff:ff:ff:ff:ff inet 10.4.1.121/24 scope global eth1 inet6 fe80::284c:97ff:fe76:61d6/64 scope link valid_lft forever preferred_lft forever
Routes: Destination Gateway Genmask Flags Metric Ref Use Iface 10.4.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0 0.0.0.0 172.17.42.1 0.0.0.0 UG 0 0 0 eth0
ping 10.4.1.120, ping 10.4.1.1 - Destination Host Unreachable.
When I run the following commands on the Docker host, the host looses network connection: ip addr del 10.4.1.120/24 dev eth0 ip link add link eth0 dev eth0m type macvlan mode bridge ip link set eth0m up ip addr add 10.4.1.120/24 dev eth0m route add default gw 10.4.1.1
The resulting interfaces: 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000 link/ether 00:50:56:9d:12:3b brd ff:ff:ff:ff:ff:ff inet6 fe80::250:56ff:fe9d:123b/64 scope link valid_lft forever preferred_lft forever 4: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN link/ether ca:29:ac:2d:d3:47 brd ff:ff:ff:ff:ff:ff inet 172.17.42.1/16 scope global docker0 inet6 fe80::c829:acff:fe2d:d347/64 scope link valid_lft forever preferred_lft forever 5: eth0m@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN link/ether d2:1d:f8:4f:82:db brd ff:ff:ff:ff:ff:ff inet 10.4.1.120/24 scope global eth0m inet6 fe80::d01d:f8ff:fe4f:82db/64 scope link valid_lft forever preferred_lft forever
Routes: 10.4.1.0/24 dev eth0m proto kernel scope link src 10.4.1.120 172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.42.1 default via 10.4.1.1 dev eth0m
Can you please help?
If you're trying to ping from the Docker host, it's normal (it's a shortcoming of macvlan interfaces). Otherwise... Try to open a different issue (that one is closed, I hadn't seen it before) and we'll figure this out ! :-)
This came up on the Docker mailing list a while back; posting it here just for reference:
pipework doesn't seem to be able to map new Ethernet devices into containers on stock CentOS 6.5.
The error is as follows:
My understanding is that the CentOS 6.5 kernel gained network-namespace functionality, but that the bundled "ip" command did not.
The Internets claim that upgrading to the OpenStack RDO version of the "iproute" package may resolve this issue. I haven't tested this personally.
I would expect the same problem to affect RHEL 6.5 users too?
This is a reasonably-common stock environment that works with Docker but not Pipework. Hopefully this issue will either lead to pipework working, or to people discovering and testing the OpenStack RDO workaround.