Multivendor networks exist everywhere — especially when one considers that networks consist of more than switches, routers and firewalls.
Servers, backup systems and a seemingly endless list of other elements all have their role in — and view of — the network. This means that prudent network designers should care more than ever about the extent of multivendor or heterogeneous support, and that it is actually part of the solutions they are considering.
Synonyms for disingenuous include insincere and false, so maybe such words are a bit strong, but experience shows there is much more to heterogeneous support than can be indicated by a vendor’s check-box indicating “yes” in the product profile. The absence of an industry-wide definition of multivendor support allows vendors to claim they offer such support even when that support is trifling.
This means the burden falls on users to define, and validate, heterogeneous support up to the level they require. And, while network managers are probably not looking for new things to fill their days, nothing short of detailed definitions of features and functions supported is of value.
In the past, network managers were often most concerned about heterogeneous support when it came to deploying a switched infrastructure with, say, one vendor’s switches at the core and another at the edge. It was important that QoS bits were recognised consistently and that performance enhancers such as link aggregators could work between switches from different vendors.
A Darwinian marketplace saw to it that functions were up to required levels. Switch-vendors that couldn’t work as required were soon put out of the picture.
Today, though, there are a lot more subtle and complex aspects to heterogeneous networks. This means any failure that doesn’t result in a switch crash and is more difficult to uncover.
Solutions such as Cisco’s Security Monitoring, Analysis and Reporting system ingest log and event data, and, applying advanced analysis techniques, inform network managers of problems or weaknesses that might otherwise go undetected.
Such systems have to read and understand the arcane event-descriptions that are generated in the logs of firewalls, intrusion-prevention systems, servers and so forth. This is a non-trivial task because there are so many devices to deal with, and they are always evolving and adding new events.
Heterogeneous support means not only being able to input this event-data, without crashing the network, but also includes the frequency with which analysis systems are updated so they can understand the many events that a given firewall might generate.
There is little point in an analysis system that spits out “event unrecognised” or “event undefined’ messages for months on end until it is finally updated so it can understand the new data. If the system can’t understand the data then it can’t analyse it — that much is certain.
So, be sure to get vendors to commit in writing to a policy of staying current with respect to all the event information being generated by all the heterogeneous devices they claim they can support. If you don’t, or they won’t, you could find that your self-defending network can’t protect itself very well.