openstack核心组件-neutron-理论

neutron 介绍：

传统的网络管理方式很大程度上依赖于管理员手工配置和维护各种网络硬件设备；而云环境下的网络已经变得非常复杂，特别是在多租户场景里，用户随时都可能需要创建、修改和删除网络，网络的连通性和隔离不已经太可能通过手工配置来保证了。

如何快速响应业务的需求对网络管理提出了更高的要求。传统的网络管理方式已经很难胜任这项工作，而“软件定义网络（software-defined networking, SDN）”所具有的灵活性和自动化优势使其成为云时代网络管理的主流。

Neutron 的设计目标是实现“网络即服务（Networking as a Service）”。为了达到这一目标，在设计上遵循了基于 SDN 实现网络虚拟化的原则，在实现上充分利用了 Linux 系统上的各种网络相关的技术。

SDN 模式服务— NeutronSDN( 软件定义网络 ), 通过使用它，网络管理员和云计算操作员可以通过程序来动态定义虚拟网络设备。Openstack 网络中的 SDN 组件就是 Quantum.但因为版权问题而改名为Neutron 。

Neutron网络基本概念

（1）network

network 是一个隔离的二层广播域。Neutron 支持多种类型的 network，包括 local, flat, VLAN, VxLAN 和 GRE。

local
local 网络与其他网络和节点隔离。local 网络中的 instance 只能与位于同一节点上同一网络的 instance 通信，local 网络主要用于单机测试。

flat
flat 网络是无 vlan tagging 的网络。flat 网络中的 instance 能与位于同一网络的 instance 通信，并且可以跨多个节点。

vlan
vlan 网络是具有 802.1q tagging 的网络。vlan 是一个二层的广播域，同一 vlan 中的 instance 可以通信，不同 vlan 只能通过 router 通信。vlan 网络可跨节点，是应用最广泛的网络类型。

vxlan
vxlan 是基于隧道技术的 overlay 网络。vxlan 网络通过唯一的 segmentation ID（也叫 VNI）与其他 vxlan 网络区分。vxlan 中数据包会通过 VNI 封装成 UDP 包进行传输。因为二层的包通过封装在三层传输，能够克服 vlan 和物理网络基础设施的限制。

gre
gre 是与 vxlan 类似的一种 overlay 网络。主要区别在于使用 IP 包而非 UDP 进行封装。

不同 network 之间在二层上是隔离的。

以 vlan 网络为例，network A 和 network B 会分配不同的 VLAN ID，这样就保证了 network A 中的广播包不会跑到 network B 中。当然，这里的隔离是指二层上的隔离，借助路由器不同 network 是可能在三层上通信的。

network 必须属于某个 Project（ Tenant 租户），Project 中可以创建多个 network。 network 与 Project 之间是 1对多 关系。

（2）subnet

subnet 是一个 IPv4 或者 IPv6 地址段。instance 的 IP 从 subnet 中分配。每个 subnet 需要定义 IP 地址的范围和掩码。

network 与 subnet 是 1对多 关系。一个 subnet 只能属于某个 network；一个 network 可以有多个 subnet，这些 subnet 可以是不同的 IP 段，但不能重叠。下面的配置是有效的：

network A
subnet A-a: 10.10.1.0/24 {“start”: “10.10.1.1”, “end”: “10.10.1.50”}
subnet A-b: 10.10.2.0/24 {“start”: “10.10.2.1”, “end”: “10.10.2.50”}

但下面的配置则无效，因为 subnet 有重叠

network A
subnet A-a: 10.10.1.0/24 {“start”: “10.10.1.1”, “end”: “10.10.1.50”}
subnet A-b: 10.10.1.0/24 {“start”: “10.10.1.51”, “end”: “10.10.1.100”}

这里不是判断 IP 是否有重叠，而是 subnet 的 CIDR 重叠（都是 10.10.1.0/24）。但是，如果 subnet 在不同的 network 中，CIDR 和 IP 都是可以重叠的，比如

network A subnet A-a: 10.10.1.0/24 {“start”: “10.10.1.1”, “end”: “10.10.1.50”}
network B subnet B-a: 10.10.1.0/24 {“start”: “10.10.1.1”, “end”: “10.10.1.50”}

这里大家不免会疑惑： 如果上面的IP地址是可以重叠的，那么就可能存在具有相同 IP 的两个 instance，这样会不会冲突？ 简单的回答是：不会！

具体原因： 因为 Neutron 的 router 是通过 Linux network namespace 实现的。network namespace 是一种网络的隔离机制。通过它，每个 router 有自己独立的路由表。上面的配置有两种结果：

1. 如果两个 subnet 是通过同一个 router 路由，根据 router 的配置，只有指定的一个 subnet 可被路由。

2. 如果上面的两个 subnet 是通过不同 router 路由，因为 router 的路由表是独立的，所以两个 subnet 都可以被路由。

（3）port

port 可以看做虚拟交换机上的一个端口。port 上定义了 MAC 地址和 IP 地址，当 instance 的虚拟网卡 VIF（Virtual Interface） 绑定到 port 时，port 会将 MAC 和 IP 分配给 VIF。

subnet 与 port 是 1对多 关系。一个 port 必须属于某个 subnet；一个 subnet 可以有多个 port。

小结：
下面总结了 Project，Network，Subnet，Port 和 VIF 之间关系。
Project 1 : m Network 1 : m Subnet 1 : m Port 1 : 1 VIF m : 1 Instance

Neutron 功能

Neutron 为整个 OpenStack 环境提供网络支持，包括二层交换，三层路由，负载均衡，防火墙和 VPN 等。Neutron 提供了一个灵活的框架，通过配置，无论是开源还是商业软件都可以被用来实现这些功能。

二层交换 Switching

Nova 的 Instance 是通过虚拟交换机连接到虚拟二层网络的。Neutron 支持多种虚拟交换机，包括 Linux 原生的 Linux Bridge 和 Open vSwitch。 Open vSwitch（OVS）是一个开源的虚拟交换机，它支持标准的管理接口和协议。

利用 Linux Bridge 和 OVS，Neutron 除了可以创建传统的 VLAN 网络，还可以创建基于隧道技术的 Overlay 网络，比如 VxLAN 和 GRE（Linux Bridge 目前只支持 VxLAN）。在后面章节我们会学习如何使用和配置 Linux Bridge 和 Open vSwitch。

三层路由 Routing

Instance 可以配置不同网段的 IP，Neutron 的 router（虚拟路由器）实现 instance 跨网段通信。router 通过 IP forwarding，iptables 等技术来实现路由和 NAT。我们将在后面章节讨论如何在 Neutron 中配置 router 来实现 instance 之间，以及与外部网络的通信。

负载均衡 Load Balancing

Openstack 在 Grizzly 版本第一次引入了 Load-Balancing-as-a-Service（LBaaS），提供了将负载分发到多个 instance 的能力。LBaaS 支持多种负载均衡产品和方案，不同的实现以 Plugin 的形式集成到 Neutron，目前默认的 Plugin 是 HAProxy。我们会在后面章节学习 LBaaS 的使用和配置。

防火墙 Firewalling

Neutron 通过下面两种方式来保障 instance 和网络的安全性。

Security Group

通过 iptables 限制进出 instance 的网络包。

Firewall-as-a-Service

FWaaS，限制进出虚拟路由器的网络包，也是通过 iptables 实现。

Neutron 优点：
Openstack 中的 SDN 组件架构也属于可插拔类型。通过各种插件可以管控不同种类的交换机、路由器、防火墙、负载均衡器并实现 firewall as a service 等许多功能。通过软件来定义的网络，可以对整个云计算设施进行更为精细的掌控。

Neutron 部署方案

方案1：控制节点 + 计算节点：

控制节点：部署的服务包括：neutron server, core plugin 的 agent 和 service plugin 的 agent。

计算节点：部署 core plugin 的agent（ovs agent（控制节点也要部署）），负责提供二层网络功能。

这里有几点需要说明：

1. core plugin 和 service plugin 已经集成到 neutron server，不需要运行独立的 plugin 服务。
2. 控制节点和计算节点都需要部署 core plugin 的 agent，因为通过该 agent 控制节点与计算节点才能建立二层连接。
3. 可以部署多个控制节点和计算节点。
   

方案2：控制节点 + 网络节点 + 计算节点

在这个部署方案中，OpenStack 由控制节点，网络节点和计算节点组成。

控制节点：部署 neutron server 服务。

网络节点：部署的服务包括：core plugin 的 agent 和 service plugin 的 agent。

计算节点：部署 core plugin 的agent，负责提供二层网络功能。

这个方案的要点是将所有的 agent 从控制节点分离出来，部署到独立的网络节点上。
1，控制节点只负责通过 neutron server 响应 API 请求。

2，由独立的网络节点实现数据的交换，路由以及 load balance等高级网络服务。

3，可以通过增加网络节点承担更大的负载。

4，可以部署多个控制节点、网络节点和计算节点。

该方案特别适合规模较大的 OpenStack 环境。

配置多个网卡区分不同类型的网络数据

OpenStack 至少包含下面几类网络流量
Management
API
VM
External

Management 网络
用于节点之间 message queue 内部通信以及访问 database 服务，所有的节点都需要连接到 management 网络。

API 网络
OpenStack 各组件通过该网络向用户暴露 API 服务。Keystone, Nova, Neutron, Glance, Cinder, Horizon 的 endpoints 均配置在 API 网络上。通常，管理员也通过 API 网络 SSH 管理各个节点。

VM 网络
VM 网络也叫 tenant 网络，用于 instance 之间通信。
VM 网络可以选择的类型包括 local, flat, vlan, vxlan 和 gre。
VM 网络由 Neutron 配置和管理。

External 网络
External 网络指的是 VM 网络之外的网络，该网络不由 Neutron 管理。 Neutron 可以将 router attach 到 External 网络，为 instance 提供访问外部网络的能力。 External 网络可能是企业的 intranet，也可能是 internet。

这几类网络只是逻辑上的划分，物理实现上有非常大的自由度。

我们可以为每种网络分配单独的网卡；也可以多种网络共同使用一个网卡；为提高带宽和硬件冗余，可以使用 bonding 技术将多个物理网卡绑定成一个逻辑的网卡

neutron 架构

Nuetron 架构

与 OpenStack 的其他服务的设计思路一样，Neutron 也是采用分布式架构，由多个组件（子服务）共同对外提供网络服务。

Neutron 由如下组件构成：

Neutron Server
对外提供 OpenStack 网络 API，接收请求，并调用 Plugin 处理请求。

Plugin
处理 Neutron Server 发来的请求，维护 OpenStack 逻辑网络状态， 并调用 Agent 处理请求。

Agent
处理 Plugin 的请求，负责在 network provider 上真正实现各种网络功能。

network provider
提供网络服务的虚拟或物理网络设备，例如 Linux Bridge，Open vSwitch 或者其他支持 Neutron 的物理交换机。

Queue
Neutron Server，Plugin 和 Agent 之间通过 Messaging Queue 通信和调用。

Database
存放 OpenStack 的网络状态信息，包括 Network, Subnet, Port, Router 等。

Neutron 架构非常灵活，层次较多，目的是：

为了支持各种现有或者将来会出现的优秀网络技术。

支持分布式部署，获得足够的扩展性。

以创建一个 VLAN100 的 network 为例，假设 network provider 是 linux bridge， 流程如下：

Neutron Server 接收到创建 network 的请求，通过 Message Queue（RabbitMQ）通知已注册的 Linux Bridge Plugin。

Plugin 将要创建的 network 的信息（例如名称、VLAN ID等）保存到数据库中，并通过 Message Queue 通知运行在各节点上的 Agent。

Agent 收到消息后会在节点上的物理网卡（比如 eth2）上创建 VLAN 设备（比如 eth2.100），并创建 bridge （比如 brqXXX） 桥接 VLAN 设备。

plugin 解决的是 What 的问题，即网络要配置成什么样子？而至于如何配置 How 的工作则交由 agent 完成。

plugin，agent 和 network provider 是配套使用的，比如上例中 network provider 是 linux bridge，那么就得使用 linux bridge 的 plungin 和 agent；如果 network provider 换成了 OVS 或者物理交换机，plugin 和 agent 也得替换。

plugin 的一个主要的职责是在数据库中维护 Neutron 网络的状态信息，这就造成一个问题：所有 network provider 的 plugin 都要编写一套非常类似的数据库访问代码。为了解决这个问题，Neutron 在 Havana 版本实现了一个 ML2（Modular Layer 2）plugin，对 plgin 的功能进行抽象和封装。有了 ML2 plugin，各种 network provider 无需开发自己的 plugin，只需要针对 ML2 开发相应的 driver 就可以了，工作量和难度都大大减少。ML2 会在后面详细讨论。

plugin 按照功能分为两类： core plugin 和 service plugin。core plugin 维护 Neutron 的 netowrk, subnet 和 port 相关资源的信息，与 core plugin 对应的 agent 包括 linux bridge, OVS 等； service plugin 提供 routing, firewall, load balance 等服务，也有相应的 agent。后面也会分别详细讨论。

neutron server 组件详解：

Neutron server 分层模型

Core API：对外提供管理 network, subnet 和 port 的 RESTful API。

Extension API：对外提供管理 router, load balance, firewall 等资源 的 RESTful API。

Commnon Service：认证和校验 API 请求。

Neutron Core：Neutron server 的核心处理程序，通过调用相应的 Plugin 处理请求。

Core Plugin API：定义了 Core Plgin 的抽象功能集合，Neutron Core 通过该 API 调用相应的 Core Plgin。

Extension Plugin API：定义了 Service Plgin 的抽象功能集合，Neutron Core 通过该 API 调用相应的 Service Plgin。

Core Plugin：实现了 Core Plugin API，在数据库中维护 network, subnet 和 port 的状态，并负责调用相应的 agent 在 network provider 上执行相关操作，比如创建 network。

Service Plugin：实现了 Extension Plugin API，在数据库中维护 router, load balance, security group 等资源的状态，并负责调用相应的 agent 在 network provider 上执行相关操作，比如创建 router。

归纳起来，Neutron Server 包括两部分：

1. 提供 API 服务。
2. 运行 Plugin。

即 Neutron Server = API + Plugins

ML2 Core Plugin 详解

Neutron 是如何支持多种 network provider？

openstack中有两大常见 Core Plugin： linux bridge plugin 和 open vswitch plugin。
Neutron 可以通过开发不同的 plugin 和 agent 支持不同的网络技术。这是一种相当开放的架构。不过随着支持的 network provider 数量的增加，开发人员发现了两个突出的问题：

1. 只能在 OpenStack 中使用一种 core plugin，多种 network provider 无法共存。
   只使用一个 core plugin 本身没有问题。但问题在于传统的 core plugin 与 core plugin agent 是一一对应的。也就是说，如果选择了 linux bridge plugin，那么 linux bridge agent 将是唯一选择，就必须在 OpenStack 的所有节点上使用 linux bridge 作为虚拟交换机（即 network provider）。

2. 不同 plugin 之间存在大量重复代码，开发新的 plugin 工作量大。
   所有传统的 core plugin 都需要编写大量重复和类似的数据库访问的代码，大大增加了 plugin 开发和维护的工作量。

ML2 能解决传统 core plugin 的问题

Moduler Layer 2（ML2）：是 Neutron 在 Havana 版本实现的一个新的 core plugin，用于替代原有的 linux bridge plugin 和 open vswitch plugin。 作为新一代的 core plugin，提供了一个框架，允许在 OpenStack 网络中同时使用多种 Layer 2 网络技术，不同的节点可以使用不同的网络实现机制。

ML2 对二层网络进行抽象和建模，引入了 type driver 和 mechansim driver。这两类 driver 解耦了 Neutron 所支持的网络类型（type）与访问这些网络类型的机制（mechanism），其结果就是使得 ML2 具有非常好的弹性，易于扩展，能够灵活支持多种 type 和 mechanism。

（1） Type Driver
Neutron 支持的每一种网络类型都有一个对应的 ML2 type driver。
type driver 负责维护网络类型的状态，执行验证，创建网络等。 ML2 支持的网络类型包括 local, flat, vlan, vxlan 和 gre。 我们将在后面章节详细讨论每种 type。

（2） Mechansim Driver
Neutron 支持的每一种网络机制都有一个对应的 ML2 mechansim driver。
mechanism driver 负责获取由 type driver 维护的网络状态，并确保在相应的网络设备（物理或虚拟）上正确实现这些状态。

mechanism driver 有三种类型：

Agent-based
包括 linux bridge, open vswitch 等。

Controller-based
包括 OpenDaylight, VMWare NSX 等。

基于物理交换机
包括 Cisco Nexus, Arista, Mellanox 等。 比如前面那个例子如果换成 Cisco 的 mechanism driver，则会在 Cisco 物理交换机的指定 trunk 端口上添加 vlan100。

Service Plugin / Agent 详解

Core Plugin/Agent 负责管理核心实体：net, subnet 和 port。而对于更高级的网络服务，则由 Service Plugin/Agent 管理。

Service Plugin 及其 Agent 提供更丰富的扩展功能，包括路由，load balance，firewall等。

DHCP
dhcp agent 通过 dnsmasq 为 instance 提供 dhcp 服务。

Routing
l3 agent 可以为 project（租户）创建 router，提供 Neutron subnet 之间的路由服务。路由功能默认通过 IPtables 实现。

Firewall
l3 agent 可以在 router 上配置防火墙策略，提供网络安全防护。另一个与安全相关的功能是 Security Group，也是通过 IPtables 实现。 Firewall 与 Security Group 的区别在于：

1，Firewall 安全策略位于 router，保护的是某个 project 的所有 network。
2，Security Group 安全策略位于 instance，保护的是单个 instance。

Load Balance
Neutron 默认通过 HAProxy 为 project 中的多个 instance 提供 load balance 服务。

Neutron 架构框架总结

与 OpenStack 其他服务一样，Neutron 采用的是分布式架构，包括 Neutorn Server、各种 plugin/agent、database 和 message queue。

1. Neutron server 接收 api 请求。
2. plugin/agent 实现请求。
3. database 保存 neutron 网络状态。
4. message queue 实现组件之间通信。

metadata-agent 之前没有讲到，这里做个补充：

instance 在启动时需要访问 nova-metadata-api 服务获取 metadata 和 userdata，这些 data 是该 instance 的定制化信息，比如 hostname, ip， public key 等。
但 instance 启动时并没有 ip，那如何通过网络访问到 nova-metadata-api 服务呢？

答案就是 neutron-metadata-agent 该 agent 让 instance 能够通过 dhcp-agent 或者 l3-agent 与 nova-metadata-api 通信

将 Neutron 架构展开

1，Neutron 通过 plugin 和 agent 提供的网络服务。
2，plugin 位于 Neutron server，包括 core plugin 和 service plugin。
3，agent 位于各个节点，负责实现网络服务。
4，core plugin 提供 L2 功能，ML2 是推荐的 plugin。
5，使用最广泛的 L2 agent 是 linux bridage 和 open vswitch。
6，service plugin 和 agent 提供扩展功能，包括 dhcp, routing, load balance, firewall, vpn 等

虚拟机获取 ip

用 namspace 隔离 DHCP 服务

Neutron 通过 dnsmasq 提供 DHCP 服务，而 dnsmasq 通过 Linux Network Namespace 独立的为每个 network 服务隔离
在二层网络上，VLAN 可以将一个物理交换机分割成几个独立的虚拟交换机。类似地，在三层网络上，Linux network namespace 可以将一个物理三层网络分割成几个独立的虚拟三层网络。

每个 namespace 都有自己独立的网络栈，包括 route table，firewall rule，network interface device 等。

Neutron 通过 namespace 为每个 network 提供独立的 DHCP 和路由服务，从而允许租户创建重叠的网络。如果
没有 namespace，网络就不能重叠，这样就失去了很多灵活性。

每个 dnsmasq 进程都位于独立的 namespace, 命名为 qdhcp-

查看命名空间
#ip netns list

查看详细信息
#ip netns exec namespace ip a

root namespace：
其实，宿主机本身也有一个 namespace，叫 root namespace，拥有所有物理和虚拟 interface device。物理 interface 只能位于 root namespace。
新创建的 namespace 默认只有一个 loopback device。管理员可以将虚拟 interface，例如 bridge，tap 等设备添加到某个 namespace。

对于 flat_net 的 DHCP 设备 tap19a0ed3d-fe，需要将其放到 namespace qdhcp-7bf09be4-8653-4869-84f0-33494f238627 中，但这样会带来一个问题：tap19a0ed3d-fe 将无法直接与 root namespace 中的 bridge 设备 brqf153b42f-c3 连接。
Neutron 使用 veth pair 解决了这个问题。
veth pair 是一种成对出现的特殊网络设备，它们象一根虚拟的网线，可用于连接两个 namespace。向 veth pair 一端输入数据，在另一端就能读到此数据。
tap19a0ed3d-fe 与 ns-19a0ed3d-fe 就是一对 veth pair，它们将 qdhcp-f153b42f-c3a1-4b6c-8865-c09b5b2aa274 连接到 brqf153b42f-c3。

获取 dhcp IP 过程分析

在创建 instance 时，Neutron 会为其分配一个 port，里面包含了 MAC 和 IP 地址信息。这些信息会同步更新到 dnsmasq 的 host 文件。

同时 nova-compute 会设置虚机 VIF 的 MAC 地址。

instance 获取 IP 的过程如下：

1. vm 开机启动，发出 DHCPDISCOVER 广播，该广播消息在整个 net 中都可以被收到。

2. 广播到达 veth tap19a0ed3d-fe（dhcp端口），然后传送给 veth pair 的另一端 ns-19a0ed3d-fe。dnsmasq 在它上面监听，dnsmasq 检查其 host 文件，发现有对应项，于是dnsmasq 以 DHCPOFFER 消息将 IP、子网掩码、地址租用期限等信息发送给 vm。

3. vm 发送 DHCPREQUEST 消息确认接受此 DHCPOFFER。

4. dnsmasq 发送确认消息 DHCPACK，整个过程结束。

VXLAN简介

overlay network概念

overlay network 是指建立在其他网络上的网络。overlay network 中的节点可以看作通过虚拟（或逻辑）链路连接起来的。overlay network 在底层可能由若干物理链路组成，但对于节点，不需要关心这些底层实现。

例如 P2P 网络就是 overlay network，隧道也是。vxlan 和 gre 都是基于隧道技术实现的，它们也都是 overlay network。

VXLAN简介

VXLAN 为 Virtual eXtensible Local Area Network。正如名字所描述的，VXLAN 提供与 VLAN 相同的以太网二层服务，但拥有更强的扩展性和灵活性。与 VLAN 相比，
VXLAN 有下面几个优势：

1. 支持更多的二层网段。
   VLAN 使用 12-bit 标记 VLAN ID，最多支持 4094 个 VLAN，这对大型云部署会成为瓶颈。VXLAN 的 ID （VNI 或者 VNID）则用 24-bit 标记，支持 16777216 个二层网段。
2. 能更好地利用已有的网络路径。
   VLAN 使用 Spanning Tree Protocol 避免环路，这会导致有一半的网络路径被 block 掉。VXLAN 的数据包是封装到 UDP 通过三层传输和转发的，可以使用所有的路径。
3. 避免物理交换机 MAC 表耗尽。
   由于采用隧道机制，TOR (Top on Rack) 交换机无需在 MAC 表中记录虚拟机的信息。

VXLAN 封装和包格式：
VXLAN 是将二层建立在三层上的网络。通过将二层数据封装到 UDP 的方式来扩展数据中心的二层网段数量。
VXLAN 是一种在现有物理网络设施中支持大规模多租户网络环境的解决方案。VXLAN 的传输协议是 IP + UDP。
VXLAN 定义了一个 MAC-in-UDP 的封装格式。在原始的 Layer 2 网络包前加上 VXLAN header，然后放到 UDP 和 IP 包中。通过 MAC-in-UDP 封装，VXLAN 能够在 Layer 3 网络上建立起了一条 Layer 2 的隧道。

Open vSwitch：

Open vSwitch 中的网络设备：
br-ex：连接外部（external）网络的网桥。
br-int：集成（integration）网桥，所有 instance 的虚拟网卡和其他虚拟网络设备都将连接到该网桥。
br-tun：隧道（tunnel）网桥，基于隧道技术的 VxLAN 和 GRE 网络将使用该网桥进行通信。
tap interface：命名为 tapXXXX。
linux bridge：命名为 qbrXXXX。
veth pair：命名为 qvbXXXX, qvoXXXX
OVS integration bridge：命名为 br-int。
OVS patch ports：命名为 int-br-ethX 和 phy-br-ethX（X 为 interface 的序号）。
OVS provider bridge：命名为 br-ethX（X 为 interface 的序号）。
物理 interface：命名为 ethX（X 为 interface 的序号）。
OVS tunnel bridge：命名为 br-tun。

三层网络介绍

虚拟机访问外网

（1）虚拟机中访问一个外网地址，并用 traceroute 命令跟踪路由查看
（2）根据网络拓扑，由于虚机访问外网要经过本网段的网关，然后经过路由的外网接口转发出去，到达目标ip
（3）查看路由命名空间的网络配置，查到路由连接外网的端口和ip

（4）查看路由iptables NAT 转发规则，记录对私网做的SNAT

（5）验证：
在虚机 ping外网 时， 可以通过 tcpdump 分别观察 router 两个 interface 的 icmp 数据包来验证 SNAT 的行为：

#ip netns exec qrouter-176bd7e0-6427-46a5-906a-be6a373a29a1 tcpdump -i qg-8df29d32-d6 -n icmp

外网访问虚机——floating ip原理

SNAT 让 instance 能够直接访问外网，但外网还不能直接访问 instance。因为 instance 没有外网 IP。这里 “直接访问 instance” 是指通信连接由外网发起，例如从外网 SSH 实例。

（1）首先将实例绑定浮动 ip， floating IP 是配置在 router 的外网 interface 上的，再查看 router 的 interface 配置
（2）在实例中ping外网地址，在路由的qr-7b56f58b-b5 接口上，实例访问外网ip，外网ip将数据包转发回实例ip；但在路由的qg-8df29d32-d6 接口上，始终是通过 floating IP 与外网通信。
（3） 原因是在路由中iptables做了DNA T（基于目的地址转发），查看 router 的 NAT 规则

当 router 接收到从外网发来的包，如果目的地址是 floating IP ，将目的地址修改为实例的 IP 。这样外网的包就能送达到实例；
当实例发送数据到外网，源地址 将被修改为 floating IP 。