對網路不太了解
想請問同一家廠商的router
AC世代跟AX世代可以組mesh嗎?
目前考慮的對象是ASUS AC86U跟AX86U
因為家裡已有舊款，不知道升級以後舊款怎麼處理
作者:
jeff40108 (死得腥羶豔油劑是他)
2020-08-09 13:14:00Aimesh=拉雞建議砍掉重練，買真mesh
作者:
jior (大J)
2020-08-09 21:36:00真的，直接買真的mesh吧
作者:
birdy590 (Birdy)
2020-08-10 00:06:00現在趨勢 thin AP 越來愈少了吧 連商業產品都開始用現成 wisoc 去湊 AC+AP, 但這樣出來還是 fat AP沒辦法 不這樣搞開發速度太慢 根本沒競爭力
我們專弄不是一般用法的wifi，你說的那東西我們不用到是現在除了ThinAP, FatAP外,,又往Cloud AP去了這市場也起來了~~~
作者:
HiJimmy (å—¨ å‰ç±³)
2020-08-10 22:02:00Cloud AP是像之前Fon Ap那樣?
其實就是控制器變雲端化了.使用者簡單容易管理設定cisco meraki , aruba instant onRuckus Cloud Wi-Fi 等,我自己是用 instant on
沒記錯的話，最早搞控制器雲端化的應該是Unifi?
作者: ptckimo (ptckimo) 2020-08-12 16:19:00
商業版的ThiAP？不難找啊！DrayTek VigorAP 903組mesh超好用，pchome udn都有賣，預算夠的話用這個不後悔
作者:
uxtz (炎夏)
2020-08-12 23:56:00想要mesh建議是直接上啦，這種用ai mesh去湊得真的不穩如果有舊款建議就拿來當純路由器用吧....
作者:
birdy590 (Birdy)
2020-08-13 00:09:00現在不流行 ThinAP 了... UBNT 有說明 頻道要統一是硬傷雖然妥善規劃下漫遊效果是最好 但實在太貴又太麻煩開發軟體去控制現成 wifi 晶片 效果接近但便宜很多
Thin AP是價格問題，商用一堆哪裡不流行穩定 功能根本屌打MeshThin AP由控制器統一管理，我是不知道哪裡麻煩喇
作者:
birdy590 (Birdy)
2020-08-13 12:42:00不是講了嗎 頻道必須一樣 設計上困難會很大所以會有各式各樣當天線 儘量把空間切開不要重疊用fast roaming就簡單多了 頻道錯開就好 剩下讓裝置自己選
誰跟你說頻道要一樣?cisco / aruba ThinAP在有 AC 下,自己2.4Ghz鄰近AP 都會 1 6 11 分開不重複一但 CH 統一了就是信號品質會不良.ch 使用率會高有空自己開inSSIDer 看看有 ThinAP 的環境多顆ch 是怎分佈的UBNT 若會寫出這樣的話,我應該不會用他們家的東西
作者:
birdy590 (Birdy)
2020-08-13 15:00:00等一下 通通錯開 請問一下要如何漫遊?用 k/v/r 做漫遊的 節點大概也瘦不到哪裡去吧我是認為傳統定義的"thin AP"早就已經絕種了
作者:
birdy590 (Birdy)
2020-08-13 15:08:00那個年代包括漫遊全都是由 AC 控制, 頻道錯開不用重連?一個蘿蔔一個坑 怎麼可能照樣漫遊 @@這得先回到開頭 "thin AP"的定義到底是什麼像 Cisco 就直接改叫 lightweight ap, 舊定義根本不用了
ThinAP , FatAP 現在比較是一個名詞.....
ThinAP沒有頻道必須一樣，那是Mesh的問題正常鄰近AP頻道都要錯開，不然會自己打自己
作者:
birdy590 (Birdy)
2020-08-14 00:24:00這樣就是沒漫遊啊 QQ 莫忘 thin AP 比那些漫遊協定還老以前 UBNT 還做了 Zero-Handoff Roaming, 現在也退休了還是定義的問題 如果 thin AP 定義退化到"由中央控制器統一設定" 我認為這其實已經脫離原本的意思了我記得最原始的定義應該是 AP 只負責 radio, 其它全部由控制器來做 當然這不會有什麼"個別設定"的問題所以 像Cisco這樣直接改用自己的定義可能更好些
？？？？最早能夠漫遊的就是ThinAP，你還在那邊沒有漫遊
作者:
birdy590 (Birdy)
2020-08-14 11:27:00你沒看上面討論 那就是得用同樣頻道 不然要怎麼漫遊?wifi 不重新連線有辦法換頻道?
然後ThinAP本來就要有Controller，哪來的定義退化
作者:
birdy590 (Birdy)
2020-08-14 11:28:00看清楚點 我的是"只剩下由中央控制器統一設定"但後來的 AC+AP, cloud AP 也都是這樣 但一點也不 thin最早的 thinAP 節點應該只負責 radio, 就像是台超大 AP
ThinAP一直都是由Controller統一設定管理好爆一一
作者:
birdy590 (Birdy)
2020-08-14 11:29:00對 但這部份不是重點啊 中央控制就會 thin 嗎?本來最重要的特性 在環境變化之後條件已經不存在了
作者:
birdy590 (Birdy)
2020-08-14 11:31:00所以上面一開始不是就問了 "得先弄清楚 thin AP 的定義"原始定義從來就不是"由中央控制器統一管理 那只是個角"或者說是 節點功能極度簡化後的必然結果節點只靠本身根本不能獨立工作 如何不由中央統一管理
ThinAP FatAP定義一直都是這樣，是你搞不清楚八一一
作者:
birdy590 (Birdy)
2020-08-14 11:38:00一直都是"哪樣"?"Thin AP只提供無線訊號傳遞" 2005年的大標題是長這樣這個時候當然是沒有漫遊的 所以才會講 ubnt 的 zhr
作者:
birdy590 (Birdy)
2020-08-14 11:47:00他應該是看懂漫遊的問題了 不然你的 thin/FAT 毫無分別你自己都沒發現這種定義已經失去意義了?請問一下 把一堆 fat AP 安裝中控系統 會不會變瘦照這種邏輯連 aimesh 都變成 thin AP 了, 到底哪裡瘦了
作者:
birdy590 (Birdy)
2020-08-14 11:56:00不要迴避問題嘛, 請問一下 aimesh 是不是 thin AP一個定義如果本身就無法自圓其說 就肯定有問題我連解釋都給你了還看不懂? 原始定義的 thin AP 已滅絕像上面思科這種作法 直接自己創造一套新的定義才是正途
作者:
birdy590 (Birdy)
2020-08-14 12:00:00麻煩請你用你的定義解釋一下 aimesh 為什麼不是 thin AP因為這個"控制器"的工作範圍 你根本連碰都沒碰
先不說華碩的AiMesh≠MeshAiMesh關掉能不能單獨運作？可以啊那就是FatAP啊，這很難懂嗎
作者:
birdy590 (Birdy)
2020-08-14 12:03:00這到底什麼爛定義 @@
ThinAP沒Controller就不能動，這真的很難懂嗎？？？？
我還真不知道這摸簡單的定義會有人不懂啊對定義也不是我下的，感恩
作者:
birdy590 (Birdy)
2020-08-14 12:07:00(然後順便補充一下, 就連AiMesh≠Mesh可能也有必要修正不知道有多少人發現, 多數平台上 k/v 都已經開了thin AP 的原始定義上面有 "節點只提供無限訊號傳遞"一開始控制器的工作是很多的 根本不可能搞什麼雲端設定節點只是它工作的一塊, 不是設定完就沒事了那時候的節點性質比較像延伸出去的天線 所以很多可以玩中控要把裝置搬到另一個節點 裝置甚至根本不知道不然你告訴我沒有漫遊協定還能怎麼漫遊?但是用現在的硬體這個做不到 因為很多工作都下放了不再只是提供無線訊號傳遞 自然就談不上"thin"硬體上跟一般AP沒什麼分別 韌體做的事情搞不好還更複雜
我是懶得說了...我工作規劃的環境都是給數百人上顆顆AP的運作懂無線通訊的人就不會說漫遊一定是要同一個頻道了ThinAP就是自己本身不負責RF/auth的部份,就是自己開起來後..所有的動作用控制器來指揮聰明的控制器會自己感知AP附新的頻道使用情況自動使用較少使用率的頻道.ThinAP 架構下有沒有可能用 11kvr ? 有可能也有的人家可以做的事比 FAP 多太多了,802.1x , mac auth , portal auth 等真的不明白可以去看看 cisco 白皮書真想了解 可以去 查一下 CAPWAP想要自己搞自己的 AC + AP 可以看 open CAPWAP
作者:
birdy590 (Birdy)
2020-08-15 23:33:00你沒講反過來那面啊, thin AP 當然可以用 kvr但是不靠 kvr 能不能做出無縫漫遊? 當時那可是賣點之一現實是有 kvr 之後 廠商發現根本沒必要像以前那麼辛苦你應該也很瞭解 對裝置來說 換頻道其實就等於重連重連就不會是無縫... 當時 ZHR 的漫遊效果比 k/v/r 還強開頭 thin AP 頻道當然可以錯開, 但要做漫遊就不行了有了 k/v/r, 變成裝置也參一咖以後 沒必要再做那麼 thin所以幾乎絕種了... 大致上完整的 story 應該長這樣