前言
试想一个场景，云上北京的一台机器要访问广州的 站（可能在当地公 ，也可能在同一朵云的广州节点上），这个 文的生命周期会是什么样，它究竟会如何跨越万水千山达到目的地？旅途中又会经过哪些不同种类设备，这些设备都对 文做哪些修改，为何做这些修改，为什么需要这么设计？
而随着目的地的不同，通信场景的不同， 文的旅途具体可以抽象出哪几类，每一种场景里具体要做哪些设计考虑，需要解决哪些关键问题。对于从事云计算或通信行业的人来说，我想这样的问题或多或少有思考过，尤其对于长期从事传统 络而对云的这种Overlay 络知晓相对不是很多的读者，我想对于这样的一系列问题心中很可能有所疑惑和一定好奇。
另外，在处理云上疑难问题时，经常会碰到全链路问题，访问路径复杂，会经过很多台设备（包括CDN、安全设备、各类 络设备、各类 关、虚机内容器节点，甚至多云互联等），不同设备经常对 文做修改，以及云计算技术本身的抽象性（提供给用户的界面和操作很简单，但底层的层层封装和设计考虑往往很复杂），这些共同原因导致很多全链路问题处理起来比较耗时。
整体上看，如果对一个IP 文在云上的整个旅途有一种完整的全链路视角，带着这样的视角剖析云上各种场景的IP 文之旅，将旅途完完整整的展示出来，不仅能加深对云 络技术、产品和通信的理解，也会很大程度协助排查云上的诸多复杂全链路问题。
具体来说，IP 文在云上的旅途包括非常多场景：例如同地域VPC内及VPC之间，访问公 （Public IP/EIP/NAT），通过专线访问线下IDC等混合云场景，访问云服务场景，访问SLB/ALB场景，CEN TR场景，云防火墙&CEN TR结合场景，容器 络场景等等。
下图为阿里云 络产品体系架构，可以通过此对阿里云主要云 络产品的总体分类有个基本认识，以及对一个 文跨越机房转发的轨迹有个大致的画面。
场景一：同VPC，同VSW
2.1 背景介绍
图中的源ECS（云服务器）和目的ECS是属于同一VPC（虚拟专用 ）且同VSW（虚拟交换机）。因为是同一虚拟交换机，所以肯定是在同一可用区（同一IDC机房）内。
然后ECS互相ping对方，比如左边192.168.255.176 ping 192.168.255.169.
我们一起看下这中间，流量从起始后经过的每台Overlay节点设备需要查看的转发表项和实际抓包 文细节。分为路由层面和转发层面来看，先看路由层面。
2.2 路由层面
? 阿里云 络通信
在查看表项之前先看下面的两张图：
首先，阿里云 络是一张非常庞大的Overlay 络，云上端到端的通信都是Overlay通信，需要特别关注VPC的tunnel-id，VPC的路由表等。而每个VPC都有一个唯一的tunnel-id。VPC的路由表默认会包括所属每个虚拟交换机的 段，以及云服务地址 段。
如下图所示，阿里云上 络通信的一个基本原则就是相同tunnel-id（相同VPC）的流量默认可以通信，不同tunnel-id（不同VPC）的流量默认不能通信。这也是阿里云为了做到不同用户业务完全隔离的基本技术手段。当然，相同VPC内的流量也可以通过比如 络ACL、安全组等手段来限制通信，不同VPC的流量也可以通过建立对等连接、加入云企业 CEN等手段来实现互通。
? 源ECS 路由表项
文从源ECS发出去，需要查看路由表，上面是源ECS路由表项，可以看到源ECS上只有一条默认路由，指向192.168.255.253这个 关地址，那这个是什么地址？
这其实是个虚地址，可以大致理解为阿里虚拟转发交换机vSwitch上的地址，所以下一跳需要查看这台vSwitch的相关表项。
这里的虚拟转发交换机和VPC配置中的交换机含义不同，前者为一套庞大软件组件，需要完成非常多核心转发功能，而后者其实并不存在具体对应的某个交换机被云实例所挂，只是VPC管控层面为云实例自动分配的一个属性，一个交换机一个 段，这样可以便于用户从high-level层面进行 段规划，业务规划和组 设计等。
? 阿里虚拟转发交换机vSwitch（也常称AVS）
首先它是阿里自研虚拟交换机（可类比OVS），以软件形态在物理服务器内部署，承担Overlay的封装/解封装、ECS安全组、路由表项查找、bps/pps等指标跟踪、session维护等等非常多的重要功能。它是服务器内部 络的核心组件，整体负责服务器内部ECS流量的转发和交换。如下图所示，存在Slowpath和Fastpath。
1）Slowpath：基于route/ACL和业务逻辑决定转发行为，首包需要走Slowpath
2）Fastpath：基于Slowpath生成的session做match/action，有session之后直接走Fastpath转发非常高效
? 阿里vSwitch（AVS）表项简要介绍
如下图所示，在物理机内每台ECS的每个 卡会连接到AVS上的一个虚拟接口（接口名和ECS 卡的mac地址有映射关系）， 文到达AVS后，会在AVS内部依次查找多个表项，在不考虑配置多路由表/子 路由（类似策略路由，可根据源地址段做转换）的情况下，一般来说，主要会查看路由表、VTEP映射表。接下来简要说下各自的用途：
1）表1 路由表，根据tunenl-id来查找，也就是说这上面包含有多个VPC的路由表，那么一台AVS有多少tunnel-id的VPC路由表，实际上包括该物理机上所有ECS所属的VPC以及他们通过其他手段学习到的其他VPC的路由表。对于本VPC所属的交换机 段地址，这些VPC路由的下一跳为0.0.0.0，即继续查找表2。
2）表2 VTEP映射表，存放着要去往的目的地址所对应的物理机地址，用于做Overlay封装使用。最开始，这里面并没有表项，但是通信第一次之后，会通过VPC Gateway学习到目的地所对应的物理机地址。
如下图，包括所有路由表、安全组等非常多的信息都是通过VPC管控进行下发，必要时也会和ECS管控、云企业 CEN管控等其他控制器进行联合工作。如前面所说，云 络是一种非常庞大的Overlay 络，上层有各个产品的控制器进行管控，充分利用SDN思想的核心优势，让设备配置、表项、路由表等等信息的下发变得更加灵活，同时也得以支持超大规模云 络。
? 场景一整体通信过程梳理
当源ECS把包发给所在物理机的AVS后，AVS查看表项，先查路由表，下一跳为0.0.0.0，接着查表2。如果已经通信过一次，那么表2会有目的ECS与其物理机地址的映射关系。然后开始封装Overlay 文，内层源目的为私 ip，外层的源地址为本物理机地址，目的地址为目的物理机地址。如果没通信过，会先通过VPC Gateway进行学习映射表。
当物理机里的vSwitch收到 文后，根据 文里的tunnel-id查找相关VPC-id的表项（此场景下与目的ECS属于同一VPC），因为目的地址是该VPC的交换机 段地址，所以下一跳也为0.0.0.0，接着同样是查看VTEP映射关系表，由于目的地址为本AVS的虚拟接口所连接的ECS，所以表项里会对于目的地址为这样地址的下一跳设为该虚拟接口，从该虚拟接口转发给目的ECS。
? 回包路程
原理一模一样，例如目的ECS的路由表项，和源ECS非常类似，也是通过默认路由发给.253的地址。然后一路返回同样采用Overlay技术封装，由本物理机地址直接发送到源物理机地址。
2.3 转发层面
? 源ECS&目的ECS抓包
注意ip.id 20953，标识这个 文，后续抓包通过这个id来说明是同一个 文。
? 源ECS连接的物理机内vSwitch抓包
可以看到原始 文包在里面，外面是一层Overlay封装，最外面是外层源目的ip地址，为源物理机地址–>目的物理机地址，tunnel-id为源ECS所属的VPC tunnel-id 504301.
根据ip.id可以和ECS上抓的包对应起来，是同一个 文。
? 目的ECS连接的物理机内vSwitch抓包
通过时间，内层ip.id，外层ip.id都可以看出这个包就是上面源vSwitch发出的包。
通过四个点的同时抓包可以看到， 文的走向和表项分析的路径一样：源ECS-源AVS-物理机1–物理机2-目的AVS-目的ECS。
2.4 通信路径总结
简单来说，对于同VPC，同VSW，逻辑通信路径是：ECS1 → 源AVS → 源物理机 → (VPC Gateway) → 目的物理机 → 目的AVS → ECS2。
对于物理通信路径，因为源和目的属于同一可用区/机房，流量直接在机房内进行转发，也就是近年流行的3层CLOS架构。
另外，为何封装了外层目的地址物理机地址后，物理 络就知道怎么转发，原因是物理机地址段都已通告在underlay 络，所以underlay 络知道如何转发到相应物理机地址。
所以其实不管底层物理 络跳数有多少，从上层来看，非首包是一跳到位，直接从源物理机发到目的物理机，对于首包来说则是两跳，中间要经过VPC 关设备。所以这也是在尽可能简化通信，减小通信复杂度，只是这其中各种表项的定义和学习同步需要精心设计。
场景二：同VPC，不同VSW
3.1 背景介绍
场景二里的源ECS和目的ECS属于同一VPC，但属于不同虚拟交换机，即处于不同细分 段中，在这里同时处于不同可用区/机房。
3.2 路由层面
1）从Overlay层面和查看表项层面，其实这种场景和场景一非常类似，原因在于AVS上的表1路由表里会有VPC管控自动下发的本VPC里所有交换机的地址 段路由，下一跳都指向0.0.0.0，也就是表2. 所以源和目的AVS在查表1的时候都是直接指向表2，然后根据表2的表项内容进行封装和转发。
2）区别在于这两种场景的物理通信路径不一样（如果属于不同VSW同时也属于不同可用区的话），因为源和目的是不同可用区，就会多经过一个专用的连接不同可用区做内 通信的 络设备，加上每个可用区机房都要经过一次3层CLOS架构的设备，整体物理跳数会更多，延时相应的也会更大。
3.3 转发层面
下面通过几个节点的抓包来验证通信路径是否如上述分析一样：
? 源ECS抓包
注意锁定这里的ip.id 36495
? 源ECS连接的源AVS抓包
注意ip.id 36495，可以看到同样是和场景一一样，外面包一层Overlay封装，外层源目的IP是本物理机地址 → 目的物理机地址。
? 目的ECS连接的AVS上抓包
注意ip.id 36495，可以看到这就是上面那个包。
目的AVS拆掉Overlay封装，把里层的 文发给虚拟接口所连接的ECS（根据内层目的IP地址可进行路由找到出接口是连接目的ECS的虚拟接口）。
? 目的ECS上抓包
3.4 通信路径总结
1）和场景一类似，也是首包过VPC Gateway，对于非首包，直接从源物理机到目的物理机进行Overlay封装，并没有额外步骤。
具体来说，路径也是为 ECS1 → 源AVS → 源物理机 → (VPC Gateway) → 目的物理机—目的AVS → ECS2。
2）所以只要是同一VPC内通信，不管是不是处于同一VSW虚拟交换机，是不是同一可用区，底层逻辑通信和封装结构并没有明显区别。当然，物理通信路径会多经过一些跳数（如果不同可用区），延时会更大一点。
场景三：不同VPC，同地域
4.1 背景介绍
这里的ECS1和ECS2是同地域的不同VPC，一般来说，可以通过对等连接/VPC互联，CEN1.0、CEN2.0/CEN TR这三种方式进行通信。
前两种方式的底层通信路径比较类似，所以这里直接选用采取CEN1.0的方式互通进行剖析。
4.2 路由层面
? 源ECS路由表项
和场景一类似，到达目的地172.16.7.98会通过默认路由送往.253地址。
? 目的ECS路由表项
同样和场景一类似：
? 源vSwitch/AVS表项
1）首先也是查看表1路由表；
2）在这里就和前两种场景不同，此时的目的地址段不是源VPC里的交换机 段地址，而是另一个VPC的地址段，那么它是否会出现在源vSwitch的路由表里？
这就要看源VPC是否有学习到目的VPC的路由表，学习方式一般有对等连接、CEN1.0、CEN 2.0 TR。对等连接方式需要手动在两边的VPC路由表里添加到对端 段的路由，CEN方式会自动进行学习（只要源目的VPC加入同一个CEN）。
那么这里，是采用CEN1.0方式学习，所以源VPC的路由表里会出现对端VPC 段地址，下一跳为对端VPC的tunnel-id，非常关键，在这个场景里为371185（源VPC tunnel-id为504301）；
3）查到下一跳为对端VPC的tunnel-id后， 文会交给CEN 关（VPC Gateway），Gateway会转发给目的物理机；
4）同理可以推断，目的AVS上的表项回包到源ECS地址，路由表里下一跳是源VPC的tunnel-id 504301，也是发给 关Gateway。
4.3 转发层面
? 源ECS上抓包
锁定ip.id 17001
? 源vSwitch上抓包
因为这非首包，所以外层目的地址直接为目的物理机地址 11.246.47.134
要特别注意，源AVS发出去的包里的tunnel-id为371185，而并非504301，也就是说源vSwitch发出去的包，第一步直接就把tunnel-id置为对端VPC的tunnel-id。
? 目的vSwitch上抓包
根据ip.id 可以和前面的包完全对上，外层源目的IP地址为源物理机地址 → 目的物理机地址。
? 目的ECS抓包
目的ECS收到的是目的vSwitch解掉Overlay封装后的 文，ip.id可以对上。
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！