Kyle Mestery
7 years ago
275 changed files with 9330 additions and 6560 deletions
@ -0,0 +1,9 @@ |
|||
================================= |
|||
Client command extension support |
|||
================================= |
|||
|
|||
The client command extension adds support for extending the neutron client while |
|||
considering ease of creation. |
|||
|
|||
The full document can be found in the python-neutronclient repository: |
|||
http://docs.openstack.org/developer/python-neutronclient/devref/client_command_extensions.html |
|||
@ -0,0 +1,74 @@ |
|||
Keep DNS Nameserver Order Consistency In Neutron |
|||
================================================ |
|||
|
|||
In Neutron subnets, DNS nameservers are given priority when created or updated. |
|||
This means if you create a subnet with multiple DNS servers, the order will |
|||
be retained and guests will receive the DNS servers in the order you |
|||
created them in when the subnet was created. The same thing applies for update |
|||
operations on subnets to add, remove, or update DNS servers. |
|||
|
|||
Get Subnet Details Info |
|||
----------------------- |
|||
:: |
|||
|
|||
changzhi@stack:~/devstack$ neutron subnet-list |
|||
+--------------------------------------+------+-------------+--------------------------------------------+ |
|||
| id | name | cidr | allocation_pools | |
|||
+--------------------------------------+------+-------------+--------------------------------------------+ |
|||
| 1a2d261b-b233-3ab9-902e-88576a82afa6 | | 10.0.0.0/24 | {"start": "10.0.0.2", "end": "10.0.0.254"} | |
|||
+--------------------------------------+------+-------------+--------------------------------------------+ |
|||
|
|||
changzhi@stack:~/devstack$ neutron subnet-show 1a2d261b-b233-3ab9-902e-88576a82afa6 |
|||
+------------------+--------------------------------------------+ |
|||
| Field | Value | |
|||
+------------------+--------------------------------------------+ |
|||
| allocation_pools | {"start": "10.0.0.2", "end": "10.0.0.254"} | |
|||
| cidr | 10.0.0.0/24 | |
|||
| dns_nameservers | 1.1.1.1 | |
|||
| | 2.2.2.2 | |
|||
| | 3.3.3.3 | |
|||
| enable_dhcp | True | |
|||
| gateway_ip | 10.0.0.1 | |
|||
| host_routes | | |
|||
| id | 1a2d26fb-b733-4ab3-992e-88554a87afa6 | |
|||
| ip_version | 4 | |
|||
| name | | |
|||
| network_id | a404518c-800d-2353-9193-57dbb42ac5ee | |
|||
| tenant_id | 3868290ab10f417390acbb754160dbb2 | |
|||
+------------------+--------------------------------------------+ |
|||
|
|||
Update Subnet DNS Nameservers |
|||
----------------------------- |
|||
:: |
|||
|
|||
neutron subnet-update 1a2d261b-b233-3ab9-902e-88576a82afa6 \ |
|||
--dns_nameservers list=true 3.3.3.3 2.2.2.2 1.1.1.1 |
|||
|
|||
changzhi@stack:~/devstack$ neutron subnet-show 1a2d261b-b233-3ab9-902e-88576a82afa6 |
|||
+------------------+--------------------------------------------+ |
|||
| Field | Value | |
|||
+------------------+--------------------------------------------+ |
|||
| allocation_pools | {"start": "10.0.0.2", "end": "10.0.0.254"} | |
|||
| cidr | 10.0.0.0/24 | |
|||
| dns_nameservers | 3.3.3.3 | |
|||
| | 2.2.2.2 | |
|||
| | 1.1.1.1 | |
|||
| enable_dhcp | True | |
|||
| gateway_ip | 10.0.0.1 | |
|||
| host_routes | | |
|||
| id | 1a2d26fb-b733-4ab3-992e-88554a87afa6 | |
|||
| ip_version | 4 | |
|||
| name | | |
|||
| network_id | a404518c-800d-2353-9193-57dbb42ac5ee | |
|||
| tenant_id | 3868290ab10f417390acbb754160dbb2 | |
|||
+------------------+--------------------------------------------+ |
|||
|
|||
As shown in above output, the order of the DNS nameservers has been updated. |
|||
New virtual machines deployed to this subnet will receive the DNS nameservers |
|||
in this new priority order. Existing virtual machines that have already been |
|||
deployed will not be immediately affected by changing the DNS nameserver order |
|||
on the neutron subnet. Virtual machines that are configured to get their IP |
|||
address via DHCP will detect the DNS nameserver order change |
|||
when their DHCP lease expires or when the virtual machine is restarted. |
|||
Existing virtual machines configured with a static IP address will never |
|||
detect the updated DNS nameserver order. |
|||
@ -0,0 +1,27 @@ |
|||
====================================== |
|||
L2 Networking with SR-IOV enabled NICs |
|||
====================================== |
|||
SR-IOV (Single Root I/O Virtualization) is a specification that allows |
|||
a PCIe device to appear to be multiple separate physical PCIe devices. |
|||
SR-IOV works by introducing the idea of physical functions (PFs) and virtual functions (VFs). |
|||
Physical functions (PFs) are full-featured PCIe functions. |
|||
Virtual functions (VFs) are “lightweight” functions that lack configuration resources. |
|||
|
|||
SR-IOV supports VLANs for L2 network isolation, other networking technologies |
|||
such as VXLAN/GRE may be supported in the future. |
|||
|
|||
SR-IOV NIC agent manages configuration of SR-IOV Virtual Functions that connect |
|||
VM instances running on the compute node to the public network. |
|||
|
|||
In most common deployments, there are compute and a network nodes. |
|||
Compute node can support VM connectivity via SR-IOV enabled NIC. SR-IOV NIC Agent manages |
|||
Virtual Functions admin state. In the future it will manage additional settings, such as |
|||
quality of service, rate limit settings, spoofcheck and more. |
|||
Network node will be usually deployed with either Open vSwitch or Linux Bridge to support network node functionality. |
|||
|
|||
|
|||
Further Reading |
|||
--------------- |
|||
|
|||
* `Nir Yechiel - SR-IOV Networking – Part I: Understanding the Basics <http://redhatstackblog.redhat.com/2015/03/05/red-hat-enterprise-linux-openstack-platform-6-sr-iov-networking-part-i-understanding-the-basics/>`_ |
|||
* `SR-IOV Passthrough For Networking <https://wiki.openstack.org/wiki/SR-IOV-Passthrough-For-Networking/>`_ |
|||
@ -1,31 +0,0 @@ |
|||
# Config file for Metaplugin |
|||
|
|||
[meta] |
|||
# Comma separated list of flavor:neutron_plugin for plugins to load. |
|||
# Extension method is searched in the list order and the first one is used. |
|||
plugin_list = 'ml2:neutron.plugins.ml2.plugin.Ml2Plugin,nvp:neutron.plugins.vmware.plugin.NsxPluginV2' |
|||
|
|||
# Comma separated list of flavor:neutron_plugin for L3 service plugins |
|||
# to load. |
|||
# This is intended for specifying L2 plugins which support L3 functions. |
|||
# If you use a router service plugin, set this blank. |
|||
l3_plugin_list = |
|||
|
|||
# Default flavor to use, when flavor:network is not specified at network |
|||
# creation. |
|||
default_flavor = 'nvp' |
|||
|
|||
# Default L3 flavor to use, when flavor:router is not specified at router |
|||
# creation. |
|||
# Ignored if 'l3_plugin_list' is blank. |
|||
default_l3_flavor = |
|||
|
|||
# Comma separated list of supported extension aliases. |
|||
supported_extension_aliases = 'provider,binding,agent,dhcp_agent_scheduler' |
|||
|
|||
# Comma separated list of method:flavor to select specific plugin for a method. |
|||
# This has priority over method search order based on 'plugin_list'. |
|||
extension_map = 'get_port_stats:nvp' |
|||
|
|||
# Specifies flavor for plugin to handle 'q-plugin' RPC requests. |
|||
rpc_flavor = 'ml2' |
|||
@ -1,17 +0,0 @@ |
|||
# neutron-rootwrap command filters for nodes on which neutron is |
|||
# expected to control network |
|||
# |
|||
# This file should be owned by (and only-writeable by) the root user |
|||
|
|||
# format seems to be |
|||
# cmd-name: filter-name, raw-command, user, args |
|||
|
|||
[Filters] |
|||
|
|||
# cisco-apic filters |
|||
lldpctl: CommandFilter, lldpctl, root |
|||
|
|||
# ip_lib filters |
|||
ip: IpFilter, ip, root |
|||
find: RegExpFilter, find, root, find, /sys/class/net, -maxdepth, 1, -type, l, -printf, %.* |
|||
ip_exec: IpNetnsExecFilter, ip, root |
|||
@ -0,0 +1,42 @@ |
|||
# Licensed under the Apache License, Version 2.0 (the "License"); you may |
|||
# not use this file except in compliance with the License. You may obtain |
|||
# a copy of the License at |
|||
# |
|||
# http://www.apache.org/licenses/LICENSE-2.0 |
|||
# |
|||
# Unless required by applicable law or agreed to in writing, software |
|||
# distributed under the License is distributed on an "AS IS" BASIS, WITHOUT |
|||
# WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the |
|||
# License for the specific language governing permissions and limitations |
|||
# under the License. |
|||
|
|||
from oslo_log import log as logging |
|||
|
|||
from neutron.agent.l3 import router_info as router |
|||
from neutron.common import constants as l3_constants |
|||
from neutron.i18n import _LE |
|||
|
|||
LOG = logging.getLogger(__name__) |
|||
|
|||
|
|||
class DvrRouterBase(router.RouterInfo): |
|||
def __init__(self, agent, host, *args, **kwargs): |
|||
super(DvrRouterBase, self).__init__(*args, **kwargs) |
|||
|
|||
self.agent = agent |
|||
self.host = host |
|||
|
|||
def get_snat_interfaces(self): |
|||
return self.router.get(l3_constants.SNAT_ROUTER_INTF_KEY, []) |
|||
|
|||
def get_snat_port_for_internal_port(self, int_port): |
|||
"""Return the SNAT port for the given internal interface port.""" |
|||
snat_ports = self.get_snat_interfaces() |
|||
fixed_ip = int_port['fixed_ips'][0] |
|||
subnet_id = fixed_ip['subnet_id'] |
|||
match_port = [p for p in snat_ports |
|||
if p['fixed_ips'][0]['subnet_id'] == subnet_id] |
|||
if match_port: |
|||
return match_port[0] |
|||
else: |
|||
LOG.error(_LE('DVR: no map match_port found!')) |
|||