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

Unscrewed: A Story About OpenBSD

skeptech.org

Post reply on HN
Print view View original

31–40 of 67 posts

Re: Unscrewed: A Story About OpenBSD

#31

Post by richardwhiuk »

corysama wrote: post #30
wolf550e wrote: post #5

Can that hardware keep up with crypto bitrate and firewall rules, on multiple 10gb links?

The Snabb Switch crew are starting to work on support for basic handling of packets on 100G NICs. However... > With the new CPUs tending to increase the core count while the CPU frequency goes down, we'll get less and less "CPU cycles per packet". For example E5-2699v3 45M is 18 cores@2.3GHz. 10Gbps with 256 byte packets is achieved with 4.53Mpps, this makes ~500 clocks per packet on this CPU. Now make this 100Gbps a…

Normally the solution is to have the NIC give you multiple receive queues and then tie each queue to a different core, meaning you get a packet on each core every time you clock them off the NIC. Increasing CPU cores gives you a massive win when you do that.

(On a hardware note, increasing cores and decreasing frequency makes the CPU look more like an ASIC :) )

Re: Unscrewed: A Story About OpenBSD

#32

Post by _yy »

jerf wrote: post #24
_yy wrote: post #10

Earlier quoted context omitted.

No such thing as session synchronization for different vendors. You also need to configure everything for both of these vendors, which may or may not have equal feature sets.

It's hard to have independence without independence. You want separate, you're going to have to deal with separate.

Yeah but no sane organization is going to do that. It would create so much headache.

Re: Unscrewed: A Story About OpenBSD

#33

Post by aexaey »

jlgaddis wrote: post #26
_yy wrote: post #10

Earlier quoted context omitted.

No such thing as session synchronization for different vendors. You also need to configure everything for both of these vendors, which may or may not have equal feature sets.

Maybe for firewalls (synch'ing state), but for routers there's VRRP, at least.

In the context of hosting/cloud network what would probably be load balancer / reverse proxy which has the most state/sessions. And incidentally, LBs are probably the piece of dedicated network iron most ripe to be replaced with a bunch of commodity servers and some software.

Regardless, statefulness is bad of course, and less of it you have, the better you are off - we've seen this time and again: share nothing arch[1], Amdahl's law[2], locks-vs-RCU[3], memorizing tcp flows-vs-IP header hash[4,5], etc... Being able to make decision on current packet/memory access here and now, independently, without having to keep track of other flows/connections/sessions/threads beats alternative approaches every time [6].

[1] https://en.wikipedia.org/wiki/Shared_nothing_architecture

[2] https://en.wikipedia.org/wiki/Amdahl's_law

[3] http://www.rdrop.com/users/paulmck/RCU/hart_ipdps06.pdf

[4] https://tools.ietf.org/html/rfc2992

[5] http://www.juniper.net/techpubs/en_US/junos13.2/topics/conce...

[6] Intel's heroic effort to maintain cache coherency at all cost is a notable exception, although opinions vary wildly on whether this is actually the best thing to do, and how long they will be able to sustain it.

Re: Unscrewed: A Story About OpenBSD

#34

Post by scurvy »

A couple of elephants in the room:

Why on earth were you running a hosting business with Cisco 2950s? Those are wiring closet desktop switches with tiny buffers. That alone probably caused a lot of pain. You didn't know about it, but they did.

Second, the Juniper J4350 is a software router based on BSD. There's no special hardware in there like ASICs. It's just a PC.

JunOS (historically) is based on BSD. They're moving to Linux now.

I love OpenBSD for small projects too, but let's admit that there was some bad logic in this decision making process. This could be called "how the mx10 saved my ass because I went with undocumented, unproven open source project that has been on github for 3 days" if the technologies were reversed.

Re: Unscrewed: A Story About OpenBSD

#35

Post by maaarghk »

lmm wrote: post #2

Commodity hardware and general-purpose systems win every time. Honestly I wonder, who the hell buys these overpriced networking appliances? Similarly with expensive proprietary databases, or ESB systems. Are they just leftovers of a different time (note article is from 2007)? Is it a case of management buying from the salesman who bought them a nice dinner? Some place where these things generate actual value that I'm…

Remember that "nobody ever got fired for buying IBM".

Re: Unscrewed: A Story About OpenBSD

#37

Post by jerf »

_yy wrote: post #32
jerf wrote: post #24

Earlier quoted context omitted.

It's hard to have independence without independence. You want separate, you're going to have to deal with separate.

Yeah but no sane organization is going to do that. It would create so much headache.

A sane organization will do it if the benefits outweigh the risks. An organization with sufficient risks will chose it. Most won't, because the risks (specifically, hard cash) won't be outweighed by the benefits.

But that's incidental to what was my real point, which is that if you do want a separate network, it has to be separate. Tie your two "separate" networks together with integration and you're returning single-points-of-failure back into the mix. Granted, practicality may dictate a couple of those... integrated authentication comes to mind... but you don't want the two separate networks to be all slickly and smoothly integrated for the most part.

Re: Unscrewed: A Story About OpenBSD

#38

Post by EvanAnderson »

detaro wrote: post #8
lmm wrote: post #2

Commodity hardware and general-purpose systems win every time. Honestly I wonder, who the hell buys these overpriced networking appliances? Similarly with expensive proprietary databases, or ESB systems. Are they just leftovers of a different time (note article is from 2007)? Is it a case of management buying from the salesman who bought them a nice dinner? Some place where these things generate actual value that I'm…

People who want to have support by a large vendor. If your DIY-setup fails you can't blame a vendor. In theory using the same kind of appliance as everybody else means you can easily find an networking guy to work with it, people who are good at both traditional networking gear and BSD/Linux are harder to find. If a dedicated box fails you can just have someone with some experience plop a new one in, reapply the conf…

I've heard the "blame a vendor" argument again and again in my life, but I have yet to see this "blame" ever occur. Granted, I'm dealing with small and medium-sized companies, but I've never seen any kind of tangible financial outcome from "blaming" a vendor (other than that vendor not getting future sales).

Re: Unscrewed: A Story About OpenBSD

#39

Post by mioelnir »

scurvy wrote: post #34

A couple of elephants in the room: Why on earth were you running a hosting business with Cisco 2950s? Those are wiring closet desktop switches with tiny buffers. That alone probably caused a lot of pain. You didn't know about it, but they did. Second, the Juniper J4350 is a software router based on BSD. There's no special hardware in there like ASICs. It's just a PC. JunOS (historically) is based on BSD. They're movi…

> JunOS (historically) is based on BSD. They're moving to Linux now.

Do you have details on this? Given how active they are in the FreeBSD community, I would have thought to have heard about that already.

Re: Unscrewed: A Story About OpenBSD

#40

Post by profeta »

scurvy wrote: post #34

A couple of elephants in the room: Why on earth were you running a hosting business with Cisco 2950s? Those are wiring closet desktop switches with tiny buffers. That alone probably caused a lot of pain. You didn't know about it, but they did. Second, the Juniper J4350 is a software router based on BSD. There's no special hardware in there like ASICs. It's just a PC. JunOS (historically) is based on BSD. They're movi…

well, he did mention the lack of $150k for the proper cisco hardware.
Post reply on HN