Hello. We have a problem with the flow field "nd_target" at IPv6 again.
We already had a similar problem https://mail.openvswitch.org/pipermail/ovs-discuss/2017-November/045618.html. At that time, the problem was solved by adding the field "icmp_code=0". Everything worked fine until we upgraded from version 2.17.1 to version 2.17.2 (and newer). For example, We use Ubuntu 22.04: # cat /proc/version Linux version 5.15.0-52-generic (buildd@lcy02-amd64-032) (gcc (Ubuntu 11.2.0-19ubuntu1) 11.2.0, GNU ld (GNU Binutils for Ubuntu) 2.38) #58-Ubuntu SMP Thu Oct 13 08:03:55 UTC 2022 We have a VM with virtual interfaces vnet0. At the bridge set fail_mode to "secure": # ovs-vsctl list br public-switch | grep fail_mode* fail_mode : secure The interface bond0.6 is an external interface. We added two flows for the test: # ovs-ofctl --no-stat dump-flows public-switch cookie=0x1212, priority=1212,icmp6,icmp_type=135,icmp_code=0,nd_target=2a03:f480:2:a::1f actions=output:vnet0 cookie=0x2, priority=2,icmp6,in_port="bond0.6",icmp_type=135,icmp_code=0 actions=drop So, all ICMP6 traffic with type 135 and code 0 and if nd_target field equals to IPv6 address 2a03:f480:2:a::1f the traffic must send to vnet0 (VM have IPv6 2a03:f480:2:a::1f). All other traffic should be dropped. This is how it worked until version 2.17.1 # ovs-vswitchd --version ovs-vswitchd (Open vSwitch) 2.17.1 # ovs-dpctl --more --names dump-flows filter="icmp6" ufid:a0a9b704-2127-407a-a09e-283c71625563, recirc_id(0),dp_hash(0/0),skb_priority(0/0),in_port(bond0.6),skb_mark(0/0),ct_state(0/0),ct_zone(0/0),ct_mark(0/0),ct_label(0/0),eth(src=00:00:00:00:00:00/00:00:00:00:00:00,dst=00:00:00:00:00:00/00:00:00:00:00:00),eth_type(0x86dd),ipv6(src=::/::,dst=::/::,label=0/0,proto=58,tclass=0/0,hlimit=0/0,frag=no),icmpv6(type=135,code=0),nd(target=2a03:f480:2:6::a3,sll=00:00:00:00:00:00/00:00:00:00:00:00,tll=00:00:00:00:00:00/00:00:00:00:00:00), packets:6, bytes:516, used:0.280s, dp:ovs, actions:drop ufid:ac28d296-a0a7-4fba-a143-129167b36f43, recirc_id(0),dp_hash(0/0),skb_priority(0/0),in_port(bond0.6),skb_mark(0/0),ct_state(0/0),ct_zone(0/0),ct_mark(0/0),ct_label(0/0),eth(src=00:00:00:00:00:00/00:00:00:00:00:00,dst=00:00:00:00:00:00/00:00:00:00:00:00),eth_type(0x86dd),ipv6(src=::/::,dst=::/::,label=0/0,proto=58,tclass=0/0,hlimit=0/0,frag=no),icmpv6(type=135,code=0),nd(target=2a03:f480:2:5::cb,sll=00:00:00:00:00:00/00:00:00:00:00:00,tll=00:00:00:00:00:00/00:00:00:00:00:00), packets:0, bytes:0, used:never, dp:ovs, actions:drop ufid:0e2e4f37-fb5d-4256-9ec0-ea4bd6d3c8c0, recirc_id(0),dp_hash(0/0),skb_priority(0/0),in_port(bond0.6),skb_mark(0/0),ct_state(0/0),ct_zone(0/0),ct_mark(0/0),ct_label(0/0),eth(src=00:00:00:00:00:00/00:00:00:00:00:00,dst=00:00:00:00:00:00/00:00:00:00:00:00),eth_type(0x86dd),ipv6(src=::/::,dst=::/::,label=0/0,proto=58,tclass=0/0,hlimit=0/0,frag=no),icmpv6(type=135,code=0),nd(target=2a03:f480:2:6::59,sll=00:00:00:00:00:00/00:00:00:00:00:00,tll=00:00:00:00:00:00/00:00:00:00:00:00), packets:6, bytes:516, used:0.280s, dp:ovs, actions:drop As you can see in the "ovs-dpctl" output the field "nd_target" is not "::/::" and has a value in the form of IPv6 address. # ovs-appctl ofproto/trace public-switch in_port=1,icmp6,icmpv6_type=135,nd_target=2a03:f480:2:a::1f Flow: icmp6,in_port=1,vlan_tci=0x0000,dl_src=00:00:00:00:00:00,dl_dst=00:00:00:00:00:00,ipv6_src=::,ipv6_dst=::,ipv6_label=0x00000,nw_tos=0,nw_ecn=0,nw_ttl=0,icmp_type=135,icmp_code=0,nd_target=2a03:f480:2:a::1f,nd_sll=00:00:00:00:00:00,nd_tll=00:00:00:00:00:00 bridge("public-switch") ----------------------- 0. icmp6,icmp_type=135,icmp_code=0,nd_target=2a03:f480:2:a::1f, priority 1212, cookie 0x1212 output:2 Final flow: unchanged Megaflow: recirc_id=0,eth,icmp6,in_port=1,nw_frag=no,icmp_type=0x87/0xff,icmp_code=0x0/0xff,nd_target=2a03:f480:2:a::1f Datapath actions: 3 The tcpdump output inside of VM: # tcpdump -nn -i ens3 icmp6 tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on ens3, link-type EN10MB (Ethernet), snapshot length 262144 bytes 16:45:24.360169 IP6 2a03:f480:2::1 > ff02::1:ff00:1f: ICMP6, neighbor solicitation, who has 2a03:f480:2:a::1f, length 32 16:45:24.360429 IP6 2a03:f480:2:a::1f > 2a03:f480:2::1: ICMP6, neighbor advertisement, tgt is 2a03:f480:2:a::1f, length 32 16:45:25.386965 IP6 2a03:f480:2::1 > ff02::1:ff00:1f: ICMP6, neighbor solicitation, who has 2a03:f480:2:a::1f, length 32 16:45:25.387025 IP6 2a03:f480:2:a::1f > 2a03:f480:2::1: ICMP6, neighbor advertisement, tgt is 2a03:f480:2:a::1f, length 32 16:45:26.410914 IP6 2a03:f480:2::1 > ff02::1:ff00:1f: ICMP6, neighbor solicitation, who has 2a03:f480:2:a::1f, length 32 16:45:26.410962 IP6 2a03:f480:2:a::1f > 2a03:f480:2::1: ICMP6, neighbor advertisement, tgt is 2a03:f480:2:a::1f, length 32 Everything works as it should. The flow field "nd_target" did not work any more when we upgraded OpenvSwitch to version 2.17.2. # ovs-vswitchd --version ovs-vswitchd (Open vSwitch) 2.17.2 We added the same flows. # ovs-dpctl --more --names dump-flows filter="icmp6" ufid:3adcd133-4486-4843-8b40-3202aeb74de5, recirc_id(0),dp_hash(0/0),skb_priority(0/0),in_port(vnet0),skb_mark(0/0),ct_state(0/0),ct_zone(0/0),ct_mark(0/0),ct_label(0/0),eth(src=00:00:00:00:00:00/00:00:00:00:00:00,dst=00:00:00:00:00:00/00:00:00:00:00:00),eth_type(0x86dd),ipv6(src=::/::,dst=::/::,label=0/0,proto=58,tclass=0/0,hlimit=0/0,frag=no),icmpv6(type=135,code=0),nd(target=::/::,sll=00:00:00:00:00:00/00:00:00:00:00:00,tll=00:00:00:00:00:00/00:00:00:00:00:00), packets:334, bytes:28724, used:0.052s, dp:ovs, actions:drop ufid:432327b0-b3f7-48a4-8bc3-344c39d7040f, recirc_id(0),dp_hash(0/0),skb_priority(0/0),in_port(bond0.6),skb_mark(0/0),ct_state(0/0),ct_zone(0/0),ct_mark(0/0),ct_label(0/0),eth(src=00:00:00:00:00:00/00:00:00:00:00:00,dst=00:00:00:00:00:00/00:00:00:00:00:00),eth_type(0x86dd),ipv6(src=::/::,dst=::/::,label=0/0,proto=58,tclass=0/0,hlimit=0/0,frag=no),icmpv6(type=135,code=0),nd(target=::/::,sll=00:00:00:00:00:00/00:00:00:00:00:00,tll=00:00:00:00:00:00/00:00:00:00:00:00), packets:502, bytes:43172, used:0.036s, dp:ovs, actions:drop As you can see in the "ovs-dpctl" output the field "nd_target" is "::/::" now and is not used in matching. At the same time the "ovs-appctl ofproto/trace" output is the same. # ovs-appctl ofproto/trace public-switch in_port=1,icmp6,icmpv6_type=135,nd_target=2a03:f480:2:a::1f Flow: icmp6,in_port=1,vlan_tci=0x0000,dl_src=00:00:00:00:00:00,dl_dst=00:00:00:00:00:00,ipv6_src=::,ipv6_dst=::,ipv6_label=0x00000,nw_tos=0,nw_ecn=0,nw_ttl=0,icmp_type=135,icmp_code=0,nd_target=2a03:f480:2:a::1f,nd_sll=00:00:00:00:00:00,nd_tll=00:00:00:00:00:00 bridge("public-switch") ----------------------- 0. icmp6,nw_frag=no,icmp_type=135,icmp_code=0,nd_target=2a03:f480:2:a::1f, priority 1212, cookie 0x1212 output:2 Final flow: unchanged Megaflow: recirc_id=0,eth,icmp6,in_port=1,nw_frag=no,icmp_type=0x87/0xff,icmp_code=0x0/0xff,nd_target=2a03:f480:2:a::1f Datapath actions: 3 The tcpdump output inside of VM is empty: # tcpdump -nn -i ens3 icmp6 tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on ens3, link-type EN10MB (Ethernet), snapshot length 262144 bytes ^C 0 packets captured 0 packets received by filter 0 packets dropped by kernel We noticed strange behavior. Immediately after adding the flows the flow with nd_target field is working about 10-20 seconds and packet counter increase: # ovs-ofctl dump-flows public-switch cookie=0x1212, duration=2.221s, table=0, n_packets=12, n_bytes=1032, priority=1212,icmp6,nw_frag=no,icmp_type=135,icmp_code=0,nd_target=2a03:f480:2:a::1f actions=output:vnet0 cookie=0x2, duration=2.221s, table=0, n_packets=2087, n_bytes=179482, priority=2,icmp6,icmp_type=135,icmp_code=0 actions=drop And we see Neighbor Solicitation packets inside the VM. After 10-20 seconds all Neighbor Solicitation packets start dropping again.
_______________________________________________ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
