Re: Re : [vpp-dev] Maintainer router plugin

[Justin Iurman]

Hi Jerome,

> Regarding multi instance, have you considered running multiple instances of 
> VPP
> in different containers?

I did, however this is not an option as I'd like to keep my "entire topology 
running on the same machine" philosophy.

Also, I think this could be a plus for the router plugin to handle 
multi-instance/memif setups. Though, I don't see how we could do.

Cheers,
Justin
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11539): https://lists.fd.io/g/vpp-dev/message/11539
Mute This Topic: https://lists.fd.io/mt/28707406/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re : [vpp-dev] Maintainer router plugin

[Jerome Tollet via Lists.Fd.Io]

Hello Justin,
Regarding multi instance, have you considered running multiple instances of VPP 
in different containers?
Jerome

Le 08/12/2018 18:00, « vpp-dev@lists.fd.io au nom de Justin Iurman » 
 a écrit :

Hi Hongjun,

> There is no plan to use memif at present. Welcome your contribution if 
you will.

Of course, if I find some free time. Anyone interested in working on this ?

> In router plugin, we inject links, routes, etc. from different namespace 
in
> Kernel into different VRFs In VPP.
> Not support multi-instance mode.

How do you determine which namespace(s) to look at ? Or do you take care of 
all namespaces by default ?

Also, would multi-instance mode be feasible ?

Cheers,
Justin


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11535): https://lists.fd.io/g/vpp-dev/message/11535
Mute This Topic: https://lists.fd.io/mt/28707406/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Maintainer router plugin

[Justin Iurman]

Hi Hongjun,

> There is no plan to use memif at present. Welcome your contribution if you 
> will.

Of course, if I find some free time. Anyone interested in working on this ?

> In router plugin, we inject links, routes, etc. from different namespace in
> Kernel into different VRFs In VPP.
> Not support multi-instance mode.

How do you determine which namespace(s) to look at ? Or do you take care of all 
namespaces by default ?

Also, would multi-instance mode be feasible ?

Cheers,
Justin
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11529): https://lists.fd.io/g/vpp-dev/message/11529
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]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Maintainer router plugin

[Ni, Hongjun]

Hi Justin,

There is no plan to use memif at present. Welcome your contribution if you will.

In router plugin, we inject links, routes, etc. from different namespace in 
Kernel into different VRFs In VPP.
Not support multi-instance mode.

Thanks,
Hongjun

From: vpp-dev@lists.fd.io [mailto:vpp-dev@lists.fd.io] On Behalf Of Justin 
Iurman
Sent: Friday, December 7, 2018 2:00 PM
To: Neale Ranns 
Cc: Jan Hugo Prins | BetterBe ; Ole Troan 
; vpp-dev ; Ray Kinsella 

Subject: Re: [vpp-dev] Maintainer router plugin

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: mailto:vpp-dev@lists.fd.io>> on behalf of Jan Hugo 
Prins | BetterBe mailto:jpr...@betterbe.com>>
Date: Wednesday, 11 April 2018 at 20:54
To: Ole Troan mailto:otr...@employees.org>>
Cc: vpp-dev mailto:vpp-dev@lists.fd.io>>, Ray Kinsella 
mailto: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



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>
Kind regards

Jan Hugo Prins
DevOps Engineer

<https://betterbe.com>

Auke Vleerstraat 140 E
7547 AN Enschede
CC no. 
08097527<https://www.kvk.nl/orderstraat/product-kiezen/?kvknummer=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<https://www.betterbe.com>

BetterBe accepts no liability for the content of th

Re: [vpp-dev] Maintainer router plugin

[Brian Dickson]

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 
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: * on behalf of Jan Hugo Prins | BetterBe <
> jpr...@betterbe.com>
> *Date: *Wednesday, 11 April 2018 at 20:54
> *To: *Ole Troan 
> *Cc: *vpp-dev , Ray Kinsella 
> *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 
>

Re: [vpp-dev] Maintainer router plugin

[Justin Iurman]

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:  on behalf of Jan Hugo Prins | BetterBe 
> 
> Date: Wednesday, 11 April 2018 at 20:54
> To: Ole Troan 
> Cc: vpp-dev , Ray Kinsella 
> 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
> 
> 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
> 
> 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]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Maintainer router plugin

[Neale Ranns]

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



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=08097527>

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.

Re: [vpp-dev] Maintainer router plugin

[Jan Hugo Prins | BetterBe]

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
>> 
>> 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 951www.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.
>> 

-- 
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 
*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.

Re: [vpp-dev] Maintainer router plugin

[Jim Thompson]

> On Apr 11, 2018, at 12:19 PM, Ole Troan  wrote:
> 
> VPP API used to program routes. learn interface events, addresses etc. Pure 
> user-land no involvement from kernel.
> 

We’re also not “fans” of the router plugin.  (And we’ve done a lot of work on 
it.)

We have a system (today) that uses the VPP API to program routes, talking to 
FRR (Quagga), rather than going via the kernel netlink interface, mostly 
because that path is a) slow and b) icky (now you have state in three places).  
The additions to FRR are straight-forward.  Zebra has different implementations 
that can be used to communicate routes to the kernel:  (ioctl, socket, netlink, 
…). We added one for VPP and added a config option to enable it.  We have 
something similar for Strongswan.

As soon as we get this release out of our product (“TNSR”), we plan to open an 
investigation into using “tldk” (as present in VPP, not as the external 
project) as transport for FRR and Strongswan.

My “gut” says “top middle” is the right architecture.

Jim

Re: [vpp-dev] Maintainer router plugin

[Ole Troan]

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
> 
> 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 (#8896): https://lists.fd.io/g/vpp-dev/message/8896
View All Messages In Topic (11): https://lists.fd.io/g/vpp-dev/topic/16973079
Mute This Topic: https://lists.fd.io/mt/16973079/21656
New Topic: https://lists.fd.io/g/vpp-dev/post

Change Your Subscription: https://lists.fd.io/g/vpp-dev/editsub/21656
Group Home: https://lists.fd.io/g/vpp-dev
Contact Group Owner: vpp-dev+ow...@lists.fd.io
Terms of Service: https://lists.fd.io/static/tos
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub
-=-=-=-=-=-=-=-=-=-=-=-



signature.asc
Description: Message signed with OpenPGP

Re: [vpp-dev] Maintainer router plugin

[Jan Hugo Prins | BetterBe]

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?

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/

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.

Re: [vpp-dev] Maintainer router plugin

[Ray Kinsella]

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







-=-=-=-=-=-=-=-=-=-=-=-
Links:

You receive all messages sent to this group.

View/Reply Online (#8891): https://lists.fd.io/g/vpp-dev/message/8891
View All Messages In Topic (7): https://lists.fd.io/g/vpp-dev/topic/16973079
Mute This Topic: https://lists.fd.io/mt/16973079/21656
New Topic: https://lists.fd.io/g/vpp-dev/post

Change Your Subscription: https://lists.fd.io/g/vpp-dev/editsub/21656
Group Home: https://lists.fd.io/g/vpp-dev
Contact Group Owner: vpp-dev+ow...@lists.fd.io
Terms of Service: https://lists.fd.io/static/tos
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Maintainer router plugin

[Ray Kinsella]

Hi Jan,

Yes we have been developing/maintaining the router plugin for sometime.

Ray K

On 11/04/2018 00:27, Jan Hugo Prins | BetterBe wrote:

Hello,

Is someone actively maintaining the router plugin?

Jan Hugo
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.



-=-=-=-=-=-=-=-=-=-=-=-
Links:

You receive all messages sent to this group.

View/Reply Online (#8890): https://lists.fd.io/g/vpp-dev/message/8890
View All Messages In Topic (6): https://lists.fd.io/g/vpp-dev/topic/16973079
Mute This Topic: https://lists.fd.io/mt/16973079/21656
New Topic: https://lists.fd.io/g/vpp-dev/post

Change Your Subscription: https://lists.fd.io/g/vpp-dev/editsub/21656
Group Home: https://lists.fd.io/g/vpp-dev
Contact Group Owner: vpp-dev+ow...@lists.fd.io
Terms of Service: https://lists.fd.io/static/tos
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Maintainer router plugin

[Jan Hugo Prins | BetterBe]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello Ole,

That sounds to me like the router / rtnetlink plugins are a dead horse,
not worth any more of my time ;-)
I have setup a BGP session on IPv4 and the first results are not that
good. The session is setup, the routes are installed in the Linux
kernel, but in VPP  I don't see them at all.
I would expect to see the routes when I do "sh ip fib" but I only see a
small part of the routes directly connected to the OSPF neighbor's and
no BGP routes at all, but because the BGP routes are all behind OSPF
routes that are missing, I think this is to be expected.

It would be really great if frr would communicate directly with VPP and
install the routes and the interface configuration etc, but this sounds
like a development story that could take some time.

Jan Hugo Prins


On 04/11/2018 11:57 AM, Ole Troan wrote:
> Hi Jan Hugo, > >> The main thing I'm currently missing is OSPFv3. The 
> multicast
packets >> don't arrive in linux kernel. >> Attached is a pcap file
showing the dropped packets. >> OSPFv2 seems to be working fine. >> I
hope to test the BGP for IPv4 and IPv6 today. >> >> I have put my
findings in the vppsb-dev mailinglist. >> >> I would be really happy if
I could get this setup working. >> I currently have the possibility to
test any code changes you make :-) > > I am of course proposing a
completely different model than what's in the router plugin. > > A first
step would be to ensure we got all the functionality we need from the
VPP <--> Linux punt path. > > Best regards, > Ole > > >
 >
- -- 
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 
*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.

-BEGIN PGP SIGNATURE-

iF0EARECAB0WIQRlyp0kFjWHi/j64SQKby/W7MOWVwUCWs3r+wAKCRAKby/W7MOW
V6E/AKCqYzY0Zn/ot6emlTcUyh9iOQVo2QCfXfjxjqZfWJ+ot9V4iJowYrmbDaE=
=ImyJ
-END PGP SIGNATURE-

Re: [vpp-dev] Maintainer router plugin

[Ole Troan]

Hi Jan Hugo,

> The main thing I'm currently missing is OSPFv3. The multicast packets
> don't arrive in linux kernel.
> Attached is a pcap file showing the dropped packets.
> OSPFv2 seems to be working fine.
> I hope to test the BGP for IPv4 and IPv6 today.
> 
> I have put my findings in the vppsb-dev mailinglist.
> 
> I would be really happy if I could get this setup working.
> I currently have the possibility to test any code changes you make :-)

I am of course proposing a completely different model than what's in the router 
plugin.

A first step would be to ensure we got all the functionality we need from the 
VPP <--> Linux punt path.

Best regards,
Ole


-=-=-=-=-=-=-=-=-=-=-=-
Links:

You receive all messages sent to this group.

View/Reply Online (#): https://lists.fd.io/g/vpp-dev/message/
View All Messages In Topic (4): https://lists.fd.io/g/vpp-dev/topic/16973079
Mute This Topic: https://lists.fd.io/mt/16973079/21656
New Topic: https://lists.fd.io/g/vpp-dev/post

Change Your Subscription: https://lists.fd.io/g/vpp-dev/editsub/21656
Group Home: https://lists.fd.io/g/vpp-dev
Contact Group Owner: vpp-dev+ow...@lists.fd.io
Terms of Service: https://lists.fd.io/static/tos
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub
-=-=-=-=-=-=-=-=-=-=-=-



signature.asc
Description: Message signed with OpenPGP

Re: [vpp-dev] Maintainer router plugin

[Jan Hugo Prins | BetterBe]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello Ole,

The main thing I'm currently missing is OSPFv3. The multicast packets
don't arrive in linux kernel.
Attached is a pcap file showing the dropped packets.
OSPFv2 seems to be working fine.
I hope to test the BGP for IPv4 and IPv6 today.

I have put my findings in the vppsb-dev mailinglist.

I would be really happy if I could get this setup working.
I currently have the possibility to test any code changes you make :-)

Jan Hugo Prins


On 04/11/2018 10:33 AM, 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/

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.

-BEGIN PGP SIGNATURE-

iF0EARECAB0WIQRlyp0kFjWHi/j64SQKby/W7MOWVwUCWs3RqAAKCRAKby/W7MOW
VyOLAJ9YDbq3eySyyvqpOchasdS57veZsACfWaBJCINMXrgNq0bpTlUDWf1j7HE=
=ZxtU
-END PGP SIGNATURE-



vppTestDrop.pcap
Description: application/vnd.tcpdump.pcap


vppTestDrop.pcap.sig
Description: PGP signature

Re: [vpp-dev] Maintainer router plugin

[Ole Troan]

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



-=-=-=-=-=-=-=-=-=-=-=-
Links:

You receive all messages sent to this group.

View/Reply Online (#8886): https://lists.fd.io/g/vpp-dev/message/8886
View All Messages In Topic (2): https://lists.fd.io/g/vpp-dev/topic/16973079
Mute This Topic: https://lists.fd.io/mt/16973079/21656
New Topic: https://lists.fd.io/g/vpp-dev/post

Change Your Subscription: https://lists.fd.io/g/vpp-dev/editsub/21656
Group Home: https://lists.fd.io/g/vpp-dev
Contact Group Owner: vpp-dev+ow...@lists.fd.io
Terms of Service: https://lists.fd.io/static/tos
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub
-=-=-=-=-=-=-=-=-=-=-=-



signature.asc
Description: Message signed with OpenPGP

[vpp-dev] Maintainer router plugin

[Jan Hugo Prins | BetterBe]

Hello,

Is someone actively maintaining the router plugin?

Jan Hugo
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.