On Thu, Jul 4, 2019 at 1:19 PM Jim Thompson via Lists.Fd.Io <jim= netgate....@lists.fd.io> wrote:
> > On Jul 1, 2019, at 4:44 AM, Steuer Heribert <ste...@patronas.com> wrote: > > Hello, > > > > I am trying to understand what the current status of the router plugin in > vppsb is. It seems not to compile with any recent version of VPP. > > There is not much value in a data plane implementation without a proper > control plane. Can you guys please enlighten me about the current status > of the plugin or whether it was replaced by any other implementation that > enables tools like Bird or FRR to inject routes into the VPP FIB? > > > > Thanks lot for your help, > > Heri > > > Heri, > > First, your question has been asked and answered several times on vpp-dev: > Well, I'd make a distinction between "received a response from someone on the list", and "answered". Thus far, the responses have been at best disappointing, and at worst, display a clear disconnect between the VPP developers, and the people using VPP (or intending on using VPP who cannot now due to lack of support for this project). > > > https://lists.fd.io/g/vpp-dev/topic/issue_in_installing_router/16635086?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,16635086 > > > https://lists.fd.io/g/vpp-dev/topic/building_router_plugin/10641656?p=Created,,,20,1,0,0::,,,0,0,0,10641656 > > > https://lists.fd.io/g/vppsb-dev/topic/questions_about_the_router/10642802?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,1,20,10642802 > > There is more of this type of thing in the archives. > > Second, several vendors maintain private forks of the router plugin, so > it’s obviously possible to make it compile, and run. > If you are aware of these specifically, can you provide (a) which vendors those are, (b) contacts, and (c) whether any submissions back to the main non-forked tree have been contributed (and either accepted or rejected)? > > This said, the router plugin is the “short path” to control plane > functionality, but there are reasons it’s in the sandbox, and it will > likely never be part of VPP proper. > So, I don't really have a problem with it not being in VPP proper, so long as it is maintained. It serves a very specific purpose, and does so adequately, if/when it compiles. It has not been maintained to keep parity with VPP, and I think everyone asking about it, is interested in the minimum amount of effort to keep it viable in the short term. > > Basically: it’s architecturally ugly, and the more you try to fix it, the > more difficult the problems become. As an example, you’ll eventually want > to be able to mirror the interface state to bird or frr, as they see the > tap interfaces. This rabbit hole of this type of issue goes very deep. > This ugliness is addressable via multiple means. I think the complaints about support in the short term would probably diminish if long-term plans to provide *some* way of integrating with FRR (and possibly BIRD) were being discussed. I have seen complaints about the ugliness, but not any discussion on a way forward that addresses those issues. I have some suggestions on better solutions, which may already be feasible to do with a minimum of effort by someone familiar with the core of VPP itself (i.e. VPP developers.) Some of the possibilities (some of these have caveats or may not be feasible to be used in some environments): - Bifurcated drivers - the NIC presents itself with two PCIe IDs instead of one ID. Have the VPP use one ID, have the host (and FRR) use the other ID. - The downside is, two MACs are present, and two IP addresses are needed, one for FRR, one for VPP. - This is NOT a good solution, especially for use on actual production routers, where restrictions on MAC addresses and IPs exist, like Internet Exchange Points (IXPs). - Possibly using the "virtual function" modes of NICs, for intercepting the 5-tuples for specific protocols/ports (like BGP as TCP/179, plus other host-specific protocols like SSH - This might be possible using a general mode on the basis of the host's IP addresses - This is a low-level (driver) equivalent to the kernel's IPTABLES functionality - I haven't played with this at all, so can't even be sure this would work - Bridged connection to the host IP stack - Needs to have some handling upstream, by VPP, to figure out where the frame is destined, based on destination IP address - Or, may need to have internal hidden MAC addresses (MAC masquerading?) - Ideally would use Ethernet link state propagation (not sure if that is the right term); transceivers often have this mechanism, for letting the device on one side of a link learn about the link state on the other side of the transceiver (which is technically a two-port bridge) - Both (either) of these also require that the FRR (software router) "talk" to VPP, to pass updates to the routing table - FRR already has built-in support for use of a separate device/socket for such communication; it is a configuration item for the running FRR router. - There are two supported standards, one of which is "netlink" (which the "netlink" plug-in in vppsb has the code for), I don't recall the other one. - This would be a dedicated socket/pipe rather than having to "sniff" /dev/netlink the way the plug-in does - There might also be a need for some kind of internal-only "ethernet" link between the host stack and the VPP routing element(s), that the host can point its default route at, so it isn't necessary for FRR to install the BGP routes into the host's own routing table (this reduces the load on the OS/kernel, as well as avoids duplicating the netlink update packets) At this point, I am interested in (a) seeing if the core VPP developers are interested/willing/able to take this on, and (b) how many folks on the mailing lists are interested in having this capability put into the CORE of VPP (rather than being a sandbox item). I recall seeing a request for router/netlink to be incorporated into the mainline vpp code, which was never approved. So, saying this is an open source project is kind of disingenuous if the maintainers won't accept the contributed code. Implementing the code in isolation, rather than being accepted upstream, isn't really open source, since EVERYONE who wants this functionality would have to do the same work, independently, rather than being able to share their code via this project. And no, the protocol as a plug-in is not acceptable to the FRR/quagga/BIRD community. The routing update processing is a de-facto standard, supported by all the major software router projects: netlink. The netlink plug-in is there; this doesn't have to be via the tap-inject thing, it can be some other method (such as a socket or named pipe). All I'm asking for is to put into the main VPP code base, so it inherits updates to all the required parts, and will continue to compile as VPP gets updated. Right now, attempting to build these plugins fails, and folks actively using these plugins are STUCK on vpp 18.07 (the only one I am able to build, and then only with a fair bit of tweaking for some slight broken-ness.) Thanks for listening, and with all due respect. Brian > For protocols that run over UDP, (and OSPF), VPP’s punt interface is one > path forward. > > You can’t punt TCP, so BGP would need to be retrofit on top of VPP’s host > stack. TCP-MD5 needs to be implemented in the host stack before a > standards-compliant BGP could be accomplished. > > Another path is to implement a protocol as a plugin. This is how we’ve > implemented VRRP (protocol 112). > > VPP is an open source project, so you’re free to implement via one of > these or another method, as you choose. > > Jim > > p.s. perhaps you only meant to engage in hyperbole, but I’ve found VPP > quite useful without FRR or bird or any other dynamic routing protocol. > They’re nice to have, but not required for many use cases. > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > > View/Reply Online (#13449): https://lists.fd.io/g/vpp-dev/message/13449 > Mute This Topic: https://lists.fd.io/mt/32309215/1550117 > Group Owner: vpp-dev+ow...@lists.fd.io > Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [ > brian.peter.dick...@gmail.com] > -=-=-=-=-=-=-=-=-=-=-=- >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#13457): https://lists.fd.io/g/vpp-dev/message/13457 Mute This Topic: https://lists.fd.io/mt/32309215/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
