Re: [vpp-dev] VPP Router Plugin or alternatives
On Thu, Jul 4, 2019 at 1:19 PM Jim Thompson via Lists.Fd.Io wrote: > > On Jul 1, 2019, at 4:44 AM, Steuer Heribert 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 supp
Re: [vpp-dev] VPP Router Plugin or alternatives
> On 8 Jul 2019, at 22:23, Brian Dickson wrote: > > > > On Thu, Jul 4, 2019 at 1:19 PM Jim Thompson via Lists.Fd.Io > wrote: > > On Jul 1, 2019, at 4:44 AM, Steuer Heribert 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). So, did i get it right that you expect that "VPP developers" should start working on feature which you "VPP user" need to address your disappointment? > > > 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. So, you expect that somebody maintains it for you? why? what is his incentive to do so? People are typically maintaining some specific feature because they are interested in using it and they see a value in open source collaboration. It think best way to make feature maintained is to do the work right and convince others contributors that this is not throw-over-the-fence code. You will be happy as feature is maintained, we will be happy as we will have one valuable member of the community. Not being able to write code is not excuse, as you can always find somebody to do it for you. > > 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. Who is "everyone" and why do you think think that any vpp contributor or committer should work on feature you are interested in instead of working on the feature that person is interested in. > > > 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 "virtu
Re: [vpp-dev] VPP Router Plugin or alternatives
On Mon, Jul 8, 2019 at 3:39 PM Damjan Marion wrote: > > > > On 8 Jul 2019, at 22:23, Brian Dickson > wrote: > > > > > > > > On Thu, Jul 4, 2019 at 1:19 PM Jim Thompson via Lists.Fd.Io netgate@lists.fd.io> wrote: > > > > On Jul 1, 2019, at 4:44 AM, Steuer Heribert 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). > > So, did i get it right that you expect that "VPP developers" should start > working on feature which you "VPP user" need to address your > disappointment? > > It is unclear to outside observers (users and potential contributors) what the official relationship is between vpp and vppsb (and in particular the netlink and router plugins, or the plugin framework(s) generally. If you had some good piece of documentation somewhere, there would be much less frustration, I'm sure. IMHO, the pre-existence of these plugins doesn't really rise to the level of "start working" on a feature. I believe the main problems with the plugins not compiling has more to do with the "meta" elements (makefiles or equivalent), plus parts that require parallel maintenance (things like struct references, re-organization of stuff). These should be a lot less work for someone not familiar with the newer kinds of build environments. I'm an old-school type that is familiar with "./configure; make; make install" kinds of build steps. I'm not averse to learning new things, but if someone already is doing this routinely as part of the core VPP project, I think it would be a very light load to keep netlink and router plug-ins in a "mostly un-supported except for ensuring they compile" level of support. Also, note the references immediate below, by the previous respondent. They newest of those was for 18.04, and many of them were 17.x release work-arounds or instructions. AFAICT, nothing newer than 18.07 can be fixed without a lot of time and effort, coming in cold. > > > > > > 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. > > So, you expect that somebody maintains it for you? why? what is his > incentive to do so? People are typically maintaining some specific feature > because they are interested in using it and they see a value in open source > collaboration. > I was under the impression that keeping unmodified code "in sync" would not be that difficult, and of great value to the larger community of folks using VPP. The value of VPP is best measured by the number of folks using it. I believe a non-trivial number of folks have basically stumbled across VPP from the links shared from the FRR project (alternate forwarding planes). If you don't want those people using VPP, I don't understand your rationale. Most of the people who come here from that origin, are not looking to add BGP to VPP. They are looking to add VPP to BGP. The BGP is not optional, but the VPP very much is (it is basically a performance boost, but without BGP is useless to them.) > > It think best way to make feature maintained is to do the work ri
Re: [vpp-dev] VPP Router Plugin or alternatives
I would follow the build instructions in vppsb/router/README.md. I found it
helpful to do the unsophisticated:
$ cd vppsb
$ rm -rf *
$ git checkout .
so that I would clear out references to automake 1.15 as I have a newer
automake, version 1.16.1.
Then the netlink part should configure, build, and install fine.
For the router directory, I got tap_inject_node.c to build by adding
#include
But tap_inject_netlink.c needs more help due to API changes, for example,
/home/burts/vpp3/build-data/../router/router/tap_inject_netlink.c: In
function ‘add_del_neigh’:
/home/burts/vpp3/build-data/../router/router/tap_inject_netlink.c:114:22:
error: ‘ethernet_arp_ip4_over_ethernet_address_t’ {aka ‘struct
’} has no member named ‘ethernet’
clib_memcpy (&a.ethernet, n->lladdr, ETHER_ADDR_LEN);
^
/home/burts/vpp3/build-root/install-vpp_debug-native/vpp/include/vppinfra/string.h:180:44:
note: in definition of macro ‘clib_memcpy’
#define clib_memcpy(d,s,n) memcpy_s_inline(d,n,s,n)
I don't know if I have the time or knowledge to progress, but it looks like
you should be able to progress without much knowledge of cmake and ninja.
Focus on the nitty gritty and hopefully somebody can help with the API
changes if you need that.
Burt
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#13460): https://lists.fd.io/g/vpp-dev/message/13460
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]
-=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] vppctl makes VPP hang-up occasionally
Hi all, We found that VPP itself freeze once a day under using "vppctl" command repeatedly. I think this is a kind of spin-lock problem but I can't understand the root cause. See here for details. https://jira.fd.io/browse/VPP-1711 If this goes on, It's hard to operate VPP as production service. So I need help to fix this issue. Could anyone help/suggest to this issue? Thanks, Tatsumi. ― 立�� �v介 ヤフ�`株式会社 テクノロジ�`グル�`プ システム�y括本部 クラウドプラットフォ�`ム本部 技�g1部 コンピュ�`ト TEL: 03-6898-3081 mail: ytats...@yahoo-corp.jp ― Yusuke Tatsumi Compute team, Cloud Platform Division, System Management Group Yahoo Japan Corporation Direct: +81 (3) 6898 3081 mail: ytats...@yahoo-corp.jp -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#13461): https://lists.fd.io/g/vpp-dev/message/13461 Mute This Topic: https://lists.fd.io/mt/32402610/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
