又一個 Wifi AP 問題

由於老闆做興趣的公司多元化發展,所以跑去外地開了間旅館,一切都完工開張之後,就開始是我們的夢魘了,說是夢魘也算一半是自己造的業,當初在幫忙審弱電規格時,想說只是間不大的旅館,看到兩家廠商都提出用 DrayTek 的 Fat AP + 中央控管解決方案後,就覺得這東西可能還可以,也傻傻的以為負責統包的「廠商」會用心的幫忙解決一切的問題,結果… 廠商也就只是裝好而已,其它的也是能推就推,加上我們自己也不熟悉這個廠牌,中間的過程這邊就不抱怨了,在一步一步的試錯之後,我們今天又遇到一個麻煩事。

老闆說:那個那個 908 號房的訊號很差,無線網路還是很不好啊,到底解決了沒有?

幸好今天我們的小銳同事今天有過去開會,趕緊拿起電話急扣:快幫我去 908 號房試試,其實也幸好那房間現在沒住人,小銳同事開了門就跑進去看訊號強度。

報告報告,訊號看起來都還不錯哩,我手機上看來都有 3 格 (其實我不太確定他是拿什麼軟體看的,我腦補滿格是 5 格)。

小銳這個人其實在技術上也是挺細心的,一下子用 LINE 打給我做走動測試,一下子跑 SpeedTest,終於給了我一個 AHA :我知道哪裡有問題了!就是這個角落,小銳說他一走到這,和我的 LINE 通話就會斷斷續續。靠,這種土炮測試竟然比那些什麼 Wifi 強度 App 要來得快速有效還自帶團隊合作感,趕快繼續土炮下去,ㄟㄟㄟ,那個小銳你就一邊重複念 1~10,一邊走動,我一有聽不到的的時候就叫你停,然後看是在幾號…

AP1

測著測著小銳就想到幾週前,由於飯店在遠方,我們靠飯店那些非 IT 專業的工作人員蒐集到的問題描述又很亂:有人說連不上網路,也有人說網路速度慢,所以我們便在不同的樓層上對 AP 做上不同的設定,希望下次再來時可以藉由這些實驗組對照出還剩下的問題。

小銳說,這個樓層就是有做 2.4G + 5G 的雙頻設定,而且開了所謂的 Band Steering 功能,AP 上對這個功能的描述是:當 5G 訊號夠強時,AP 會強迫客戶端從 2.4G 跳到 5G 去。

只是沒想到,這個 5G 訊號的穿透能力看來不甚好,既使「訊號上」看起來還可以,但實際上的傳輸就是會出問題,嗯… 至少我們打 LINE 電話就出問題了。有了這個假設之後,我們就趕緊把這層樓的 5G 實驗組給拿掉,讓他只跑 2.4G 訊號,接著再讓小銳出動進行走動式土炮 LINE 通話測試,果不其然,一切就順順利利,趕快和老闆回報問題解決。

說實在的,對於 Wifi 問題我還真的沒啥辦法,又不是程式、系統或資料庫可以去翻出來看,訊號的這東西我是完全沒輒,你去問所謂的專家嘛,感覺就是叫你買 Cisco, Aruba 好像一切就解決了,你一叫他保證時他也不敢掛保證。這次大概是我處理各種 Wifi 問題以來「相對」的最有科學根據的一次吧,希望這樣子的運氣可以持續下去啊,不然三不五時的要開車跑遠地去處理也是既費時又費力。

Unifi AP 的升級

先開宗明義來說,其實不是什麼很難的東西,大致上來說,對於這類 ThinAP 的管理上,你得要注意 Controller 和 AP 之間誰負責什麼東西,才會比較容易知道問題出在哪。

1

以我今天遇到的問題來說,其實就只單純的是看到 Controller 的 GUI 上顯示了有 firmware 可以升級,按下升級鍵之後,這個 Controller 的 GUI 也是煞有其事的在那裡跑了很久,最後… 版本號碼還是顯示一樣,這問題與其說是今天發現的,倒不如說是已經發現很久了,只是之前一直沒有動機去升級它,今天是因為看到有幾位 user 反應有 Wifi 的連線問題,想說目前的版號距離上一次也已經快一年了,看 Change log 裡也滿滿的都是我看不懂的 bug fix,所以選日不如撞日,就試著解解看吧。

爬了一些論壇文章,症狀雖然都是升級不上去,但是有人教你用 GUI 上的自定義升級,有人教你 ssh 進 AP 自己下指令去 Controller 抓 firmware 下來,我甚至還跑到 AP 裡頭去看 log,但是都沒用,連 log 都沒看到任何錯誤。最後我是看到有個人提醒說要在 AP 上校時,這時候心血來朝,試著去 AP 上 ping ping 看隨便一個網址… Bingo!

原來是因為我們的 AP 由於是跑單純的 bridge mode,Controller 與 AP 之間的溝通也是透過 IP 而非 Domain name,所以當初設定的同事並沒有在 AP 上設定 DNS resolver,動手加進去之後,就可以順利由 GUI 上簡單的升級了。

2

在這個案例中,有趣的是由於 Controller 上一直顯示著可以升級 firmware,以致於我從沒想過實際的升級程序是 Controller 叫 AP 自己去抓 firmware 下來升級,加上這個 Controller 的 GUI 上也沒有正確 capture 這個錯誤出來,所以自己卡關了很久。這個升級雖然只是個不起眼的小事,卻解決了我心中卡很久的一口痰,還是覺得爽。

比威而鋼還威的 TCP BBR

前一陣子從 iThome 看到了 Google 要把 TCP BBR 應用在 Google Cloud Platform 的新聞, 才發現原來這東西這麼神,2700 倍的傳輸率,佇列延遲減少 25 倍,隨手翻了下網路上的部落格,沒想到有那麼浮誇的說法證明:下載從 84K/s 變成 3.9M/s,這立刻引起我的好奇心,找到了 Google 自己的部落格說明,原來是長久以來使用的 TCP 壅塞控制演算法有點笨,遇到有 packet loss 的狀況時,就會以比較保守的方式來傳遞接下來的封包,而新的 TCP BBR 則用了比較聰明的方法來處理 packet loss 的問題,整個示意圖就如下所示:


* Source

文中也特別拿了幾個國家為例子,說明在應用了 TCP BBR 之後,YouTube 的表現情形,不看還好,一看之下,沒想到 Google 也這麼浮誇寫實,YouTube 到 ID 的 Max Round-Trip time 竟然可以改善到 50% 以上,這讓我突然想到以前公司在進行某個網路直播專案時,那個爛 4G 網路讓我們驗收時吃了很多苦頭,所以我也來做個浮誇的測試好了。不過因為一來我很懶,二來也沒那個預算搭建回當初專案的原始架構,所以以下浮誇的測試只在我的本機上實驗。

  • 實驗環境 (都在同一台機器裡):
NB: OBS Studio 19.0.3 --> NB: clumsy-0.2 --> VM: SRS 2.0.242 + CentOS 6.9 --> NB: flv.js in Chrome
  • 實驗方法:
  1. 先以 Kernel 2.6.32-696.6.3 直接測試,擷取螢幕看直播視訊延遲
  2. 以 clumsy 加上 inbound & outbound 各 50ms 的延遲,並隨機 drop 10% 的封包
  3. 等個幾秒,擷取螢幕看直播視訊延遲
  4. 停止 clumsy,等個幾秒,擷取螢幕看直播視訊延遲
  5. 升級 Kernel 為 4.13.0-0.rc1,重複步驟 1~4
    * 我拿了一個 Firefox 開時鐘來讓 OBS 擷取螢幕畫面,所以測試畫面中會看到 Firefox
  • 實驗結果:
  1. 沒 TCP BBR,不啟用 clumsy,延遲大概 3 秒
    Without BBR - normal network
  2. 沒 TCP BBR,啟用 clumsy,稍等一下,延遲變為 13 秒,實測時這個延遲會迅速擴大,最差的狀況是影像會停掉
    Without BBR - bad network
  3. 沒 TCP BBR,把 clumsy 關掉,稍等一下,延遲回到 5 秒左右
    Without BBR - normal network again
  4. 有 TCP BBR ,不啟用 clumsy,延遲大概 2-3 秒,其實和沒 BBR 時差不多,這畫面看起來延遲只有 2 秒應該只是個測試誤差
    With BBR - normal network
  5. 有 TCP BBR,啟用 clumsy,稍等一下,延遲變為 4 秒
    With BBR - bad network
  6. 不信邪,再等一等,有 TCP BBR,啟用 clumsy,延遲還是維持 4 秒左右
    With BBR - bad network-2
  7. 恢復原狀,有 TCP BBR,不啟用 clumsy,延遲還是維持 4 秒不動
    With BBR - normal network again

總結來看,這個 TCP BBR 還真的神,在高延遲且掉包的網路上,在我的測試環境 1 個 client 對 1 個 server 的情境下就能有這麼好的表現,安裝的方法我就不特別提了,網路上隨便 google 都一堆,不過還是要提醒大家一下,再好的東西還是得先測試才能上正式環境,免得哪個不小心你就踩了坑了都不知道。

BBR Summary

玩一下 Google Compute Engine 要花很多錢嗎?

雖然身為一個 IT 人,也知道這一行要與時俱進不然就被淘汰的道理,但是我個人對於「在雲端上花錢」這件事情的態度算是偏向保守的那一派,像是 LINE Pay 已經出來半年了,我是為了貪那繳稅的回饋金才去辦卡且綁定了我的 LINE 帳號,Google Play 上就算有需要綁定過信用卡,也是用完之後就移掉,不然我自己會想像被他亂收錢。

這次之所以會想要在 GCE 上花錢,是因為看了某個對岸網友的文章,發現 Google 竟然直接在他的 GCE 上提供 Anycast IP + Global Load Balancer + CDN 的服務,因為這實在是太狂了,所以我忍不住就打破了自己的的風險規則,跑去把我的信用卡放上去。

我測試的東西也就是 Anycast IP –> With CDN –> Load Balancer –> 一台台灣 VM + 一台新加坡 VM 這樣子的架構,測試之前先在我自己電腦上的 VM 跑了一次,並且把安裝與設定步驟記錄了下來,所以去 Google 上開機器時,除了幾個 Google 自己的設定需要實驗多花了點時間之外,大致上可以說是沒幾個小時就做完相關的設定工作,然後就開始測試了。之後就放那邊放了兩天,端午節之前把 Anycast IP, CDN, Load Balancer 及新加坡機器關掉,只留下台灣這台 VM 給同事測試用 (對,我實際上的需求並沒有一定得要用 Anycast IP,只是拿來試試看功能而已),這樣子我一共花了多少錢呢? 才 US$1.96

1

而且 Google 也提供了一個預算管制的功能,當所花的錢超過你設定的預算時,就會發警示信出來。因為我拿來玩 GCE 的帳號就是我平常在用的 Google 帳號,也綁了我的 Android 手機,所以這功能讓我很安心的繼續用下去。

2

前一陣子不知道是哪位臉書上的心得,說是微軟 Azure 要和 Amazon AWS 或 Google GCE 對打還是走得很辛苦的。對照一下這幾年來看到 Google 在做的事情:Google 自建海纜、GCE、Anycast IP on GCE、Google CDN (如果 Google 要把他們在世界各個 ISP 放的 Google Global Cache 也拿來做 CDN 加速的話,那就更恐怖了),可以看到 Google 要做而且已經快做到的是「世界」的 IT Infrastructure – 全世界的中華電信、全世界的 Hinet,這意思是什麼呢?如果你今天只想做台灣的網站也就算了,如果你是想搞跨國的網路應用(電子商務、遊戲、社群、直播…),以後你也不用多想了,就直接放 Google 上就好了,如同幾年前的台灣一樣,大家想搞網路、搞遊戲,機房鐵定要選中華電信、專線一定得拉 Hinet,因為全台灣的使用者幾乎都是用 Hinet,想不接 Hinet 線路就是要讓使用者 lag 爆。這種事情以後就會反過來,大家要在全球佈局的話首選就會是 Google,因為最簡單速度又最快。

所以,學學這些 Public Cloud 的使用經驗看來就是未來 IT 人的必備技能,而且搞不好還比去學什麼 Server 安裝或 Cisco 設備操作要來得基本且必要,要練習這些東西很花錢嗎?你要練 Server 安裝、系統管理之類的可能要去買台機器或借個環境才能操作,想練網路我看很多人會花個幾千塊去網路上買二手設備來練習,但是想練 Google Public Cloud? 以我這次的例子來說,只要 1.96 鎂就好,可能比很多人一天的通勤費用還便宜些,好東西,不買嗎?

在 Windows 上使用支援 edns client subnet 的工具 – dig 9.11

之前提到了說 BIND 會從 9.11 開始支援 EDNS client-subnet,所以若你的 BIND 已經開始使用 GeoDNS 的功能,恰好你的 end user 用的 DNS server 也支援 EDNS client-subnet 的話 (eg. Google DNS 就支援),那恭喜你,你的 GeoDNS 的效果應該會變得更加顯著。

但實際把功能丟上去之後,你就會發現有事沒事的你會遇到使用者抱怨他連你的網站速度太慢,原因是因為你的 GeoDNS 回給他的結果和你預期的不同,原本你想要 GeoDNS 丟個離日本最近的 IP 給他,但他拿到的卻是個英國的 IP。這時候我們就需要個可以快速驗證 GeoDNS 設定是否正確的工具了。

這工具其實也很簡單,因為就是隨著 BIND 9.11 一起更新的 dig 命令,只是以前我笨笨的,以為 BIND 只有出 source code,自己又沒種花時間去 Windows 下建立編譯的環境,所以都是去抓別人編譯好的執行檔,自己都覺得有點不是挺安全的,不過剛剛仔細一瞧,原來 ISC 自己的官方網站上就放了 BIND 的 Windows 版,只要下載之後安裝也就可以用了…

01

安裝的時候只要選擇「Tools Only」就好,我想大家也不想在自己的電腦裡裝個用不著的 BIND Server

02

裝好之後,如果你像我一樣對自己用的系統有一點潔癖的話,可以把目錄下的這些檔案(除 BINDInstall之外)拷貝到你喜歡的目錄,剩下的東西則可以全部移除。

03

dig + EDNS client-subnet 的使用方法也很簡單,就是

dig [domain name you want to query] @[DNS Server] +subnet=[addr]

http://www.google.com 為例,如果我是個位於美國的使用者,IP 是 128.32.203.137 (我隨便抓了個柏克萊大學的 IP 來測試),解析出來的會是 172.217.5.100

04

那如果我是個台大的學生,IP 是 140.112.8.116 的話,解析出來的會是 163.28.18.30 (左右…)

05

我自己現在用的是遠傳的網路,從 ping 的結果看來,Google 應該也是有應用 GeoDNS 來加快網站的速度(當然也用了 BGP anycast,但不在此文討論範圍)

06

最後,更笨的是,如果你什麼都不想裝,就用別人放在雲端上的服務就好了…

https://tools.keycdn.com/dig

 

區網電腦透過pfsense取得ISP的IPv6

首先,要先去申請IPv6,這是"完全免費的"以中華來說,可以臨櫃申請,也可以線上申請,在這邊網頁上Ctrl+F搜尋ipv6申請

IPv6_ready_logo_phase2

在這邊使用的是pfsense2.2.6版本,但設定應該大同小異 繼續閱讀「區網電腦透過pfsense取得ISP的IPv6」

Centos 路由去回不同路解決方式

不知道大家有沒有在linux伺服器上有兩張網卡,且設有多段IP,但是卻如法在同網段ping通和tracert的經驗

本人我就遇過這樣的問題

如果你有兩張網卡 eth0與eth1

eth0的網段為10.10.1.0/24

eth1的網段為10.20.1.0/24

我們假設網段10.10.1.0/24的gateway是10.10.1.1

預定要讓預設的gateway裝置eth0回的話,解決的方式如下:

1.編輯iproute的規則名稱
[root@pandacentos ~]#vi /etc/iproute2/rt_tables
10     pandaroute #10為route table的值,pandaroute為route table名稱,都可自訂,但名稱請取服務名稱,方便辨識
2.重啟網路服務
[root@pandacentos ~]#service network restart
3.增加route的rule
[root@pandacentos ~]#ip route add default via 10.10.1.1 table pandaroute
[root@pandacentos ~]#ip rule add from 10.10.1.0/24 table pandaroute
以上的方式試一次性的解決方式,因為沒加到static route,所以在重開機後route就會消失,要如何避免這個問題,你可以在/etc/rc.d/rc.local上加上面這兩行制令,或用下面的static route 和rule的方式添加
[root@pandacentos ~]#vi /etc/sysconfig/network-script/route-eth0
default via 10.10.1.1 table pandaroute
[root@pandacentos ~]#vi /etc/sysconfig/netwrok-script/rule-eth0
from 10.10.1.0/24 table pandaroute
4.如果是加static route的方式,請在重起一次網路服務
[root@pandacentos ~]#service network restart