Back in the Day

Console Cables Are Life

Back in the Day Console Cables Are Life

Are you a network engineer?

Are you a network engineer?

Open your desk drawer, take out the beautiful light blue cable, and give it a hug and kiss. That cable has inevitably been your friend (and sometimes foe) for your entire career, right? RS-232 Console cables have been a staple of routing and switching for what seems like millennia.

Think about it, the initial method of programming network devices has been 9600 baud until the past few years and now clocks in at a whopping 38kbps. How many times have you tried pasting a block of config text only to see the console reject one command or typo and everything fails from that point. Inevitably a small number of devices are deployed with broken configs due to this broken process.

The point of this mini-blog series is to compare how we did things back in the day, and how we do things now. We’re not suggesting you should throw your console cables in the trash, we still need one for the odd troubleshooting scenarios or lab configurations.

Console cables are really not used very often anymore, due to the advent of these cool features:

Zero Touch Provisioning (ZTP)

You should be able to take a device out of the cardboard box and connect the management port to your OOB network and get an IP address via DHCP.  Ping monitoring of mgmt ports on the OOB network, as well as a way to view the DHCP scope assignments help you figure out what address was assigned so you can SSH in to the new device for configuration.

Open Network Install Environment (ONIE) 

By adding a value to the DHCP server response, a device is instructed where to get a copy of its NOS image for the first boot. This file is served via HTTP.
ZTP Script
The DHCP response can also specify a script that the new device should run. This can include installing trusted keys and secrets.

Root of Trust

By default, a new switch is going to trust instructions in the DHCP ZTP script, so when connecting the management port to your OOB network, you need to immediately lock down the device so no 3rd party instructions or malicious code can be installed. This process is known as the Trusted Boot Chain. The design and configuration of the chain is specific to your business needs and outside the scope of this document. Additional security mechanism can include air-gap trusted boot with a USB key, or trusted/secure boot hardware in the device itself.

Sounds complex!  Not with Verity.

If you were to start from scratch you’d need to configure 3-5 different microservices and deploy it on a small server connected to the ethernet management network. Sounds fun for a home lab where you want to learn each component, but in reality it makes sense to have a tool that does all of this and more, right? Verity is a unified platform for operating networks, from data center and campus, to packet brokers and the management network.

That’s right, Verity has integrated management network configuration. Simply deploy the Verity system on a server, plug it into the management network, and you’re good to go. Verity will configure the management switch, set up a DHCP server, handle the ONIE/ZTP instructions as well as installation of any security keys, certificates or custom software. Verity can selectively install new versions of SONiC on any vendor device and give you custom control over what firmware/boot files to install on each platform. Devices under Verity management immediately appear in the Verity UI with all of their telemetry and can be configured for network roles in seconds. Configurations are guaranteed to be correct, no more typos, no more console buffer overflows.

en_US
Contact Us
We really like talking about networks!