ADDC方案
ADDC概述
ADNET(Application-Driven Network,应用驱动网络)是H3C公司推出的统一网络解决方案,在传统网络基础上,融合了SDN、NFV、AI 等新技术,发展成一个开放、弹 性、灵活的体系,具有丰富的南北向接口,支持第三方应用开发,与用户业务深度契合。通过软件定义进一步释放网络的潜在价值,构建一个完善和谐的新IT生态系统。 现主要分为三大应用场景,分别是数据中心网(DC)、园区网(Campus)和广域网(WAN),本篇笔记主要涉及ADDC方案(6.0及以后的版本)。 ADDC解决方案,是通过引入SDN技术,基于Overlay、 VxLAN技术,实现了逻辑网络和物理网络的解耦,通过统一的控制器来集中管理网络基础架构。
在ADDC1.0和2.0版本中,使用的是强控方案,即基于Openflow作为vxlan控制层面的组网,控制器通过openflow下发的流表指导设备进行流量的转发;在ADDC3.0以后的版本中,方案改进为基于标准MP-BGP EVPN作为VxLAN控制面的弱控组网,控制器通过NETCONF协议,以XML形式给网络设备下发配置(包括AC口、VSI-interface等),设备根据evpn路由或l2vpn mac表进行流量转发,设备与控制器建立的openflow连接,主要涉及一些协议报文的处理流表(如上送控制器、转发给其他网络设备或交给设备自身CPU处理)。在混合overlay组网中,控制器还使用Ovsdb协议主要负责对SDN虚拟交换机设备下发配置以及转发和策略相关表项。
方案部署基本流程
1.安装部署统一数字底盘
统一数字底盘基于 Matrix 安装,支持一个 Master 节点的单机部署模式和三个 Master 节点+N 个 Worker 节点(N≥0)的集群部署模式,集群部署模式下支持 Worker 节点扩容。支持单机部署向集群模式的平滑扩容。单机部署模式和集群部署模式均支持物理服务器部署或虚拟机部署(实际应用场景中,一般都是物理服务器部署)
- Matrix:基于 Kubernetes,实现了对 Docker 容器的编排调度。主要用于 Kubernetes 集群的搭建,微服务的部署,以及系统、Docker 容器、微服务等的运维监控。
- Kubernetes:简称 K8s,是一个开源的容器编排引擎,用于对容器化应用进行自动化部署、 扩缩和管理。
- Master 节点:集群主节点。一个集群必须包含 3 个 Master 节点(单机模式下仅需一个 Master 节点),集群将从 3 个 Master 节点中自动选举出一台作为主用 Master 节点,其它 Master 节 点为备用 Master 节点。当集群的主用 Master 节点故障时,将在备用 Master 节点中重新选出新的主用 Master 节点,接管原主用 Master 节点的业务,避免业务中断。主用 Master 和备用 Master 的作用如下:
- 主用 Master 节点:负责管理和监控集群中的所有节点,北向业务虚 IP 会下发至主用 Master 节点上,所有 Master 节点共同承担业务的运行。
- 备用 Master 节点:仅承担业务的运行,不负责管理和监控其它节点。
- Worker 节点:集群业务节点。Worker 节点仅承担业务,不参与主用 Master 节点的选举。Worker 节点为可选节点,当 Master 上的业务已经达到资源和性能瓶颈,如 CPU 和内存使用率居高不下,业务响应慢,节点上 Pod 个数达到或接近 300 个限制等,可通过增加 Worker 节点提 升集群的性能和业务处理能力.
1.1准备工作
规划好数字底盘的ip地址:
如果是单机部署,则仅需要规划一个master节点ip即可;此外,如果使用双栈地址,则需要在下表地址规划中加上ipv6地址。

准备好数字底盘应用包 标准模式下,必选的安装包为 common_PLAT_GlusterFS_2.0_.zip、general_PLAT_portal_2.0_.zip和general_PLAT_kernel_2.0_.zip 精选模式下,必选的安装包多了kernel-base和network。
本文涉及的是DC场景,DC的必选安装包在标准模式下,还需多安装general_PLAT_kernel-base_2.0 、general_PLAT_oneclickcheck_2.0、general_PLAT_Dashboard_2.0和general_PLAT_widget_2.0安装包。
其他的应用包功能以及安装依赖详细信息见官网的 指导手册
服务器配置要求 硬件要求具体看 硬件配置指导手册 软件要求主要涉及服务器的操作系统,如果使用H3Linux镜像文件,其中已经集成了操作系统、Matrix 等应用软件包。在完成 H3Linux 操作系统的安装后,将自动安装需要的依赖包及 Matrix。因此用户无需手动安装依赖包及 Matrix。如果是非H3C操作系统,需要先部署操作系统及依赖包,再部署 Matrix。
1.2安装操作系统
以H3Linux为例,安装流程与普通Linux系统(CentOS6/7)类似,重点需要注意磁盘分区:
H3C每台节点服务器都需要为 GlusterFS (GFS)应用预留一块空磁盘、空闲空间或分区(只支持标准分区,不支持lvm分区),标准模式下容量至少 200 GB,精简模式下容量至少 180GB(精简模式当前仅支持 x86),且该磁盘不能被格式化,否则会安装失败。若已被格式化,则可用“wipefs -a /dev/磁盘名称”命令清空磁盘来进行修复
如果服务器的磁盘空间满足统一数字底盘的最低部署要求,且第一块逻辑盘作为系统盘时,将会自动对磁盘进行分区,如果根分区所在磁盘可用空间大于等于1.5T,则会自动为GFS创建一个分区,该分区大小为:根分区大小-1.23T。如果根分区磁盘大小较大,会导致GFS所在分区大小较大,因此可以在自动分区基础上再进行分区操作。
尽管“var/lib/etcd”分区允许非独立磁盘部署,但仍推荐etcd的磁盘与安装了系统和其他组件的磁盘分别对应独立的物理硬盘。
此外,还需要注意操作系统的时间同步问题,需要选择上海时间,该时间在matrix集群创建好后不能随意修改,否则会对应用组件的运行造成较大影响,从而影响业务。
最后是网络设置,主机名不允许使用默认主机名,因为需要保证各个节点的主机名不相同,在部署matrix集群前,仍然可以修改主机名,在命令行中用“hostnamectl set-hostname hostname”命令进行主机名的修改。部署好后不允许修改主机名。
安装好操作系统后,在终端命令行中输入systemctl status matrix
验证matrix是否安装成功(active字段显示active:running)
其余安装细节以及其他操作系统的安装过程参见 指导书 。
1.3配置Matrix集群参数
如果是非H3Linux,需要在此之前,先安装Matrix,具体操作见指导书。
使用https://ip_address:8443/matrix/ui
登录matrix界面。
其中,ip_add为节点的ip地址,8443是固定端口。默认用户名为admin,密码为Pwd@12345
其中集群内部虚ip和北向业务虚ip即 准备工作 中所规划的对应ip地址,两个地址都必须在Master节点所处的网段内。
Service IP地址池,用于为Service分配IP地址,不能与部署环境中的其它网段冲突。默认地址为 10.96.0.0/16,一般保持默认值。
容器地址池,用于为容器分配IP地址,不能与部署环境中的其它网段冲突。默认地址为 177.177.0.0/16,一般保持默认值。
NTP服务器,用于保证集群内各节点系统时间的一致性,支持选择内置服务器和外置服务器。选择外置服务器时,需要配置NTP服务器地址,且该地址不可与集群内各节点的IP地址冲突。 本文中使用内置服务器作为NTP服务器,部署集群时会首先进行时间同步,集群部署完成后,三台Master节点会定时同步时间,从而保证集群内各节点的系统时间保持一致。
1.4创建集群
单机部署模式下,仅需增加一个 Master 节点即可部署集群。集群部署模式下,需要增加三个 Master 节点后,再部署集群。
参数说明:
- 类型:显示为“Master”,且不可修改。
- IP 地址:规划的 Master 节点的 IP 地址。
- 用户名:节点操作系统的用户名,当前仅支持 root 用户及 admin 用户。根据安装操作系统时实际选择的用户填写。集群中所有节点的用户名必须相同。
- 密码:节点操作系统的用户密码。
1.5部署统一数字底盘应用安装包
上传 准备好的 应用安装包,有两种方式,一种是系统后台上传(上传到/opt/matrix/app/install/packages目录下),另一种是web界面上传。上传后的部署操作则均在web界面进行。
输入https://ip_address:8443/matrix/ui
登录matrix,默认用户名为admin,密码为Pwd@12345
其中ip_address为北向业务虚ip
在向导界面下,进行底盘必选应用包的部署,其中在标准模式下,有三个必选的安装包,默认勾选。
接着在部署应用界面,进行组件必选应用包的部署,其中安装部署顺序需要按照 组件安装指导书 中的应用包安装顺序进行。
至此,统一数字底盘的安装部署完成,后续可通过http://ip_address:30000
访问数字底盘并进行组件的安装部署和管理等操作,其中ip_address为北向虚ip。用户名和密码默认与8443端口一样。
2.部署管理统一数字底盘组件
统一数字底盘可以根据DC、Campus、WAN不同场景安装多种组件,且允许共存。由于本文仅涉及ADDC,因此仅安装了DC组件。
2.1 准备工作
启用网卡(若服务器仅一块网卡可跳过)
修改网卡的配置信息:使用vi /etc/sysconfig/network-scripts/if_name
,if_name为网卡的标识,可用ifconfig查看服务器的所有网卡信息
BOOTPROTO 配置为“none”表示不指定网卡的启动协议,ONBOOT 配置为“yes”表示开机自动启用网卡连接。
修改完文件后重启网卡。
地址规划 组网中包括两种类型网络:
- Calico 网络 Calico 是一个开源的网络和网络安全解决方案,适用于容器、虚拟机和基于主机的本地工作负载。Calico 网络为容器间交互所使用的网络,为内部使用。Calico 网络所使用的网段为部署 Matrix 集群时设置的容器 IP 地址池,默认为 177.177.0.0,安装部署组件时无需再配置地址池给 Calico 网络使用。Calico 网络和 MACVLAN 网络可复用同一个网口。
- MACVLAN 网络 MACVLAN 网络用来作为管理网络。MACVLAN 虚拟网络技术可以实现一个物理网口绑定多个 IP 和多个 MAC 地址的功能。一些应用程序,尤其是遗留应用程序或监控网络流量的应用程序,希望直接连接到物理网络。在这种情况下,可以使用 MACVLAN 网络驱动程序为每个容器的虚拟网络接口分配一个 MAC 地址,使其看起来是一个直接连接到物理网络的物理网络接口。物理网口需要能够处理“混杂模式”,即一个物理接口可以分配多个 MAC 地址。
SeerEngine-DC组件即DC控制器;vBGP则是应用在混合overlay组网中,vBGP与Spine建立对等体,通过控制器对主机 Overlay的虚机信息进行封装并作为路由发布到EVPN设备侧,同时将EVPN设备侧的BGP路由通过流表形式下发至主机Overlay网络,从而实现网络Overlay和主机Overlay下的虚机流量互通,vBGP是控制器实现 OpenFlow流表与BGP路由互转的核心组件。DTN是实现仿真功能的组件。本文只涉及SeerEngine组件。
一般将DC组件与设备通 信的网卡称为南向网卡与IP,将DC组件与数字底盘交互通信,WEB配置的网卡称为北向网卡与IP。DC组件北向网卡通信方式与ambassador一致采用calico方式。南向网卡通信采用macvlan方式,通过veth pair 进行直接连接到物理服务器的对应网卡中,并与物理服务器命令空间隔离。
我们需要规划的DC网络类型就是MACVLAN,也就是南向网卡的ip地址,该地址是DC控制器用来与设备建立openflow和netconf连接的,即纳管设备。北向网卡ip则是使用前面创建[集群中默认配置](# 1.3配置Matrix集群参数)的容器地址池
(177.177.0.0/16),不需要进行配置。
SeerEngine-DC的MACVLAN原理及规划: 控制器需要通过物理服务器的网卡来纳管网络设备,此时可以选择是否复用统一数字底盘的网卡,以及是否复用其网段。以下图为例,统一数字底盘的IP地址为98.2.1.1,vlan tag 为4050,网卡为eth1,网关在管理交换机上的vlan4050虚接口上,为98.2.1.254。 ① 复用网卡eth1,且复用网段,ip地址为98.2.1.2,则不需要配置VLAN ② 复用网卡eth1,单独网段,ip地址为1.1.1.1,此时如果不配配置单独VLAN,则需要共用网关接口,因此需要在管理交换机的vlan4050接口下增加一个子网ip1.1.1.254,作为控制器的网关 ③ 复用网卡eth1,单独网段,ip地址为1.1.1.1,配置单独VLAN30,则需要在管理交换机上另起一个vlan 30虚接口,配置ip地址1.1.1.254 ④单独网卡eth2,复用网段,ip地址为98.2.1.2,若不配置VLAN,需要在管理交换机的端口上配置PVID为4050,保证DC和网关可达;若配置VLAN,需要配置VLAN为4050,否则不可达。 ⑤ 单独网卡eth2,单独网段,ip地址为1.1.1.1,此时无VLAN则在交换机的接口上配上网关虚接口所对应的vlan作为PVID即可,若有VLAN,则任意配置,仅需要与交换机上的网卡接口VLAN对应即可。
标准Kubernetes POD之间通信,分为单主机容器与跨主机容器网络通信两种。单主机容器通信包含host类型,bridge 类型。跨主机容器网络通信包含macvlan类型,calico类型。
2.2部署组件
登录统一数字底盘(30000页面),在系统
页签中,选择部署管理
项,上传seerengine-dc安装包,勾选”云数据中心“,再勾选”DC控制组件“,如需部署vBGP和DTN,则自行上传勾选。
按照准备工作中的地址规划,配置MACVLAN网络,关联上行口
在网络绑定页面,将网络和子网绑定到不同组件,使用子网 IP 地址池为组件分配 IP 地址。
确认参数无误后,点击部署。
至此,DC组件部署完成,后续登录统一数字底盘即可使用SeerEngine-DC等组件。
3.纳管设备
如上图,控制器需要将两个fabric中的Leaf和Spine以及Border进行纳管,后续进行配置下发和流表下发。
纳管设备的前提是underlay网络打通,即整张网络的底层需要实现互通,underlay打通方式分为手工配置和自动化上线,手工配置包括硬件资源配置、管理网配置、L2VPN和VXLAN配置、underlay路由协议、VTEP地址、OverlayBGP配置、连接Leaf/Border)的接口配置、以及M-LAG配置(如果设备使用M-LAG技术)等。 自动化上线则是在控制器上设置TFTP服务,并内置DHCP服务器,设备在自动化的部署的过程中,向DHCP服务器请求管理口地址,同时在控制器上配置自动化上线模板,设备空配置启动后,会在管理口上自动获取IP地址。
Underlay网络打通后,就可以在控制器上对设备进行纳管操作,后续进行业务配置的下发。
以Spine、Border合一的场景为例,具体介绍一下手动纳管的过程:
fabric拓扑:
两台Leaf、一台Spine/Border、一台FW和一台LB,每台设备通过管理口与MGMT交换机进行互连。
设备 | 管理口地址 |
---|---|
Spine | 192.168.100.42 |
Leaf1 | 192.168.100.43 |
Leaf2 | 192.168.100.44 |
FW | 192.168.100.64 |
LB | 192.168.100.63 |
EX | 192.168.100.41 |
3.1Underlay网络配置(手工)
网络设备:
以Spine/Border为例,两台Leaf配置过程类似
空配置重启
reset saved-configuration reboot force 硬件资源参数配置 部分设备是修改hardware-resource,如S6800、S12500等,部分设备是修改switch-mode,如S10500X、S7500X等,本实验中使用S6800 [spine-border1] hardware-resource switch-mode 4 [spine-border1] hardware-resource routing-mode ipv6-128 [spine-border1] hardware-resource vxlan Border40k
管理网配置 ① 配置管理vpn ② 配置管理默认路由 ③ 配置管理口 ④ 配置管理用户 ⑤ 配置VTY ⑥ 配置NETConf ⑦ 使能SSH服务
L2VPN和VXLAN基础配置 (1) 开启设备的L2VPN功能。 [spine-border1] l2vpn enable (2) 禁止从VXLAN隧道学习MAC、ARP、ND。 [spine-border1] vxlan tunnel mac-learning disable [spine-border1] vxlan tunnel arp-learning disable [spine-border1] vxlan tunnel nd-learning disable
Underlay路由协议配置 以OSPF协议为例
配置VTEP地址(loopback地址)
Overlay BGP配置
连接Leaf接口的配置 以OSPF协议为例
安全设备:
FW和LB不同Leaf和Spine,仅需要配置好本身的管理网,以及自身的接入模式(IRF和RBM)即可,本实验是单FW和LB,因此不涉及
管理网配置 ① 管理口地址配置 ② 管理网默认路由 ③ 管理口加入安全域(FW需要) ④ 增加管理用户 ⑤ VTY配置 ⑥ SSH和NETConf配置
IRF配置
3.2控制器配置
- 增加Fabric,填写好Fabric相关参数
其中,Overlay 路由协议 BGP AS 号:必填,此 AS 号需与 Fabrics 内设备的 BGP AS 号相同,以 100 为例。
将Fabric加入到VDS中
在Fabric中添加交换设备,填写管理地址和VTEP地址,选择设备类型,border选择边界设备,leaf选择接入设备,配置NETCONF,其中用户名和密码即设备的管理网用户配置,并且可根据实际业务需求决定是否开启转发预配置,最后在openflow页签上,需要配置好VRF名称,即在设备上配置的管理网vpn名称。
如果开启了转发预配置,则只要配置了虚拟链路层网络,便会在对应的接口下发AC配置,Leaf上的VSI接口会up,此时会占用设备的AC资源,而如果关闭了转发预配置,则在控制器上只要虚拟端口没有上线,就不会下发AC口配置,VSI接口也不会up,从而占用AC资源,实际应用场景基本都是关闭转发预配置。
在网络设备的VXLAN可以进行设备侧的转发预配置全局配置,还可以到虚拟链路层网络中的高级设置中,对某个具体的虚拟链路层网络进行转发预配置的开启和关闭,以后者的配置为优先。
对于边界设备,还需要将设备加入到边界设备组中。其中一些配置需要结合实际场景进行配置,如防火墙接入模式(逻辑上),本实验中是旁挂接入,HA部署模式为IRF,网络位置为出口网关。
防火墙接入模式此处配置的接入模式为逻辑上的接入模式,可以支持物理直连,逻辑直连;物理旁挂,逻辑直连/旁挂,不同场景下发的配置不同,流量转发路径也不同,具体可见[单安全网关出口场景](# 单安全网关出口场景 )对于安全设备,如FW和LB,需要先在资源池中添加三个网络地址池以及一个VLAN资源池
① 虚拟管理网络地址池
② 租户承载防火墙内网地址池
③ 租户承载负载分担内网地址池
④ 租户承载网VLAN池
地址池和vlan池的意义见上图,由于实际应用中,在根墙上使用context虚拟出多台虚墙(LB也同理),用虚墙承载业务流量,因此控制器与这些虚墙之间需要建立Openflow连接(与根墙不需要建立Openflow连接,仅建立NetConf连接,用于创建context),而context与控制器的管理连接地址需要由控制器统一下发,因此虚拟管理网地址池中的地址便是context与控制器之间建立管理连接网络的地址。
而租户承载FW和租户承载LB内网,分别是spine设备与FW、LB的互连网络,使用vlan接口实现互通,因此租户承载网vlan池就是用来在spine上,给这两个内网起vlan虚接口的。
接着,在边界设备组中,将这几个地址池和vlan资源加入。
在Fabric中增加L4-L7设备,相关字段按实际情况填写
在
设备资源
中,增加L4-L7物理资源池和资源模板资源池模板的意义FW和LB的资源池模板是为了在根设备上创建context的模板,其中需要注意的是上下行口和管理口,其均复用的是根设备的接口,因此根设备是使用哪个口与管理交换机互连、与Spine/Border互连,则需要将其与模板中所配置的一一对应。管理口即前面提到的虚拟管理网所使用的接口,上行口指的是L4-L7设备与外部网络进行通信的接口,即内网流量经过该设备时,从上行口发送给外部网络,也从该接口接收外部网络发送来的流量,下行口则相反。需要注意的是,上下行口可以复用,下行口和管理口也可以复用,但三个口不能同时复用,上行口也无法和管理口复用。
此外,当需要配置集中式[虚拟路由器互连](# 6.虚拟路由器互连),且接入防火墙时,需要在模板中配置虚拟路由器互连接口,该接口不能和下行口复用。因为虚拟路由器互连vlan池可以和租户承载网vlan池范围重叠,如果复用下行口,那么vlan就可能重叠,那么又有问题?不能在同一个子接口下起个子网吗?可以,但控制器的逻辑就是不支持,因此不可复用下行口。
完成操作后,可以在设备资源中,查看到所有设备的纳管情况,正常情况下,设备状态是active的,数据同步状态是绿色的√
可以将鼠标放到inactive上查看具体原因,常见的原因以及排查思路如下:
1、OpenFlow连接失败最为常见,其原因主要分为以下几种:
(1)SeerEngine-DC先知引擎控制器Web页面纳管的物理网元设备信息填写错误;如管理网的VRF是否填写正确,与设备上是否一致
(2)物理网元设备的管理IP地址与SeerEngine-DC先知引擎控制器的IP地址路由不可达;
(3)设备上的OpenFlow实例配置错误;
(4)物理网元设备与SeerEngine-DC先知引擎控制器之间通信的端口号(TCP 6633)未放行。
2、Netconf连接失败也较为常见,其原因主要分为以下几种:
(1)物理网元设备Neconf配置错误;如未开启NetConf over ssh和http服务、ssh user 中未开启netconf服务等
(2)SeerEngine-DC先知引擎控制器Web页面纳管的物理网元设备信息用户名密码填写错误;
(3)物理网元设备上创建了SSH用户或配置了SSH访问限制;
(4)物理网元设备与SeerEngine-DC先知引擎控制器之间通信的Netconf端口号(TCP 443)未放行。
需要注意的是,初次纳管时,控制器需要先和设备建立NetConf连接,利用NetConf连接为设备下发Openflow实例的配置,再利用openflow配置,与设备建立openflow连接,实现纳管。因此当初次纳管时,如果填错了NetConf的用户名密码信息,inactive原因是会显示openflow连接失败的。此外,netconf是长连接,正常情况下不会进行重连,只有当openflow重新连接时,才会触发netconf重新连接。因此当需要立即触发netconf连接时,可以通过active和undo active openflow 实例来触发。
交换设备:
前面提到,对于交换设备,控制器先通过netconf为设备下发openflow配置,设备根据openflow配置与控制器建立openflow连接,因此,纳管成功后,会在交换机上看到设备通过管理地址与控制器建立的连接(以Spine为例):
可以看到,除了BGP和ssh连接以外,还存在八个netconf连接(本机830端口)和一个openflow连接(控制器6633端口),接着可以查看控制器下发的openflow连接:
其中controller 1即表示本机和控制器建立openflow连接的ip地址对,active instance表示激活该openflow实例,之前也提到,可以undo该命令,来触发netconf的重新连接
建立了openflow连接后,控制器会给设备下发流表,如协议报文上送控制器(ARP)
安全设备:
不同于交换设备,控制器对于安全设备中的根设备,是不需要建立openflow连接的,控制器是与虚墙进行openflow连接,因此纳管后tcp连接中仅有netconf连接。
4.业务配置(以单安全网关出口场景为例)
官网配置手册中包含多种无云业务场景,本实验以最常见的单安全网关出口场景为例
4.0实验拓扑以及内容简介
实验拓扑如下:
资源规划
规划项 | 具体内容 |
---|---|
租户承载防火墙内网 | 23.1.3.1/24—23.1.3.100/24 |
租户承载负载均衡内网 | 23.1.4.1/24—23.1.4.100/24 |
虚拟管理网 | 98.13.13.1/24—98.13.13.100/24,网关98.13.13.254 |
租户承载网vlan池 | 300—499 |
外部网络 | 13.1.1.0/24,网关13.1.1.254 |
业务网段 | 23.1.0.0/16 |
Loopback0地址 | 13.2.2.x/32 |
设备管理网 | 192.168.100.0/24 |
实验内容简介:
为租户分别创建了两个虚拟路由器,对应vpn8888和vpn9999,三个虚拟链路层网络,一个链路层网络拥有一个子网,分别是23.1.0.0/24、23.1.1.0/24和23.1.2.0/24网段,并分别创建两个vfw和vlb(独享模式),其中,vfw1和vlb1绑定vpn8888,vfw2和vlb2绑定9999。
4.1 控制器基本配置
前四步
1、增加Fabric
2、配置VDS
3、配置全局参数
4、增加边界设备组
前面的四步在[纳管设备](# 3.纳管网络设备)时,已经做了部分的配置,不再赘述。
4.1.5增加VLAN-VXLAN映射表
在资源池的VNID资源池中增加vlan-vxlan或vlan-network映射表
VLAN-VXLAN映射表的作用,就是在EVPN-vxlan手工配置中的AC口配置,最终下发的配置便是服务实例,下图例子是将vlan100映射到vxlan500中
默认情况下,是vlan-vxlan一对一映射,通过指定映射区间宽度,实现批量一对一映射。
两张表均需要指定配置到某个设备的具体接口下,即在该AC口创建一个或多个服务实例,不同的是,vlan-network需要关联虚拟链路层网络,而vlan-vxlan不需要关联,因此vlan-vxlan映射的不足是,当启用了转发预配置下发,当多个虚拟链路层网络加入虚拟路由器后,控制器便会在应用了该表的接口下,下发所有的AC口配置,即使该设备下并没有对应的虚拟链路层网络。举个例子:
现有一个vlan-vxlan映射表,vlan[100,200]–>vxlan[500,600],为一一映射关系,创建了两个虚拟链路层网络,segment id(简单理解就是vxlan ID)分别为500和600,因此根据映射表,分别对应的vlan为100和200,将这两个虚拟链路层网络加入到虚拟路由器(简单理解就是L3VNI所在的vpn实例)8888中,那么此时控制器会在Leaf1和Leaf2的GE1/0/2接口下,同时下发两个服务实例:
service-instance 100 service-instance 200 encapsulation s-vid 100 encapsulation s-vid 200 xconnect vsi 500 xconnect vsi 600
但实际情况是,Leaf1和Leaf2下并每没有下联所有的虚拟链路层网络,此时就会浪费设备的AC资源。因此解决该问题的方法有两个,一个是使用VLAN-NETWORK映射表,另一个是关闭转发预配置
4.1.6增加租户
4.1.7增加出口网关
新增出口网关,将边界组成员设备加入到网关中(绑定了地址池和vlan资源),并将服务资源池添加到网关中(绑定了context模板)。
4.1.8租户绑定出口网关
租户绑定出口网关,从而可以使用对应的资源池资源
4.2租户Overlay配置
接下来就是控制器上对业务的操作流程,最终会落到设备的具体配置上,下文中的配置以VPN8888为例,VPN9999类似
4.2.1增加虚拟链路层网络
在前面也提到过几次这个概念,虚拟链路层网络,简单理解,就是业务网段,即虚机与交换机设备进行连接的网络地址,对应到设备配置上,就是AC口的配置,结合控制器上的参数,对应具体的配置。
- Segment ID:即vxlan id,该数值需要落在刚刚配置的vlan-vxlan映射表的vxlan区间
- 子网:根据实际业务网络,将其规划到各个虚拟链路层网络中。可以将多个子网加入到同一个虚拟链路层网络中,最终下发到设备的配置,便是AC口的服务实例,结合vlan-vxlan网络,将vlan映射到对应的vxlan中,其中子网的网关ip,即evpn分布式网关中的vsi虚接口的ip地址,即VTEP设备作为虚机的网关。当有多个子网时,便会在vsi虚接口上起多个sub地址,多个子网共用该vsi虚接口作为网关。
- DHCP的开启:当关闭转发预配置时,设备的配置下发取决于控制器上的虚拟端口是否上线,而虚拟端口的上线又取决于上送控制器的ARP/DHCP报文是否匹配对应的配置,如果关闭DHCP,表示该虚拟端口上线是使用ARP报文触发,如果使用DCHP,则代表使用DHCP Discover报文触发。同时,如果开启DHCP报文,此时控制器会向虚机分配ip地址。
4.2.2增加虚拟路由器
前面提到,虚拟路由器其实就是一个vpn实例,对应evpn-vxlan中,vsi虚接口所绑定的vpn实例,虚拟路由器配置中的segment id就是l3vni,当把虚拟链路层网络加入到虚拟路由器后,便可以在该路由器内进行互通,可以简单理解为传统二三层网络中,多个vlan虚接口加入到了一个vpn实例中,对内可用该vpn实例路由表进行互通,对外则用一个统一的虚接口进行互通。
在传统EVPN-VXLAN的手工配置中,需要先创建VSI,其number作为l2vni,在其中绑定vxlan,创建对应的vsi接口,作为分布式网关,再另起一个vsi接口用于配置l3vni,并将所有的vsi接口绑定一个vpn实例,最后在Leaf的下行口配置服务实例,即静态AC配置。
对应到控制器上的操作中,增加虚拟链路层网络,即下发了二层VSI对应的配置,其中的segment id为vxlan id,对应vsi interface(控制器上下发的VSI配置中,vxlan id和vsi虚接口 id是一致的);增加虚拟路由器,则是下发三层VSI接口的配置(l3vni)和VPN实例,VPN实例名字格式为租户名称_虚拟路由器名称_虚拟路由器Segment ID
。而服务实例下发到某个具体接口,是由vlan-vxlan映射表配置时选择应用到某个接口决定的。
只有当虚拟链路层网络加入到虚拟路由器上时,且虚拟端口上线(关闭转发预配置)控制器才会给leaf设备下发AC配置。具体流程如下(终端手动配置IP地址):
1、终端23.1.0.111发送arp报文,请求网关23.1.0.254地址,报文到达leaf设备,匹配流表,上送控制器
2、控制器分析该arp报文,查看其vlan和ip地址所在子网,是否匹配vlan-vxlan映射表(或vlan-network映射表),以vlan-vxlan为例,arp报文vlan为100,匹配映射表中的vxlan500,查看其子网23.1.0.0/24,在虚拟链路层网络的子网中,且该虚拟链路层网络加入了虚拟路由器中。
3、控制器下发配置到vlan-vxlan映射表应用到的接口xge1/0/3上。
4.2.3租户绑定FW和LB服务资源
该步骤就是在安全设备上根据L4-L7模板,创建一个context用来承载VFW/VLB,该context此时仅使用了ip资源池中的虚拟管理网,因此此时还未创建VFW/VLB,需要将VFW/VLB关联虚拟路由器,虚拟路由器在绑定该context,此时一个完整的VFW/VLB才运行在了context中。
资源分配方式中从资源池分配
表示为VFW/VLB单独创建一个context,复用已创建资源则是与其他VFW/VLB共享一个context,在context中用vpn实例互相隔离。
当选择从资源池分配时,可用选择是否共享节点,在此基础上可选择最大共享数量,表示最多支持多少个VFW/VLB共享该context。通过控制器主动配置共享节点数量,属于手工复用context,没有数量限制。使用场景仅限云网融合场景。
添加LB资源同理。
为FW和LB分别创建了context提供给虚拟设备,并根据资源池配置,为vFW和vLB分配了管理地址。
LB设备:
配置了虚拟管理口地址(复用了根LB的管理口),以及租户承载负载分担内网的vlan和ip地址(地址和vlan规划见[前面的配置](# 3.2控制器配置))
进入context中,此时还未关联虚拟路由器,作为vlb的承载器,此时仅有管理地址
下发了openflow配置,通过Openflow纳管context
FW设备:
同样地,FW也会下发虚拟管理口(网)
为context下发openflow配置
4.2.4增加防火墙
首先增添安全规则:
接着创建安全策略,绑定安全规则
最后添加防火墙,绑定安全策略和虚拟路由器,至此创建了一个vfw。
4.2.5创建负载均衡
首先增加健康检测:
接着增加实服务组,实服务组即对应一组内网服务器(虚机),统一对外提供服务,本实验以对外提供ssh服务为例。其中绑定健康检测,指定虚拟端口作为实服务组成员。
增加虚服务器,即实服务组的成员,统一以一个虚服务器的角色对外提供服务。
创建监听器,用于将虚服务器和实服务组关联起来,并指定监听的协议和端口
此时若选择开启用户源地址转换,见 单安全网关出口场景中不同选项导致的不同配置
最后创建负载均衡器,绑定监听器,至此创建了一个完整的vlb。
4.2.6创建外部网络
创建外部网络,其中类型为VLAN,表示出口网关与外部网络使用vlan虚接口进行互连,segment id则是对应的vlan号,extend segment id在 直通外网 中会给出口网关所在设备(Spine)下发不同的配置。在配置外部网络的子网中,网关ip指的是外部网络出口的对端ip,在单安全出口的FW旁挂场景中,外网出口在FW上,网关ip在spine上(如果是直通外网,出口ip则下发在border上,网关ip需要在外网交换机上手动配置)
4.2.7虚拟路由器绑定vfw和vlb
4.2.8虚拟路由器绑定外部网络
虚拟路由器绑定了vfw和vlb以及外部网络后,分别会在Border、vfw所在context和vlb所在context下发配置。
此时,context中才应该存在租户承载防火墙内网和租户承载负载分担内网的子接口和ip地址(若配置了虚拟路由器连接地址池和vlan池,还会在FW中下发虚拟路由器接口和ip地址)
若此时选择开启SNAT,则会在FW和Border上下发其他配置,具体见 单安全网关出口场景中不同选项导致的不同配置
Border:
连接vfw下行口的vlan接口配置(租户承载防火墙内网)
连接vfw上行口(外部网络网关在border上,出口在vfw上)
连接vlb接口
L3VNI接口下配置了PBR,匹配终端出外网的报文,修改下一跳到 LB(关闭源地址转换时下发的配置)
来自LB的去往外网的流量,下发一条默认路由,指向vfw的下行口
从外网访问内网网段时,匹配静态路由,指向vfw的上行口
从外网访问虚服务器的流量,从FW回到border时,匹配32位明细路由,指向LB
VFW:
vfw的下行口(租户承载FW内网)
vfw的上行口(外部网络出口)
来自border去往外网的流量,匹配跨VPN静态路由,交回给border的外网网关
来自外网去往内网的流量,匹配跨VPN的静态路由,通过租户承载防火墙内网交给border
VLB
与border互连接口(租户承载负载均衡内网)
去往border的缺省路由
创建了负载均衡,将实服务组和虚服务器通过监听器进行关联,并使用健康检测进行连通性检测
4.3流量路径分析
4.3.1入内网路径
① EX上有到内网网段的静态路由,下一跳指向Border。接着Border匹配静态路由,交给FW
② FW收到报文后,匹配跨VPN静态路由,通过租户承载FW内网交给Border
③ Border收到报文,发现目的IP地址匹配明细静态路由,发送给LB
④ LB匹配负载均衡,根据算法,将该报文负载均衡到实服务组的某个成员(本实验中仅一个成员),创建会话表,通过默认路由发送给Border
⑤ Border收到报文,匹配由Leaf发送来的MP-BGP二类路由,发送给Leaf
⑥ Leaf收到报文后,作为终端网关,发送给终端
4.3.2出外网路径
① 交给网关,网关在leaf上,leaf匹配Border在BGP引入的默认路由(Border上该默认路由指向FW),将报文交给Border
② Border收到该报文,本应匹配指向FW的默认路由,但由于在L3VNI对应VSI接口下,配置了PBR,因此被引流至LB
③ LB上匹配会话表,将源IP(23.1.0.111)修改为虚服务器IP(23.1.0.101),并匹配默认路由,通过租户承载LB内网,交回给Border(与4.3.1的④同理)
④Border收到报文,此时在租户承载内网的vlan接口下收到该报文,此时则匹配默认路由,通过租户承载FW内网,发给了FW
⑤ FW收到该报文,匹配跨VPN的默认路由,通过FW的上行口,交回给Border
⑥ Border在外部网络网关上收到该报文,发现目的IP匹配直连路由,交给EX交换机
5.服务链场景
微分段(Microsegment), 又称为基于精细分组的安全隔离,其实质就是基于对报文进行分组后的组标识来进行流量控制。例如,将数据中心网络中的服务器按照一定的原则进行分组,再基于分组部署流量控制策略,从而达到简化运维、安全管控的目的。
总的来说,就是安全设备(安全资源池),以服务器的角色形式,接在了Leaf上,通过在Leaf上创建EPG(End-point Group),基于IP地址、IP网段等对网络端点进行EPG划分,以便实现基于EPG进行流量管控,将流量引到安全资源池。此外,还可以通过通过部署GBP(Group Based Policy),可以对属于不同EPG的网络端点之间的通信进行安全管控。GBP通过在应用策略中设置 源EPG和目的EPG之间的访问规则来实现。
Ø 微分段的实现机制可以概括为:
(1)划分EPG,即将网络端点加入EPG。根据应用场景和部署方式的不同,可以通过如下方式将网络端点加入EPG:Network、Subnet、Terminal和External。
(2)在应用策略中设置源EPG和目的EPG的访问规则,实现对属于不同EPG的网络端点之间的通信进行安全管控。控制器将上述配置下发到源端设备上后,源端设备接收到报文时,会判断报文所属的EPG,根据GBP(应用策略中设置的访问规则)对报文的转发进行控制(允许通过、拒绝通过或重定向到服务链)。综上所述,微分段是生效在报文转发路径中的源端设备上的。当GBP判决结果为丢弃时,报文将被直接丢弃,不会再经由中间网络转发至目的端,这就避免了带宽浪费
Ø EPG划分方式:
① Network方式,表示一个虚拟链路层网络内所有子网的网络端点
② Subnet方式,表示一个子网内的网络端点
③ Terminal方式,表示一个虚拟端口对应的网络端点。
④ External方式,表示一个外网网段内的网络端点。
Ø 在应用策略中,通过设置源EPG和目的EPG之间的例外规则,可以实现:
•创建源EPG和目的EPG白名单,即允许源EPG和目的EPG中的网络端点互访。
•创建源EPG和目的EPG黑名单,即禁止源EPG和目的EPG中的网络端点互访。
•将源EPG和目的EPG之间的流量重定向到指定的服务路径,以实现将流量引入到服务链转发。
6.虚拟路由器互连
分布式:
RT互引实现,通过PBR修改发布路由时的RT值,并通过路由策略决定是否将路由引入。此时两个Leaf上有对方的L3VNI对应的VSI接口。
以Leaf_1下接23.1.0.0/24,Leaf_2下接23.1.2.0/24为例
Leaf1:
Leaf2:
Leaf2上学到Leaf1下加入到虚拟路由器连接中的子网以及主机路由,是学在对端L3VNI所在的VSI接口下,Leaf1上的路由表同理
集中式:
① 不上墙,在border实现:路由复制实现。
② 不上墙,在border实现,开启路由精简:使用跨VPN的静态路由(不指定下一跳)实现,部分设备直接实现,部分设备使用Loopback口实现
③ 上墙,在FW上实现,同一context中:使用跨VPN的静态路由(不指定下一跳)实现,使用Loopback口实现
④ 上墙,在FW上实现,不同context中:使用跨虚拟路由器互连接口实现
经典问题:VPN1和VPN2建立虚拟路由器连接,VPN2和VPN3建立虚拟路由器连接,VPN1和VPN3能否通信?
① 使用分布式进行连接,此时由于使用了路由策略对引入的路由有了限制,因此此时VPN1和VPN3是无法通信的
② 集中式连接,在不上墙且不开启路由精简情况下。在路由复制中添加了advertise
字段,则表示允许发布引入的路由,此时VPN1和VPN3可以互通,如果不发布,则此时VPN1和VPN3是没有对方的路由的,此时无法通信
7.直通外网
直通外网指的是无安全设备,Border直连外部交换机连通外网,外部网络的出口IP下发在Border上,网关需要在外部交换机上设置。
VPN实例直通外网方法:
- RT互引+ospf/bgp
- PBR
- 互写静态路由
- 路由复制+静态路由
8.其它
AD6.0环境下,S6800设备无法下发集中式的虚拟路由器配置的问题,得到结论是由于6800不支持vlink,因此在下发配置时,无法下发vlink的路由复制配置,导致所有配置无法下发。
两个虚拟路由器共享ipv4外部网络后,绑定v6的外部网络,必须要保持ipv6的外网出口IP两个虚拟路由器也是配成一样的。不一样的就会报错。
配置虚拟路由器的segment id时,不能配置在vlan-vxlan配置的去区间上。
Ø 共享型外部网络和独享型外部网络的区别主要在于:
共享型外部网络中,M-LAG系统作为一个border设备组,通过在设备组上下发外部网络的相关配置实现外部网络打通。
而独享型外部网络,是M-LAG系统中,两台设备分别作为单独的border,分别使用各自的网段实现与外部网络的互通。
Ø 共享出口网关不会下发默认路由,非共享会下发
Ø 在配置外部网络时,如果选择了external segment id,则在border上的回程路由会使用RT互引实现,如果不配置ex segement id,则使用路由复制实现VPN互引。若在外部网络页签开启路由精简,则使用跨vpn的不指定下一跳的静态路由实现(直通出口网关场景)
而安全纳管场景,border上的回程路由,在没有开启SNAT时,使用静态路由,指向FW;若开启SNAT,则无路由(因为出外网的源ip在FW上转为了浮动IP,则回程报文的目的ip则是浮动ip,与border同网段)
Static NAT对于icmp的地址转换原理:
由于icmp不像tcp或udp有端口号,因此在内网中有多个ip需要转为同一个外网ip时,无法根据正常理解的按端口号区分内网ip,但在fw上查看session table的时候,仍然可以看到sip和dip具有端口号,实现原理是:在ip数据包中的icmp报文头中,有一个identifier
字段,nat使用该字段来作为nat地址转换过程中的端口号
该场景是在外部网络中启用了SNAT,因此在fw上会将内网地址23.1.0.111转换为外部网络出口ip,即13.1.1.2,icmp reques报文的sip改为了13.1.1.2,发往了外部网络13.1.1.253,其中会携带001b标识符,外部网络收到request报文后,回应报文中同样携带了001b的标识符,因此能匹配上会话表,通过防火墙,进行地址转换,会送给内网23.1.0.111
LB开启源地址转换,FW默认配置
入方向的流量路径,与默认配置一致,只是在LB上,报文的源ip变为了虚服务器的ip,目的地址同样还是变为了实服务器ip。
但回程流量到达leaf和border时,会在vpn路由表中匹配虚服务器地址32位掩码的明细路由(是一个静态路由,出接口为租户承载负载分担内网的vlan虚接口),将报文发送给LB,而不是通过PBR引上去。因为源地址转换后,发送给实服务器的报文中,源ip变为了虚服务器ip,因此实服务器回应报文时,目的ip是虚服务器ip,因此在border上,是匹配明细路由直接上了LB。
LB关闭源地址转换,开启浮动ip
此情况下,相当于在FW上,为LB的虚服务器ip创建了一个NAT映射,将该虚服务器ip通过NAT映射到防火墙的一个外部网络出口ip上,此时外部网络就不是直接通过ssh 虚服务器ip,进行访问,而是通过ssh 浮动ip(可以根据自行配置端口号,选择是否在ssh时加上端口号) 而流量报文在DC内部(进入FW以后),流量路径和报文ip的转换与第一种情况相同。
LB开启源地址转换,同时开启浮动ip
与第三种情况类似,只是流量路径不同。
流量报文在DC内部(进入FW以后),流量路径和报文ip的转换与第二种情况相同。
DC二层网络域作为dhco中继,可以修改中继回应终端的报文是广播还是单播,但终端在请求的时候报文携带了广播位是否置位,此时如果修改中继回应报文模式,可能会有问题。
参考文章
https://www.cisco.com/c/en/us/support/docs/ip/network-address-translation-nat/13771-10.html