Higher Education

Hey folks,

Was curious if anyone has tips / best practice measures I may have missed for dealing with running out of IP space - getting kids off the network fast enough to free up ip space. 

We have a pair of 72xx's on each camus.  Each pair is L2 so roaming between buildings is smooth.

Multiple /23 networks under a single vlan on router - all in infoblox (dhcp) under a shared network for vlan pooling.  We are closer and closer to hitting 90-95% on all networks across.  Sometimes the shared vlan pooling in infoblox isn't working properly (all networks will be 80% and one will be 40% - working with techs on this now) but besides that some numbers:

DHCP lease time - 5 min.
Station ageout (although don't think this has much to do with it) - 1000 sec (16.6 min)

Any other values I should look at?  Any recommendations on what we can do besides add more IP space which we are constantly looking for?  **bleep** kids and their devices :)

 

Side note - for anyone curious why we don't do vlan pooling on Aruba - we tried.  Hash and even approaches both were very inaccurate and not even at all.  Infoblox seems to work much better.

 

Thanks in advance!

Have you trimmed out the lower data rates?

If you have a tool (e.g., Splunk) to perform analysis on your logs, you could dig deeper to find out whether the consumption of leases is due to persistent clients using the network for medium-to-long periods of times (e.g., laptops) or whether the consumption is from short-lived associations from smart phones and tablets.

 

What we found was that the smart devices accounted for a great deal of address consumption, so we have since moved student mobile devices into RFC1918 space. This freed up a great deal of addresses for us.

 

We have the same issues as you in terms of having to look for enough contiguous address space. If we get into a bind, we would like move all student devices into RFC1918 space.

 

Long term view is building NAT64 in the core and putting all Wi-Fi clients on IPv6 only.

 

 

And FWIW, even VLAN pooling is remarkably more efficient (for us) than hash was. The variance between most and least utilized subnets in a hashed pool was ~22% on average; with even, it's ~6%. That's substantial when you're talking about 20-30 /23s in a pool! :)

---

@Ryan wrote:

And FWIW, even VLAN pooling is remarkably more efficient (for us) than hash was. The variance between most and least utilized subnets in a hashed pool was ~22% on average; with even, it's ~6%. That's substantial when you're talking about 20-30 /23s in a pool! :)

---

Thanks Ryan, it's helpful to know that even pooling can be that effcicient.  Last I heard the best I should expect was 90%.

 

Chuck Enfield

Penn State

I'm not sure to what 90% refers, but just to be clear, I was referring to the percentage delta between the least and most utilized networks in a pool. For instance, with hash, the least may have been 72% utilized wheras the most was at 94%. With even, that difference is typically closer to 6% (e.g., least @ 78%, most @ 84%).

 

Happy to have provided an example, Chuck. :)

Yeah, I didn't say that very clearly.  I've been avoiding vlan pooling because I was told to expect about 10% difference between the most and least utilized vlans in a pool.  The way I looked at that was that if I needed to be sure all my clients got DHCP offers, I could only use 90% of the assigned addresses - thus 90% efficiency.  The people I work for want to hold me to ARIN's standards for the assignement of any new addresses to wireless (must be using at least 80% accross all assigned subnets) and if 90% was the most I could ever use I would never get 80% overall.  If pooling will allow 94% max, maybe 80% overall is acheivable.

 

Thanks,

 

Chuck

I definitely think that's achievable. We alarm when any one network is at 90% and when the pool average is at 80%. Whenever the latter happens, the former is usually true for a good portion of the networks.

Would you guys recommend moving into a single Vlan /19 instead of small vlan pools? Would you the controller feature of drop broad/multicast would be enough to containt this traffic when using a bigger pool? 

I like the single bigger VLANs with drop BC/MC. There was a lot of waste when I had VLAN pools and the most used vs the least used VLAN in the pool would vary by up to 20% (sometimes more). If one VLAN in that pool runs out of addresses, any device that hashes to that VLAN is unable to get on, period. I always had to add VLANs to stay ahead of the most used VLAN in the pool.

At the most recent Airheads in Vegas, it was recommended to use a single large vlan, like a /19, if at all possible.  There were also multiple methods of segmenting users into controlled broadcast groups, based on role, as well as converting multi/broadcast traffic to unicast.

 

@mleja2 wrote:

Multiple /23 networks under a single vlan on router - all in infoblox (dhcp) under a shared network for vlan pooling.  We are closer and closer to hitting 90-95% on all networks across.  Sometimes the shared vlan pooling in infoblox isn't working properly (all networks will be 80% and one will be 40% - working with techs on this now) but besides that some numbers:

DHCP lease time - 5 min.

mleja2,

 

Everyone above has given some decent insight on how to resolve your issue, but I just wanted to add that since you're using Infoblox you could probably contact your rep and get an eval license for their reporting server. We had real high usage on our initial-logon VLAN and after the reporting server collected data for a week found that our staff were trying to connect Apple TVs, Playstations, Xboxs, MFPs, etc. to our wireless network despite having wired connections specifically for those devices. So those devices would sit in that VLAN, eating up an IP address forever. Now via the magic of Infoblox if those devices connect to our initial-logon SSID they don't even get an IP address.

 

Just something else to consider!

 

Hip