ebtables 的redirect target 不能把帶vlan 信息的skb的傳到三層？？？？

philarlala

最近在做linux 網(wǎng)橋的相關(guān)配置測(cè)試，發(fā)現(xiàn)ebtables的redirect target 不能把帶vlan的信息的skb傳到三層，其分析過(guò)程如下

環(huán)境：
linux 內(nèi)核版本：3.14.31
機(jī)器有兩個(gè)網(wǎng)卡分別是eth2，eth3，兩個(gè)網(wǎng)卡作為網(wǎng)橋br0的端口，
而且這個(gè)兩個(gè)端口接著都是交換機(jī)的trunk口，就是通過(guò)br0的幀都打了vlan tag， 可以帶不同的vlan id

ebtables的規(guī)則如下
-A BROUTING -p 802_1Q --vlan-encap IPv4 -j redirect  --redirect-target DROP

當(dāng)帶著vlan 信息的ip包過(guò)來(lái)的時(shí)候，碰到上面的ebtables規(guī)則，數(shù)據(jù)包經(jīng)過(guò)的路徑如下

netif_receive_skb( )->skb_vlan_untag( )->br_handle_frame( )->ebt_broute( )->ebt_do_table( )->ebt_redirect_tg( )->netif_receive_skb( )->ip_rcv( )

skb_vlan_untag( ) 會(huì)把802.1q的vlan tag的信息，放到 skb->vlan_tci 和skb->vlan_proto 這兩個(gè)值中，這時(shí)候， vlan_tx_tag_present(skb) 就會(huì)為真
ebt_redirect_tg( )  這個(gè)函數(shù)會(huì)修改eth_hdr(skb)->h_dest 和skb->pkt_type=PACKET_HOST，讓其在網(wǎng)橋中做bridged 的判斷的時(shí)候，數(shù)據(jù)包能上到上層 ;
ebt_broute ( ) 如果返回 NF_DROP,就是規(guī)則中的標(biāo)準(zhǔn)target ,br_handle_frame 就會(huì)返回RX_HANDLER_PASS 給 netif_receive_skb()這個(gè)函數(shù)

netif_receive_skb 的主要實(shí)現(xiàn)代碼在__netif_receive_skb_core 這個(gè)函數(shù),所以把這個(gè)函數(shù)的代碼的幾個(gè)關(guān)鍵點(diǎn)調(diào)出來(lái)分析了

static int __netif_receive_skb_core(struct sk_buff *skb, bool pfmemalloc){
                   ..........................
another_round:
        skb->skb_iif = skb->dev->ifindex;

        __this_cpu_inc(softnet_data.processed);

        if (skb->protocol == cpu_to_be16(ETH_P_8021Q) ||
            skb->protocol == cpu_to_be16(ETH_P_8021AD)) {
                skb = skb_vlan_untag(skb);
                if (unlikely(!skb))
                        goto unlock;
        }   
                  ............................................
        if (vlan_tx_tag_present(skb)) {
                if (pt_prev) {
                        ret = deliver_skb(skb, pt_prev, orig_dev);
                        pt_prev = NULL;
                }
                if (vlan_do_receive(&skb))
                        goto another_round;
                else if (unlikely(!skb))
                        goto unlock;
        }
        rx_handler = rcu_dereference(skb->dev->rx_handler);
        if (rx_handler) {
                if (pt_prev) {
                        ret = deliver_skb(skb, pt_prev, orig_dev);
                        pt_prev = NULL;
                }
                switch (rx_handler(&skb)) {    ------------->這里調(diào)用的實(shí)際函數(shù)就是br_handle_frame( )
                case RX_HANDLER_CONSUMED:
                        ret = NET_RX_SUCCESS;
                        goto unlock;
                case RX_HANDLER_ANOTHER:
                        goto another_round;
                case RX_HANDLER_EXACT:
                        deliver_exact = true;
                case RX_HANDLER_PASS:---->當(dāng)broute鏈返回NF_DROP的時(shí)候br_handle_frame 就返回RX_HANDLER_PASS
                        break;
                default:
                        BUG();
                }
                if (unlikely(vlan_tx_tag_present(skb))) {      -----> 當(dāng)從網(wǎng)橋的相關(guān)代碼返回的時(shí)候，就會(huì)走到這里，如果在網(wǎng)橋的代碼里面沒(méi)有對(duì)skb->vlan_tci 做任何處理的話
                                                                                ------->這個(gè)判斷就會(huì)是真 ，下面的那個(gè)判斷也是一樣 ，因此skb->pkt_type就會(huì)被改成PACKET_OTHERHOST,
                        if (vlan_tx_tag_get_id(skb))                ----->但是這個(gè)在ebt_redirect_tg()才剛把這把skb->pkt_type改為PACKET_HOST
                            skb->pkt_type = PACKET_OTHERHOST;  
                /* Note: we might in the future use prio bits
                 * and set skb->priority like in vlan_do_receive()
                 * For the time being, just ignore Priority Code Point
                 */
                        skb->vlan_tci = 0;
        }

       .....................................
}

如果 skb->pkt_type =PACKET_OTHERHOST, 當(dāng)skb傳到 ip_rcv , 這個(gè)skb會(huì)因?yàn)閟kb->pkt_type 不是PACKET_HOST，而被ip_rcv 丟掉，

上面就是整個(gè)分析過(guò)程，后來(lái)我想想，會(huì)不會(huì)有什么參數(shù)可以讓網(wǎng)橋在skb上傳到上層協(xié)議棧的時(shí)候清空skb->vlan_tci ,找了個(gè)遍，都沒(méi)有找到，
我就在ebt_redirect_tg()中做了個(gè)修改，驗(yàn)證上面的分析，結(jié)果，概率之后skb就真的能上傳到三層了，修改如下


static unsigned int  ebt_redirect_tg(struct sk_buff *skb, const struct xt_action_param *par)
{
        const struct ebt_redirect_info *info = par->targinfo;
        
        if (!skb_make_writable(skb, 0))
                return EBT_DROP;

        if (par->hooknum != NF_BR_BROUTING)
                /* rcu_read_lock()ed by nf_hook_slow */
                memcpy(eth_hdr(skb)->h_dest,
                       br_port_get_rcu(par->in)->br->dev->dev_addr, ETH_ALEN);
        else
                memcpy(eth_hdr(skb)->h_dest, par->in->dev_addr, ETH_ALEN);
        skb->pkt_type = PACKET_HOST;
   
       if (unlikely(vlan_tx_tag_present(skb))) { --->加了這個(gè)判斷和清空的操作
            skb->vlan_tci = 0;
        }
        return info->target;
}

有點(diǎn)想不明白的，為什么在__netif_receive_skb_core 中，rx_handle 返回后，要根據(jù)skb是否帶有vlan 信息把skb->pkt_type修改為PACKET_OTHERHOST呢？
難道linux 協(xié)議棧認(rèn)為，都要到三層了，skb中的vlan 信息就沒(méi)用啦，所以傳給三層的skb就應(yīng)該帶vlan 信息的了？？如果是這樣的話，那么ebt_redirect_tg()這個(gè)函數(shù)
是不是應(yīng)該考慮一下skb帶vlan信息的情況，然后做處理呢？？

另外，我試過(guò)在ebtables的nat表中的PREROUTING 添加一條同樣效果的規(guī)則，一樣存在同樣的問(wèn)題。
后來(lái)查了ebtables 中dnat的代碼，也是一樣的，沒(méi)有考慮skb帶vlan的情況的


發(fā)email到netfilter的maillist，被退信了，寫給代碼的作者又沒(méi)有回復(fù)，

大家討論一下吧，到底怎么回事，會(huì)不會(huì)是我有什么地方理解錯(cuò)誤了？？？？

Godbach

回復(fù) 1# philarlala


skb_vlan_untag 這個(gè)函數(shù)的首先看一下，感覺(jué)他應(yīng)該是調(diào)整 skb 中的一些指針。

報(bào)文進(jìn)入三層的話 ，skb->data 應(yīng)該就指向三層了。但是 vlan 的信息應(yīng)該都在的，自己可以考慮通過(guò) offset 的方式獲取過(guò)。 我說(shuō)的是通常的做法，不一定保證完全有效。需要你驗(yàn)證一下。

   

nswcfd

br_netfilter/ebtables本身就是一個(gè)hack機(jī)制，有支持不了的場(chǎng)景也不是什么新鮮事情。

在網(wǎng)橋br_handle_frame被調(diào)用之前，先經(jīng)過(guò)了一輪vlan處理，如果本地有對(duì)應(yīng)的vlan接口，則goto another_round，進(jìn)入vlan口的本地接收邏輯。
能夠進(jìn)入網(wǎng)橋邏輯，說(shuō)明前面的vlan處理失敗，即本地沒(méi)有vlan接口，所以在第二次vlan處理的時(shí)候，置位OTHER_HOST。

綜合起來(lái)就是，帶tag的報(bào)文，如果本地可以處理（有相關(guān)的vlan子接口），就修改為PACKET_HOST；
否則（即便rx_hanlder為空，不走網(wǎng)橋邏輯），還帶著tag的話，就認(rèn)為是OTHERHOST。

現(xiàn)在的處理流程，跟2.6時(shí)候的不太一樣，那里netif_receiveskb里面沒(méi)有專門針對(duì)vlan的處理邏輯，所以沒(méi)有問(wèn)題（被etable_redirect修改的packet_type不會(huì)再次被覆蓋）。

philarlala

在skb_vlan_untag( )中是有處理指針的，這個(gè)函數(shù)主要是把vlan頭的信息放到skb中放vlan 信息的成員skb->vlan_tci 和skb->vlan_proto 中，而在skb中就不會(huì)再有vlan頭的信息，這個(gè)3.14的內(nèi)核的處理和2.6.x的處理是不一樣的，在2.6.x中把skb整個(gè)打印出來(lái)，是可以看到在前面是vlan頭相關(guān)的信息的，在3.14中中打印整個(gè)skb是沒(méi)有vlan頭這些信息的回復(fù) 2# Godbach


   

philarlala

對(duì)啊，我就覺(jué)得好有點(diǎn)神奇啊，這個(gè)寫內(nèi)核的都是大神，不應(yīng)該考慮的這么草率才對(duì)的回復(fù) 3# nswcfd


   

Godbach

回復(fù) 4# philarlala

你怎么打印的？

是從二層頭部開始打印嗎？


   

nswcfd

2.6時(shí)代，vlan針對(duì)8021q注冊(cè)了一個(gè)packet_type，tag處理是在netif_receive之后完成的（不考慮硬件加速的場(chǎng)景），不像新內(nèi)核，把tag處理提前了netif_receive里面。

2.6: netif_receive_skb -> vlan_skb_recv -> untag（取決于vlan_flag） -> netif_rx -> ip_rcv
3.x: netif_receive_skb -> untag -> goto another_round(內(nèi)部循環(huán)) -> ip_rcv

以上是針對(duì)vlan虛擬子接口的情況，即本地終結(jié)vlan tag。

這跟樓主談到的vlan報(bào)文交換（bridge邏輯）還不太一樣。bridge的轉(zhuǎn)發(fā)是不關(guān)心vlan tag的（這跟絕大多數(shù)交換機(jī)的行為不太一樣）。
ebtable/broute提供了一個(gè)提前終止bridge并回退route的機(jī)制，但這機(jī)制跟vlan報(bào)文的功能組合關(guān)系恐怕沒(méi)在代碼作者的考量范圍之內(nèi)（或者沒(méi)有同步更新吧）。

樓主有沒(méi)有進(jìn)一步想一想，就算3.x沒(méi)有問(wèn)題，packet_type是host，報(bào)文送到ip_rcv，又該怎么處理？
查找路由表，找出接口，應(yīng)該是eth2、eth3、bri0的哪一個(gè)？發(fā)出去的報(bào)文，tag又是怎么被打上的？
skb上可能帶著tag的信息，但如果做了DNAT，把目的IP改成localhost，那本地發(fā)出去的應(yīng)答報(bào)文是新的skb，它的tag又是怎么指定的呢？

nswcfd

難道linux 協(xié)議棧認(rèn)為，都要到三層了，skb中的vlan 信息就沒(méi)用啦

應(yīng)該是這么個(gè)意思，讓vlan tag終結(jié)在本地三層。就算是需要轉(zhuǎn)發(fā)到其它口，也未必就是進(jìn)來(lái)方向的tag。
典型的應(yīng)用場(chǎng)景，跨vlan的路由。本來(lái)不同vlan的報(bào)文是二層相互隔離的，要想互通，只能通過(guò)三層路由來(lái)互連。

philarlala

從skb->head 開始打印回復(fù) 6# Godbach


   

philarlala

ebtable/broute提供了一個(gè)提前終止bridge并回退route的機(jī)制，但這機(jī)制跟vlan報(bào)文的功能組合關(guān)系恐怕沒(méi)在代碼作者的考量范圍之內(nèi)（或者沒(méi)有同步更新吧）

我也覺(jué)得ebtables和vlan的組合有點(diǎn)混亂的，看到4.x的內(nèi)核代碼，這一部分的內(nèi)容好像都是這樣的回復(fù) 7# nswcfd