在上一篇博文分析完 Neutron Server 的启动过程后，按原先安排应该是接着分析 L2、L3 等服务(agent)的启动过程，但发现它们的启动过程相对于 Neutron Server 来说要简单的多，也比较类似，再过多阐述有点重复的嫌疑；另外也是为了从实践角度出发，对虚拟机创建过程的情景做一个分析，将 Nova、Glance、Neutron 及 Cinder 模块串联起来，其中夹杂对一些关键服务（如 L2、L3）的分析，也不失为一个好的办法。所以，接下来，我们将从虚拟机创建情境入手，一步步来分析涉及的知识点。今天我们先来看下创建虚拟机会用到的网络及子网。
网络及子网在 Neutron 中都属于 Core Resouce，它们的创建入口在 Core Plugin（ML2）中（具体路由分析见上一篇博文 Neutron Server 的启动过程）。还有一点需要特别注意的是，Core Plugin 中的 Resource CRUD 操作一般都会涉及与 Type driver、Mechanism driver、Extension driver 及 RPC 的交互。接下来对网络及子网的创建也会重点从这 4 点出发来分析。
开始之前，我们先说一下本文一些前提条件：
- L2 Agent 采用的是 Linux Bridge Agent
- 新建的（租户）网络的类型为 VLAN（Enable 了 Admin State）
- 新建（该网络的）子网开启 DHCP，手动设置 CIDR（不从 subnet pool 分配）
- 其余都采用默认值（Extension driver 默认开启了 port security）
创建网络
在 ML2 中，创建网络（create_network 函数）算是最简单的，因为它最主要的事情就是把网络相关信息保存到 Neutron 数据库当中。
下边我们可以从 5 个部分来分析一下：
- 自身(网络)：在 networks 表添加一条记录，记录自己的信息
- Type driver：在 networksegments 表添加一条记录，记录该网络的
类型信息、segmentation id - Mechanism driver: 所调用的 create_network_precommit 和 create_network_postcommit 均是直接返回（pass）
- Extension driver: 在 networksecuritybindings 表添加一条记录，记录是否开始 port security（默认开启）
- RPC：ML2 中初始化的 DhcpAgentNotifyAPI（参考上文）订阅（subscribe）了网络创建的事件（AFTER_CREATE，详细参考上文Callback System），所以在创建网络结束后会轮询调用到 DhcpAgentNotifyAPI 中的 _native_event_send_dhcp_notification 函数，但最后还是直接返回而没有其他操作
