Q: Best Practices to implement single large subnet flat network
A: Controllers and tunneled APs make it possible to easily scale to a /18 or /16, in principle. Address management, broadcast, and multicast issues are essentially self-contained and intentionally managed in our environments.
Fundamentally, the potential problems in this size network are created by unknown unicast flooding, broadcasts, multicasts, and DHCP server scaling.
- Unknown Unicast Flooding by disabling flooding on the network switches.
- Broadcast in the network comes from primary sources with DHCP and ARP.
- Multicasts are a challenging issue and needs to be need to relatively carefully control network capacity, segregate traffic on multiple VLANs, and enable per-VLAN IGMP snooping
- Large DHCP scope sizes create scalability and latency challenges, especially on renewals and NAKs. Reducing the size of outstanding scopes can be managed by reducing the lease timer, but this can be very problematic in high-availability traditional active-active DHCP server models so needs to be careful in setting up the lease timer/config.
1. Source address table size – should be large enough to not inadvertently purge connected clients
2. Source address aging timer – minimizing this value to the smallest possible is useful to eliminate traffic for inactive client, but CPU constraints and multi-card replication has to be considered.
Many chassis-based switches have slow cross-card replication of SAT and sync is important.
3. DHCP lease timer – should be smaller than ARP timer and as closely aligned to average associated client duration for efficient address usage, but cognizant of DHCP HA replication intervals to prevent un-synchronization of pools from short total lease timers.
4. ARP timer – must be longer than DHCP lease timer to prevent the need for downstream client ARP.
5. ARP table size – should be large enough to not rotate during the DHCP lease timer duration for the sum total of associated clients over the valid period.
If you follow practices like this, theoretically, there is no scaling restriction to the network. For every additional requirement that you place on the network, like static IP hosts, lots of valid multicast traffic, etc, you start adding more constraints to scale. At a high level, our controller based networks with tunneling from the APs automatically manage all of these problems, and eliminate scaling challenges, so a /16 is perfectly reasonable scale.
Controller features to enable:
“Broadcast Filter ALL” on each VAP
You would only need “Broadcast Filter ALL” on each VAP under the SSID profile, is all.
Broadcast filter ARP is on by default. If you are going to have multicast apps, you will need DMO enabled.
We will enable traffic management later, when we can measure its effectiveness.
Configure terminal
Wlan virtual-ap <profile-name.
broadcast-filter all
broadcast-fitler arp
Configure terminal
Interface vlan <id>
bc-mc optimization
Write memory
BCMC optimization on VLAN is the config individual to the controllers so we may need to enable this config individually on all the controllers. Enable air-group addition to this in case of MDNS service required.
Note: Please make sure we discuss with TAC and Aruba Sales team for any clarity or for better implementation on the production network