I know best subjective, but I'm looking at a project to announce some IP space that's between uses now and see what's there. I'm planing to run a flow logger and ntop on the VM and see what is coming in if anything. I'm looking at the options for BGP out there, and there's quite a few (other than running a VM with a router doing BGP), but most data I've seen is focused on scale and filtering use, or RPKI. My use case is a bit different, and I can't find any best practices for this use case from what I've found.
That said, is there a better solution other than linux/ntop/ipt-netflow?
I run BIRD on Ubuntu and it works well. Feel free to reach out off list Bryan if you want some examples of a basic config
Thank you,
Michael Spears
Doesn’t VyOS simply use Quagga?
FRR on Linux with one of the VPS providers that support BGP like Vultr.
Also consider asking CAIDA for access to Telescope -- that's where
they collect packets on unused IP addresses.
Regards,
Bill Herrin
VyOS uses FRR, but they used to run quagga.
And most bsd(?)/linux package managers has frr in their repository so maybe that could be something to look at?
I think FRR is a fork of Quagga.
pfSense running FRR is a pretty solid BGP router.
Mark.
Hi Bryan,
Openbsd project has openbgpd built right in. Simple and security-minded implementation.
Presentations: https://www.openbgpd.org/papers.html
Testimonials: https://www.openbgpd.org/users.html
Regards,
Nick
Confidentiality Notice: This E-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply E-mail and destroy all copies of the original message.
Agreed with Mark, used pfSense running FRR a few months ago without issues.
Hi!
I like VyOS or FRR (both in Debian Linux).
Regards,
+lots.
I’ve used a number of Linux routing thingies (BIRD, Quagga, VyOS/Ubiquiti, OpenBGPd, ExBGP), and FRR is (for me at least) by far the friendliest. It’s trivial to spin this up on a cloud VM and start announcing a prefix.
For doing something like Anycast though (where you are mostly just announcing a route on demand), ExaBGP is great.
W
For those that like FRR:
https://thehackernews.com/2023/05/researchers-uncover-new-bgp-flaws-in.html
All 3 of those CVEs look like they were fixed and backported into 8.2 through 8.4 at least 6 months ago.
Tom - you are correct
Of course - who keeps things like BGP Route Servers and FRR up to date -
cough cough
Glenn S. Kelley,
I am a Connectivity.Engineer
Text and Voice Direct: 740-206-9624
a Division of CreatingNet.Works
IMPORTANT: The contents of this email and any attachments are
confidential. They are intended for the named recipient(s) only. If
you have received this email by mistake, please notify Glenn Kelley,
the sender, immediately and do not disclose the contents to anyone or
make copies thereof.
Lots of replies saying which of BIRD/exabgp/frr/quagga/openbgpd folks prefer, but they're all pretty good. Honestly for such a project they're all just as great, it comes down mostly to what you're used to config-wise. Used to big metal router configuration? You might find BIRD foreign. Used to more functional code stuff? BIRD is pretty great. Others I have less experience with.
As for "something better than cobbling it together", I'd recommend just do that. Install your usual Linux/BSD distro, install one of the BGP daemons, and run a flow logger (eg pmacctd, which can split out flowspec which you can consume with whatever you're comfortable with). Setting up everything short of the actual flowspec inspection should be a half-hour endeavor, maybe three hours if you have to fight with the VM provider to get BGP filters working right :).
Matt
No argument there at all. Just felt like there was enough FUD in that link it was worth calling out that specific.
IS-IS in Quagga and FRR are not yet ready for business, is what I would caution.
I don't know if the other options support it or not.
Mark.