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<mailto: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> -- <http://www.betterbe.com> Kind regards Jan Hugo Prins DevOps Engineer [cid:image001.png@01D3D319.C2ED6FA0]<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<tel:+31534800694> E jpr...@betterbe.com<mailto:jpr...@betterbe.com> M +31 (0)6 263 58 951<tel:+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.
