Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1836870

Summary: Adding a bad route to a router can break the router even after the route is removed
Product: Red Hat OpenStack Reporter: Jiri Stransky <jstransk>
Component: documentationAssignee: Greg Rakauskas <gregraka>
Status: CLOSED CURRENTRELEASE QA Contact: RHOS Documentation Team <rhos-docs>
Severity: unspecified Docs Contact:
Priority: high    
Version: 13.0 (Queens)CC: amuller, chrisw, gregraka, jamsmith, ralonsoh, scohen, skaplons
Target Milestone: asyncKeywords: Triaged, ZStream
Target Release: 13.0 (Queens)   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: docs-accepted
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1856924 1856925 1856926 (view as bug list) Environment:
Last Closed: 2020-07-28 12:52:31 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: 1856924, 1856925, 1856926    

Description Jiri Stransky 2020-05-18 11:46:08 UTC
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

Comment 3 Rodolfo Alonso 2020-05-19 10:44:48 UTC
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.

Comment 20 Greg Rakauskas 2020-07-28 12:52:31 UTC
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