何時規劃 IAP (叢集運行) 何時規劃 CAP (控制器控管的AP)
其實沒有所謂的標準答案 雖然 單一IAP 叢集 可以支援128 部AP 但實際運作上 建議少於12部!!
建置 IAP 主要的考量是 簡單好管理 不需要採購控制器.. 期初規劃上成本比較低..可是如果 數量超過十部以上的時候 存取人員 超過200人以上 就會建議規劃 CAP....
IAP 會建議規劃在相同的安裝地點...同一個campus 下的網路 而且運作在相同VLAN上面...
剩下的練英文吧!!!
- In "larger" scale scenarios. "Larger" is, of course, completely subjective and means something different to everyone, but a workable guideline is anything more than 12 IAPs at a single physical location.
- Whenever it doesn't make sense to repeatedly buy and be concerned with Compute resources (CPU, RAM, Flash) in each IAP and it makes more sense to the customer and/or you to put a ton of Compute into specialized-for-that-purpose component of the architecture, i.e. a controller.
- Any time the customer's existing wired backbone is not already pretty finely tuned to deal with the Broadcasts / Multicasts that IAPs, being basically 802.11-802.3 bridges, kick out.
- Any time more than 1 IAP cluster of more than 64 IAPs would be recommended (yes, QA says the limit is 128 IAPs in a single cluster, but it's prudent to stay under half of what a system is capable of), one should be looking at a CAP architecture.
- Whenever the idea of having to add (a) VLAN tag(s) to each and every Edge switch and port off of which an IAP will hang is unattractive to the customer.
- If nearly all of the end user's traffic is North-South, i.e. going from wireless endpoints to some Server in the Data Center (where a controller is usually placed) or to the Internet, anyway then the tunneled architecture of CAPs and (a) controller(s) is just easier.
- When you're building a WLAN for subjectively large concentrations of users, e.g. 2000+, in a single physical location or campus of adjacent buildings.
This is not to say that IAPs don't have their place. They're completely the right answer for highly distributed brick-and-mortar / physical locations estates, e.g. Retail, enterprises with lots of small branches, smaller K-12 campi, etc.
Oh, and a key marketplace differentiator for our controller-less IAPs is that, a customer can start with the smaller-scale architecture of IAPs, and then, when they grow to requiring the larger-scale features of a CAPs-and-controller architecture their IAPs can be easily be converted to CAPs. None of our competitors can do that.