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!')) |
||||