4 ms·

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 s

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.

tptacek 10y ago
Quagga/Zebra is a giant C project. The industry is moving away, as much as it can, from serving critical infrastructure on giant C programs.
- Rapzid 10y ago
  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.
  - tptacek 10y ago
    "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 same electronic component that forwards packets.
    - Rapzid 10y ago
      I'm not playing on anything; just not aware of a trend away from C for this stuff.
    - xorcist 10y ago
      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.
      - tptacek 10y ago
        I didn't say it was. But then: I don't trust that Cisco C code at all. Do you?
        kbenson 10y ago
        In the decade I worked at an (smaller, regional) ISP, there were a number of times that I know of that Cisco provided a custom firmware to us get around a bug we found that prevented regular configuraitons from working as expected. Considering the scale of Cisco, and that we were small enough at the time to need less than five people in network operations, I find that terrifying. They weren't security issues, but it does point towards their code base being too complex for them to adequately manage.
        sre_ops 10y ago
        Yes. It currently runs over 70% of global internet and considering all kinds of error conditions that show up on the global internet the code is extremely stable.
        tptacek 10y ago
        Sendmail used to run on something like 90% of the global Internet. And mail in the 1990s pretty much did work, pretty reliably. Would you have banked your site's security on the quality of Sendmail 8.6.12's code?
        nickpsecurity 10y ago
        Slam dunk on that comment! Such systems, due to lots of debugging, can work reliably in a narrow set of use cases where specific features have massive use. Then there's the uncommon, usage scenarios and features that get much less debugging. Then there's all the patches they keep distributing to fix... "things." And then the fact that safe, reliable code is only first step toward secure code where an intelligence, malicious person is targeting it. Totally different ballpark that neither Sendmail nor Cisco handled so well. Small shops like Sentinel and Secure64 did way better with a tiny fraction of the money. So, it has to be intentional for the extra profit at customers' expense.
elliotf 10y ago
I would imagine/hope that it's more about integration with other code than using it solely as a BGP daemon. The repo seems to be related to http://osrg.github.io/ryu/ http://osrg.github.io/ryu/ which is a "software-defined networking framework" Off-hand, you could use GoBGP to do cheap loadbalancing-ish things without external dependencies.
misframer 10y ago
Go is easier to profile and test.
detaro 10y ago
Nicer to integrate with other stuff maybe. E.g. for simple "just announce these routes" or a looking glass, where I'd right now might use the (python-based) ExaBGP
- AdamJacobMuller 10y ago
  Indeed, this is great for things where you want to do programmatic manipulation of routing. Something which ExaBGP is good at, but is very slow and Quagga/BIRD are really poor at, but are quite fast at.
wmf 10y ago
This is not due to being written in Go, but GoBGP looks like it has a nicer (non-Cisco-clone) configuration language.

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.

tptacek 10y ago

Quagga/Zebra is a giant C project. The industry is moving away, as much as it can, from serving critical infrastructure on giant C programs.

Rapzid 10y ago
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.
- tptacek 10y ago
  "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 same electronic component that forwards packets.
  - Rapzid 10y ago
    I'm not playing on anything; just not aware of a trend away from C for this stuff.
  - xorcist 10y ago
    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.
    - tptacek 10y ago
      I didn't say it was. But then: I don't trust that Cisco C code at all. Do you?
      - kbenson 10y ago
        In the decade I worked at an (smaller, regional) ISP, there were a number of times that I know of that Cisco provided a custom firmware to us get around a bug we found that prevented regular configuraitons from working as expected. Considering the scale of Cisco, and that we were small enough at the time to need less than five people in network operations, I find that terrifying. They weren't security issues, but it does point towards their code base being too complex for them to adequately manage.
      - sre_ops 10y ago
        Yes. It currently runs over 70% of global internet and considering all kinds of error conditions that show up on the global internet the code is extremely stable.
        tptacek 10y ago
        Sendmail used to run on something like 90% of the global Internet. And mail in the 1990s pretty much did work, pretty reliably. Would you have banked your site's security on the quality of Sendmail 8.6.12's code?
        nickpsecurity 10y ago
        Slam dunk on that comment! Such systems, due to lots of debugging, can work reliably in a narrow set of use cases where specific features have massive use. Then there's the uncommon, usage scenarios and features that get much less debugging. Then there's all the patches they keep distributing to fix... "things." And then the fact that safe, reliable code is only first step toward secure code where an intelligence, malicious person is targeting it. Totally different ballpark that neither Sendmail nor Cisco handled so well. Small shops like Sentinel and Secure64 did way better with a tiny fraction of the money. So, it has to be intentional for the extra profit at customers' expense.

elliotf 10y ago

I would imagine/hope that it's more about integration with other code than using it solely as a BGP daemon. The repo seems to be related to http://osrg.github.io/ryu/ http://osrg.github.io/ryu/ which is a "software-defined networking framework" Off-hand, you could use GoBGP to do cheap loadbalancing-ish things without external dependencies.

misframer 10y ago

Go is easier to profile and test.

detaro 10y ago

Nicer to integrate with other stuff maybe. E.g. for simple "just announce these routes" or a looking glass, where I'd right now might use the (python-based) ExaBGP

AdamJacobMuller 10y ago
Indeed, this is great for things where you want to do programmatic manipulation of routing. Something which ExaBGP is good at, but is very slow and Quagga/BIRD are really poor at, but are quite fast at.

wmf 10y ago

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