微店全三层网络接入方案

点 击 关 注   “ 微 店 技 术 团 队 ” ， 阅 读 更 多 技 术 干 货

背景

传统网络架构中，在服务器接入这一层通常会将网关放在交换机一侧，随着时代的发展，网关下移、接入核心之间三层互联越来越成为主流，本文就来与大家探讨下现有网络架构中，服务器接入网络的发展历程，以及在微店未来数据中心网络架构中实现的一种纯三层的服务器接入方案。本文只探讨 Underlay 这个层面。

术语介绍

先列举一下常见术语

服务器接入网络的方案的演进

大二层的兴起

曾经一段时间大二层的概念很火，各家厂商都推出了集中管控的网络设备，比如经典的 Cisco Nexus 752 系列，在运维管理上，确实简化了不少，随着规模的扩大，慢慢大二层的弊端也凸显出来。大二层很适合做虚拟化的场景，因为最开始虚拟化技术面世的时候，还没有 overlay 的概念，所有虚拟机依靠网络硬件连接在一起，网络架构的设计规划会影响到一个虚拟化平台的规模和扩展性，传统大二层网络配合新的网络设备集中管理技术无疑是一剂良药，解决了虚拟机热迁移 IP 地址的漂移问题（可以实现 IP 地址不变），让网工可以轻轻松松管理一个超大规模的二层网络。

随着时间的发展，数据中心规模的不断增加，数据中心网络里的一些问题开始越来越被人重视。

第一个是规模，目前互联网单个数据中心的规模越来越大，远远不是之前的几千台服务器的规模可比，现在的新建数据中心，突破 10W 台服务器的新闻报道会越来越多。这么大的数据中心，如果坚持使用大二层的网络，会形成一个巨大的广播域。

第二个是密度，随着服务器 CPU 核心的提升、容器的盛行，单台物理机的密度逐年提高，一台服务器上可以跑 100 ~ 200 个甚至更多个 Docker，随着运维技术对硬件性能的压榨，私网 IP 的密度（单位物理服务器消耗的 IP 个数）也会成倍的提升，这就带来一个广播流量持续提升的局面。以前数据中心规模小的时候，偶尔出一次故障，还可以接受，技术的演进就是要解决更多的已知的常见问题，未来对网络出现大规模故障的容忍程度也会越来越低，所有人追求的都是无故障。广播风暴、STP 抖动、环路（比如服务器错误的桥接多个网口）等大二层技术中出现的技术隐患越来越被重视，未来运维体系中绝不会允许再出现这样大风险的网络架构设计。

第三是对厂商的依赖问题，比如思科的 Nexus 752 产品固然好，但是价格也放贵，一个数据中心如果初期使用了 Nexus 752，后续扩展的话一定要继续购买 2K 系列的交换机，一个数据中心必须统一用一个厂商的设备。另外在运维中，集中控制的网络设备还涉及到一些版本升级等割接问题，如果有架构能实现不同厂商交换机混布，相信公司采购的话语权一定会更重，能更好的控制成本、用技术解决硬件兼容的问题。

第四是网络运维技术的发展，网工会写代码、写脚本以后会是招聘的一个硬性要求，还有 ZTP 零配置部署技术的发展、SDN 的发展、BGP 协议在数据中心内的使用，如何管理上千台独立的交换机，以前很麻烦，要靠招人来解决运维管理更大的网络，当下以及未来会运用更多的自动化技术去统一管理网络，所以从管理角度，我们也不再需要集中管理的设备出现，FEX 这类功能注定会成为一个历史。网工的命运是要握在自己手里。

三层网络架构的兴起

三层网络架构的兴起有一个成熟的技术前置条件，那就是 Overlay 技术的兴起，随着 Overlay 发展，vxlan、gre 等封装技术的兴起让虚拟机的迁移不再依赖于物理机的网络环境，但是 Overlay 不是本文的重点，故不深究。Underlay 和 Overlay 的界限逐渐清晰，Underlay 负责大带宽、大规模网络通信；Overlay 通过 SDN 等技术负责实现 VPC，配合 K8S 和 Openstack 等主流资源管理平台。在此条件下，Underlay 肩负起了消除在大二层时代的一些隐患的重任。让我们看看网络三层架构有哪些好处。

1. 减小广播域，广播风暴、环路不再影响整个数据中心，而只影响个别机柜

2. 减少对厂商技术的依赖，一个数据中心不再需要全部品牌统一，在扩展机柜时往往只需要保证服务器相同两台接入交换机型号相同就可以实现双上联，例如 mode 4 bonding，接入交换机通过堆叠或者 M-LAG 或者 VPC（Cisco） 技术实现。

3. 割接过程中的灵活处理，以往大二层割接过程比较痛苦，要理清楚各种厂商特有协议的防环机制，要弄明白 STP 的状态，还要确保二层流量能成功引导到新的网关上，采用三层后只需要关注路由走向就可以灵活处理割接工作。

4. 不再需要价格高昂的框式设备的核心交换机，通过 ECMP 和 CLOS 技术可以实现大量盒式设备通过 2 Tier or 3 Tier 方式组建数据中心核心网络，在线扩展性一流，设备故障对业务的影响几乎消除，免去大量维保费用通过多采购设备自己做备件。

最适合的才是最好的

三层网络有很多好处，接下来我们就要针对公司的需求做进一步分析。

对于微店来说，微店目前的 Overlay 需求不是那么强烈，反而对内网的延迟比较敏感，如何在能拥有三层架构所有好处的同时，还能得到一个最佳的网络性能，因此我们决定不用 Overlay，如何在没有封装的情况下实现跨三层的 IP 地址漂移，这是一个重点。

其次我们来列下其他需求：

1. 虽然对整个数据中心网络设备品牌要求没那么高了，但是要求同一台服务器相连的两台接入交换机为同一个型号，能否做到不同厂商的接入交换机？

2. 全网三层推广后，核心交换机的割接工作影响小了，但是接入交换机的在线替换依然不可能，因为涉及到 bonding，涉及到堆叠等技术，很难做到 24 小时无缝在线无风险替换接入交换机（很伟大的理想）。

3. 二层广播域虽然被隔离为小块了，但是依然出现过一个机柜内发生 ip redirect 的问题，导致一个机柜的网络出故障，我们想做到彻底隔离广播域。

4. 我们也有虚拟化技术，虚拟化技术中也包含 KVM 的迁移技术，如果保证 VM 迁移后 IP 地址不变继续可用是一个很大的问题，同样，我们的迁移也有一定的限制，只能在单个集群内迁移，你可以理解一个或两个机柜为一个集群，也就是一个集群的密度在 40 台物理机左右，我们能做到单元化管理，同样也是出于从系统层面隔离故障域的角度。另外我们的规划是全网虚拟化，不交付物理机，这也是一个条件。

5. 还有一个我们内在的需求，就是方案尽量简单

答案似乎只有一个

带着这些需求我们在设计中发现，只要将宿主机（物理机）运行路由协议，废弃 bonding，采用 ecmp 做上联就可以满足 1 2 3 点需求，除了第四点 IP 地址漂移不好解决。但是如果我们不计较第四点需求，分配给每一台宿主机一个独立子网，允许 KVM 挂了就挂了，利用诸如 K8S 的技术去保证业务存活，倒也简单了。如果这样考虑就是我们的 三层到接入服务器 方案。这个方案还有一个大的问题就是对 IP 地址浪费比较严重，每个宿主机子网都会利用不全。

所以接下来的问题就简单了，变成“如何在两台同样运行三层路由协议的宿主机上实现同网段同网关的 KVM 之间通信？”

我们先假定实现了上述功能，顺便把之前提到的内容总结下做个对比。

常规服务器接入方式对比

分析

接下来我们重点讨论下如何在两台同样运行三层路由协议的宿主机上实现同网段同网关的 KVM 之间通信？

首先不同 KVM 的既然在相同网段中，网关肯定相同，就意味着不同宿主机上都要有相同的网关。

接下来就是同宿主机的不同 KVM 通信，这一点肯定没有问题，因为在同一个网桥 bridge 里，二层是可以直接通的。

关键就是如何让不同宿主机的同网段 KVM 通信，我们分析一下目前的环节哪里导致了数据包不通。

答案是 ARP 环节，既然目标在同一个网段，本机操作系统会发送 ARP 请求去广播寻找同网段的目标 IP，而这个时候，由于我们的宿主机都是三层上联，广播包不可能会被转发到目标 VM 所在的宿主机上，自然没有人回应 ARP。

第一个关键点

有没有可以让网关假装回应并将二层流量转换成三层流量转发的功能呢？

有，ARP 代理功能即可实现。

ARP 代理是很常见的一个网络功能，在网络设备、操作系统中非常常见，但是在目前的网络中由于网段的合理规划，通常是不需要开启 ARP 代理功能的，绝大多数场景下我们都选择关闭 ARP 代理、关闭 IP 重定向等功能，但是在我们这次的需求中，ARP 代理这个功能非常关键。

ARP 代理可以回应 ARP 请求，欺骗客户端，让客户端误以为目标 IP 已经找到， ARP 代理回应这个 ARP 请求，并将自己的接口 IP 告诉客户端，我就是你要找的人。  我们看下 sysctl 怎么说 proxy_arp 功能，proxy_arp 只需要在接口上打开设置为 1 即可，同时会去检测一下接口相关的 medium_id 值，不过这个值所有接口都默认为 0，也就是不影响 proxy_arp 的执行结果。如果手工设置的话需要让不同三层接口属于不同的 medium_id，否则 proxy_arp 不会转发。

medium_id - INTEGER
    Integer value used to differentiate the devices by the medium they
    are attached to. Two devices can have different id values when
    the broadcast packets are received only on one of them.
    The default value 0 means that the device is the only interface
    to its medium, value of -1 means that medium is not known.

    Currently, it is used to change the proxy_arp behavior:
    the proxy_arp feature is enabled for packets forwarded between
    two devices attached to different media.

proxy_arp - BOOLEAN
    Do proxy arp.
    proxy_arp for the interface will be enabled if at least one of
    conf/{all,interface}/proxy_arp is set to TRUE,
    it will be disabled otherwise

在我们网关处开启 ARP 代理功能后，网关会回应客户端的 ARP 请求，在客户端看来，目标 IP 的 MAC 地址就是网关的 MAC 地址，接下来客户端会将 IP 报文发给宿主机上的网关，网关在收到数据包后，要做的事情就是查路由表，找到正确的方向。

第二个关键点

所以这里是第二个关键点，如何让处于同网段但是分属于不同宿主机的虚拟机之间流量精确导向。

这里我们依靠的是精确的主机路由，也就是 32 位主机路由。我们通过将 /32 主机路由宣告或者是重分布进网络中就可以实现精确导向。确保每台宿主机上都有着 MDU 内所有 VM 的主机路由，或者再优化一点，只要确保接入交换机上有着所有 MDU 内的主机路由，宿主机上均为缺省路由即可满足需求。这里要注意下我们前面提到的需求，我们的需求是能实现一个 MDU 内的虚拟机漂移即可，不需要整个机房漂移，所以每个 MDU 内可以控制在几千个主机路由的规模，接入交换机上联的话通过 BGP 宣告一条汇总的路由，核心和骨干网网络规模的路由条目还是很精简的。

其他注意事项

我们现在已经实现了“如何在两台同样运行三层路由协议的宿主机上实现同网段同网关的 KVM 之间通信？”

但是之前提到的 IP 地址漂移的需求，要能满足 KVM 在一个宿主机上起来，网络自然就通了。在一台宿主机上关闭，在另外一台宿主机上起来，也是随时可用的状态，这就要求 32 位主机路由可以跟随 KVM 一起自动的配置，恰好 qemu-kvm 启动和关闭时可以指定 script，在宿主机上对一台 KVM 开机或者关机操作时，会执行固定的脚本，但是脚本传入的参数 $1 是网卡名称，例如  vnet0 ，如何根据宿主机上的 vnet0 获取到 KVM 里的真实 IP 地址？

好在我们前期规划的好，所有的 MAC 地址都是根据 KVM 的 IP 地址生成的，也就是说 48bit MAC 地址，其中后 32bit 是 IP 地址，所以我们只要准备个脚本能把 MAC 地址后四段（共六段）转化为 IP 地址，最后生成 ip route add/del 的命令即可。

接下来是整体设计和配置方案。

设计方案

由几个部分组成：宿主机网络接入部分，VM 网络接入部分，宿主机参数调整

原理图

核心思想

满足网络通不通的条件只需要看：数据包是否可以出去；数据包是否可以回来。 通常情况下，网络设计是需要满足一个广播域一个子网、一个网关的原则，否则 ARP 二层广播出去后会得不到回应，进而也无法进行二层同网段之间的通信。

我们通过 ARP PROXY 的方式让广播域隔离的 VM 发出来的 ARP 请求报文得到回应，这样的话 KVM 会将访问同网段的其他 IP 的流量交给网关，再通过 32 位主机路由精确引导流量访问目标主机，实现跨三层（广播域）的同网段流量互通。 该方式没有任何 overlay 的封装开销，配置简单，思路清晰。

宿主机上的网口类型规划

宿主机网络接入

• 接入交换机承担与宿主机三层对接，接入交换机每个与服务器互联的端口均配置 /30 的 IP 地址，每条链路均为 /30 互联。

• 宿主机上直接运行 FRR，开启 OSPF 协议，与接入交换机建立 OSPF 连接

• 宿主机上通过 Lo0 添加 /32 IP 用于宿主机管理

• 开启 BFD 协议，确保服务器线路故障 200ms 自动切换

FRR 配置举例：

bfd
 peer 10.47.175.9 local-address 10.47.175.10  # 50ms 心跳，四次失败，可以让链路故障 200ms 后切换
  detect-multiplier 4
  receive-interval 50
  transmit-interval 50
  no shutdown

interface eth0
 ip ospf bfd

router ospf
 redistribute kernel  ## 重分布宿主机里 kernal 产生的路由（比如 ip route add 添加的）
 ospf router-id 10.47.176.132  # 指定 Router-ID，与 lo0 IP 相同
 network 10.47.175.10/32 area 0.0.0.0  # eth0 接口地址
 network 10.47.175.14/32 area 0.0.0.0  # eth1 接口地址
 network 10.47.176.132/32 area 0.0.0.0  # Loopback 接口地址

接入交换机配置：

interface Ethernet1/4
  bfd interval 50 min_rx 50 multiplier 4
  no bfd echo  # 关闭 echo 模式，采用 asynchronous 模式

router ospf 1
  bfd
  router-id 172.20.225.254
  passive-interface default

interface Ethernet1/4  # 与服务器 eth0 互联接口
  no ip ospf passive-interface
  ip router ospf 1 area 0.0.0.0

KVM 启动自动加载静态路由

/etc/qemu-ifup 系统会传入每个 KVM 在宿主机上生成的对应网卡名称，例如 vnet0

#!/bin/sh

bridge=br-l2

mac=(`awk -F":" '{print $3,$4,$5,$6}' /sys/class/net/$1/address`)

for i in ${mac[*]}
do
    x=`expr $x + 1`
    ip_part[$x]=$(( 16#$i ))
done

ip=${ip_part[1]}.${ip_part[2]}.${ip_part[3]}.${ip_part[4]}

ip route add $ip/32 dev $bridge

VM 网络接入

• 每个分配的 VM 子网通过创建 bridge 实现

• 每个 bridge 需要配置 IP 地址用于 VM 的网关，MAC 地址无要求

• VM 通过 xml 配置随机启动时自动加入 bridge

bridge 配置

brctl addbr br-l2
ip addr add dev br-l2 10.0.0.1/24
ip link set dev br-l2 up

KVM 配置

<interface type='bridge'>
      <mac address='02:42:c1:25:0f:ba'/>
      <source bridge='br-l2'/>
      <model type='virtio'/>
      <driver name='vhost' queues='2'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
</interface>

宿主机参数调整

kernel 内核要求

需要满足 ECMP L4 HASH 要求，选择 4.10 以上版本

内核参数调节

• 全局需要开启路由转发，接口也要注意需要开启

• proxy_arp 功能只需要在 bridge 上开启

• proxy_arp 等待时间默认过长，会导致首包互通较慢，修改为 10ms 后改善很大

net.ipv4.conf.all.forwarding = 1  # 开启路由转发
net.ipv4.conf.br-l2.proxy_arp = 1  # 默认 0，未开启代理
net.ipv4.neigh.br-l2.proxy_delay = 1  # 默认 80，800ms 等待时间，修改为 10ms

网络变更注意事项

这里列举一下不同情形的变更方案

设备重启、换线、升级

这一类的变更都是针对链路或者设备做变更，通常需要流量切走，切走后即可安全变更，由于是全网三层架构，流量切走的方案也极其简单，OSPF/BGP 邻居 shutdown，操作之前确保服务器双上联都健康。流量切走后就可以为所欲为地对设备进行操作。 风险：极低

设备替换为其他型号

最好在测试环境演练过，确保配置能够生效，OSPF/BGP 邻居建起来就没有任何问题，过程大概同上，流量切走后可以做任意插拔线动作。

IP 同机房跨机柜在线迁移

这里稍微复杂一点，但是我们能提供这样的能力，背景往往是一个机柜退租，服务器要迁往别的机柜。

主要思路还是依靠 32 位主机路由，在目标 MDU 内部署好接入交换机和服务器，宿主机上的网关不变，互联地址什么都要保持唯一性，唯一可以重复的就是逻辑网关，也就是 br-l2 的 IP 地址，此外由于产生了跨核心的 IP 迁移，所以 32 位主机路由需要在整个机房内传递，待整个机柜服务器迁移完毕后，将原始机柜的网络断开，在目标机柜宣告 VM 汇总网段。

整机房在线迁移

背景往往是一个 IDC 要撤出，思路跟上面相似，都是通过主机路由，但是汇总路由要注意一下是否包含，以我们自己的 IDC 举例，一个 IDC 会划分出一个大的网段，不同的 MDU 会占用不同的网段，这样做的好处是核心骨干网上路由条目数会非常的精简，便于维护。在这种情形下要挨个将一个机房的不同机柜均迁走是一个大工程，迁移的过程中要注意汇总路由的宣告问题，MDU 的汇总路由要透传所有 IDC，等整个机房千万再进行合并汇总，总体来说也是可以做到的，但是比不过 Overlay 方式的 VM 迁移自动化程度高。