[lxc-users] Understanding IPVLAN and LCX cross namespaces

[webman at manfbraun.de]

Hello!

 

Probably, someone may give me a hint.

In the following, I try to describe my configuration.

 

I have a VPS with two switchports and two network
interfaces in Linux (wich is debian stretch - so no LXD).

I want to move one of the interfaces, which itself
has multiple ip-addresses, into a LXC VM - thats easy.

But the different ip-addreses should only appear
in separate lcx vms, which would make iptables
management and separation a lot easier. I want to end
up with one slave VM for one IP and security services
running in the container, which uses the eth port.

So I started experimenting, but I cannot make this work.

First, I start two containers, the one, which
uses the eth1 from the host, is named "portsplit"
and its network type is "phys". The other one has
network type "empty" and is named "slave1".

If both containers are running, I start this script
on the host:

---

 

ip l set eth1 down

 

ip link add ipvlan1 link eth1 type ipvlan mode l3

ip l set ipvlan1 up

ip link set ipvlan1 netns $(lxc-info -pHn slave1)   ##Move IF into container.

 

ip link set eth1 up

ip link set eth1 netns $(lxc-info -pHn portsplit)

This is just the beginning to understand the stuff.

After this, I log in to the containers and apply a

>systemctl restart networking.

The "portsplit" itself does NOT(!!) have an ip-address.
it uses the following route:

default dev eth1 scope link

The slave has the two following routes:

default via 192.168.26.254 dev ipvlan1 onlink ##To LAN-GW

192.168.26.0/24 dev ipvlan1 proto kernel scope link src 192.168.26.239 ##OWN

 

I am then mapping the containers ip-namespaces into
/var/run/netns, so that I can access them easily.

 

I am running tcpdump on the LAN-GW (192.168.26.254),
on the "portsplit" (with NO ip) and on slave1 with
ip 192.168.26.239.

The packets are leaving the slave1, crossing the portsplit
and are reaching the LAN-GW, which answers with an ARP (who-is),
crossing the portswitcher and come back to slave1 - which never
answers.

And thats right, because ipvlan blocks all broadcast (the default,

which "ip -d l" shows is "NOARP") for the sub-interfaces.

 

On the gateway, there is never a mac address for slave1
in the arp table, the entry is flagged "(incomplete)".


Naturally, the ISP will allow me only the mac address,
the physical (eth1) interface will have.

 

>From my understanding, the eth1 must act with an arp-reply
with his own mac-address (which is the same for all
interfaces on the ipvlan!) and internally send the
packet to the linked ipvlan1.

 

If someone could probably explain, this would made
me happy.

 

I experimented too with:

#net.ipv4.conf.all.accept_source_route = 1

#net.ipv4.conf.enp4s0f1.proxy_arp = 1

#net.ipv4.conf.enp4s0f1.proxy_arp_pvlan = 1

 

BTW, if I switch th ipvlan creation to "mode L2",
everythings starts working. But my ISP would see
different mac addresses and the wholy broadcast
would flood all "slave" 's …. This was the reason
for the "mode L3".

 

Any help would be really welcomed!

 

uname-a: 4.17.0-0.bpo.1-amd64
Just to be sure, I updated iproute2 from backports (Now: 4.18).

 

Just a last note.

What I see accidentally: The ipvlan kernel module is not
loaded. Ok, I saw this with lsmod, but I do not known,
what this mean (later loaded or dynamically?). On the host,
I just made a modprobe ipvlan and it is there, but no references.

 

Thanks,
Manfred

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20180928/06db18df/attachment.html>