09-05-2014 12:01 PM
Are there any practical limits to a MAS's if it were to be used as a gateway for a wired guest network using an external captive portal (CPPM)? VLANs on non-Aruba downstream switches would terminate/route here.
I am thinking the constrictive limit would be the size of the User Table? Any limit on users-per-port or anything I'm not thinking of like that?
09-05-2014 01:10 PM
Are we talking about downstream un-managed switches/hubs or full blown switches with L2/L3 capabilities? Un-manageed switches/hubs are pretty east to work with as they typically have a low number of users attached not to mention they don't trunk back to the MAS which does not support AAA on Trunk ports. If we're talking about a large number of users, our maximums are as follows.
A standalone 24 Port switch can support 472 users, which ever way you want to cut that up. 472 on one port or distributed.
A standalone 48 port switch can support 472 user per 24 port block (0-23 and 24-47).
If you add stacking into that, we can support 1,000 users total assuming you aren't exceeding the above limits.
Could you give me more details on your topology?
09-08-2014 07:08 AM
These would be a managed L2/L3 switch environment that lack a meaningful web authentication option.
We are considering this in some places where a guest might use wired access but not configured for dot1x or MAC auth.
My test topology made the Switch the router for that particular VLAN. I tested with an access port untrusted on the Aruba switch; and then again (I thought) using a trunked port carrying the captive portal VLAN to the non-Aruba edge switches succesfully. I believe routing through the MAS forced the CP profile despite the not-untrusted trunk port. I do recognize the inherint risk of inter-user traffic at that point but may have other mitigating controls there.
What happens to the user-per-port limit on a 48-port switch if a port channel is spanned across ports say 0-23 and 0-24 (crossing the 24 port block)?
09-08-2014 07:32 AM
Only access ports may be configured as untrusted and so a trunk or port-channel cannot be configured for untrusted. I'm a little unclear on your test topology.
This would have worked:
Unmangaged_SW -------- (Access Port) SX500
These would not work:
Unmangaged_SW -------- (Trunk Port) SX500
This is the error you should have seen.
(host) (gigabitethernet "1/0/0") #no trusted port
Error: Trunk ports cannot be untrusted
Unmangaged_SW -------- (Port Channel) SX500
The "no trusted port" command is not accepted at all on a port-channel interface.
Reagrding "I believe routing through the MAS forced the CP profile despite the not-untrusted trunk port.", how exactly did you have this configured then? The only way I can picture it is like this but you still shouldn't have hit the CP page.
interface vlan X
ip addres X.X.X.X Y.Y.Y.Y
interface gigabitethernet "X/Y/Z"
09-16-2014 03:51 AM
09-16-2014 04:59 AM
I have considered the tunneled node approach - but had concerns about routing all guest wired traffic (we have 5 logical segments to our network that could each have a guest VLAN) back through a controller. The original notion was that if each branch had a MAS handling the routing/CP for the branch's guest vlan, each would solely be responsible for PE on the guest sessions.
Looks like user limits per port could be a constraint and the no untrusted trunked vlan [You were right - I must never have tested this] makes an implementation a little less neat than I had pictured in my head.