FRR as Route-Reflector & Scaling stats
Hi Nanog, We want to Deploy and use FRR for Route reflection on a Dell Edge. Any one has expereience with it and can give insight into number of routes and scale that you used FRR to do Route Reflection -- Rakesh Madupu 2xJNCIE - SP/DC / CCIE-SP#47613 https://r2079.wordpress.com
On Thu, 7 Nov 2019 at 14:36, Rakesh M <raaki.88@gmail.com> wrote:
Hi Nanog,
We want to Deploy and use FRR for Route reflection on a Dell Edge. Any one has expereience with it and can give insight into number of routes and scale that you used FRR to do Route Reflection
There is possibly no better place to ask than on the FRR mailing list: frog@lists.frrouting.org Cheers, James.
Hello Rakesh, As James said, better to ask it at FRR mailing list. Generally chipset is what limits the scale (e.g. trident2 is 128k ipv4 lpm https://docs.cumulusnetworks.com/cumulus-linux/Layer-3/Routing/ ). If you disable "zebra" daemon, FRR works only in control-plane then you would most likely have a limitation with memory/RAM only. (speed is another issue). Regards Erçin TORUN -----Original Message----- From: NANOG <nanog-bounces@nanog.org> On Behalf Of James Bensley Sent: Thursday, November 7, 2019 5:39 PM To: Rakesh M <raaki.88@gmail.com>; NANOG Mailing List <nanog@nanog.org> Subject: Re: FRR as Route-Reflector & Scaling stats On Thu, 7 Nov 2019 at 14:36, Rakesh M <raaki.88@gmail.com> wrote:
Hi Nanog,
We want to Deploy and use FRR for Route reflection on a Dell Edge. Any one has expereience with it and can give insight into number of routes and scale that you used FRR to do Route Reflection
There is possibly no better place to ask than on the FRR mailing list: frog@lists.frrouting.org Cheers, James. [http://www.turkcell.com.tr/downloads/bireysel/img/Tcelldis.gif] <http://turkcell.li/iyaani> Bu elektronik posta ve onunla iletilen butun dosyalar sadece gondericisi tarafindan almasi amaclanan yetkili gercek ya da tuzel kisinin kullanimi icindir. Eger soz konusu yetkili alici degilseniz bu elektronik postanin icerigini aciklamaniz, kopyalamaniz, yonlendirmeniz ve kullanmaniz kesinlikle yasaktir ve bu elektronik postayi derhal silmeniz gerekmektedir. TURKCELL bu mesajin icerdigi bilgilerin doğruluğu veya eksiksiz oldugu konusunda herhangi bir garanti vermemektedir. Bu nedenle bu bilgilerin ne sekilde olursa olsun iceriginden, iletilmesinden, alinmasindan ve saklanmasindan sorumlu degildir. Bu mesajdaki gorusler yalnizca gonderen kisiye aittir ve TURKCELLin goruslerini yansitmayabilir Bu e-posta bilinen butun bilgisayar viruslerine karsi taranmistir. ________________________________ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient you are hereby notified that any dissemination, forwarding, copying or use of any of the information is strictly prohibited, and the e-mail should immediately be deleted. TURKCELL makes no warranty as to the accuracy or completeness of any information contained in this message and hereby excludes any liability of any kind for the information contained therein or for the information transmission, reception, storage or use of such in any way whatsoever. The opinions expressed in this message belong to sender alone and may not necessarily reflect the opinions of TURKCELL. This e-mail has been scanned for all known computer viruses.
ERCIN TORUN Sent: Friday, November 15, 2019 9:34 AM
Hello Rakesh,
As James said, better to ask it at FRR mailing list.
Generally chipset is what limits the scale (e.g. trident2 is 128k ipv4 lpm https://docs.cumulusnetworks.com/cumulus-linux/Layer-3/Routing/ ). If you disable "zebra" daemon, FRR works only in control-plane then you would most likely have a limitation with memory/RAM only. (speed is another issue).
Data-plane lookup memory limitations have nothing to do with the scale of a RR function, as you eluded to (if the RR is in path then it has to act as any other routing node so FIB scaling limitations apply -but that is completely orthogonal to the RR function). One would assume that NOS to be used for a crucial role in the overall BGP infrastructure would feature the essential ability to limit the installation (complete/selective) of routes to FIB/data-plane. (or in the modern virtual deployments lack the data-plane altogether). adam
Hi Adam, The intention is not to put in the Data Plane at all but use it for control functions and calculating optimal paths, we are happy with how FRR is handling small network islands to Route traffic in Data Plane and wanted to test this as a candidate for Hierarchical Route-Reflection at site level while proven hardware will be used at a Cluster level. for the benefit of others, FRR member replied about his observations ''' Hi Rakesh, We currently running one FRR route-reflector on a backbone, some peers send FV, some not. Here is header of 'show bgp summary': IPv4 Unicast Summary: BGP router identifier 10.10.10.100, local AS number 65009 vrf-id 0 BGP table version 143698323 RIB entries 1428204, using 218 MiB of memory Peers 26, using 537 KiB of memory Peer groups 9, using 576 bytes of memory We hit problem with bgpd eating whole CPU core on 7.1, so I built FRR with appropriate patch manually. But that must been fixed in 7.2. Otherwise it runs pretty good for the last ~3 months. ''' On Fri, Nov 15, 2019 at 11:04 AM <adamv0025@netconsultings.com> wrote:
ERCIN TORUN Sent: Friday, November 15, 2019 9:34 AM
Hello Rakesh,
As James said, better to ask it at FRR mailing list.
Generally chipset is what limits the scale (e.g. trident2 is 128k ipv4 lpm https://docs.cumulusnetworks.com/cumulus-linux/Layer-3/Routing/ ). If you disable "zebra" daemon, FRR works only in control-plane then you would most likely have a limitation with memory/RAM only. (speed is another issue).
Data-plane lookup memory limitations have nothing to do with the scale of a RR function, as you eluded to (if the RR is in path then it has to act as any other routing node so FIB scaling limitations apply -but that is completely orthogonal to the RR function). One would assume that NOS to be used for a crucial role in the overall BGP infrastructure would feature the essential ability to limit the installation (complete/selective) of routes to FIB/data-plane. (or in the modern virtual deployments lack the data-plane altogether).
adam
-- -- Rakesh Madupu 2xJNCIE - SP/DC / CCIE-SP#47613 https://r2079.wordpress.com
❦ 15 novembre 2019 09:33 +00, ERCIN TORUN <ercin.torun@turkcell.com.tr>:
Generally chipset is what limits the scale (e.g. trident2 is 128k ipv4 lpm https://docs.cumulusnetworks.com/cumulus-linux/Layer-3/Routing/ ). If you disable "zebra" daemon, FRR works only in control-plane then you would most likely have a limitation with memory/RAM only. (speed is another issue).
To avoid disabling Zebra daemon, you can use "table-map" to choose the routes to send to Zebra: <http://docs.frrouting.org/en/latest/bgp.html#clicmd-table-mapROUTE-MAP-NAME> For example: route-map DENY_ALL deny 10 router bgp 65000 vrf private address-family ipv4 unicast table-map DENY_ALL exit-address-family -- Avoid unnecessary branches. - The Elements of Programming Style (Kernighan & Plauger)
participants (5)
-
adamv0025＠netconsultings.com -
ERCIN TORUN -
James Bensley -
Rakesh M -
Vincent Bernat