Quagga is built into one of our core products, works great. That particular vendor a sponsor of frr, and is replacing quagga with frr soon. Maybe look at the vendor/partner list for quagga and frr, and decide which project has better long-term prospects. David From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Nathan Brookfield Sent: Sunday, February 23, 2020 4:41 AM To: Dmitry Sherman <dmitry@interhost.net> Cc: nanog@nanog.org Subject: Re: Quagga for production? Hi Mate, Yep on and off for about 15 years, very solid, very reliable. I tend to use Bird this hmorning we rays for this task but Zebra and Quagga are rock solid. Kindest Regards, Nathan Brookfield (VK2NAB) Simtronic Technologies Pty Ltd On 23 Feb 2020, at 23:29, Dmitry Sherman <dmitry@interhost.net<mailto:dmitry@interhost.net>> wrote:  Hello, Anybody working with Quagga for production peering with multiple peers and dynamic eBGP/iBGP announcement? Thanks. Dmitry ---------------------------------------------------------------------- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, notify the sender immediately by return email and delete the message and any attachments from your system.

Mark Tinka wrote on 18/03/2020 14:25:

At the moment, I run Quagga with OSPF and export that into my IS-IS core to drive Anycast services.

I used to use ISIS for this, but more recently moved to ebgp with 1s/3s timers. The convergence characteristics are reasonable and as the only routing protocol dependence is bgp, we can use bird which in turn allow us to automate provisioning via saltstack. Automating quagga and frr is hacky. Nick

Mark Tinka wrote on 18/03/2020 17:02:

I prefer to have a number of core systems accessible in the IGP, because BGP can sometimes get hosed for one reason or another.

BGP always needs IGP to work. The reverse is not true, and reduces us to absolute basics when it hits the fan (which it has, a few times before).

Yeah. I was thinking more for the case of customer-facing anycast resolvers, in which case BGP down means that the network is down, and if the network is down it doesn't matter than DNS is also down because their shared fate means that when BGP is back up, DNS will start working again. Nick

On 18/Mar/20 22:22, Nick Hilliard wrote:

Yeah.  I was thinking more for the case of customer-facing anycast resolvers, in which case BGP down means that the network is down, and if the network is down it doesn't matter than DNS is also down because their shared fate means that when BGP is back up, DNS will start working again.

As much as possible, I'll always choose to have the most basic infrastructure available under abnormal conditions, regardless of the service. ME3600X's and ASR920's, for example, will install 0/0 and ::/0 in FIB last. If your access to the core depends entirely on BGP in such scenarios, you will be unable to access it for as much as 10 minutes. Mark.

Mark Tinka <mark.tinka@seacom.mu> writes:

On 17/Mar/20 19:39, Jens Link wrote:

...

Jens, using frr for quite some time now without any problems

IS-IS, per chance?

Sorry, only BGP for now. Jens -- ---------------------------------------------------------------------------- | Delbrueckstr. 41 | 12051 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink@quux.de | --------------- | ----------------------------------------------------------------------------