Higher Education

I'm talking really flat.....   we are reworking ip space for our campus and have now gotten  a sizeable chunk of contiguous space for our wireless and housing networks.   I had previously used vlans pools - had 11 /22's..... was a bit concerned - but had the bcast and mcast controls in palce... it worked really well.

 

Was looking at an optimum # of vlans for vlan pool hashing to work with... and well I bet using one vlan would give me the most even distribution accross all vlan(s)... but  I'm looking at using /18's

 

actually thinking of a /18 and multinetting on few smaller subnets for good measure.

 

does going so flat present any issues if I wanted to do some fancy airgroup tricks in the future?

 

anyone have any glowing reports from flatland?  or tales of horror and woe as the plains were flooded with uncontrollable layer2 protocols...(or worse?)

 

 

 

Also as a follow up - assuming flatland is happyland.....    any compelling reasons to keep my captive-portal ssid on separate ip space from my 802.1X ssid - and let the controller and roles maintain the security separation?

 

 

Travis

 

Thanks to bcast/mcast optimization, there are some very, very large subnets on Aruba wireless (/16) with features like AirGroup in use.

It's best to work with your Aruba SE on this.

 

I am working with my SE.  Have heard that people have been using very flat networks.

 

My experience with /22's and using the bcast/mcast mitigation options - leads me to beleive this should be fine.   Just wanted to get some direct feedback from anyone else who has gone flat.

 

Get some info direct from the horse's mouth...  :)

 

 

I am going to be attempting to launch a /21 with BC/MC Optmiization soon, I'll write back how it goes! :)

I have two /19's deployed on different controllers and see a high so far of about 50% address space utilization in each. No problems so far.... Previously, I had pools of /23's and /24's.

.

I assume you're PATing those /19s. To what sized networks are mapped?



Ryan Holland
Senior Network Engineer
The Ohio State University
Office of the Chief Information Officer
TNC, 320 W 8th Ave., Columbus, OH 43201
614-292-9906 Office
holland.112@osu.edu ocio.osu.edu

(sent while mobile)

Ryan,

Actually, I have two /19's that are private address space and each is PAT'd to a public /24. I also have two other /19's that are public and are not translated.

Thanks,

Brad

 

So are you multinetting those /19's

 

I'm looking to multinet a /18 and /19 onto one vlan.

 

Flatland sounds good from my pervious experience with /22 and what others have reported.

 

What specific BC and MC controls are in place?

I've been using the following

per VAP:

Drop Broadcast and Multicast

Convert Broadcast ARP requests to unicast

 

Are their other controlls I should be putting in place?

 

 

 

 

I'm running flat networks at my location; 4 /16's
we do not allow inter-user communication

we do not allow multicast/bcast  (Except for on 1 SSID in a limited number of locations)

Things work well for the most part. 

We do have a problem with constant gratuitous arps from across campus going everywhere.

Wireshark is continuously scrolling on these GARPS alone.

Slightly side-track issue.....   but is there really no way to multi-net on the aruba controllers.

 

specifically I can not have multiple ip subnets defined on one VLAN.

 

Looking around - appears I can create secondary ip interfaces on the wired switches .  Is there a different way to set this up on the controllers - or is just not a currently supported feature?

 

Travis

If the goal is increase IP capacity for a single vlan, have you considered vlan pooling instead?



Ryan Holland
Senior Network Engineer
The Ohio State University
Office of the Chief Information Officer
TNC, 320 W 8th Ave., Columbus, OH 43201
614-292-9906 Office
holland.112@osu.edu ocio.osu.edu

(sent while mobile)

I was looking at one vlan - to avoid pooling - since pools don't fill up evenly.

 

I was also thinking of using the same single vlan with large ip blocks for 802.1X and captive portal.   

 

Since the controller needs to have an IP on the client's IP network to work.   Multinetting for a captive portal vlan will not work since that is not allowed on the controller

 

Multinetting with 802.1X works find since the routing ve is upstream on a router that can have multiple IP's defined per interface.  (I've used this before to add a little extra to the vlan pools that were getting more impacted)

 

So still moving forward with large flat networks.... just using two vlans, one for 802.1X and one for Captive-portal