TR转发路由器测评

开始

本文分 4 个部分

1，测试环境准备

2，场景测试

3，建议反馈

4，总结

前言

转发路由器 Transit Router（简称“TR”）是云企业网CEN下的一款转发网元，通过TR可以实现云与云或者云与本地的网络互通，甚至打造一张企业多地域互通的网络，并能进行相应的网络路由、流量策略管理。

早些年前，公司业务分布在上海阿里金融云 和上海华x云上，同时部分业务在杭州IDC机房里。为了打通两边VPC，用了高速通道，将阿里云和华x云打通，再将阿里云和机房打通，不过无法将三个节点融入到一个网中，因为高速通道只支持单点连接，且配置很麻烦，路由管理上也只能手动去配置。这次了解到云企业网CEN 可以帮企业快速构建阿里云多端多点网络甚至是混合云的服务，其核心能力就是转发路由器TR了。现在跟随我一起来测评下吧。

一，测试环境准备

测试目标

阿里云下创建 杭州， 北京 ，河源 3个 region的VPC实例。

具体测试场景期望为：

1，3个VPC之间的ECS及云资源 实现内网网络互通。

2，3个VPC之间的通过SLB 内网实现业务正常访问。

3，3个VPC之间 实现OSS 内网数据操作。

4，3个VPC之间 实现SLS 内网日志数据加工复制。

现在我们搭建下环境看看能否实现。

VPC资源需求规划

切记 3 个VPC要分属不同的网段。

（此处交换机创建了3个不同的zone，本打算做些其它测试，因存在部分重复内容，顾作罢）

基础环境准备

准备好VPC资源规划后，开始创建云企业网和转发路由器

不过先领取下TR试用福利

创建CEN实例

下面对多个VPC 环境进行配置

VPC-杭州-1

杭州VPC 之前有创建过，这里直接创建VSwitch即可。

创建转发路由器-杭州

TR-hangzhou 创建完成

创建ECS，进行后面的场景测试

VPC-北京-2

创建VPC实例

创建 VSwitch 3个，且为不同区域

3个不同区域的交换机和命名方式。

创建转发路由器-北京

创建ECS

VPC-河源-3

创建VPC实例

创建 VSwitch 3个，且为不同区域（此处河源节点zone 区域只有A、B）

创建转发路由器-河源

创建ECS

创建跨地域连接

因为此处测试的是多地域网络互通，所以必须使用跨地域连接方式打通。

入口就在cen下 的带宽包管理的设置跨地域带宽下。

打通 杭州-河源

创建名为“CONN-杭州-河源”的跨地域连接

创建完后，就可以对河源和杭州的ECS进行ICMP协议测试，测试结果为互通。（注意安全组要放开ICMP协议）

河源配置打通-杭州 OSS VPC访问

我们要在河源访问杭州的VPC 云资源，必须打通路由。

比如河源访问杭州 Endpoint vpc地址 oss-cn-hangzhou-internal.aliyuncs.com，默认是不通的，上面只是ECS层面自动同步了路由。

操作步骤：

1，在河源TR连接中的转发路由器路由表添加 OSS 杭州Endpoint  VPC 网络的 CIDR 地址100.118.28.0/24的路由。

下一跳选 河源TR方式

2，杭州添加vpc地址

杭州TR的转发路由器路由表中添加路由 100.118.28.0/24

下一跳 选择vpc类型

3，在河源VPC 路由表中添加 杭州 OSS VPC地址。

此处内网地址为 100.118.28.0/24 ，类似CIDR地址也许会存在变动。

测试杭州的OSS VPC地址，已经打通。

河源配置打通-杭州 SLS VPC

类似打通杭州的 SLS VPC endpoint 地址

1，在河源 VPC 配置 路由 地址100.100.142.0/24

2，杭州添加vpc地址

100.100.142.0/24

下一跳 选择vpc类型

3,在河源添加cidr地址100.100.142.0/24

下一跳选 河源TR方式

打通 杭州-北京

创建名为“CONN-杭州-北京”的跨地域连接

创建完成后，北京和杭州VPC地域已经打通网络。

我们测试2个VPC的ECS 都能互相ping通（注意安全组要放开ICMP协议）

北京配置打通-杭州 OSS VPC访问

参照 打通河源到杭州OSS VPC资源访问流程，1，2，3步。

其实1，2步不用操作，路由会自己学习同步（同步策略我没打开，也会延迟自动同步？）

但北京VPC侧 需要添加 OSS 杭州 VPC路由地址。

操作完毕后访问杭州OSS VPC地址通了。

打通 北京-河源

创建名为“CONN-北京-河源”的跨地域连接

创建后，两地ECS 互相访问畅通。

因为北京和河源 之间暂时 不需要对云资源进行访问，就不做路由添加了。

CEN控制界面概览

打通效果：创建的3个转发路由TR，以及跨地域连接信息。

资源拓扑图，我们创建的3个 转发路由器TR关联到cen中，点开region，能进一步看到更多资源信息。

网络拓扑：对我们以上3个region关联的拓扑一目了然。

路径分析：使用路径分析功能诊断资源之间的网络连通性。

比如测试下 检测河源和目的资源杭州的网络连通性，类似路由跟踪，不过此处明显更直观。

用户选择源和目的资源创建路径后，即可获得路径是否可达的结果及原因

监控：对当前网络互通和资源使用率进行了监控。

二，场景测试

1，3个VPC之间的ECS及云资源访问 实现网络互通

ECS 地址如下：

杭州 172.16.101.29

北京 192.168.1.246

河源 10.10.1.25

转发路由器TR 没关联前 网络是不通的。

添加跨地域连接，打通后：

某地互相访问 另两地的ECS 地址 ，都没有问题，测试结果通过。

OSS 打通

需求是杭州 OSS 作为主实例，北京和河源访问杭州 VPC OSS地址：oss-cn-hangzhou-internal.aliyuncs.com

测试结果通过。

SLS 打通

需求是杭州 SLS作为主实例，北京和河源都需要访问杭州 VPC SLS地址：cn-hangzhou-intranet.log.aliyuncs.com

测试通过。北京和河源 都能访问到杭州SLS VPC地址

测试结果通过。

2，3个VPC之间 实现OSS内网数据操作

在ECS上静态挂载一个OSS

此处使用 ossfs 挂载到目录，可参考https://help.aliyun.com/zh/oss/developer-reference/ossfs-installation

在华东1 创建bucket：nginx-web-test-dir

再创建目录，分别用作3个region的资源读写。

nginx-hz

nginx-bj

nginx-hy

使用ossfs 挂载OSS成功

分别挂载其它2台ECS，有了以上路由打通后，异地挂载也很顺利。

测试结果通过。

3，3个VPC之间的通过SLB实现业务正常访问

需求：外网访问分布在3个地域的共同资源。

规划 ：杭州 华东1 创建SLB 内网，绑定弹性IP。分别在 3地，创建nginx服务。

原本以为杭州SLB能遍历到北京和河源的ECS，结果不行，只能通过在杭州ECS做WEB代理，跳板到另外两地的web服务器上。

操作：

ECS 安装配置nginx，以及挂载好OSS目录。

为方便及规范部署，使用镜像克隆下杭州ECS系统，直接复制部署到北京和河源。

复制镜像

此处使用杭州地区做web proxy。

通过一个SLB 访问三地的nginx服务，需要做个proxy。

配置如下

SLB创建

杭州创建个 SLB，为私网，使用弹性EIP，作为公网输出。

配置杭州 nginx 8080服务

启动 3地的各自nginx

访问 SLB地址，可以看到会代理到不同的地域nginx服务上。

测试结果通过。

4，3个VPC之间 实现SLS 内网日志数据加工复制

为观察访问日志更加方便，以及日志后期的分析用途，我们将以上3 地的日志都采集到各自region的SLS logstore里，再通过数据加工将 3 地的 logstore数据 同步到杭州project。

先创建好 3 地的3个project。

分别创建 logstore

accesslog-nginx-hz

accesslog-nginx-bj

accesslog-nginx-hy

杭州地区日志设置收集成功。

其它地域依次配置。

SLS 整体都能获取到 各自地域的nginx access log

开始操作数据加工复制。

无奈不能走VPC地址，这步无法走通。

只能尝试在杭州project 分别创建多个地域的logstore，统一收集到一个Project下。

但SLS 侧走 VPC 内网不通。

使用 VPC网络方式，采集收集到一端的需求不能走通。大概是SLS侧无法反向识别我们多地域的内网 ECS路由。当然这并不一定是TR转发路由前的问题。

三，建议反馈

1，创建跨地域连接后返回界面没有数据

创建完 TR跨地域连接后

点击返回列表，找不到 跨地域带宽 入口。

只能从TR实例里 再找到跨地域连接管理去找到刚才创建的信息。

建议创建入口和展示入口统一。

2，转发路由器器路由表添加CIDR地址体验不太友好

目的地址CIDR 默认灰选，不打开，只有先选择最后的子网掩码后，才能编辑前面的主机地址。

从体验上 感觉不太习惯，建议全部放开，或者用户自定义输入。

3，自动同步学习路由表问题

两地创建跨地域连接后，同步自动学习和主动静态配置有冲突。

比如河源和杭州创建跨地域连接后，

河源地域 自动学习 杭州VPC 路由地址，大概10分钟左右才同步完，且默认没有打开路由同步（见下图）。

手动配置静态路由后，自动学习的路由显示拒绝。

杭州配置的源路由地址。

所有转发路由器都未开启路由同步

建议优化自动同步策略。

4，TR转发器内路由表设置不合理

一个Region地域有几十，甚至上百种云资源。

一个云产品资源 有可能存在多个 内网的 CIDR 地址。

以上我只是测试，加了一个杭州OSS内网网段 100.118.28.0/24。

在生产中，如果需要在CEN网中 关联全部端的 云资源路由，不太可能在转发路由器TR中这样手动维护多个配置点。

希望TR产品考虑下，如何解决用户这种全网VPC互通场景。

四、总结

上文测试的 4 个目标，我们实现了3/4，结果虽然不完美(不完全是TR转发器的问题)，但还是有惊喜的：

测试中发现，云企业网和TR方式组网简单，开通即用，全网实现多点，多级路由的自动分发与学习，也可以管控路由。其次，按需付费，按量付费， 相对于传统组网一次性的专线大投入而言，更加亲民。最后，易于运维，CEN下提供的可视化网络拓扑，路由分析，资源监控功能让人印象深刻，可以帮助我们迅速掌握全网运行状态，提高网络运维效率。

有了CEN和转发路由器TR，我们能快速搭建多地域专有网络互联、本地数据中心和专有网络互联等多种上云方式下的网络互联的需求。正如我开头说的，早些年只能对混合云或者VPC间做单点互联，且配置麻烦。有些更传统的网络搭建方式，使用物理专线互联，搭建和沟通成本巨大，且费用高昂。当时面临着组网复杂、成本高、无弹性、管理繁琐等问题。现在阿里云CEN和TR方式，能快速搭建云上网络，提供优质、高效、稳定的网络传输环境。实为一大幸事。

但也有些许遗憾，比如上面所说的使用TR跨地域连接打通多个VPC实例后，无法直接访问内网资源，添加路由表和路由条目的方式，门槛比较高，且相对复杂。还有多点组网后需要精细化的流量管理和防护策略。

总体看，CEN和TR路由转发方案给我们面对业务快速发展提供了更多网络架构层应变的能力。面向多业务场景的部署，访问加速，打通数据，构建中台和数据中心，不同地域容灾备份等。

相信这次测评只是个开始，我们共同期待CEN和TR的蜕变吧。