Macvtap networking

[hellt]

this branch is an attempt to parametrize connection mode that vrnetlab uses

this is done by adding --connection-mode variable to launch.py that takes vrxcon (default) and bridge value.

values macvtap and ovs can be added, if someone will add the appropriate code and make it work

linux bridge

linux bridge based networking is added, based on original work in vrnetlab#188

The downside of this driver is that it doesn't pass through LACP and BPDU packets

ovs

ovs can pass bpdu, but to make it work inside the container requires some trickery. I haven't proceed.

macvtap

The macvtap connection mode will create macvtap interafaces for each ethX interface (where X !=0) and instruct qemu to use this interface.

The problem is that I can't yet make the datapath workin, I see the packets reaching the vrnetlab macvtap interface, but I can't verify that the packets reach qemu's interface.

The complication is that qemu doesn't natively support macvtap interfaces, thus its needed to manually open /dev/tapX device and pass the file descriptor to the qemu.

I wonder if @networkop or @plajjan you have some courage to look at that?

PS. here is the docker command I used:

docker create --rm -i --privileged -v /dev:/dev --name vr-sros vrnetlab/vr-sros:20.10.R1 --connection-mode macvtap
docker network connect net1 vr-sros
docker start -ia vr-sros

[hellt]

my assumption is that somehow the opening process of the TAP device finishes, thus the file descriptor doesn't really point to the device

https://github.com/hellt/vrnetlab/pull/2/files#diff-90a8e5693dd578cdb77e5881950a539f63419037f994bea412fb6a741542a1ebR291

[networkop]

so did you make macvtap work @hellt ?

[hellt]

Nope, left the code in the codebase No errors from qemu, but datapath was not working

…

On Tue, 19 Jan 2021, 15:07 Michael Kashin, ***@***.***> wrote: so did you make macvtap work @hellt <https://github.com/hellt> ? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABLKV5POXNZYGZV75CC5PP3S2WGYXANCNFSM4WHIFIWA> .

[hellt]

Looking at the macvtap-cni https://github.com/kubevirt/macvtap-cni/blob/master/pkg/util/netlink.go#L237 I suppose the root cause might be that I was creating macvtap interface in the container namespace, whereas it might be needed to be created on the host, and then moved into the container netns

[networkop]

yeah, good point. although the namespace-aware macvtap kernel patch seems to address this issue.

[hellt]

If you will have your go around macvtap I'd be eager to hear your experience So far I spent too much time on :/ will let others to try it out

…

On Tue, 19 Jan 2021, 18:12 Michael Kashin, ***@***.***> wrote: yeah, good point. although the namespace-aware macvtap kernel patch seems to address this issue. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABLKV5IB7FQWXJUWDN2GLTLS2W4RFANCNFSM4WHIFIWA> .

[networkop]

yeah, i might give it another go, later in the week.
do you have some script to set up a test environment? e.g. something that would bring up two container with cirros inside them?

[hellt]

Not really, I've been using this branch with SR OS images to test it.

…

On Tue, Jan 19, 2021 at 6:39 PM Michael Kashin ***@***.***> wrote: yeah, i might give it another go, later in the week. do you have some script to set up a test environment? e.g. something that would bring up two container with cirros inside them? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABLKV5KC4WWNIMQNZ55YQNTS2W7W5ANCNFSM4WHIFIWA> .