Bridge at AP VS Bridge at Controller Advantage and disadvantage

[Eddgar_Rojas_Ca]

Hi colleages:
I have 2 big sites and both of them have a wireless controller virtual, 1 having like 230 Ap's (Main Site) and other having 72 all using bridge at controller (except a 3rd small site with 3 APs using brige@AP). I use around 10 roles each ones with is own VNS using one SSID. All sites have their own internet connection for browsing and slower links for communication to main site.

I also have integrated extreme Control, and Extreme NAC solution to register user on network and also policy manager for manage controllers and switches.

A partner recommends me that would be great idea to consolidate these controllers on main Site and setting all AP VNS at Bridge@AP. but I have a lot of doubt about it

So What are Advantage and disadvange using Bridge@ap topolgy VS bridge@Contoller?

is better Bridge@AP scenario? and Why?

[StephanH]

Hello,

in my opinion there is another important difference.

Only if you use B@AP and PSK, your APs can work without an controller for example in case of an connection loss to the controller.

In some cases this point is important. But as Bruce wrote the decision depends on your design choice and requirements

Best regards
Stephan

[Hawkins__Bruce]

The default setting ... even for B@controller topologies ... is to have "AP Filtering" enabled so Policy Rules are "enforced" at the AP. The only difference is ... you can disable that if you want with B@controller topologies ... and with B@AP you have no choice but to enforce Policy Rules at the AP.

[Evan_Kuckelheim]

Sorry to just jump in here; is there any performance hits with bridge B@AP with policy compared to B@controller. Is the filtering done on the same place in both Scenarios?

[Hawkins__Bruce]

The most basic advantages/disadvantages between them are:

B@controller:

-- Ease of administration. If you want to add a new VNS/WLAN that contains traffic to a new VLAN, you only have to tag one port on the controller and you're done. If you want to do the same thing with B@AP topologies ... you would have to tag every AP port and all the interswitch links between all edge and distribution switches (if you have them) up to your core as well.

-- All traffic is brought back to the controller and out only one or a few ports (if you create a LAG)

B@AP

-- More work to administer (see above)
-- Traffic is distributed across as many ports as you have APs

Whether one is "better" than the other or not depends on your design choice and requirements. If you have a controller in a central location, say Dallas ... with all your APs in remote locations ... Boston, Detriot, LA, SF etc ... then it probably doesn't makes sense to tunnel all that traffic back to the controller ... when a lot of it will have an ultimate destination of some other device in the remote location the packets were sourced from. Also, if you have a small network with not that many APs and a limited IT staff ... it may not make sense to overly complicate the design ... and with 10-15 APs and a hundred or two hundred clients connecting through them (just numbers I'm throwing out there .. NOT hard limits or recommendations) you may have an easier time sticking to B@controller topologies in terms of the work involved ... and you may see no issues with performance.

In your case ... 300+ APs ... it may make sense to move some or all topologies to B@controller ... if you are prepared to do the work to build out ALL your VLANs to all AP ports and the switches that serve them ... but ultimately you are the best one to decide that. If you do it, you may see benefits in breaking your client traffic up over 300+ AP ports vs. tunneling all your traffic back to your two controllers and egressing that traffic out a handful of ports, but you will add additional work to maintain and grow the solution as well.

Hope this helps.