Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GoBGP: BGP Implemented in Go

github.com

Post reply on HN
Print view View original

21–30 of 130 posts

Re: GoBGP: BGP Implemented in Go

#21

Post by harshreality »

jimbokun wrote: post #6
misframer wrote: post #5

Earlier quoted context omitted.

Is that necessary? I'm not sure how many people are unaware of what BGP is.

I'm not aware what BGP is, clicked hoping to find out, was sorely disappointed.

bgp

A project page for a $language implementation of $protocol shouldn't be expected to give a basic description of $protocol. If you care about a new implementation, you already know what the protocol does, at least generally. If you're lucky, the project page links to a protocol description (possibly at wikipedia), or, as above, you can simply google it yourself and then decide whether a $language implementation of it is something you care about.

Re: GoBGP: BGP Implemented in Go

#22

Post by wmf »

devnull42 wrote: post #4

So at the moment I see no reason why Go written BGP would be better than standard Quagga/Zebra. There aren't really concurrency or resource issues with large scale Quagga in my experience.

This is not due to being written in Go, but GoBGP looks like it has a nicer (non-Cisco-clone) configuration language.

Re: GoBGP: BGP Implemented in Go

#23

Post by dsr_ »

tptacek wrote: post #11

This is the sort of thing Go really shines on: network and infrastructure services that would ordinarily be provided by big ugly C programs, where the latency requirements are significant but not as bad as raw packet forwarding. If your current best alternative is a C program, I'm not sure why you wouldn't seriously consider replacing any of the following with Go (or Rust) programs: * Authority DNS * DNS caches * ntp…

...well, because of the primary shortcoming of the Go system: lack of standard infrastructure to manage the inevitable updates.

Let's say I have replaced bind, unbound, ntpd, postfix, openssh, dovecot, snmpd and asterisk with Go-written equivalents. Three weeks later, there is a bug found in the standard Go TLS library.

My distro ships all the packages noted above, but not their Go-equivalents, so my work load now includes monitoring security-announce lists for eight different products, where before I monitored the security-announce list for my distro.

I need to be able to rebuild all eight systems myself, rather than getting automatic package updates to my test systems, and then promoting the packages through alpha and then production. Go is nicer than some other languages about that, but it builds binaries, not packages.

Next:

I'm pretty sure you can't build an snmpd without ASN.1 parsing, and ASN.1 parsing is the very model of a fraught and perilous splatter-fest. Will the Go ASN.1 parser be better maintained than libtasn? Maybe, maybe not. Repeat this for everything else.

Can these problems be solved? Sure. Are they ready right now? Not that I'm aware of. Please enlighten me, if you have good answers.

Re: GoBGP: BGP Implemented in Go

#24

Post by Rapzid »

tptacek wrote: post #14
Rapzid wrote: post #13

Earlier quoted context omitted.

I'm not aware of any trend in the area of routing/switching for linux away from C projects. nftables and open vswitch are both new-ish and written C.

"As much as it can". nftables and openvwitch both forward packets, and thus need to be written in C (or, perhaps, in the long term, Rust). Really, you're playing on a semantic ambiguity in the word "router". A BGP implementation doesn't forward packets; it maintains a database of forwarding paths that the packet forwarding layer consults. In a large Cisco router, the SOC that runs BGP and maintains the RIB isn't the…

I'm not playing on anything; just not aware of a trend away from C for this stuff.

Re: GoBGP: BGP Implemented in Go

#25

Post by JoachimSchipper »

tptacek wrote: post #11

This is the sort of thing Go really shines on: network and infrastructure services that would ordinarily be provided by big ugly C programs, where the latency requirements are significant but not as bad as raw packet forwarding. If your current best alternative is a C program, I'm not sure why you wouldn't seriously consider replacing any of the following with Go (or Rust) programs: * Authority DNS * DNS caches * ntp…

Because some C programs are pretty excellent, and rewrites cause bugs? E.g. replacing OpenNTPd, Postfix, OpenSSH - or djbdns or qmail - by a rewrite probably doesn't reduce the number of problems.

(In particular, note that SSH daemons can fail in many ways other than by remote code execution.)

In the long run, C's role is indeed shrinking - but let's not be too hasty.

Re: GoBGP: BGP Implemented in Go

#26

Post by tptacek »

JoachimSchipper wrote: post #25
tptacek wrote: post #11

This is the sort of thing Go really shines on: network and infrastructure services that would ordinarily be provided by big ugly C programs, where the latency requirements are significant but not as bad as raw packet forwarding. If your current best alternative is a C program, I'm not sure why you wouldn't seriously consider replacing any of the following with Go (or Rust) programs: * Authority DNS * DNS caches * ntp…

Because some C programs are pretty excellent, and rewrites cause bugs? E.g. replacing OpenNTPd, Postfix, OpenSSH - or djbdns or qmail - by a rewrite probably doesn't reduce the number of problems. (In particular, note that SSH daemons can fail in many ways other than by remote code execution.) In the long run, C's role is indeed shrinking - but let's not be too hasty.

For a full-featured SSH running on a machine I was likely to log into and work interactively on, I'd prefer OpenSSH.

But most of what people do with SSH in a devops context isn't interactive; it's a simple control channel for well-defined sequences of file transfers and commands.

I'd prefer a minimal, Go/Rust-based SSH server for my EC2 servers, for instance.

I don't know why I'd prefer OpenNTP to a Go/Rust NTP. What's the advantage to it? OpenNTP is carefully built to avoid a class of bugs that its implementation language is very susceptible to. Go/Rust simply don't have those bugs at all. The latter seems like the safer option.

Same goes for DNS.

Re: GoBGP: BGP Implemented in Go

#27

Post by LamaOfRuin »

misframer wrote: post #5
dragonshed wrote: post #2

I assume BGP == Border Gateway Protocol https://en.wikipedia.org/wiki/Border_Gateway_Protocol Suggestion: include a quick abstract what what BGP is with a link for more information.

Is that necessary? I'm not sure how many people are unaware of what BGP is.

I was generally aware of what Border Gateway Protocol was, but it did not immediately spring to mind when I read BGP, and the full name is not mentioned in the repo readme.

Re: GoBGP: BGP Implemented in Go

#28

Post by xorcist »

tptacek wrote: post #14
Rapzid wrote: post #13

Earlier quoted context omitted.

I'm not aware of any trend in the area of routing/switching for linux away from C projects. nftables and open vswitch are both new-ish and written C.

"As much as it can". nftables and openvwitch both forward packets, and thus need to be written in C (or, perhaps, in the long term, Rust). Really, you're playing on a semantic ambiguity in the word "router". A BGP implementation doesn't forward packets; it maintains a database of forwarding paths that the packet forwarding layer consults. In a large Cisco router, the SOC that runs BGP and maintains the RIB isn't the…

Not really. Neither the BGP layer nor the packet forwarding layer in that big Cisco box of yours is moving away from C code.

Standard network software such as Postfix and OpenSSH took ten years to replace their predecessors, and their eventual replacement will be just as gradual. It's not happening right now, so I think it's a bit of a stretch to call it a trend.

Re: GoBGP: BGP Implemented in Go

#29

Post by tptacek »

dsr_ wrote: post #23
tptacek wrote: post #11

This is the sort of thing Go really shines on: network and infrastructure services that would ordinarily be provided by big ugly C programs, where the latency requirements are significant but not as bad as raw packet forwarding. If your current best alternative is a C program, I'm not sure why you wouldn't seriously consider replacing any of the following with Go (or Rust) programs: * Authority DNS * DNS caches * ntp…

...well, because of the primary shortcoming of the Go system: lack of standard infrastructure to manage the inevitable updates. Let's say I have replaced bind, unbound, ntpd, postfix, openssh, dovecot, snmpd and asterisk with Go-written equivalents. Three weeks later, there is a bug found in the standard Go TLS library. My distro ships all the packages noted above, but not their Go-equivalents, so my work load now in…

No. I've written SNMP from scratch in Ruby, Python, and C++. DER ASN.1 for X.509 might be treacherous (simply in the sense that any mistake you make at all will be ruinous), but that's just not the case for SNMP's BER.

The whole point of using Rust or Go instead of C is that the "peril" of implementing things like ASN.1/BER is pretty much eliminated.

As for your former point: I don't follow. Go's deployment infrastructure is a superset of C's, and, if you're a masochist, almost everything in C's deployment toolkit is available to Go projects as well.

Re: GoBGP: BGP Implemented in Go

#30

Post by tptacek »

xorcist wrote: post #28
tptacek wrote: post #14

Earlier quoted context omitted.

"As much as it can". nftables and openvwitch both forward packets, and thus need to be written in C (or, perhaps, in the long term, Rust). Really, you're playing on a semantic ambiguity in the word "router". A BGP implementation doesn't forward packets; it maintains a database of forwarding paths that the packet forwarding layer consults. In a large Cisco router, the SOC that runs BGP and maintains the RIB isn't the…

Not really. Neither the BGP layer nor the packet forwarding layer in that big Cisco box of yours is moving away from C code. Standard network software such as Postfix and OpenSSH took ten years to replace their predecessors, and their eventual replacement will be just as gradual. It's not happening right now, so I think it's a bit of a stretch to call it a trend.

I didn't say it was. But then: I don't trust that Cisco C code at all. Do you?
Post reply on HN