Bridge at AP VS Bridge at Controller Advantage and disadvantage

  • 0
  • 1
  • Question
  • Updated 2 months ago
  • Answered
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?
Photo of Eddgar Rojas Calderon

Posted 2 months ago

  • 0
  • 1
Photo of Hawkins, Bruce

Hawkins, Bruce, Employee

  • 1,312 Points 1k badge 2x thumb
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.
Photo of Evan Kuckelheim

Evan Kuckelheim

  • 678 Points 500 badge 2x thumb
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?
Photo of Hawkins, Bruce

Hawkins, Bruce, Employee

  • 1,312 Points 1k badge 2x thumb
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.
Photo of SH

SH

  • 5,320 Points 5k badge 2x thumb
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


Thanks for the response, now i am a bit clear, i enforce the policies by Policy Manager and also use NAC, B@AP and B@controller does affect how policy manger an NAC is used?
Photo of SH

SH

  • 5,320 Points 5k badge 2x thumb
Hello Eddgar,

policy manager and NAC has no direct impact to the topology mode (B@AP or B@EWC) you are using.

The authorization your NAC is sending back to the controller change the Role related to the policies.
With this role you can change the vlan the traffic contains to and thereby you can switch the topology. The vlan is the connection between Policy and Topology.

Best regards
Stephan
Photo of Rob Mitchell

Rob Mitchell

  • 242 Points 100 badge 2x thumb
Something else to consider is what roaming functionality you want and the design of the network/VLANs. e.g. if you are bridging at the controller, no problem, the same lease continues throughout the wireless network during the roam. If you bridge at the AP, and the local vlan say in switch stack A is different to the local vlan in switch stack B as you wander down the corridor and connect from an AP that is patched to stack A to an AP that is patched to stack B, the client would perform a layer 3 roam, i.e. release and renew the DHCP lease for the new scope. Obviously if you have latency sensitive systems, VoWifi etc this is not good.

A way around this would be to span the same wireless VLANs to all edge switches that connect to the APs. Again depends on the size of the site, but based on your AP counts it sounds like a reasonable sized setup, so would advise against spanning the same VLAN to multiple edge locations as not best practice design.

(Edited)
Wow Thanks a lot as you stated roaming is a key point as on CAMPUS one each building has its own layer 3 router, could nos sparse vlan anyway, as also dchp would be also a problem. So i considering Bridge to controller on main Campus and Bridge @AP on the remote one as is much smaller and less dense. Ill Take the best to of two scenario.