<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p><font face="SFNS Display">Hi Gary,</font></p>
    <p><font face="SFNS Display">why you need this route installed on
        vRouter? It's not a packet-originating node, it's just a transit
        point. As soon as you'll have a proper routing table on guest
        VMs (according to DHCP configuration), they will send packets
        destined to </font>172.16.0.0/12 through 172.31.96.1 and
      everything else - to 172.31.96.21. Neither vR nor NATing host
      don't require more specific routes.<br>
    </p>
    <br>
    <div class="moz-cite-prefix">On 6/6/17 9:23 PM, Gary molenkamp
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:989d0393-4698-c3cc-b23b-b1826a8858ec@uwo.ca">I'm having
      an issue with Neutron under Newton in assigning routes to the
      provider network.  I would appreciate any advice on whether I am
      doing this incorrectly, or if this a bug with neutron.
      <br>
      <br>
      <br>
      I have a routed provider network that is using RFC1918 address
      space for our institution's private network.  ie:
      <br>
      <br>
          provider-subnet:   172.31.96.0/22   default gateway:
      172.31.96.1
      <br>
      <br>
      This subnet is routed to other subnets in the 172.16.0.0/12
      address space, but does not have any outbound service to general
      internet.  To provide outbound NAT to instances,  I add a NATing
      host to the provider-subnet physical network and changed the
      default gateway to that host.  I then added a host route to the
      subnet that uses the original gateway as the nexthop on the
      generic 172.16.0.0/12 ip space:  such that:
      <br>
      <br>
      NATing host=172.31.96.21
      <br>
      <br>
      <br>
      # openstack subnet show 066df21a-d23d-4917-8b28-d097957633dc
      <br>
      <br>
+-------------------+-----------------------------------------------------+
      <br>
      <br>
      | Field             |
      Value                                               |
      <br>
      <br>
+-------------------+-----------------------------------------------------+
      <br>
      <br>
      | allocation_pools  |
      172.31.96.32-172.31.99.240                          |
      <br>
      <br>
      | cidr              |
      172.31.96.0/22                                      |
      <br>
      <br>
      | created_at        |
      2017-04-12T15:59:32Z                                |
      <br>
      <br>
      | description      
      |                                                     |
      <br>
      <br>
      | dns_nameservers   |
      8.8.8.8                                             |
      <br>
      <br>
      | enable_dhcp       |
      True                                                |
      <br>
      <br>
      | gateway_ip        |
      172.31.96.21                                        |
      <br>
      <br>
      | host_routes       | destination='172.16.0.0/12',
      gateway='172.31.96.1'  |
      <br>
      <br>
      | id                |
      066df21a-d23d-4917-8b28-d097957633dc                |
      <br>
      <br>
      | ip_version        |
      4                                                   |
      <br>
      <br>
      | ipv6_address_mode |
      None                                                |
      <br>
      <br>
      | ipv6_ra_mode      |
      None                                                |
      <br>
      <br>
      | name              |
      provider-campus                                     |
      <br>
      <br>
      | network_id        |
      67917c09-6cb4-4622-ae1b-9f5aef890b0f                |
      <br>
      <br>
      | project_id        |
      a9746d7b6ff047dca9ac3aced978643c                    |
      <br>
      <br>
      | project_id        |
      a9746d7b6ff047dca9ac3aced978643c                    |
      <br>
      <br>
      | revision_number   |
      10                                                  |
      <br>
      <br>
      | service_types     |
      []                                                  |
      <br>
      <br>
      | subnetpool_id     |
      None                                                |
      <br>
      <br>
      | updated_at        |
      2017-06-06T13:33:31Z                                |
      <br>
      <br>
+-------------------+-----------------------------------------------------+
      <br>
      <br>
      <br>
      However, when a router is added and set to the gateway on this
      provider subnet,  the included routes do not have the proper
      nexthop set in the routing table and instead just point to the
      default route:
      <br>
      <br>
      # ip netns exec qrouter-da32efe2-1294-4f7e-8c47-0ef2a6d2fd39 route
      -n
      <br>
      <br>
      Kernel IP routing table
      <br>
      <br>
      Destination     Gateway         Genmask         Flags Metric
      Ref    Use Iface
      <br>
      <br>
      0.0.0.0         172.31.96.21    0.0.0.0         UG    0     
      0        0 qg-5f5ca6e9-56
      <br>
      <br>
      172.31.96.0     0.0.0.0         255.255.252.0   U     0     
      0        0 qg-5f5ca6e9-56
      <br>
      <br>
      172.31.104.0    0.0.0.0         255.255.255.0   U     0     
      0        0 qr-db64ea28-cd
      <br>
      <br>
      <br>
      If I explicitly add the destination routes to a virtual router,
      everything works as intended:
      <br>
      <br>
      <br>
      # openstack router set --route
      destination='172.16.0.0/12',gateway='172.31.96.1' r2
      <br>
      <br>
      # ip netns exec qrouter-da32efe2-1294-4f7e-8c47-0ef2a6d2fd39 route
      -n
      <br>
      <br>
      Kernel IP routing table
      <br>
      <br>
      Destination     Gateway         Genmask         Flags Metric
      Ref    Use Iface
      <br>
      <br>
      0.0.0.0         172.31.96.21    0.0.0.0         UG    0     
      0        0 qg-5f5ca6e9-56
      <br>
      <br>
      172.16.0.0      172.31.96.1     255.240.0.0     UG    0     
      0        0 qg-5f5ca6e9-56
      <br>
      <br>
      172.31.96.0     0.0.0.0         255.255.252.0   U     0     
      0        0 qg-5f5ca6e9-56
      <br>
      <br>
      172.31.104.0    0.0.0.0         255.255.255.0   U     0     
      0        0 qr-db64ea28-cd
      <br>
      <br>
      <br>
      I would rather have the route definition in the provider subnet
      rather than having to replicate the routing entries for every
      router instance.  Am I missing something, or should this be
      working as initially intended.
      <br>
      <br>
      Note:  running openstack newton on centos7.3.1611 using bridge
      plugin for newton:
      <br>
      <br>
      openstack-neutron-ml2-9.2.0-1.el7.noarch
      <br>
      centos-release-openstack-newton-1-1.el7.noarch
      <br>
      python2-openstacksdk-0.9.5-1.el7.noarch
      <br>
      openstack-neutron-common-9.2.0-1.el7.noarch
      <br>
      openstack-neutron-linuxbridge-9.2.0-1.el7.noarch
      <br>
      python-openstackclient-3.2.1-1.el7.noarch
      <br>
      openstack-neutron-9.2.0-1.el7.noarch
      <br>
      <br>
      <br>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
Volodymyr Litovka
  "Vision without Execution is Hallucination." -- Thomas Edison
</pre>
  </body>
</html>