The companies contributed both Minipack and the Arista 7368X4 switch to OCP.
Cumulus Networks, the leader in building open, modern and scalable networks, announced at OCP Summit that Cumulus Linux is the first network operating system to fully support the Minipack next-generation modular switch platform. Developed by Edgecore and contributed by Facebook to the Open Compute Project, Minipack empowers organizations of all sizes to architect, design and scale their infrastructure with unprecedented flexibility, capacity and interoperability.
Minipack is a modular switch platform, which means together, Cumulus Networks and Edgecore are bringing the benefits of web-scale networking to the mainstream. Minipack follows the open networking principles of disaggregation that allow customers to maintain consistent automated provisioning across all their switches of different form-factors (fixed or chassis).
Minipack leverages the latest ASIC technology from Broadcom including the Tomahawk III, the industry’s highest performance switch silicon. Compared to its predecessor, Backpack, Minipack is ½ the height, uses ½ the power and offers equivalent capacity making it one of the most operationally efficient open networking data center spine switches available today.
Additionally, Minipack offers either 100GE or 400GE options with Field Replaceable Port Interface Modules (PIM)’s in the following form factors:
Networking vendors have long touted distinct routers and switches with different LAN/WAN interfaces for different customer use cases. After three decades of evolution, Ethernet now truly addresses all aspects of the present state and the next generation of networking, making it possible to support these previously separate use cases from a single common platform, which flexibly incorporates new capabilities in an open, standards-based approach. Arista, together with an ecosystem of partners including Broadcom and Cloud Titan customers, has a history of collaborating in many industry forums to define these new networking capabilities, including OCP, 25/50G and COBO, while driving next generation optics such as OSFP and QSFP-DD.
OCP announced four other new projects at the summit: Inspur-led OpenRMC (stands for “rack...
Open Rack will increase the environmental sustainability of the vendor’s future data centers and...
Behind the scenes, Verizon engineers have been preparing for 5G by migrating network core and edge...
Exatel has been pushing for a 5G model that would see all operators share the same network. Dutch...
“Much of Linkerd’s recent momentum is from folks coming to Linkerd after struggling with...
The company released a new service that accelerates access to data lakes and warehouses to simplify...
Cyber insurance actually does payout
The post Marriott data breach has cost the hotel chain only $3 million so far, after insurance appeared first on EtherealMind.
Ansible, ansible, ansible seems to be all we hear these days. There are lots of resources out there all trying to convince us this is the new way get stuff done. The reality is quite different – adoption of tools like this is slow in the networking world, and making the move is hard for command-line devotees.
Here are the three main problems I encountered in my adoption of Ansible as a modern way to manage devices:
Ansible is derived from the systems world, and is only latterly coming to be used for managing network devices. It is often said that Ansible is agentless, but when managing a Linux host (for example) the control machine pushes the Ansible playbook to that host and executes it there. In effect, *Python* is the agent.
Most network devices don’t have on-box Python, so when using Ansible against a router or a switch you have to have ‘connection: local’ in your playbook:
---
name: Get info
hosts: all
roles:
Juniper.junos # Invokes the Junos Ansible module
connection: local # Tells it to run locally
gather_facts: no
What this does is run the playbook using the local Continue reading
Marvell announced its 400 Gb/s silicon for edge data centers, Netronome unveiled new SmartNICs for...
Ah, good old Quality of Service. How often have we spent our time as networking professionals trying to discern the archaic texts of Szigeti to learn how to make you work? QoS is something that seemed so necessary to our networks years ago that we would spend hours upon hours trying to learn the best way to implement it for voice or bulk data traffic or some other reason. That was, until a funny thing happened. Until QoS was useless to us.
QoS didn’t die overnight. It didn’t wake up one morning without a home to go to. Instead, we slowly devalued and destroyed it over a period of years. We did it be focusing on the things that QoS was made for and then marginalizing them. Remember voice traffic?
We spent years installing voice over IP (VoIP) systems in our networks. And each of those systems needed QoS to function. We took our expertise in the arcane arts of queuing and applied it to the most finicky protocols we could find. And it worked. Our mystic knowledge made voice better! Our calls wouldn’t drop. Our packets arrived when they should. And the world was Continue reading