Wrong addition of VIPs to all logical router pods leading to triggering GARP on different locations
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
neutron |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
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-
external_ids : {"neutron:
logical_port : "add962d2-
mac : [router]
nat_addresses : ["fa:16:3e:77:7f:9c 172.24.100.181 is_chassis_
options : {peer=lrp-
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.
Fix for this was proposed here: https:/ /review. opendev. org/c/openstack /neutron/ +/832594