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 > > > > > -- > Kind regards > > Jan Hugo Prins > DevOps Engineer > <image001.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 > 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/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
