史萊姆論壇

史萊姆論壇 (http://forum.slime.com.tw/)
-   網路疑難應用技術研討區 (http://forum.slime.com.tw/f47.html)
-   -   子網路切割與路由 (http://forum.slime.com.tw/thread212180.html)

Admin1 2007-07-27 01:35 PM

子網路切割與路由
 
假如我們目前有二台電腦,使用 HUB 連接,設定如下:
====================
A <----------> HUB <----------> B

A 電腦
網路界面:eth0
220.228.161.117/255.255.255.128
subnet id ==>220.228.161.0

B 電腦
網路界面:eth0
220.228.161.124/255.255.255.192
subnet id ==>220.228.161.64
====================


問題:
這二台電腦彼此是否可以通訊?
若是不可,為何不可?
若是可以,為何可以?


請各位對於網路有研究的朋友一起來聊聊囉....

rezard 2007-07-27 02:35 PM

引用:

作者: Admin1 (文章 1771971)
假如我們目前有二台電腦,使用 HUB 連接,設定如下:
====================
A <----------> HUB <----------> B

A 電腦
網路界面:eth0
220.228.161.117/255.255.255.128
subnet id ==>220.168.161.0

B 電腦
網路界面:eth0
220.228.161.124/255.255.255.192
subnet id ==>220.168.161.64
====================


問題:
這二台電腦彼此是否可以通訊?
若是不可,為何不可?
若是可以,為何可以?


請各位對於網路有研究的朋友一起來聊聊囉....

老大,不好意思請問一下,IP位址220.228.161.xxx,subnet id ==>220.168.161.ooo

紅字是故意不一樣,還是打錯?:on_47: :on_47: :on_47:

巫拉 2007-07-27 02:37 PM

引用:

作者: Admin1 (文章 1771971)
假如我們目前有二台電腦,使用 HUB 連接,設定如下:
====================
A <----------> HUB <----------> B

A 電腦
網路界面:eth0
220.228.161.117/255.255.255.128
subnet id ==>220.168.161.0

B 電腦
網路界面:eth0
220.228.161.124/255.255.255.192
subnet id ==>220.168.161.64
====================


問題:
這二台電腦彼此是否可以通訊?
若是不可,為何不可?
若是可以,為何可以?


請各位對於網路有研究的朋友一起來聊聊囉....

可以通訊,兩個網段是由同一個220.228.161.0 做子網路切割,
只是一個是切成128組IP,一個是切成64組IP,
220.228.161.117與220.228.161.124又同屬一組64IP範圍,
故會通。

飛鳥 2007-07-27 02:37 PM

引用:

作者: rezard (文章 1772026)
老大,不好意思請問一下,IP位址220.228.161.xxx,subnet id ==>220.168.161.ooo

紅字是故意不一樣,還是打錯?:on_47: :on_47: :on_47:

打錯啦:on_74:

rezard 2007-07-27 02:44 PM

引用:

作者: 飛鳥 (文章 1772029)
打錯啦:on_74:

:on_67: :on_67: :on_67:

所以小弟可以說這環境設定錯誤,所以...不通、不通、不通...嗎?:on_19: :on_19:

(不通...噗通...小弟需要一個跌入馬桶的蔥寶圖案,噗通...):on_08: :on_08:

Admin1 2007-07-27 02:52 PM

引用:

作者: rezard (文章 1772026)
老大,不好意思請問一下,IP位址220.228.161.xxx,subnet id ==>220.168.161.ooo

紅字是故意不一樣,還是打錯?:on_47: :on_47: :on_47:


不小心打錯 ^^a

Admin1 2007-07-27 02:54 PM

引用:

作者: 巫拉 (文章 1772027)
可以通訊,兩個網段是由同一個220.228.161.0 做子網路切割,
只是一個是切成128組IP,一個是切成64組IP,
220.228.161.117與220.228.161.124又同屬一組64IP範圍,
故會通。


是的,在這樣的條件下會通,因為是同屬一組64IP範圍

不過真是不好玩,一下子就被答對了

本來想讓大伙煩惱一下的:on_80:

想試試看是不是大伙一看到 "不同子網路段" 與 "沒有 router" 就會直接宣告不通...





=====================
好久沒看到您說話了:on_81:

Admin1 2007-07-27 02:55 PM

引用:

作者: rezard (文章 1772037)
:on_67: :on_67: :on_67:

所以小弟可以說這環境設定錯誤,所以...不通、不通、不通...嗎?:on_19: :on_19:

(不通...噗通...小弟需要一個跌入馬桶的蔥寶圖案,噗通...):on_08: :on_08:


這樣子說也可以

但這不是我的本意啦.......:on_36:

rezard 2007-07-27 03:06 PM

引用:

作者: Admin1 (文章 1771971)
假如我們目前有二台電腦,使用 HUB 連接,設定如下:
====================
A <----------> HUB <----------> B

A 電腦
網路界面:eth0
220.228.161.117/255.255.255.128
subnet id ==>220.228.161.0

B 電腦
網路界面:eth0
220.228.161.124/255.255.255.192
subnet id ==>220.268.161.64
====================


問題:
這二台電腦彼此是否可以通訊?
若是不可,為何不可?
若是可以,為何可以?


請各位對於網路有研究的朋友一起來聊聊囉....

還有一個還沒改到...

B 電腦
網路界面:eth0
220.228.161.124/255.255.255.192
subnet id ==>220.268.161.64

:on_54: :on_54:

本帖馬上變成大家來找碴單元...

:on_19: :on_19: 還是噗通...

rezard 2007-07-27 03:14 PM

引用:

作者: Admin1 (文章 1772044)
是的,在這樣的條件下會通,因為是同屬一組64IP範圍

不過真是不好玩,一下子就被答對了

本來想讓大伙煩惱一下的:on_80:

想試試看是不是大伙一看到 "不同子網路段" 與 "沒有 router" 就會直接宣告不通...





=====================
好久沒看到您說話了:on_81:

說正經的,這樣設定在任何NOS上都通嗎?
對不起,RFC改到後來小弟都亂了,有些書上的訊息根本就是舊的...:on_43:

老大可否提供一下有關這部份應該參閱的RFC編號,謝謝。:on_65: :on_65:

飛鳥 2007-07-27 03:42 PM

我記得的是,封包是只包括來源ip,和目的ip,封包是不包括子網路遮罩資訊

1.網路卡收到封包後,會把封包的來源ip和自己的子網做and,看是不是同一個網段的
2.如果跟自己同一個網段,就收下封包並交給協定上一層處理

算法如下圖
http://netgames123.googlepages.com/IP.JPG

a電腦和b電腦各自算出自己的SubnetID

但當A電腦收到B電腦的封包時,依照上面1,2步驟,A電腦會以為B電腦跟他同一個網段(兩個IP結果都是跟255.255.255.128做AND後,結果都是220.228.161.0),便把B的MAC記錄在ARP中

這樣就會建立連線了

但反過來,如果是B收到A封包,依照上面1,2步驟,B電腦會以為A電腦跟他同一個網段(兩個IP結果都是跟255.255.255.192做AND後,結果都是220.228.161.64)

雖然子網不同,AND運算結果不同,但兩者都把對方視為跟自己同一網段,那網路也是會通的

rezard 2007-07-27 04:40 PM

小弟簡單畫了二張圖,進來逛的大大們應該可以更清楚一點瞭解二部電腦邏輯上所在的網段...
首先是A電腦220.228.161.117
http://img510.imageshack.us/my.php?i...ubneta1dt7.jpg

再來是B電腦220.228.161.124
http://img510.imageshack.us/my.php?i...ubnetb1vy1.jpg

如有錯誤請提醒一下,謝謝。

飛鳥 2007-07-27 05:23 PM

引用:

作者: rezard (文章 1772121)
小弟簡單畫了二張圖,進來逛的大大們應該可以更清楚一點瞭解二部電腦邏輯上所在的網段...
首先是A電腦220.228.161.117
http://img510.imageshack.us/my.php?i...ubneta1dt7.jpg

再來是B電腦220.228.161.124
http://img510.imageshack.us/my.php?i...ubnetb1vy1.jpg

如有錯誤請提醒一下,謝謝。

沒錯!
第一張圖,是分成兩段
0~127 共128個ip,0是SubnetID,127是廣播ip,可用ip1~126

128~255 共128個ip,128是SubnetID,255是廣播ip,可用ip129~254


第二張圖,分四段
0~63 共64個ip,0是SubnetID,63是廣播ip,可用ip1~62

64~127 共64個ip,64是SubnetID,127是廣播ip,可用ip65~126

128~191 共64個ip,128是SubnetID,191是廣播ip ,可用ip129~190

192~255 共64個ip,192是SubnetID,255是廣播ip,可用ip193~254

Admin1 2007-07-27 07:11 PM

引用:

作者: rezard (文章 1772053)
還有一個還沒改到...

B 電腦
網路界面:eth0
220.228.161.124/255.255.255.192
subnet id ==>220.268.161.64

:on_54: :on_54:

本帖馬上變成大家來找碴單元...

:on_19: :on_19: 還是噗通...

我也不知道怎麼回事:on_36:

今天一直頭昏昏.........:on_74:

可能是昨天沒睡好的關係

Admin1 2007-07-27 07:14 PM

引用:

作者: rezard (文章 1772060)
說正經的,這樣設定在任何NOS上都通嗎?
對不起,RFC改到後來小弟都亂了,有些書上的訊息根本就是舊的...:on_43:

老大可否提供一下有關這部份應該參閱的RFC編號,謝謝。:on_65: :on_65:

我覺得這跟 spec 沒有太大的關係

這純粹是觀念上的問題

一般人會很直覺的認定 "不同的網路段需要 router 轉送封包"

但若是從 "為什麼需要 router 轉送" 這點切入

這題其實不難解

Admin1 2007-07-27 07:17 PM

引用:

作者: rezard (文章 1772121)
小弟簡單畫了二張圖,進來逛的大大們應該可以更清楚一點瞭解二部電腦邏輯上所在的網段...
首先是A電腦220.228.161.117
http://img510.imageshack.us/my.php?i...ubneta1dt7.jpg

再來是B電腦220.228.161.124
http://img510.imageshack.us/my.php?i...ubnetb1vy1.jpg

如有錯誤請提醒一下,謝謝。


如果你直接從 kernel 如何判別某個封包該往哪個網路界面送出去這點來看

這題其實出乎意料的簡單,不需要太複雜的計算

計算的東西,就交給這個網站吧: http://www.subnet-calculator.com/

Admin1 2007-07-27 07:23 PM

====================
A <----------> HUB <----------> B

A 電腦
網路界面:eth0
220.228.161.117/255.255.255.128
subnet id ==>220.228.161.0

B 電腦
網路界面:eth0
220.228.161.124/255.255.255.192
subnet id ==>220.228.161.64
====================


當 A 要傳封包給 B 的時候,例如我們要從 A 電腦 PING B 電腦時,系統會把 B 電腦的 IP用 A 電腦本身的 netmask 進行 AND 運算,也就是 220.228.161.124 AND 255.255.255.128。此時可以發現計算出來的 subnet id 為 220.168.161.0,正好就是 A 電腦的 eth0 界面,kernel 就直接把封包往 eth0 丟出去。

丟出去的 IP Header 裡面並沒有 netmask 這種東西(ip packet 中並不帶有 netmask 訊息),所以 B 電腦看到的就是一個 destination address 為 220.228.161.124 的封包,B 電腦就會把它收起來。

然後當 B 電腦要回傳封包給 A 時,會把 A 電腦的 IP 拿來和 B 電腦本身的 netmask 做運算,也就是 220.228.161.117 AND 255.255.255.192,算出來的 subnet id 為 220.168.161.64,正好就是 B 電腦的 eth0 界面,所以封包就往 B 電腦的 eth0 界面送出去。

當 A 電腦收到封包時,會看到的就是一個 destination address 為 220.228.161.117 的封包,A 電腦就會把它收起來,然後 A 與 B 的通訊就完成了。


附上一張 IP Header 的圖供參考:
http://www.ssfnet.org/Exchange/tcp/Graphics/tcpHeader1.gif

rezard 2007-07-28 08:23 AM

所以,這種通訊可否稱之為「美麗的誤解」呢?

A誤會B為同國的人,所以A就敞開大門歡迎B,B也誤會A為同國的人,所以B也敞開大門歡迎A。實際上二個人卻分屬不同國家,只是剛好都講英文,聽的懂對方在講什麼,自己講的對方也聽的懂。

那麼,「在標準TCP/IP協定運作下,區網內A電腦與B電腦IP Address必須位於同一子網段才能通信」這個立論是錯的,因為本例就是此立論的例外...。可惜一般教科書或學校比較不會探討這部分。

或許也可以這麼看待:從classful到classless的改變,沒有順道變更IP封包的規格才造成這種誤謬。classful不需要mask,classless卻需要mask,但mask值不隨封包傳送,而是節點保留自己的mask來判斷封包該走哪個介面。

放到廣域網路上來看,classful與classless是可以並存的,因為所有的router只需要由封包的目標位址去計算判斷該封包的出口介面,該封包就可以一直被傳送到目的地。

這結果造就了今天方便的網際網路,卻也埋下了危險因子。惡意的封包無法透過這一層協定被阻隔拋棄,當然有人會說第三層本來就不是要做過濾的動作,只是小弟認為"以量取勝"(時間週期內遞送處理最多的封包數)和"以質抑量"(透過快速有效的辨識直接剔除不良封包)某個程度上是可以取得做法上的平衡的。

Admin1 2007-07-28 02:46 PM

引用:

作者: rezard (文章 1772665)
那麼,「在標準TCP/IP協定運作下,區網內A電腦與B電腦IP Address必須位於同一子網段才能通信」這個立論是錯的,因為本例就是此立論的例外...。可惜一般教科書或學校比較不會探討這部分。

有些原則解釋的太細會讓人無所適從,就像是數學的 "公式" 一樣,有時為了方便教學或記憶,就給人一條公式套一套,答案就出來了,遇到不適用的狀況才告訴你那是例外。對於 TCP/IP 若要有深入的瞭解,個人是推薦 Richard Stevens 寫的 The Protocols (TCP/IP Illustrated, Volume 1),他一共寫了三本書,建議看第一本就好,其他二本除非想寫網卡 driver 那一類的系統程式,不然應該用不到。

http://ec1.images-amazon.com/images/I/4124NANAQ5L._SS500_.jpg

這本書對於 TCP/IP 有著極精湛的論述,可謂前無古人後無來者的 Bible,可惜 Stevens 大師已不在人世(我記得他過世了),不能再受大師薰陶,實為人生一大憾事。


引用:

作者: rezard (文章 1772665)
或許也可以這麼看待:從classful到classless的改變,沒有順道變更IP封包的規格才造成這種誤謬。classful不需要mask,classless卻需要mask,但mask值不隨封包傳送,而是節點保留自己的mask來判斷封包該走哪個介面。

rezard 真的不簡單,這個問題 Stevens 大師也有提到,他老人家認為在未來也許會有加強版的 TCP/IP protocol Suit,可以解決安全性與動態 netmask 問題,只可惜十年過去了,好像還是沒看到此類機制的出現(但好像有聽過可以透過其他的機制達到此目的)。

目前如果真的要做到實體的隔離,可能要靠 cisco 的 switch or router 來建 vlan。


所有時間均為台北時間。現在的時間是 09:04 AM

Powered by vBulletin® 版本 3.6.8
版權所有 ©2000 - 2025, Jelsoft Enterprises Ltd.

『服務條款』

* 有問題不知道該怎麼解決嗎?請聯絡本站的系統管理員 *


SEO by vBSEO 3.6.1