OIT filters SNMP (Simple Network Management Protocol) broadcast traffic on the wireless networks operated by OIT. We do so because such traffic can degrade network service in some situations, and there is no legitimate need for devices to use SNMP broadcast traffic on the campus network.
SNMP (Simple Network Management Protocol) is a network protocol typically used by network management software to query and control network infrastructure components (routers, switches, etc). Some devices that are not network infrastructure components may also support SNMP.
SNMP traffic is normally unicast, not broadcast. The SNMP client (typically network management software) sends SNMP requests to the IP address of a specific SNMP server (typically a piece of network infrastructure); the SNMP server responds to the client. Or a piece of network infrastructure typically sends an SNMP trap (an event report) to the IP address of a specific SNMP trap receiver (typically network management software).
Some vendors have repurposed SNMP to attempt to use it as a discovery protocol. They distribute software which sends SNMP requests to IP broadcast or multicast addresses in an attempt to locate devices listening to SNMP on the same IP network as the client.
SNMP was not intended to be used as a service discovery protocol. There is no need to broadcast SNMP traffic in order to use SNMP for the purpose it was designed to accomplish.
Broadcast-based service discovery protocols generally do not behave well on large networks. Devices using SNMP as a service discovery protocol sometimes send queries every few seconds for hours at a time looking for all devices offering a particular service (for example, devices offering print services). Broadcast traffic must be flooded to all devices on the IP subnet, consuming network bandwidth and requiring processing by all devices on the IP subnet.
Additionally, the SNMP broadcast traffic can trigger ARP broadcast traffic. Those devices that wish to respond to the SNMP broadcast may need to broadcast an ARP request for IP adddress of the SNMP broadcaster. This traffic too must be flooded to all devices on the IP subnet, consuming network bandwidth and requiring processing by all devices on the IP subnet.
The effect of excessive broadcast traffic can contribute to poorer network performance, particularly on wireless networks.
At Princeton University, we typically see SNMP broadcast traffic for extended periods from only selected devices. These typically include:
OIT began filtering SNMP broadcast traffic in December 2010.
IPv4 traffic destined to UDP ports 161 or 162 is discarded by the filter if the traffic is destined to the IPv4 limited broadcast address. On our wireless networks, the filter at the wireless access points also includes the IPv4 subnet-directed broadcast addresses used by the wireless networks.
The traffic is filtered at the campus network's core Ethernet switches; all buildings (or groups of buildings) are attached to these core switches. It's presently installed in such a way as to apply only to those networks supporting wireless services provided by OIT. This causes the filter to apply to traffic (for our wireless networks) as that traffic passes through the campus core on its way from one leg of the network to another. (In some cases, multiple buildings share a single connection to the campus core, so this filter doesn't affect traffic which remains within that group of buildings.)
The filter is also applied at the edge of the wireless services provided by OIT, so it also applies to traffic sent by a wireless client as that traffic arrives at the wireless access point or the wireless controller. This filters the traffic before it would be flooded to other clients (wireless or wired), even if those clients are on the same leg of the network, or behind the same wireless access point.
It is possible that in the future, the filter installed at the network core might be expanded to also include the wired (non-wireless networks).
We do not filter SNMP unicast traffic.