vxlan是udp 封装的，那么可靠性如何解决？
作者: 元首
这个问题主要看问的是什么视角：
1.如果单纯用tcp、udp的原生特性去评价，TCP有丢包重传，UDP没有，那么OK。这个可以说是VXLAN的问题，当你的包在VXLAN domain丢了，那就是丢了，但是，这只是underlay的事情，你的overlay可能是TCP based，所以对于client来说，我依旧能去使用TCP 重传去触发服务器给我重新建立连接。
2.你会发现现在的VXLAN的解决方案都是厂家给你大盒子整CLOS拓扑，然后都是高速接口链路（如40G，甚至100G），那么按照这个设计逻辑来说，可以简单认为成，这个fabric是不会丢包的，如果你一定要说，OK，万一丢包呢，咋办？你丢包无非就是性能不够或者设备不够，那你加呗。spine-leaf横向做加法，没了。
3.厂家针对他自己的盒子ASIC都是硬解VXLAN UDP header并且有ECMP作为辅助，说人话就是，理论上，多个leaf和多个spine之间在ECMP过程中流量是分摊的（这个分摊就是用VXLAN UDP header的 source port），并不会达到链路满载出现拥塞问题。
4.因为本身tunnel这个东西，技术很多，用现在主流的VXLAN，NVGRE, IPSEC GRE IPIP 等等，你会发现，能提出这个问题的场景也就是DC，那么运营商咋办？运营商的SP MPLS网络怎么负载分担？你可能会说，那IGP做个普通的邻居，ECMP之后加个LDP分label。然后表就是负载的啊？那为啥还问负载的问题？？主要来说，上面描述的仅仅是控制平面的事情，对于数据平面来说，这个并不是真正意义的负载？那么为啥这么说？很简单。还是回归到hash的问题。我们一般情况下说的负载hash是base在L3 IP L4 port。那么MPLS呢？？这可是不是L3 L4的东西，所以你在路由表里看到的负载分担仅仅是控制平面的，数据平面真跑起来可不一定是你想的那样子的。那么解决办法是啥？
4.1，在运营商的盒子（PE,P）开DPI功能，让设备去检查包的里面
4.2，使用entropy label或者FAT label
简单说啥意思。如果你开DPI的话，你会让设备很累，因为DPI是看包的里面，需要用到CPU的资源，所以这个不作为考量， 厂家也不会推荐你这么做，（我们讨论的是运营商的盒子哦，这流量超大，设备分分钟因为你开DPI累死）
那么entropy label和fat label意思很简单，在transport label和service label中间在加个label，专门做hash用，至于说entropy和fat算是RFC的两个标准，entropy是L2VPN L3VPN都可以，fat label是L2VPN only。
那么你可能会问，卧槽，有TM的加label。这包得多长？这还有效率么？OK，这个问题只能用厂家物理硬件做硬解去解释了。
因为这么多年，你看网络本身就是在加头部和物理硬件之间去游荡，所以结论就是，硬件如果牛逼，在长的包也没问题。
举个例子，就单纯说MPLS就行。SRTE的包有多长？经过一跳。加个label。cisco ASR的设备都会告诉你这个硬件本身最大支持多少个MPLS LABEL stack。这不很奇怪么？为毛SR理论上应该是比LDP RSVP牛逼的产物，会在包长度上这么反直觉？答案：故意的！ 当你说优点的时候，什么所谓的简化控制平面，OSPF ISIS也能分label等等等的说辞，听起来很不错，但实际情况是，包变长了。也就中了厂家的圈套，这就是他们想看到的。因为啥？只有我的硬件（ASIC）能处理。
那么, SRV6呢？这个能解决包太长的问题么？？
很遗憾。不能。甚至包会更长。为啥？？
因为在SRV6的世界里没MPLS什么事，所有的encoding都是在IPV6的packet里呈现的。说人话，就是在IPV6追加extension header去解释PE p在哪里，这个叫做location function，也叫所谓的segment routing header。OK，这多长？？你自己想想。。128bit V6 vs 32bit MPLS STACK，效率问题？？OK，厂商说了。。我的芯片多牛逼多牛逼。没效率问题。。
所以结论是啥呢？？
很遗憾，没什么结论，包长度的效率问题是硬件解决的。可靠性问题是不让你的网络出现丢包和拥塞，当你分得说极限环境等等等。那你就拿硬件本身说事就行了。