我在Flickr.com上面找到這一個比較清楚的圖. (右方, 點入放大).
最左方的 AUX 有其他功能我們先不看. 畫面中間左方網路孔 "10/100/1000 SW" 孔位是讓我們上鏈 (Uplink) 到交換器, 最右方網路孔 "10/100/1000 PC" 是讓我們接到座位的PC.
所以簡單地說, 典型的 Cisco IP 話機本身就包含一個兩埠的小交換器. 其中上鏈孔還必須以 Trunk 模式啟動, 因為同時要承載電話本身的封包(Voice VLAN), 和座位 PC 的流量 (沒有加標籤的原生VLAN, Native or Untagged VLAN).
2009年5月31日 星期日
2009年5月26日 星期二
為何 IP Multicast 位址的 MAC address 必須擠到23 位元裡面 ?
應該各位在讀到 BSCI 教材中, 有關 IP Multicast 位址要對應到適當的 MAC address 來傳送這段時, 都會注意到: 好麻煩喔, 為什麼要設計成這樣, 硬是將數目比較多的 IP Multicast 位址, 以 "32比1" 的方式, 擠到比較小的 MAC Address 範圍內? 而且還是僅保留低位元的 "後23位元" 這麼奇怪怪的數字, 害我們這麼辛苦, 要去記對照規則!
其實這是有一段小故事的!
據說當年 IP Multicast 之父 Steve Deering 在還是研究生的時候, 為了要實作 IP Multicast 的驗證雛型, 必然也需要專用的 MAC 位址來給 IP Multicast 封包, 在 LAN 上面傳輸時使用.
各位應該知道, IP Multicast 的位址範圍, 是在 224.0.0.0 ~ 239.255.255.255 間的 D 等級網段. 如果要讓每一個IP Multicast 位址都有專有的 MAC 位址, 一共需要 2^28 個 MAC 位址, 也就是, 需要 16 個 OUI 的範圍才夠.
我們從二進位來看, 就會比較清楚:
各位應該還記得我前一篇有關 MAC 位址的費用, 現在每一個 OUI 要 US$ 1,650, 當年要價也要 US$ 1,000. 換句話說, Steve 當年需要想辦法來支付 US$ 16,000 (相當於新台幣50多萬元) 給 IEEE, 才夠他完全的一對一來分配唯一的 MAC 位址給每個 IP Multicast 位址專用.
很不幸, 經費沒有那麼多, 只夠他申請一組 OUI, 也就是最多只有 2^24 個 MAC 可以使用. 這組得來不易的 OUI 當然也要省著用, 所以要先保留一個位元不能用, 所以只剩下 23 個位元, 也就是 2^23 個 MAC 位址才可以給 IP Multicast 位址使用.
這個當初 Steve 申請到的 OUI "01-00-5E" (註1), 就成了我們今天 IP Multicast 專用的 MAC 位址的 OUI !
所以各位看到訊框的目的地 MAC 位址, 都會長成這個模樣:
所以這個故事也讓我們學到一件事: 錢還是很重要的!
[參考資料]
註1: 比較正確一點地說, 應該 Steve 註冊到的 OUI 是 "00-00-5E" 才對. 但是載送 IP Multicast 封包的訊框上第一個 Octet 的 multicast bit 一定是打開的, 所以使用類似 Wireshark 看到的時候外觀都會是 "01-00-5E".
其實這是有一段小故事的!
據說當年 IP Multicast 之父 Steve Deering 在還是研究生的時候, 為了要實作 IP Multicast 的驗證雛型, 必然也需要專用的 MAC 位址來給 IP Multicast 封包, 在 LAN 上面傳輸時使用.
各位應該知道, IP Multicast 的位址範圍, 是在 224.0.0.0 ~ 239.255.255.255 間的 D 等級網段. 如果要讓每一個IP Multicast 位址都有專有的 MAC 位址, 一共需要 2^28 個 MAC 位址, 也就是, 需要 16 個 OUI 的範圍才夠.
我們從二進位來看, 就會比較清楚:
33 2 1 0
1098765.43210987.65432109.876543210
-------------------------------------
( 224 . 0 . 0 . 0 )
11100000.00000000.00000000.00000000
11101111.11111111.11111111.11111111
( 239 . 255 . 255 . 255 )
各位應該還記得我前一篇有關 MAC 位址的費用, 現在每一個 OUI 要 US$ 1,650, 當年要價也要 US$ 1,000. 換句話說, Steve 當年需要想辦法來支付 US$ 16,000 (相當於新台幣50多萬元) 給 IEEE, 才夠他完全的一對一來分配唯一的 MAC 位址給每個 IP Multicast 位址專用.
很不幸, 經費沒有那麼多, 只夠他申請一組 OUI, 也就是最多只有 2^24 個 MAC 可以使用. 這組得來不易的 OUI 當然也要省著用, 所以要先保留一個位元不能用, 所以只剩下 23 個位元, 也就是 2^23 個 MAC 位址才可以給 IP Multicast 位址使用.
這個當初 Steve 申請到的 OUI "01-00-5E" (註1), 就成了我們今天 IP Multicast 專用的 MAC 位址的 OUI !
所以各位看到訊框的目的地 MAC 位址, 都會長成這個模樣:
|< 23 bits >|
00000001-00000000-01011110-0XXXXXXX-XXXXXXXX-XXXXXXXX
01 - 00 - 5E -(00~7F) -(00~FF) - (00~FF)
所以這個故事也讓我們學到一件事: 錢還是很重要的!
[參考資料]
- InformIT: Interdomain Multicast Fundamentals > Multicast on the LAN
- Page 31 of Book "Developing IP Multicast Networks", by Beau Williamson
註1: 比較正確一點地說, 應該 Steve 註冊到的 OUI 是 "00-00-5E" 才對. 但是載送 IP Multicast 封包的訊框上第一個 Octet 的 multicast bit 一定是打開的, 所以使用類似 Wireshark 看到的時候外觀都會是 "01-00-5E".
2009年5月22日 星期五
IEEE OUI 和 IAB的註冊費用
相關文章：
快速參考,
MAC Address
IAB (Individual Address Block) 簡單的講起來, 相當於是個人或是小團體可以負擔得起的, 除了OUI以外的申請全球唯一的 MAC Address 的方式.
當然價格便宜的話, 可用的位址一定比較少. 沒錯, IAB 你只有 12 位元可以自由使用, 所以一共是 4096 個 MAC Address 可用.
OUI 則有 24 個位元可以自由使用, 所以一共是大約一千六百多萬個位址可用.
如下圖所示, IAB 註冊費是 US$ 550, OUI 是 US$ 1,650. 雖然還是所費不貲, 不過好消息是沒有年費! 所以可以終身使用!
從這個圖我們還看到了連訊框中的 16位元的 EtherType 都可以付費買下, 只不過稍微貴了一點: US$ 2,500.
當然價格便宜的話, 可用的位址一定比較少. 沒錯, IAB 你只有 12 位元可以自由使用, 所以一共是 4096 個 MAC Address 可用.
OUI 則有 24 個位元可以自由使用, 所以一共是大約一千六百多萬個位址可用.
如下圖所示, IAB 註冊費是 US$ 550, OUI 是 US$ 1,650. 雖然還是所費不貲, 不過好消息是沒有年費! 所以可以終身使用!
http://standards.ieee.org/faqs/OUI.html#q2
What costs are involved with obtaining an OUI, IAB or EtherType Field?
The OUI is $1,650.00 (US); the IAB is $550.00 (US) and the EtherType Field is $2,500.00 (US). The only other fees that would be involved is a $15.00 bank fee that is only applicable with the wire transfer payment method and a fee for private status on the public listing. There are no annual fees.
從這個圖我們還看到了連訊框中的 16位元的 EtherType 都可以付費買下, 只不過稍微貴了一點: US$ 2,500.
2009年5月21日 星期四
Wireshark 怎麼知道訊框是由哪一廠牌的網卡送出?
相關文章：
快速參考,
MAC Address
關鍵就在於, MAC Address 並不是可以隨便用的, 而是要統一跟 IEEE 申請繳費的. 各位應該都還記得, 48位元的 MAC Address 當中, 從高位元數下來的前 24 位元是所謂的組織唯一識別碼 (Organizationally Unique Identifier, OUI). 這個數值是就是由 IEEE 配發的. 至於剩下的其他 24 位元, 才是由廠商自己分配.
所以, Wireshark 這種 "封包擷取軟體" 裡面其實就是參考了這樣的對照表, 所以一收到訊框, 查完前 24 位元, 馬上就知道是哪家廠牌製造的.
那麼這個對照表要去哪裡下載或是查詢? 其實就在 IEEE 的網站當中.
[Wireshark (就是以前的 Ethereal) 參考資訊]
所以, Wireshark 這種 "封包擷取軟體" 裡面其實就是參考了這樣的對照表, 所以一收到訊框, 查完前 24 位元, 馬上就知道是哪家廠牌製造的.
那麼這個對照表要去哪裡下載或是查詢? 其實就在 IEEE 的網站當中.
- IEEE OUI 查詢主頁面: http://standards.ieee.org/regauth/oui/index.shtml
- IEEE OUI 完整對照表下載: 在前述頁面的一個連結: http://standards.ieee.org/regauth/oui/oui.txt
[Wireshark (就是以前的 Ethereal) 參考資訊]
- Wireshark 官方網站: http://www.wireshark.org/
- 其他人寫的 Wireshark 華語說明文章: http://blog.shaolin.tw/2008/03/wireshark.html
2009年5月20日 星期三
Wireless LAN 佈建方式補充說明
雖然 "Cisco 網路學院" 的教材裡面, 例子中使用的是 Cisco Linksys 這種個人使用的 Wireless LAN 接入點 (Access Point). 實務上, 如果當你的 Wireless LAN 到了一定的規模, 通常的作法是改用集中式管理 (centralized management) 的, 或 Cisco 所稱呼的輕薄型接入點 (Thin AP) 功能的產品.
這種新的的 AP 架構, 關鍵在於"集中式管理". 我們不再需要一台一台 AP 去維護設定, 僅需要在集中控管的"控制器"(Wireless LAN Controller) 上設定好, 所有的 AP 一開機就自動註冊到控制器, 然後由控制器端完全遙控 AP 的動作.
說遙控可是一點都不誇張, 因為所有 AP 動作都透過 IP 網路聽命於控制器, 這個時候 AP 變成是 "沒有大腦的遠端 Wireless LAN 網路卡", 控制器才是所有功能的核心. 在這樣的架構下, AP 不能單獨運作, 一定要搭配控制器才能動作.
我們可以類比想像, 就好像一個主人(控制器) 同時在放好多風箏 (AP) 一樣. 風箏 (AP) 要飛高飛低是完全受主人(控制器)的大腦在遙控. 在所以 Cisco 稱呼他是輕薄型接入點設計, 就是要強調這一點.
所以這種架構, AP 不能單獨運作, 一定要搭配控制器. 通常為了備援, 控制器都是兩套以上.
至於 "一定的規模" 應該有多大, 就應該改考慮使用新架構? 我個人的建議是 兩台 以上. 要不然, 通常的經驗就都會 "一路錯下去": 因為 Thin AP 價格真的不菲, 是一般 AP 的 10 倍以上的價格! 但是效益要等到開始用(管理), 才發揮得出來!
[參考資料]
http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_9-3/wireless_lan_switches.html
這種新的的 AP 架構, 關鍵在於"集中式管理". 我們不再需要一台一台 AP 去維護設定, 僅需要在集中控管的"控制器"(Wireless LAN Controller) 上設定好, 所有的 AP 一開機就自動註冊到控制器, 然後由控制器端完全遙控 AP 的動作.
說遙控可是一點都不誇張, 因為所有 AP 動作都透過 IP 網路聽命於控制器, 這個時候 AP 變成是 "沒有大腦的遠端 Wireless LAN 網路卡", 控制器才是所有功能的核心. 在這樣的架構下, AP 不能單獨運作, 一定要搭配控制器才能動作.
我們可以類比想像, 就好像一個主人(控制器) 同時在放好多風箏 (AP) 一樣. 風箏 (AP) 要飛高飛低是完全受主人(控制器)的大腦在遙控. 在所以 Cisco 稱呼他是輕薄型接入點設計, 就是要強調這一點.
所以這種架構, AP 不能單獨運作, 一定要搭配控制器. 通常為了備援, 控制器都是兩套以上.
至於 "一定的規模" 應該有多大, 就應該改考慮使用新架構? 我個人的建議是 兩台 以上. 要不然, 通常的經驗就都會 "一路錯下去": 因為 Thin AP 價格真的不菲, 是一般 AP 的 10 倍以上的價格! 但是效益要等到開始用(管理), 才發揮得出來!
[參考資料]
http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_9-3/wireless_lan_switches.html
2009年5月19日 星期二
使用者端的 Redundancy: Wireless LAN. 備援 Internet 完整版
延續前一篇, 知道解法了嗎?
關鍵也是更精準的路由資訊 (more specific route): 只要比 "預設路由" 還要更精準就可以了! 其實預設路由是 "最不精準的" (least specific), 即使只要多精準一個位元就好, 不就比她還要精準了嗎!
---
公布答案了: 就是再加上 0.0.0.0/1 和 128.0.0.0/1 這兩筆路由, 將它們都指向有線 LAN 網段的閘道器 IP 位址即可! 所以 Internet 的連線也一樣會先走有線的 LAN, 斷線後才走 Wireless LAN!
用十進位不容易看出來, 改用二進位就很清楚:
當然, 相同的想法, 也可以拆成四個路由, 八個路由等等, 所以答案不只這一組. 但是兩個是最簡單的!
有一點腦筋急轉彎, 不過這招真的很好用!
關鍵也是更精準的路由資訊 (more specific route): 只要比 "預設路由" 還要更精準就可以了! 其實預設路由是 "最不精準的" (least specific), 即使只要多精準一個位元就好, 不就比她還要精準了嗎!
---
公布答案了: 就是再加上 0.0.0.0/1 和 128.0.0.0/1 這兩筆路由, 將它們都指向有線 LAN 網段的閘道器 IP 位址即可! 所以 Internet 的連線也一樣會先走有線的 LAN, 斷線後才走 Wireless LAN!
用十進位不容易看出來, 改用二進位就很清楚:
33 2 1 0 33 2 1 0
1098765.43210987.65432109.876543210 1098765.43210987.65432109.876543210
00000000.00000000.00000000.00000000, mask 10000000.00000000.00000000.00000000
10000000.00000000.00000000.00000000, mask 10000000.00000000.00000000.00000000
當然, 相同的想法, 也可以拆成四個路由, 八個路由等等, 所以答案不只這一組. 但是兩個是最簡單的!
有一點腦筋急轉彎, 不過這招真的很好用!
2009年5月17日 星期日
使用者端的 Redundancy: Wireless LAN
使用者端使用 Wireless LAN 有一個最不可取代的好處, 是一般的有線的 (Wired) LAN 完全作不到的, 就是全自動復原的功能! Windows 會自動去找下一個可以使用的 Wireless LAN 接入點 (Access Point)! 所以是可以做到讓使用者完全感受不到網路斷線的問題!
不過, Wireless LAN 即便是現有的技術, 還是有著頻寬不足的問題, 尤其是當使用者非常密集地坐在一起, 每一位都需要大量資料傳輸的時候! 如果使用者端只使用 Wireless LAN, 碰上了這種環境, 就會有被抱怨的風險! 這將會是網管人員的惡夢!
所以另外一種做法, 是做將 Wireless LAN 當作有線 LAN 的備援來使用. 這樣倒是可以兩者兼顧, 平常都使用有線的 LAN 網路傳資料, Switch 故障時再讓使用者端使用 Wireless LAN 上網, 當然故障的時候網路還是會慢一點, 但是至少不會全斷!
可是能做到自動切換嗎? 可以的, 但是要使用一點路由資訊的小技巧! 假設公司內部都是 192.168.0.0/16 範圍內的網段. 首先將有線和 Wireless LAN 分配成不同的 IP 網段. Windows 這端的設定, 就必須是 "192.168.0.0/255.255.0.0" 路由指向有線的 LAN 網段閘道器 IP 位址; 然後將 Windows 的預設路由 (Default route) 指向 Wireless LAN 網段的閘道器 IP 位址.
看出關鍵了吧! 因為 192.168.0.0/16 是更精準的路由資訊 (more specific route), 所以平常都會走有線的 LAN, 直到 Switch 故障的時候, 才改透過預設路由走 Wireless LAN, 完成全自動切換.
應該有很多 "自動的方式" 可以將以上兩個路由分開, 可以用 Windows 本身的群組規則 (Windows AD Group Policy) 可以做到; 簡單一點的話, 其實 DHCP 就可以了!
以上的做法可以解決 Intranet 自動備援的問題. 一定有朋友想到了, 如果還要同時做到上 Internet 也是自動備援呢?
先賣個關子, 下一篇再聊!
不過, Wireless LAN 即便是現有的技術, 還是有著頻寬不足的問題, 尤其是當使用者非常密集地坐在一起, 每一位都需要大量資料傳輸的時候! 如果使用者端只使用 Wireless LAN, 碰上了這種環境, 就會有被抱怨的風險! 這將會是網管人員的惡夢!
所以另外一種做法, 是做將 Wireless LAN 當作有線 LAN 的備援來使用. 這樣倒是可以兩者兼顧, 平常都使用有線的 LAN 網路傳資料, Switch 故障時再讓使用者端使用 Wireless LAN 上網, 當然故障的時候網路還是會慢一點, 但是至少不會全斷!
可是能做到自動切換嗎? 可以的, 但是要使用一點路由資訊的小技巧! 假設公司內部都是 192.168.0.0/16 範圍內的網段. 首先將有線和 Wireless LAN 分配成不同的 IP 網段. Windows 這端的設定, 就必須是 "192.168.0.0/255.255.0.0" 路由指向有線的 LAN 網段閘道器 IP 位址; 然後將 Windows 的預設路由 (Default route) 指向 Wireless LAN 網段的閘道器 IP 位址.
看出關鍵了吧! 因為 192.168.0.0/16 是更精準的路由資訊 (more specific route), 所以平常都會走有線的 LAN, 直到 Switch 故障的時候, 才改透過預設路由走 Wireless LAN, 完成全自動切換.
應該有很多 "自動的方式" 可以將以上兩個路由分開, 可以用 Windows 本身的群組規則 (Windows AD Group Policy) 可以做到; 簡單一點的話, 其實 DHCP 就可以了!
以上的做法可以解決 Intranet 自動備援的問題. 一定有朋友想到了, 如果還要同時做到上 Internet 也是自動備援呢?
先賣個關子, 下一篇再聊!
2009年5月15日 星期五
Redundancy: 我也上了一課
相關文章：
備援設計
應該很多朋友已經注意到, 本站的有些 .PKT 檔案和圖檔, 這一兩天沒有辦法下載. 這是因為我部分的內容是放在外面 (而且唯一) 的一家 Web Hosting 公司的伺服器上. 他們目前已經停機超過 24 小時了!
在此要跟各位說聲抱歉! 因為的確有些重要檔案我沒有備份, 所以部分內容可能還要更久才能回復.
平常都是我在教別人, 結果我對我自己網站的內容並沒有遵守相同的紀律. 這次的事件給我自己也好好地上了一課!
在此要跟各位說聲抱歉! 因為的確有些重要檔案我沒有備份, 所以部分內容可能還要更久才能回復.
平常都是我在教別人, 結果我對我自己網站的內容並沒有遵守相同的紀律. 這次的事件給我自己也好好地上了一課!
2009年5月14日 星期四
有必要如此生氣嗎?
我在 Mobile01 看到一群人在討論, 標題是 "我受夠了!!!為了看網路電視別人的權益都不管了嗎?", 整個故事的背景是有人在抱怨, 幾位室友分租上 Internet 的線路, 但是老是有室友不合作, 執行網路電視的軟體或 P2P 軟體, 讓大家上網都很慢. 然後有些熱情的網友就開始提供一些奇怪的方法, 有些甚至是違法的行為 (請勿模仿, 公共危險罪可是公訴罪) 來讓這位不合作的室友停止這種行為.
其實他們的討論是多餘的, 安裝一部 Cisco Router 就可以輕易的達成 "每個室友頻寬使用量鎖定" 的目標.
(當然, 有些國產品牌的寬頻分享器也有這種功能, 我先將焦點放在 Cisco 產品的技術上.)
各位可以使用 Cisco 新的 "模組化品質管制服務設定介面" (Modular QoS CLI, MQC) 來完成, 以下是設定的範例:
當然以上的例子, 在我們的 ICND 課程當中是沒有的, 這算是 QoS 課程的內容才會提到!
其實他們的討論是多餘的, 安裝一部 Cisco Router 就可以輕易的達成 "每個室友頻寬使用量鎖定" 的目標.
(當然, 有些國產品牌的寬頻分享器也有這種功能, 我先將焦點放在 Cisco 產品的技術上.)
各位可以使用 Cisco 新的 "模組化品質管制服務設定介面" (Modular QoS CLI, MQC) 來完成, 以下是設定的範例:
!
! 對每位室友設定 IP 位址辨認條件, 我先假設就兩位室友
!
access-list 101 permit ip host 192.168.1.1 any
access-list 102 permit ip host 192.168.1.2 any
access-list 111 permit ip any host 192.168.1.1
access-list 112 permit ip any host 192.168.1.2
!
! 定義類別, 分上下行
!
class-map Roommate1-Up
match access-group 101
class-map Roommate2-Up
match access-group 102
class-map Roommate1-Down
match access-group 111
class-map Roommate2-Down
match access-group 112
!
! 組合成一套品質服務內容 (policy-map)
! 我先假設下行給 500K, 上行給200K. "police" 命令的單位是bps.
!
policy-map Up
class Roommate1-Up
police 200000 conform-action transmit exceed-action drop
class Roommate2-Up
police 200000 conform-action transmit exceed-action drop
policy-map Down
class Roommate1-Down
police 500000 conform-action transmit exceed-action drop
class Roommate2-Down
police 500000 conform-action transmit exceed-action drop
!
! 將品質服務內容套用在網路卡上
!
int f0/0
ip address 192.168.1.254 255.255.255.0
service-policy input Up
service-policy output Down
當然以上的例子, 在我們的 ICND 課程當中是沒有的, 這算是 QoS 課程的內容才會提到!
2009年5月12日 星期二
備援的重要性 - 從捷運看網路設計
就在今天早上上班的尖峰時間, 我經過 "捷運台北車站", 看到直通的第二層淡水/新店線月台的電扶梯故障了! 一群工作人員正緊急搶修中! 我相信今天有不少人都有目睹到這一幕! 還好的是, 還有樓梯可以走, 還有另外一條電扶梯也可以到, 所以即使是最快的這條路斷了, 經過工作人員的疏導, 乘客的影響並不大!
想像一下, 假設當初設計 "捷運台北站" 的工程師, 所有通道都只有一條路, 結果遇到了今天的狀況發生, 那就變成所有的乘客都沒辦法在尖峰時間進入到淡水/新店線月台! 我相信引來的抱怨聲浪, 肯定是會上報紙的!
我們在規劃網路建置時, 一定都要包含到多重備援路徑! 沒有單一線路是永遠不會斷的! 避開單點故障全系統故障 (Single Point of Failure) 的設計, 絕對會讓各位的網路工作和生活過得更平安一點!
想像一下, 假設當初設計 "捷運台北站" 的工程師, 所有通道都只有一條路, 結果遇到了今天的狀況發生, 那就變成所有的乘客都沒辦法在尖峰時間進入到淡水/新店線月台! 我相信引來的抱怨聲浪, 肯定是會上報紙的!
我們在規劃網路建置時, 一定都要包含到多重備援路徑! 沒有單一線路是永遠不會斷的! 避開單點故障全系統故障 (Single Point of Failure) 的設計, 絕對會讓各位的網路工作和生活過得更平安一點!
我將上課補充的 Packet Tracer 檔案文章, 整理在右邊第二版面當中
(Jan 6, 2012 更正: 已經搬到畫面的正下方! 歡迎繼續多加利用！)
相信眼尖的朋友已經注意到了! 怕大家沒有看到, 還是多提醒一下!
這些檔案是我在教 Cisco 網路學院班時做給學生練習用的, 我相信對其他的朋友, 甚至是老師, 也許多少有些幫助, 所以乾脆整理清楚一點, 方便大家隨時點選!
歡迎大家多多利用, 也請多批評指教!
相信眼尖的朋友已經注意到了! 怕大家沒有看到, 還是多提醒一下!
這些檔案是我在教 Cisco 網路學院班時做給學生練習用的, 我相信對其他的朋友, 甚至是老師, 也許多少有些幫助, 所以乾脆整理清楚一點, 方便大家隨時點選!
歡迎大家多多利用, 也請多批評指教!
2009年5月11日 星期一
Fw: 在職學習高手—交大計算機與網路中心組長高義智
「學習永無止盡，對我來說，是一件最快樂的事！」
很榮幸有機會跟這位前輩高義智 (Patrick) 一起在 HP 當過近兩年的同事, 他是我 HP 的入行指導師 (Mentor), 我從他哪裡學到非常多的事情. 我後來會進入 "Cisco 教學領域", 也是經由他的牽線而促成的. 他真的是我的貴人!
記者的這篇報導, 描述得一點都不誇張, 他真的是證照一張接著一張考到, 學位也是拿完一個又一個的!
至於記者提到的那個大型連鎖超商客戶, 是我所遇過的客戶裡面最難應付的, 但是只有他"罩"得住! 只要他一出面, 客戶就都沒問題了! 不只這個, 很多客戶即使遠在新竹, 台中, 甚至高雄, 他也常常是一通電話, 就 "飛" 下去順利解決!
很傳奇的人物吧! 話不多說, 就讓各位自己看看吧! (一共四頁, 要看完喔!)
在職學習高手—交大計算機與網路中心組長高義智
撰文◎李翠卿 攝影◎葉俊嘉 2008-11-04
【Career職場情報誌】第391期
2009年5月9日 星期六
2009年5月7日 星期四
2009年5月6日 星期三
"H1N1" 來襲時, 你和你的公司都做好準備了嗎?
相關文章：
評論
當年 SARS 來襲時, 如果有人疑似感染, 整個辦公室的人員都必須在家裡或是就地隔離. 當時的政府想到了 "第二辦公室" 的概念: 也就是說, 人員和正副主管是分散在兩個(或以上)的辦公室中辦公, 才不會只因一個員工感染, 唯一的那個辦公室就完全不能辦公.
"H1N1" 也許不久後就會跟當年的 SARS 一樣散布開來. 我們 "網路人" 在這個時候, 有甚麼工作, 是現在就可以做的? 我這裡提幾個建議, 是各公司可以立刻努力的方向:
(1) 建立第二辦公室. 模仿一下政府的作法, 這是很有效的. Intranet 建立不困難, Internet 的應用可能就比較複雜, 甚至可能需要修改軟體. 如果過去就有第二辦公室的朋友, 就趕快做一下演習吧! 你應該會需要新的路由器, 交換器, 申請新的線路, 或是需要 "跨據點負載平衡器" 來完成這些功能.
(2) 機房無人化. 機器並不會感染 "H1N1", 如果可以讓你機房裡面的各種有形或無形的 "資訊資產", 透過 "網路" 就可以存取和管理, 那即使在家自我隔離的同事, 都還可以連進來辦公. 你應該會需要 SSL VPN 閘道器, 管理軟體, 遠端桌面工作軟體.
(3) 視訊會議與協同作業平台. 通常分離兩地的正副主管和員工間, 特別需要這個服務來開會溝通. 你應該會需要視訊會議的設備, IP語音通訊軟硬體, 和協同作業平台系統.
(4) 非主要系統透過 Internet 委外. 例如有些公司的 Email 系統, 教育訓練系統, 差勤公文系統等比較沒有資料外洩的顧慮的 那就讓它們都 Internet 化吧! 很多公司, 甚至外國公司, 都可以提供相對應的委外服務. 其實這樣的做法, 就是最近很熱門的 "雲端運算" (Cloud Computing) 概念的實踐!
希望 "H1N1" 並不會擴散開來, 但是 "網路人" 還是趕快要做好準備, 不幸真的來了, 就不會束手無策!
"H1N1" 也許不久後就會跟當年的 SARS 一樣散布開來. 我們 "網路人" 在這個時候, 有甚麼工作, 是現在就可以做的? 我這裡提幾個建議, 是各公司可以立刻努力的方向:
(1) 建立第二辦公室. 模仿一下政府的作法, 這是很有效的. Intranet 建立不困難, Internet 的應用可能就比較複雜, 甚至可能需要修改軟體. 如果過去就有第二辦公室的朋友, 就趕快做一下演習吧! 你應該會需要新的路由器, 交換器, 申請新的線路, 或是需要 "跨據點負載平衡器" 來完成這些功能.
(2) 機房無人化. 機器並不會感染 "H1N1", 如果可以讓你機房裡面的各種有形或無形的 "資訊資產", 透過 "網路" 就可以存取和管理, 那即使在家自我隔離的同事, 都還可以連進來辦公. 你應該會需要 SSL VPN 閘道器, 管理軟體, 遠端桌面工作軟體.
(3) 視訊會議與協同作業平台. 通常分離兩地的正副主管和員工間, 特別需要這個服務來開會溝通. 你應該會需要視訊會議的設備, IP語音通訊軟硬體, 和協同作業平台系統.
(4) 非主要系統透過 Internet 委外. 例如有些公司的 Email 系統, 教育訓練系統, 差勤公文系統等比較沒有資料外洩的顧慮的 那就讓它們都 Internet 化吧! 很多公司, 甚至外國公司, 都可以提供相對應的委外服務. 其實這樣的做法, 就是最近很熱門的 "雲端運算" (Cloud Computing) 概念的實踐!
希望 "H1N1" 並不會擴散開來, 但是 "網路人" 還是趕快要做好準備, 不幸真的來了, 就不會束手無策!
2009年5月4日 星期一
第五屆華陀盃網路技能競賽開始受理報名
我今天收到 Cris 的 Email. 歡迎大家踴躍報名參加!
主旨: 第五屆華陀盃網路技能競賽開始受理報名
網路遨遊探資訊 疑難排解論英雄第五屆華陀盃網路技能競賽正式開跑!!歡迎老師帶隊與學生共同探索網路世界的各項驚奇與挑戰即日起接受報名.報名網址:http://catc.nctu.edu.tw/contest2009/ 報名時間及方式：即日起至98年7月10日止，請至活動網址報名報名資格：97學年度在學或應屆畢業之大專院校學生,兩人為一組報名費用 : 思科網路學會會員學校每組600元,非學會學校每組800元(比賽當日現場繳交,現場開立收據,費用內含每人午餐,T-Shirt乙件,及當日安全保險費用) 比賽日期：98年7月17日（星期五）比賽地點: 中國文化大學推廣教育部(台北市建國南路二段231號)競賽方式: 初賽：線上問答、現場搶答、 Packet Tracer模擬軟體解題競賽決賽：LAB實機操作競賽（依初賽成績評選10組隊伍進入決賽）本競賽冠軍隊伍將代表台灣參加思科網路學會亞太區網路技能競賽，與其他國家菁英一較高下,為國爭光！！ 獎項說明: 冠軍隊伍將獲頒獎狀及15,000元獎金亞軍及季軍隊伍將獲頒獎狀及獎金其他入選決賽之隊伍將獲頒獎狀及禮卷主辦單位：中國文化大學／國立交通大學協辦單位：台灣思科系統股份有限公司／ 台灣思科網路學會議評會／思科網路學會贊助單位：麟瑞科技股份有限公司／Training Partners認證學院對活動有任何建議請洽中國文化大學林老師 (pclin@sce.pccu.edu.tw)及思科網路學會Cris (crichin@cisco.com)
Cisco IOS Router/Switch 使用 TELNET 備份設定
使用 HyperTerminal 在 Console 上備份設定, 上課一定都有練習過. 不過日常的網路維護, 反倒是很難有機會使用 Console: 因為 Router/Switch 通常都鎖在 "遠處, 門禁森嚴" 的機房中.
我常用一個小技巧, 只可惜這招只能在 Windows XP 上使用.
其中 "log-file.txt" 就是畫面記錄檔的名稱. "192.168.1.1" 就是你的 Router 或 Switch 的 IP 位址. 接下來應該如何各位應該就很熟練了!
各位應該還記得要將終端機行數 (length) 設成是 0, 意思就是不要有 "--- MORE ---" 分頁的功能!
我常用一個小技巧, 只可惜這招只能在 Windows XP 上使用.
TELNET -F log-file.txt 192.168.1.1
其中 "log-file.txt" 就是畫面記錄檔的名稱. "192.168.1.1" 就是你的 Router 或 Switch 的 IP 位址. 接下來應該如何各位應該就很熟練了!
enable
terminal length 0
show run
show start
各位應該還記得要將終端機行數 (length) 設成是 0, 意思就是不要有 "--- MORE ---" 分頁的功能!
2009年5月1日 星期五
如何搜尋本站張貼的內容當中, 有提到 "OSPF" 的文章?
搜尋結果, 請注意會出現下面的這個畫面, 代表是搜尋結果:
請注意, 這時候 "網址列" 變成是這樣:
http://showipprotocols-tw.blogspot.com/search?q=ospf
這樣大家應該就看得出規則來了!
所以, 如果習慣在瀏覽器的網址列直接下命令的話, 就可以用 "/search?q=關鍵字" 的方式來搜尋了!
如果各位比較習慣使用 Google.com 搜尋的話, 也是可以的, 請在關鍵字後面, 多加上 "site:showipprotocols-tw.blogspot.com" 的方式即可. 不過, Google.com 的資訊會比各位直接在 Blogger.com 上搜尋出來的結果, 內容會稍微不即時一些.
http://www.google.com/search?q=ospf+site:showipprotocols-tw.blogspot.com
另外要請大家注意: 以上方法這個方法, 都只能搜尋本站內部的內容. 至於進一步的搜尋方式, 留待下次在聊了!
訂閱：
文章 (Atom)
經典熱門文章
-
Bits per sec : 9600 Data bits : 8 Parity : none Stop bits : 1 Flow control : none 我們以往在作Router... -
我剛才在讀 網路文章 的時候，我才發現，原來Google也有對外服務的NTP伺服器，網址分別有五個： TIME.google.com TIME1.google.com TIME2.google.com TIME3.google.com TIME4.google.... -
TFTP Server 是我們平常在維護網路必備的工具之一. 我們需要 TFTP Server 來備份/安裝 IOS 映像檔, 與設定內容. Cisco 原本曾經有過一個免費的 TFTP Server 軟體, 不過已經停止它的後續的開發和維護. 反而在 Cisco 網站當中 ...
-
應該各位在讀到 BSCI 教材中, 有關 IP Multicast 位址要對應到適當的 MAC address 來傳送這段時, 都會注意到: 好麻煩喔, 為什麼要設計成這樣, 硬是將數目比較多的 IP Multicast 位址, 以 "32比1" 的方式, 擠...
-
我先花一點時間，聊一聊Spine/Leaf網路拓樸。 Spine/Leaf 是一種網路拓樸 Spine/Leaf 示意圖。 來源： Cisco.com ，"Figure 1. Cisco Dynamic Fabric Automation Archit...