Wired Intelligent Edge

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?

Kevin,

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?

 

Best regards,

 

Madani

 

 

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)?

Kevin,

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

!

vlan x

   aaa-profile "TEST"

!

interface gigabitethernet "X/Y/Z"

   switching-profile "TRUNK"

!

 

Best regards,

 

Madani

What about rather than performing routing for that VLAN on the MAS, just terminate that vlan on the MAS and have it dump that traffic into a tunnel going back to Aruba wireless controller, and authenticate there just like a wireless client (assuming you have Aruba wireless)

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.