Envoy is a remote management appliance. This basically means that it sits at your various remote sites and connects into the various network devices that make up the infrastructure at each, and you connect to it from afar via out-of-band WAN connections (ie modem, ISDN or other links that don’t form part of your production network) – the point being that even when your world’s stopped sending the ones and zeroes in the right directions, you have a mechanism to get in and manage/fix the infrastructure devices.
The box we reviewed was a 1U appliance with ten ports on the front panel: four serial and four Ethernet ports for connecting to the management capabilities of the infrastructure kit; a serial port for a management connection; and an Ethernet console port. There’s also the obligatory small LCD display and a set of six buttons that allow you to do the "unplugged" basics of setting the IP address and restarting/stopping/factory-defaulting the box. The LCD panel also shows some basic monitoring information about its surroundings (notably humidity and temperature) – and of course this info is also available remotely. Of the various ports on the back, the two important ones are the modem (dial-up is often the connection of last resort if your WAN or VPN has gone screwy) and a port for connecting a power controller (the Envoy supports APC, BayTech and ServerTech manageable power bars for forcibly power-cycling your kit). The ports are hosted on module cards, of which you can have up to two per chassis, and so you can have between four and 32 ports.
The test network we looked at pretended to be a two-site organisation. So we had a pair of Cisco routers providing a simulated WAN connection, with a Cisco switch and an Envoy on each "site". The console (serial) ports of the router and switch were linked into serial ports on their local Envoy, and at one of the sites was an Intel-based server running EMS – the Envoy Management Station which acts as a central control point for the distributed Envoy appliances.
Management of the EMS is browser-based (though if you wish you can use a command-line interface on the individual Envoy appliances), and has the traditional two-pane display with the network overview in a narrow left-hand bar and the detail in the main pane on the right. The left-hand pane is a hierarchy organised by site; within each site you can drill into the list of Envoys you have at that site. Clicking on a site gives you an overview menu that allows you to view alarm, change log and login records for that site, and to configure settings such as default port configurations and access privileges. Selecting an Envoy’s icon gives you detailed access to that Envoy – so there’s more statistical stuff (for both the Envoy and the devices it’s managing) and access control, plus the meat of what the device is for – the various features for managing the network devices the Envoy is connected to.
Before we talk about the features, a quick gripe about the GUI. In many ways it’s excellent: it’s clean and uncluttered, and full of sensible features (splitting reports into hourly/daily/weekly/monthly and allowing on-screen, CSV or PDF viewing, for instance). It’s also very helpful to beginners – so when I couldn’t figure out why it wasn’t letting me define a scheduled task, I noticed that hovering the cursor over the "Schedule Task” button gave me a pop-up reminding me that you have to define a filter first. The downside is that it could do with a bit of dynamic HTML – for instance, you have to scroll the main page down to select a managed device, but when you select one it does an HTTP postback and you jump back up at the top of the screen again. It’s nothing that a decent GUI person couldn’t fix in a relatively short time, though, and it’s not a huge issue.
First up is rules and rulesets. These are, basically, IF … THEN checks and actions that you can use to alert you of problems and/or take action when they happen. There’s a wad of built-in rules that cover all the usual bases (interface up/down events, prolonged high CPU usage, and so on) or you can define your own – though a little bit of knowledge of the internal management variables of your particular kit will be required for home-grown ones. If the conditions of a rule are met, the resulting action can be anything from doing nothing or sending an email up to issuing a reboot command, uploading a configuration file to the device, or doing a hard power cycle (assuming, of course, you have a manageable power strip attached). As the names imply, you can collect rules into rulesets to make allocation of rules to devices a bit more manageable.
Next is scheduled tasks – a self-explanatory concept. To create a scheduled task, you first need to create a filter. This is basically a set of criteria that describe the devices to which you can then apply a task. So you might choose all routers of a particular make and model, or all switches at a particular site; they’re easy to define in the GUI and there’s a "preview" option that shows you what devices match that filter, just so you can double-check you’ve done it right. Once you have a filter you can define a scheduled task (either a one-off or executing at given times) for machines that match that filter; the list of things you’re allowed to do is built based on the filter criteria, so it won’t let you do something impossible. Incidentally, the EMS includes a “file archive”, into which you can drop things like config files or firmware upgrades – which allows you to do things like scheduling the automatic overnight upload of new config parameters to the routers and switches in your world.
Finally we have SLVs – Service Level Verification tasks – which are an optional add-on. These are rather like scheduled tasks except that they have to be defined on a per-Envoy basis – everything else can be defined globally and propagated over the entire network or a specified lump of it. An SLV allows you to make an HTTP, VoIP or TCP connection to a specified place and verify its performance, with a view to reporting back on service level compliance (or lack thereof) of the underlying infrastructure. It’s a nice touch that the stats you get back aren’t just the total time taken – for the HTTP connection, for instance, it reports the time taken to connect, and the time taken until the first and last bytes of the response were received, and the VoIP check similarly reports back a load of individual parameter measurements.
As I’ve mentioned already, you can manage the Envoy via a command line if you so desire – though the EMS makes life so much easier for verbose activities like defining rules. If your network is up and happy you can use SSH to connect in-band, directly over the WAN; if not, the EMS will act as a pass-through so you can use the CLI via the out-of-band management network. And of course, once you’ve connected to the Envoy’s command line, you simply issue a "port X/Y" command (eg "port 1/1" for the Cisco 1700 on one of our test Envoys) and the command line switches to the console of the device on that port.
So would you use Envoy instead of, say, a traditional RS-232 console server that hooks into the console ports of your devices? Yes, you probably would – what you gain is the ability to apply changes to collections of distributed devices very easily, and apparently minor functions like the file repository and the in-built power strip integration combine with the more major stuff like rules and actions to give you far more than you’d get with a basic console server. And the good points vastly overrule the GUI niggles I’ve mentioned – and anyway, with any luck Uplogix will listen to us and fix these in the next revision.
If I were buying the Envoy, I’d get the EMS as well – doing things graphically is nicer than remembering CLI incantations.