IronView Network Manager: Foundry SNMP Management Platform

01 /What IronView Network Manager was

IronView Network Manager, usually shortened to INM, was the element management application Foundry sold alongside its switches and routers through the 2000s. It was a Java application with a server component and a client, installed on a Windows or Solaris server and later on Linux. The product discovered Foundry devices by SNMP, drew them on a topology map, presented their status, and gave a single console for configuration and monitoring tasks that otherwise meant logging into each device. Foundry marketed it under the network management sections of the old site. It was an element manager: it managed Foundry devices well and other vendors barely.

02 /What it did

• Discovery and topology. Given seed addresses and community strings, INM walked SNMP tables, identified Foundry models by sysObjectID and drew links from Foundry Discovery Protocol and bridge tables.
• Device views. Front panel renderings with port state, module inventory, power and fan status, pulled from the Foundry enterprise MIBs.
• Configuration. Scheduled backup of running and startup configurations, side by side comparison, and deployment of a configuration or a software image to one device or a group.
• Fault management. A trap and syslog receiver with filtering, severity mapping and forwarding to an upstream manager.
• Traffic. An sFlow collector that took samples from JetCore and later hardware and reported top talkers, protocols and conversations per interface; see sFlow.

03 /The earlier per-product managers

Before INM consolidated management, Foundry documentation described separate tools: a web management interface built into each device, per-family management applications for ServerIron and for the switching lines, and an installation guide filed under the name FEManager in the network management section of the documentation tree, whose exact scope is not clear from surviving captures. INM absorbed these functions over successive releases. The built-in web interface stayed on the devices and is the one piece of that generation a second-hand unit still carries; it should be disabled for the reasons given in the advisories archive.

04 /What it did well and where it stopped

INM was good at what SNMP element managers were good at: inventory, port state, configuration archive, and a picture of a Foundry-only network. It stopped where every element manager of the period stopped. It was single-vendor, so a mixed network still needed a general manager above it. It scaled to hundreds of devices, not tens of thousands. The Java client was heavy, the server needed its own care and licensing, and reporting was fixed rather than queryable. Alerting relied on traps, so a device that died silently was noticed only at the next poll. None of this is specific to Foundry; it describes the whole class.

05 /What happened to it after 2008

After the Brocade acquisition the INM functions were reportedly folded into Brocade management tooling, and the IronView name faded from price lists within a few years. No successor vendor distributes INM today. Installers for the last releases exist in private archives, but they depend on Java runtimes and operating systems of their period and offer nothing a current generic toolset lacks.

06 /Managing legacy IronWare gear today

A second-hand Foundry switch is an SNMP agent, an sFlow agent, a syslog source and an SSH endpoint. Every function INM provided maps to a generic tool that speaks those protocols.

The SNMP MIBs page lists the standard and Foundry MIB objects worth polling, and the network monitoring hub covers sFlow and port mirroring for deeper inspection. Restrict SNMP and SSH to the poller and the backup host by access list; the CLI reference has the shape.