If you’ve recovered from the shock of hearing me say something positive about Cisco’s Data Center Network Manager (DCNM) product, then you’ll want to hold on tightly to your underbritches as I tell you that I just used DCNM ISSU to perform disruptive software upgrades on eight of the switches in my ethernet fabric, and–spoiler alert–it was actually a fairly pleasant experience!
DCNM offers management of ISSU (In-Service Software Upgrade). ISSU usually implies some kind of hitless (to the revenue ports) upgrade, historically made possible on the Nexus 7000, for example, by having dual supervisor modules and using Non-Stop Forwarding (NSF) to keep the forwarding plane intact while the supervisors failover. With the single-CPU layer-2 Nexus 5600 switches, however, the data plane can be told to continue forwarding frames while the control plane reboots with new code, allowing for an upgrade to take place without interruption.
Unfortunately it’s not always possible to perform a non-disruptive upgrade. The code version I was installing included a fix to the linecard BIOS, so the linecards had to be reloaded as well as the main CPU. In other words, the switch has to be rebooted after the upgrade, and there’s Continue reading
Containers continue to gain momentum as organizations look for greater efficiencies and lower costs to run distributed applications in their increasingly virtualized datacenters as well as for improving their application development environments. As we have noted before, containers are becoming more common in the enterprise, though they still have a way to go before being fully embraced in high performance computing circles.
There are myriad advantages to containers, from being able to spin them up much faster than virtual machine instances on hypervisors and to pack more containers than virtual machines on a host system to gaining efficiencies …
A New Twist On Adding Data Persistence To Containers was written by Timothy Prickett Morgan at The Next Platform.
Looks like the culprit in the recent Cisco debacle is the Intel Atom “System on Chip” (SoC) that Cisco used in it’s gear. My sources within Cisco won’t give up the goods, but many seem to be pointing to Cisco, although a single source at Cisco seemed to indicate there was another player included in this issue but wouldn’t comment. The real footing of these Intel accusations come from Intel itself. Back in Janurary 2017, they updated their spec document documenting an issue with the LPC clock on the Atom s2000, with no workaround and a system that is unable to boot, this depicts a grim outlook for our networking devices.
The news gets worse though, according to a recent article from The Register Cisco isn’t the only one experiencing issues.
People with Synology DS1815+ storage boxes have been reporting complete hardware failures; the DS1815+ is powered by an Intel Atom C2538. […]
Other vendors using Atom C2000 chips include Aaeon, HP, Infortrend, Lanner, NEC, Newisys, Netgate, Netgear, Quanta, Supermicro, and ZNYX Networks. The chipset is aimed at networking devices, storage systems, and microserver workloads.
For now, only time will tell what other devices are going to come out Continue reading