GitLab

SlapOS provides to each partition dedicated TAP interface, so that an instance could organize internal networking. In practice this is used by KVM software release and here in ors-amarisoft, where we feed to eNB such TAP interface for CPRI-based radio unit so that eNB, in turn, could provide access to CPRI Control and Management channel via provided TAP.

However there is a problem: SlapOS provides only one TAP interface per instance, while we need to have one TAP for each Radio Unit.

-> Solve this problem by creating TAP "subinterfaces" per each RU ourselves.

The interfaces we create are full TAP interfaces, just we name them with prefix based on main interface, and we allocate only part of address space of sole SlapOS TAP to each subtap. For example if SlapOS provided us slaptap16 with 2401:5180:0:66:a200::/71 IPv6 range and we want to split it for 2 radio units, we'll be splitting it into 3 regions as follows:

slaptap16: split 2401:5180:0:66:a200::/71 by 2
preserve         2401:5180:0:66:a200::/73
-> slaptap16-1   2401:5180:0:66:a280::/73
-> slaptap16-2   2401:5180:0:66:a300::/73

Here we preserve 2401:5180:0:66:a200::/73 for usage on original slaptap16, and we create slaptap16-1 and slaptap16-2 with correspondingly allocated address range subparts for the RUs.

The splitting is done easily but depends on having networking administration capability to be able to work. We solve this with employing /opt/amarisoft/setcap, which we already use for dnsmasq, and with compiled trampoline program because setcap does not really work directly on scripts.

To avoid hard dependency on having network capabilty rights, we fallback to using regular SlapOS slaptap in case there is only one RU.

ru/lopcomm/* and enb.cfg are adapted straightforwardly, but dnsmasq adaptation is left to a later step not to mix everything into one pile.

/cc @jhuge, @lu.xu, @xavier_thompson, @Daetalus