[systemd-devel] systemd-nspawn network ping

[Kai Krakow]

Am Mon, 29 Feb 2016 16:38:59 +0800 (CST)
schrieb kennedy  <kennedyhan at 163.com>:

> I think it will be routed, I tied ping 169.254.x.x container to
> container, and it's successed. And, I created the systemd-nspawn
> container after 5 minus ago, the container's host0 network auto turns
> ip on 169.254.x.x rather than 10.0.0.x .

No, it's not routed. You can ping from container to container because
they are connected to the same network segment (via the bridge, which
is a virtual switch - well, that's layer2 routing of course). A ping
won't leave the bridge: Try to ping from within the container to
something else in your LAN (remove the masquerading first, disable
DHCP, or use the source parameter on ping). It shouldn't work.

If you run "sudo ip addr" it will show link scope on these addresses,
not global.

You expectation was "host scope" - packets won't leave the host. A host
scope network is 127.0.0.0/8: Try running a web service on
127.0.0.2:80, now go to the other container and try curl on that
address: won't work because 127/8 has host scope.

Host scope: local loopback
Link scope: local network segment
Global scope: can pass segment boundaries

IPv6 has an additional site scope: Packets won't pass outbound network
segments (read: don't leave via the public external interface of a
boundary/edge router).

https://en.wikipedia.org/wiki/Link-local_address

> At 2016-02-29 15:40:10, "Kai Krakow" <hurikhan77 at gmail.com> wrote:
> 
> Hello!
> 
> 
> This is link local IP. You can see it like 127.0.0.0/8 but for the
> whole network segment: it won't be route thus it never leaves the
> bridge. I think you can safely ignore it tho I also think there is a
> way to deactivate assigning such addresses in networkd. AFAIK it's
> called APIPA.
> 
> 
> Regards,
> Kai
> 
> 
> kennedy <kennedyhan at 163.com> schrieb am Mo., 29. Feb. 2016 um 07:43
> Uhr:
> 
> Thanks! it works!
> but I had a little question.
> In my container, I run `route -n` it show me 3 result ,they are:
> 
> 
> Kernel IP routing table
> Destination     Gateway         Genmask         Flags Metric Ref
> Use Iface 0.0.0.0         0.0.0.0         0.0.0.0         U
> 2048   0        0 host0 10.0.0.0        0.0.0.0
> 255.0.0.0       U     0      0        0 host0 169.254.0.0
> 0.0.0.0         255.255.0.0     U     0      0        0 host0
> 
> 
> What's the "169.254.0.0" comes from ? I'v never configured that.
> 
> 
> and when I add the "--network-veth" option on systemd-nspawn, the
> "169.254.0.0" it's disappeared.
> 
> 
> ------
> Yours Sincerely
> Han
> 
> 
> 
> At 2016-02-29 00:26:54, "Kai Krakow" <hurikhan77 at gmail.com> wrote:
> >Am Sun, 28 Feb 2016 23:41:22 +0800 (CST)
> >schrieb kennedy <kennedyhan at 163.com>:
> >
> >> how to ping container to container each other in systemd-nspawn ?
> >> I've tried --network-veth option but it doesn't work enough.
> >
> >You need to join all host-side veth interfaces into the same bridge.
> >Make two files for systemd-networkd:
> >
> ># 99-bridge-cn.netdev
> >[NetDev]
> >Name=br-containers
> >Kind=bridge
> >[Match]
> >Name=br-containers
> >
> ># 99-bridge-cn.network
> >[Network]
> >Address=10.0.0.1/24
> >DHCPServer=yes
> >IPForward=yes
> >IPMasquerade=yes
> >
> >Then "systemctl --edit systemd-nspawn at .service" to contain the
> >following:
> >
> >############
> >[Service]
> >ExecStart=
> >ExecStart=/usr/bin/systemd-nspawn --quiet --keep-unit --boot \
> >--link-journal=try-guest --private-network \
> >--network-bridge=br-containers --machine=%I
> >############
> >
> >This will add all your container veth devices to the same bridge
> >which you configured in systemd-networkd. You should now be able to
> >ping each other.
> >
> >You may need to adjust a few more settings for your needs. I'd
> >recommend to add nss-mymachines (see man page).
> >
> >
> >-- 
> >Regards,
> >Kai
> >
> >Replies to list-only preferred.
> >
> >_______________________________________________
> >systemd-devel mailing list
> >systemd-devel at lists.freedesktop.org
> >https://lists.freedesktop.org/mailman/listinfo/systemd-devel


-- 
Regards,
Kai

Replies to list-only preferred.