In the past, I’ve designed, deployed and operated networks of various sizes, needs and scopes. One of the perennial design points common to all of them is how to approach the out-of-band (OOB) network. When it comes to making sure your production network operates in the face of issues, the OOB network is often a critical component. But it also raises the question of how to build it, what components to use and how much they affect the “day job” of running the production network. These decisions haven’t always been easy.

Generally, there is a spectrum of approaches. On one end is the choice to go with the same gear that you are deploying in the production network. On the other end is the decision to just build the OOB network out of what you can get from the local or online electronics superstore. One can cause you budget problems; the other raises the question if your OOB network will be there when you most need it. All too often the most frugal designs win, and this can cause you to have to troubleshoot the OOB network before you can troubleshoot the production network. So the issue is more than just the initial acquisition cost, but also the recurring costs both for external and internal support.

Even if you decide to go with OOB gear from the same manufacturer as the production gear, it doesn’t always mean that the same configuration ability, features or operational characteristics are going to be carried over to the platforms selected. Some even use different, stripped down versions of their software. Operationally, you might not gain as much as you thought and maybe the “bargain basement” way might be the better way to go.

But that is not the case anymore. Owing to the disaggregated revolution that Cumulus Networks, our hardware partners and others have been bringing to the market, the best of both frugal and consistent strategies is now possible. Cumulus RMP (Rack Management Platform) gives you a cost-effective OOB switch with the same interface and extensibility that Cumulus Linux provides you on your production network. Both leverage the open Linux configuration model and enable you to reuse any tools or methods you have been leveraging with Cumulus Linux in Cumulus RMP.

Not only do you have the same tools and operational models, but because Cumulus RMP is an open Linux distribution, you also have access to the rich set of Linux tools in your OOB network. Data collection is no longer limited to SNMP, but you can now treat the platform just like how you treat a Linux server and collect your statistics with tools such as Graphite and collectd. You can now run open DHCP, TFTP, HTTP and other services directly on the OOB node to provide for more localized services that reduce the reliance on your wider network.

For example, leveraging the pre-installed dnsmasq service, you can have it act as a local DHCP pool along with your PXE/ONIE TFTP server to kickstart the imaging of the attached network devices and servers in the rack. So you no longer need to rely on your WAN connection when you are turning up a new site. And for longer term operations, you can save on bandwidth by pushing the update to the one OOB switch instead of having up to 48 of your servers all pull it down from a remote location.

Check out our page on Cumulus RMP and our webinar in which I talk in depth about using linux for managing the entire rack.

Welcome to the world of open networking across the whole of your data center network!

The post Open Networking for the Whole of Your Data Center Network appeared first on Cumulus Networks Blog.

Read more here:: Cumulus Networks

Open Networking for the Whole of Your Data Center Network