[lxc-users] Create bridge between LXC Container and Ethernet device
Patrick
I'm trying to create a bridge device between my LXC Container and my Ethernet Device, which has 2 public IPs. The bridge device creation fails, as you can see here: https://paste.debian.net/hidden/c81c8832/. I want to bridge the LXC Container with the secondary IP address of the Ethernet interface. Does somebody has an idea how to do that?
Best Regards,
Patrick
Serge E. Hallyn
You're probably better off just using iptables.
> _______________________________________________
> lxc-users mailing list
> lxc-...@lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users
Guido Jäkel
a Bridge is a router device at layer 2, not a layer 3 one! At layer 2, all routing is determined by the MAC addresses, not by the IP adresses. In the other hand, an Interface is an L2-to-L3 connector, it will arbitrate between a L3 identifier (an IP) and an L2 identifier (a MAC).
In the vanilla case, you assign eth0 one or more (eth:foo) IP addresses. That means in a certain kind op picture, that the "IP stack" is attached to the MAC address of eth0: All packets catch by this MAC will be advanced to the layer 3, if the IP matches.
Next use case, you attach a Linux software bridge to an interface, say br0 to eth0. Then, eth0 is not used for any L3 job anymore. It will act at L2 in promiscuous mode, i.e. it will accept packets for any IP. To (re-)connect you "host", you have to use the **additional**, "build-in" layer 3 device of the Linux software bridge. Here, you assign the well-known IP level parameters (address, netmask, gateway) in the same way as you had done it before. This setup will work without any difference as in the vanilla case.
Now, you want to add an IP interface of an LXContainer, that's at L3. You'll use a veth device for this. It's a kind of L2 crossover wire with two L3 interface connectors at both namespaces, the host one and the container one. At container side, you'll see it as a eth0 and again, work with this at L3 in the well-known way. At the host side, you will attach it at L2 to the bridge br0 (and don't use L3, again).
On the bridge, at L2, the routing is driven by the MAC. And in the same way as a switch will act, there is a MAC-to-IP table that will forward any packing that inbounds to the bridge to the "right" attached outbound channel. Please play around with 'brctl show br0', 'brctrl showmacs br0' and 'brctl showstp br0'.
In your case, you may:
* assign 1.2.3.4/24 to br0 instead of eth0, leave IP level of eth0 unconfigured
* assign 5.6.7.8/32 to the inner side of veth0, i.e. eth0 inside the container. In the same way as on the LXC host, use 1.2.3.1 as the gateway to outbound "all other packets" to.
* configure your external net that the packets to 5.6.7.8 are forwarded to the (MAC of) eth0 of the host.
Note: There are other ways to archive the task to deliver packages to a container. But in contrast to the described above, this are more "plumber" ones that use specific low level things. You may e.g. act on level of "iptables"; in comparison this is like using a high level programming language, that compile to assembler that compile to processor binary code.
I hope this picture will give a good imagination
with Best Wishes to 2021 to you and all in this community
Guido
Andrey Repin
You said what you have, but you did not said, what you want to achieve.
--
With best regards,
Andrey Repin
Monday, January 4, 2021 18:15:52
Sorry for my terrible english...
Patrick
thanks to everyone for your answers. I was able to create a bridge so that my container gets it's own dedicated public IP, but it was a bit more complicated than expected.
> In your case, you may:
> * assign 1.2.3.4/24 to br0 instead of eth0, leave IP level of eth0 unconfigured
> * assign 5.6.7.8/32 to the inner side of veth0, i.e. eth0 inside the container. In the same way as on the LXC host, use 1.2.3.1 as the gateway to outbound "all other packets" to.
> * configure your external net that the packets to 5.6.7.8 are forwarded to the (MAC of) eth0 of the host.
That was basically the solution. But I had to set 1.2.3.4 as the gateway for the container, as my hoster has some restrictions. I found out that my hoster binds the IP addresses to specific MAC addresses, so if I try to set 1.2.3.1 as the gateway for the container, my packages just get dropped, as the MAC address of the container does not match the MAC address of the main interface. So I enabled IP forwarding, added a route for 5.6.7.8/32 on the host system, set 1.2.3.4 as the gateway and the container finally has WAN access.
There is only one problem left. The DNS doesn't work. I can ping 8.8.8.8, but I can't ping domain names. I tried it with Debian and Ubuntu, I configered my DNS using plain /etc/resolv.conf, Netplan and systemd-resolved, but I can't get it work. I tried several public DNS servers, they work on the host system, but not inside the container. I'm not sure if this is my fault or if it's because of a restriction from my hoster.
I have some "debug information" to share with you, maybe you can find a misconfiguration:
This is from the host system: https://paste.debian.net/1180073/
This if from inside the container: https://paste.debian.net/1180075/
As in my last e-mail, 1.2.3.4/24 and 5.6.7.8/32 are both public IP addresses and 1.2.3.1 is the gateway.
Thanks again to everyone.
Best Regards,
Patrick
> Patrick <mailin...@mailbox.org> hat am 01.01.2021 20:57 geschrieben:
Guido Jäkel
(eighter change the hoster or) you may install a simple forwarding DNS resolver like dnsmasq on you lxc host and configure the container(s) to use this.
Guido
Patrick
I installed dnsmasq and configured the container to use it and I could finally ping domain names. After that, I tried to install some packages, but I just got http timeouts when trying to do that, so something was still wrong.
Finally I decided to use lxc-net to create a private subnet and forward the ports I need to the container; it's working fine. I still suspect my hoster for the problems I had with the bridge setup, so I don't thought it made any sense to keep trying solving the problem. At least thats my opinion.
Best wishes to everyone on this mailing list,
Patrick
> Patrick <mailin...@mailbox.org> hat am 01.01.2021 20:57 geschrieben:
>
>
Guido Jäkel
congratulations! Now as you seems to have a running setup, you'll probably want to keep it. Said that, I want to give 5ct more on your statement of the fixed IP and MAC you have to use:
Maybe you have pay attention of the MACs used by the veth's attaching to the software bridge: It's a that the brige is using the lowest-numbered MAC of the attached devices as the MACs of the outgoing packets (see e.g. https://backreference.org/2010/07/28/linux-bridge-mac-addresses-and-dynamic-ports/). I don't know about the current state of LXC about this, but in my enviromment I let the container management script assign a certain calculated, "high-numbered" MAC (some prefix and a calculated part derived from the containers IP, in concrete: a.b.c.d -> 00:50:C2:bb:cc:dd (hex)).
In your special hoster-driven situation, it might be necessary to use for the vet's a MACs with an higher number as the one to be used with your fixed IPs to get the expected MACs to be used for the outgoing traffic. If this was the core issue, it may solve the "DNS" problem as well as the "http get"-problem.
Guido