Unscrewed: A Story About OpenBSD
skeptech.org
Unscrewed: A Story About OpenBSD
1–10 of 67 posts
Re: Unscrewed: A Story About OpenBSD
#2Commodity 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 missing?
Re: Unscrewed: A Story About OpenBSD
#3Commodity 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…
I think it's mostly about support and SLAs. Some people like to know that if something goes wrong there's a vendor they can shout at.
Re: Unscrewed: A Story About OpenBSD
#4Commodity 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…
> Honestly I wonder, who the hell buys these overpriced networking appliances?
people that need to switch more packets than what you buy off of newegg can handle.
edit: oh that and when you have a network of thousands of routers and switches that you want to centrally manage in a way that "mass ssh" doesn't scale to and you just want to buy the management software from someone that has written it before and not spend a while getting the software wrong before you get it right.
if you can count the number of routers you need in your head, you probably should just be using beige boxes with a commodity OS...
Re: Unscrewed: A Story About OpenBSD
#5Can that hardware keep up with crypto bitrate and firewall rules, on multiple 10gb links?
Re: Unscrewed: A Story About OpenBSD
#6Commodity 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…
I think it's mostly about support and SLAs. Some people like to know that if something goes wrong there's a vendor they can shout at.
Sadly though, shouting at a vendor doesn't fix your issues within a couple of hours, and downtime can be a pain.
Running Linux/*BSD/Whatever on off-the-shelf boxen which you can pickup everywhere (and have cheap spares) and fix yourself will let you get back online quickly.
Re: Unscrewed: A Story About OpenBSD
#7Regarding first paragraph of the story (redundant pair or routers crashing at once), it worth mentioning one possible neat trick to avoid this: When having a redundant pair of devices (routers, etc.), make sure such pair is comprised of devices made by different vendors - thinking here being that if there is a bug that triggers router crash, it's unlikely that two different vendors would be vulnerable to the same one.
Or with a generous budget, you can do what BT have done with their 21CN project: For each macro-block (access, aggregation, core), have two redundant networks each one built by a different set of vendors.
Re: Unscrewed: A Story About OpenBSD
#8Commodity 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 configuration and be done. Correctly replicating a DIY setup is harder, especially if the person building it didn't do a perfect job at documenting it.
Appliances promise all sort of fancy features that might be hard to exactly replicate yourself (if you actually need them often is a different question, but often networking isn't exactly in a position to say "no" to such requests). Although there is more and more a trend of manufacturers also offering the software for virtual environments, many appliances are x86-servers anyways.
+ as the article mentions all those cases where you need specialised hardware, e.g. routing/switching at high speeds, or working in special environments.
Re: Unscrewed: A Story About OpenBSD
#9Earlier quoted context omitted.
I think it's mostly about support and SLAs. Some people like to know that if something goes wrong there's a vendor they can shout at.
Sadly though, shouting at a vendor doesn't fix your issues within a couple of hours, and downtime can be a pain. Running Linux/*BSD/Whatever on off-the-shelf boxen which you can pickup everywhere (and have cheap spares) and fix yourself will let you get back online quickly.
If it's not your money you're spending, then the support contract helps take the heat off you when there are problems. Also, the junior staff can do things when there are problems and you're not in the office.
Re: Unscrewed: A Story About OpenBSD
#10Regarding first paragraph of the story (redundant pair or routers crashing at once), it worth mentioning one possible neat trick to avoid this: When having a redundant pair of devices (routers, etc.), make sure such pair is comprised of devices made by different vendors - thinking here being that if there is a bug that triggers router crash, it's unlikely that two different vendors would be vulnerable to the same one…
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.