Bug 1671809

Summary: port_security disabled in networking-ovn works for egress, but not for ingress
Product: Red Hat OpenStack Reporter: Miguel Angel Ajo <majopela>
Component: python-networking-ovnAssignee: Kamil Sambor <ksambor>
Status: CLOSED ERRATA QA Contact: Roman Safronov <rsafrono>
Severity: high Docs Contact:
Priority: high    
Version: 13.0 (Queens)CC: apevec, chrisw, dalvarez, ekuris, fiezzi, ksambor, lhh, lmartins, majopela, nusiddiq, ojanas, pmorey, rhos-maint
Target Milestone: ---Keywords: Triaged, ZStream
Target Release: 13.0 (Queens)   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: python-networking-ovn-4.0.3-5.el7ost Doc Type: If docs needed, set a value
Doc Text:
-
 Story Points: ---
Clone Of:
: 1683311 (view as bug list) Environment:
Last Closed: 2019-04-30 17:24:33 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1672625    
Bug Blocks: 1683311, 1789764    
Attachments:
Description Flags
lflows, ports, dump-flows, port bindings, etc from OVN none

Description Miguel Angel Ajo 2019-02-01 17:20:51 UTC 
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
Comment 1 Miguel Angel Ajo 2019-02-01 17:29:33 UTC 
Created attachment 1525912 [details]
lflows, ports, dump-flows, port bindings, etc from OVN
Comment 30 Roman Safronov 2019-04-11 16:27:18 UTC 
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
Comment 33 errata-xmlrpc 2019-04-30 17:24:33 UTC 
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