- 博客(733)
- 资源 (7)
- 收藏
- 关注
RSS订阅
原创 国产操作系统统信UOS的简单故障维护，系统崩溃小妙招
前面先通过一篇文章对统信UOS操作系统做了初步介绍，又通过一篇文章进行了简单的使用说明，今天就对日常使用和维护过程中一些常见问题或故障的处理做一下总结。（本文操作环境为搭载统信UOS桌面专业版1022的国产台式机UNIS CD2000。）Q：如何制作系统安装启动盘？A：首先需要注册统信UOS账号用于下载镜像，镜像下载位置在UOS官网的“资源中心→镜像下载”，选择“桌面专业版”下的“统信UOS桌面专业版arm64”进行镜像下载，此镜像支持飞腾2000处理器（如果使用的其他架构的CPU，请根据实际情况进
2021-03-08 22:37:42
34870
7
原创 统信UOS入门设置（简单使用说明）
相信通过上一篇文章的铺垫，你对统信UOS有了一定的认识，通过帮助文档也能获得比较全面的帮助。但是，我介绍的毕竟是专业版，跟普通的个人版多少存在一些差别，本文再介绍一些小的使用设置。（本文操作环境为搭载统信UOS桌面专业版1022的国产台式机UNIS CD2000。）修改密码系统出厂时设置了默认密码，建议在正常使用后及时修改，避免泄露关键信息。可以在控制中心通过“账户”选择对应账号进行修改，也可以设置自动登录或无密码登陆，建议使用包含大小写字母、数字和特殊符号的组合密码以提高密码健壮性。也可以在终
2021-03-07 15:50:19
34763
1
原创 一问带你掌握通过storcli做RAID
因为系统不支持直接做raid，所以需要使用storcli这个工具来操作。首先把工具上传到服务器任意目录，并使用命令chmod +x storcli64修改文件权限为可执行。另外可通过命令ln -s /root/storcli64 /usr/bin/storcli来设置软链接，这样后续可以在任意目录下输入storcli执行./ storcli64，和系统命令一样。首先使用storcli /c0 show命令查看 RAID 控制器信息，其中包含磁盘的拓扑结构、RAID信息、物理磁盘配置状态等信.
2020-12-21 21:48:27
16145
3
原创 等保2.0简单介绍
近来，网络安全这个话题炽手可热，身处互联网行业的相关人士应该深有体会。其中，关于安全标准这方面，热度最高的应该算是“等保”了。初识等保“等保”，即网络安全等级保护，是我国网络安全领域的基本国策、基本制度。早在2017年8月，公安部评估中心就根据网信办和信安标委的意见将等级保护在编的5个基本要求分册标准进行了合并形成《信息安全技术 网络安全等级保护基本要求》一个标准。（ GB/T 22239—2019代替 GB/T 22239-2008）该标准于2019年5月10日发布，于2019年12月1日开始实施
2020-09-09 10:41:32
10417
4
原创 vFW虚拟防火墙部署实战
疫情还没结束，远程办公仍在继续，这个时间想做个实验都变得很困难，毕竟很少有人单独买设备放家里准备做实验的。远程登录实验室，又没人在现场配合做网线拔插等操作，怎么办呢？搞一台虚拟防火墙vFW吧！以比较常用的VMware安装H3C的vFW为例，只需要下载vFW的系统镜像，然后在VMware上创建虚拟机，挂载系统镜像进行安装部署就可以了。操作十分简单，可以参考如下链接进行安装部署，需要特别提醒的是根据实际需求调整硬件配置，不要太低。http://www.h3c.com/cn/d_201807/108957
2020-07-23 09:10:19
4948
4
原创 IRF堆叠使用问题分析
IRF堆叠使用问题分析更多技术文章请访问 https://guotiejun.comIRF（Intelligent Resilient Framework，智能弹性架构）是H3C自主研发的软件虚拟化技术。它的核心思想是将多台设备连接在一起，进行必要的配置后，虚拟化成一台设备。使用这种虚拟化技术可以集合多台设备的硬件资源和软件处理能力，实现多台设备的协同工作、统一管理和不间断维护。IRF中每台设备都称为成员设备。成员设备按照功能不同，分为两种角色：·主用设备（简称为主设备）：负责管理整个IRF。·
2020-07-15 13:51:13
5952
2
原创 Type-2是管家，Type-5是外交官！Border Leaf让智算中心网络走出去
调整了虚拟机CPU和内存的份额，预留了全部内存，同时将延迟敏感度调整为高，也关闭了KSM和CPULimit，理论上能大幅提升虚拟设备的运行效率。目前，我们的智算中心已经实现了Underlay网络的极速收敛和Overlay网络的全活接入，内功深厚，但酒香也怕巷子深，闭门造车总不是长久之计。用老话说，这就是盖了豪宅没修路——再好的网络，出不去也是白搭。因为前两个测试EVPN多宿主ESI的实验使用的临时拓扑，所以本次组网拓扑我们回滚到分布式网关，同时在Leaf1设备上旁挂一台VSR设备，用于接入互联网。
2026-03-22 07:37:18
230
原创 万物皆可EVE-NG！一招解决Ubuntu镜像MAC冲突
经过一番抽丝剥茧，终于找到了罪魁祸首：在Ubuntu使用Netplan配置IP地址时，默认使用networkd作为渲染器，对于Bond或Bridge这种虚拟接口，systemd-networkd会根据系统的Machine-ID经过哈希运算生成一个私有MAC地址。有时候，即使我们在配置文件中显式指定了MAC地址，也会被自动生成的MAC地址覆盖，不要怀疑，我已经替大家踩过这个坑了。知道了问题原因，那解决方案就简单了，在打包镜像前，彻底清理Machine-ID，让系统下次启动时重新随机生成即可。
2026-03-21 07:37:08
486
原创 丢包之谜：为什么你的ESI实验总是不通？EVE-NG虚拟化环境避坑指南
调整了虚拟机CPU和内存的份额，预留了全部内存，同时将延迟敏感度调整为高，也关闭了KSM和CPULimit，理论上能大幅提升虚拟设备的运行效率。1、在EVE-NG中，Ubuntu虚拟机镜像存在问题，虽然指定了不同的MAC地址，但是进入系统，Server1和Server2两台主机仍然使用相同的MAC地址，影响网络转发；，既要拉心跳线，又要做繁琐配置。明确了以上问题，就好办了，我要争取全部解决掉，实现EVPN多宿主ESI的零丢包。，对双工和速率的感知稍差，不如E1000网卡仿真，更接近真实的物理网卡。
2026-03-20 07:45:34
240
原创 从M-LAG到ESI：打造不用心跳线的神交式双活智算中心架构
调整了虚拟机CPU和内存的份额，预留了全部内存，同时将延迟敏感度调整为高，也关闭了KSM和CPULimit，理论上能大幅提升虚拟设备的运行效率。但俗话说：不怕一万，就怕万一，目前的服务器都是单线接入，如果Leaf1设备挂了，或者那根上行链路断了，业务肯定直接熄火，又该怎么办呢？对于这种单点故障，应对方案就是利用EVPN的Type-1路由和Type-4路由，实现服务器跨Leaf设备的双上行接入，实现无心跳线的全活转发。，实现智算中心处处是网关、步步是捷径，网络流量指哪打哪，同时降低 67 %的时延。
2026-03-19 07:45:08
249
原创 从8跳到3跳：EVPN 分布式网关让时延降低67%的完整实战
其中，Spine/Leaf交换机均使用Nvidia Cumulus VX的5.15.1版本，资源配置为2核CPU、3 GB内存；现在，我们发现现在这种网络架构，虽然配置简单，但两台终端之间的转发路径也太绕了，蜀道难，难于上青天，这甚至都不是次优路径，应该是除环路外的最差路径了。调整了虚拟机CPU和内存的份额，预留了全部内存，同时将延迟敏感度调整为高，也关闭了KSM和CPULimit，理论上能大幅提升虚拟设备的运行效率。，让网关化为无形，实现处处是网关、步步是捷径的便捷之美。
2026-03-18 07:43:56
475
原创 跨VLAN通信过五关斩六将都不够，我的数据包创造了8跳的新纪录
在智算中心里，服务器不可能永远待在同一个VLAN下面，跨网段的三层转发转发才是家常便饭。调整了虚拟机CPU和内存的份额，预留了全部内存，同时将延迟敏感度调整为高，也关闭了KSM和CPULimit，理论上能大幅提升虚拟设备的运行效率。每一台Leaf都是网关，在智算中心，东西向流量占比超过 80%，分布式网关能实现就近转发，是高并发架构的灵魂。全网网关都在某一台核心设备上，优点是配置简单，缺点是所有跨网段流量都要去核心设备上绕一圈，产生次优路径。，实现了服务器之间跨Leaf设备的通信。
2026-03-17 07:42:58
316
原创 从180秒到0.01秒：智算中心Underlay路由优化的速度与激情
但是，BGP Unnumbered只能解决连通性问题，在智算中心这种对丢包极度敏感的场景下，默认60秒Keepalive和180秒Holdtime的收敛速度简直是老牛拉破车，遇到智算中心网络抖动，等180秒路由才收敛？本次实验环境为EVE-NG专业版6.4.0-78，虚拟机配置为40核vCPU、96 GB内存。所以，本次实验核心就是“快”，我们将通过BGP Timer调优和BFD，力争将收敛时间从分钟级压缩到毫秒级，实现故障的秒级感知与平滑切换，为后续的RoCEv2流量提供一个“稳如泰山”的底层。
2026-03-15 07:37:53
254
原创 告别OSPF！EVE-NG专业版+BGP Unnumbered打通Underlay的完整实战
虽然规格有所降低，但是我们调整了CPU和内存的份额，预留了全部内存，同时将延迟敏感度调整为高，理论上资源调度优先级更高。2、核心设备我们替换成了Nvidia Cumulus VX，这台伪装成交换机的Linux服务器，既支持交换机特性，又支持路由器特性，用路由协议解决交换问题。既然要搞智算中心，不玩点这种原生Linux的味道，总觉得少了点极客的灵魂。新的RoCE实验的第一期，我们先把Underlay网络打通，不同于之前的实验。，我们这次在换镜像的时候，提前把后面实验用到的命令先验证一下。万事俱备，这就发车！
2026-03-14 07:36:45
279
原创 从屡战屡败到一气呵成：EVE-NG专业版 + Cumulus VX终于跑通RoCE
有了专业版，推荐首先进入【System】下的【System Settings】，有个Template Visibility选项，配置Unprovisioned images为【Hide】，指的就是将没有导入的不可用镜像隐藏，方便我们更快找到已经导入的镜像。同时还做了大量优化。更建议的做法是，依靠专业版的CPU Pinning功能，将特定节点绑定到固定的物理核心上，既能防止某个镜像占用过多资源影响宿主机，又能保证该节点的CPU响应是实时的、无干扰的。然后就开始部署了，操作很简单，按几次回车就行，非常简单。
2026-03-13 07:45:37
771
原创 原生支持真的好用吗？Ubuntu 24.04桌面共享vs远程登录全解析
首先是桌面共享，可以看到下面分成了【Desktop Sharing/桌面共享】和【Remote Control/远程控制】两个权限，一共是三种组合方式：桌面共享关+远程控制关、桌面共享开+远程控制关、桌面共享开+远程控制开。1、远程桌面分为桌面共享和远程登录两种服务，且远程登录的优先级更高。使能之后，我们会收到提醒：因为远程登录的优先级更高，所以会抢占3389端口，此时桌面共享的服务端口会更改为3390。登录成功之后，确实就是一个新的会话了，之前的操作界面全都消失了，就连分辨率都是远程桌面设置的分辨率。
2026-03-12 07:44:41
376
原创 ECN配置折戟记：vEOS模拟器局限性深度剖析
考虑到在大拓扑环境下，vEOS模拟器在数据面转发性能上确实存在瓶颈，我们需要缩减设备规模，以腾出更多的CPU算力给那些精细的算法，所以，从这个实验开始，我们对实验拓扑进行压缩，配置为2-Spine + 2-Leaf 的精简Clos架构，即2台Spine设备、2台Leaf设备，下挂4台Server终端，同时依旧配置为分布式网关，采用border leaf架构外挂VSR来访问互联网。在智算中心的Incast场景下，如果只靠我们上次尝试的PFC进行暴力刹车，容易引发全网性的头端阻塞（HoL）甚至死锁。
2026-03-11 07:43:30
328
原创 零成本AI部署：旧手机变身智能助手全记录
免费模型虽然性能差一点，但是可以在量上取胜，这两天我已经累计调用了超过600万的免费token，要是按照付费版的deepseek-ai/DeepSeek-R1来算，大概要100块钱了。其实要使用境外的平台会好一些，模型能力更强，但是国内访问不到，成功率为0%，国内就稳定的多，平均成功率超过95%，失败还不是因为网络问题，是因为请求超速了。可以看到，OpenClaw网关的内存占用约为105 MB，还是很轻量的，之前在服务器上部署的时候，内存基本上要占到400 MB左右。该说不说，旧手机的系统内存占用就是低。
2026-03-10 07:42:24
901
原创 手机也能跑DeepSeek-R1/Qwen3了：零成本搭建AI推理平台
当然，ollama的运算速度相比还是低一些，如果要充分压榨CPU性能，榨出这颗芯片的最后一滴油水，可以再试试llama.cpp，实测运行3B参数的qwen2.5输出速度最快有25.6 TPS，比我们今天测试最快的1.5B参数DeepSeek的20.9 TPS还要再快22.5 %。模型加载后的内存占用情况为：MEM 10.3 G、Swap 2.08 G，相当于占用5 GB内存，比7B参数的DeepSeek占用还要高。当然，在后面的测试过程中，手机有微微发热的情况，暖手但是不烫。
2026-03-09 07:41:35
755
原创 告别云服务器费用：零成本将旧手机改造Linux服务器实战指南
这台手机系统版本为Android 9，搭载骁龙835处理器（2017年旗舰，8核CPU，4个2.45GHz的大核加4个1.9GHz的小核设计），搭配绰绰有余的6 GB LPDDR4x运行内存和64 GB UFS 2.1存储，放到现在，硬件配置也不比低端盒子性能差，完全能胜任轻量级服务器角色。通过本次实践，我们成功验证了旧手机改造Linux服务器的可行性。不过，传统的方案都需要公网服务器，即使是轻量应用服务器，2核4 G的入门型也要65元/月，包年享受8.5折优惠，也还要663 元/年，不还是贵了吗？
2026-03-08 07:37:41
335
原创 千呼万唤始出来！Windows用户终于吃上了Codex+GPT-5.4这口“热豆腐”，但额度有点一言难尽
虽然它还有些初出茅庐的青涩，而且它目前还只能在【本地】这一亩三分地里施展拳脚，再加上额度的限制让人意犹未尽，但其内置的自动化逻辑和GPT-5系列模型的加持，已经足以让我们窥见未来：代码不再是敲出来的，而是想出来的。切换到【技能】模块，可以看到软件内置的Skill技能，通过打包指令、资源和可选脚本，可以赋予Codex更强大的能力，实现类似n8n的自动化动作流程。这里显示的【1周，100%，3月13日】的意思是：在这个为期1周的免费额度计费周期里，我的免费额度还剩余100%，并将在3月13日恢复全部额度。
2026-03-07 07:36:17
861
原创 资源占用仅27MB！Ubuntu远程桌面高效部署方案
连接时使用跟Windows一样的3389端口，这个端口一般云主机也是默认放通的，无需额外配置安全组规则。当然，如果你不想每次登录的时候都在那个xRDP的对话框输入账号密码，也可以使用MSTSC自带的保存凭据选项。通过本次实践，我们见证了AI生成脚本在Linux远程桌面部署中的卓越表现，这个轻量级脚本解决方案真正实现了小身材，大能量。相比未登录状态，内存占用约增加480 MB，当然，这还是我们启用了一个终端加一个任务管理器的情况。轻装上阵，在初始状态下，系统的内存占用为573 MB，磁盘用量为16 GB。
2026-03-06 07:45:44
864
原创 从理想到现实：RDMA无损网络PFC配置的“血泪史“
我尝试进Bash强行修改它，但是失败了，提示参数错误。我自认为是比较细心的人，这么多次实验，接线一次都没错，但是EVE-NG的接线限制对我的实验也确实有影响，那就是设备一旦启动便无法再执行线路相关的调整，只能确认没问题之后再启动设备。说实话，罗马不是一天建成的，没有什么成功是一蹴而就的，尤其是这样的大型网络模拟，光接线就有60根，配置更是上千行，一旦接错了，排查起来跑是要一个头两个大。完成从“尽力而为”到“绝对可靠”的跨越，全靠配置PFC（802.1Qbb），可以说，没有PFC，RDMA就是无米之炊。
2026-03-05 07:45:04
315
原创 从理想到现实：RDMA无损网络PFC配置的“血泪史“
我尝试进Bash强行修改它，但是失败了，提示参数错误。我自认为是比较细心的人，这么多次实验，接线一次都没错，但是EVE-NG的接线限制对我的实验也确实有影响，那就是设备一旦启动便无法再执行线路相关的调整，只能确认没问题之后再启动设备。说实话，罗马不是一天建成的，没有什么成功是一蹴而就的，尤其是这样的大型网络模拟，光接线就有60根，配置更是上千行，一旦接错了，排查起来跑是要一个头两个大。完成从“尽力而为”到“绝对可靠”的跨越，全靠配置PFC（802.1Qbb），可以说，没有PFC，RDMA就是无米之炊。
2026-03-05 07:45:04
304
原创 从理想到现实：RDMA无损网络PFC配置的“血泪史“
我尝试进Bash强行修改它，但是失败了，提示参数错误。我自认为是比较细心的人，这么多次实验，接线一次都没错，但是EVE-NG的接线限制对我的实验也确实有影响，那就是设备一旦启动便无法再执行线路相关的调整，只能确认没问题之后再启动设备。说实话，罗马不是一天建成的，没有什么成功是一蹴而就的，尤其是这样的大型网络模拟，光接线就有60根，配置更是上千行，一旦接错了，排查起来跑是要一个头两个大。完成从“尽力而为”到“绝对可靠”的跨越，全靠配置PFC（802.1Qbb），可以说，没有PFC，RDMA就是无米之炊。
2026-03-05 07:45:04
248
原创 从理想到现实：RDMA无损网络PFC配置的“血泪史“
我尝试进Bash强行修改它，但是失败了，提示参数错误。我自认为是比较细心的人，这么多次实验，接线一次都没错，但是EVE-NG的接线限制对我的实验也确实有影响，那就是设备一旦启动便无法再执行线路相关的调整，只能确认没问题之后再启动设备。说实话，罗马不是一天建成的，没有什么成功是一蹴而就的，尤其是这样的大型网络模拟，光接线就有60根，配置更是上千行，一旦接错了，排查起来跑是要一个头两个大。完成从“尽力而为”到“绝对可靠”的跨越，全靠配置PFC（802.1Qbb），可以说，没有PFC，RDMA就是无米之炊。
2026-03-05 07:45:04
248
原创 从理想到现实：RDMA无损网络PFC配置的“血泪史“
我尝试进Bash强行修改它，但是失败了，提示参数错误。我自认为是比较细心的人，这么多次实验，接线一次都没错，但是EVE-NG的接线限制对我的实验也确实有影响，那就是设备一旦启动便无法再执行线路相关的调整，只能确认没问题之后再启动设备。说实话，罗马不是一天建成的，没有什么成功是一蹴而就的，尤其是这样的大型网络模拟，光接线就有60根，配置更是上千行，一旦接错了，排查起来跑是要一个头两个大。完成从“尽力而为”到“绝对可靠”的跨越，全靠配置PFC（802.1Qbb），可以说，没有PFC，RDMA就是无米之炊。
2026-03-05 07:45:04
568
原创 从理想到现实：RDMA无损网络PFC配置的“血泪史“
我尝试进Bash强行修改它，但是失败了，提示参数错误。我自认为是比较细心的人，这么多次实验，接线一次都没错，但是EVE-NG的接线限制对我的实验也确实有影响，那就是设备一旦启动便无法再执行线路相关的调整，只能确认没问题之后再启动设备。说实话，罗马不是一天建成的，没有什么成功是一蹴而就的，尤其是这样的大型网络模拟，光接线就有60根，配置更是上千行，一旦接错了，排查起来跑是要一个头两个大。完成从“尽力而为”到“绝对可靠”的跨越，全靠配置PFC（802.1Qbb），可以说，没有PFC，RDMA就是无米之炊。
2026-03-05 07:45:04
282
原创 从理想到现实：RDMA无损网络PFC配置的“血泪史“
我尝试进Bash强行修改它，但是失败了，提示参数错误。我自认为是比较细心的人，这么多次实验，接线一次都没错，但是EVE-NG的接线限制对我的实验也确实有影响，那就是设备一旦启动便无法再执行线路相关的调整，只能确认没问题之后再启动设备。说实话，罗马不是一天建成的，没有什么成功是一蹴而就的，尤其是这样的大型网络模拟，光接线就有60根，配置更是上千行，一旦接错了，排查起来跑是要一个头两个大。完成从“尽力而为”到“绝对可靠”的跨越，全靠配置PFC（802.1Qbb），可以说，没有PFC，RDMA就是无米之炊。
2026-03-05 07:45:04
243
原创 从理想到现实：RDMA无损网络PFC配置的“血泪史“
我尝试进Bash强行修改它，但是失败了，提示参数错误。我自认为是比较细心的人，这么多次实验，接线一次都没错，但是EVE-NG的接线限制对我的实验也确实有影响，那就是设备一旦启动便无法再执行线路相关的调整，只能确认没问题之后再启动设备。说实话，罗马不是一天建成的，没有什么成功是一蹴而就的，尤其是这样的大型网络模拟，光接线就有60根，配置更是上千行，一旦接错了，排查起来跑是要一个头两个大。完成从“尽力而为”到“绝对可靠”的跨越，全靠配置PFC（802.1Qbb），可以说，没有PFC，RDMA就是无米之炊。
2026-03-05 07:45:04
305
原创 从理想到现实：RDMA无损网络PFC配置的“血泪史“
我尝试进Bash强行修改它，但是失败了，提示参数错误。我自认为是比较细心的人，这么多次实验，接线一次都没错，但是EVE-NG的接线限制对我的实验也确实有影响，那就是设备一旦启动便无法再执行线路相关的调整，只能确认没问题之后再启动设备。说实话，罗马不是一天建成的，没有什么成功是一蹴而就的，尤其是这样的大型网络模拟，光接线就有60根，配置更是上千行，一旦接错了，排查起来跑是要一个头两个大。完成从“尽力而为”到“绝对可靠”的跨越，全靠配置PFC（802.1Qbb），可以说，没有PFC，RDMA就是无米之炊。
2026-03-05 07:45:04
551
原创 从东西向到南北向：Border Leaf如何实现智算中心网络的“全向通达“
Type-5路由的自动传播让全网Leaf设备都能获得默认路由，实现了一处配置，全网生效的智能化管理。，每一台Leaf设备都能独立处理本地的三层转发，在Anycast Gateway的加持下，解决智算中心网络中最核心的延迟问题，配合多路ECMP、MTU 9000等技术，才能真正称得上是“大厂级”的算力底座。理论上讲，有两种架构方案，其中最常用的就是Border Leaf（边界叶交换机）架构，这种设计可以将集群内部的复杂性与外部网络的策略完全解耦，而且可以横向扩展多组Border Leaf，不影响物理架构。
2026-03-04 07:43:56
580
原创 从东西向到南北向：Border Leaf如何实现智算中心网络的“全向通达“
Type-5路由的自动传播让全网Leaf设备都能获得默认路由，实现了一处配置，全网生效的智能化管理。，每一台Leaf设备都能独立处理本地的三层转发，在Anycast Gateway的加持下，解决智算中心网络中最核心的延迟问题，配合多路ECMP、MTU 9000等技术，才能真正称得上是“大厂级”的算力底座。理论上讲，有两种架构方案，其中最常用的就是Border Leaf（边界叶交换机）架构，这种设计可以将集群内部的复杂性与外部网络的策略完全解耦，而且可以横向扩展多组Border Leaf，不影响物理架构。
2026-03-04 07:43:56
306
原创 从东西向到南北向：Border Leaf如何实现智算中心网络的“全向通达“
Type-5路由的自动传播让全网Leaf设备都能获得默认路由，实现了一处配置，全网生效的智能化管理。，每一台Leaf设备都能独立处理本地的三层转发，在Anycast Gateway的加持下，解决智算中心网络中最核心的延迟问题，配合多路ECMP、MTU 9000等技术，才能真正称得上是“大厂级”的算力底座。理论上讲，有两种架构方案，其中最常用的就是Border Leaf（边界叶交换机）架构，这种设计可以将集群内部的复杂性与外部网络的策略完全解耦，而且可以横向扩展多组Border Leaf，不影响物理架构。
2026-03-04 07:43:56
238
原创 从东西向到南北向：Border Leaf如何实现智算中心网络的“全向通达“
Type-5路由的自动传播让全网Leaf设备都能获得默认路由，实现了一处配置，全网生效的智能化管理。，每一台Leaf设备都能独立处理本地的三层转发，在Anycast Gateway的加持下，解决智算中心网络中最核心的延迟问题，配合多路ECMP、MTU 9000等技术，才能真正称得上是“大厂级”的算力底座。理论上讲，有两种架构方案，其中最常用的就是Border Leaf（边界叶交换机）架构，这种设计可以将集群内部的复杂性与外部网络的策略完全解耦，而且可以横向扩展多组Border Leaf，不影响物理架构。
2026-03-04 07:43:56
342
原创 从东西向到南北向：Border Leaf如何实现智算中心网络的“全向通达“
Type-5路由的自动传播让全网Leaf设备都能获得默认路由，实现了一处配置，全网生效的智能化管理。，每一台Leaf设备都能独立处理本地的三层转发，在Anycast Gateway的加持下，解决智算中心网络中最核心的延迟问题，配合多路ECMP、MTU 9000等技术，才能真正称得上是“大厂级”的算力底座。理论上讲，有两种架构方案，其中最常用的就是Border Leaf（边界叶交换机）架构，这种设计可以将集群内部的复杂性与外部网络的策略完全解耦，而且可以横向扩展多组Border Leaf，不影响物理架构。
2026-03-04 07:43:56
534
原创 从东西向到南北向：Border Leaf如何实现智算中心网络的“全向通达“
Type-5路由的自动传播让全网Leaf设备都能获得默认路由，实现了一处配置，全网生效的智能化管理。，每一台Leaf设备都能独立处理本地的三层转发，在Anycast Gateway的加持下，解决智算中心网络中最核心的延迟问题，配合多路ECMP、MTU 9000等技术，才能真正称得上是“大厂级”的算力底座。理论上讲，有两种架构方案，其中最常用的就是Border Leaf（边界叶交换机）架构，这种设计可以将集群内部的复杂性与外部网络的策略完全解耦，而且可以横向扩展多组Border Leaf，不影响物理架构。
2026-03-04 07:43:56
305
原创 从东西向到南北向：Border Leaf如何实现智算中心网络的“全向通达“
Type-5路由的自动传播让全网Leaf设备都能获得默认路由，实现了一处配置，全网生效的智能化管理。，每一台Leaf设备都能独立处理本地的三层转发，在Anycast Gateway的加持下，解决智算中心网络中最核心的延迟问题，配合多路ECMP、MTU 9000等技术，才能真正称得上是“大厂级”的算力底座。理论上讲，有两种架构方案，其中最常用的就是Border Leaf（边界叶交换机）架构，这种设计可以将集群内部的复杂性与外部网络的策略完全解耦，而且可以横向扩展多组Border Leaf，不影响物理架构。
2026-03-04 07:43:56
534
原创 从东西向到南北向：Border Leaf如何实现智算中心网络的“全向通达“
Type-5路由的自动传播让全网Leaf设备都能获得默认路由，实现了一处配置，全网生效的智能化管理。，每一台Leaf设备都能独立处理本地的三层转发，在Anycast Gateway的加持下，解决智算中心网络中最核心的延迟问题，配合多路ECMP、MTU 9000等技术，才能真正称得上是“大厂级”的算力底座。理论上讲，有两种架构方案，其中最常用的就是Border Leaf（边界叶交换机）架构，这种设计可以将集群内部的复杂性与外部网络的策略完全解耦，而且可以横向扩展多组Border Leaf，不影响物理架构。
2026-03-04 07:43:56
281
原创 从东西向到南北向：Border Leaf如何实现智算中心网络的“全向通达“
Type-5路由的自动传播让全网Leaf设备都能获得默认路由，实现了一处配置，全网生效的智能化管理。，每一台Leaf设备都能独立处理本地的三层转发，在Anycast Gateway的加持下，解决智算中心网络中最核心的延迟问题，配合多路ECMP、MTU 9000等技术，才能真正称得上是“大厂级”的算力底座。理论上讲，有两种架构方案，其中最常用的就是Border Leaf（边界叶交换机）架构，这种设计可以将集群内部的复杂性与外部网络的策略完全解耦，而且可以横向扩展多组Border Leaf，不影响物理架构。
2026-03-04 07:43:56
309
单片机应用实践实习报告-南京工业大学
2015-02-02
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人