[ovs-dev] [RFC] OVN: Support Static Route

[Ramu Ramamurthy]

Reported-At: https://bugs.launchpad.net/networking-ovn/+bug/1539347
Reported-By: nazhu at cn.ibm.com
Co-Authored-By: nazhu at cn.ibm.com,ruansx at cn.ibm.com

---
openstack-neutron (CMS) allows the configuration of
"static-routes" on a router as shown below.

neutron router-update --route 
destination=192.168.3.0/24,nexthop=192.168.1.100 router1

The static route gets implemented (in openstack) by adding a route in 
the router-namespace using a command such as: ip route add to 
destination-cidr via nexthop.

The next-hop is a port known to the CMS, and so, the CMS knows the 
IP->mac mapping
of the nexthop port.

The usecases addressed by static route includes a VPN router. A VPN 
router is a VM that has interfaces on a private network, and on a 
provider network.
The static route allows other VMs on the private network to reach the 
VPN-network via
the VPN router.

Example:
       Private networks are 192.168.1.0/24 and 192.168.2.0/24
       VPN-router has an interface (192.168.1.100) on private network 
(192.168.1.0/24)
       VPN connects to 192.168.3.0/24 over the provider network
       the following static route is needed to allow VMs private networks 
to reach the VPN network
       destination=192.168.3.0/24, nexthop=192.168.1.100


An approach to implement static routes in OVN follows:

1) A new column called static route is added to the Logical Router table
     * the static route column may in turn refer to a new 
Logical_Router_Static_Route table whose columns include
      destination, nexthop
     OR for simplicity,
    * the static route column may contain the static routes as a string 
with formatting to denote separation - for example, 
"destination=192.168.3.0/24,nexthop=192.168.1.100;destination=192.168.2.0/24,nexthop=10.0.1.4"

2) Based on the presence of the "static route" field in the logical 
router, OVN northd programs a logical flow corresponding to the each 
static route as follow:

actions : "ip.ttl--; reg0 = nexthop; next;"
external_ids : {stage-name=lr_in_ip_routing}
match : "ip4.dst == destination cidr"
pipeline : ingress

The lr_in_arp stage would have already have an arp-resolution-entry for 
the nexthop since the nexthop (IP,Mac) is already added as a logical 
port.