OIT Network Switching and Routing

OIT Filters Most IPv4 Broadcast and Multicast Traffic on Wireless Networks

OIT filters most IPv4 broadcast and multicast traffic on the wireless networks operated by OIT. We do so because such traffic contributes to degraded wireless network service, while being unnecessary for the wireless network functionality OIT supports.

The filters described were installed during March 2012 - July 2012, replacing a number of more-specific filters previously installed.

Why does OIT filter most IPv4 broadcast and multicast traffic on the wireless networks?

As the number of devices on the wireless networks has grown, the volume of broadcast and multicast traffic from those devices has grown. Such traffic has grown also as applications and operating systems make increasing use of broadcast and multicast to announce services they wish to offer to the "local" network, and to try to discover such services offered by other devices on the "local" network.

Broadcast and multicast traffic are vital parts of the network; their existance is not inherently bad. However, as the volume of broadcast and multicast traffic grows, network service can degrade. Wireless networks are especially sensitive to the effect of broadcast and multicast traffic. Experience has taught us that if we do not block most broadcast or multicast traffic on our wireless networks, these large networks degrade, sometimes to the point where they become unusable.

Our wireless networks are intended for use only by clients, not servers. These networks are not suitable places to attach devices acting as servers. Given that, there should be no need for applications and operating systems to discover other devices on the local network acting as servers, or to advertise that they are acting as servers.

Prior to March 2012, OIT filtered selected IPv4 broadcast and multicast traffic on the wireless networks. We focused on those protocols which were not needed to provide the services we support on our wireless networks, yet were responsible for most of the broadcast and multicast traffic. Each time we discovered another protocol which met these criteria, we implemented a new filter for that protocol. As applications and operating systems continued to expand their use of such protocols, it was necessary for us to grow these filters repeatedly. During March 2012 - July 2012, we changed our approach to instead filter all IPv4 broadcast and multicast traffic by default on our wireless networks, only permitting those few protocols which are necessary for the supported operation of our wireless networks.

What is filtered, and where is it filtered?

IPv4 datagrams are filtered if they are destined to any of the following IPv4 addresses:

224.0.0.0/4
This is the multicast network range.

255.255.255.255
This is the limited broadcast address.

10.8.0.0
This is the 0's style subnet-directed broadcast address for vapornet100.

10.8.255.255
This is an incorrect 1's style subnet-directed broadcast address for vapornet100 some clients may erroneously use.

10.9.0.0
This is an incorrect 0's style subnet-directed broadcast address for vapornet100 some clients may erroneously use.

10.9.255.255
This is the 1's style subnet-directed broadcast address for vapornet100.

10.24.0.0
This is the 0's style subnet-directed broadcast address for visitornet101.

10.24.255.255
This is an incorrect 0's style subnet-directed broadcast address for visitornet101 some clients may erroneously use.

10.25.0.0
This is an incorrect 0's style subnet-directed broadcast address for visitornet101 some clients may erroneously use.

10.25.255.255
This is the 1's style subnet-directed broadcast address for visitornet101.

169.254.0.0
This is the 0's style subnet-directed broadcast address for the link-local network.

169.254.255.255
This is the 1's style subnet-directed broadcast address for the link-local network.

Several exceptions to these filters are enumerated below.

The filters are applied at the edge of the wireless services provided by OIT. They 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, even if those clients are on the same leg of the network, or are attached via the same wireless access point.

The traffic is also filtered at the campus network's core Ethernet switches; all buildings (or groups of buildings) are attached to these core switches. These filters are installed in such a way as to apply only to those networks supporting wireless services provided by OIT. This causes the filters 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.)

What are the exceptions?

Several kinds of IPv4 broadcast and multicast traffic are excepted from these filters:


A service of OIT Network Switching and Routing
The Office of Information Technology,
Princeton University
Last updated: July 15 2016