Ipvlan l3 mode routing

Hi.

First of all, I am wondering if LXD 4.1 ipvlan works with l3s (Symmetric mode) mode like an L3 device (router).

When the l3s mode operates like an l3 device device, two containers are created and the created two containers are assigned different band IPs (ex. container01: 10.10.20.#, cotainer02: 172.16.10.#). In this case, how does the container communicate with the outside world (e.g NAT, static routing)?

Thank you

IPVLAN is a bit of a strange beast when it comes to thinking about routing.

Inside the container we just add a device route as the default gateway so that all packets using the default route are just dumped into the ipvlan interface and they are then handled by the host.

However the host isn’t acting like a ‘router’ in the ‘normal’ sense in that the ipvlan parent interface is always used to route outbound packets (so the host’s routing table is only consulted to lookup the next hop on that interface, rather than using the host’s routing table to decide which interface to use to route the packet, which you may expect if the host is acting as a true router).

Also when packets leave the host in l3s mode, they dont go through the FORWARD chain like packets that are routed normally. Instead they are processed through the OUTPUT and POSTROUTING chains as if they are the host’s own packets leaving.

However as you can add SNAT rules to POSTROUTING chain, you should be able to NAT outbound packets (although if you’re doing that then it rather defeats the main purpose of using ipvlan of exposing a container’s IP onto the wider network).

You can mix subnets between different containers and they will be able to communicate fine with each other. However the wider network will likely having trouble using the non-local-subnet IPs the same as if you added non-local-subnet IPs as aliases on the host’s interface.

First, Thank you for your explain.

Honestly, I didn’t fully understand what you explained.

I know the purpose of using ipvlan as below.

  1. Parent interface is wireless
  2. Physical switch limits the number of MAC addresses allowed on a port (port security)
  3. interface performance drops because exceeded the number of different MAC addresses

If I am misunderstanding the purpose of using ipvlan or if there is any purpose I do not know, please explain.

I wanted to test it myself, but I couldn’t. It seems that I can’t update the lxd with snap yet.
When can I update lxd with snap? i will contact you again if testing is possible.

And one more question. Not ipvlan.
If the vhost_vsock module is supported in the kernel, is nested vm possible in lxd?

The last centos vm kernel update was also performed for nested vm testing. vhost_vsock is supported in main line kernel 5.6.12 (latest kernel).

For me, English is a difficult language. Please understand if the sentence is a little strange.

Thank you again for your kind and detailed answers.

Your use-case for ipvlan is valid and makes sense. But I wasn’t sure about your question about using IPs in a subnet that is not part of your wireless network and using NAT.

If you were going to use NAT to hide your containers behind the host’s IP then you could use LXD’s default private bridge lxdbr0, as it does this out of the box (with the added benefit that the host can also communicate with the containers which ipvlan doesn’t allow).

Also take a look at the routed NIC type as it can be used similarly to ipvlan, but uses normal routing behaviour and the host can communicate with the containers as well.

As for your question about vhost_vsock please could you post this as a separate thread so that the answer can be found by other people in the future.

Thanks
Tom

standard source natting / nat masquerade also limits the number of mac addreses presented to your switch.

same as if you used the default lxdbr0 bridge

stuff on the outside of your host will only see your hosts mac address to reply to

Thank you Jon for your explain ^^.

I mentioned static routing and NAT for ipvlan’s routing method because it doesn’t do dynamic routing (e.g, IGRP, OSPF, etc …) except for the router.

The reason for using ipvlan’s l3s mode…
to use a different band IP than the default network band is as follows.

The purpose of this is to allow containers to exist in the same network separated from each other by service type in which host is running on the lxd overlay network.

Because as far as I know, it is impossible to configure the same network band on two or more hosts in the fan network.

Thank you for writing answer while busy.