We mentioned a central monitoring service a moment ago; this is the InSight server application, which is the central repository for the switches and controllers to send their event information to as well as being the unit that controls the configuration of the various distributed kit. The official hardware requirement for the InSight server is a twin 2.8GHz CPU with 2GB RAM, simply because there could be sizeable quantities of logging information arriving from around the network. In fact InSight is currently available in appliance form, but the aim is to drop the appliance from the range and simply offer it as a software-only package.
To manage the InSight server you run the InSight client, which is a Java applet that will be happy on any Windows desktop (and which you can download from the server). It’s a very friendly GUI-based system with the usual two-pane display, which has very sensible drill-down features that let you start at the system overview and click down into items to find out more. Setting up policies and roles is all done via a very simple GUI, and there’s a graphical dashboard that shows you the current state of play on the network with regard to policy infringements and such like, in addition to who’s connected, what role they’ve been allocated to, when they connected, and so on. When you change the policy settings you can deploy the policy to devices either individually or en masse; you can use the same deployment screens to send out firmware or bootloader updates, to (each device can have a primary and secondary firmware/bootloader set, so you can roll back an upgrade pretty easily). As you’d expect there’s a reporting section (which has built-in reports and also lets you grow your own), and you have the obligatory database backup/restore functionality. The database is actually MySQL; if you want to dig in the raw data with your own favourite query tool, ConSentry will happily let you have the schema so you know where to look.
Although most of the system’s features are managed via InSight, a few aren’t. Two are trivial: to turn on the EPV and “captive portal” features on requires a little bit of typing on the devices’ CLI interfaces, though this doesn’t matter particularly because you’re only ever likely to do it once and then leave it alone. Similarly, setting the initial IP information for the devices is a CLI job, but again it’s a one-off task. The one odd CLI-only task is defining user IDs in the internal database (for EPV authentication); you’d think they would have this in the GUI. In reality, though, you’re most likely to use RADIUS or AD/LDAP for your user database anyway, and not the internal database.
We mentioned earlier that the switch and controller work in a similar way, the only differences being down to the way the devices are built. The switch is designed as an edge device, and is a layer 2/3 VLAN-capable switch, which means that in addition to the protection-related configuration we’ve covered above, you also have some configuration capabilities for the layer 2/3 and VLAN settings. The controller, on the other hand, is designed as a core unit and has four or ten pairs of ports (depending on the model), each with an “in” and an “out”, and as such it simply decides whether or not a packet coming in on one side of the pair should be sent out of the other side – there’s no layer 2/3 stuff or VLAN cleverness in the way. The only other real difference is down to how the operation mode (Passthrough, Monitor or Protect) is applied: on the switch, whichever mode you select applies to the entire switch; on the controller you can specify the mode individually for each pair of ports.
The only slightly weird thing we noted with the ConSentry kit was in the database maintenance screen, where you can choose to purge the database’s contents either on demand or on a schedule. The thing is, though, that “Purge the database every 14 days” doesn’t mean “throw everything away that’s more than 14 days old”; it means “every 14 days, empty the database completely”. Why you’d want to do this is less than clear.
All in all, though, we found the unit very simple to use, and although you have to use the CLI for some configuration tasks, it’s not all that hard (it’s very Cisco-like, actually, so if you’re familiar with their kit you’ll have a head start). The GUI is excellent, it’s very straightforward to define roles and policies (though the graphical representation of the role hierarchy has some gratuitous animation that looks cool but adds nothing!) and the dashboard feature is useful and has a nice drill-down capability.
Controller: CS1000 £12,000; CS2400 £18,000
Tel: 020 7156 5000 x303
Email: [email protected]
It’s quite nice that you get largely the same functionality in the controller and the switch. It means that an SME could buy one or two switches and get up and running without the need for a controller, and a larger business could buy a controller for the core and get going with policies, then add switches later as their edge devices fall off the depreciation process in beancounter central.