Open Stack

Sorry, I should have also mentioned that I'm using a tenant based 
networking model within Openstack.  Each project/tenant has their own 
network/subnet and is only connected to the provider network via a 
vRouter.    The vRouter has the more specific routes in order to know 
which is the proper next-hop on the provider network.


On 07/06/17 03:12 AM, Volodymyr Litovka wrote:
>
> 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

-- 
Gary Molenkamp			Computer Science
Systems Administrator		University of Western Ontario
molenkam at uwo.ca                 http://www.csd.uwo.ca
(519) 661-2111 x86882		(519) 661-3566

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