您现在的位置： Linux教程網 >> UnixLinux > >> Linux綜合 >> Linux內核

Linux內核分析 - 網絡[六]：網橋

看完了路由表，重新回到netif_receive_skb ()函數，在提交給上層協議處理前，會執行下面一句，這就是網橋的相關操作，也是這篇要講解的內容。

skb = handle_bridge(skb, &pt_prev, &ret, orig_dev);

網橋可以簡單理解為交換機，以下圖為例，一台linux機器可以看作網橋和路由的結合，網橋將物理上的兩個局域網LAN1、LAN2當作一個局域網處理，路由連接了兩個子網1.0和2.0。從eth0和eth1網卡收到的報文在Bridge模塊中會被處理成是由Bridge收到的，因此Bridge 也相當於一個虛擬網卡。

STP五種狀態

DISABLED

BLOCKING

LISTENING

LEARNING

FORWARDING

創建新的網橋br_add_bridge [net\bridge\br_if.c]

當使用SIOCBRADDBR調用ioctl時，會創建新的網橋br_add_bridge。

首先是創建新的網橋：

dev = new_bridge_dev(net, name);

然後設置dev->dev.type為br_type，而br_type是個全局變量，只初始化了一個名字變量

SET_NETDEV_DEVTYPE(dev, &br_type);     
static struct device_type br_type = {     
 .name = "bridge",     
};

然後注冊新創建的設備dev，網橋就相當一個虛擬網卡設備，注冊過的設備用ifconfig就可查看到：

ret = register_netdevice(dev);

最後在sysfs文件系統中也創建相應項，便於查看和管理：

ret = br_sysfs_addbr (dev);

將端口加入網橋br_add_if() [net\bridge\br_if.c]

當使用SIOCBRADDIF調用ioctl時，會向網卡加入新的端口br_add_if。

創建新的net_bridge_port p，會從br- >port_list中分配一個未用的port_no，p->br會指向br，p->state設為BR_STATE_DISABLED。這裡的p實際代表的就是網卡設備。

p = new_nbp(br, dev);

將新創建的p加入CAM表中，CAM表是用來記錄mac地址與物理端口的對應關系；而剛剛創建了p，因此也要加入CAM表中，並且該表項應是local的[關系如下圖]，可以看到，CAM表在實現中作為net_bridge的 hash表，以addr作為hash值，鏈入net_bridge_fdb_entry，再由它的dst指向net_bridge_port。

err = br_fdb_insert (br, p, dev->dev_addr);

設備的br_port指向p。這裡要明白的是，net_bridge可以看作全局量，是網橋，而net_bridge_port則是與網卡相對應的端口，因此每個設備dev有個指針br_port指向該端口。

rcu_assign_pointer(dev->br_port, p);

將新創建的net_bridge_port加入br的鏈表port_list中，在創建新的net_bridge_port時，會分配一個未用的port_no ，而這個port_no就是根據br->port_list中的已經添加的net_bridge_port來找到未用的port_no的[具體如下圖]。

list_add_rcu(&p->list, &br->port_list);

重新計算網橋的ID，這裡根據br->port_list鏈表中的net_bridge_port的最小的addr來作為網橋的ID。

br_stp_recalculate_bridge_id (br);

網卡設備的刪除br_del_bridge()與端口的移除add_del_if()與添加差不多，不再詳述。

熟悉了網橋的創建與添加，再來看下網橋是如何工作的。

當收到數據包，通過netif_receive_skb()->handle_bridge()處理網橋：

static inline struct sk_buff *handle_bridge(struct sk_buff *skb,     
         struct packet_type **pt_prev, int *ret,     
         struct net_device *orig_dev)     
{     
 struct net_bridge_port *port;     
         
 if (skb->pkt_type == PACKET_LOOPBACK ||     
     (port = rcu_dereference(skb->dev->br_port)) == NULL)     
  return skb;     
         
 if (*pt_prev) {     
  *ret = deliver_skb(skb, *pt_prev, orig_dev);     
  *pt_prev = NULL;     
 }     
         
 return br_handle_frame_hook(port, skb);     
}

1. 如果報文來自lo設備，或者dev->br_port為空(skb->dev是收到報文的網卡設備，而在向網橋添加端口時， dev->br_port被賦予了創建的與網卡相對應的端口p)，此時不需要網橋處理，直接返回報文；

2. 如果報文匹配了之前的 ptype_all中的協議，則pt_prev不為空，此時要先進行ptype_all中協議的處理，再進行網橋的處理；

3. br_handle_frame_hook是網橋處理鉤子函數，在br_init() [net\bridge\br.c]中

br_handle_frame_hook = br_handle_frame;

br_handle_frame() [net\bridge\br_input.c]是真正的網橋處理函數，

下面進入br_handle_frame()開始網橋部分的處理：

與前面802.1q講的一樣，首先檢查users來決定是否復制報文：

skb = skb_share_check(skb, GFP_ATOMIC);

如果報文的目的地址是01:80:c2:00:00:0X，則是發往STP的多播地址，此時調用br_handle_local_finish()來完成報文的進一步處理：

if (unlikely(is_link_local(dest))){     
……     
if (NF_HOOK(PF_BRIDGE, NF_BR_LOCAL_IN, skb, skb->dev,     
   NULL, br_handle_local_finish))     
  return NULL; /* frame consumed by filter */ 
 else 
  return skb;     
}

而br_handle_local_finish()所做的內容很簡單，因為是多播報文，主機要做的僅僅是更新報文的源mac與接收端口的關系(在CAM表中)。

static int br_handle_local_finish(struct sk_buff *skb)     
{     
 struct net_bridge_port *p = rcu_dereference(skb->dev->br_port);     
         
 if (p)     
  br_fdb_update(p->br, p, eth_hdr(skb)->h_source);     
 return 0;  /* process further */ 
}

接著br_handle_frame()繼續往下看，然後根據端口的狀態來處理報文，如果端口state= BR_STATE_FORWARDING且設置了br_should_route_hook，則轉發後返回skb；否則繼續往下執行state=BR_STATE_LEARNING段的代碼：

rhook = 

rcu_dereference(br_should_route_hook);     
if (rhook != NULL) {     
 if (rhook(skb))     
  return skb;     
 dest = eth_hdr(skb)->h_dest;     
}

如果端口state= BR_STATE_LEARNING，如果是發往本機的報文，則設置pkt_type為PACKET_HOST，然後執行 br_handle_frame_finish來完成報文的進一步處理。要注意的是，這裡將報文發往本機的報文設為PACKET_HOST，實現了經過網橋處理後，再次進入netif_receive_skb()時，不會再被網橋處理(結果進入網橋的條件理解)：

if (!

compare_ether_addr(p->br->dev->dev_addr, dest))     
  skb->pkt_type = PACKET_HOST;     
NF_HOOK(PF_BRIDGE, NF_BR_PRE_ROUTING, skb, skb->dev, NULL,     
  br_handle_frame_finish);

除此之外，端口處於不可用狀態，此時丟棄掉報文：

kfree_skb(skb);

下面來詳細看下br_handle_frame_finish()函數。

首先還是會根據收到報文的源mac和端口更新CAM表，這是交換機區別於hub的重要特征：

br_fdb_update(br, p, eth_hdr(skb)->h_source);

然後如果端口處於LEARNING狀態，則只是學習到CAM表中，而不對報文作任何處理，所以丟棄掉報文：

if (p->state == BR_STATE_LEARNING)     
  goto drop;

否則端口已處於FORWARDING狀態，此時分情況：

1. 如果報文是多播的，則br_flood_forward(br, skb, skb2);

2. 如果報文是單播的，但不在網橋的CAM表中，則br_flood_forward(br, skb, skb2);

3. 如果報文是單播的，在網橋的CAM表中，但不是發往本機，則br_forward(dst->dst, skb, skb2);

4. 如果報文是單播的，在網橋的CAM表中，且是發往本機，則br_pass_frame_upbr_pass_frame_up(skb2);

br_handle_frame_finish()處理完後，順著最後一種情況繼續往下走，br_pass_frame_up()。

該函數比較簡單，我們知道，在底層報文的向上傳遞就是通過設備的更換來進行的(參考802.1q)，這裡將skb的設備換成網橋設備，使上層協議不知道報文來自網卡，而是認為報文來自於網橋；然後調用 netif_receive_skb()再次進入接收棧：

skb->dev = brdev;     
return NF_HOOK(PF_BRIDGE, NF_BR_LOCAL_IN, skb, indev, NULL,     
         netif_receive_skb);

經過網橋處理後，再次進入netif_receive_skb()->handle_bridge()，此時skb- >dev已經不是網卡設備了，而是網橋設備，注意到在向網橋添加端口時，是相應網卡dev->br_port賦值為創建的端口，網橋設備是沒有的，因此其br_port為空，在這一句會直接返回，進入正常的協議棧流程：

if (skb->pkt_type == 

PACKET_LOOPBACK ||     
     (port = rcu_dereference(skb->dev->br_port)) == NULL)     
  return skb;

當發送數據報文時，會調用br_dev_xmit()[net\bridge\br_device.c]，大致會根據目的地址調用 br_multicast_deliver()或br_flood_deliver()或br_deliver()，在其過程中會將skb->dev由原來的網橋設備brdev換面網卡設備dev，然後通過網卡變更向下傳遞報文；

內核協議棧中，發送與接收是分離的，接收像是報文脫殼的過程，發送則是函數的嵌套調用。有關發送的流程，稍後專門詳述。