• Kirill Smelkov's avatar
    software/ors-amarisoft: Provide dedicated TAP interface for each Radio Unit · 49ce8ef5
    Kirill Smelkov authored
    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 capability 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.
    
    NOTE that relying on setcap is not a good in the long term and should be
         reworked once SlapOS is improved to provide ability for instances to
         request several TAP interfaces. Please see discussion at
         nexedi/slapos!1471 (comment 194356)
         for details.
    
    /cc @jhuge, @lu.xu, @xavier_thompson, @Daetalus
    /reviewed-on nexedi/slapos!1471
    49ce8ef5
libinstance.jinja2.cfg 4.6 KB