最近看到老东家发布了一篇很有意思的文章：Building an SRv6 uSID Data Center Fabric with SONiC，使用Sonic 构建基于SRv6 Fabric的DC架构。SRv6一般常用于骨干网和DCI，并且需要依托于BGP -> IGP迭代。其实之前在考虑城域网架构时，就思考过是否可以利用SRv6的高级特性，根据业务需求分割两个平面进行独立承载，但设备厂商提供的解决方案都是依托于IGP，而非Only BGP环境。最近阿里云在一些场合发布他们新的Peering架构ePF时提到过SRv6 only BGP，再结合这篇文章，没想到提前在Sonic Switch上先实现了，真的让人惊讶与开源社区的迭代速度。

这篇文章主要尝试下Sonic Switch，记录遇到的问题及解决方法。并测试SRv6实现到了什么程度，是否可以直接替代现有BGP Only的DC架构。PS：全部实验均是通过PNET搭建并验证，Sonic版本是从上面 那篇文章中下载的，基于202305版本，相关配置命令可以看那篇文章提到的github，以及FRR和Sonic的官方文档，为了方便，我列到了下面：

• https://github.com/segmentrouting/srv6-labs/tree/main/sonic-vs
• http://docs.frrouting.org/en/latest/zebra.html?highlight=json
• https://github.com/sonic-net/SONiC/blob/master/doc/srv6/srv6_hld.md

拓扑环境

      Ethernet0┌─────────┐Ethernet1
     ┌─────────┤   L2    ├──────────┐
     │         └─────────┘          │
     │Ethernet2                     │Ethernet2
┌────┴────┐                    ┌────┴────┐
│ POD1-L1 │                    │ POD2-L1 │
└────┬────┘                    └────┬────┘
     │Ethernet1                     │Ethernet1
     │                              │
     │Ethernet1                     │Ethernet1
┌────┴────┐                    ┌────┴────┐
│ POD1-L0 │                    │ POD2-L0 │
└────┬────┘                    └────┬────┘
     │Ethernet2                     │Ethernet2
     │                              │
     │eth2                          │eth0
 ┌───┴───┐                       ┌──┴────┐
 │  S1   │                       │  S2   │
 │ Server│                       │ Server│
 └───────┘                       └───────┘

注意：

背景

EVE NG的订阅费又涨了，记得2021年还在犹豫要不要在黑五下单1年的pro版本（如果没记错，应该是600多），现在已经1000多了，我就很无语……1000多为啥不买思科的VIRL……，对于我们这种个人付费的用户来说，着实有些贵了。之前朋友一直安利PNET，这回正好尝试下。

区别

其实我到现在也没弄明白PNET和EVE NG的关系，对于使用感受来说，PNET ≈ EVE NG Pro + 一些新功能（比如支持不关闭仿真设备直接变更连线，类似VIRL2），但PNET又不具备一些EVE的高级功能，如集群部署。可是为什么EVE 可以允许PNET免费开放这么多pro的功能？暂时就没有追述原因了；

EVE NG Community的使用问题

• 我的使用环境是隔离的Lab环境，无法连接外网，访问EVE NG Comunity的GUI，感觉会非常慢，开始我一直觉得是跳板机性能不行，但后来发现不是，就像有些进程一直在尝试联网但导致了超时，从而影响了体验；
• 现在新增仿真设备时，图标总是启动状态，导致无法编辑，必须连续启动好几个，找没有启动的图标……这个真的很烦人，跟朋友讨论后，应该是一个EVE 的Bug……
• EVE NG有很多好用的功能是不包含在Community中的，比如配置保存（有些仿真设备是不支持的）等，这些其实挺影响使用的；

Background

实验环境打算用trex打流，然后用下面环境测试cable，但物理server配置好路由后，发现只能收路由，不转发流量，我们确认已经开启了ipv4转发的指令，路由也是正常的，但就是不work，所以我在EVE NG的环境上搭了一个类似的环境，确认下是否是trex本身的问题；

# sysctl -a |grep net.ipv4.conf.all.forwarding
net.ipv4.conf.all.forwarding = 1

对于trex内容，请看我之前的相关文章：http://www.zhaocs.info/tag/trex；

服务交付架构

Dubbo是基于java开发的，是一个分布式微服务框架（服务调用），如果没有分布式需求，是不需要Dubbo的。

• Registry：不管是消费者还是提供者，都需要联系注册中心，只是提供者是注册，而消费者是订阅；
• Consumer：通过RPC调用Provider提供的方法（如下图的invoke），就像调用本地方法一样；
• Monitor：监控消费者和提供者的信息；

• 开发会把代码托管到Git上，进行代码托管，以及版本管理；
• 运维会通过工具（这里是Jenkins）从Git上拉代码，并编译代码打包成Docker镜像，上传到Harbor数据库中；
• 运维再通过k8s的资源配置清单，应用到K8s集群中，把服务生成Pod并提供服务；
• Pod利用Dubbo微服务自动去注册中心注册（ZK，ZooKeeper，类似ETCD），这里的ZK同ETCD一样，不会部署在K8s内，因为是有状态服务；
• Dubbo微服务的提供者集群和消费者集群部署在K8s中，方便利用K8s的机制并根据实际情况进行灵活的扩容/缩容；
• 用户通过Ingress规则，找到相应消费者集群，完成服务互动；

这里只介绍如何部署Dashboard，至于使用方法，会在之前的文章：K8s – Core Resource Management Method GUI部分进行总结；

安装部署Dashboard

上传Dashboard的Image

root@f0-15:~# docker pull docker.io/k8scn/kubernetes-dashboard-amd64:v1.8.3
v1.8.3: Pulling from k8scn/kubernetes-dashboard-amd64
a4026007c47e: Pull complete 
Digest: sha256:ebc993303f8a42c301592639770bd1944d80c88be8036e2d4d0aa116148264ff
Status: Downloaded newer image for k8scn/kubernetes-dashboard-amd64:v1.8.3
docker.io/k8scn/kubernetes-dashboard-amd64:v1.8.3
root@f0-15:~# docker images |grep dashboard
k8scn/kubernetes-dashboard-amd64   v1.8.3                     fcac9aa03fd6   4 years ago   102MB
root@f0-15:~# docker tag fcac9aa03fd6 harbor.frank.com/public/dashboard:v1.8.3
root@f0-15:~# docker push harbor.frank.com/public/dashboard:v1.8.3