A question about the # of vrf per router or switch can support by FRR?
Is there a limit that the # of vrf can support for a single switch or router by using FRR? Thanks, Jay
Jay - There is no hard limit. Having said that I am not aware of serious testing beyond like 64 vrf's. But that is allot of vrf's to have to maintain at one time.. donald On Tue, Oct 31, 2017 at 10:39 PM, Jay Chen <jchen1@paloaltonetworks.com> wrote:
Is there a limit that the # of vrf can support for a single switch or router by using FRR?
Thanks,
Jay
_______________________________________________ dev mailing list dev@lists.frrouting.org https://lists.frrouting.org/listinfo/dev
Hi Donald, Great, thank you for the clarification. I noticed that FRR using linked list in both BGP, and OSPF where a red black tree may be better in turn of Big-O. Two questions below: A. Is it worth to implement a redblack tree? B. Any effort is already in progress in implementing an embedded redblack tree and use it in some key places? If the answer to A is yes, B is no. I can volunteer to implement a light weight redblack tree (embedded usage), and patch it (I have done a couple of time for another two router companies). I just thought it might be better than search a long linked list. Thanks, Jay On 11/1/17, 6:15 AM, "Donald Sharp" <sharpd@cumulusnetworks.com> wrote: Jay - There is no hard limit. Having said that I am not aware of serious testing beyond like 64 vrf's. But that is allot of vrf's to have to maintain at one time.. donald On Tue, Oct 31, 2017 at 10:39 PM, Jay Chen <jchen1@paloaltonetworks.com> wrote: > Is there a limit that the # of vrf can support for a single switch or router > by using FRR? > > > > Thanks, > > Jay > > > > > _______________________________________________ > dev mailing list > dev@lists.frrouting.org > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.frrouting.org_lis... >
Jay - What version of the code are you looking at? VRF's use RB trees: static __inline int vrf_id_compare(const struct vrf *, const struct vrf *); static __inline int vrf_name_compare(const struct vrf *, const struct vrf *); RB_GENERATE(vrf_id_head, vrf, id_entry, vrf_id_compare); RB_GENERATE(vrf_name_head, vrf, name_entry, vrf_name_compare); struct vrf_id_head vrfs_by_id = RB_INITIALIZER(&vrfs_by_id); struct vrf_name_head vrfs_by_name = RB_INITIALIZER(&vrfs_by_name); So do interfaces now as well: static int if_cmp_func(const struct interface *, const struct interface *); static int if_cmp_index_func(const struct interface *ifp1, const struct interface *ifp2); RB_GENERATE(if_name_head, interface, name_entry, if_cmp_func); RB_GENERATE(if_index_head, interface, index_entry, if_cmp_index_func); We've been trying to intelligently move code over and may have missed something. donald On Wed, Nov 1, 2017 at 1:00 PM, Jay Chen <jchen1@paloaltonetworks.com> wrote:
Hi Donald,
Great, thank you for the clarification. I noticed that FRR using linked list in both BGP, and OSPF where a red black tree may be better in turn of Big-O. Two questions below:
A. Is it worth to implement a redblack tree? B. Any effort is already in progress in implementing an embedded redblack tree and use it in some key places?
If the answer to A is yes, B is no. I can volunteer to implement a light weight redblack tree (embedded usage), and patch it (I have done a couple of time for another two router companies). I just thought it might be better than search a long linked list.
Thanks, Jay
On 11/1/17, 6:15 AM, "Donald Sharp" <sharpd@cumulusnetworks.com> wrote:
Jay -
There is no hard limit. Having said that I am not aware of serious testing beyond like 64 vrf's. But that is allot of vrf's to have to maintain at one time..
donald
On Tue, Oct 31, 2017 at 10:39 PM, Jay Chen <jchen1@paloaltonetworks.com> wrote: > Is there a limit that the # of vrf can support for a single switch or router > by using FRR? > > > > Thanks, > > Jay > > > > > _______________________________________________ > dev mailing list > dev@lists.frrouting.org > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.frrouting.org_lis... >
Donald, Cool, indeed it is using an rb already. I was looking at BGP that uses a lot of list for group, peer etc. My code is indeed old too. I am going to update it and try the newest one. Thanks, Jay On 11/1/17, 10:04 AM, "Donald Sharp" <sharpd@cumulusnetworks.com> wrote: Jay - What version of the code are you looking at? VRF's use RB trees: static __inline int vrf_id_compare(const struct vrf *, const struct vrf *); static __inline int vrf_name_compare(const struct vrf *, const struct vrf *); RB_GENERATE(vrf_id_head, vrf, id_entry, vrf_id_compare); RB_GENERATE(vrf_name_head, vrf, name_entry, vrf_name_compare); struct vrf_id_head vrfs_by_id = RB_INITIALIZER(&vrfs_by_id); struct vrf_name_head vrfs_by_name = RB_INITIALIZER(&vrfs_by_name); So do interfaces now as well: static int if_cmp_func(const struct interface *, const struct interface *); static int if_cmp_index_func(const struct interface *ifp1, const struct interface *ifp2); RB_GENERATE(if_name_head, interface, name_entry, if_cmp_func); RB_GENERATE(if_index_head, interface, index_entry, if_cmp_index_func); We've been trying to intelligently move code over and may have missed something. donald On Wed, Nov 1, 2017 at 1:00 PM, Jay Chen <jchen1@paloaltonetworks.com> wrote: > Hi Donald, > > Great, thank you for the clarification. > I noticed that FRR using linked list in both BGP, and OSPF where a red black tree may be better in turn of Big-O. Two questions below: > > A. Is it worth to implement a redblack tree? > B. Any effort is already in progress in implementing an embedded redblack tree and use it in some key places? > > If the answer to A is yes, B is no. I can volunteer to implement a light weight redblack tree (embedded usage), and patch it (I have done a couple of time for another two router companies). I just thought it might be better than search a long linked list. > > Thanks, > Jay > > > > On 11/1/17, 6:15 AM, "Donald Sharp" <sharpd@cumulusnetworks.com> wrote: > > Jay - > > There is no hard limit. Having said that I am not aware of serious > testing beyond like 64 vrf's. But that is allot of vrf's to have to > maintain at one time.. > > donald > > On Tue, Oct 31, 2017 at 10:39 PM, Jay Chen <jchen1@paloaltonetworks.com> wrote: > > Is there a limit that the # of vrf can support for a single switch or router > > by using FRR? > > > > > > > > Thanks, > > > > Jay > > > > > > > > > > _______________________________________________ > > dev mailing list > > dev@lists.frrouting.org > > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.frrouting.org_lis... > > > >
Jay - Conversion of lists over for well used data structures would be greatly appreciated and in general is on the list of things that need to be done.. I do know the bgp peers have both a list and a hash( for o(1) lookup) that was put in about 1.5 years ago and showed some great improvements in scaling because of not having to traverse a list for peer lookup. donald On Wed, Nov 1, 2017 at 1:28 PM, Jay Chen <jchen1@paloaltonetworks.com> wrote:
Donald,
Cool, indeed it is using an rb already. I was looking at BGP that uses a lot of list for group, peer etc. My code is indeed old too. I am going to update it and try the newest one.
Thanks, Jay
On 11/1/17, 10:04 AM, "Donald Sharp" <sharpd@cumulusnetworks.com> wrote:
Jay -
What version of the code are you looking at? VRF's use RB trees:
static __inline int vrf_id_compare(const struct vrf *, const struct vrf *); static __inline int vrf_name_compare(const struct vrf *, const struct vrf *);
RB_GENERATE(vrf_id_head, vrf, id_entry, vrf_id_compare); RB_GENERATE(vrf_name_head, vrf, name_entry, vrf_name_compare);
struct vrf_id_head vrfs_by_id = RB_INITIALIZER(&vrfs_by_id); struct vrf_name_head vrfs_by_name = RB_INITIALIZER(&vrfs_by_name);
So do interfaces now as well:
static int if_cmp_func(const struct interface *, const struct interface *); static int if_cmp_index_func(const struct interface *ifp1, const struct interface *ifp2); RB_GENERATE(if_name_head, interface, name_entry, if_cmp_func); RB_GENERATE(if_index_head, interface, index_entry, if_cmp_index_func);
We've been trying to intelligently move code over and may have missed something.
donald
On Wed, Nov 1, 2017 at 1:00 PM, Jay Chen <jchen1@paloaltonetworks.com> wrote: > Hi Donald, > > Great, thank you for the clarification. > I noticed that FRR using linked list in both BGP, and OSPF where a red black tree may be better in turn of Big-O. Two questions below: > > A. Is it worth to implement a redblack tree? > B. Any effort is already in progress in implementing an embedded redblack tree and use it in some key places? > > If the answer to A is yes, B is no. I can volunteer to implement a light weight redblack tree (embedded usage), and patch it (I have done a couple of time for another two router companies). I just thought it might be better than search a long linked list. > > Thanks, > Jay > > > > On 11/1/17, 6:15 AM, "Donald Sharp" <sharpd@cumulusnetworks.com> wrote: > > Jay - > > There is no hard limit. Having said that I am not aware of serious > testing beyond like 64 vrf's. But that is allot of vrf's to have to > maintain at one time.. > > donald > > On Tue, Oct 31, 2017 at 10:39 PM, Jay Chen <jchen1@paloaltonetworks.com> wrote: > > Is there a limit that the # of vrf can support for a single switch or router > > by using FRR? > > > > > > > > Thanks, > > > > Jay > > > > > > > > > > _______________________________________________ > > dev mailing list > > dev@lists.frrouting.org > > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.frrouting.org_lis... > > > >
Yes, this on my to-do list. On Nov 1, 2017 4:02 PM, "Donald Sharp" <sharpd@cumulusnetworks.com> wrote: Jay - Conversion of lists over for well used data structures would be greatly appreciated and in general is on the list of things that need to be done.. I do know the bgp peers have both a list and a hash( for o(1) lookup) that was put in about 1.5 years ago and showed some great improvements in scaling because of not having to traverse a list for peer lookup. donald On Wed, Nov 1, 2017 at 1:28 PM, Jay Chen <jchen1@paloaltonetworks.com> wrote:
Donald,
Cool, indeed it is using an rb already. I was looking at BGP that uses a lot of list for group, peer etc. My code is indeed old too. I am going to update it and try the newest one.
Thanks, Jay
On 11/1/17, 10:04 AM, "Donald Sharp" <sharpd@cumulusnetworks.com> wrote:
Jay -
What version of the code are you looking at? VRF's use RB trees:
static __inline int vrf_id_compare(const struct vrf *, const struct vrf *); static __inline int vrf_name_compare(const struct vrf *, const struct vrf *);
RB_GENERATE(vrf_id_head, vrf, id_entry, vrf_id_compare); RB_GENERATE(vrf_name_head, vrf, name_entry, vrf_name_compare);
struct vrf_id_head vrfs_by_id = RB_INITIALIZER(&vrfs_by_id); struct vrf_name_head vrfs_by_name = RB_INITIALIZER(&vrfs_by_name);
So do interfaces now as well:
static int if_cmp_func(const struct interface *, const struct interface *); static int if_cmp_index_func(const struct interface *ifp1, const struct interface *ifp2); RB_GENERATE(if_name_head, interface, name_entry, if_cmp_func); RB_GENERATE(if_index_head, interface, index_entry, if_cmp_index_func);
We've been trying to intelligently move code over and may have missed something.
donald
On Wed, Nov 1, 2017 at 1:00 PM, Jay Chen <jchen1@paloaltonetworks.com> wrote: > Hi Donald, > > Great, thank you for the clarification. > I noticed that FRR using linked list in both BGP, and OSPF where a red black tree may be better in turn of Big-O. Two questions below: > > A. Is it worth to implement a redblack tree? > B. Any effort is already in progress in implementing an embedded redblack tree and use it in some key places? > > If the answer to A is yes, B is no. I can volunteer to implement a light weight redblack tree (embedded usage), and patch it (I have done a couple of time for another two router companies). I just thought it might be better than search a long linked list. > > Thanks, > Jay > > > > On 11/1/17, 6:15 AM, "Donald Sharp" <sharpd@cumulusnetworks.com> wrote: > > Jay - > > There is no hard limit. Having said that I am not aware of serious > testing beyond like 64 vrf's. But that is allot of vrf's to have to > maintain at one time.. > > donald > > On Tue, Oct 31, 2017 at 10:39 PM, Jay Chen < jchen1@paloaltonetworks.com> wrote: > > Is there a limit that the # of vrf can support for a single switch or router > > by using FRR? > > > > > > > > Thanks, > > > > Jay > > > > > > > > > > _______________________________________________ > > dev mailing list > > dev@lists.frrouting.org > > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists. frrouting.org_listinfo_dev&d=DwIBaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFW e5J8PTfkrzVSo&r=yetdj-aXQpuqTCJGs-93hOpK3740MIRXowfUNLByeos&m= 39gFpBpfaetXLzjjR76DUE8_Ju4vRUt7sYRtCAk5gY8&s=1AXFF8MKa7HBFGMglzbyhXAP3TjDeW h9w9xcNn4puxQ&e= > > > >
_______________________________________________ dev mailing list dev@lists.frrouting.org https://lists.frrouting.org/listinfo/dev
Donald, Is it? In my previous life. I had 5k VRFs supported with many live deployments around 2k. Obviously edge routers is quite a different market, still... All things are relative... Jeff On Wed, Nov 1, 2017 at 06:16 Donald Sharp <sharpd@cumulusnetworks.com> wrote:
Jay -
There is no hard limit. Having said that I am not aware of serious testing beyond like 64 vrf's. But that is allot of vrf's to have to maintain at one time..
donald
On Tue, Oct 31, 2017 at 10:39 PM, Jay Chen <jchen1@paloaltonetworks.com> wrote:
Is there a limit that the # of vrf can support for a single switch or router by using FRR?
Thanks,
Jay
_______________________________________________ dev mailing list dev@lists.frrouting.org https://lists.frrouting.org/listinfo/dev
_______________________________________________ dev mailing list dev@lists.frrouting.org https://lists.frrouting.org/listinfo/dev
Jeff - I thought I was pretty careful in my reply. I've seen testing of 64 vrf's and I consider that many vrf's hard to operationally deploy. I don't disagree with you that some PE's will deploy thousands of VRF's. I was/am unwilling to claim vrf scaling until we get someone who actually tries it out and possibly runs into some data structure design flaw in FRR/kernel that we did not consider. I actually think it would be really interesting for someone to give it a shot, though! It would provide valuable feedback to us! donald On Wed, Nov 1, 2017 at 2:31 PM, Jeff Tantsura <jefftant@gmail.com> wrote:
Donald,
Is it? In my previous life. I had 5k VRFs supported with many live deployments around 2k. Obviously edge routers is quite a different market, still...
All things are relative... Jeff
On Wed, Nov 1, 2017 at 06:16 Donald Sharp <sharpd@cumulusnetworks.com> wrote:
Jay -
There is no hard limit. Having said that I am not aware of serious testing beyond like 64 vrf's. But that is allot of vrf's to have to maintain at one time..
donald
On Tue, Oct 31, 2017 at 10:39 PM, Jay Chen <jchen1@paloaltonetworks.com> wrote:
Is there a limit that the # of vrf can support for a single switch or router by using FRR?
Thanks,
Jay
_______________________________________________ dev mailing list dev@lists.frrouting.org https://lists.frrouting.org/listinfo/dev
_______________________________________________ dev mailing list dev@lists.frrouting.org https://lists.frrouting.org/listinfo/dev
In the Linux kernel model, the VRF is a netdevice. So, for PE-scale scaling of VRFs, that is also a factor in the mix. On Wed, Nov 1, 2017 at 12:28 PM, Donald Sharp <sharpd@cumulusnetworks.com> wrote:
Jeff -
I thought I was pretty careful in my reply. I've seen testing of 64 vrf's and I consider that many vrf's hard to operationally deploy. I don't disagree with you that some PE's will deploy thousands of VRF's. I was/am unwilling to claim vrf scaling until we get someone who actually tries it out and possibly runs into some data structure design flaw in FRR/kernel that we did not consider. I actually think it would be really interesting for someone to give it a shot, though! It would provide valuable feedback to us!
donald
On Wed, Nov 1, 2017 at 2:31 PM, Jeff Tantsura <jefftant@gmail.com> wrote:
Donald,
Is it? In my previous life. I had 5k VRFs supported with many live deployments around 2k. Obviously edge routers is quite a different market, still...
All things are relative... Jeff
On Wed, Nov 1, 2017 at 06:16 Donald Sharp <sharpd@cumulusnetworks.com> wrote:
Jay -
There is no hard limit. Having said that I am not aware of serious testing beyond like 64 vrf's. But that is allot of vrf's to have to maintain at one time..
donald
On Tue, Oct 31, 2017 at 10:39 PM, Jay Chen <jchen1@paloaltonetworks.com
wrote:
Is there a limit that the # of vrf can support for a single switch or router by using FRR?
Thanks,
Jay
_______________________________________________ dev mailing list dev@lists.frrouting.org https://lists.frrouting.org/listinfo/dev
_______________________________________________ dev mailing list dev@lists.frrouting.org https://lists.frrouting.org/listinfo/dev
_______________________________________________ dev mailing list dev@lists.frrouting.org https://lists.frrouting.org/listinfo/dev
participants (5)
-
Donald Sharp -
Jay Chen -
Jeff Tantsura -
Quentin Young -
Vivek Venkatraman