Cable ISP的網管似乎有待加強....

以下引自tw.bbs.comp.network(原post者[email protected])

========================================================================
我用了BlackICE之後
常常可以在記錄裡面看到其他東森使用者的IP,Node,Group,NetBIOS,DNS和MAC
這是因為東森的線路較不安全嗎??
========================================================================

看來是CMTS的broadcast forwarding沒關,在同一CMTS下不同user可能在同一ip subnet下,碰上NETBIOS over TCP/IP這類會產生一堆broadcast的protocol就慘了;) ;) ....

如果不能在CM上先把這類garbage濾掉(對絕大多數user而言實用性偏低,闖禍的機會倒是不少,又浪費upload bandwidth;) ,至少CMTS也不要把這些garbage forwarding下來吧:D :D ....

小弟不太了解原文要表達的內容, 待小弟去研究看看....

BTW, broadcast 有可能在同一個 CMTS 底下發生, 通常不會跨過一台 CMTS 到達其他設備上....但一台 CMTS 之下可能會有高達一萬戶在線上.....

[QUOTE][i]最初由 raytracy 發表[/i]
[B]小弟不太了解原文要表達的內容, 待小弟去研究看看....

BTW, broadcast 有可能在同一個 CMTS 底下發生, 通常不會跨過一台 CMTS 到達其他設備上....但一台 CMTS 之下可能會有高達一萬戶在線上..... [/B]
[/QUOTE]

抱歉沒說清楚....其實也不是Cable ISP才會有問題,只要是跑純bridge mode的ISP(透過DHCP或直接assign fixed IP給user者,wether XDSL or Cable....BTW,PPPoE倒是不會有這個問題;) )沒在CPE將user送到subnet broadcast address的packet濾乾淨的話恐怕都會有類似的問題(client哪曉得自己是接在bridge mode的WAN上,偏偏NETBIOS over TCP/IP會產生一堆這類traffic,再加上Cable ISP的uplink又是多人共用的,問題更明顯;) ),如果CMTS/BRAS又把這類garbage forwarding下來的話光這些traffic就夠嗆的了:jump2: :jump2: ....

小弟這邊 CM 的 port 135, 137, 139, 445 通常都是擋掉的, 好像沒有類似的現象出現.....

[QUOTE][i]最初由 raytracy 發表[/i]
[B]小弟這邊 CM 的 port 135, 137, 139, 445 通常都是擋掉的, 好像沒有類似的現象出現..... [/B][/QUOTE]

以弟個人觀點最好不要直接擋NETBIOS over TCP/IP(雖然一樣會work;) )----因為要用的人會complain;) ,或許擋掉NETBIOS over TCP/IP送到subnet broadcast address的traffic(主要由master browser election或NETBIOS name resolution等等產生....BTW,或許應該濾掉client送到subnet broadcast address的所有traffic,有點類似router對WAN port設no ip direct-broadcast)會好些---要用的人總該知道destination的ip和resource name吧:) :) ....

[QUOTE][i]最初由 wangcm 發表[/i]
[B]以弟個人觀點最好不要直接擋NETBIOS over TCP/IP(雖然一樣會work;) )----因為要用的人會complain;) ,或許擋掉NETBIOS over TCP/IP送到subnet broadcast address的traffic(主要由master browser election或NETBIOS name resolution等等產生)會好些---要用的人總該知道destination的ip和resource name吧:) :) .... [/B][/QUOTE]
Hmmm....瞭解了, 兄的建議很好, 小弟考慮改變一下.....

呃....不過, 這樣好像很困難......因為我們 CM 的 Profile 是依照產品速率作群組的, 並不是依照 Subnet 作群組. 原本我是對全部的 CM 下一個 Global 的 access filter:

deny any any tcp 135

如果要改成檔 Subnet broadcast, 勢必要改成:

deny a.b.c.d a.b.c.255 tcp 135

這種樣子, 可是這樣就必須一台一台 CM 各別去設定, 在我們 Provision 軟體中, 恐怕很難這樣做; 因為改成各台CM用自己的, 會造成無法搜尋使用同一個速率的 CM 群, 在與帳務部門核對客戶資料時會有困難.....不知兄有沒有什麼建議?

[QUOTE][i]最初由 raytracy 發表[/i]
[B]Hmmm....瞭解了, 兄的建議很好, 小弟考慮改變一下.....

呃....不過, 這樣好像很困難......因為我們 CM 的 Profile 是依照產品速率作群組的, 並不是依照 Subnet 作群組. 原本我是對全部的 CM 下一個 Global 的 access filter:

deny any any tcp 135

如果要改成檔 Subnet broadcast, 勢必要改成:

deny a.b.c.d a.b.c.255 tcp 135

這種樣子, 可是這樣就必須一台一台 CM 各別去設定, 在我們 Provision 軟體中, 恐怕很難這樣做; 因為改成各台CM用自己的, 會造成無法搜尋使用同一個速率的 CM 群, 在與帳務部門核對客戶資料時會有困難.....不知兄有沒有什麼建議? [/B][/QUOTE]

弟對帳務沒什麼sense,抱歉了,不過搜尋profile應該還是可以用partiral match(只要參考QoS部份就行了??),或是直接寫程式參考DHCP request中的DHCP relay(應該就是CM的MAC address)取代TFTP server動態產生profile(或可配合accounting的DB達成高度客製化,說不定會比提供靜態的generic profile更有吸引力),不知是否可行:confused: :confused: ....

BTW,要是CM有像router的no ip direct-broadcast問題就好解決了,或是以弟對早期Motorola CMTS的印像(non-DOCSIS規格,不過弟沒實際handle過DOCSIS規格者就是了,sorry;) ),其user-user packet forwarding是可以關掉交由前端的router handle的(這就好玩了:D :D );) ,不知現在DOCSIS規格的CMTS是否可以比照辦理:confused: :confused: ....

profile的部份~我這用LSC的..早期抓到的profile是以modem的MAC為檔名~
不過過了一陣子後就變成是以速度來分了...

~~~~
DHCP和TFTP一般似乎都是使用同一台server
寫程式取代標準的TFTPd...在modem要求檔案時...透過modem的mac或是ip來傳回對應的profile...
難度上應該還好...(不過感覺這種需求應該在目前的程式已經會提供了才對@@)
原本的客戶資料庫與管理部份似乎也不大需要更動....
就像是在原本使用的方式上...包上一層...

~~~~
在程式製作上...感覺難易度似乎還好...
不過要知道原本系統用的程式,其運作方方式還提供的功能是怎樣~
server的負擔應該也會大不少@@

以上是我的想法..
不過我對這方面只算片面的了解...也許想法有點過於天真吧...