Re: [Openstack-operators] Reaching VXLAN tenant networks from outside (without floating IPs)

[Mike Spreitzer]

I do not recall trying that case.  I am surprised it is failing; and even 
more surprised that it is failing due to an explicit RST from the server 
VM.  Fortunately this is something you can debug.  Have a look at packet 
traces taken at various points along the way, and see what is going on. 
BTW, when using packet tracing I find it troublesome to do the filtering 
and/or the pretty-printing online; I simply capture all the packets at a 
given interface and them examine them later with Wireshark.

Regards,
Mike



From:   Gustavo Randich <gustavo.rand...@gmail.com>
To:     Mike Spreitzer/Watson/IBM@IBMUS
Cc: "openst...@lists.openstack.org" <openst...@lists.openstack.org>, 
"openstack-operators@lists.openstack.org" 
<openstack-operators@lists.openstack.org>
Date:   07/15/2016 01:44 PM
Subject:Re: [Openstack-operators] Reaching VXLAN tenant networks 
from outside (without floating IPs)



Hi, this approach worked fine, except in the case when VM has a floating 
IP, perhaps because of some SNAT rules in the Neutron Node router 
preventing TCP traffic (connection reset by peer) using internal IP 
address, although ICMP works. Using floating IP works ok, but for the use 
case we are deploying, we need to always access VMs via internal IP, 
regardless of the VM having a float or not.

I remember this problem was corrected in DVR for the case of VMs with 
floating IPs assigned communicating via internal IPs (it works ok now).




On Thu, Jun 30, 2016 at 2:32 PM, Mike Spreitzer <mspre...@us.ibm.com> 
wrote:
No, those routers are routers.  If one of them gets a packet, the router 
will forward the packet as usual for a router.

You might think they don't handle connections into tenant networks, but 
that might be because nothing is trying to use them as routers for the 
tenant networks.  That's a question about the routing tables in the rest 
of your environment.

If the client has a route to a Neutron tenant network that goes through a 
Neutron router, the client is able to connect to a server on the Neutron 
tenant network.

The normal configuration for routers on the internet is to not forward 
traffic to the RFC 1918 addresses.  I do not recall how the Neutron 
routers handle packets addressed to those addresses from sources on the 
"outside".

Regards,
Mike



From:Gustavo Randich <gustavo.rand...@gmail.com>
To:Mike Spreitzer/Watson/IBM@IBMUS
Cc:"openst...@lists.openstack.org" <openst...@lists.openstack.org
>, "openstack-operators@lists.openstack.org" <
openstack-operators@lists.openstack.org>
Date:06/30/2016 11:25 AM
Subject:Re: [Openstack-operators] Reaching VXLAN tenant networks 
from outside (without floating IPs)




Mike, as far as I know those routers allow only outgoing traffic, i.e. VM 
can see external networks, but those external networks cannot connect to 
VM if it doesn't have a FIP, am I right?

Thanks!
Gustavo

On Wed, Jun 29, 2016 at 7:24 PM, Mike Spreitzer <mspre...@us.ibm.com> 
wrote:
Gustavo Randich <gustavo.rand...@gmail.com> wrote on 06/29/2016 03:17:54 
PM:

> Hi operators...
> 
> Transitioning from nova-network to Neutron (Mitaka), one of the key 
> issues we are facing is how to reach VMs in VXLAN tenant networks 
> without using precious floating IPs.
> 
> Things that are outside Neutron in our case are:
> 
> - in-house made application orchestrator: needs SSH access to 
> instances to perform various tasks (start / shutdown apps, configure
> filesystems, etc.)
> 
> - various centralized and external monitoring/metrics pollers: need 
> SNMP / SSH access to gather status and trends
> 
> - internal customers: need SSH access to instance from non-openstack
> VPN service
> 
> - ideally, non-VXLAN aware traffic balancer appliances
> 
> We have considered these approaches:
> 
> - putting some of the external components inside a Network Node: 
> inviable because components need access to multiple Neutron deployments
> 
> - Neutron's VPNaaS: cannot figure how to configure a client-to-site 
> VPN topology
> 
> - integrate hardware switches capable of VXLAN VTEP: for us in this 
> stage, it is complex and expensive
> 
> - other?

You know Neutron includes routers that can route between tenant networks 
and external networks, right?  You could use those, if your tenant 
networks use disjoint IP subnets.

Regards,
Mike









___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Reaching VXLAN tenant networks from outside (without floating IPs)

[Mike Spreitzer]

Gustavo Randich  wrote on 06/29/2016 03:17:54 
PM:

> Hi operators...
> 
> Transitioning from nova-network to Neutron (Mitaka), one of the key 
> issues we are facing is how to reach VMs in VXLAN tenant networks 
> without using precious floating IPs.
> 
> Things that are outside Neutron in our case are:
> 
> - in-house made application orchestrator: needs SSH access to 
> instances to perform various tasks (start / shutdown apps, configure
> filesystems, etc.)
> 
> - various centralized and external monitoring/metrics pollers: need 
> SNMP / SSH access to gather status and trends
> 
> - internal customers: need SSH access to instance from non-openstack
> VPN service
> 
> - ideally, non-VXLAN aware traffic balancer appliances
> 
> We have considered these approaches:
> 
> - putting some of the external components inside a Network Node: 
> inviable because components need access to multiple Neutron deployments
> 
> - Neutron's VPNaaS: cannot figure how to configure a client-to-site 
> VPN topology
> 
> - integrate hardware switches capable of VXLAN VTEP: for us in this 
> stage, it is complex and expensive
> 
> - other?

You know Neutron includes routers that can route between tenant networks 
and external networks, right?  You could use those, if your tenant 
networks use disjoint IP subnets.

Regards,
Mike



___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [neutron] Attach routing rules to networks?

[Mike Spreitzer]

I assume `--host-route` works with a destination that is a single host. Is 
there something I can do to establish a routing rule for a destination 
that is a CIDR block?

Thanks,
Mike



From:   Joseph Bajin <josephba...@gmail.com>
To: James Denton <james.den...@rackspace.com>
Cc: Mike Spreitzer/Watson/IBM@IBMUS, openstack-operators 
<openstack-operators@lists.openstack.org>
Date:   04/04/2016 04:46 PM
Subject:Re: [Openstack-operators] [neutron] Attach routing rules 
to networks?



We use the host-route flag as mentioned above.  It makes it easy to sent 
internet like traffic to a gateway type of box and internal traffic to the 
inside for tenants that do have public access. 

On Sat, Apr 2, 2016 at 10:33 PM, James Denton <james.den...@rackspace.com> 
wrote:
Hi Mike,

You should be able to update the subnet(s) and use the --host-route flag 
with destination,nexthop pairs. The routes get pushed via DHCP.

James

Sent from my iPhone

On Apr 2, 2016, at 9:28 PM, Mike Spreitzer <mspre...@us.ibm.com> wrote:

Is there a way to attach a routing rule to a network or subnet, with the 
consequence that each device attached to that net or subnet gets that 
routing rule?

Thanks,
Mike


___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators





___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [openstack-operators]disable snat for router gateway

[Mike Spreitzer]

Aaron Segura  wrote on 01/16/2016 12:19:53 PM:

> You shouldn't have to do anything other than disable SNAT and set a 
> route for your tenant network upstream.

Indeed, I have exercised exactly this.

Regards,
Mike



___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [neutron] Routing to tenant networks

[Mike Spreitzer]

> From: Carl Baldwin <c...@ecbaldwin.net>
> To: Dan Sneddon <dsned...@redhat.com>
> Cc: Matt Kassawara <mkassaw...@gmail.com>, Mike Spreitzer/Watson/
> IBM@IBMUS, "openstack-operators@lists.openstack.org"  operat...@lists.openstack.org>
> Date: 01/14/2016 10:59 AM
> Subject: Re: [Openstack-operators] [neutron] Routing to tenant networks
> 
...
> 
> I'd discourage the use of 100.64.0.0/10 for any tenant networks.
> Quoted the RFC [1]:  "This address block will be called the "Shared
> Address Space" and will be used to number the interfaces that connect
> CGN devices to Customer Premises Equipment (CPE)." and "In particular,
> Shared Address Space can only be used in Service Provider networks or
> on routing equipment that is able to do address translation across
> router interfaces when the addresses are identical on two different
> interfaces."  It isn't spelled out clearly, but this hints at only
> using these addresses on infrastructure devices used in service
> providers' networks.  The closest this would get to a customer is
> assigning the router at the customer's edge an address from this range
> (like your home router's external address).  These devices pass
> packets and use the shared address space to communicate with other
> devices in the service provider's network but these addresses are
> never seen by the end user in the packets that reach their devices.
...

I think OpenStack's position should be that it is the operator's choice 
how to assign/use addresses.  And OpenStack's advice to the operators 
should be to follow the RFC (duh!).

Thanks,
Mike


___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [neutron] Routing to tenant networks

[Mike Spreitzer]

Is there any condition under which a Neutron router will route packets 
from a provider network to a tenant network with destination address 
unmolested? E.g., non-RFC1918 addresses on the tenant network?  Does 
Neutron know anything about RFC6598?

Thanks,
Mike



___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] Neutron IPv6 manual for single-stacking in Juno

[Mike Spreitzer]

I see https://wiki.openstack.org/wiki/NEUTRON-IPV6-MANUAL explicitly 
disclaims interest in single-stacking and in Juno.  Where would I go to 
learn how to use IPv6 in the single-stack Juno case?

Thanks,
Mike

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [neutron] multiple external networks on the same host NIC

[Mike Spreitzer]

Uwe Sauter uwe.sauter...@gmail.com wrote on 04/25/2015 04:17:35 PM:

 Or instead of using Linux bridges you could use a manually created 
 OpenVSwitch bridge. This allows you to add internal
 ports that could be used by Neutron like any other interface.
 
 - Create OVS bridge
 - Add your external interface to OVS bridge
   * If your external connection supports/needs VLANs, configure 
 external interface as trunk
 - Add any number of internal interfaces to OVS bridge
   * Tag each interface with its VLAN ID, if needed
 - Configure Neutron to use one internal interface for each subnet 
 you'd like to use (no VLAN configuration required as
 this happenes outside of Neutron)
 
 Regards,
 
Uwe
 
 Am 25.04.2015 um 21:41 schrieb George Shuklin:
  Can you put them to different vlans? After that it would be very easy 
task.
  
  If not, AFAIK, neutron does not allow this.
  
  Or you can trick it thinking it is (are) separate networks.
  
  Create brige (br-join), plug eth to it.
  Create to fake external bridges (br-ex1, br-ex2). Join them 
 together to br-join by patch links
  (http://blog.scottlowe.org/2012/11/27/connecting-ovs-bridges-with-
 patch-ports/)
  
  Instruct neutron like there is two external networks: one on br-
 ex1, second on br-ex2.
  
  But be alert that this not very stable configuration, you need to 
 maintain it by yourself.
  
  On 04/25/2015 10:13 PM, Mike Spreitzer wrote:
  Is there a way to create multiple external networks from 
 Neutron's point of view, where both of those networks are
  accessed through the same host NIC?  Obviously those networks 
 would be using different subnets.  I need this sort of
  thing because the two subnets are treated differently by the 
 stuff outside of OpenStack, so I need a way that a tenant
  can get a floating IP of the sort he wants.  Since Neutron 
 equates floating IP allocation pools with external
  networks, I need two external networks.
 
  I found, for example, http://www.marcoberube.com/archives/248--- 
 which describes how to have multiple external
  networks but uses a distinct host network interface for each one.

Now that I have found my bridge_mappings configuration statement, I can 
return to thinking about what you said.  It sounds very similar to what 
George said --- it is just that you suggest an OVS switch in place of 
George's br-join (which I had assumed was also an OVS switch, since it is 
named like the others).  Do I have this right?

Thanks,
Mike

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [neutron] multiple external networks on the same host NIC

[Mike Spreitzer]

Uwe Sauter uwe.sauter...@gmail.com wrote on 04/27/2015 10:54:15 AM:

 Am 27.04.2015 um 16:36 schrieb Mike Spreitzer:
  Uwe Sauter uwe.sauter...@gmail.com wrote on 04/25/2015 04:17:35 PM:
  
  Or instead of using Linux bridges you could use a manually created
  OpenVSwitch bridge. This allows you to add internal
  ports that could be used by Neutron like any other interface.
 
  - Create OVS bridge
  - Add your external interface to OVS bridge
* If your external connection supports/needs VLANs, configure
  external interface as trunk
  - Add any number of internal interfaces to OVS bridge
* Tag each interface with its VLAN ID, if needed
  - Configure Neutron to use one internal interface for each subnet
  you'd like to use (no VLAN configuration required as
  this happenes outside of Neutron)
 
  Regards,
 
 Uwe
 
  Am 25.04.2015 um 21:41 schrieb George Shuklin:
   Can you put them to different vlans? After that it would be 
 very easy task.
  
   If not, AFAIK, neutron does not allow this.
  
   Or you can trick it thinking it is (are) separate networks.
  
   Create brige (br-join), plug eth to it.
   Create to fake external bridges (br-ex1, br-ex2). Join them
  together to br-join by patch links
   (http://blog.scottlowe.org/2012/11/27/connecting-ovs-bridges-with-
  patch-ports/)
  
   Instruct neutron like there is two external networks: one on br-
  ex1, second on br-ex2.
  
   But be alert that this not very stable configuration, you need to
  maintain it by yourself.
  
   On 04/25/2015 10:13 PM, Mike Spreitzer wrote:
   Is there a way to create multiple external networks from
  Neutron's point of view, where both of those networks are
   accessed through the same host NIC?  Obviously those networks
  would be using different subnets.  I need this sort of
   thing because the two subnets are treated differently by the
  stuff outside of OpenStack, so I need a way that a tenant
   can get a floating IP of the sort he wants.  Since Neutron
  equates floating IP allocation pools with external
   networks, I need two external networks.
  
   I found, for example, http://www.marcoberube.com/archives/248---
  which describes how to have multiple external
   networks but uses a distinct host network interface for each one.
  
  Now that I have found my bridge_mappings configuration statement, 
 I can return to thinking about what you said.  It sounds very
  similar to what George said --- it is just that you suggest an OVS
 switch in place of George's br-join (which I had assumed was
  also an OVS switch, since it is named like the others).  Do I have
 this right?
  
  Thanks,
  Mike
  
 
 Mike,
 
 
 if I understood Georges answer correctly he suggested one bridge 
 (br-join, either OVS or linux bridge) to connect other bridges
 via patch links, one for each external network you'd like to create.
 These second level bridges are then used for the Neutron
 configuration:
 
 br-ext1 - Neutron
/
 patch-link
  /
 ethX –br-join
  \
 patch-link
\
 br-ext2 - Neutron
 
 
 
 I suggested to use an OVS bridge because there it'd be possible to 
 stay away from the performance-wise worse patch-links and Linux
 bridges and use internal interfaces to connect to Neutron directly
 – which on second thought won't work if Neutron expects a
 bridge in that place.
 
 What I suggested later on is that you probably don't need any second
 level bridge at all. Just create a second/third external
 network with appropriate CIDR. As long as those networks are 
 externally connected to your interface (and thus the bridge) you
 should be good to go.

To be precise, are you suggesting that I have just one br-ex, connected to 
the host NIC as usual, and in my bridge_mappings configuration statement, 
map all the external network names to br-ex?

Thanks,
Mike



___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [neutron] multiple external networks on the same host NIC

[Mike Spreitzer]

Uwe Sauter uwe.sauter...@gmail.com wrote on 04/27/2015 01:22:35 PM:

  if I understood Georges answer correctly he suggested one bridge
  (br-join, either OVS or linux bridge) to connect other bridges
  via patch links, one for each external network you'd like to create.
  These second level bridges are then used for the Neutron
  configuration:
 
  br-ext1 - Neutron
 /
  patch-link
   /
  ethX –br-join
   \
  patch-link
 \
  br-ext2 - Neutron
 
 
 
  I suggested to use an OVS bridge because there it'd be possible to
  stay away from the performance-wise worse patch-links and Linux
  bridges and use internal interfaces to connect to Neutron directly
  – which on second thought won't work if Neutron expects a
  bridge in that place.
 
  What I suggested later on is that you probably don't need any second
  level bridge at all. Just create a second/third external
  network with appropriate CIDR. As long as those networks are
  externally connected to your interface (and thus the bridge) you
  should be good to go.
  
  In parallel emails we have established that I have to do what you 
 have drawn.  I need to do that the node(s) that run L3
  agents.  Do I need to modify the bridge_mappings, flat_networks, 
 or network_vlan_ranges configuration statement on the
  other nodes (compute hosts)?
  
  Thanks,
  Mike
  
 
 I think you just need to create the cascading bridges with their 
 inter-connects, then tell Neutron the association
 between secondary bridge (e.g. br-ext1, br-ext2) and external 
 network. Then create (!) the external networks and restart
 Neutron.
 
 Concerning you intra-cloud networking I don't think you need to 
 reconfigure anything as long as this is already working.
 Compute hosts shouldn't be affected as its not their business to 
 know about external networks.

So I did what George said and you drew, using OVS bridges, and it seems to 
be working.

Thanks,
Mike


___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [neutron] multiple external networks on the same host NIC

[Mike Spreitzer]

gustavo panizzo (gfa) g...@zumbi.com.ar wrote on 04/27/2015 11:23:13 
AM:

 On 2015-04-27 22:59, Mike Spreitzer wrote:
  Uwe Sauter uwe.sauter...@gmail.com wrote on 04/27/2015 10:54:15 AM:
 
  What I suggested later on is that you probably don't need any second
  level bridge at all. Just create a second/third external
  network with appropriate CIDR. As long as those networks are
  externally connected to your interface (and thus the bridge) you
  should be good to go.
  
  To be precise, are you suggesting that I have just one br-ex, 
connected
  to the host NIC as usual, and in my bridge_mappings configuration
  statement, map all the external network names to br-ex?
 
 you can only have one flat network per bridge.
 
 i don't know what's your usercase but one i had the need to map 2
 different public ip address to each vm vnic, i was going to do the
 double bridge thing but i resolved it using allowed pairs extension. it
 may work for you

My use case is that I have two behaviorally different external subnets --- 
they are treated differently by stuff outside of OpenStack, with 
consequences that are meaningful to tenants.  Thus, I have two categories 
of floating IP addresses, depending on which external subnet holds the 
floating IP address.  The difference is meaningful to tenants.  So I need 
to enable a tenant to request a floating IP address of a specific 
category.  Since Neutron equates floating IP address allocation pool with 
network, I need two external networks.

Both of these external subnets are present on the same actual external 
LAN, thus both are reached through the same host NIC.

It looks to me like the allowed mac/IP address pair feature will not solve 
this problem.

Thanks,
Mike

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [neutron] multiple external networks on the same host NIC

[Mike Spreitzer]

 gustavo panizzo (gfa) g...@zumbi.com.ar wrote on 04/27/2015 11:23:13 
AM:
 
  On 2015-04-27 22:59, Mike Spreitzer wrote:
   Uwe Sauter uwe.sauter...@gmail.com wrote on 04/27/2015 10:54:15 
AM:
  
   What I suggested later on is that you probably don't need any 
second
   level bridge at all. Just create a second/third external
   network with appropriate CIDR. As long as those networks are
   externally connected to your interface (and thus the bridge) you
   should be good to go.
   
   To be precise, are you suggesting that I have just one br-ex, 
connected
   to the host NIC as usual, and in my bridge_mappings configuration
   statement, map all the external network names to br-ex?
  
  you can only have one flat network per bridge.
  
  i don't know what's your usercase but one i had the need to map 2
  different public ip address to each vm vnic, i was going to do the
  double bridge thing but i resolved it using allowed pairs extension. 
it
  may work for you
 
 My use case is that I have two behaviorally different external 
 subnets --- they are treated differently by stuff outside of 
 OpenStack, with consequences that are meaningful to tenants.  Thus, 
 I have two categories of floating IP addresses, depending on which 
 external subnet holds the floating IP address.  The difference is 
 meaningful to tenants.  So I need to enable a tenant to request a 
 floating IP address of a specific category.  Since Neutron equates 
 floating IP address allocation pool with network, I need two 
 external networks. 
 
 Both of these external subnets are present on the same actual 
 external LAN, thus both are reached through the same host NIC. 
 
 It looks to me like the allowed mac/IP address pair feature will not
 solve this problem. 

Sorry, I simplified too much.  Here is one other critical detail.  I do 
not really have just two different external subnets.  What I really have 
is two behaviorally different collections of subnets.  I need to make a 
Neutron external network for each of the two collections of external 
subnets.

Thanks,
Mike

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [neutron] multiple external networks on the same host NIC

[Mike Spreitzer]

Uwe Sauter uwe.sauter...@gmail.com wrote on 04/27/2015 10:54:15 AM:

 Am 27.04.2015 um 16:36 schrieb Mike Spreitzer:
  Uwe Sauter uwe.sauter...@gmail.com wrote on 04/25/2015 04:17:35 PM:
  
  Or instead of using Linux bridges you could use a manually created
  OpenVSwitch bridge. This allows you to add internal
  ports that could be used by Neutron like any other interface.
 
  - Create OVS bridge
  - Add your external interface to OVS bridge
* If your external connection supports/needs VLANs, configure
  external interface as trunk
  - Add any number of internal interfaces to OVS bridge
* Tag each interface with its VLAN ID, if needed
  - Configure Neutron to use one internal interface for each subnet
  you'd like to use (no VLAN configuration required as
  this happenes outside of Neutron)
 
  Regards,
 
 Uwe
 
  Am 25.04.2015 um 21:41 schrieb George Shuklin:
   Can you put them to different vlans? After that it would be 
 very easy task.
  
   If not, AFAIK, neutron does not allow this.
  
   Or you can trick it thinking it is (are) separate networks.
  
   Create brige (br-join), plug eth to it.
   Create to fake external bridges (br-ex1, br-ex2). Join them
  together to br-join by patch links
   (http://blog.scottlowe.org/2012/11/27/connecting-ovs-bridges-with-
  patch-ports/)
  
   Instruct neutron like there is two external networks: one on br-
  ex1, second on br-ex2.
  
   But be alert that this not very stable configuration, you need to
  maintain it by yourself.
  
   On 04/25/2015 10:13 PM, Mike Spreitzer wrote:
   Is there a way to create multiple external networks from
  Neutron's point of view, where both of those networks are
   accessed through the same host NIC?  Obviously those networks
  would be using different subnets.  I need this sort of
   thing because the two subnets are treated differently by the
  stuff outside of OpenStack, so I need a way that a tenant
   can get a floating IP of the sort he wants.  Since Neutron
  equates floating IP allocation pools with external
   networks, I need two external networks.
  
   I found, for example, http://www.marcoberube.com/archives/248---
  which describes how to have multiple external
   networks but uses a distinct host network interface for each one.
  
  Now that I have found my bridge_mappings configuration statement, 
 I can return to thinking about what you said.  It sounds very
  similar to what George said --- it is just that you suggest an OVS
 switch in place of George's br-join (which I had assumed was
  also an OVS switch, since it is named like the others).  Do I have
 this right?
  
  Thanks,
  Mike
  
 
 Mike,
 
 
 if I understood Georges answer correctly he suggested one bridge 
 (br-join, either OVS or linux bridge) to connect other bridges
 via patch links, one for each external network you'd like to create.
 These second level bridges are then used for the Neutron
 configuration:
 
 br-ext1 - Neutron
/
 patch-link
  /
 ethX –br-join
  \
 patch-link
\
 br-ext2 - Neutron
 
 
 
 I suggested to use an OVS bridge because there it'd be possible to 
 stay away from the performance-wise worse patch-links and Linux
 bridges and use internal interfaces to connect to Neutron directly
 – which on second thought won't work if Neutron expects a
 bridge in that place.
 
 What I suggested later on is that you probably don't need any second
 level bridge at all. Just create a second/third external
 network with appropriate CIDR. As long as those networks are 
 externally connected to your interface (and thus the bridge) you
 should be good to go.

In parallel emails we have established that I have to do what you have 
drawn.  I need to do that the node(s) that run L3 agents.  Do I need to 
modify the bridge_mappings, flat_networks, or network_vlan_ranges 
configuration statement on the other nodes (compute hosts)?

Thanks,
Mike


___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [neutron] multiple external networks on the same host NIC

[Mike Spreitzer]

Is there a way to create multiple external networks from Neutron's point 
of view, where both of those networks are accessed through the same host 
NIC?  Obviously those networks would be using different subnets.  I need 
this sort of thing because the two subnets are treated differently by the 
stuff outside of OpenStack, so I need a way that a tenant can get a 
floating IP of the sort he wants.  Since Neutron equates floating IP 
allocation pools with external networks, I need two external networks.

I found, for example, http://www.marcoberube.com/archives/248 --- which 
describes how to have multiple external networks but uses a distinct host 
network interface for each one.

Thanks,
Mike___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [neutron] multiple external networks on the same host NIC

[Mike Spreitzer]

Uwe Sauter uwe.sauter...@gmail.com wrote on 04/25/2015 04:42:06 PM:

 Am 25.04.2015 um 22:28 schrieb Mike Spreitzer:
  From: Uwe Sauter uwe.sauter...@gmail.com
 
  Or instead of using Linux bridges you could use a manually created
  OpenVSwitch bridge. This allows you to add internal
  ports that could be used by Neutron like any other interface.
 
  - Create OVS bridge
  - Add your external interface to OVS bridge
* If your external connection supports/needs VLANs, configure
  external interface as trunk
  - Add any number of internal interfaces to OVS bridge
* Tag each interface with its VLAN ID, if needed
  - Configure Neutron to use one internal interface for each subnet
  you'd like to use (no VLAN configuration required as
  this happenes outside of Neutron)
 
  Regards,
 
 Uwe
 
  Am 25.04.2015 um 21:41 schrieb George Shuklin:
   Can you put them to different vlans? After that it would be 
 very easy task.
  
   If not, AFAIK, neutron does not allow this.
  
   Or you can trick it thinking it is (are) separate networks.
  
   Create brige (br-join), plug eth to it.
   Create to fake external bridges (br-ex1, br-ex2). Join them
  together to br-join by patch links
   (http://blog.scottlowe.org/2012/11/27/connecting-ovs-bridges-with-
  patch-ports/)
  
   Instruct neutron like there is two external networks: one on br-
  ex1, second on br-ex2.
  
   But be alert that this not very stable configuration, you need to
  maintain it by yourself.
  
   On 04/25/2015 10:13 PM, Mike Spreitzer wrote:
   Is there a way to create multiple external networks from
  Neutron's point of view, where both of those networks are
   accessed through the same host NIC?  Obviously those networks
  would be using different subnets.  I need this sort of
   thing because the two subnets are treated differently by the
  stuff outside of OpenStack, so I need a way that a tenant
   can get a floating IP of the sort he wants.  Since Neutron
  equates floating IP allocation pools with external
   networks, I need two external networks.
  
   I found, for example, http://www.marcoberube.com/archives/248---
  which describes how to have multiple external
   networks but uses a distinct host network interface for each one.
  
   Thanks,
   Mike
  
  Thanks Uwe, I might try that, it sounds like the simplest thing 
 that will work.  I think I can not use VLAN tagging in my
  environment.  I am using ML2 with OVS, and it is working now with 
 a single external network.  Should I expect to find a
  bridge_mappings entry in my plugin.ini?  I do not find one now. 
 This setup was mainly created by other people, so I am not sure
  what to expect.  When using ML2 with OVS, how do I tell Neutron 
 what my bridge mappings are?
  
  Thanks,
  Mike
  
 
 Mike,
 
 VLAN is optional in the setup I described. I just was pointing out 
 where such a configuration could take place.
 
 As far as my experience with OVS and Neutron goes, Neutron will just
 ignore already existing configurations. That's also the
 reason why install manuals tell you to create br-int and br-ex.
 
 Regarding the exact configuration of ML2 and plugin.ini I'm not 
 quite sure if I understand your question correctly. Are you asking
 how to tell Neutron which interface should be used for the different
 IP subnets?
 
 Perhaps you could post your plugin.ini with sensitive information 
 replaced with something generic.
 
 Regards,
 
Uwe
 

Yes, I realize the VLAN tagging is just an option in the approach you are 
outlining.  George pointed out that VLAN tagging could carry even more of 
the load here.  I mentioned that I can not use VLAN tagging as an 
explanation of why I have to pursue what you are describing.

Following in my plugin.ini.  As you can see, it is not what I would be 
editing. I have already added stuff to flat_networks, in anticipation of 
being able to use more than one.  My problem is that there is no 
bridge_mappings, so I can not update it to add more external networks!


# This file autogenerated by Chef
# Do not edit, changes will be overwritten

[ml2]
# (ListOpt) List of network type driver entrypoints to be loaded from
# the neutron.ml2.type_drivers namespace.
#
# type_drivers = local,flat,vlan,gre,vxlan
# Example: type_drivers = flat,vlan,gre,vxlan
type_drivers = gre,flat

# (ListOpt) Ordered list of network_types to allocate as tenant
# networks. The default value 'local' is useful for single-box testing
# but provides no connectivity between hosts.
#
# tenant_network_types = local
# Example: tenant_network_types = vlan,gre,vxlan
tenant_network_types = gre

# (ListOpt) Ordered list of networking mechanism driver entrypoints
# to be loaded from the neutron.ml2.mechanism_drivers namespace.
# mechanism_drivers =
# Example: mechanism_drivers = openvswitch,mlnx
# Example: mechanism_drivers = arista
# Example: mechanism_drivers = cisco,logger
# Example: mechanism_drivers = openvswitch,brocade
# Example: mechanism_drivers = linuxbridge,brocade

Re: [Openstack-operators] [neutron] multiple external networks on the same host NIC

[Mike Spreitzer]

Kevin Benton blak...@gmail.com wrote on 04/25/2015 08:38:25 PM:

 Bridge mappings is an agent configuration value, it's not in the 
 neutron server config. 
 Run ps -ef and look for the neutron openvswitch agent process to see
 which configuration files it's referencing. The bridge mappings will
 be in one of those. 

Thanks, that led me to it.

Mike

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [Neutron] Floating IPs / Router Gateways

[Mike Spreitzer]

 From: Jacob Godin jacobgo...@gmail.com
 To: Mike Spreitzer/Watson/IBM@IBMUS
 Cc: Daniel Comnea comnea.d...@gmail.com, OpenStack Operators 
 openstack-operators@lists.openstack.org
 Date: 04/15/2015 08:37 AM
 Subject: Re: [Openstack-operators] [Neutron] Floating IPs / Router 
Gateways
 
 Ah, gotcha. So you're not using overlapping subnets then.
 
 Unfortunately that hack wouldn't work in our environment, but 
 definitely something that others might consider using.

Right, the solution I am using now imposes address constraints between 
tenants that share a router.  I need to eliminate constraints between 
tenants, so I have to abandon the solution I am using.  So I, too, am 
looking for different solution.

I want to support a lot of tenants doing fairly unrestricted stuff, so all 
the connections --- from their Compute Instances that do NOT have a 
floating IP --- to public servers is more than I want to SNAT onto a 
*single* public address.

Thanks,
Mike

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [Neutron] Floating IPs / Router Gateways

[Mike Spreitzer]

 From: Mike Spreitzer/Watson/IBM@IBMUS
 
  From: Jacob Godin jacobgo...@gmail.com 
  
  Ah, gotcha. So you're not using overlapping subnets then. 
  
  Unfortunately that hack wouldn't work in our environment, but 
  definitely something that others might consider using. 
 
 Right, the solution I am using now imposes address constraints 
 between tenants that share a router.  I need to eliminate 
 constraints between tenants, so I have to abandon the solution I am 
 using.  So I, too, am looking for different solution. 
 
 I want to support a lot of tenants doing fairly unrestricted stuff, 
 so all the connections --- from their Compute Instances that do NOT 
 have a floating IP --- to public servers is more than I want to SNAT
 onto a *single* public address. 

I found a few tantalizing leads in 
http://specs.openstack.org/openstack/neutron-specs/index.html
I can not check them out fully right now because review.openstack.org is 
temporarily down.

http://specs.openstack.org/openstack/neutron-specs/specs/kilo/specify-router-ext-ip.html
Allow the external IP address of a router to be specified

If you, like I, are intermediating the calls on Neutron and can transform 
a less specific call by the tenant into a precise formulation of your 
choosing (as either admin or the tenant, on a case by case basis), you can 
use the following solution.

Let the external network known to Neutron not be the actual public 
network but rather some other private network.  Using control over the 
router's IP on that other private network, scrunch all the router IP 
addresses into a dense range that is not in the allocation range.  Thus, 
the router IP addresses and the tenants' floating IP addresses are 
separated - you can put them in distinct large CIDR blocks.  Using some 
other router that connects that other private network to the actual public 
network, masquerade the router IP addresses onto however many public 
addresses you like, while doing 1:1 bidirectional NAT for the tenants' 
floating IP addresses.

Regards,
Mike___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [Neutron] Floating IPs / Router Gateways

[Mike Spreitzer]

 From: Daniel Comnea comnea.d...@gmail.com
 To: Jacob Godin jacobgo...@gmail.com
 Cc: Mike Spreitzer/Watson/IBM@IBMUS, OpenStack Operators openstack-
 operat...@lists.openstack.org
 Date: 04/15/2015 02:34 AM
 Subject: Re: [Openstack-operators] [Neutron] Floating IPs / Router 
Gateways
 Sent by: daniel.com...@gmail.com
 
 Mike, pls share the solution, some are interested even if is a hack 
 as long as it gets the job done.
 

 
 On Tue, Apr 14, 2015 at 10:24 PM, Jacob Godin jacobgo...@gmail.com 
wrote:
 Hey Mike,
 
 Would you send along your solution off-list? I'm curious, and I won't 
judge :)
 
 On Tue, Apr 14, 2015 at 6:22 PM, Mike Spreitzer mspre...@us.ibm.com 
wrote:
 Jacob Godin jacobgo...@gmail.com wrote on 04/14/2015 05:12:48 PM:
 
  Absolutely. We're trying to reduce our public IPv4 usage, so having 
  one per tenant network (not even including floating IPs) is a drain. 
 
 I am having exactly the same issue.  I am currently solving it with 
 a different hack that nobody likes, I will not even describe it 
 here.  But total agreement that the problem is important. 
 
 IPv6 is the ultimate answer, provided there is a reasonably smooth 
 transition.  I think we will need to support a tenant that is using 
 both v4 and v6 during his transition.  This will require NAT between
 a tenant's v4 and v6. 
 
 Regards, 
 Mike

OK, you asked for it.  What we do is share Neutron routers, and add some 
iptables rules that prevent communication between the tenants sharing a 
router.  I told you it was a hack.

Regards,
Mike

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [Neutron] Floating IPs / Router Gateways

[Mike Spreitzer]

Jacob Godin jacobgo...@gmail.com wrote on 04/14/2015 05:12:48 PM:

 Absolutely. We're trying to reduce our public IPv4 usage, so having 
 one per tenant network (not even including floating IPs) is a drain.

I am having exactly the same issue.  I am currently solving it with a 
different hack that nobody likes, I will not even describe it here.  But 
total agreement that the problem is important.

IPv6 is the ultimate answer, provided there is a reasonably smooth 
transition.  I think we will need to support a tenant that is using both 
v4 and v6 during his transition.  This will require NAT between a tenant's 
v4 and v6.

Regards,
Mike___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators