Cisco is making it more difficult to use used hardware
ifixit.com
ifixit.com
Eventually reputable vendors began to pop up. I recall doing a great deal of business (>$1m) with a company called "Network Hardware Resale". They're still in business as "Curvature" and I believe still moving second hand network and server gear as well as providing support.
There have been times that I recall when lead times for Cisco gear have exceeded 8 weeks, when I didn't have any other options other than using refurbished gear.
From my perspective, Cisco is nothing more than a company looking to extract as much money as possible out of Enterprise IT shops. They pretty much gave up the service provider market. IOS has gone a million different directions, and they've been slow to embrace IAC.
Back when I was buying refurb gear, I was also buying some new and some officially re-marketed gear. I'd get support for the chassis and supervisor modules (Cat 6500) so that I could get reliable software updates.
My sales rep's regional manager sent a threatening letter to the VP of my department with some dire warning about how we were in violation of the law or some such. We all ended up in a meeting in which they produced a list of serial numbers of gear that we'd sought support on that were supposedly grey-market. We produced the same list of serial numbers on invoices for legit Cisco certified re-marketed equipment. They'd just failed at record-keeping. My VP was livid and threw them out of his office. Pretty sure they got fired after.
Anyway, this is all just a tactic to extract the most money possible. It'd be irrational to choose Cisco for any new network deployment these days.
I'm interested what you would buy instead? In the UK SME space I see mostly HP, Watchguard, Unifi. Lease lines still often come with Cisco gear (supplied by the provider). Otherwise I only see Cisco at the bigger entities.
Their CCR-series is very much bang per buck if L4-filtering is enough, which should be enough in today's world of end-to-end encrypted communications.
The CRS3xx-series as stated has become much saner with changes to bridging and with most features implemented are also worth the cost.
The upside with affordable devices and the licensing model they have, make it possible to keep cold spares available in case of disaster.
It does however make sense to study the management interfaces and disable all but SSH and HTTPS in order to minimize attack surface.
I used to test changes (when duties allowed) with nmap, and several times I showed experienced engineers that they had left a service open to the WAN by mistake! When a network is in the hands of general engineers, like it often is in the SME space, I like Watchguard firewalls. Very good defaults, helpful os.
I can imagine in a datacenter where you have network specialists, and robust working procedures Mikrotik could work well.
I use Unifi for Wifi, and have used their routers for a dedicated guest wifi network. For switches I know nothing other than HP, but don't see a lot of issues, especially with the Aruba kit.
The firewall in Mikrotik-devices is among the cleanest I've seen and very hard to miss-configure as long as the firewall is otherwise configured to not let unauthorized traffic through.
And yes, people are people and this is why we educate people when needed.
If I were doing data center switching, I'd buy something Broadcom based on which I could run something like Cumulus Linux.
For wifi, I like Unifi. For routers, Juniper is fine. Arista seems to be well-regarded in the switching space as well. Basically anything but Cisco.
That said, I haven't had to think about network elements for quite a few years.
If you have a small network team UniFi would be a perfect fit. It’s very manageable and support is great.
in the enterprise, ubiquiti and HP seem to still be quite relevant. The amount of HP procurve gear in use is rather large.
My first job was writing drivers for chips on that switch. My recent experience is with younger tech companies, so I'm sure recruiters get some false positives when they search for resumes with "ios."
https://null.53bits.co.uk/index.php?page=7600-forwarding-asi...
Got a little PTSD just looking at that page.
Regardless, ONIE + ONOS has been an excellent choice for a while now.
I’m hoping someday cheap whitebox switches start entering the market, fs.com has a couple but they’re still out of reach for small shops and hobbyists compared to getting used gear off eBay.
A lot of effort is going to the 10G and 100G top of rack models because that's usually where you can backport to 1G/10G access switches. The core switches and more complex models have not seem much success.
Even with perfect documentation, it's not something that you can just fire up a BSD on - getting it all supported and running requires many years of works. Many of the functionalities of those routers make special assumptions to boost performance and don't even fit into a standard network stack, so minimally, you would need to develop your own functional network stack for that.
Or at least that's my impression of them, correct me if I'm misinformed.
We’re not there yet but the situation is definitely changing / improving.
But only if you can use that commodity hardware. If you need the stuff running on ASICs, it's as the parent describes and I don't see how that could change.
Can whitebox solutions ever offer the same performance as boxes from cisco etc? If not then I'm not convinced there will be much more improvement coming.
Cisco's entire Nexus line of switches was there entry into the market with merchant silicon. Their costs were much lower, but their pricing per port stayed roughly the same as their Catalyst line driving up margins. Adoption was pretty lackluster however until they started offering massive discounts on the Nexus products.
Anyway, you can generally get non-blocking line rate on all ports out of any Broadcom reference design. The only distinction between that and a Cisco is the how the device is managed.
Layer 3 forwarding is all the same. Whitebox stuff generally comes with simple routing protocol implementations.
Cisco, Juniper, et al. have routing protocol implementations generally guaranteed to work with their other network elements. That's how the L3 forwarding tables get populated.
Whether that makes a difference depends on the network architecture. FAANG companies and others are deploying whitebox switches, building "underlay" networks using eBGP, and using SDN as an overlay basically obviating the need to have much intelligence built into the network element.
Cumulus Linux replicates these efforts to some extent. One gets a whitebox switch running Linux with open source routing protocol implementations and configuration via something like ansible.
That's why a lot of engineering is based around getting data planes working, and ignoring most of the control plane that runs on the application processor. Even if you only get that to control the ASICs and run a simple REST server to accept data plane control commands it's already enough to turn a switch into something useful forever.
Setting them up is a PITA and almost an order of magnitude harder than DDR memory training or x86 bootstrapping without an FSP/BSP. But it's possible and has been shown to work.
Other projects like Open Compute and ONIE give a lot of insight for reverse engineering of newer fabric and data plane components which significantly shortens the process of reversing and re-using existing hardware.
The control plane side of things is much easier in that regard as they are commonly generic ARM or POWER architecture SoCs with generic Flash/PROM components running a more generic RTOS (i.e. one that is used across an entire line of products and supping many data planes) or even a Linux based OS. That, combined with easy to extract firmwares and JTAG + Serial makes the control plane a lot less complex than the data plane. This is also why control planes are usually left alone because you can drop in any control plane software we already have and focus on interfacing with the ASICs instead.
Wow, an order of magnitude harder that booting x86 without FSP, but it's still possible... I can't imagine that. I salute the efforts.
Eyeopening! Thanks.
The problem with the Cisco ones is mostly because they sit somewhere in between FPGAs and a Barrel CPU. Without the custom loading and init they are essentially useless.
Think of them as an FPGA with a softcore CPU. If they are empty they have no CPU so you can't run code on them. If you fill them with Cisco core data you get no use out of them without logging in to their DRM server. So you need to feed them the softcore but without the cisco runtime code.
No idea what Cisco does specifically, but I've worked with other gear or software that worked like this.
https://www.cisco.com/c/en/us/td/docs/wireless/technology/me...
Too many customers are ISPs and gifts who do not want core infra connected to the internet.
It doesn't sound unusual to me, I feel it's just the usual "Enterprise" bullshit, where you have little control or internal knowledge over your equipment, and must follow a restrictive licensing plan and use official support to keep it running. I think the most extreme version is the IBM mainframe computers, if you DRM license module is inoperative, the computer is essentially reduced to a huge piece of useless junk. Other enterprise hardware/software is not too restrictive, but still follows the same pattern, such as Oracle products.
Also, degrading a device because of a license issue can become a huge liability.
What if the smart licensing service has a technical error, and all switches in your datacenter go down because they no longer support the software features you require?
From my experience with other datacenter network vendors, most seem to just do a vanity kind of licensing where they basically audit you every X years for licenses.
I wonder what the landscape is like in Europe for things like this. I know some countries are more diligent about physical products having a longer useful life than others.
https://www.gov.uk/guidance/regulations-waste-electrical-and...
https://www.cisco.com/c/en/us/about/product-innovation-stewa...
I'd like to see their salesperson try and explain the advantages of this to my CIO.
seem like good devices for a small environment or at home, but the stability left a lot to be desired.
Back in the IOS days there were many stories of calling into smartnet and finding the hardware you bought new from CDW had a serial different from Cisco’s master list. Cisco would cut you off for fear of liability, the owner would dump the hw onto the used market and lather-rinse-repeat with another unsuspecting fowl.
Anyways, when you're buying hardware at this price point, you're not just paying for a box that moves packets.
In many cases, they already are, though it's debatable whether it's ready to compete head-on with the major commercial offerings. You can buy white box switches and open software platforms to control them for SDN purposes right now, for example. But I'd say so far the main SDN suites haven't built up a great reputation and a lot of IT groups still prefer to source everything from one supplier with an expensive but all-encompassing support contract.
Just because you have a Broadcom chip doesn’t mean you need to use some new-fangled centralized / crontroller based control plane.
Disclaimer: I work for Nokia, we also make big switches, I believe we have a similar licensing model for certain products.
The deployment model for grey market bit is usually on networks that run on cheap models. They'll do things like buy one of the devices through white channel market and get SW access. Then, they'll turn around and buy a bunch more grey channel devices and use the SW access to upgrade, etc. As long as the device can handle the PPS and bitrates needed, its good enough for these networks. If it dies, buy another one and let it hang until it gets replaced. There are plenty of networks that just don't care about the operational issues.. and they love to keep cisco because of talent pipeline and training ecosystem.
Anyway, running equipment without vendor support is fine. If its a config issue, the docs are okay. If it is a bug, 9 times out of 10 TAC throws a random bug ID and tells you to upgrade. Naturally, It becomes an issue more when you run on the periphery of what is supported.
It must be hell for these guys when they hit a show-stopper in old sw and they have no access to the fixed sw for their old hw.
If you don't like the license model of IOS (etc), buy hardware that is supported by free/open source OS instead.
The last thing I want is another failure mode in my critical path.
But since smartphones are mere terminals and computers are trending that way too it won't be long before a freely programmable computer will be a rarity.
Software distribution is now centralized to the point that we have lost a lot compared to just two decades ago. Freeware and shareware would be unthinkable today, direct-to-the-user by virtue of downloading from the creator. App-stores and self-bricking hardware are the new normal.
They have no business relationship with the buyer of second hand Cisco gear.
If you don't like it, but something else.
But capitalism itself is going concentrate ownership, removing it from the vast majority of people. At that point what's the point?
Speaking of Cisco, if the Soviet Union lasted 10 more years, would we all have IPv6 by now? (Not to say that I want more Soviet Union.)