Bug 2053013

Summary: Wrong addition of VIPs to all logical router pods leading to triggering GARP on different locations
Product: Red Hat Enterprise Linux Fast Datapath Reporter: Luis Tomas Bolivar <ltomasbo>
Component: ovn-2021Assignee: lorenzo bianconi <lorenzo.bianconi>
Status: CLOSED DUPLICATE QA Contact: Jianlin Shi <jishi>
Severity: high Docs Contact:
Priority: unspecified    
Version: FDP 21.KCC: ctrautma, dceara, jiji, lorenzo.bianconi, mmichels, nusiddiq
Target Milestone: ---   
Target Release: FDP 22.B   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: ovn2.13-20.12.0-195 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 2064704 (view as bug list) Environment:
Last Closed: 2022-03-04 01:36:46 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:    
Bug Blocks: 2064704, 2064706, 2064709    

Description Luis Tomas Bolivar 2022-02-10 13:03:08 UTC
Description of problem:
When a loadbalancer is created in an OSP tenant network (VIP and members), and that tenant networks is connected to a router, which in turns is connected to the provider network, the ovn loadbalancer gets associated to the ovn logical router. This includes also the cr-lrp port (patch port connecting the router and the provider network, in OSP world, the router gateway port), and it can be seen by the entry on the nat_address of that port, which includes the VIP of the loadbalalancer.

This may cause problems as that means ovn-controller will send GARPs for that (internal, tenant network) IP. There is nothing blocking different tenants in OSP to create a subnet with the same CIDR and then a loadbalancer with the same VIP. If that is the case, there may be several ovn-controllers generating GARPs on the provider network for the same IP, each one with the MAC of the logical router port belonging to each user. This could be a problem for the physical network infrastructure.


Steps to Reproduce:
1. Create a router in OSP and attach it to the provider network
2. Create a tenant network/subnet and connect it to the router
3. Create a Load Balancer in OSP, with the VIP in  that tenant network

Actual results:
Check the VIP of the loadbalancer is on the OVN SB Port_Binding table, at the nat_addresses of the patch port connecting the router to the provider network:

datapath            : e3a0a334-9a02-41c7-a64d-6ea747839808
external_ids        : {"neutron:cidrs"="172.24.100.181/24 2001:db8::f816:3eff:fe77:7f9c/64", "neutron:device_id"="335cd008-216f-4571-a685-b0de5a7ffe50", "neutron:device_owner"="network:router_gateway", "neutron:network_name"=neutron-d923b3db-500d-4241-95be-c3869c72b36a, "neutron:port_name"="", "neutron:project_id"="", "neutron:revision_number"="6", "neutron:security_group_ids"=""}                                                                                                                            
logical_port        : "add962d2-21ab-4733-b6ef-35538eff25a8"
mac                 : [router]
nat_addresses       : ["fa:16:3e:77:7f:9c 172.24.100.181 is_chassis_resident(\"cr-lrp-add962d2-21ab-4733-b6ef-35538eff25a8\")", "fa:16:3e:77:7f:9c 172.24.100.229 *20.0.0.98* 172.24.100.112 is_chassis_resident(\"cr-lrp-add962d2-21ab-4733-b6ef-35538eff25a8\")"]
options             : {peer=lrp-add962d2-21ab-4733-b6ef-35538eff25a8}
parent_port         : []
tag                 : []
tunnel_key          : 4
type                : patch
up                  : false
virtual_parent      : []


Expected results:
In the example, ip 20.0.0.98 should not be there as that belongs to an IP in a tenant network that should not be advertized (GARP) in the provider network.

Comment 10 Jianlin Shi 2022-03-02 02:12:27 UTC
Hi Mark,

How is this bug solved? with the RFE bz2054394 or any other way?
if it is solved by bz2054394, then we can set this bug as duplicated, how do you think?

Comment 11 Mark Michelson 2022-03-03 13:46:58 UTC
Yes, this is solved by https://bugzilla.redhat.com/show_bug.cgi?id=2054394, so you can mark this as a duplicate if you would like.

Comment 12 Jianlin Shi 2022-03-04 01:36:46 UTC

*** This bug has been marked as a duplicate of bug 2054394 ***