學不到伺服器的mac地址

A. 一台伺服器開不起來了，找人修修不好，但是現在需要伺服器的MAC地址，怎樣才能知道這台伺服器的MAC地址呢

伺服器設置里能看到
管理口登進去也可以
實在不行交換機上也有Mac地址表

B. dell 交換機學不到mac 地址

交換機如果硬體沒問題那就是配置的問題，先查看一下mac表，源mac和目標mac需要在同一網段。
交換機(英文:Switch，意為「開關」)是一種用於電信號轉發的網路設備。它可以為接入交換機的任意兩個網路節點提供獨享的電信號通路。最常見的交換機是乙太網交換機。其他常見的還有電話語音交換機、光纖交換機等。
交換機的傳輸模式有全雙工，半雙工，全雙工/半雙工自適應 。 交換機的全雙工是指交換機在發送數據的同時也能夠接收數據，兩者同步進行，這好像我們平時打電話一樣，說話的同時也能夠聽到對方的聲音。目前的交換機都支持全雙工。全雙工的好處在於遲延小，速度快

C. 網路設備埠可以學到伺服器的mac地址意味著什麼

MAC地址是固化在網卡上串列EEPROM中的物理地址，通常有48位長。
乙太網交換機根據某條信息包頭中的MAC源地址和MAC目的地址實現包的交換和傳遞。
要搭建區域網，必須學會綁定IP與MAC地址；
換了新網卡，必須學會修改MAC地址以應對不能上網的尷尬。
不要讓MAC地址成為網上生活的絆腳石呦。
獲取本機的MAC
對於數量不多的幾台機器，可以這樣獲取MAC地址：在Windows 98/Me中，依次單擊「開始」→「運行」 →輸入「winipcfg」→回車。
在Windows 2000/XP中，依次單擊「開始」→「運行」→輸入「CMD」→回車→輸入「ipconfig /all」→回車。
對於如何批量獲取MAC地址
IP與MAC的捆綁
MAC地址是網卡的惟一標識，這種惟一性恰好給網路管理帶來了福音，因為通過捆綁IP和MAC地址，就可以輕松防止區域網中IP地址盜用現象，阻止非法入侵者。
對於動態IP，做一個DHCP伺服器來綁定用戶網卡MAC地址和IP地址，然後再根據不同IP設定許可權；
對於靜態IP，如果用三層交換機，可以在交換機的每個埠上做IP地址的限定，這樣如果改變某台客戶端的IP地址，這台PC也就不能連通網路了。
以靜態IP地址的綁定為例，實現一下上面的高招：假設此時的網卡MAC地址為44-45-53-54-00-00。
假設在Windows 98操作系統中，啟動虛擬DOS後，鍵入「ARP空格-s空格192.168.0.66空格44-45-53-54-00-00」，回車。
這樣實現了靜態 IP地址192.168.0.66與網卡地址為44-45-53-54-00-00的計算機的捆綁，接下來看看ARP常用參數表。
特別提示：ARP命令僅在區域網中上網的代理伺服器端有用，還要是靜態IP地址。
如果是一名網路管理員，就必須對MAC地址和IP的綁定運用自如，這樣才能杜絕很多隱患。

D. WEB伺服器為什麼取不到用戶的MAC地址

起因是某個同事接到了領導安排下來的一個需求，要在一個Web應用（Java+Tomcat）中，記錄用戶登錄時的IP地址和MAC地址，用於安全審計，於是咨詢我如何實現。

第一反應是，這個需求本身是不成立的，根據以往的了解，MAC地址應該是過不了路由器的才對。
以往做開發，都是用engineer的思維：先動手做，遇到問題再解決問題。但這個需求，應當用scientist的思維去思考：首先確定能不能做，然後才是怎麼做。

翻查了一些資料，想來證實" 為什麼WEB伺服器，可以獲取到客戶端的IP地址，但獲取不到MAC地址 "，看著看著才發現，這是個挺大的命題，夠寫一篇BLOG了。

PS：由於個人對這塊內容了解的不夠徹底， 本文很可能會有謬誤 ，請讀者先不要太當真，另外希望平台組的同事給予指證。

我所認為的結論應該是這樣的：

下面一步步解釋一下。

先從HTTP說起。
HTTP是一個應用層的協議，它建立在TCP協議之上。
HTTP請求就是用來發送一段文本。關於這段文本如何組織，第一行寫什麼，第二行寫什麼，哪裡加一個空行，就是HTTP協議所要規范的內容。
舉個直接的例子，下面是一個簡單的HTTP GET請求，有興趣可以用telnet模擬一下。

我們可以看到，HTTP的這段請求中，完全找不到客戶端的MAC地址，甚至連IP地址都沒有描述。
那IP地址是從哪裡取到的呢？接下來我們再深入一點，看下一個內容：Socket

HTTP的客戶端和服務端，是通過Socket進行連接的。

Socket是什麼呢？ Socket是對OSI模型第4層-傳輸層中的TCP/IP協議的封裝 。Socket本身並不是協議，而 是一個調用介面 (API)。Socket和TCP/IP協議沒有必然的聯系。但通過Socket，我們才能使用TCP/IP協議。應用層不必了解TCP/IP協議細節，直接通過對Socket介面函數的調用完成數據在IP網路的傳輸。

Socket包含了網路通信必須的五種信息： 連接使用的協議，本地主機的IP地址，本地進程的協議埠，遠地主機的IP地址，遠地進程的協議埠 。

所以，因為有了Socket，客戶端和服務端完全不需要了解底層細節，直接通過調用Socket來實現就可以了。

這也就是為什麼伺服器端 可以獲取到客戶端的IP地址 的原因，因為Socket中包含了遠地主機的IP地址。（當然，通過代理伺服器進行訪問的除外，這種要依靠HTTP協議的X-Forwarded-For頭來確認IP，不在本次的討論范圍中）

那為什麼 無法獲取到客戶端的MAC地址 呢？很簡單，同理，因為Socket中無法取到MAC地址。。。

如果繼續發問，為什麼Socket中都既然都包含IP地址了，為什麼偏偏不包含MAC地址信息呢？看來我們還要更深入一點，看一下OSI模型吧。

首先祭出這張經典的OSI七層模型圖，計算機網路的基石，請先盯著看一會兒，認真復習一下

這里還有一張OSI七層模型與TCP/IP四層模型的對照圖

為了方便理解，再放上一張更直觀的，每一層對應的數據型式和主要協議的示意圖

通過上圖大體可以知道：

下面舉個栗子，當我們在瀏覽器中打開一個鏈接後，看看OSI各層倒底發生了什麼：
這里撇開DNS解析之類東西，只說一下HTTP報文的發送

首先來看一下發送端（瀏覽器所在的主機）。參照第一張OSI模型圖，按照從上向下的順序來看。應用層數據其實只有那麼幾行文本，然後往下，每過一層，都要被加上首部/尾部。 這個過程就像是一層一層的穿衣服 。

HTTP請求文本：

數據發出去後，再看一下數據在網路上的流轉。
數據一般要經過交換機、路由器等網路設備，層層轉發，這些設備所做的事情就像是： 脫掉一件或幾件衣服，做一些修修補補，然後再重新穿回去 。

通過上面這張圖，我們就可以理解，MAC地址在本地網路下的重要作用了。也理解了，本地網路下，是可以查出每個節點的MAC地址的。

經過路由器後，為了能到達下一跳，數據鏈路層中的MAC地址就被篡改了，下面這張圖很能說明問題：

最後看一下接收端（WEB伺服器所在的主機）。參照第一張OSI模型圖，按照從下至上的順序來看，它要做的事情是： 將衣服一件一件全部脫掉 ，最後WEB伺服器就取到了最初的應用層數據。

所以，當一個乙太網幀到達目的主機後，其中的MAC地址早已經不是原來客戶端的MAC了，操作系統的Socket自然也無法獲取原始的MAC地址了。

上面已經證明了，WEB服務端，是無法獲取客戶端的MAC地址的。
那麼，能不能通過一些trick來繞道實現呢？
想了想，大概可以有如下的思路：

那麼這個思路可不可行呢？

最後的最後，不禁思考，獲取MAC的意義在哪裡呢？
如果單純是為了取證和審計，我想意義是不大的，甚至不如直接記錄IP地址。
因為：

所以，一般的安全管控要求下，還是只記錄IP吧。

E. 伺服器的MAC硬體地址

如果客戶機和伺服器在同一個網段，那麼你可以通過簡單的ping和arp命令來獲得伺服器的MAC地址。
如果客戶機和伺服器不在同一網段，也就是說中間存在路由器連接，那麼就沒有辦法獲得伺服器的MAC地址了，就算是獲得了也沒有什麼用。

F. 交換機學不到mac是什麼問題

可以首先檢查接pc的物理線路是否正常，如果是所有埠都無法學習到mac，可檢查是否關閉了交換機的自動學習功能，如果都沒問題那麼可以懷疑硬體問題！