Have you ever enabled frame relay traffic shaping on a router interface? Unless you are someone that has done a lot of frame relay configuration in the past or someone that studied heavily for the CCIE prior to version 5 you probably haven’t. Which means you would have to look up the command online to learn all about what it does.
What you might overlook when you’re checking things out is a little quirk in the command that you have to override almost instantly. When you enable the command frame-relay traffic-shaping on an interface it immediately sets all the bandwidth settings for the interfaces to 56k. I’m sure this is because a long time ago when most of the leased lines were ISDN BRI links, 56k was the default setting. And because the default setting worked so well for so many people for so long, it just stayed that way. Even when interfaces got faster the default never really got updated. We all just made mental notes to go in and reset the interface bandwidth for each link to make sure we didn’t cause ourselves more grief than we needed to. Soon enough, the quirky behavior of the command was relegated to the trivia dustbin for CCIE candidates and random factoids in routing books.
Legacy Latency
The quirky behavior of ages-old commands in your operating system has a bigger impact on your design than you may know. Carrying forward that technical debt to systems that have more modern features means that you have to be careful about how you configure everything. For example, in traditional Cisco IOS and IOS-XE, interfaces are named with their speed settings. You can have Ethernet, FastEthernet, GigabitEthernet, TenGigabitEthernet, and so on. However, on the NX-OS platforms there is only an Ethernet interface no matter how fast it is. And Nexus Systems never really dealt with the old 10Mbps or really event 100Mbps FastEthernet interfaces. So, to them, it’s always been gigabit or better.
But these quirks take away from your ability to distribute configurations or standardize on things. What happens if the operating system on your edge device has a different syntax than the one in your core? What about if your configuration triggers a hidden command or something totally incompatible with your platform? You’re in for a world of trouble. And the longer your platform carries forward these archaic commands the more likely you are to create problems.
What should happen then? Should you stop creating new modules for your venerable operating systems? Should you just stop development and build something new? The quandary is difficult for companies that have a vested interest in the way they build their software. The value in keeping things consistent often outweighs the value of creating something new and fresh.
This is where startups can leap in and create some real, lasting value. Companies that don’t have to build things on the back of existing legacy software can really start to innovate. For example, who even uses serial interfaces anymore? Why program ways to deal with them into your OS if your software may never encounter one in the real world? It would be much better to focus your efforts and development on things like stability and scalability instead of figuring out how to handle the inputs for a DS3 module.
Driving Innovation
Enter DriveNets. They’re a company that knows what needs to happen to build a modern, disaggregated routing platform for cloud and hyperscale environments. The DriveNets Network Operating System (DNOS) is built with modern technology in mind. The control and data planes are independent of each other, which means they can scale across a variety of systems without the need to build bigger boxes to handle one or the other.
This also means they can be truly disaggregated. They accomplish this like any good cloud company should: with containers. DNOS is built with containerized microservices. This means it can scale as big as you want as quickly as you can fire up new container instances. It also means that the system is completely stable and reliable. If one of those services dies or needs to be restarted it doesn’t affect the whole system. Anyone that has ever lost a device because of an errant software crash knows how problematic that can be.
And to add on to that, the separation of control and data planes means that DNOS can keep forwarding even if there is a need to switch control planes on the backend. When could that be necessary? Oh, I don’t know…maybe when BGP needs to keep packets moving in a service provider? The ability to forward traffic in control plane switchover is only really possible if you have complete separation. All the fancy tricks in the world aren’t going to help you if your control plane causes BGP packets to back up.
Bringing It All Together
The video above is a great overview of DNOS and the philosophy behind why it was built with microservices in mind. It’s also a great way to see how modern network operating systems need to focus on different things now than they have in the past. No more frame relay or FastEthernet interfaces. Instead, we have to worry about sub-second failover of control planes and rock-solid stability for cloud and hyperscale environments. And this is where the innovation is going to happen in the future. It’s not going to be on legacy software. Instead, it’s going to be in the features that customers need today and the development methods they prefer. Leave the legacy software to those that really need it. DriveNets has figured out how to build something that will define the future of better networks.
