一個簡單卻無法解釋的網絡問題

為何連接交換機上的一臺設備，不需要將筆記本ip改成交換機網段，而連接交換機的管理頁面卻需要改網段?

我用的騰達的一個小交換機5口的，然后我公司有個產品有個ip可以通過網線連接訪問這個ip查看運行狀況，不過交換機的管理網段是192.168.0.1，那個設備的ip是可調的，初始是192.168.1.11。

但是將這個設備插入交換機，另外一個交換機口連接筆記本，我的筆記本網段是192.168.1.5，但是為何連接公司產品時，不需要將產品的ip和筆記本ip改成192.168.0網段的。但是想登錄交換機管理網址時需要將筆記本改成192.168.0。

廣播域內的主機之間的通信，必須處于相同的（same）網段。

當你訪問廣播域內的IP= 192.168.1.11，你的源主機使用的IP = 192.168.1.5，對嗎？如果沒有猜錯，2個主機都使用255.255.255.0掩碼，所以它們的網段是相同的，都是192.168.1.0。源主機（192.168.1.5）發現目標主機（192.168.1.11）和自己在同一個網段（192.168.1.0），所以只要用ARP廣播請求對方的MAC地址即可。

ARP Request廣播報文到達交換機時，交換機無條件廣播，處于廣播域內的目標主機自然會聽到，發現這是對自己的召喚，于是通過單播將自己的MAC地址通過ARP Reply發給源主機。源主機得到ARP Reply，就可以和對方通信了。

當你訪問廣播域內的交換機IP= 192.168.0.1，而你的源主機使用的IP = 192.168.1.5，如果雙方的掩碼都是255.255.255.0，很顯然雙方并不在相同的網段內。源主機的網段=192.168.1.0，

目標主機的網段= 192.168.0.0。

源主機發現對方和自己不在一個網段，需要將報文發給自己的網關。在問題描述中，并沒有網關IP的信息。所以源主機會通過ARP Request請求網關的MAC地址，當網關的ARP Reply到來時，源主機就得到了網關的MAC地址。于是源主機就將報文發給了網關。

網關收到報文之后，提取目的IP = 192.168.0.1，查詢路由表，按照最長匹配原則，最后得到查詢結果可能是0.0.0.0/0指向運營商的一條默認路由。

網關將IP報文發給運營商（上行），運營商網關收到IP報文之后，受寵若驚，也提取目的IP = 192.168.0.1，查詢路由表，匹配路由0.0.0.0/0，只想上一級運營商網關。

經過一次次的上行方向中繼，IP報文抵達核心網邊緣，核心網路由器查詢路由，很抱歉，查詢結果為空，于是丟了。

為何核心網路由器查詢結果為空？

因為核心網沒有0.0.0.0/0這條路由。

原來你訪問交換機的報文一路上行到運營商，最后被丟棄了，怎么會通信成功呢？

當然運營商為了保護自己的網絡不被類似的報文騷擾，可以在第一跳網關上檢查目的IP是否==私有IP，如果是，直接丟。如果否，才上行。

所以，當你把源主機IP修改成192.168.0.x/24，和交換機的管理IP=192.168.0.1/24 ，處于同一個網段時，就可以通信了，參考本文前述內容。

這個問題之所以引起了一點點小疑惑，是因為這臺二層交換機一身兼二職：

職位1：交換機（switch），為別的主機switching（二層）服務，無條件廣播broadcast報文。

職位2：主機（host），作為主機身份自然需要IP地址，同時擁有只給自己服務的IP路由表。切記，這個路由表只服務自己，不給廣播域內其它主機提供Routing（三層）服務。

交換機一身兼二職，當收到一個報文的時候，如何分辨是職位1的還是職位2的？

很簡單，只要判斷：

• 報文的目的MAC是否==myself。
• 報文的目的MAC是否==廣播MAC。
• 報文的目的MAC是否==自己已經Join的組播MAC，比如STP。

如果是，那就是給職位2的。否則就是給職位1的。