In a typical (non-promiscuous) capture, you are only seeing communications from the perspective of the host on which capture software is running and no further. Furthermore, this capture is representative of the hosts network stack only, and does not account for anything the NIC hardware may be doing, let alone any network media or devices along the transit path. When enabled, port mirroring ‘extends’ your, adding perspective by peering onto the stack of the switch itself to see what it sees. Many times this may shed light on issues not readily identifiable by a simple host capture. Issues such as faulty or misconfigured hardware are more easily identified.
Port–mirroring works by, well, ‘mirroring’ a port on the switch, replicating all the traffic it sees to another port or VLAN where the host running the capture software can see it. In the following illustration, Node A’s switch-port is mirrored. All traffic that traverses this port is copied to Node D’s switch-port, allowing capture from the connected host using Microsoft Message Analyzer.
NOTE: Though there is a modicum of consistency, the steps to configure a port-mirror can vary from vendor to vendor. Consult your hardware documentation for steps to set up a port mirror. Also note that port mirroring requires that the switch be a ‘managed’ device, meaning its firmware supports this capabilities among others.
In his article, Gopal outlines the steps needed to take the scenario one step further and direct the traffic for capture on a Hyper-V virtual machines running on Node D. Very useful if you have a scenario where it is undesirable to run the capture software on the Hyper-V Host itself.
Call to Action
Give these steps a try. Build familiarity with these steps even if you don’t have an immediate scenario where this type of troubleshooting would be beneficial. Use your newfound knowledge to amaze your friends, colleagues and customers.