嗯~ MOD 依服務種類需要unicast(隨選服務) 與 multicast (直播節目)routing 支援,

unicast 被tunnel比較不擔心, 馬踢卡死特 不知道有沒有一些額外細節要注意.....

streaming 的資料量除了頻寬够, latency也是不能太大, MOD訊務在ISP業者有可能

被保障/優化, 所以看起來順被視為理所當然, 被L2TP帶過三不管的internet之後的話...

或是你開他也開MOD, 對一般網路存取的影響, 可能還是要實測才知道影響程度了.

unicast或multicast說穿了都是標準的Ethernet封包(不然VTU-R/STB間就不會長成現在這樣了 ),除非L2TP會自動濾掉某些封包,不然除了latency/throughput外照說不會有太大的問題吧....



這一點在台灣是沒啥好研究的,因為在20M/4M以下(含20M/4M)的user申請MOD時,CHT會另外開頻寬給MOD專用(跑不同的VC/VLAN,用白話講就是開外掛,以鵝的推測,就CHT的立場而言,既然線和設備都是現成的,與其擺著白花$$,不如拿來跑收得到$$的AP,榨乾跑得出的頻寬 )....



這可能真要實測才有辦法知道了,不過鵝應該會先找個download在4M以上的鄰居測試一下(現在應該很好找了 ),免得光為了測試就得跑出國,可以work就算了,要是不work就糗斃了 ....

封包格式當然都是標準ethernet沒問題, 不過那個lab用的L2TP server我不熟, 或許

跟產品特性有關, 有些網路設備本身要有multicast tunnel interface才能夠把收到的

multicast packet 轉送到它其他 GRE/VPN tunnel 裡面再作封裝來轉送傳輸.

multicast address 是class D, 如果這個設備的介面不知道怎麼處理, 可能送不進tunnel

如果它是一股腦兒不管三七二十一通通吃的話, 或許OK. 不過, 也不能太無腦的盲送,

還需要跟自己使用的流量作區隔, 才能兼顧兩者. multicast for A 要轉送, for 鵝大

就不轉送, 進local STB....etc. , 多少需要些管理, 所以感覺還有些細節要考量吧.

以前有幾個情境曾想用類似這種vpn hub的轉送做法, 不過後來因為 wan 端有 double

traffic (先拉內容跑下載, 再轉給別人又跑上傳, 佔雙倍流量) 考慮效率性而作罷,

既然MOD流量是開外掛來的, 或許可以試試看.

VTU-R裡面看到的(20M/4M,有申請MOD,但還沒來裝機,倒是VDSL switch已經先調好一陣子了 )....


鵝的想法很簡單,就是VTU-R開MOD port isolation,把MOD的traffic導引到特定port直上L2TP router的LAN,用L2TP包進Public IP後送到VTU-R剩下的Ethernet port上Public Internet應該是可以work的,最不濟的狀況就是另外申請一路MOD專用不帶Internet的ADSL(反正ADSL電路費+MOD月租也只要NT$300有找 ),這樣應該有機會榨乾20M/4M的上傳了吧 ....

我猜L2TP會支援Broadcast , 但應該不支援Multicast ....

如果L2TP支援Multicast , 那麼照理說ISP就不會去implement MPLS Protocol
因為Dynamic Routing Protocol除了BGPv4 外,全部使用Multicast 來做為通訊協定

因為L2TP可以穿越ISP到達遠端,那麼multicast如果會forward,那對於公司有許多外點
的分公司用這個L2TP就可以輕易的串連起來,看是要Full mesh or partially mesh
都會很容易實作出來!!

PS: MPLS到現在還是成為我最不想學的Protocol .....

其實呢~ multicast 是可以被L2TP承載的, 只不過在這種case, LNS要負責replicate

multicast packet, 而不是直接裝進payload作tunnel. 邏輯上跟鵝大的做法不一樣,

當然,我不見得能知道所有廠商實作的方法與彈性. MPLS的採用, 倒不是因為需要有個

multicast solution, 它本身有相當多的優點, 例如路徑選擇效率,封包轉送效率,流量工程

Qos彈性, 快速重路由等, 如果要走大型路由/核心網路 領域的, MPLS可說是必修,

若是偏安全或應用加值的, 就比較無妨, 進MPLS之前還是跑ethernet, 把關還是在這做

等轉成MPLS之後的封包多數攻擊也無法再做什麼 插入/偽冒/修改.

許多路由協定本身就有使用multicast來作為路由器與路由器之間協定溝通的媒介,

但是路由計算/選徑 則是看路由協定而有不同演算法, multicast應沒cover到這塊.

我反倒是覺得,MPLS沒有那麼好...

我是直接稱它是 電信業的Costdown 專用Protocol , 原因就是MPLS大部份都是用於
Internet 骨幹網路裡 , 它沒什麼太多好處(對於一般末端客戶而言) , 但是卻有可能存在
未發現的壞處 , 這裡就不多說了 , 之前我就曾被某電信業者的高級主管告知一個狀況,問我
有沒有解決方案 ,說明如下

1. 骨幹網路裡有設定STP/RSTP Protocol
2. 網段有進行Subneting

問我說為何骨幹網路裡還是會發生Broadcast strom ,使得骨幹網路攤瘓!! 如何解決 ??

說老實話,我還真是被問得沒頭沒腦的,只告訴我這些線索,就問我這種怪問題 ...
嚴格來說,就算老經驗的人被問到,我也不認為他能夠知道問題點在那裡!! 我當場是回答
不出來 , 原因很簡單 , STP/RSTP已經有設定了,基本上不會有這種事,再加上subneting
後, broadcast strom頂多只會發生在一小塊區域裡,那也就是說,要不通也頂多是少部份的用戶
無法上網而已,沒道理會讓整個骨幹網路全部攤瘓!!

我離開後反覆思考,直覺認為我被唬爛了!! 根本不會有這種事發生

直到我在另一個論壇裡,向別的網友提及這件事,才有一個網友,也是這方面的專長的人
告知我才晃然知道,這不是唬爛的事,但發生原因為何? 也很簡單, 就是骨幹網路裡多了
一個沒告知我的Protocol , MPLS !! 形成原因私下我再轉述好了,這裡就不多說了...

所以我才在開始得時候說, MPLS是我最不想學的protocol ,我甚至還見過 ,一個封閉型
的網路系統居然還要設定規劃MPLS !!

Protocol的存在是要方便管理 , 而不是製造新問題出來 , MPLS的存在, 並沒有比較方便
反而使得網路系統更複雜難管 , 因此我不認為MPLS值得學習 !!

我想, 沒有一個協定可以適用所有的網路, 需求不同, 背景不同, 限制不同, 預算不同.....

都會需要不同的解決方案, MPLS已經是大型路由網路的顯學, 是維運電信網路必修知識,

但在這領域之外, 你也可說它一無是處, 就像F1 類的跑車, 除了速度, 它載客/載貨/舒適度

豪華度/省油性.....都不是房車/貨車的對手. 但基本上不會有人拿它們來這樣比.

我們做過許多大型電信骨幹, 服務了台灣過半以上的流量, MPLS based解決方案是目前

所有一二類電信業者共同的選擇, 那是用來服務數十萬人以上廣域網路, 有眾多分級的

服務, 高要求度的核心交換協定, MPLS兼有layer2與layer3協定的優點, 沒有它, 很多

既有協定根本無法做到它能提供的好處與功能, 它並不是來找麻煩, 反而像是savior,

只差在你的環境適不適合用它而已, 這我必須幫它講幾句話.

至於說到在企業用戶環境自己去建MPLS, 我們也遇過, 但它們是全國性的能源事業體,

或是跨全國性的金融集團, 有相當龐大與分散的網路, 管理人員很清楚知道自己在做甚麼,

以及為什麼這樣做, 才會有這樣的規劃. MPLS也止於WAN端 border router或Provider

edge的, 不太會跑到有STP/RSTP這種多半存在於邊際到核心交換器之間的地方.

若是誤用而覺得難用, 也恐怕是必然的了.

電信業的Costdown 專用Protocol 說的好!