man一下ebtables即可知道，或者隨便想一下也會知道，ebtables在output鏈上可以做dnat，修改目的mac位址，和iptables一樣，到達output鏈的時候已經經過路由表了，只不過對於橋裝置，該路由表是乙個「mac位址-出口裝置」的對映表。我們知道，ip層的output鏈上作了dnat後需要重新路由，這是ip-dnat這個target自己完成的，在ip-output的鉤子函式中呼叫了ip_route_me_harder重新路由，然而在鏈路層的br-output中我們沒有發現重新路由的**，這樣會有問題嗎？如果做乙個實驗，發現這樣是有問題的，乙個橋兩個口，分別是1和2，如果本地發出的包準備從2發出，此時發生了dnat，dnat的結果目的mac位於1的那一側，由於沒有重新路由(查詢位址-埠對映表)，資料幀依然從2發出，啟動了stp的網路，資料幀將永遠到達不了目的地，這就出了問題了...
且慢，雖然這是個問題，然而乙太網鏈路層的路由和ip路由卻是兩碼事，其機制一點都不一樣，可以說鏈路層的路由是自動學習得到的，其方式就是眾所周知的交換機學習，而ip路由卻是需要顯式配置的，雖然有所謂的動態路由協議，但是還是需要應用層程式的幫助，對於自動學習的表項，它早晚是要收斂的，也就是說即使沒有重新路由，由於鏈路層裝置遵循要麼往特定出口發，要麼泛洪，所以dnat後的目的位址早晚會被橋裝置學習到的，鏈路層的對映表永遠都處於一種躁動不安的狀態，不像ip路由，一旦有個永久的靜態路由，output中執行了dnat不重新路由就杯具了...
既然鏈路層可以自動學習對映表，無需人工幫助，那麼br-output之後不打擾這種機制也是必要的，為何要重新路由呢？此時說不定正在泛洪，你再重路由就要重新泛洪，本來在n個口泛洪，每個口執行了dnat後重路由都可能要再次泛洪...只要dnat後的目的裝置發乙個包到達橋裝置，就算學習成功了。只有在dnat之前和之後永久的位於不同側的時候才會出現不通的問題，如果你的網路足夠大，啟用了stp，那麼不同時刻兩個位址是否位於同側是不一定的。
因此，我覺的在泛洪時不重新路由，而不泛洪時重新路由，這樣比較好。
ebtables的OUTPUT鏈DNAT問題
man一下ebtables即可知道，或者隨便想一下也會知道，ebtables在output鏈上可以做dnat，修改目的mac位址，和iptables一樣，到達output鏈的時候已經經過路由表了，只不過對於橋裝置，該路由表是乙個 mac位址 出口裝置 的對映表。我們知道，ip層的output鏈上作了...
ebtables基本使用
ebtables和 iptables 類似，都是 linux 系統下網路資料報過濾的配置工具。既然稱之為配置工具，就是說過濾功能是由核心底層提供支援的，這兩個工具只是負責制定過濾的 rules.ebtables即是乙太網橋防火牆，乙太網橋工作在資料鏈路層，ebtables 來過濾資料鏈路層資料報。2...
ebtables基本使用說明
targets 1 accept 讓幀通過 2 drop 丟棄幀。3 continue 讓幀繼續走下面的規則 rule 注意 在brouting鏈中accept和drop有不同的含義 如果是drop，則規則 到路由 iptables 去處理 內建三個表 tables 1 filter 預設使用此表，...