FOUNDRYNETNo. 001SEPTEMBER 2026SECTION 04MONITORING
Network Monitoring Guide
Three guides on seeing what the network is doing: statistical traffic visibility with sFlow, counters and traps with SNMP, and full packet capture through a mirror port. The section inherits the sFlow technology page, the MIB reference and the monitoring chapter of the enterprise configuration guide.
04 /Contents
- 01sFlow: Packet Sampling and Counter Polling for Switch MonitoringGuide
sFlow is a sampling-based monitoring standard built into switch hardware: one packet header in every N plus periodic interface counters, from which a collector reconstructs who talks to whom.
- 02SNMP MIBs: OIDs, MIB-II Objects and Enterprise TreesGuide
A MIB is the schema that tells a poller what a device can report and where each value lives in the OID tree. SNMP is the protocol that fetches it.
- 03Port Mirroring: How to Configure a SPAN Port and Capture TrafficHow-to
Port mirroring copies the frames passing through one switch port to another port where a capture host listens. It is the fastest way to see real traffic, and the easiest way to lose half of it.
04.1 /Orientation
There are three ways to know what a switch is doing, and they answer different questions. SNMP polls counters and receives traps: how many octets crossed an interface, is the power supply healthy, did a link flap. sFlow samples packets and exports headers: who is talking to whom, which protocols dominate, where a flood is coming from. Port mirroring copies every frame on a port to an analyser: what exactly was in the conversation. A monitoring design uses all three and knows which one to reach for when the phone rings.
sFlow covers the sampling model defined in RFC 3176, the arithmetic that turns a one-in-N sample into a traffic estimate with a known error, the agent-to-collector datagram, and a comparison with NetFlow and IPFIX. SNMP MIBs walks the OID tree from the standard interface table to a vendor enterprise branch, explains 32-bit counter wrap, and covers why version 3 is the only version that should touch a management network. Port mirroring is a procedure: choose direction, respect the oversubscription limit, configure the mirror and monitor ports, verify with a capture, and know when a TAP is the better tool.
Foundry was among the earliest switch vendors to implement sFlow in hardware, and its /technology/sflow/ page was cited widely as an explanation of the method. Its enterprise MIB lives under the private enterprise number 1991, which is the branch any poller needs when it inventories a legacy IronWare device. The IronView Network Manager, Foundry's management application, is profiled in the archive; the guides here explain the protocols it used and how the same job is done today with any collector and poller.
The monitoring chapter of the enterprise configuration and management guide, which covered port mirroring, was one of the most linked documentation pages on the old site because it answered a question every administrator eventually asks: how do I see this traffic? That question and its modern answer are the spine of the section. The recovered documents in the margin are that chapter, the MIB reference PDF and the sFlow technology page.
Monitoring also has security consequences that the original documents did not dwell on. A community string on an internet-facing interface, an sFlow collector on an untrusted segment or a mirror port left enabled after a capture are each a data leak. Every guide here says where the protocol should be allowed to travel and where it should be blocked.