Hallo!!! We have a problem with flow field "nd_target" at IPv6.
For example. We have two VM with virtual interfaces vnet0 and vnet1. 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 external interface. We added only three flows for the test : *# ovs-ofctl --no-stat dump-flows public-switch --sort=priority* cookie=0x123575, table=2, priority=1,icmp6,icmp_type=135 actions=output:vnet1 cookie=0x124994, table=2, priority=108,icmp6,icmp_type=135,nd_target=XXXX:XXXX:2:2::a5 actions=output:vnet0 cookie=0x10005, priority=10005,icmp6,in_port="bond0.6",icmp_type=135 actions=resubmit(,2) So, all ICMP6 traffic with type 135 going on bond0.6 resubmit to table 2 and the if nd_target field equals to IPv6 address XXXX:XXXX:2:2::a5 the traffic send to vnet0 (VM1 have IPv6 XXXX:XXXX:2:2::a5). All other traffic should go to vnet1 (VM2). We start tcpdump on both VMs by command: *# tcpdump -e -nn -i eth0 "icmp6 && ! ( ip6[40] == 128 || ip6[40] == 129)"* and start pinging XXXX:XXXX:2:2::a5 from remote server. On VM1 on tcpdump output is clear. But on VM2 (with interface vnet1) on tcpdump output we see the following: 16:52:22.523950 xx:xx:xx:1b:b3:67 > 33:33:ff:00:00:a5, ethertype IPv6 (0x86dd), length 86: fe80::xxxx:xxff:fe1b:b367 > ff02::1:ff00:a5: ICMP6, neighbor solicitation, who has xxxx:xxxx:2:2::a5, length 32 16:52:23.522694 xx:xx:xx:1b:b3:67 > 33:33:ff:00:00:a5, ethertype IPv6 (0x86dd), length 86: fe80::xxxx:xxff:fe1b:b367 > ff02::1:ff00:a5: ICMP6, neighbor solicitation, who has xxxx:xxxx:2:2::a5, length 32 16:52:24.467750 xx:xx:xx:01:f0:2b > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: fe80::xxxx:xxff:fe01:f02b > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has fe80::1, length 32 16:52:24.522639 xx:xx:xx:1b:b3:67 > 33:33:ff:00:00:a5, ethertype IPv6 (0x86dd), length 86: fe80::xxxx:xxff:fe1b:b367 > ff02::1:ff00:a5: ICMP6, neighbor solicitation, who has xxxx:xxxx:2:2::a5, length 32 16:52:25.523074 xx:xx:xx:1b:b3:67 > 33:33:ff:00:00:a5, ethertype IPv6 (0x86dd), length 86: fe80::xxxx:xxff:fe1b:b367 > ff02::1:ff00:a5: ICMP6, neighbor solicitation, who has xxxx:xxxx:2:2::a5, length 32 16:52:26.522647 xx:xx:xx:1b:b3:67 > 33:33:ff:00:00:a5, ethertype IPv6 (0x86dd), length 86: fe80::xxxx:xxff:fe1b:b367 > ff02::1:ff00:a5: ICMP6, neighbor solicitation, who has xxxx:xxxx:2:2::a5, length 32 16:52:27.522594 xx:xx:xx:1b:b3:67 > 33:33:ff:00:00:a5, ethertype IPv6 (0x86dd), length 86: fe80::xxxx:xxff:fe1b:b367 > ff02::1:ff00:a5: ICMP6, neighbor solicitation, who has xxxx:xxxx:2:2::a5, length 32 16:52:28.538976 xx:xx:xx:1b:b3:67 > 33:33:ff:00:00:a5, ethertype IPv6 (0x86dd), length 86: fe80::xxxx:xxff:fe1b:b367 > ff02::1:ff00:a5: ICMP6, neighbor solicitation, who has xxxx:xxxx:2:2::a5, length 32 16:52:29.538513 xx:xx:xx:1b:b3:67 > 33:33:ff:00:00:a5, ethertype IPv6 (0x86dd), length 86: fe80::xxxx:xxff:fe1b:b367 > ff02::1:ff00:a5: ICMP6, neighbor solicitation, who has xxxx:xxxx:2:2::a5, length 32 16:52:30.538550 xx:xx:xx:1b:b3:67 > 33:33:ff:00:00:a5, ethertype IPv6 (0x86dd), length 86: fe80::xxxx:xxff:fe1b:b367 > ff02::1:ff00:a5: ICMP6, neighbor solicitation, who has xxxx:xxxx:2:2::a5, length 32 16:52:31.531703 xx:xx:xx:01:e8:b1 > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: fe80::xxxx:xxff:fe01:e8b1 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has fe80::1, length 32 As you can see, the ICMP6 traffic with type 135 that have nd_target field equals to IPv6 address XXXX:XXXX:2:2::a5 going to port vnet1 and not to vnet0. In the same time at the datapath we can see one flow as following: *# ovs-dpctl --more --names dump-flows filter="icmp6"* ufid:a545e5e6-39ff-4f5e-a71c-da4c41bbcf22, 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/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:35, bytes:3010, used:0.678s, actions:vnet1 As you can see, field nd_target is set to ::/:: and to XXXX:XXXX:2:2::a5. If we start command *# tcpdump -nn -i bond0.6* all ICMP6 traffic with type 135 start going to port vnet0 and at the datapath we see the following flows now: *# ovs-dpctl --more --names dump-flows filter="icmp6"* ufid:cee80ab9-4514-447d-8804-d024796cadec, 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=0/0,tclass=0/0,hlimit=0/0,frag=no), packets:81, bytes:6966, used:0.340s, actions:drop ufid:c306b8a3-e023-4077-b5af-fb13ecb21316, 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/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:70, bytes:6020, used:0.340s, actions:vnet0 If we stop pinging XXXX:XXXX:2:2::a5 from remote server and start pinging again after 10 seconds, the traffic will go to vnet1. The similar situation was at https://mail.openvswitch.org/pipermail/ovs-discuss/2017-March/043979.html. The flows work correctly with IPv4 traffic. # uname -a Linux kvm0.fv.ee 4.13.3 #1 SMP Wed Sep 20 16:43:41 MSK 2017 x86_64 x86_64 x86_64 GNU/Linux # lsb_release -d Description: CentOS Linux release 7.4.1708 (Core) # ovs-ofctl --version ovs-ofctl (Open vSwitch) 2.8.1 OpenFlow versions 0x1:0x5 Thank you.
_______________________________________________ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
