CM+IP分享器常斷線?


頁 : [1] 2 3 4

LeeFred
2004-05-22, 08:09 PM
raytracy 大大您好,小弟在此想請教你有關本人使用CABLE MODEM的一個問題

我使用的是新竹(光復路上)的東森CABLE (我的CABLE MODEM是MOTOROLA銀色機子) 自從我接了IP分享器以後,大約3~5天會斷線一次,斷線後須把CABLE MODEM電源重新啟動,才能夠正常上網,這問題已經困擾我很久了,不知道是什麼原因讓CABLE會經常斷線?

我已經確定我的IP分享器沒有問題,因為我已經換了3台來測試過,隔幾天都會固定斷線。

過熱這個問題應該是不太可能,因為MODEM斷線時,機體本身溫度還好。

不知道有什麼其他因素會導致經常斷線? 煩請賜教,謝謝。

raytracy
2004-05-23, 04:39 PM
最初由 LeeFred 發表
自從我接了IP分享器以後,大約3~5天會斷線一次,斷線後須把CABLE MODEM電源重新啟動,才能夠正常上網,這問題已經困擾我很久了,不知道是什麼原因讓CABLE會經常斷線?

抱歉, 回信晚了. IP分享器的問題其實蠻多型態的, 雖然您已經做了一些判斷, 但我還是需要您協助提供更進一步的訊息來診斷:

1. 問題發生時, 若將分享器關機1分鐘後重開, 是否可恢復?
2. 問題發生時, 若將所有電腦關機5分鐘再開, 是否可恢復?
3. 問題發生時, CM 上的燈號會出現什麼樣的狀態?
4. 問題發生時, 若拔除分享器, 直接將電腦接上CM, 可否上網?
(作此步驟需注意, 電腦接上CM之後, 電腦必須重開一次, 結果才會正確)
5. 若第4.點結果無法上網, 用IE看http://192.168.100.1 是否有反應?
6. 問題發生時, 請在電腦上用 docsdiag 讀出 CM 當時的 Log 內容
(docsdiag 安裝方法請參閱 http://forum.raytracy.com/viewtopic.php?t=2 , 讀 Log 時需在後面另加上 -v -log 的參數)
7. 問題發生時, 記錄下當時每部電腦上, 正在執行的軟體.

在問題發生時, 執行以上各點時, 可以依序做下來, 但都不要重開CM, 讓CM保持在問題的狀態中, 才能找出問題. 如果能提供第6,7兩點的結果給我, 會比較容易判斷. 另, 很重要一點: 務必記下您發生問題, 或做這些步驟的時間!!

我們要追查的方向有三個: CM, IP分享器, 電腦軟體. 但就您先前的描述, 暫時還無法以科學的分析, 判斷出任何一個方向. 請您提供更詳細的資料, 小弟一定盡力協助.

raytracy
2004-05-26, 09:31 AM
最初由 可愛滴小玉 發表
一、請問一下CM&IP分享器&網卡&實體線路&機房就大大的了解那一種是常斷線的主因?
(節省版面, 我只引第一段, 其他請網友自行對照)

1. 機房與實體最常遇到, 分享器次之, CM及網卡最少

2. 您是管機房的? ;) Firewall擋ICMP不會發生這種現象, 您的狀況明顯與IP分享器有關. 當時您若有在使用 P2P 類型的軟體, 就可能造成分享器當機 (不是過熱, 是分享器的Session數不夠, 像D-LINK只能處理1024 Session, 但P2P開了幾天之後, 通常會產生一兩萬個Session), 此外, 病毒發動攻擊時也會因為 Session 數過高, 造成分享器當機.

3. 您所描述的現象, 比較傾向是HFC的問題. CM只要燈號不正常, 99%是HFC訊號出問題(除了CM自己壞掉 :D). 此時最重要的, 就是在用戶端立刻用 docsdiag 程式, 將 CM 上的數據通通抓下來, 供事後比對分析.

4. Lag 問題種類很多, 假設排除連外的部份, 只討論自家網路內部的話:
a. 上行客戶數過多 (單一上行超過200戶)
b. 上行頻寬滿載 (平均流量超過 70%)
c. 上行電磁突波雜訊干擾 (通常會有固定的時間性)
d. 用戶IP遭到蠕蟲病毒(WORM)的連續攻擊 (像Sasser, 疾風)
e. CMTS 的 CPU Loading 滿載 (尖峰超過 80%)
f. Router 的 CPU Loading 滿載 (尖峰超過 80%)
g. 下行頻寬滿載 (平均流量超過90%, 或單一下行超過800戶)
h. BER 過高 (用docsdiag會看到uncorrectable error持續增加)
i. IP分享器效能不佳
j. 用戶電腦遭病毒感染, 持續對外攻擊, 佔用CM上行頻寬
k. 用戶使用Game外掛程式, 被 Game Server 擋掉

單純的 Ping 很難測出連線品質, 不過可以在用戶端用Windows, 採電總標準做初步判斷:

ping -l 1024 -w 100 -n 1000 <CMTS IP>

(這會Ping很久喔, 十幾分鐘...;D)
結果不應該超過 5 個 packet lost. 如果用戶端可以接上 Linux 電腦的話, 改用下面這個會比較準:

ping -q -n -s 100 -A -c 1000 <CMTS IP>

(不加 -q 可以看到過程, 加了就只看結果) 但上面這個要注意: 結果所顯示的 max 值不能超過 100ms, 同時也不能超過 3 個以上的 packet lost (凡看到任何超過 100ms 的封包, 都要另外算成 lost). 在網咖中跑這個測試的標準是不能有任何的 packet lost.

只要測出超過標準的結果, 就要強烈懷疑是上面 4.a~4.k 其中任何一點所造成. 通常 ping 不需要測到 Game server 端, 除非懷疑中間路由上的某個設備有問題, 否則是 CMTS 到 CM 中間的問題最多.

可愛滴小玉
2004-05-26, 09:52 AM
只開一個看股軟體

剛剛下ping -l 1024 -w 100 -n 1000 168.95.1.1

Ping statistics for 168.95.1.1:
Packets: Sent = 64, Received = 62, Lost = 2 (3% loss),
Approximate round trip times in milli-seconds:
Minimum = 119ms, Maximum = 162ms, Average = 133ms

若是ping 168.95.1.1 -t
Ping statistics for 168.95.1.1:
Packets: Sent = 67, Received = 67, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 48ms, Maximum = 99ms, Average = 58ms

不才的我再請教一個問題分享器的Session數怎麼看?

raytracy
2004-05-26, 10:02 AM
最初由 可愛滴小玉 發表
只開一個看股軟體
剛剛下ping -l 1024 -w 100 -n 1000 168.95.1.1

Ping statistics for 168.95.1.1:
Packets: Sent = 64, Received = 62, Lost = 2 (3% loss),
Approximate round trip times in milli-seconds:
Minimum = 119ms, Maximum = 162ms, Average = 133ms

以上我說的測試, 必須是在「沒有任何流量」下測, 否則結果不正確, 所以您不需要執行任何軟體. 另外, 該測試是針對 CMTS與CM, 超過CMTS的範圍就沒有意義. 所以不需要測到 168.95.1.1 去....:D
但您的測試有個疑問: 怎麼會只有 Sent=64, Received=62 呢? 我們是下了 -n 1000 的參數, 至少 Sent= 應該要等於 1000 才對? 還是您中途把它停掉了?

不才的我再請教一個問題分享器的Session數怎麼看?
線上即時的Session數通常在管理介面裡看不到, 只能看他的產品包裝外面有沒有寫? 不過, 大部分也都沒有寫....:corkysm:
PCZONE 有網友實測過各種品牌, 用在 P2P 會當機的有:
====================================
DLINK 7票 (主要是704,除了當機外,包含進不了設定頁面)
友旺 2票 (包含幫聯強代工的CAS系列)
PCI 4票 (主要是4FM,新推出的04AR也有人講了 其他討論串可以找到更多受害者)
技嘉BR401 1票 不知道是誰做的,有可能是技嘉自己生產的
=====================================
至於不會當機的, 則有 SMC 和 VIGOR 兩種. 但據說不會當機的, 都賣得很貴...:D

(後記: 不過, 昨天聽我們技術部門說, SMC 也測出有當機的紀錄, 但不知是否舊型號)

xliang
2004-05-26, 10:23 AM
IP分享器我也推薦VIGOR
我本身也有用 蠻穩定的 比DLINK好很多
說到貴還好啦 站上有網友是代理他的產品
1700就可以買到了

可愛滴小玉
2004-05-31, 02:04 PM
東森目前沒有使用MOTO的機子,你說的銀色機應該是ASKEY這一台

它常斷線的因素應該取決實體線路(HFC),或是這一台機子(評價不太好)

打個電話請客服先幫您看一下。

lundi
2004-05-31, 05:44 PM
1000 packets transmitted, 1000 packets received, 0% packet loss
round-trip min/avg/max/mdev = 7.719/10.255/67.567/5.093 ms
看來我家線路品質還算正常... hmm
但是 max 67.567 會不會有點高... 有辦法在 50 以下嗎?


最初由 raytracy 發表
(節省版面, 我只引第一段, 其他請網友自行對照)

2. 您是管機房的? ;) Firewall擋ICMP不會發生這種現象, 您的狀況明顯與IP分享器有關. 當時您若有在使用 P2P 類型的軟體, 就可能造成分享器當機 (不是過熱, 是分享器的Session數不夠, 像D-LINK只能處理1024 Session, 但P2P開了幾天之後, 通常會產生一兩萬個Session), 此外, 病毒發動攻擊時也會因為 Session 數過高, 造成分享器當機.



請問這裡是指的, FW 檔 ICMP 不至於斷線?
是否因為 "CM -> IP分享器 -> 電腦" ...
(所以問題是出在ip分享器上?)

據我所知 "CM -> 電腦", 開 FW 把 ICMP 擋掉,
是會造成斷線的... 因為會有一台內部的機器 10.x.x.x,
一直傳 ICMP packet 到電腦, lost 掉不知道多少後, 就會被斷線..

raytracy
2004-05-31, 06:59 PM
最初由 lundi 發表round-trip min/avg/max/mdev = 7.719/10.255/67.567/5.093 ms
看來我家線路品質還算正常... hmm
但是 max 67.567 會不會有點高... 有辦法在 50 以下嗎?
Cable 和 ADSL 最大的不同點, 就在於 ADSL 使用類似 ATM 的傳輸技術, 所以 Ping 值可以很穩定; 但 Cable 使用 TDMA 技術, 最多會有高達 200 個用戶要同時去搶 Time-slot, 搶到 Time-slot 的人才可以傳資料. 因此大家看到 Cable 的 Ping 值高低差距會比較大, 但是只要不要太離譜, 一般是可以接受的. 您的 avg 還在 10ms 左右, 這代表那個 max 67.x 其實只是一些特例, 並非是經常發生的. 一般 Cable 在線路上完全沒有客戶時, Ping 值應該都可以低於 10ms. 即使客戶滿載, 小於 100ms 還是可以接受的. 這也就是為何電信總局要把查驗規範訂在 100ms 以下的主要原因.

這裡順便帶一下, 希望大家能走出 Ping 值高低的迷思, 因為 Ping 的高低, 並不完全等於您的傳輸速率. 舉個例子: T1/128K 的 ADSL, 若和 128K/128K 的數據專線相比, 誰的傳輸速度快? 而誰的 Ping 值比較高? (這兩個答案完全相反) 相信實際測過的人, 恐怕都會嚇一大跳, 摸不著頭緒....(曾經有學校因此拒用 T1/128K 的 ADSL, 因為根據他們 Ping 的結果: 認為 128K 的專線比 ADSL 還要快.....您覺得呢?...:D)

請問這裡是指的, FW 檔 ICMP 不至於斷線?是否因為 "CM -> IP分享器 -> 電腦" ...
(所以問題是出在ip分享器上?)
是的....當 PC 上的軟體, 使用過多的連線議程(Network Session)時, 大部分IP分享器的設計, 並未考慮到要負擔那麼多的議程, 此時會出現不可預期的現象, 當機是其中之一. 判斷的依據是: IP分享器重開就正常; 或PC軟體關掉就成常.
據我所知 "CM -> 電腦", 開 FW 把 ICMP 擋掉,
是會造成斷線的... 因為會有一台內部的機器 10.x.x.x, 一直傳 ICMP packet 到電腦, lost 掉不知道多少後, 就會被斷線..
不會的. 10.x.x.x 指的是派發給 CM 的 IP (不是分享器或PC喔), 而 CM 並沒有設計使用 ICMP 當 Keep-alive 的機制, 來保持連線. CM 的 Keep-alive 機制是作用在 HFC 光纖同軸網路的 MAC 層上面, 利用大約每隔 25 秒一次的 Maintenance Ranging 來確認 CM 還活著. (不過 HFC 的 MAC 層訊號, 在PC這邊是看不到的, 所以您不可能知道 CM 的 Maintenance Ranging狀態如何? 只有當它失敗之後, 才能從 CM 的 Log 中得知.)

至於您會感受到「好像把 ICMP 擋掉會造成斷線」, 其實那是PC上的軟體所造成的, 小弟知道有些線上遊戲, 自己會固定發 ICMP 封包出來, 如果 Server 沒有收到的話, 那個遊戲就會自己斷線. 其實當時 CM 並未斷線, 只是 PC 的軟體自己斷的. 其他可能還有類似的軟體也會這樣.

您可以試試看: 將 PC 的 FW 擋掉 ICMP, 然後開著不要去用, 也不要執行任何軟體, 看 CM 是否會斷線? (註: CM 若斷線, 一定會有燈號滅掉, 所以如果燈號正常的話, 斷線的責任就不是 CM)

lundi
2004-05-31, 08:51 PM
最初由 raytracy 發表

不會的. 10.x.x.x 指的是派發給 CM 的 IP (不是分享器或PC喔), 而 CM 並沒有設計使用 ICMP 當 Keep-alive 的機制, 來保持連線. CM 的 Keep-alive 機制是作用在 HFC 光纖同軸網路的 PHY 層上面, 利用大約每隔 25 秒一次的 Maintenance Ranging 來確認 CM 還活著. (不過 HFC 的 PHY層訊號, 在PC這邊是看不到的, 所以您不可能知道 CM 的 Maintenance Ranging狀態如何? 只有當它失敗之後, 才能從 CM 的 Log 中得知.)

至於您會感受到「好像把 ICMP 擋掉會造成斷線」, 其實那是PC上的軟體所造成的, 小弟知道有些線上遊戲, 自己會固定發 ICMP 封包出來, 如果 Server 沒有收到的話, 那個遊戲就會自己斷線. 其實當時 CM 並未斷線, 只是 PC 的軟體自己斷的. 其他可能還有類似的軟體也會這樣.

您可以試試看: 將 PC 的 FW 擋掉 ICMP, 然後開著不要去用, 也不要執行任何軟體, 看 CM 是否會斷線? (註: CM 若斷線, 一定會有燈號滅掉, 所以如果燈號正常的話, 斷線的責任就不是 CM)

應該是 SERVER 端那邊發出來的 icmp 封包到 PC,
來當作 keep-alive 的測試, ... (不是 CM 發給 PC)

tcpdump: listening on eth0
20:40:53.711921 10.34.80.x > 210-85-53-x.cm.dynamic.apol.com.tw: icmp: echo request
20:40:53.712113 210-85-53-x.cm.dynamic.apol.com.tw > 10.34.80.x: icmp: echo reply
20:40:58.713501 10.34.80.x > 210-85-53-x.cm.dynamic.apol.com.tw: icmp: echo request
20:40:58.713682 210-85-53-x.cm.dynamic.apol.com.tw > 10.34.80.x: icmp: echo reply

來自 10.34.80.x 的 icmp 封包,
這應該是主機那邊 keep-alive 機制所送到我 PC 上的,
因為我用 iptables 把所有 icmp 都擋掉, 過沒多久就斷線了..
我試過, 其他 icmp 全檔, 只允許 10.34.80.x 的 icmp 封包,
這樣就都不會斷線了..