Description of problem: When trying to solve a different routing issue involving fixed IPs not known to Neutron, i experimented with various weird routes set on OpenStack routers. One of the things i tried was: openstack router set --no-route --route destination=172.19.13.0/24,gateway=172.19.13.41 osm-ci-13-router This is a fishy rule and i expected might break routing, but after i removed the rule with: openstack router set --no-route osm-ci-13-router The routing remained broken. Floating IPs for the network serviced by this router didn't work, and egress traffic from that network didn't work either. Workaround: Disassociate all floating IPs on the subnet, detach the router from the subnet, re-attach the router to the subnet and re-attach all floating IPs. This restored both outgoing connectivity and incoming FIP connectivity. Version-Release number of selected component (if applicable): PSI rhos-d, most likely OSP 13 with ML2 OVS and DVR enabled
Hello Jiri: This operation will definitely break the router. IMO, this operation should be blocked by the API itself or the Neutron server. But I think those kind of operations are allowed "on your own responsibility". This will happen to a non-DVR router too. For example, this is a simple router with a tenant network and a public one (with GW). We have both CIDRs routed to the corresponding interface (one per network) and the default router (to the GW): root@osdev18:/etc/neutron# ip netns exec $router ip r default via 192.168.20.1 dev qg-32e426d5-23 proto static 10.0.10.0/26 dev qr-d1ce24ed-6b proto kernel scope link src 10.0.10.1 192.168.0.0/16 dev qg-32e426d5-23 proto kernel scope link src 192.168.200.237 If we add a new route via an IP of the private network, it will be added to the private network interface: root@osdev18:/etc/neutron# openstack router set --route destination=192.168.10.0/24,gateway=10.0.10.34 router1 root@osdev18:/etc/neutron# ip netns exec $router ip r default via 192.168.20.1 dev qg-32e426d5-23 proto static 10.0.10.0/26 dev qr-bc401d1f-45 proto kernel scope link src 10.0.10.1 192.168.0.0/16 dev qg-32e426d5-23 proto kernel scope link src 192.168.200.237 192.168.10.0/24 via 10.0.10.34 dev qr-bc401d1f-45 Then we delete the added route and we add the conflicting one. That router will replace the default one added to route the packets of the private subnet through the private network interface: root@osdev18:/etc/neutron# openstack router set --route destination=10.0.10.0/26,gateway=10.0.10.34 router1 root@osdev18:/etc/neutron# ip netns exec $router ip r default via 192.168.20.1 dev qg-32e426d5-23 proto static 10.0.10.0/26 via 10.0.10.34 dev qr-bc401d1f-45 192.168.0.0/16 dev qg-32e426d5-23 proto kernel scope link src 192.168.200.237 That means when we delete the added route, the route for the private subnet won't be present anymore. That means no connectivity with the tenant network and subnet: root@osdev18:/etc/neutron# openstack router set --no-route router1 root@osdev18:/etc/neutron# ip netns exec $router ip r default via 192.168.20.1 dev qg-32e426d5-23 proto static 192.168.0.0/16 dev qg-32e426d5-23 proto kernel scope link src 192.168.200.237 As you commented, the only way to re-create the private subnet route in the router namespace, is to 1) remove any route related to this subnet, 2) remove the tenant subnet from the router and 3) add it again. This is not a bug but a "misuse" (let me call it in this way) of the router API. The replacement of the private subnet route in the router namespace is a consequence of adding this incorrect/forbidden route. Regards.
Hi, The change has been made to the RHOSP 13 "Networking Guide." Customers can see this change here: https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/13/html-single/networking_guide/index#add-router Thanks, --Greg