我在宇宙無敵天位大長輩的 blog 貼了個 commet, 覺得應該轉貼到這邊,
ISP 對 HINET peering 的費用有兩大塊
1. peering charge (就是這次調降的部分)
2. CHT 專線電路費 (沒有調降, 某些人還被變相漲價)
第 2 項這個專線電路是只能用中華電信提供的電路, 也就是說想跟 HINET peering 的話就要讓 CHT 的區分公司剝一次皮. 這次的降價只有 peering charge 降價, 但是專線電路費沒有降價, 基本上宣傳效果大於實際效果. 這次 peering charge 的調降, 最立竿見影的成效就是死掉一大堆夾在小 ISP 跟 HINET 之間的 resale services 的 ISP.
中華電信 (區分公司還有數據分公司) 長期以來不斷的玩這種數字遊戲, 比如說 ADSL 降價只降網路費用卻不調降 (或僅微幅調降) 界接電路費以及用戶迴路電路費用, 再加上交叉補貼的「market manervering」的結果, 就是中華電信宣佈「調降」的幅度越大, 其他 ISP 死的越快.
消費者是盲目的, CHT 的媒體公關透過好朋友記者大肆宣傳「中華電信降價」的消息的同時, 也暗示著消費者應該要求他的 ISP 降價, 但是消費者誰去探究過中華電信每次「降價」行動對於市場的影響, 以及未來對於台灣數據通訊服務產業的影響呢?
「中華電信降價」對台灣數據通訊服務的發展是一帖強身建骨的良藥, 或者是一碗裝飾華麗且味道甜美的毒藥?
Tuesday, September 27, 2005
Monday, September 19, 2005
TAnet 再次拒絕 ICP 業者單點互連
2005/9/19 是個值得紀念的日子, 紀念 TAnet 再一次把 ICP 業者拒於門外.
TAnet 有個老掉牙的規定, 叫做 ISP 七點互連規則. 原始設計這個七點互連規則是有歷史因素的, 因為當年整個 TAnet Backbone 是用一個 T1 從北串到南, 如果 ISP 只在台北互連, 那相當容易 (應該說鐵定) 會把 TAnet Backbone 灌到爆. 而後來 TAnet 的 backbone 雖然持續擴充到 STM-1, 2*STM-1 也都沒有擺脫 Backbone 頻寬不足的窘境, 也因此這個七點互連規則一直沒有拿掉.
在這麼多年的執行過程中, 台灣的 ISP 一方面為了百萬莘莘學子, 另外一方面當然也是因為 TAnet 所擁有的龐大「資源」, 所以台灣的幾大 ISP 無不全力配合遵守七點互連規則, 而幾個 ISP 匯集的區網中心慢慢的就把 ISP 互連以及七點原則視為理所當然, 甚至把它變成一個公平與否以及資源角力的一個標準 (有一些滿精采的故事).
但是, 隨著 Internet 的發展以及 TAnet 本身的成長與變化, 到後來因為種種因素 TAnet 與 TWAREN 共用骨幹, 再再讓 TAnet Backbone 以驚人的速度成長, backbone 的發展已經遠快於連線單位 (與連線學校) 跟上的腳步. (TAnet Backbone 流量統計)
Internet 的發展一路走來 ISP 逐漸成熟進入穩定階段, 另一個蓬勃發展預期高成長的另外一個網際網路相關行業叫做 ICP, 例如 Yahoo!, Google, 或是本土的小嬰兒 *Home 集團 (PCHome, ITHome...). 而這個高成長的行業有人預言為下一個 Internet 革命的推動力之一.
ICP 與 ISP 的經營特性多少有點不同, ISP 是逐 user 而居而發展, 但是 ICP 卻是逐 IDC 而居而發展. ICP 需要大量的建設完整的機房空間去配置伺服器以及儲存系統, 通常來說, 一個世界級的 ICP (例如 Google, Yahoo!) 在大國家只有幾個機房 (例如美國東西岸各一兩個), 而到小國家 (例如台灣) 頂多就放一個機房, 甚至數個鄰近的小國家共放一個機房.
如果 Internet 發展到今天還要強迫 ICP 去比照 ISP 依循著將近十年前的所制定的七點互連規則, 就執行上或是技術的合理性上都將被嚴重的懷疑. 更糟糕的是, TAnet 的某些委員會決定把 ICP 跟 ISP 一視同仁的時候, 檯面上所堅持的薄弱的理由僅僅是「公平性」三個字. 拿不出合理的技術證據支持把 ISP 跟 ICP 一視同仁的決定.
捫 心自問, 檯面上的理由絕對不是真正的理由. 檯面上的理由只是牽強的托辭, 隱藏在強自鎮定的面具下的, 是對於複雜資源分配的不確定性的恐懼. 如果 Google 選擇了連接某一個區網而不去連接另外一個區網, 是不是有 Google 連線的區網講話會比較大聲? 是不是有 Google 連線的區網下次會得到更多資源去提升設備與頻寬? 這些恐懼都來自於自信心的缺乏, 缺乏把區網角色經營好的信心, 缺乏用心經營服務而獲得更多資源的信心.
當有一天 ICP 業者發現, 事實上 TAnet 佔他們真正客戶比例只是少數的時候, 會不會乾脆就放棄 TAnet? 反正 TAnet 與 ICP 連線的品質差, 也只是少數人會痛. 當這一天來的時候, 堅持七點互連才有「公平性」的委員們敢不敢站出來大聲說「當年就是我堅持反對 ICP 單點連線, 就是我堅持要 ICP 從他台北機房拉個線路到高雄去滿足七點互連規則的」
事情發生了之後, 今天慷慨激昂反對的人, 哪一個敢站出來?
TAnet 有個老掉牙的規定, 叫做 ISP 七點互連規則. 原始設計這個七點互連規則是有歷史因素的, 因為當年整個 TAnet Backbone 是用一個 T1 從北串到南, 如果 ISP 只在台北互連, 那相當容易 (應該說鐵定) 會把 TAnet Backbone 灌到爆. 而後來 TAnet 的 backbone 雖然持續擴充到 STM-1, 2*STM-1 也都沒有擺脫 Backbone 頻寬不足的窘境, 也因此這個七點互連規則一直沒有拿掉.
在這麼多年的執行過程中, 台灣的 ISP 一方面為了百萬莘莘學子, 另外一方面當然也是因為 TAnet 所擁有的龐大「資源」, 所以台灣的幾大 ISP 無不全力配合遵守七點互連規則, 而幾個 ISP 匯集的區網中心慢慢的就把 ISP 互連以及七點原則視為理所當然, 甚至把它變成一個公平與否以及資源角力的一個標準 (有一些滿精采的故事).
但是, 隨著 Internet 的發展以及 TAnet 本身的成長與變化, 到後來因為種種因素 TAnet 與 TWAREN 共用骨幹, 再再讓 TAnet Backbone 以驚人的速度成長, backbone 的發展已經遠快於連線單位 (與連線學校) 跟上的腳步. (TAnet Backbone 流量統計)
Internet 的發展一路走來 ISP 逐漸成熟進入穩定階段, 另一個蓬勃發展預期高成長的另外一個網際網路相關行業叫做 ICP, 例如 Yahoo!, Google, 或是本土的小嬰兒 *Home 集團 (PCHome, ITHome...). 而這個高成長的行業有人預言為下一個 Internet 革命的推動力之一.
ICP 與 ISP 的經營特性多少有點不同, ISP 是逐 user 而居而發展, 但是 ICP 卻是逐 IDC 而居而發展. ICP 需要大量的建設完整的機房空間去配置伺服器以及儲存系統, 通常來說, 一個世界級的 ICP (例如 Google, Yahoo!) 在大國家只有幾個機房 (例如美國東西岸各一兩個), 而到小國家 (例如台灣) 頂多就放一個機房, 甚至數個鄰近的小國家共放一個機房.
如果 Internet 發展到今天還要強迫 ICP 去比照 ISP 依循著將近十年前的所制定的七點互連規則, 就執行上或是技術的合理性上都將被嚴重的懷疑. 更糟糕的是, TAnet 的某些委員會決定把 ICP 跟 ISP 一視同仁的時候, 檯面上所堅持的薄弱的理由僅僅是「公平性」三個字. 拿不出合理的技術證據支持把 ISP 跟 ICP 一視同仁的決定.
捫 心自問, 檯面上的理由絕對不是真正的理由. 檯面上的理由只是牽強的托辭, 隱藏在強自鎮定的面具下的, 是對於複雜資源分配的不確定性的恐懼. 如果 Google 選擇了連接某一個區網而不去連接另外一個區網, 是不是有 Google 連線的區網講話會比較大聲? 是不是有 Google 連線的區網下次會得到更多資源去提升設備與頻寬? 這些恐懼都來自於自信心的缺乏, 缺乏把區網角色經營好的信心, 缺乏用心經營服務而獲得更多資源的信心.
當有一天 ICP 業者發現, 事實上 TAnet 佔他們真正客戶比例只是少數的時候, 會不會乾脆就放棄 TAnet? 反正 TAnet 與 ICP 連線的品質差, 也只是少數人會痛. 當這一天來的時候, 堅持七點互連才有「公平性」的委員們敢不敢站出來大聲說「當年就是我堅持反對 ICP 單點連線, 就是我堅持要 ICP 從他台北機房拉個線路到高雄去滿足七點互連規則的」
事情發生了之後, 今天慷慨激昂反對的人, 哪一個敢站出來?
Wednesday, September 14, 2005
亂數假文產生器
剛剛在 "RichyLi.com 李怡志的圖表、網路、新聞個人網站" 看到的新奇玩具「亂數假文產生器」! 可以亂數產生中文的假文... 對文字工作者來說是工具, 不過對於其他人來說就是新奇的玩具囉! 齁齁齁... 真好玩 ^_^
吃快打破碗
不知道這個標題下的恰不恰當, 我要說的是如果發現問題一直想找 quick fix 的話 (不管是因為時間壓力或是因為偷懶), 到最後都會 fix 出更大的問題. 修東牆漏西牆, 修修補補到最後問題越來越大條...
(看某人改網頁程式有感而發)
(看某人改網頁程式有感而發)
Sunday, September 11, 2005
擋 ssh brute force 攻擊
剛剛從拉飯的 blog (Rafan's Blog) 那邊看到 sshit ( http://anp.ath.cx/sshit/ ) 這個東西, 真是用來擋 ssh brute force 攻擊的好工具呀!
sshit 要搭配 ipfw (使用 rule 2100 到 2199) 還有 Perl module IPC::Shareable (在 ports 裡面有 /usr/ports/devel/p5-IPC-Shareable)
sshit 要搭配 ipfw (使用 rule 2100 到 2199) 還有 Perl module IPC::Shareable (在 ports 裡面有 /usr/ports/devel/p5-IPC-Shareable)
FreeBSD GIF Tunnel
GIF = Generic Tunnel Interface
用 GIF 的 Tunnel Mode 可以把兩個 Intranet 串起來透過 Internet 互通, 這就是 IP VPN 啦. 如果加上 IPsec 等編碼, 就變成 Secure IP VPN 啦.
Gateway A:
Public IP: 100.1.1.10
Private IP: 192.168.100.1/24
ifconfig gif0 create tunnel 100.1.1.10 200.2.2.20
ifconfig gif0 inet 192.168.100.1 192.168.200.1 netmask 0xffffffff
route add 192.168.200.0/24 192.168.200.1
Gateway B:
Public IP: 200.2.2.20
Private IP: 192.168.200.1/24
ifconfig gif0 create tunnel 200.2.2.20 100.1.1.10
ifconfig gif0 inet 192.168.200.1 192.168.100.1 netmask 0xffffffff
route add 192.168.100.0/24 192.168.100.1
嗯... 還有就是 gif0 的 MTU 問題, 這個要注意一下...
用 GIF 的 Tunnel Mode 可以把兩個 Intranet 串起來透過 Internet 互通, 這就是 IP VPN 啦. 如果加上 IPsec 等編碼, 就變成 Secure IP VPN 啦.
Gateway A:
Public IP: 100.1.1.10
Private IP: 192.168.100.1/24
ifconfig gif0 create tunnel 100.1.1.10 200.2.2.20
ifconfig gif0 inet 192.168.100.1 192.168.200.1 netmask 0xffffffff
route add 192.168.200.0/24 192.168.200.1
Gateway B:
Public IP: 200.2.2.20
Private IP: 192.168.200.1/24
ifconfig gif0 create tunnel 200.2.2.20 100.1.1.10
ifconfig gif0 inet 192.168.200.1 192.168.100.1 netmask 0xffffffff
route add 192.168.100.0/24 192.168.100.1
嗯... 還有就是 gif0 的 MTU 問題, 這個要注意一下...
Tuesday, September 6, 2005
Subscribe to:
Posts (Atom)