...
macvlan with Additional IP - allows you to have, a dedicated network interfaces (to the outside world) but actually only use one real physical network card. Unlike using a bridge this will not have the cpu overhead and need for your network card to work in promiscuous mode. This article builds on the work done in the introductory LXC article.
I actually use both techniques together.
| Warning |
|---|
Make sure to change the password or better remove the default ubuntu account generated by the lxc creation script before making the container accessible to the Internet. |
This will get better over time, ie compared to Solaris where you just tell the container to use a public IP address and the macvlan or bridging is done for you.
Port Forwarding using IP Tables
You might want to use one IP Address on the host and then map specific ports out from the containers. As a pre-requisite you will need to setup Static LXC Assigned IP address.
...
| Code Block | ||
|---|---|---|
| ||
sudo iptables -t nat -D PREROUTING -p tcp -i eth0 --dport 22 -j DNAT --to-destination 10.0.3.11:23 |
bridge with Additional IP Address
...
macvlan with Additional IP Address
Here's the Use Case,
| Panel |
|---|
For further isolation you may have purchased an additional IP address. For example run Apache on your host using port 80 and then also run Apache inside one of your containers also requiring port 80. Since it is not possible to have port 80 twice on the same IP you opt to purchase a second IP. In most hosting services this is not expensive, but they will likely not give you a dedicated network card. In this example we purchase an additional static IP from the hosting company and use the same network card as the host. |
| Note |
|---|
| Hopefully this will get better with LXD, but this is quite cumbersome compared to Solaris where you just tell the container to use a public IP address. |
The most viable options, I understand are using bridge or a dedicated vlan.
With macvlan you configure the container to directly use the public IP address without the overhead of changing the network card to promiscuous mode. Once and have a lower CPU overhead. Once setup the macvlan gets it's own MAC address. This only works if there are no restrictions on the network which set's static IPs based on the hosts' MAC address. Usually this is only the case with the initial primary IP provided by the hosting company.
The containers can reach the network and each other, but not the host. Even though the host may be on the same network. I am not sure why this is the case (maybe security?) but do not have a need to solve this use case at the moment. Macvlan has many modes, but from my readings bridge mode is most appropriate.This is by design of macvlan. The container network cards (Sub-interfaces) on the same host (parent) cannot communicate with each other. ALL frames from sub-interfaces are forward out through the parent interface. Even physcial switches that reflect the frames back in will get dropped.
If you had previously assigned a static IP to the container using /etc/lxc/dnsmasq.conf make sure to remove the entry (I believe you also need to restart the host).
...
More in depth and discusses outbound NAT so containers can communicate to other container public IPs -http://blog.codeaholics.org/2013/giving-dockerlxc-containers-a-routable-ip-address/
Bridge versus Macvlan - http://hicu.be/bridge-vs-macvlan