On 3/7/24 04:50, Zhangweiwei wrote:
> I have configured vlan-limit to 0, but the packets still are not delivered to
> mitapVm72.
> Here is the track information:
>
> [root@localhost ~]# ovs-vsctl set o . other_config:vlan-limit=0
> [root@localhost ~]#
> [root@localhost ~]# ovs-appctl ofproto/trace vds1-br in_port=tapVm72
> 52540067d5615254009abfed8100006408004500005458ad4000400151f502024602020246010800dde3067a0078e030e9650000000088c0020000000000101112131415161718191a1b1c1d1e1f202122232425262728292a2b2c2d2e2f3031323334353637
> Flow:
> icmp,in_port=6,dl_vlan=100,dl_vlan_pcp=0,vlan_tci1=0x0000,dl_src=52:54:00:9a:bf:ed,dl_dst=52:54:00:67:d5:61,nw_src=2.2.70.2,nw_dst=2.2.70.1,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,icmp_type=8,icmp_code=0
>
> bridge("vds1-br")
> -----------------
> 0. in_port=6, priority 32768
> >>>> dropping VLAN 100 tagged packet received on port tapVm72 configured
> as VLAN 0 access port <<<<
> output:3
> >>>> dropping VLAN 100 tagged packet received on port tapVm71 configured
> as VLAN 0 access port <<<<
>
> Final flow: unchanged
> Megaflow: recirc_id=0,eth,ip,in_port=6,nw_frag=no
> Datapath actions: 6
>
>
> Packets are mirrored in this function. input_vid_is_valid() checked failed
> when a packet with vlan ingress on tapVm72 , because tapVm72 is an access
> port.
I see. That makes sense. The issue is caused by the mix of the NORMAL
pipeline processing and direct forwarding. There are two ways you can
fix the issue:
1. Remove the tag 0 from the ports, so they are not access ports anymore.
Is there a reason for them to be access ports if you're not using the
NORMAL action? Also, the tag 0 is a special value that can be ignored,
so I'd advise to not use it.
2. Change the type from access to dot1q-tunnel. This way double tagging
will be allowed and the packets should not be dropped anymore.
I don't think the vlan check can be easily removed from the mirroring
code, because we should not mirror a packet if it is going to be dropped
by a NORMAL pipleline later.
Best regrads, Ilya Maximets.
> mirror_packet(struct xlate_ctx *ctx, struct xbundle *xbundle,
> mirror_mask_t mirrors)
> {
> struct xvlan in_xvlan;
> struct xvlan xvlan;
>
> /* Figure out what VLAN the packet is in (because mirrors can select
> * packets on basis of VLAN). */
> xvlan_extract(&ctx->xin->flow, &in_xvlan);
> if (!input_vid_is_valid(ctx, in_xvlan.v[0].vid, xbundle)) {
> return;
> }
>
> -----邮件原件-----
> 发件人: Ilya Maximets [mailto:i.maxim...@ovn.org]
> 发送时间: 2024年3月6日 19:43
> 收件人: zhangweiwei (RD) <zhang.wei...@h3c.com>; ovs-discuss@openvswitch.org
> 抄送: i.maxim...@ovn.org
> 主题: Re: [ovs-discuss] Mirror: ovs-tcpdump cannot capture vlan packets on the
> port with tag
>
> On 3/6/24 08:54, Zhangweiwei via discuss wrote:
>> Hi,
>>
>> I set tag 0 on port tapVm72and tapVm71, and then send ping packets
>> with vlan
>> 100 from tapVm72to tapVm71. But ovs-tcpdump cannot capture any packets
>> with vlan on tapVm72. It seems that vlan check is failed in
>> mirror_packet(), because
>> tapVm72 is an access port and the vlan packets are dropped. This is
>> not reasonable because OVS does not use NORMAL forward. When using
>> custom OpenFlow tables, mirror action should not consider tag configuration.
>
> I don't think that is related to tapVm72 being an access port.
> Could you, please, run ovs-appctl ofproto/trace on a packet arriving from
> tapVm72 ?
>
> Note that since mitapVm72 is not in vlan 0, mirrored traffic will have both
> vlan tags pushed to the packet. For this to work the vlan-limit
> configuration should be 2 or 0 (unlimited). Default value is 1 and that may
> be one reason why packets are not delivered to mitapVm72. ofproto/trace
> should be able to confirm if that is the case.
>
> Best regards, Ilya Maximets.
>
>>
>> 1、ovs version: 3.2.1
>> 2、Bridge
>> [root@localhost openvswitch-3.2.1]# ovs-vsctl show
>> Bridge vds1-br
>> Controller "tcp:172.20.66.228:6633"
>> is_connected: true
>> Controller "tcp:172.20.66.229:6633"
>> is_connected: true
>> fail_mode: secure
>> datapath_type: netdev
>> Port vxlan_vds1-br
>> Interface vxlan_vds1-br
>> type: vxlan
>> options: {key=flow, local_ip="3.3.3.70",
>> remote_ip=flow, tos=inherit}
>> Port tapVm72
>> tag: 0
>> Interface tapVm72
>> type: dpdkvhostuserclient
>> options:
>> {vhost-server-path="/var/run/openvswitch/tapVm72"}
>> Port mitapVm72
>> Interface mitapVm72
>> Port tapVm71
>> tag: 0
>> Interface tapVm71
>> type: dpdkvhostuserclient
>> options:
>> {vhost-server-path="/var/run/openvswitch/tapVm71"}
>> Port vds1-br
>> Interface vds1-br
>> type: internal
>> ovs_version: "3.2.1"
>>
>> 3、dpcls:
>>
>> [[root@localhost openvswitch-3.2.1]# ovs-appctl dpctl/dump-flows -m |
>> grep tap
>>
>> ufid:21fadb70-e3c1-4a2c-a0db-a042daa051c4,
>> recirc_id(0),dp_hash(0/0),skb_priority(0/0),in_port(tapVm71),skb_mark(
>> 0/0),ct_state(0/0x30),ct_zone(0/0),ct_mark(0/0),ct_label(0/0),packet_t
>> ype(ns=0,id=0),eth(src=52:54:00:67:d5:61,dst=52:54:00:9a:bf:ed),eth_ty
>> pe(0x8100),vlan(vid=100,pcp=0/0x0),encap(eth_type(0x0800),ipv4(src=2.2
>> .70.1,dst=2.2.70.2/255.255.192.0,proto=1,tos=0/0,ttl=64/0,frag=no),icm
>> p(type=0/0,code=0/0)), packets:4388, bytes:447576, used:0.420s,
>> dp:ovs, actions:tapVm72, dp-extra-info:miniflow_bits(5,2)
>>
>> ufid:83a55534-3c62-4415-9aa7-bd8486675c68,
>> recirc_id(0),dp_hash(0/0),skb_priority(0/0),in_port(tapVm72),skb_mark(
>> 0/0),ct_state(0/0x30),ct_zone(0/0),ct_mark(0/0),ct_label(0/0),packet_t
>> ype(ns=0,id=0),eth(src=52:54:00:9a:bf:ed,dst=52:54:00:67:d5:61),eth_ty
>> pe(0x8100),vlan(vid=100,pcp=0/0x0),encap(eth_type(0x0800),ipv4(src=2.2
>> .70.2,dst=2.2.70.1/255.255.192.0,proto=1,tos=0/0,ttl=64/0,frag=no),icm
>> p(type=8/0,code=0/0)), packets:4388, bytes:447576, used:0.420s,
>> dp:ovs, actions:tapVm71, dp-extra-info:miniflow_bits(5,2)
>
> -------------------------------------------------------------------------------------------------------------------------------------
> 本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出
> 的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、
> 或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本
> 邮件！
> This e-mail and its attachments contain confidential information from New
> H3C, which is
> intended only for the person or entity whose address is listed above. Any use
> of the
> information contained herein in any way (including, but not limited to, total
> or partial
> disclosure, reproduction, or dissemination) by persons other than the intended
> recipient(s) is prohibited. If you receive this e-mail in error, please
> notify the sender
> by phone or email immediately and delete it!
_______________________________________________
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
