[bridge]加入到bridge中的interface能直接与ip层通信吗？

new_learner

原帖由 kevert 于 2009-3-22 17:42 发表
之所以ICMP报文没有发送出去应该是跟ARP有关系的。
ip neigh ls 看看结果。
基本流程是这样子的：
ping报文到了网关，MAC地址是网关自己，因此br0收到这个报文，从而交给上层也就是IP层处理，IP层处理之后，找路由找到eth0，创建路由缓存，但是此时并没有对应WAN侧设备的ARP信息，因此创建一个邻居节点，将这个邻居节点和这条路由缓存关联起来，但是没有获取到ARP，所以，发送 ARP请求出去，也就是通过eth0发送ARP请求出去，这个请求的响应被网关eth0收到，本来这个请求的skb->dev指向的是eth0的，结果因为eth0又被加到桥里面去了，因此，使得这个请求被桥处理之后skb->dev变成了br0了，然后送给上层处理，此时，因为ARP请求是从eth0发出去的，但是结果回应却在ARP层看来是从br0收到的，而实际上内核创建一个邻居节点的时候需要两个条件: dev 以及 MAC地址，因此这样skb->dev变成了br0，从而导致匹配不上，从而导致ARP从eth0发送出去之后没有dev匹配不上，而导致没有响应，认为目的不可达，也就是eth0并没有学到WAN侧设备的MAC地址，而是认为可以通过br0到达，所以，你最终看到结果是学习到了ARP,但是是 br0学习到的，而不是eth0学习到的，使用 ip neigh ls 就可以很清楚的知道， arp -a 显示出来内容不够细致。

说了这么多，自己都觉得有点罗嗦了，不知道解决了你的疑问么。

不好意思回复晚了，今天公司网络有点问题。

非常感谢这位兄弟的帮忙，这个问题也正如你说的这样，与arp相关。
我试过在缓存里加入静态arp，网络就通了；如果把这条arp删掉，ping包就出不去。
分析流程也正如你描述的这样，非常准确，再次感谢你：）

当然也谢谢LS各位帮忙分析问题的兄弟！

Godbach

偶也又仔细的看了kevert 兄的分析，解释的很具体啊。系统学到ARP并不代表某个端口学到了ARP。也可能是别的端口学到的。

受益匪浅。

liyaoshi

原帖由 Godbach 于 2009-3-20 21:33 发表

作为一个桥，至少得有两个物理接口接到这个桥里面吧

一个也可以

Godbach

一个的时候怎么做转发呢？

new_learner

原帖由 kevert 于 2009-3-22 17:42 发表
之所以ICMP报文没有发送出去应该是跟ARP有关系的。
ip neigh ls 看看结果。
基本流程是这样子的：
ping报文到了网关，MAC地址是网关自己，因此br0收到这个报文，从而交给上层也就是IP层处理，IP层处理之后，找路由找到eth0，创建路由缓存，但是此时并没有对应WAN侧设备的ARP信息，因此创建一个邻居节点，将这个邻居节点和这条路由缓存关联起来，但是没有获取到ARP，所以，发送 ARP请求出去，也就是通过eth0发送ARP请求出去，这个请求的响应被网关eth0收到，本来这个请求的skb->dev指向的是eth0的，结果因为eth0又被加到桥里面去了，因此，使得这个请求被桥处理之后skb->dev变成了br0了，然后送给上层处理，此时，因为ARP请求是从eth0发出去的，但是结果回应却在ARP层看来是从br0收到的，而实际上内核创建一个邻居节点的时候需要两个条件: dev 以及 MAC地址，因此这样skb->dev变成了br0，从而导致匹配不上，从而导致ARP从eth0发送出去之后没有dev匹配不上，而导致没有响应，认为目的不可达，也就是eth0并没有学到WAN侧设备的MAC地址，而是认为可以通过br0到达，所以，你最终看到结果是学习到了ARP,但是是 br0学习到的，而不是eth0学习到的，使用 ip neigh ls 就可以很清楚的知道， arp -a 显示出来内容不够细致。

说了这么多，自己都觉得有点罗嗦了，不知道解决了你的疑问么。

这两天又看了一下代码，kevert兄是不是认为在ip_finish_output2()中，skb实际上是没有发送出去的，直接在这个函数里被free了？
见下面代码：

1. 
   
2. static inline int ip_finish_output2(struct sk_buff *skb)
   
3. {
   
4. 
   
5.         。。。。。。
   
6. 
   
7.         if (hh)
   
8.         {
   
9.                 int hh_alen;
   
10. 
    
11.                 read_lock_bh(&hh->hh_lock);
    
12.                 hh_alen = HH_DATA_ALIGN(hh->hh_len);
    
13.                   memcpy(skb->data - hh_alen, hh->hh_data, hh_alen);  /*填充ethernet header*/
    
14.                 read_unlock_bh(&hh->hh_lock);
    
15.                 skb_push(skb, hh->hh_len);
    
16.                 return hh->hh_output(skb);   /*dev_queue_xmit()*/
    
17.         }
    
18.         else if (dst->neighbour)
    
19.                 return dst->neighbour->output(skb); /*neigh_resolve_output()*/
    
20. 
    
21.         /**************** 1 ***********/
    
22.         if (net_ratelimit())
    
23.                 printk(KERN_DEBUG "ip_finish_output2: No header cache and no neighbour!\n");
    
24.         kfree_skb(skb);
    
25.         return -EINVAL;
    
26. }
    

复制代码

你的意思是不是代码运行了到了/**************** 1 ***********/处，所以skb被free掉了？

另外，根据你提到的：

IP层处理之后，找路由找到eth0，创建路由缓存，但是此时并没有对应WAN侧设备的ARP信息，因此创建一个邻居节点，将这个邻居节点和这条路由缓存关联起来，但是没有获取到ARP，所以，发送 ARP请求出去，

请问一下这个"因此创建一个邻居节点"的代码是在哪里呢？
我跟到了这个函数调用路径：

1. 
   
2. ip_route_input_slow()-->rt_intern_hash()-->arp_bind_neighbour()-->__neigh_lookup_errno()-->neigh_create()
   

复制代码

但好像还是没看到哪里在发送arp request packet？
请kevert兄指点一下迷津。。。。谢谢～

new_learner

原帖由 new_learner 于 2009-3-27 23:20 发表


你的意思是不是代码运行了到了/**************** 1 ***********/处，所以skb被free掉了？

可能我理解错了，代码应该没有运行到/**************** 1 ***********/这里
而是运行到了

1. 
   
2. else if (dst->neighbour)
   
3.                 return dst->neighbour->output(skb); /*neigh_resolve_output()*/
   

复制代码

只是dst->neighbour->output()没有运行成功。

Godbach

new_learner兄的问题还没有完全解决吗？

kevert

大概应该是这样子：
如果没有学习到ARP，那么就会将路由层发过来的报文先存储在该邻居节点的一个缓存队列上，当ARP尝试几次之后没有学到之后，就会认为该邻居不可达，从而设置该邻居的状态为NUD_FAILED，然后邻居子系统有两个定时器函数来进行定时回收，一个是全局的，一个是邻居项自己的（一个表包括很多个邻居项），在这两个定时器中会根据状态来做些事情，应该就是在这两个定时器中将数据包kfree掉的。全局的为：neigh_periodic_timer，主要是用来释放邻居节点，回收内存，数据包的释放是在 neigh_timer_handler 这个定时器中。
大概流程应该就是这样了，具体细节你可以跟进去看看。可能描述有点误差也不一定，因为很久没有接触这块了，你还是一切以代码为准吧。

new_learner

原帖由 kevert 于 2009-3-29 10:38 发表
大概应该是这样子：
如果没有学习到ARP，那么就会将路由层发过来的报文先存储在该邻居节点的一个缓存队列上，当ARP尝试几次之后没有学到之后，就会认为该邻居不可达，从而设置该邻居的状态为NUD_FAILED，然后邻 ...

谢谢kevert的讲解。
我想最后arp reply没有与arp request对应起来的根本原因在这段代码：

1. 
   
2. arp_rcv()-->arp_process()-->__neigh_lookup()-->neigh_lookup()
   
3. 
   
4. struct neighbour *neigh_lookup(struct neigh_table *tbl, const void *pkey,
   
5.                                struct net_device *dev)
   
6. {
   
7.         struct neighbour *n;
   
8.         int key_len = tbl->key_len;
   
9.         u32 hash_val = tbl->hash(pkey, dev) & tbl->hash_mask;   /*¼ÆËã³öhashÖµ*/
   
10.        
    
11.         NEIGH_CACHE_STAT_INC(tbl, lookups);
    
12. 
    
13.         read_lock_bh(&tbl->lock);
    
14.         for (n = tbl->hash_buckets[hash_val]; n; n = n->next)
    
15.         {   
    
16.                                 /*从这里可以看出，要匹配到tbl->hash_buckets里的元素，需要pkey和dev同时满足。
    
17.                      但由于对arp的处理在bridge之后(可以参看netif_receive_skb()),在tbl->hash_buckets的n->dev
    
18.                                是eth0,但接受进来的arp reply的dev却是br0，所以这里无法做到匹配,导致arp_process()中没有运行到
    
19.                      neigh_update()这个函数里*/
    
20.                 if (dev == n->dev && !memcmp(n->primary_key, pkey, key_len))
    
21.                 {
    
22.                         neigh_hold(n);
    
23.                         NEIGH_CACHE_STAT_INC(tbl, hits);
    
24.                         break;
    
25.                 }
    
26.         }
    
27.         read_unlock_bh(&tbl->lock);
    
28.         return n;   
    
29. }
    

复制代码

kevert

原帖由 new_learner 于 2009-3-31 17:49 发表

谢谢kevert的讲解。
我想最后arp reply没有与arp request对应起来的根本原因在这段代码：

arp_rcv()-->arp_process()-->__neigh_lookup()-->neigh_lookup()

struct neighbour *neigh_lookup(struct ne ...

是的，正解。因为找不到，所以导致ARP认为通过eth0无法到达该WAN设备。从而使得不通。