Open Stack

Hi Gary,

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 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.


On 6/6/17 9:23 PM, Gary molenkamp wrote:
> 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.
>
>
> I have a routed provider network that is using RFC1918 address space 
> for our institution's private network.  ie:
>
>     provider-subnet:   172.31.96.0/22   default gateway: 172.31.96.1
>
> 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:
>
> NATing host=172.31.96.21
>
>
> # openstack subnet show 066df21a-d23d-4917-8b28-d097957633dc
>
> +-------------------+-----------------------------------------------------+ 
>
>
> | Field             | 
> Value                                               |
>
> +-------------------+-----------------------------------------------------+ 
>
>
> | allocation_pools  | 
> 172.31.96.32-172.31.99.240                          |
>
> | cidr              | 
> 172.31.96.0/22                                      |
>
> | created_at        | 
> 2017-04-12T15:59:32Z                                |
>
> | description |                                                     |
>
> | dns_nameservers   | 
> 8.8.8.8                                             |
>
> | enable_dhcp       | 
> True                                                |
>
> | gateway_ip        | 
> 172.31.96.21                                        |
>
> | host_routes       | destination='172.16.0.0/12', 
> gateway='172.31.96.1'  |
>
> | id                | 
> 066df21a-d23d-4917-8b28-d097957633dc                |
>
> | ip_version        | 
> 4                                                   |
>
> | ipv6_address_mode | 
> None                                                |
>
> | ipv6_ra_mode      | 
> None                                                |
>
> | name              | 
> provider-campus                                     |
>
> | network_id        | 
> 67917c09-6cb4-4622-ae1b-9f5aef890b0f                |
>
> | project_id        | 
> a9746d7b6ff047dca9ac3aced978643c                    |
>
> | project_id        | 
> a9746d7b6ff047dca9ac3aced978643c                    |
>
> | revision_number   | 
> 10                                                  |
>
> | service_types     | 
> []                                                  |
>
> | subnetpool_id     | 
> None                                                |
>
> | updated_at        | 
> 2017-06-06T13:33:31Z                                |
>
> +-------------------+-----------------------------------------------------+ 
>
>
>
> 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:
>
> # ip netns exec qrouter-da32efe2-1294-4f7e-8c47-0ef2a6d2fd39 route -n
>
> Kernel IP routing table
>
> Destination     Gateway         Genmask         Flags Metric Ref    
> Use Iface
>
> 0.0.0.0         172.31.96.21    0.0.0.0         UG    0 0        0 
> qg-5f5ca6e9-56
>
> 172.31.96.0     0.0.0.0         255.255.252.0   U     0 0        0 
> qg-5f5ca6e9-56
>
> 172.31.104.0    0.0.0.0         255.255.255.0   U     0 0        0 
> qr-db64ea28-cd
>
>
> If I explicitly add the destination routes to a virtual router, 
> everything works as intended:
>
>
> # openstack router set --route 
> destination='172.16.0.0/12',gateway='172.31.96.1' r2
>
> # ip netns exec qrouter-da32efe2-1294-4f7e-8c47-0ef2a6d2fd39 route -n
>
> Kernel IP routing table
>
> Destination     Gateway         Genmask         Flags Metric Ref    
> Use Iface
>
> 0.0.0.0         172.31.96.21    0.0.0.0         UG    0 0        0 
> qg-5f5ca6e9-56
>
> 172.16.0.0      172.31.96.1     255.240.0.0     UG    0 0        0 
> qg-5f5ca6e9-56
>
> 172.31.96.0     0.0.0.0         255.255.252.0   U     0 0        0 
> qg-5f5ca6e9-56
>
> 172.31.104.0    0.0.0.0         255.255.255.0   U     0 0        0 
> qr-db64ea28-cd
>
>
> 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.
>
> Note:  running openstack newton on centos7.3.1611 using bridge plugin 
> for newton:
>
> openstack-neutron-ml2-9.2.0-1.el7.noarch
> centos-release-openstack-newton-1-1.el7.noarch
> python2-openstacksdk-0.9.5-1.el7.noarch
> openstack-neutron-common-9.2.0-1.el7.noarch
> openstack-neutron-linuxbridge-9.2.0-1.el7.noarch
> python-openstackclient-3.2.1-1.el7.noarch
> openstack-neutron-9.2.0-1.el7.noarch
>
>

-- 
Volodymyr Litovka
   "Vision without Execution is Hallucination." -- Thomas Edison

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20170607/2ae1813f/attachment.html>