Two other questions/suggestions on how to handle aspects of the router plugin (at least for FRR), and/or multiple instances:
(1) FRR supports methods other than netlink for updating a FIB. One of those is FPM (I think forwarding plane manager?). FPM allows netlink format packets, or another format (can't recall what that is right now). That might support enough indirection for this, but I'm not sure. (2) I believe FRR (and other BGP implementations) support the use of multiple kernel tables as the destination for routing updates. I think the VRF stuff might support per-VRF tables. If there was a way for VPP to associate a namespace with a kernel table instance, that might be all that is needed (presuming vppctl commands are exposed for controlling the association itself). I'm very interested in this as well, but not yet actively working on it. Brian On Fri, Dec 7, 2018 at 1:00 PM Justin Iurman <justin.iur...@uliege.be> wrote: > Guys, > > Any plan to use memif interfaces for router plugin ? Also, is there a plan > to implement a multi-instance mode ? Because, for now, "enable tap-inject" > only works for one router, and not others, when I run multiples VPP > instances on a same machine. > > Thanks, > Justin > > Hi Jan, > > > > A VPP packet trace and the output from “sh ip mfib’ would help diagnose > your multicast packet drops. > > > > /neale > > > > *From: *<vpp-dev@lists.fd.io> on behalf of Jan Hugo Prins | BetterBe < > jpr...@betterbe.com> > *Date: *Wednesday, 11 April 2018 at 20:54 > *To: *Ole Troan <otr...@employees.org> > *Cc: *vpp-dev <vpp-dev@lists.fd.io>, Ray Kinsella <m...@ashroe.eu> > *Subject: *Re: [vpp-dev] Maintainer router plugin > > > > Hi Ole, > > I really don't mind that you all derailed my discussion. I think a good > design discussion is a good thing. Especially when the end result is a > better product, or in this case, better integration between products. > What I have found with respect to OSPFv3, is that the OSPF multicast > packets are being dropped at the router edge. See my earlier message with > the PCAP file. > > I currently have no idea why my OSPFv2 routers are not properly installed > in the VPP IP FIB, while they are in the Linux IP FIB. > > Jan Hugo Prins > > On 04/11/2018 07:37 PM, Ole Troan wrote: > > Jan Hugo, > > > > But this basically means that, for now, it won't be possible to create a BGP > router with a combination of FRR and VPP doing both IPv4 and IPv6 with OSPF > and BGP. > > Or do you see possibilities to make OSPFv3 work? > > Sorry, for derailing your thread and making it into an architectural > discussion. ;-) > > If you ask my opinion, I would probably prefer it not to go into the main > repository. > > > > That said, if it works for OSPFv2, one shouldn't think it would be that hard > to make it work for OSPFv3 either. > > Probably some ARP/ND issues? Ray, would you know? > > > > Best regards, > > Ole > > > > > > > > Jan Hugo Prins > > > > > > On 04/11/2018 03:20 PM, Ray Kinsella wrote: > > Hi Ole, > > > > I agree - but completely reinventing the wheel is not a the best course > either. These are tried and tested implementations and are worth reusing, I > do agree that integrating through the Linux Kernel is not ideal. > > > > We developed the router plugin to show that integration was possible we never > claimed that it was the 'best' way to integrate either. > > > > Plugging a Quagga/FRR/Bird etc into VPP/HC is definitely the better path. > Historically it has been hard with Quagga due to GPL licensing, I understand > that FRR is the easiest path. > > > > Ray K > > > > On 11/04/2018 09:33, Ole Troan wrote: > > Hi Jan, > > > > Is someone actively maintaining the router plugin? > > I'm not a big fan of the router plugin. > > The starting point of the router plugin is "how can you take an unmodified > routing protocol implementation and make it work with VPP". > > That leads to all kinds of complexities as the two methods they tried shows. > > > > If we change the premise does the solution space look better? > > > > I think we could change the routing protocol implementation to talk directly > with VPP's API for interfaces / interface events, it programs the VPP FIB > directly. > > Then it could send and receive packets somewhat similar to what we have for > the punt Unix domain socket. > > We might need a better punt path mechanism, where a Linux application can > register for a particular IP protocol (like 89 for OSPF) on a particular > interface. But that should be easy to do. > > > > I did have a brief chat with David Lamparter of Quagga fame and he had > thought about doing it in a similar way. > > > > What is your particular use case? Is it just a routing protocol you need? > > > > Best regards, > > Ole > > > > > > > > > > > > > > > > -- > > Kind regards > > > > Jan Hugo Prins > > DevOps Engineer > > <nnpihedfchemlegl.png> > > Auke Vleerstraat 140 E > > 7547 AN Enschede > > CC no. 08097527 T +31 (0) 53 48 00 694 > > E jpr...@betterbe.com > > M +31 (0)6 263 58 951 www.betterbe.com > > <http://www.betterbe.com> > > <http://www.betterbe.com> > > > > > > <http://www.betterbe.com> > > > *-- <http://www.betterbe.com>* > > Kind regards > > Jan Hugo Prins > *DevOps Engineer* > > <image001.png> <https://betterbe.com> > > Auke Vleerstraat 140 E > 7547 AN Enschede > CC no. 08097527 > <https://www.kvk.nl/orderstraat/product-kiezen/?kvknummer=080975270000> > > *T* +31 (0) 53 48 00 694 <+31534800694> > *E* jpr...@betterbe.com > *M* +31 (0)6 263 58 951 <+31%20%280%296%20263%2058%20951> > > *www.betterbe.com* <https://www.betterbe.com> > > BetterBe accepts no liability for the content of this email, or for the > consequences of any actions taken on the basis > of the information provided, unless that information is subsequently > confirmed in writing. If you are not the intended > recipient you are notified that disclosing, copying, distributing or > taking any action in reliance on the contents of this > information is strictly prohibited. > > ,_._,_ > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > > View/Reply Online (#11525): https://lists.fd.io/g/vpp-dev/message/11525 > Mute This Topic: https://lists.fd.io/mt/16973079/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 (#11526): https://lists.fd.io/g/vpp-dev/message/11526 Mute This Topic: https://lists.fd.io/mt/16973079/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
