Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Look at supporting ipvlan #2000

Closed
stgraber opened this issue May 5, 2016 · 13 comments

Comments

5 participants
@stgraber
Copy link
Member

commented May 5, 2016

ipvlan seems like an ideal replacement for macvlan in a whole bunch of cases, to the point where it can be used as a complete bridge replacement for cases where you want to connect to a physical network.

@stgraber stgraber self-assigned this May 5, 2016

@stgraber stgraber added the Feature label May 5, 2016

@stgraber stgraber added this to the soon milestone May 5, 2016

@stgraber

This comment has been minimized.

Copy link
Member Author

commented May 5, 2016

The best way to support this would be through LXC as a new network device type there, though we can also set it up ourselves until then and just pass it with the phys type.

@eugenesan

This comment has been minimized.

Copy link

commented May 12, 2016

@stgraber
Great idea, ipvlan support would be a godsend for setups with WiFi on host.

I've tried to manually configure it but without success:

ip link add ipv0 link wlp58s0 type ipvlan mode l3
lxc profile device set default eth0 parent ipv0
lxc profile device set default eth0 nictype physical
lxc start vm0
lxc exec vm0 bash
ifconfig eth0 10.0.0.1/24 up
ip route add default dev eth0
ping 192.168.1.1 (TIMEOUT)

What I am doing wrong?

P.S.
Docker seems to have experimental support for ipvlan: https://github.com/docker/docker/blob/master/experimental/vlan-networks.md#ipvlan-l3-mode-example
In addition there is a nice article on subject: http://networkstatic.net/configuring-macvlan-ipvlan-linux-networking/

@stgraber

This comment has been minimized.

Copy link
Member Author

commented May 12, 2016

I have a branch that adds ipvlan support but I'm yet to have it work in a useful way anywhere.

There are also a bunch of very annoying limitations of ipvlan which may make it basically useless for LXD.

@eugenesan

This comment has been minimized.

Copy link

commented May 12, 2016

That's sad.
This feature was my only hope for using LXD with WiFi.
I'll continue to follow this topic in case some thing will come up.

Thanks.

@stgraber

This comment has been minimized.

Copy link
Member Author

commented May 12, 2016

Yeah, I tried with wifi last week and I could see traffic getting into the container but couldn't send anything out, so similar to macvlan in that regard...

@stgraber

This comment has been minimized.

Copy link
Member Author

commented Jul 27, 2016

So I have/had a branch that does this but it doesn't really give us anything as the MAC isn't stable and so container IP keeps changing. In my tests, it also didn't work on authenticated wifi in either l2 or l3 mode.

So closing this as macvlan provides the same features as far as we're concerned and has the same limitations but not the MAC address problem.

@stgraber stgraber closed this Jul 27, 2016

@stgraber stgraber modified the milestone: soon Aug 14, 2016

@phsm

This comment has been minimized.

Copy link

commented Feb 28, 2017

I vote for the ipvlan feature.
It allows to accumulate many IPs into single MAC-address, it is crucial when you have, like, 8000 containers spreaded over 10 or 20 machines - not every access-level switch can handle that much addresses in the forwarding table. With using ipvlan, it would be single MAC-address per all the containers within a host.

I can help you with testing/debugging it..

@stgraber

This comment has been minimized.

Copy link
Member Author

commented Feb 28, 2017

The problem is that containers configure themselves by using DHCP so things don't work so well when the MAC is the same or some non-stable value.

@abcfy2

This comment has been minimized.

Copy link

commented Dec 7, 2017

Hi @stgraber . Sorry to bump up this issue. Is there any simple ways to bridge WIFI interfaces for now? I can't find any official docs about it. I'm using lxd 2.20 on Ubuntu 16.04.

  driver: lxc
  driver_version: 2.0.8
  kernel: Linux
  kernel_architecture: x86_64
  kernel_version: 4.10.0-40-generic
  server: lxd
  server_pid: 26904
  server_version: "2.20"
  storage: zfs
  storage_version: 0.6.5.9-2
@stgraber

This comment has been minimized.

Copy link
Member Author

commented Dec 7, 2017

No, wifi cannot be bridged, with normal bridges, or macvlan or ipvlan, that's because of the way wifi authentication works.

With some cards you can actually bridge wifi, but this requires a completely open wifi network, without any security or MAC filtering in place.

In general if your host is on wifi, you should be using routing to have your containers reachable from your network, setting up a route to your containers' subnet through your wifi connected host on your gateway.

@s3rj1k

This comment has been minimized.

Copy link
Contributor

commented Jun 8, 2018

@stgraber I would like to implement this feature (ipvlan) using manual IP assignment from config (no DHCP), would you consider merging this then code is stable?

@phsm

This comment has been minimized.

Copy link

commented Jun 18, 2018

Voting for the ipvlan feature again.
Seems thats not much to do in code since it initializes in the same way as macvlan does.

As for unaviability to configure ipvlan hosts via DHCP: not everyone needs DHCP, you know.. Ipvlan support might be added with "alarm alarm, experimental feature, use on your own risk" badge or something like that..

@stgraber

This comment has been minimized.

Copy link
Member Author

commented Jun 18, 2018

Feel free to send a branch and we'll review it but I don't expect us to add any other manual IP configuration fields to the nic device type for this so IP config would need to happen from inside the container.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.