CRC錯誤時的交換表

Question

我對更新開關表的基本思想如何工作感到非常困惑。 如果CRC錯誤，它是否仍會更新SMAC以在下一次使用？ 也許是因為可能存在錯誤（SMAC），所以交換機將SMAC與消息一起丟棄了嗎？

另一件事是在存儲轉發模式下首先發生什么，更新表或首先發送消息？

Answer 1

首先看這張照片

場景是PC1 10.0.0.2嘗試Ping PC3 10.0.0.4 ：

1. PC1發送ARP消息（BroadCast）消息，並且該交換機是一個廣播域，這意味着它將接收廣播消息，然后將所有消息發送到所有接口上與其連接的任何設備，它將向PC2發送消息，然后PC3正常，然后詢問誰是10.0.0.4然后PC3將回答，然后再次將回答發送到交換機，並說多數民眾贊成我這是怎么發生的？

注意：您可以在Wireshark上看到這些消息

ARP消息（廣播）包含： SIP (Source IP) | DIP (Destination IP) | SMAC(Source Mac) | FF:FF:FF:FF:FF:FF (Destination MAC ~> BroadCast Message)

好的PC3答案如何？

ARP Protocol將應答然后發送SMAC (11:11:11:11:11:11) | DMAC (33:33:33:33:33:33)

所以現在Switch會將它們都保存在CAM TABLE如下圖：

好了，幀是如何發送的..它是基於Frame Check Sequence (FCS)它是通信協議中的額外檢測代碼。幀用於send upper-layer data以及最終的應用程序數據從source發送到destination但是detection這並不意味着error recovery只是定義錯誤的幀然后將其刪除，因為以太網不采取任何措施來重新傳輸，因此FSC字段包含一個源節點根據該幀中的數據計算出的數字，該數字加到了該幀的末尾，當目標節點接收到該幀時發送該幀，然后重新計算FCS編號，並將其與幀中包含的FCS編號進行比較（如果兩個編號不同，則會發生錯誤），並且該幀將被丟棄，並且發送主機會在整個幀上計算CRC並將該尾部添加到數據中，例如將其標記為數據，然后接收主機重新計算幀上的CRC，然后將其與接收到的FCS進行比較，在這種情況下，它可以檢測到任何丟失或更改的數據。 n傳輸，因此不需要更新CAM TABLE因為它不會接受任何損壞的幀，您可以通過clear mac address-table dynamic or static來清除或刷新CAM TABLE ，請閱讀有關FCS和CRC以及幀發送方式的更多信息消息https://en.wikipedia.org/wiki/Frame_check_sequence

更新

如果廣播不回復怎么辦？交換機保存了SMAC？

首先讓我給你看一個實際的例子，並顯示CAM TABLE空

好的，如果PC1嘗試ping不存在的IP地址，例如10.0.0.5該怎么辦？

ok現在再次檢查CAM TABLE

僅存儲SMAC的交換機

好的，再次去ping pc3現在它將重播

現在再次檢查CAM TABLE

好吧，如果您要刷新CAM TABLE嘗試clear mac-address-table dynamic或static