《云数据中心网络架构与技术》读书笔记 | 第6章 构建数据中心的逻辑网络(Overlay网络)
2023-09-14 09:09:06 时间
第6章 构建数据中心的逻辑网络(Overlay网络)
6.1 Overlay网络
- 构建Overlay网络的技术成为Overlay技术,即NVo3类技术。主流的NVo3技术有VXLAN、NVGRE等。
6.2 VXLAN基础及相关概念
- VXLAN中的新元素:
- VTEP:VXLAN的边缘设备,是VXLAN隧道的起点和重点
- VNI:一种类似VLAN ID的用户标识,一个VNI代表一个租户
- VXLAN隧道:逻辑的概念,建立在两个VTEP之间的一条虚拟通道
- VTEP对VM发送的原始以太帧进行封装,增加VXLAN Header、UDP Header、Outer IP Header、Outer MAC Header
- VXLAN的特点:
- 24bit的VNI可以支持多达1600万个VXLAN段的网络隔离
- VNI可和VPN实例关联,支持L2VPN、L3VPN等复杂业务
- 除VTEP外,其他设备不需要识别虚拟机的MAC地址
- 租户可规划自己的虚拟网络,不需要考虑物理网络IP地址和广播域的限制
- VXLAN封装的UDP源端口由内层的流信息哈希而来
6.3 VXLAN Overlay网络
6.3.1 VXLAN Overlay网络类型
- 1. Network Overlay:所有VTEP均由物理交换机承担
- 集中式中,Leaf为二层网关,Spine或Border Leaf作为VXLAN的三层网关
- 分布式中,Leaf同时作为二层和三层网关,Spine仅作为IP流量高速转发节点,不处理VXLAN报文
- 2. Host Overlay:所有VTEP均由vSwitch承担
- 虚拟交换机部署在服务器上
- 作为Leaf和Spine的物理交换机仅进行IP报文的高速转发,不处理VXLAN报文
- 3. Hybrid Overlay:部分VTEP部署在物理交换机上,部分VTEP部署在vSwitch上
- 东西向流量在虚拟交换机和物理Leaf交换机之间通过VXLAN隧道转发;南北向流量在虚拟交换机(或Leaf物理交换机)与Spine(或Edge)之间通过VXLAN隧道转发
6.3.2 网络类型对比
- 推荐使用Network Overlay构建云数据中心网络
- 推荐分布式Network Overlay作为企业首选的数据中心网络部署方案
6.4 VXLAN控制平面
- 引入EVPN作为VXLAN的控制平面
- 可实现VTEP自动发现、VXLAN隧道自动建立
- 同时发布二层MAC和三层路由信息
- 减少网络中泛洪流量
- 1. EVPN基本原理
- 新增了EVPN NLRI(Network Layer Reachable Information),定义了几BGP EVPN路由类型
- Type2 MAC/IP路由:通告主机MAC地址、主机ARP和主机路由信息
- Type3 Inclusive Multicast路由:用于VTEP的自动发现和VXLAN隧道的动态建立
- Type5 IP前缀路由:通告引入的外部路由,也可以通告主机路由信息
- EVPN路由发布时携带RD、RT,与L3VPN类似
- 新增了EVPN NLRI(Network Layer Reachable Information),定义了几BGP EVPN路由类型
- 2. 同子网互通场景下的VXLAN隧道建立
- 对等体之间通过交互Type3路由来传递VNI和VTEP IP地址
- 如果三层可达,则建立一条到对端的VXLAN隧道,如果对端VNI与本端相同,则创建一个头端复制表,用于后续广播、组播、未知单播报文的转发
- 3. 跨子网互通场景下的隧道建立
- 隧道的建立是通过Type2或Type5 EVPN路由来实现的。Type2路由用于发布32位主机路由,Type5路由可以实现VXLAN与Externel Network的互通
- Leaf1获取Host1的IP+MAC+Host1所属二层VNI+VBDIF绑定的L3VPN实例的三层VNI,根据这些生成Type2路由
- Leaf1的EVPN实例将Host1的IP+MAC+三层VNI发给本端L3VPN实例,生成本地Host1的路由
6.5 VXLAN数据平面
- 1. 流量模型
- 同一VPC内同子网流量,直接由TOR节点完成VXLAN封装的转发
- 同一VPC内跨子网流量,直接在TOR上完成三层路由
- 不同VPC之间的流量,需要经过防火墙到达VXLAN三层网关
- 数据中心内外访问流量,一般要经过IPS/FW、LB、VXLAN网关、TOR节点后再到VPC服务器
- 2. 同子网已知单播报文转发(含ARP请求/应答流程)
- ARP请求报文需要泛洪,封装在到达多个VTEP的隧道内
- ARP应答报文为单播报文,封装在至源VTEP的隧道内
- 3. 同子网BUM报文转发
- 同子网BUM报文转发只在VXLAN二层网关之间进行,采用头端复制的方式
- 到达各个VTEP后,进行VXLAN解封装,获取内层二层报文,在二层广播域内的非VXLAN隧道侧进行广播处理,为报文添加VLAN Tag,转发给对应的终端
- 4. 跨子网报文转发
- 跨子网报文转发需要通过三层网关实现
- 根据报文目的IP地址,源VTEP根据报文的入接口查找对应L3VPN实例下的路由表,目的VTEP根据报文携带的三层VNI找到对应的L3VPN示例
- 5. 跨VPC报文转发
- 跨VPC的互访,需要经过两个VPC的防火墙进行安全过滤
- 6. 数据中心内外报文转发
- 防火墙需要查找路由转发至vSys-root,并通过默认路由转发至Service Leaf的Public vRouter
- Service Leaf的Public vRouter通过默认路由将报文转发至Border Leaf的Public vRouter,Border Leaf通过Underlay网络将报文转发至PE端连接互联网链路的VRF
6.6 业务模型和网络的映射
- 逻辑模型:针对用户网络的建模抽象,自动化部署业务配置时,就是将管理员设计好的VPC逻辑网络模型翻译成配置命令,并通过NETCONF或OpenFlow下发给转发器
- 物理模型:下发到物理设备的形成的功能模型,如创建一个L3VPN
- 1. 计算接入侧
- vSwitch要配置一个BFD、VRF、VXLAN隧道。二层广播在BD中进行,三层路由在对应的VRF实例中查询
- 控制器建模、计算完毕后,通过OpenFlow将二层流表和三层流表下发给vSwitch,vSwitch依据流表来转发业务报文
- 2. Service Leaf、Border Leaf和FW
- Service Leaf通过内部接口(对应于Trust域),将流量送到防火墙;防火墙vSYS内部执行安全过滤操作后从另一个防火墙接口(对应Untrust域),送到Service Leaf上的Public VRF
- Public VRF是所有用户网络共享的。Service Leaf中的Public VRF与防火墙vSYS互联的L3接口,以及Border Leaf上的Public VRF与PE互联的L3接口,是同一私网中的不同网段
- 3. 路由发布与报文转发
- 从内到外:
- 控制器在Service Leaf的VRF1配置一条默认路由,下一跳时防火墙的接口
- 控制器参与EVPN计算,学习到默认路由后,再下发流表给vSwitch
- 接入侧匹配默认路由,将数据报文封装成VXLAN格式,发送给Service Leaf的VRF1
- VRF1查找路由,发给防火墙。防火墙处理完毕后,再次匹配默认路由,将数据报文发给Service Leaf的Public VRF
- Service Leaf的Public VRF匹配默认路由,发给Border Leaf的Public VRF,Border Leaf再根据默认路由发往PE
- 从外到内:
- Service Leaf的Public VRF,会皮遏制到达业务网段的静态路由,会同步给Border Leaf的Public VRF
- Border Leaf收到来自PE的报文,匹配静态路由,下一跳为Service Leaf
- Service Leaf将报文发给防火墙处理
- 防火墙将回城报文发给Service Leaf的VRF1
- Service Leaf的VRF1查EVPN路由表后发给对应的VTEP,由VTEP解封装VXLAN报文后发给虚拟机
- 从内到外:
相关文章
- DataGuard逻辑备库创建(原创)
- 部署到ABAP服务器上的SAP UI5应用,其index.html的读取逻辑
- SAP CRM Opportunity行项目Alternative ID的填充逻辑
- SAP CRM呼叫中心点了interact按钮后的处理逻辑
- SAP ABAP OData uri type为metadata的请求处理逻辑
- SAP CRM系统里文本决定的二次执行逻辑调试
- WordPress Kyma plugin检测kyma连接状态的逻辑
- 通过单步调试理解Angular里routerLink指令实际url的生成逻辑
- Prolog 语言入门教程——果然这个东西用于逻辑推理很强大啊,但是如何将这些专家知识表达为逻辑语言,需要定义