As switched networks become the norm, the problems with keeping track of what's going on in the network become more numerous and more significant. The days are gone when you could plug a packet analyser into any port on the LAN and see every packet that was going anywhere. Unsurprisingly, given that the whole point of a switched network is to restrict the movement of packets to only those segments that need to see them.
We therefore have to try reasonably hard if we want to monitor the traffic flows down our pieces of wire. We can achieve our goal in a number of ways, though.
The first problem we're faced with is how to monitor the traffic flying down a particular segment. If we think there's a problem on one of our inter-switch links, for instance, we can't just plug a sniffer into a port on the hub that holds the uplink – we need to see what's coming out of the uplink's specific port. The simplest way to achieve this is to physically tap into the uplink cable itself – generally by disconnecting it and reconnecting through a piggy-back connector into which we can plug a second patch cord that leads to the network analyser. The downside here, of course, is that whenever we want to monitor anything, we have to disconnect and reconnect the connection we wish to monitor – which may cause interruptions to the users and may also cause the problem to vanish without trace.
The manufacturers of most mid-range and high-end switches help us out in this respect by providing "port mirroring" facilities in their switches. By changing a setting on the switch's management module, it can be made to mirror the traffic appearing on a specified port onto a second specified port. So if port 24 is spare and you want to monitor the traffic flying in and out of port 13, you tell it to mirror port 13 onto port 24 and then plug your analyser into the latter. It's a much more elegant way to proceed than physical taps, as there's no interruption to service and no need to go ferreting around a mess of patch cords in the hope of finding the right one to unplug.
SNMP and RMON
The above ideas cover the reactive monitoring side of life – how to apply a packet analyser once you know there's a problem of some sort. But what about day-to-day monitoring of traffic levels, packet types, duff packets and such like, with the goal of spotting trends and reacting before problems become severe? This is where our prehistoric (but still useful) network management protocols, SNMP and RMON, come in.
SNMP and RMON can work in this way in multi-segment switched networks simply because their data transfers are based on layer 3 (IP) and not layer 2. So traffic is routed across the network just like any other IP traffic, without being restricted by the layer 2 switching regime.
If the switches in your network have management and statistics capabilities, they will sit and collect statistics as the traffic flows around the network. All you have to do is capture this data over the network at some central location and you're sorted. You run up an SNMP-based network monitoring package, give it the addresses of your switches, and let it collect data and alerts; depending on the capacilities of your chosen package it may even represent the network graphically, but even a basic tabular representation is useful. If you have a large number of network segments, or you have multiple sites that you want to monitor centrally, consider placing one or more Remote Monitoring (RMON) probes at each site. Each probe will collate the data via SNMP from a number of switches local to it and will pass the summary data back over the WAN (again via SNMP) to the central console. The gain with using RMON probes is that because they're collecting and aggregating data, you're passing less data over the WAN than would be the case if the console was talking SNMP to every individual device.
The modest additional cost of buying the SNMP-capable versions of devices is well worth it in the long run. By adopting hardware with port mirroring facilities, we have a means to connect a packet sniffer quickly and easily should we wish to delve deeper into what's happening on a segment. So even in a heavily segmented switched network, then, we don't have to resign ourselves to not being able to monitor the low-level traffic or apply packet analysers.