"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.
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.
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.
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.
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?
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.
Extremely stable, but not extremely secure. This could be said for many companies, and Cisco shouldn't really be singled out here, but I think this is part of tptacek's overall point. The world should move away from huge C code-bases for critical infrastructure and adopt "safer" languages (Personally I love Go, but Rust may be a better option for high-speed packet routing).
I thought the replacement of Telnet with OpenSSH was fairly fast? Few years at most, it seemed to almost happen over night compared to the move from SSL to TLS for example.
SSH had been around for some five years or so before OpenSSH arrived. It slowly gained popularity on telnet/SSL and kerberized telnet because of the trivial small scale deployment, but also because it was a drop in replacement for rsh. Had it been fundamentally different it wouldn't have gone so easy, and I suspect the familiar language helped there.