背景

最近正好有个RFC2544测试，之前都是L2蛇形居多，这次测试下路由蛇形。在此类测试中，“路由蛇形拓扑”（Snake-like Routing Topology）是一种具有代表性的测试模型。该模型要求流量按照预先规划的逻辑顺序，在一台交换机上创建多个虚拟路由转发（VRF）实例，通过一系列指定端口进行有序转发。然而，此类拓扑手动配置较复杂，逻辑需要逐一捋顺，重复工作多，比较费时间。

为应对上述挑战，我请AI（grok -> gemini）开发一个自动化的Python脚本。此脚本旨在通过程序化方式生成网络配置，从手动配置工作中解放出来，显著提升测试环境部署的效率与准确性。其最终交付成果是一个能够根据用户提供的基础拓扑信息，自动生成适用于多种主流网络设备操作系统（包括H3C, Huawei, Cisco, Juniper, SONiC）完整配置文件的软件工具（目前只测试了H3C的系统，其他系统待测试，估计使用时需要些许调整，后面用到了再完善吧）。

背景

经过几个月断断续续的研究，购买设备，搭建，以及优化……终于在最近完成了我人生中第一台ITX小机箱的部署。开始时本想用视频记录下所有搭建过程，但发现还是太麻烦，索性还是通过Blog的方式进行记录，方便自己随时查阅，也供有缘人参考。

我上一个PC是2017年更新的，其中也断断续续升级过部分配件。到目前也差不多8年了。显卡着实跟不上时代，我用RTX1066 打通了很多非常不错的游戏，如用CEMU模拟的塞尔达荒野之息，配合Meta Quest2串流的VR顶流Alex，以及去年属于我们自己的3A大作黑神话悟空，虽然1066输出的画质一言难尽，但仍然使我充满快乐和满足，游戏是电脑迭代更新的第一个理由。另外最近几年AI很火，由于工作的性质，需要持续关注AI相关技术，包括但不限于如集合通信对网络的影响。所以能够进行简单的训练和推理就成为我电脑迭代升级的另一个理由。在更换PC之前，我其实是想选择Mac Studio M4 Max，但拿到后发现游戏要层层转移，问题不断；Github上跟AI相关的开源项目大部分都是基于Nvidia，Mac也就只能跑跑模型（真要跑训练，要改的东西较多），我测试过M4 Max/128GB的模型推理能力，确实还可以，但也就这样了，128GB的统一内存也没法搞定满血R1。因此最终还是退掉了，Apple的服务值得👍🏻，建议还是不要冲动消费。

本机跑Ollma很容易，分开跑同样很容易 ~ 也就是如下Topology：

MacBook pro（web） ——– （openwebui）synology 918+ ——–（ollama）MacStudio

为什么这么繁琐，主要是不想在Mac上安装docker，另外也不想把openwebui直接安装到host上，正好利用这种方式测试下交互，所以才有了这篇文章

Ollama设置 – Mac Studio

创建 launchd 配置文件

在下面文件夹中增加一个配置文件，默认应该没有这个文件夹，我是安装过NAS的drive应用，所以就不用新建了。确保ollama路径是正确的，通过which命令验证，以及打开局域网访问OLLAMA_HOST 0.0.0.0：

yong@yongdeMac-Studio ~ % more ~/Library/LaunchAgents/com.ollama.ollama.plist
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>com.ollama.ollama</string>
    <key>ProgramArguments</key>
    <array>
        <string>/usr/local/bin/ollama</string>
        <string>serve</string>
    </array>
    <key>RunAtLoad</key>
    <true/>
    <key>KeepAlive</key>
    <true/>
    <key>EnvironmentVariables</key>
    <dict>
        <key>OLLAMA_HOST</key>
        <string>0.0.0.0</string>
    </dict>
    <key>StandardOutPath</key>
    <string>/tmp/ollama.log</string>
    <key>StandardErrorPath</key>
    <string>/tmp/ollama.err</string>
</dict>
</plist>
yong@yongdeMac-Studio ~ % which ollama
/usr/local/bin/ollama

加载并启用服务

之前看完论文就完事了，过了一段时间后，很多细节就会忘记，需要重新看一遍……之前的兄弟习惯很好，看完会总结，忘记就看总结。所以趁着最近阿里发布的最新论文，我也总结下，为了以后复习用。

这篇论文写的很好，讲了很多阿里HPN的基础设施及架构细节，虽然不是全部，但也包含了大部分的内容，很难得。去堆叠部分我没写进去，这个在国内互联网已经很熟了，但目前看国外的互联网以及OCP上，还在讨论如何简化堆叠的双上联问题。论文也提到微软在2023年通过SmartNIC（w/ FPGA）来实现双活。

论文原文：

拓扑

DCN+拓扑

按照论文的说法，HPN是针对之前阿里DCN+架构进行优化演进而来的，DCN+是传统的3层CLOS架构（根据去年阿里发布灵骏的相关文章，架构应该不是这样的，应该更偏向HPN，架构从实践中演进~ ？）：

背景

之前一直看到有人谈论用Chatgpt编程序，设计产品，做游戏，反正很神就是了。在我使用过程中，并没有感觉那么神，也许是提示字给的不标准吧。最近正好有个机会，需要搞一个All2all的测试脚本，可自动化提供大规模All2All的测试任务。因此就测试了下GPT的能力。

目前用的是最新版本GPT4o（自行花了20美金），整体使用下来，GPT确实可以协助编程，只是沟通起来比较费劲和费时间……如果真正要搞一个项目，就不太现实了。估计还要再迭代几轮吧。即使是最牛的GPT4o，在沟通交互中，仍然会有以下问题：

• 强调过的内容，可能要重复说3-4遍，GPT才真的听进去了，但过了几轮后可能就又忘记了，比如”不着急出优化代码，先讨论问题“；
• 为了提升效率，对于一些小优化，其实可以提供代码片段，但GPT有时候提供的片段跟代码本身没有强联系；
• 为了排障，在脚本中增加了一些提示信息（增加执行log）。后面随着不断迭代优化，就会发现有些功能消失了。这种现象很明显，很可能会遇到之前解决过的问题再次出现……