PTT數位生活區 / Network

[問答] 使用ISL或802.1Q的vlan封包問題

看板Network作者 ( 鑽石蟑螂)時間13年前 (2011/03/08 23:13), 編輯推噓28(28推 0噓 147→)
留言175則, 3人參與, 最新討論串1/4 (看更多)
各位前輩好 小弟最近在研讀關於vlan的部分 在書上看到在trunk上傳送標上vlanID的封包 有ISL和802.1Q兩種協定，但小弟不解的是 封包的MTU為1518 bytes，像ISL重新封裝frame後 應該會超過1518 byte，那這樣一來，還能夠在 乙太網路上傳送嗎? 還是有甚麼方式可解決這個問題? 謝謝! -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 123.193.72.153
→
03/10 01:53, , 1F
解決方法當然就是, 直接加大容許的 frame size 啊
03/10 01:53, 1F
→
03/10 01:59, , 2F
標準只訂了一個(802.3ac), 但是各家廠商都有類似的作法
03/10 01:59, 2F
→
03/10 01:59, , 3F
俗稱 baby giant/baby jumbo, 早期網路晶片很多不支援
03/10 01:59, 3F
推
03/11 15:34, , 4F
應該是下面的回文貼近現況...
03/11 15:34, 4F
→
03/11 17:00, , 5F
下面的回文有講跟沒講一樣 /_\ 網路上傳輸的 frame size
03/11 17:00, 5F
→
03/11 17:01, , 6F
會大於規範中的最大值(please google 802.3ac)
03/11 17:01, 6F
推
03/11 22:13, , 7F
isl這種是彼此兩點建立的trunk...next hop就會移除
03/11 22:13, 7F
→
03/11 22:31, , 8F
封裝後的 frame 還是會在乙太網路上傳輸, 問題是問這個
03/11 22:31, 8F
推
03/12 21:03, , 9F
因為是對點的關係 中間如果有經過不參予trunk的節點
03/12 21:03, 9F
→
03/12 21:04, , 10F
自然會衍生出問題...Layer1的部分並不會因為MTU而超載
03/12 21:04, 10F
→
03/13 02:28, , 11F
你這樣是假設設備的 ethernet 晶片可以支援這種 frame
03/13 02:28, 11F
→
03/13 02:29, , 12F
但是世界並沒有那麼美好, 尤其是考慮 ISL vlan 那個年代
03/13 02:29, 12F
→
03/13 02:31, , 13F
請記得 switch 的對口未必是 switch, 也有可能是 router
03/13 02:31, 13F
→
03/13 07:23, , 14F
不過之後的 Router 就開始支援封裝的部分
03/13 07:23, 14F
→
03/13 07:24, , 15F
不過以前某些Switch~ 看到這類的Frame 就會丟棄
03/13 07:24, 15F
推
03/13 11:04, , 16F
實務上會讓trunk的點彼此對接 這裡應該是討論普遍狀況吧?
03/13 11:04, 16F
→
03/13 11:08, , 17F
能夠config trunk的設備 彼此皆config正確即可...
03/13 11:08, 17F
→
03/13 11:09, , 18F
假設中間還有其他非trunk節點 個人是不建議這樣的網路架構
03/13 11:09, 18F
→
03/13 11:11, , 19F
沒碰過很多產品 但碰過的cisco router皆支援ISL & 802.1Q
03/13 11:11, 19F
→
03/13 11:26, , 20F
之後的設備 大都支援這部分的 Frame
03/13 11:26, 20F
→
03/13 11:26, , 21F
一般來說會走Trunk的鏈路 都已 P2P 居多
03/13 11:26, 21F
→
03/13 11:28, , 22F
比較不會使用 share 的部分
03/13 11:28, 22F
→
03/13 14:01, , 23F
"實務上會讓trunk的點彼此對接"? trunk 並沒有規定用途
03/13 14:01, 23F
→
03/13 14:03, , 24F
用 trunk 連接 router 節省介面, 在 IDC 是很常見的作法
03/13 14:03, 24F
→
03/13 14:04, , 25F
GbE 介面完全沒有這類問題, 但是交接期的 FE 小毛病很多
03/13 14:04, 25F
→
03/13 14:07, , 26F
VLAN 問題還算簡單, 在這類老設備上面做 mpls 問題更多
03/13 14:07, 26F
推
03/13 14:21, , 27F
實務上對接是易於管理 架構簡單化 不需要多做其他的設定
03/13 14:21, 27F
→
03/13 14:23, , 28F
IDC界接L2部分應該多採用L3 switch了　router在靠近border
03/13 14:23, 28F
推
03/13 14:29, , 29F
蔽公司經營IDC 並不會考慮router+trunk提供頻寬服務
03/13 14:29, 29F
→
03/13 14:30, , 30F
L3 switch架構簡單且易於管理 功能也很彈性
03/13 14:30, 30F
→
03/13 14:51, , 31F
這在國外根本是家常便飯, GSR/juniper 的介面都很貴
03/13 14:51, 31F
→
03/13 14:52, , 32F
而且 IDC 很可能是中立, 與 ISP 未必屬同家業者
03/13 14:52, 32F
→
03/13 14:53, , 33F
台灣並沒有這種完全中立的 IDC, 但不代表這種需求不存在
03/13 14:53, 33F
推
03/13 14:55, , 34F
我並沒有否定你的論述 只是說明一下我的實務經驗
03/13 14:55, 34F
→
03/13 14:57, , 35F
但要做IDC 本身就要是二類電信以上的ISP 不然會有些困難
03/13 14:57, 35F
→
03/13 14:58, , 36F
交換中心式的 IDC, 只提供空間、電力以及介接電路
03/13 14:58, 36F
→
03/13 14:59, , 37F
GSR通常不會與企業客戶對接提供頻寬 juniper也有L3 switch
03/13 14:59, 37F
→
03/13 15:00, , 38F
tier-1 沒什麼人這樣用 /_\ 在國外買 IP transit
03/13 15:00, 38F
→
03/13 15:00, , 39F
電路如果沒有配發ip 也無法提供服務 有配發ip可算是ISP
03/13 15:00, 39F
還有 96 則推文
→
03/13 20:55, , 136F
會出現很多額外的需求, 這在台灣以外的地方是常態
03/13 20:55, 136F
→
03/13 20:56, , 137F
台灣也不是沒有這種 IDC, 只是差在有沒有用過罷了
03/13 20:56, 137F
→
03/13 20:57, , 138F
除去 port 本身不看, port charge 和 xconnect 都不便宜
03/13 20:57, 138F
→
03/13 20:57, , 139F
還都是月租式, 一個 engineer 的薪水也買不了幾條
03/13 20:57, 139F
→
03/13 21:00, , 140F
Router-on-a-stick 是歷史悠久的作法, 一開始 VLAN trunk
03/13 21:00, 140F
→
03/13 21:02, , 141F
被設計出來的用途正是為了這個
03/13 21:02, 141F
→
03/13 21:18, , 142F
一般來說 Router on a stick 是因為trunk衍生而來
03/13 21:18, 142F
→
03/13 21:18, , 143F
更早期 卻是耗損router的介面 Router on a stick 是能
03/13 21:18, 143F
推
03/13 21:19, , 144F
有效降低耗損Router介面的作法 (router的介面 不便宜)
03/13 21:19, 144F
→
03/13 21:20, , 145F
不過 3560在我公司算是低端設備 core layer則都是 65xx
03/13 21:20, 145F
→
03/13 21:21, , 146F
6509 6513 等~~ 一整群的~~~ 3560/3750 這種等級都是跑
03/13 21:21, 146F
→
03/13 21:22, , 147F
接近access layer的部分~ 4507則是跑分布層的部分
03/13 21:22, 147F
推
03/13 21:26, , 148F
落差還是蠻大的...只能說謝謝指教了
03/13 21:26, 148F
推
03/13 21:29, , 149F
而且問題好像也發散了.....
03/13 21:29, 149F
推
03/13 22:29, , 150F
IDC的部分 只能說與台灣業界現況完全不符 說國外就無言了
03/13 22:29, 150F
推
03/13 22:34, , 151F
BGP的部分也問題發散了..但BGP是有as number的專屬協定..
03/13 22:34, 151F
→
03/13 22:35, , 152F
除非IDC的客戶又是ISP...那我又無言了...
03/13 22:35, 152F
→
03/13 22:37, , 153F
但以IDC的角色來說 客戶95%不會是ISP 以ISP的角色才有...
03/13 22:37, 153F
推
03/13 22:42, , 154F
5%大概就像是104這樣的特例 並非ISP但卻有ip & as number
03/13 22:42, 154F
→
03/14 09:11, , 155F
請先弄清楚"IDC"的定義... IDC 幾乎都是 ISP 自己開設
03/14 09:11, 155F
→
03/14 09:12, , 156F
這是台灣的特例, 請不要把特例當成通例看待
03/14 09:12, 156F
推
03/14 10:21, , 157F
ISP開設的IDC不是IDC嗎?
03/14 10:21, 157F
推
03/14 10:24, , 158F
不知道為什麼總是要國外國外的.莫非我們要請外國人當總統?
03/14 10:24, 158F
→
03/14 10:26, , 159F
就先假設這特例成立好了..那又??
03/14 10:26, 159F
→
03/14 10:27, , 160F
如果很多事情台灣是特例 那我們生活在台灣的人要如何依從??
03/14 10:27, 160F
→
03/14 10:28, , 161F
是矇著頭向國外看齊? 還是依循著所謂的"特例"去過生活?
03/14 10:28, 161F
推
03/14 10:33, , 162F
回過頭來 focus在我們生活的土地台灣 不是比較實際??
03/14 10:33, 162F
→
03/14 10:34, , 163F
舉個極端一點的例子好了 "假使"國外紅燈右轉不違規
03/14 10:34, 163F
→
03/14 10:35, , 164F
在台灣 紅燈右轉被抓到開單了就算說台灣是特例只有台灣這樣
03/14 10:35, 164F
→
03/14 10:35, , 165F
這張罰單還是得繳錢的啊...
03/14 10:35, 165F
→
03/14 16:01, , 166F
這....感覺離題太多了!!!
03/14 16:01, 166F
→
03/14 16:02, , 167F
呵呵... 爭論難免~ 只不過有點偏離主題就是了
03/14 16:02, 167F
推
03/14 16:12, , 168F
是啊 問題發散了很遠
03/14 16:12, 168F
→
03/14 16:46, , 169F
要如何看待"非 ISP 開設的 IDC" 這才是重點
03/14 16:46, 169F
→
03/14 16:48, , 170F
所有技術都是從需求來的 一直重覆"我的作法比別人好"
03/14 16:48, 170F
→
03/14 16:48, , 171F
有意義嗎? 別人又沒辦法採用
03/14 16:48, 171F
推
03/14 17:38, , 172F
需求從實務而來
03/14 17:38, 172F
→
03/14 17:40, , 173F
那要如何看待ISP的IDC? 要如何看待非ISP的IDC? 差異是?
03/14 17:40, 173F
→
03/14 17:41, , 174F
別人沒辦法採用~?? 採用什麼~?? 問題討論串太長
03/14 17:41, 174F
→
03/14 17:42, , 175F
而且 為什麼非ISP開設的IDC才是重點? 中立? or? 願聞其詳
03/14 17:42, 175F
‣ 更多 diroach 的文章
文章代碼(AID): #1DTaUTzh (Network)
Network 近期熱門文章
更多 近期熱門文章 >>
PTT數位生活區 即時熱門文章
更多 即時熱門文章 >>
‣ 更多 diroach 的文章
文章代碼(AID): #1DTaUTzh (Network)