Failing to monitor all points on the network can lead to costly outages or increase the time to resolution -- resulting in revenue losses as well as customer dissatisfaction.
In response, enterprises are investing in farms of monitoring and analysis tools such as analysers, sniffers, archiving systems and intrusion-detection systems (IDS). To most enterprises, these tools are not an option, but a requirement to maintain a healthy network and meet security and compliance regulations. However they also represent a significant capital investment.
While it is cost prohibitive to put these devices at every network monitoring point, it is equally unwise to have them sit idle until needed. The ideal solution is to deploy devices in a way that allows them to be shared to maximize coverage and utilization. With the adoption of matrix switching technology, efficient device sharing is becoming more common. However, effectively managing this infrastructure from a single, centralised point has remained a challenge.
At its most basic, network monitoring requires the ability to connect a SPAN, Tap or mirror port to an analysis or security device for the purpose of diagnosing network issues. The matrix switch has become a key way to efficiently monitor tool farms -- with all devices wired to the matrix switch and then connections from there made electronically via software.
This did away with the conventional (and expensive) approach of sending someone to the datacentre to manually patch and re-patch connections between devices. Yet even the electronic patching could be time-consuming, requiring logging into each switch to complete the end-to-end connection. In a complex network featuring an expanded switch matrix, you might need to log into four, five or six screens to manage connectivity.
Now, however, software is available that offers seamless, end-to-end connectivity between devices from a single screen in about six mouse clicks. This "device-centric" software enables you to focus on the devices you want to reach while the tool works behind the scenes to manage all of the port-to-port, inter-device connectivity.
So what might a device-centric interface look like? Look for tools that on one screen list data sources (SPANs, Taps, mirror ports) and destination devices (analyzers and IDSs) and make it possible to select a source and destination with two clicks (more if the user wants to multicast to additional destinations). The tool should also let you apply a rate, add a job code or message if desired, and click to make the connection.
Such centralised tools should also offer a dashboard screen that lists all current monitoring sessions. That capability can be especially productive because it provides a snapshot of the source and destination of each monitoring session, as well as the device location, start time and schedule, job ticket, user name, link status and any optional user messaging applied. Up until now, it was difficult if not impossible to obtain a single, cogent view of all this information.
It's also helpful to be able to customize the view to see only the critical connection information. Options include the ability to hide other users' monitoring sessions and any monitoring sessions that are scheduled to begin later. If you need more detailed information about the port-to-port connections or the device settings, they should be easy to obtain, typically by clicking on the desired source or destination.
Additionally, you should be able to end monitoring sessions with a simple mouse click. Arguably, one could have had access to such functionality in the past, but probably not without a fair amount of custom programming.
Given the growing number and complexity of enterprise networks, a monitoring program should make it possible to customise the flow of information coming from a SPAN or mirror port, and indeed that is the case today. Specifically, a user with permissions can build and store an unlimited number of device configurations -- applying the chosen configuration at the time the monitoring session begins.
The process -- which has been made very simple -- is described as follows. If the user has access to a Cisco Catalyst 6509, he would, for example, be able to create a configuration called "NewYork_segments4-8" that funnels the desired virtual LAN or port-based traffic out of the switch's SPAN port. When connecting that SPAN port to a protocol analyzer, he would be able to apply the saved "NewYork_segments4-8" configuration to the monitoring session when it goes live -- whether that is immediately or at a time in the future.
When a monitoring session is complete, a user can manually disconnect the session or it can be set to automatically disconnect at the end of the scheduled timeframe. Upon disconnection, the system resets any data source with a saved "default" back to the original configuration.
Reserving devices and resolving schedule conflicts
Users invariably have immediate network issues to diagnose, so it's productive to have a technology that -- by default -- can create monitoring sessions that begin immediately and remain up until the user manually disconnects. In cases where a future connection is desired, however, your tool should allow you to book a reservation.
If the devices are already scheduled for use during the desired timeframe, the user should be able to ask the system to find the next available time or choose a different time/date. It may also be possible to view this information on a calendar-style screen. Both active and pending monitoring sessions might be displayed on a per device basis.
Many enterprises have had no easy means of determining -- at any point in time -- how many monitoring devices they have, and where and how they are being used. This "blind spotC" can lead to uninformed decisions with potentially significant financial ramifications.
Now, there are reporting capabilities that make it possible to review the use of every device in a data center's inventory and understand where, when and by whom it is being utilized. With such information, network managers can review:
* The number and duration of all monitoring sessions from a particular timeframe.
* The usage of all or specific devices.
* The quantity and location all devices in inventory.
This is key to understanding whether there are too few tools of a particular kind, or if tools are available and can be better utilized elsewhere.
By design, centralised management software should be Web-based, assuring availability to multiple users and eliminating security concerns about installing third-party software. Such an approach provides for easy access, where a user simply opens a standard browser and inputs the correct IP address.
And because the software must integrate into an environment with a multitude of other tools and systems, the tool should be able to accmmodate other fields, such as:
* Job ticket: Nearly all enterprise networks use an electronic job ticketing system for tracking network issues, so a field referencing the job ticket or job code is valuable.
* Location: Many enterprise networks have devices in more than one physical location. The tool should be able to display this information with the monitoring session detail.
* Message: To alert other system users to the purpose for individual monitoring sessions, it's useful to have an optional message field for users to fill out.
Lastly, an enterprise-class platform should boast a robust set of security features designed for maintaining maximum system uptime. Those would include:
* Support for centralized authentication mechanisms such as RADIUS and TACACS+.
* Comprehensive logging of all configuration change and security events/
* User-settable security levels that allow an administrator to enable or deny access to specific features on a per user or per user-group basis. For example, an admin could restrict access for users to edit or delete monitoring sessions, edit device configurations and make edits to the device calendar, just to name a few.
In conclusion, a centralized monitoring solution should provide ready access to all of the corporation's analysis tools on a one-to-one basis. It should simplify end-to-end device connections, provide a clear picture of monitoring sessions, allow sessions to be scheduled to accommodate tool usage and availability, and provide a comprehensive reporting capability that enhances investment decision-making.
Kcehowski is responsible for APCON's business strategy for the East Coast.