Why the LSO Market Will Be Billions of Dollars
Carrier SDN will drive new software called Lifecycle Service Orchestration, the next step beyond OSS/BSS.
The Magnificent 7
Our Cumulus Networks team is very excited that Supermicro has joined our Open Hardware partner program, the latest major IT systems provider to join the industry-wide open networking movement.
Now there are Seven.
Supermicro is a leading innovator in high-performance, high-efficiency server, blade, storage, and networking technology for Green Computing – worldwide. Cumulus Linux on Supermicro bare-metal switches further extends the reach of the Supermicro solutions, enabling rapid deployment of a highly scalable, cost effective software-defined network infrastructure for data center, cloud, enterprise IT, big data and HPC.
As our seventh Open Hardware partner, Supermicro is now part of a very impressive list of providers on the Cumulus Linux HCL: Agema, Dell, Edge-Core, HP, Penguin, Quanta Cloud Technology (QCT), and Supermicro.
What does it mean for the industry? Open Networking is inevitable and Cumulus Networks is leading the way.
Major changes are underway in the IT industry that improve data center networking, allowing organizations of all sizes to leverage efficient technology that was developed by the world’s largest cloud operators. The resulting data center networks scale more easily, enable much faster innovation, and cost significantly less to build and operate. With data center infrastructure leaders like Supermicro embracing Continue reading
Managing your Out-of-Band Network with Linux
Initially when I was asked to blog about out-of-band management I thought to myself, as most people would, “this is too basic!” What new thing could I cover? Generally speaking, out-of-band management, like management in general, is an afterthought. With that typical attitude, we make the mistake of placing low value on access to our network devices, seeing it as a simple back door when in reality it could provide so much more.
The idea of creating the Cumulus® RMP (Rack Management Platform) came about after talking to several customers whose approach was to purchase low-end switching platforms to meet their out-of-band management needs. These closed network platforms provide such limited feature sets that it’s easy to dismiss their usefulness. The team sat down and came up with the idea to “complete the rack.” Why not provide the same open networking capabilities that Linux servers and Cumulus® Linux® switches offer for out-of-band management? Thus Cumulus RMP was created.
Typical Deployment Scenarios
In general there are two basic scenarios when it comes to out-of-band management. The first provides a simple but versatile L2 flat design leveraging VLANs to manage the switches and servers in the rack. The Cumulus RMPs Continue reading
Traceroute and Not-so-Equal ECMP
I came across an odd little issue recently involving equal-cost multipath (ECMP) routing and traceroute. Traceroutes from within our network to destinations out on the Internet were following two different paths, with one path being one hop longer than the other. This resulted in mangled traceroute output, impeding our ability to troubleshoot.
The relevant network topology comprises a mesh of two edge routers and two core switches. Each edge router has a number of transit circuits to different providers, and advertises a default route via OSPF to the two core switches below. The core switches each load-balance traffic across both default routes to either edge routers.
Because each edge router has different providers, some destinations are routed out via edge1 and others via edge2, which means sometimes a packet will be routed to edge2 via edge1, or vice versa.
Routers typically employ a hash function using layer three and four information from each packet to pseudo-randomly distribute traffic across equal links. Typically, all packets belonging to a flow (e.g. all packets with the same source and destination IP and port numbers) follow the same path.
However, in this case traceroute packets were being split across two path of unequal Continue reading
Traceroute and Not-so-Equal ECMP
I came across an odd little issue recently involving equal-cost multipath (ECMP) routing and traceroute. Traceroutes from within our network to destinations out on the Internet were following two different paths, with one path being one hop longer than the other. This resulted in mangled traceroute output, impeding our ability to troubleshoot.
The relevant network topology comprises a mesh of two edge routers and two core switches. Each edge router has a number of transit circuits to different providers, and advertises a default route via OSPF to the two core switches below. The core switches each load-balance traffic across both default routes to either edge routers.
Because each edge router has different providers, some destinations are routed out via edge1 and others via edge2, which means sometimes a packet will be routed to edge2 via edge1, or vice versa.
Routers typically employ a hash function using layer three and four information from each packet to pseudo-randomly distribute traffic across equal links. Typically, all packets belonging to a flow (e.g. all packets with the same source and destination IP and port numbers) follow the same path.
However, in this case traceroute packets were being split across two path of unequal Continue reading
Traceroute and Not-so-Equal ECMP
I came across an odd little issue recently involving equal-cost multipath (ECMP) routing and traceroute. Traceroutes from within our network to destinations out on the Internet were following two different paths, with one path being one hop longer than the other. This resulted in mangled traceroute output, impeding our ability to troubleshoot.
The relevant network topology comprises a mesh of two edge routers and two core switches. Each edge router has a number of transit circuits to different providers, and advertises a default route via OSPF to the two core switches below. The core switches each load-balance traffic across both default routes to either edge routers.
Because each edge router has different providers, some destinations are routed out via edge1 and others via edge2, which means sometimes a packet will be routed to edge2 via edge1, or vice versa.
Routers typically employ a hash function using layer three and four information from each packet to pseudo-randomly distribute traffic across equal links. Typically, all packets belonging to a flow (e.g. all packets with the same source and destination IP and port numbers) follow the same path.
However, in this case traceroute packets were being split across two path of unequal Continue reading
In theory…
I don’t normally peruse the reviews of my books — while I appreciate well thought out criticism, I normally find personal notes from folks who’ve read my books more profitable for mining out where I’m falling down on the job as a writer than reviews posted on book seller or book review sites. But one specific book review caught my eye the other day that I think points to a larger issue in the world of engineering, especially network engineering. The reviewer stated, in essence, that there was not enough practical application in my more recent tomes, and that I’m covering the same information over and over again.
Let me begin here — I’m not writing this as a defense of my own writing so much as to think through a habit of mind I think doesn’t really help us as an engineering community.
As far as the facts on the ground go, the reviewer is right on both counts, and wrong on both counts. Let’s imagine, for a moment, that you want to understand how a car works. You approach three different people — one a race car driver, another a top flight mechanic, and another an engineer who Continue reading