Description of problem: Under an OSP environment, with the following instances diagram, ┌────────────────────────────────────────────────────────────────────────┐ │┌─────────────────────┐ ┌───────────────────┐ ┌───────────────────┐ │ ││ VM1 │ │ VM2 │ │ VM3 │ │ ││ ┌─────────────────┐│ │ │ │ │ │ ││ │ nested VM ││ │ │ │ │ │ ││ │ 10.0.0.50 ││ │ │ │ │ │ ││ │00:50:56:87:c3:bd││ │ │ │ │ │ ││ │ ││ │ │ │ │ │ ││ └───────────┬─────┘│ │ │ │ │ │ ││ │ │ │ │ │ │ │ ││ │ │ │ │ │ │ │ ││ ┌────────────x────┐ │ │ │ │ │ │ ││ │ │ │ │ │ │ │ │ ││ ├─────────────────┤ │ │┌─────────────────┐│ │┌─────────────────┐│ │ ││ │ 10.0.0.20 │ │ ││fa:16:3e:37:68:28││ ││fa:16:3e:b5:4a:7e││ │ ││ │fa:16:3e:6f:cb:e5│ │ ││ 10.0.0.200 ││ ││ 10.0.0.10 ││ │ ││ └────────┬────────┘ │ │└────────┬────────┘│ │└────────┬────────┘│ │ │└──────────┼──────────┘ └─────────┼─────────┘ └─────────┼─────────┘ │ │ │ │ │ │ │ tapc379b178-73 tapc379b178-73 tap85c00340-d4 │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ ┌─────────x───────────────────────x──────────────────────x──────────┐ │ │ │ br-int │ │ │ │ │ │ │ └───────────────────────────────────────────────────────────────────┘ │ │ │ │ compute-0 │ └────────────────────────────────────────────────────────────────────────┘ Port security is disabled for VM1 and VM1 is able to egress packets of the nested VM as 10.0.0.50 / 00:50:56:87:c3:bd and VM2/VM3 will receive them. If they try to send packets to the 00:50:56:87:c3:bd MAC address the packets won't arrive VM1. ovn doesn't implement any mechanism to learn MAC addresses on the instance ports. If we set 10.0.0.50 / 00:50:56:87:c3:bd on the allowed_address pairs of port tapc379b178-73 it works, as ovn-controller sets the right flows to steer 00:50:56:87:c3:bd packets to VM1. This didn't happen with ml2/ovs since the bridges used NORMAL rules to handle unknown MAC addresses on ports and didn't steer traffic to ports via flows based on MAC addresses. tcpdumps on VM1 and VM2 while VM2 is trying to ping the nested IP ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ [root@compute-0 heat-admin]# tcpdump -ner tap219e532f-24.pcap reading from file tap219e532f-24.pcap, link-type EN10MB (Ethernet) 11:48:33.773288 fa:16:3e:37:68:28 > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 10.0.0.50 tell 10.0.0.200, length 46 11:48:33.774145 00:50:56:87:c3:bd > fa:16:3e:37:68:28, ethertype ARP (0x0806), length 60: Reply 10.0.0.50 is-at 00:50:56:87:c3:bd, length 46 11:48:33.774332 fa:16:3e:37:68:28 > 00:50:56:87:c3:bd, ethertype IPv4 (0x0800), length 98: 10.0.0.200 > 10.0.0.50: ICMP echo request, id 14802, seq 0, length 64 11:48:34.774381 fa:16:3e:37:68:28 > 00:50:56:87:c3:bd, ethertype IPv4 (0x0800), length 98: 10.0.0.200 > 10.0.0.50: ICMP echo request, id 14802, seq 1, length 64 11:48:35.775534 fa:16:3e:37:68:28 > 00:50:56:87:c3:bd, ethertype IPv4 (0x0800), length 98: 10.0.0.200 > 10.0.0.50: ICMP echo request, id 14802, seq 2, length 64 11:48:36.776695 fa:16:3e:37:68:28 > 00:50:56:87:c3:bd, ethertype IPv4 (0x0800), length 98: 10.0.0.200 > 10.0.0.50: ICMP echo request, id 14802, seq 3, length 64 11:48:37.777906 fa:16:3e:37:68:28 > 00:50:56:87:c3:bd, ethertype IPv4 (0x0800), length 98: 10.0.0.200 > 10.0.0.50: ICMP echo request, id 14802, seq 4, length 64 11:48:38.779118 fa:16:3e:37:68:28 > 00:50:56:87:c3:bd, ethertype IPv4 (0x0800), length 98: 10.0.0.200 > 10.0.0.50: ICMP echo request, id 14802, seq 5, length 64 - destination tap: [root@compute-0 heat-admin]# tcpdump -ner tapc379b178-73.pcap reading from file tapc379b178-73.pcap, link-type EN10MB (Ethernet) 11:48:33.773487 fa:16:3e:37:68:28 > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 10.0.0.50 tell 10.0.0.200, length 46 11:48:33.773995 00:50:56:87:c3:bd > fa:16:3e:37:68:28, ethertype ARP (0x0806), length 60: Reply 10.0.0.50 is-at 00:50:56:87:c3:bd, length 46 Version-Release number of selected component (if applicable): 2.9.0-54.el7fdp How reproducible: 100% Steps to Reproduce: 1. Setup two logical Ports in OVN under the same logical switch 2. Configure those ports in namespaces on the same chassis 3. In one of the ports connect a linux bridge, and then another tap port with a different mac address and IP 4. Try to ping that IP from the port on the other namespace, it won't work. Actual results: VM1 is able to receive traffic for the nested IP/MAC Expected results: VM1 not able to receive traffic for the nested IP/MAC
Created attachment 1525912 [details] lflows, ports, dump-flows, port bindings, etc from OVN
Verified on puddle 13.0-RHEL-7/2019-04-10.1 with python-networking-ovn-4.0.3-6.el7ost.noarch Verification scenario: --------------------- 1. Created a router connected to the external network. 2. Created internal network with --port-security-disabled and connected it to the router. 3. Created VM1 and VM2 connected to the internal network. 4. Verified that switch ports have "unknown" added to addresses field (see below) switch b5cb2837-2492-49ff-8f31-af4bec6f41b3 (neutron-c6105578-e399-419f-bbb5-61c9d40a537b) (aka internal_A) port aff9aa2e-6702-43b0-ae34-99107f062e02 type: localport addresses: ["fa:16:3e:b0:f7:08 192.168.2.2", "unknown"] port provnet-c6105578-e399-419f-bbb5-61c9d40a537b type: localnet tag: 322 addresses: ["unknown"] port 27f54cfa-8fb4-466f-b0da-2ade851af874 addresses: ["fa:16:3e:20:ff:98 192.168.2.7", "unknown"] port 30c956f1-b009-41b1-acf2-6949f279e499 type: router router-port: lrp-30c956f1-b009-41b1-acf2-6949f279e499 port 574da47a-0b92-4cd5-bd7b-0641f0e6175a addresses: ["fa:16:3e:6f:cd:93 192.168.2.17", "unknown"] 5. Connected to both VMs and verified that ping worked between them in both directions. 6. On VM1 changed MAC address of the interface connected to the internal network to aa:bb:cc:dd:ee:ff and IP address to 192.168.2.22 (instead of 192.168.2.7), tried to ping VM2 (192.168.2.17) Result: ping worked 7. Connected to VM2 and pinged new VM1 address (192.168.2.22) Result: ping worked. All worked as expected
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2019:0932