- Community Home
- >
- HPE Networking
- >
- Networking
- >
- Best Practices: IP address planning for Wi-Fi
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Receive email notifications
- Printer Friendly Page
- Report Inappropriate Content
Best Practices: IP address planning for Wi-Fi
Early one morning, I came into the office, filled my coffee cup and started looking through the network issues that happened while I slept. Interestingโฆan issue with wireless connectivity for users across our campus. Clients were experiencing high latency connecting to corporate resources, phone calls were failing on softphones, and browsers were timing out trying to connect to the Internet. What caught my eye that morningโand is the reason Iโm writing this articleโwas an email from one of the service desk technicians.
โWeโre troubleshooting this wireless issue, but I canโt seem to find 10.131.64.45 or 10.131.65.200 anywhere in the building. Can you tell me where these subnets are located?โ
These were the two hosts initially reporting the problem and the service desk focused on them. That is fine to help isolate problem domains but not knowing where subnets were assigned wasnโt good. Not only did that mean our documentation was lacking, but it also meant there were some presuppositions that needed to be clarified regarding IP address allocation within the wireless architecture.
Architecture overview
Your address plan should be created in conjunction with your wireless design. Wireless APs within your four-building campus, managed by controllers in your off-campus data center, will have address allocation considerably different from a global environment with controllers in each office. Additionally, forcing all wireless traffic through a tagged VLAN on your centrally located controllers rather than dumping traffic local to the end-user LAN changes the plan and troubleshooting methods.
As I work through an address plan for wireless, I approach it in IP address-to-User ratios based on SSID function and region. Sound odd? Follow me on this.
- Corporate-user SSID: Most corporate users have a laptop, company-issued cell phone and maybe a tablet. Expect that each of those devices will connect to the wireless network simultaneously each consuming an IP address. If there are 400 employees in the campus connecting to that SSID, youโll need at least a 4:1 ratio for coverage. In this example, thatโs 1,600 addresses so you should reserve a /21.
- Vendor SSID: For your vendor guests giving presentations, you can expect each user will have a laptop and a mobile phone (2:1 ratio). How frequently these guests show up to your office is something for you to investigate but plan for an average of one-hour meetings. Add an additional 30 minutes to that time, shorten the DHCP lease to avoid address exhaustion and you can avoid DHCP exhaustion. If you carved out a /24 you would likely have enough addresses. It would be hard to imagine a region hosting 255 simultaneous devices.
- Guest SSID: Guest access gets a little tricky. For the corporate environment I plan a similar ratio as I do vendor access. For the service industryโbars, restaurants and retailโIโll consider only mobile devices, and maybe add a โpointโ for the occasional dude that is โworking from home.โ The nice thing about the service industry is you know the absolute maximum amount of bodies you must support. Look above the doorway and youโll see the fire marshals required, โmaximum occupancyโ sign. If itโs 100 people, use a 1.5:1 ratio. That means a /24 would work for your operation.
The CIDR mask may change depending on how wireless traffic is offloaded to the local area network. When I mentioned the off-site controllers handling all the campus access points, you would likely need a complete /21 for 400 users with four devices. The situation changes if you offload that traffic locally to the building, though the address block may stay the same.
In that case, you may only need a /24 per building to service those DHCP needs and you take that from your supernet. Itโs important to know the function, estimated device count and where wireless is offloaded on a per SSID basis when considering your address allocations.
Carving out space
When I start planning an address scheme in a brown field environment, I like to start with the existing IP address usage. Letโs use the medium-sized campus example. There is an off-site data center, but Wi-Fi traffic is offloaded to the wire closest to the client. Letโs further assume that there are five branch offices connected via a wide area network.
In the figure, I show IP address blocks in use for this example. For Wi-Fi, I would open a new block within the RFC 1918 space for wireless clients. Remember to keep your subnets within the natural CIDR boundaries so that your route lookups and summarization is optimal.
Within the campus you could expect 100 users per building and at a 4:1 ratio, thatโs 400 IP addresses per building for your corporate wireless SSID. I would reserve a /23 for each building. Your WAN connected offices are a little smaller and a /24 would meet their needs, even at the device ratio weโre considering. With a remote data center, you wouldnโt expect a lot of wireless devices at one time. Planning a /25 with 126-usable addresses, or a /26 with 62-useable addresses would be enough for engineers needing to work in the data center.
I suggest utilizing address space outside the โnormalโ corporate wired network blocks. In the figure I showed usage within 10.0.0.0/8. If this were my network, Iโd assign wireless to 192.168.0.0/16 or 172.16.0.0/12. When I log into a router to check routes, seeing the 172โs or 192โs in the route table immediately informs me these are wireless networks. Itโs just one of those โhintsโ that help me with troubleshooting and Iโll take all the hints I can get at 3am!
This exercise obviously applies to IPv4. If you want to get ambitious, reserve and assign IPv6 address space for your Wi-Fi clientsโฆthen you only think about subnets rather than host IPs. But thatโs another discussion.
Parting thoughts
Some of these ratios wonโt apply to your organization. I wouldnโt expect them to. What Iโm trying to do in this article is give some ideas about proper planning. In my experience, improper planning causes large issues but is one that is most easily avoided.
I have worked in organizations that owned large swaths of non-RFC 1918 subnets which they used internally. You wouldnโt need to re-IP your data center for an unforeseen IP conflict. But I never wanted to burn that space for wireless. Using RFC 1918 blocks for wireless seemed like a good idea because it was easy to adjust in the event of an overlap and you conserved valuable IPv4 addresses. Your situation may vary, but the idea is still the same.
The troubleshooting problem at the beginning of this article related to a) offloading all wireless traffic in the data center rather than on the local LAN, b) junior staff assuming all subnets were /24โs, and c) poorly documented global address assignments. Your address plan needs to be thought out, documented, and flexible. Especially in the IPv4 space. If youโre adjusting your Wi-Fi infrastructure, have all the heat maps, all the BOMs, but leave address planning to chance and youโre hurting yourself and the guys who help fix problems.
About the Author
Brian Gleason
Brian Gleason is a full-time lead network engineer for a leading integrated circuit design/manufacturing company in Austin, TX. He has been in the IT industry in various roles for more than 20 years and focuses on network technologies in the enterprise space.
- Back to Blog
- Newer Article
- Older Article
-
AI-Powered
23 -
AI-Powered Networking
17 -
Analytics and Assurance
4 -
Aruba Unplugged
7 -
Cloud
9 -
Corporate
3 -
customer stories
4 -
Data Center
15 -
data center networks
19 -
digital workplace
2 -
Edge
4 -
Enterprise Campus
9 -
Events
5 -
Government
10 -
Healthcare
2 -
Higher Education
2 -
Hospitality
4 -
Industries
1 -
IoT
8 -
Large Public Venue
1 -
Location Services
3 -
Manufacturing
1 -
midsize business
1 -
mobility
17 -
Network as a Service (NaaS)
12 -
Partner Views
4 -
Primary Education
1 -
Retail
1 -
SASE
21 -
SD-WAN
12 -
Security
94 -
small business
1 -
Solutions
7 -
Technical
5 -
Uncategorized
1 -
Wired Wireless WAN
82 -
women in technology
2
- « Previous
- Next »