a. 網橋的工作原理初識
l 緩存：網橋首先會對收到的數據幀進行緩存並處理；
學習：當幀經過網橋，網橋首先在網橋表中查找幀的源MAC地址，如果該地址不在網橋表中，則將有該MAC地址及其所對應的網橋端口信息加入（逆向學習法）；
l 過濾：判斷入幀的目標節點是否位於發送這個幀的網段中(同一端口中) ，如果是，網橋就不把幀轉發到網橋的其他端口；
l 轉發：如果幀的目標節點位於另一個網絡，網橋就將幀發往正確的網段 (向另一端口轉發) ；
每個橋維護了一個基於MAC地址的過濾數據庫，網橋根據這個數據庫，把收到的幀往相應的局域網（端口）進行轉發。
在過濾數據庫中，列出了每個可能的目的地（目的MAC地址），以及它屬於哪一條輸出線路（一個端口號，即表示轉發給哪個LAN），每個表項還有一個超時設置。
可以及時學習改變了的地址；
轉發：如果在表中找到目標地址，則直接轉發給該目的MAC地址對應的端口；
轉發：如果在表中找不到目標地址，則按擴散的辦法將該數據發送給與該網橋連接的除發送該數據的網段外的所有網段。
以混雜方式工作（接收連接到該網橋的局域網上傳送的所有幀）。
b. 網橋的工作過程
l 假設橋在端口x上接收到一個MAC幀，有如下規則
1. 查詢網橋表中包的源MAC；如果沒有，將該MAC地址及其所對應的網橋端口信息加入；如果有，繼續下一步；
2. 查詢過濾數據庫，確定該目的MAC地址是否在除[端口x]外的其它端口中；如果目的MAC地址在端口x內，不進行轉發；
3. 在轉發時，如果目的MAC地址在過濾數據庫中的某個端口y中，確定端口y是否處在阻塞或轉發狀態（生成樹協議）。【在以後的生成樹算法中我們可以看到，一個端口可能有時候是阻塞的，以防止它接收或發送幀】如果端口y是非阻塞的，把該幀通過端口y轉發到它所連接的LAN中。
4. 在轉發時，如果目的MAC地址沒有找到，把該幀往除了它所到來的端口外的所有端口發送，即進行轉發（擴散）。
c. 網橋的場景解析
學習：站點A給B發送數據，網橋通過察看幀的源地址瞭解到A在端口1，過濾數據庫中加入<A,1>。
轉發：網橋並不知道B在何處，因此把幀向所有其它端口（即端口2和3）進行擴散。（網橋連接的所有端口，除端口1）
轉發：B收到A發過來的幀之後，可能會進行迴應，即B發送數據給A，這個時候網橋察看源地址瞭解到B在端口2上，加入表項<B,2>，同時幀的目的地址A在過濾數據庫中存在，並且在端口1上，因此B發回給A的幀向端口1轉發
過濾：現在站點C向A發送數據，由於A、C和網橋連接到同一個集線器上，網橋也會收到該幀，察看源地址C，記錄C在端口1，加入表項<C,1>，同時目的地址A在過濾數據庫中並且所在的端口正是收到該幀的端口，因此不進行轉發。
老化：過濾數據庫表項的TTL每秒都增加，超過某個值則從數據庫中清除，一般缺省的TTL設置爲300秒。老化主要是考慮到網橋的內存有限、節點移動的情況。
d. Bridge講解一
Bridge（橋）是 Linux 上用來做 TCP/IP 二層協議交換的設備，與現實世界中的交換機功能相似。Bridge 設備實例可以和 Linux 上其他網絡設備實例連接，既 attach 一個從設備，類似於在現實世界中的交換機和一個用戶終端之間連接一根網線。當有數據到達時，Bridge 會根據報文中的 MAC 信息進行廣播、轉發、丟棄處理。
如圖所示，Bridge 的功能主要在內核裏實現。當一個從設備被 attach 到 Bridge 上時，相當於現實世界裏交換機的端口被插入了一根連有終端的網線。這時在內核程序裏，netdev_rx_handler_register()被調用，一個用於接受數據的回調函數被註冊。以後每當這個從設備收到數據時都會調用這個函數可以把數據轉發到 Bridge 上。當 Bridge 接收到此數據時，br_handle_frame()被調用，進行一個和現實世界中的交換機類似的處理過程：判斷包的類別（廣播/單點），查找內部 MAC 端口映射表，定位目標端口號，將數據轉發到目標端口或丟棄，自動更新內部 MAC 端口映射表以自我學習。
Bridge 和現實世界中的二層交換機有一個區別，圖中左側畫出了這種情況：數據被直接發到 Bridge 上，而不是從一個端口接受。這種情況可以看做 Bridge 自己有一個 MAC 可以主動發送報文，或者說 Bridge 自帶了一個隱藏端口和寄主 Linux 系統自動連接，Linux 上的程序可以直接從這個端口向 Bridge 上的其他端口發數據。所以當一個 Bridge 擁有一個網絡設備時，如 bridge0 加入了 eth0 時，實際上 bridge0 擁有兩個有效 MAC 地址，一個是 bridge0 的，一個是 eth0 的，他們之間可以通訊。由此帶來一個有意思的事情是，Bridge 可以設置 IP 地址。通常來說 IP 地址是三層協議的內容，不應該出現在二層設備 Bridge 上。但是 Linux 裏 Bridge 是通用網絡設備抽象的一種，只要是網絡設備就能夠設定 IP 地址。當一個 bridge0 擁有 IP 後，Linux 便可以通過路由表或者 IP 表規則在三層定位 bridge0，此時相當於 Linux 擁有了另外一個隱藏的虛擬網卡和 Bridge 的隱藏端口相連，這個網卡就是名爲 bridge0 的通用網絡設備，IP 可以看成是這個網卡的。當有符合此 IP 的數據到達 bridge0 時，內核協議棧認爲收到了一包目標爲本機的數據，此時應用程序可以通過 Socket 接收到它。一個更好的對比例子是現實世界中的帶路由的交換機設備，它也擁有一個隱藏的 MAC 地址，供設備中的三層協議處理程序和管理程序使用。設備裏的三層協議處理程序，對應名爲 bridge0 的通用網絡設備的三層協議處理程序，即寄主 Linux 系統內核協議棧程序。設備裏的管理程序，對應 bridge0 寄主 Linux 系統裏的應用程序。
Bridge 的實現當前有一個限制：當一個設備被 attach 到 Bridge 上時，那個設備的 IP 會變的無效，Linux 不再使用那個 IP 在三層接受數據。舉例如下：如果 eth0 本來的 IP 是 192.168.1.2，此時如果收到一個目標地址是 192.168.1.2 的數據，Linux 的應用程序能通過 Socket 操作接受到它。而當 eth0 被 attach 到一個 bridge0 時，儘管 eth0 的 IP 還在，但應用程序是無法接受到上述數據的。此時應該把 IP 192.168.1.2 賦予 bridge0。
另外需要注意的是數據流的方向。對於一個被 attach 到 Bridge 上的設備來說，只有它收到數據時，此包數據纔會被轉發到 Bridge 上，進而完成查表廣播等後續操作。當請求是發送類型時，數據是不會被轉發到 Bridge 上的，它會尋找下一個發送出口。用戶在配置網絡時經常忽略這一點從而造成網絡故障。
e. Bridge講解二
如下圖：主機A發送的報文被送到交換機S1的eth0口，由於eth0與eth1、eth2橋接在一起，故而報文被複制到eth1和eth2，並且發送出去，然後被主機B和交換機S2接收到。而S2又會將報文轉發給主機C、D。
交換機在報文轉發的過程中並不會篡改報文數據，只是做原樣複製。然而橋接卻並不是在物理層實現的，而是在數據鏈路層。交換機能夠理解數據鏈路層的報文，所以實際上橋接卻又不是單純的報文轉發。
交換機會關心填寫在報文的數據鏈路層頭部中的Mac地址信息（包括源地址和目的地址），以便了解每個Mac地址所代表的主機都在什麼位置（與本交換機的哪個網口相連）。在報文轉發時，交換機就只需要向特定的網口轉發即可，從而避免不必要的網絡交互。這個就是交換機的“地址學習”。但是如果交換機遇到一個自己未學習到的地址，就不會知道這個報文應該從哪個網口轉發，則只好將報文轉發給所有網口（接收報文的那個網口除外）。
比如主機C向主機A發送一個報文，報文來到了交換機S1的eth2網口上。假設S1剛剛啓動，還沒有學習到任何地址，則它會將報文轉發給eth0和eth1。同時，S1會根據報文的源Mac地址，記錄下“主機C是通過eth2網口接入的”。於是當主機A向C發送報文時，S1只需要將報文轉發到eth2網口即可。而當主機D向C發送報文時，假設交換機S2將報文轉發到了S1的eth2網口（實際上S2也多半會因爲地址學習而不這麼做），則S1會直接將報文丟棄而不做轉發（因爲主機C就是從eth2接入的）。
然而，網絡拓撲不可能是永不改變的。假設我們將主機B和主機C換個位置，當主機C發出報文時（不管發給誰），交換機S1的eth1口收到報文，於是交換機S1會更新其學習到的地址，將原來的“主機C是通過eth2網口接入的”改爲“主機C是通過eth1網口接入的”。
但是如果主機C一直不發送報文呢？S1將一直認爲“主機C是通過eth2網口接入的”，於是將其他主機發送給C的報文都從eth2轉發出去，結果報文就發丟了。所以交換機的地址學習需要有超時策略。對於交換機S1來說，如果距離最後一次收到主機C的報文已經過去一定時間了（默認爲5分鐘），則S1需要忘記“主機C是通過eth2網口接入的”這件事情。這樣一來，發往主機C的報文又會被轉發到所有網口上去，而其中從eth1轉發出去的報文將被主機C收到。