Description of problem: If openstack router is connected to network which has multiple segmented subnets routes, route table contains routes without correct gateway info. Version-Release number of selected component (if applicable): RHOSP16.1
Hello Rohini: After investigating this issue, I found that the router external interface (gateway port) configures the external network "extra subnets" as onlink routes. The "extra subnets" are the additional subnets apart from the gateway port IP CIDR. In this case, the extra subnets are those RPN subnets that are not connected to the router port. By default, when a router gateway port is enabled, the extra subnets CIDRs are set as onlink routes in the router namespace. In the example you provide: $ ssh esptnl-compute2r1-prod.sdc.itidm.elisa.fi sudo ip netns exec qrouter-8b56474d-027c-4d96-805d-869ceb92cd96 ip r ... 10.222.144.0/22 dev qg-f5b03925-e4 proto 112 scope link 10.222.144.0/22 dev qg-f5b03925-e4 proto static scope link 10.222.152.0/22 dev qg-f5b03925-e4 proto 112 scope link 10.222.152.0/22 dev qg-f5b03925-e4 proto static scope link 10.222.156.0/22 dev qg-f5b03925-e4 proto 112 scope link 10.222.156.0/22 dev qg-f5b03925-e4 proto static scope link The justification for those onlink routes is described in the patch that added them [1]. The case reported in this BZ is a particular condition where the gateway router is connected to a RPN, specifically to a segment (one subnet) of this network. That means this gateway port has broadcast connectivity to only this subnet CIDR. As commented, to have connectivity to the other subnets, the admin should manually add those extra routes on the router. E.g.: $ openstack router set --route destination=192.168.50.0/24,gateway=192.168.20.10 router1 That will overwrite the link routes and create global ones with (1) the destination IP, (2) the GW IP and (3) the device. E.g.: ... 192.168.50.0/24 via 192.168.20.10 dev qg-1d690261-35 proto 112 192.168.50.0/24 via 192.168.20.10 dev qg-1d690261-35 proto static 192.168.60.0/24 via 192.168.20.10 dev qg-1d690261-35 proto 112 192.168.60.0/24 via 192.168.20.10 dev qg-1d690261-35 proto static I'll close this bug as not a bug. Regards. [1]https://review.opendev.org/c/openstack/neutron/+/90250
Hi Rodolfo, Re-opening this one, as this is something that my customer would need in a very specific scenario, in which he would like to segment a network into discrete subnets, in order to not rely on only one (or set of) router in case of high traffic k8s cluster running on top. He would like to have the possibility to add more routers to handle the traffic buy using segmented subnets. To reply to what you proposed, here is his remarks : Hi, We tested that workaround and it does not work. After some time or change those wrong routes are added back. And they are preferred over static routes $ ssh compute1-xx.xxx.xxx sudo ip netns exec qrouter-e8f46e19-bd34-4df3-a5b3-55fd3526abae ip r default via 10.222.144.1 dev qg-a7c41976-28 proto 112 default via 10.222.144.1 dev qg-a7c41976-28 proto static 10.222.144.0/22 dev qg-a7c41976-28 proto kernel scope link src 10.222.145.242 10.222.148.0/22 dev qg-a7c41976-28 proto 112 scope link 10.222.148.0/22 via 10.222.144.1 dev qg-a7c41976-28 proto 112 10.222.148.0/22 via 10.222.144.1 dev qg-a7c41976-28 10.222.152.0/22 dev qg-a7c41976-28 proto 112 scope link 10.222.152.0/22 via 10.222.144.1 dev qg-a7c41976-28 proto 112 10.222.152.0/22 via 10.222.144.1 dev qg-a7c41976-28 10.222.156.0/22 dev qg-a7c41976-28 proto 112 scope link 10.222.156.0/22 via 10.222.144.1 dev qg-a7c41976-28 proto 112 10.222.156.0/22 via 10.222.144.1 dev qg-a7c41976-28 Regards, Pierre-André
Hello Pierre: Those link routers are not wrong, those routes are needed because when a router is connected to a GW port, the router assume it has connectivity with all network CIDRs. This is not the case in RPN. Reviewing the code is checked that those routes are re-added every time "init_router_port" is called; that happens when a new network is added or updated. The architecture the customer is testing is not tested and goes beyond the RPN feature, that is to skip any routing process inside the Neutron network. Regards.
Routed provider networks (RPN) require the fabric (physical switches) to do the routing between subnets. Every time a new subnet or segment is added, the physical router is expected to have a route added to support this. This would be expected even when new provider network is added. Neutron router is not expected to do the routing between provider networks or provider network segments, this is not part of the design intent for RPN This enhancement needs to be prioritized as Future Feature for OSP 17.z based on API change and ability to backport to OSP 17?
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 (Red Hat OpenStack Platform 16.1.7 (Train) bug fix and enhancement 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-2021:3762
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 500 days