在OpenStack中，三层路由器的实现是利用了Linux的NameSpace和iptable来完成的。每当云平台上创建一个路由器，Neutron就会在网络节点创建一个与之对应的NameSpace。
最近大半年一直在参与公司针对OpenStack的一些定制开发，主要是与Neutron组件相关。大大小小的各个项目中，与华为、中兴、EasyStack等都有过合作，每个项目基于的OpenStack版本都不一样，所以经常来回的安装部署OpenStack环境，比较繁琐，工作之余一直在寻求一种部署环境的便捷方式。目前比较主流的部署方式是devstack，也非常方便，但观察OpenStack的发展趋势，已经有越来越多的公司在做OpenStack的容器化部署，OpenStack社区也有对应的项目：kolla，虽然现在用的不是特别多，但利用容器产生的一些优势，相信在将来会有更多的公司采用容器化部署，本人在空闲时间尝试用kolla部署了一套mitaka版本的OpenStack环境（ALL IN ONE），以下是详细步骤，如果有任何问题也欢迎底下留言。
neutron除了核心资源以外还有扩展资源，核心资源的API处理实现流程已经分析过了（见：https://blog.try-except.com/technology/neutron-server-api.html）。
那么neutron是如何支持扩展资源的API并进行相关的路由配置呢？
neutron-server服务启动完成后，就能接收API请求并做出相应的处理了，本文就来分析一下neutron server是如何处理各API请求的。
neutron-server启动的过程可以参考：https://blog.try-except.com/technology/neutron-server-start.html
neutron-server是目前接触的比较多的一个项目，抽空分析一下它是如何启动的。
在上一篇文章中已经学习了如何使用oslo_config模块，再通过这篇文章跟大家讲解一下它的实现原理，丛里到外一层层剥开这个模块的面纱。方便大家更轻松的学习OpenStack源代码。
oslo_config模块是openstack用来解析命令行选项和读取配置文件的一个库。该库在OpenStack中使用是非常广泛的，应该是所有的组件都用到了它。所以在学习OpenStack代码之前，非常有必要了解一下它的使用方法和运行原理。
Zaqar是openstack内的多租户云消息服务组件，它借鉴了Amazon SQS消息组件的实现。为在Openstack内构建可伸缩、可靠和高性能的云应用提供了通道。
在Openstack的计算节点中都会运行一个neutron的L2agent，它与neutron server端的plugin共同来提供和管理二层网络的功能，目前比较流行的一个是OVS Neutron Agent。
下面就开始对其源码进行分析，本文不会分析所有的代码，只对其中vlan相关的内容进行解读。
我们已经知道在二层中的API资源(network, subnet, port)被称为是neutron的核心资源，并且由Core-plugin(ML2)负责管理。
而从三层到七层的API资源包括L3的Router，防火墙等被称为neutron的扩展资源，由Neutron中的service-plugin来负责管理。对这些资源进行操作的REST API被neutron-server看作是Extension API。