vxlan

想了解一个事物/概念，最好的办法是知道它是为什么出现的，为了解决那些问题而出现。这里，就用这种方式来学习一下VXLAN VXLAN (Virtual eXtensible Local Area Network)可以理解为扩展的VLAN。VXLAN很大程度上是为了解决VLAN的不足而出现的，所以，想了解VXLAN，你得有一定的VLAN基础。下面我们看一下VXLAN的出现是为了解决那些问题。 TOR MAC地址表问题 数据中心的每一个机柜（Rack）上通常会有一个交换机叫TOR交换机（top of rack）。这个交换机负责该rack下所有机器的二层交换。熟悉二层交换机制的话应该知道，交换机需要维护一个MAC address表来提高交换效率。在虚拟化技术出现之前，一个机柜下的机器再多也是有限的，这个MAC address table不会太大。但虚拟化技术出现后，一个宿主机上可能有多个VM，而一个机柜下又有很多个宿主机，这就会导致MAC address table的尺寸变得非常大，甚至超出了普通交换机能够支持的大小。 多租户问题 一个数据中心可能被多个租户使用。对于每个租户，他们都应该可以独立的为自己的机器分配mac地址，VLAN ID 等资源。我们需要一些机制来隔离这些租户，这样，不同租户之间的MAC地址和VLAN即使重复也不会冲突。 STP问题

来自： http://www.h3c.com/cn/d_201811/1131076_30005_0.htm 解读VXLAN 1 起源-Origin 传统的交换网络解决了二层的互通及隔离问题，这个架构发展了几十年已经相当成熟。而随着云时代的到来，却渐渐暴露出了一些主要的缺点。 Ÿ 多租户环境和虚拟机迁移 为了满足在云网络中海量虚拟机迁移前后业务不中断的需要，要求虚拟机迁移前后的IP不能变化，继而要求网络必须是大二层结构。传统的二层网络技术，在链路使用率、收敛时间等方面都不能满足需要。 Ÿ VLAN的局限 随着云业务的运营，租户数量剧增。传统交换网络用VLAN来隔离用户和虚拟机，但理论上只支持最多4K个标签的VLAN，已无法满足需求。 2 竞争-Competition 为了解决上述局限性，不论是网络设备厂商，还是虚拟化软件厂商，都提出了一些新的Overlay解决方案。 网络设备厂商，基于硬件设备开发出了EVI（Ethernet Virtualization Interconnect）、TRILL（Transparent Interconnection of Lots of Links)、SPB（Shortest Path Bridging）等大二层技术。这些技术通过网络边缘设备对流量进行封装/解封装，构造一个逻辑的二层拓扑，同时对链路充分利用、表项资源分担

拓扑图： SPINE配置： hostname SPINE-1 vdc SPINE-1 id 1 limit-resource vlan minimum 16 maximum 4094 limit-resource vrf minimum 2 maximum 4096 limit-resource port-channel minimum 0 maximum 511 limit-resource u4route-mem minimum 248 maximum 248 limit-resource u6route-mem minimum 96 maximum 96 limit-resource m4route-mem minimum 58 maximum 58 limit-resource m6route-mem minimum 8 maximum 8 nv overlay evpn feature ospf feature bgp feature pim feature vn-segment-vlan-based feature nv overlay username admin password 5 $5$bjUuS34N$DaWFpLKAxc.89ZQkEif9YY8a/JukfKjuyzDMDojrB. B role network-admin ip domain-lookup

https://opengers.github.io/openstack/openstack-base-use-openvswitch/ Posted on January 23, 2017 by opengers in openstack Open vSwitch介绍 OVS架构 ovs-vswitchd ovsdb-server OpenFlow Controller Kernel Datapath OVS概念 Bridge Port Interface Controller datapath OVS中的各种流(flows) OpenFlow flows “hidden” flows datapath flows 管理flows的命令行工具 ovs-*工具的使用及区别 Open vSwitch介绍 在过去，数据中心的服务器是直接连在硬件交换机上，后来VMware实现了服务器虚拟化技术，使虚拟服务器(VMs)能够连接在虚拟交换机上，借助这个虚拟交换机，可以为服务器上运行的VMs或容器提供逻辑的虚拟的以太网接口，这些逻辑接口都连接到虚拟交换机上，有三种比较流行的虚拟交换机: VMware virtual switch, Cisco Nexus 1000V,和Open vSwitch Open vSwitch(OVS)是运行在虚拟化平台上的虚拟交换机，其支持OpenFlow协议

先看下OVS整体架构，用户空间主要组件有数据库服务ovsdb-server和守护进程ovs-vswitchd。kernel中是datapath内核模块。最上面的Controller表示OpenFlow控制器，控制器与OVS是通过OpenFlow协议进行连接，控制器不一定位于OVS主机上，下面分别介绍图中各组件 ovs1 ovs-vswitchd ovs-vswitchd 守护进程是OVS的核心部件，它和 datapath 内核模块一起实现OVS基于流的数据交换。作为核心组件，它使用openflow协议与上层OpenFlow控制器通信，使用OVSDB协议与 ovsdb-server 通信，使用 netlink 和 datapath 内核模块通信。 ovs-vswitchd 在启动时会读取 ovsdb-server 中配置信息，然后配置内核中的 datapaths 和所有OVS switches，当ovsdb中的配置信息改变时(例如使用ovs-vsctl工具)， ovs-vswitchd 也会自动更新其配置以保持与数据库同步 # ps -ef |grep ovs-vs root 22176 22175 0 Jan17 ? 00:16:56 ovs-vswitchd unix:/var/run/openvswitch/db.sock -vconsole:emer -vsyslog:err

今天研究了一下k8s的网络模型，该解析基于flannel vxlan+ kubeproxy iptables 模式。 一.Docker 首先分析一下Docker层面的网络模型，我们知道容器是基于内核的namespace机制去实现资源的隔离的。network是众多namespace中的一个，那么如何保证一个节点上容器之间的通信呢？Docker的做法是通过虚拟网桥来桥接虚拟网卡。下面具体解释一下。 首先每一个容器在默认情况下都是在自己的network namespace里面的，也就是说默认情况下它只有一个自己独立的localhost网络(或者是什么网络设备也没有？TBD)，无法与外部进行通信。为了解决这个问题，Docker创建了一对veth pair, 这个veth pair总是承兑出现，可以理解为一对端口，所有从一头进去的数据都会从另一头出来。然后docker 会把这对veth pair的一头加入到容器的namespace中，另一头桥接到一个虚拟网桥上， 这个虚拟网桥实际上就是宿主机上的docker0网卡，我们可以通过以下指令来观察： [wlh@meizu storage]$ brctl show bridge name bridge id STP enabled interfaces docker0 8000.02422551422b no veth43dc241 　　　　　　　　

docker 网络 : bridge 自连网络名称空间 joined 与另外容器共享使用网络名称空间 open 容器直接共享宿主机的网络名称空间 none 不使用任何网络名称空间 k8s 网络通信模型 容器间网络通信 : 同一个 pod 内的多个容器间的通信 ,lo pod 间通信 : pod ip <--> pod ip 直连 pod 与 service 通信 pod ip <--> clusterip iptables 实现 service 与集群外部客户端的通信 nodeport ingress loadblance 实现 CNI 容器网络接口 flannel 仅支持地址分配 calico 支持地址分配 也支持网络策略 canal flannel+calico kube-router 解决方案 : 虚拟网桥 多路复用： MacVLAN 硬件交换： SR-IOR 虚拟出多个硬件网卡 名称空间隔离的是权限，不会隔离网络， pod 与 pod 之间网络的隔离要用网络策略实现 flannel 不支持网络策略 网络插件使用 : kubelet /etc/cni/net.d/*** 比如 kubelet /etc/cni/net.d/10-flannel.conflist --help flannel 网络 默认 vxlan 作为后端传输机制 1. 原生 vxlan overray

neutron 介绍： Neutron 概述 传统的网络管理方式很大程度上依赖于管理员手工配置和维护各种网络硬件设备；而云环境下的网络已经变得非常复杂，特别是在多租户场景里，用户随时都可能需要创建、修改和删除网络，网络的连通性和隔离不已经太可能通过手工配置来保证了。 如何快速响应业务的需求对网络管理提出了更高的要求。传统的网络管理方式已经很难胜任这项工作，而“软件定义网络（software-defined networking, SDN）”所具有的灵活性和自动化优势使其成为云时代网络管理的主流。 Neutron 的设计目标是实现“网络即服务（Networking as a Service）”。为了达到这一目标，在设计上遵循了基于 SDN 实现网络虚拟化的原则，在实现上充分利用了 Linux 系统上的各种网络相关的技术。 SDN 模式服务— NeutronSDN( 软件定义网络 ), 通过使用它，网络管理员和云计算操作员可以通过程序来动态定义虚拟网络设备。Openstack 网络中的 SDN 组件就是 Quantum.但因为版权问题而改名为Neutron 。 Neutron网络基本概念 （1）neutwork network 是一个隔离的二层广播域。Neutron 支持多种类型的 network，包括 local, flat, VLAN, VxLAN 和 GRE。 local

和三层外面再套三层的GRE不同，VXLAN则是从二层外面就套了一个VXLAN的头，这里面包含的VXLAN ID为24位，也够用了。在VXLAN头外面还封装了 UDP、IP，以及外层的MAC头 VXLAN作为扩展性协议，也需要一个地方对VXLAN的包进行 封装 和 解封装 ，实现这个功能的点称为 VTEP （VXLAN Tunnel Endpoint）。 VTEP相当于虚拟机网络的管家。每台物理机上都可以有一个VTEP。每个虚拟机启动的时候，都需要向这个VTEP管家注册，每个VTEP都知道自己上面注册了多少个虚拟机。当虚拟机要跨VTEP进行通信的时候，需要通过VTEP代理进行，由VTEP进行包的封装和解封装。 和GRE端到端的隧道不同，VXLAN不是点对点的，而是支持通过组播的来定位目标机器的，而非一定是这一端发出，另一端接收。当一个VTEP启动的时候，它们都需要通过IGMP协议。加入一个组播组，就像加入一个邮件列表，或者加入一个微信群一样，所有发到这个邮件列表里面的邮件，或者发送到微信群里面的消息，大家都能收到。而当每个物理机上的虚拟机启动之后，VTEP就知道，有一个新的VM上线了，它归我管。 虚拟机1、2、3属于云中同一个用户的虚拟机，因而需要分配相同的VXLAN ID=101。在云的界面上，就可以知道它们的IP地址，于是可以在虚拟机1上ping虚拟机2。 虚拟机1发现

网络拓扑图： SPINE1配置 ====================================================== hostname SPINE-1 nv overlay e*** feature ospf feature bgp feature pim feature nv overlay ip pim rp-address 192.168.1.8 group-list 239.0.0.0/24 ip pim log-neighbor-changes ip pim ssm range 232.0.0.0/8 ip pim anycast-rp 192.168.1.8 192.168.1.1 ip pim anycast-rp 192.168.1.8 192.168.1.2 vrf context management interface Ethernet1/1 no switchport ip address 10.10.1.1/30 ip ospf network point-to-point ip router ospf 100 area 0.0.0.0 ip pim sparse-mode no shutdown interface Ethernet1/2 no switchport ip address 10.10.3.1/30 ip ospf