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 /What the filings and archived pages confirm about IronView Network Manager

Two kinds of source survive for IronView Network Manager: Foundry's annual reports and captures of the product page. The 10-K for 2001 describes INM as the tool for tracking configuration changes and software updates and for controlling access control lists, VLANs and alarm and event handling, and records two major INM releases that year. The 10-K for 2003 adds an IronPoint edition for wireless access point management.

The product page captured in October 2006 is more specific. It describes INM as fault, configuration, accounting, performance and security management, built on Java, supported on Windows, Linux and Solaris, and organised as web-based application managers: topology, device configuration, access control list, rate limiting, MAC filter, event, change and report managers, plus a ServerIron traffic manager and a SecureIron denial of service manager. Operator actions were logged against the configuration deployed, authentication ran through TACACS+ or RADIUS, and the CLI configuration manager ran scripted command groups with parameter substitution against a device group.

The 2006 page also describes an interface to the open source Snort engine: INM fed it sFlow samples and received attack events back. INM itself did not inspect packets.

07 /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. The IronWare device families it polled are each profiled from the front page of the archive.

08 /How to verify a claim about INM before repeating it

INM is often misdescribed, because no successor kept a page for it. Check a claim in this order: the SEC filings, which are dated and unaltered; a web archive capture of the product page, which gives features but not versions; then archived release notes. A claim found in none of these is a recollection. The method this site uses for keeping vendor manuals honest applies to management software, and the same evidence habits are set out for traffic on the provenance hub.

device# show version
device# show chassis
device# show running-config
device# show configuration
device# show interfaces brief
device# show log

• Pitfall: show configuration is the saved copy and show running-config the live one. INM flagged a difference as unsaved work; a backup script should do the same.
• Pitfall: operator action logging lived in the INM database, so a configuration on a second-hand unit has no recoverable author.