DriveNets has been very active in helping tier-1 operators around the world towards achieving their goals. There have been some concerns in the market about the complexity of a new cloud-based model, in terms of planning, sourcing, integration, installation, growth, maintenance, and support. So it’s time to talk about our actual experience, the ins & outs of our deployments in the past two or three years, to show how disaggregated, cloud-native networks is the right path forward.
Let’s dig in!
Addressing Malfunctions on the Spot
BGP, or the Border Gateway Protocol, is the gateway protocol that enables exchanging routing information between autonomous systems (AS), through peering. Early on, during our greenfield deployment into our Tier-1 service provider customer’s production environment, we noticed several, recurring BGP failures. Thanks to DriveNets’ built-in redundancy in its disaggregated solution, there were no traffic drops at all, but identifying the cause to these failures was a priority to the DriveNets team.
After analyzing the system, the team was able to determine that the unsupported BGP community was behind these failures. The swift development and disaggregated architecture of DriveNets’ network operating system solved this issue within hours, without any impact to the end-user quality of experience.
Bottom line: despite claims from competitors that our solution could be more complex, that’s not the case even when we need to solve problems. When a protocol failure happens thanks to misconfiguration (as explained above), DriveNets’ routing expertise was a major factor to quickly find the problem and solve it immediately. With DriveNets, operators can avoid maintenance window outages, in addition to having fewer people involved in the process, reducing opex.
Risk-free Operations
Line card failure? Is immediate replacement considered?
Not really. At least not in traditional networks.
Sometimes, with legacy monolithic chassis routers, the failure of a line card has the potential of jeopardizing the continuity of the whole chassis during its replacement, as it can interfere with the delicate alignment among chassis components. Even though line card replacement is claimed to be a non-service-impacting procedure, service providers have been avoiding the risk, and performing this operation during maintenance windows only. It is important to take into consideration that power distribution, airflow, and pin connectivity are interrupted when a line card is extracted and a new one is inserted.
The Distributed Disaggregated Chassis (DDC) white box architecture adopted by DriveNets employs a separate line card system for packet forwarding (Network Cloud Packet Forwarder – NCP) and for fabric system (Network Cloud Fabric – NCF). As such, failure of any of these components does not affect the rest of the cluster in any way, and can be replaced immediately without scheduling and waiting for a maintenance window.
We have gone through this procedure with our customers and the results were clearly reflected in the significant reduced OPEX over time. In addition, it reduces the need for maintaining a hot spare inventory on site. While maintenance windows are a regular activity in the field, it demands the resources and support team in case something goes wrong. Maintenance windows are expensive and involve several risks. With DriveNets’ DDC architecture, there is no ‘domino effect’ of failures, and it can be done easily and on the fly without a maintenance window. Since all components are separated, if there are any issues, they are isolated to their specific units, and as such, the blast radius is controlled.
When There Are Problems with Zero-Touch Provisioning
As part of our Network Cloud solution, DriveNets Network Operating System (DNOS) is a cloud-native, distributed networking software, built-on containerized microservices, creating a unified, shared infrastructure over a distributed architecture. DNOS supports multiple service offerings at scale, including routing – from core to access – and hosting for third-party services. DNOS is highly integrated, and all provisioning is done automatically through DriveNets Orchestrator (DNOR). DNOR, a zero-touch provisioning orchestrator – automates the deployment, scaling, and management of the DriveNets Network Cloud solution.
In one of our deployments, we found out, through our zero-touch provisioning process, about an incorrect configuration, due to an extra network interface controller (NIC) card that was not supposed to be there per the hardware BoM (bill of materials). In fact, DriveNets discovered that this issue prevailed across multiple sites from different vendors.
Drivenets’ Support and Operations team was able to quickly and easily resolve this by coordinating with our system integrator partners, who were able to remove the extra NIC cards and ensure the right hardware configuration was delivered to each site. By supporting zero-touch provisioning, our software is able to identify such issues in the pre-deployment stage, and as such, the operating system is not blindly loaded onto unsupported or unexpected hardware.
Coming Up Next
There is no straight line when it comes to network development, and our goal is to be straightforward and transparent, highlighting the ups & downs, and how we addressed all the challenges and glitches in our customers’ networks.
DriveNets has been quite active in helping operators reach their goal towards a simpler, faster and more cost-effective cloud-native network infrastructure. In fact, KGPCo, the leading system integrator of network solutions – both legacy and disaggregated – confirmed this in a study based on their multiple network deployments of DriveNets Network Cloud solution:
Stay tuned to hear about more real-life experiences with our customers and partners.
Coming soon…
Download White Paper
DriveNets Total Cost of Ownership