Hi Jan,

A VPP packet trace and the output from “sh ip mfib’ would help diagnose your 
multicast packet drops.


From: <vpp-dev@lists.fd.io> on behalf of Jan Hugo Prins | BetterBe 
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 

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 

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,


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 

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,



Kind regards

Jan Hugo Prins

DevOps Engineer


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>


Kind regards

Jan Hugo Prins
DevOps Engineer


Auke Vleerstraat 140 E
7547 AN Enschede
CC no. 

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>


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.

Reply via email to