dash 2500 监控什么NPB 2.0 面面观 ｜ 基于 Ansible 自动化配置 NPB 策略

科创型企业是数字化时代的核心引擎，其发展势头与竞争力，取决于底层网络架构的稳定与高效。这类企业通常依托两大核心网络——承载关键业务的服务器区和支持高效接入的办公网（采用“混合组网”架构），以满足高性能与高可靠性的双重需求。

• 服务器区Leaf通过MC-LAG技术与服务器相连，实现服务器双活接入；
• 办公网与服务器区之间则通过全三层路由实现灵活可控的互访与高效的传输路径。

在网络规模持续扩张的背景下，“MC-LAG + 全三层”架构虽能提供高可用和灵活的路由能力，但其运维复杂度可想而知。传统网络控制器手工配置、分散管理和被动运维的模式，已成为制约企业业务敏捷发展与稳定安全的瓶颈。

面对科创型企业提出的“混合组网”需求，星融元基于TIP OpenWiFi框架构建的园区网络控制器（ACC）在规划拓扑环节新增了“混合组网”场景，显著简化了传统“MC-LAG + 全三层”架构的部署与运维流程。

在已做好网络规划的前提下。

第1步，设备导入

根据模板规范填写设备信息并上传，完成后即可在库存信息界面查看已创建的设备。

第2步，规划拓扑

ACC – 拓扑场景规划

选择“混合组网场景”模板。

按角色（Spine/Aggregation/Leaf）分配设备并填写互联接口，控制器会根据填写内容生成网络拓扑。

ACC – 拓扑生成

Leaf1与Leaf2作为分布式网关，Leaf1负责连接AP及无线终端，Leaf2负责连接有线终端。通过横向扩展汇聚层（Agg1、Agg2）实现高可用与负载均衡，Spine与汇聚设备间均运行MC-LAG，以保障链路可靠性。

Server-Leaf1与Server-Leaf2通过MC-LAG技术以纯二层模式连接服务器，网关集中部署在Spine设备上，简化服务器区网络管理并提升转发效率。

第3步，基础网络配置

ACC通过图形化界面，极大地简化了传统控制器上需要复杂命令行操作的MC-LAG（跨设备链路聚合）与全三层路由混合组网配置。

• 业务区网络配置

这一步主要针对园区网络中的汇聚层设备，为其实现带内管理和MC-LAG功能奠定基础。如：管理地址段、PeerLink VLAN、PeerLink IP……

ACC – 业务区网络配置

• 服务器区网络配置

针对服务器区的Leaf设备，配置内容与业务区类似，为Leaf设备提供带内管理能力，并为其Peer-Link接口做好准备。

ACC – 服务器区网络配置

• 出口路由配置

确保整个园区网络能够通过Spine设备与外部网络进行通信。

第4步，业务配置

• 有线业务配置

默认业务区的主要在Leaf1和Leaf2设备上进行，为不同业务区域定义VLAN、网关、DHCP中继及PoE供电等参数。

ACC – 有线业务配置

为服务器区Leaf交换机创建链路聚合组及业务VLAN，在Spine设备上创建与Leaf设备对应的VLAN。

• 无线业务配置

管理员可以在此集中管理无线接入点（AP），配置SSID、安全策略、有线终端接入方式等，并利用标签系统实现配置的自动匹配与下发。

• DHCP Server

在Spine设备上配置DHCP Server，为整个园区网络中的终端设备（如AP、无线终端、有线终端）自动分配IP地址，是实现网络自动化管理的核心环节。

ACC – 配置DHCP Server

第5步，配置下发

在完成所有网络与业务配置后，一键向交换机批量推送基础网络、有线业务及DHCP配置，而AP在上线后则根据预分配标签自动拉取对应配置，实现全自动化部署，彻底告别了传统的人工逐台配置模式。

ACC – Dashboard

ACC通过图形化界面，实现了网络状态的全面可视化，帮助运维人员直观地掌握整个网络的运行状况。

ACC – 主动告警

还能够实时监控设备的关键服务状态。一旦发现异常，会立即自动生成包含详细信息的告警，并根据告警的严重程度，精准地推送给相应的人员，从而实现高效、主动的运维管理。

同时，智能巡检功能支持对巡检项目进行精细化配置，确保运维工作的全面性和准确性。

• Spine-leaf架构

有线网络采用简洁、高可靠的 Spine/Leaf 架构运行全三层网络，天然无环路，隔绝广播风暴，同时支持按需横向扩展满足未来5-8年的扩容升级需求；下一代园区网络，用Leaf/Spine架构替代传统三层拓扑 下一代园区网络，用Leaf/Spine架构替代传统三层拓扑

• 分布式网关

无线网络则借助分布式网关设计，提供超大漫游域的无缝漫游，实现跨楼栋漫游不中断，网随人动，策略随行，兼顾安全和便利性;园区网前沿实践：基于开放网络架构的云化路由设计 园区网前沿实践：基于开放网络架构的云化路由设计

• 多元化认证方式

智能地自动识别接入网络的终端类型，并根据其属性和场景，自动匹配并执行最合适的认证方式，如802.1X或Portal认证，从而实现高效、安全且体验友好的网络准入控制。

传统分流器 / TAP 一般是通过 Web 界面手动调整配置，而实际业务中成千条配置的周期性调整给一线运维人员造成了极大的负担。

举例来说，传统方式下假设我们要配置 10 台 NPB 专用设备，为其更新 VLAN 镜像规则与目标端口映射，我们需要依次登录这 10 台设备，打开 Web 界面进行手动添加/修改规则 1000+ 条，然后检查、保存，一通操作耗时动辄数小时，甚至一整天。

随着近些年的产品迭代，虽然部分 NPB 设备已经可以做到集群内的批量配置同步，但无论是在 Web 界面上如何优化，只要运维模式依旧是手工完成的拖拉点拽，还是免不了耗时耗力易出错。

关于星融元 NPB 2.0 ，请参阅：无需TAP/分流器，SONiC上跑容器，交换机秒变NPB

在 NPB2.0 中，我们已抛弃了过往使用专用设备的方案，而是在交换机上容器化运行 NPB 组件来实现相应功能。不光如此，我们也支持用 Ansible 去调用 sonic-cli 来批量配置新一代基于SONiC的 NPB 设备（包括园区和数据中心场景），实现快速、标准化、零差错的策略部署。

Ansible是一款基于 Python 开发的开源自动化运维工具，由 Red Hat 公司主导维护，其诞生背景源于云计算时代下IT基础设施的规模化与动态化，传统手工运维方式难以应对频繁的配置变更和批量部署需求。

该工具的核心特点是基于agentless和声明式模型，借助 SSH 或 WinRM 协议直接管理节点，避免了客户端代理的安装和维护成本，其大致的交互模式为 用户通过YAML语言编写 Playbook定义目标状态，Ansible 自动将模块推送到远程节点执行配置。

由此我们可以建立标准化流程，将重复性运维操作转化为可版本控制的自动化任务，显著提升网络运维效率与可靠性。

目前 Ansible 已成为 DevOps 和云原生技术栈中的重要组件，帮助运维工程师跨平台配置统一管理各大基础设施，包括网络设备、云主机、容器集群等等。

星融元的 Ansible 官方模块集合 Asterfusion AsterNOS Collection 已完成cliconf 插件和asternos_command 模块的开发适配，这些模块可在 Playbook 中直接调用，然后在 Ansible 的 inventory 文件中定义 SONiC 设备并为其设置正确的连接变量。

运维人员根据实际需求使用上述的 CLI 模块编写 Playbook 任务并运行，即可快速完成 NPB 策略下发、ACL 更新、端口配置等批量操作，几秒钟内即可将规则同步到所有 NPB 设备（SONiC 设备），并在 Git 中追踪变更历史。

pip3 install ansible

[defaults]
inventory = inventory #指定为’inventory’文件
host_key_checking = False
retry_files_enabled = False
gathering = explicit
stdout_callback = yaml

[sonic]
sonic1 ansible_host=192.168.1.x ansible_user=x ansible_password=x

# group_vars/sonic.yml
host: “{{ ansible_host }}”
user: “{{ ansible_user }}”
password: “{{ ansible_password }}”

以下为两组示例的命令行配置

config_vlan_cmd: |
configure
vlan 3003
end
exit

config_acl_test_cmd: |
configure
access-list L3 test1 ingress priority 500000
rule 1 packet-action permit redirect-action ethernet 11
exit
interface ethernet 11
acl test1
end
exit

不需要改动，用来调用设备的 CLI（代码略）

新增两个task分别调用config_acl_test_cmd和config_vlan_cmd

—
– hosts: sonic
gather_facts: no
tasks:
– name: Push klish commands
sonic_klish:
commands: “{{ config_acl_test_cmd }}”
host: “{{ host }}”
user: “{{ user }}”
password: “{{ password }}”
delegate_to: localhost
register: result

– name: Push klish commands 1
sonic_klish:
commands: “{{ config_vlan_cmd }}”
host: “{{ host }}”
user: “{{ user }}”
password: “{{ password }}”
delegate_to: localhost
register: result

– debug: var=result.stdout

[root@localhost ansible]# ansible-playbook -v site.yml
Using /home/ryan/ansible/ansible.cfg as config file

打印如下，则执行完毕：

PLAY [sonic] *********************

TASK [Push klish commands] ****************
changed: [sonic1 -> localhost] => changed=true
stdout: |-
Warning: Permanently added ‘192.168.1.102’ (RSA) to the list of known hosts.
…Entering cli view, please wait…
stty: ‘standard input’: Inappropriate ioctl for device
stty: ‘standard input’: Inappropriate ioctl for device
sonic# configure
sonic(config)# access-list L3 test1 ingress priority 500000
sonic(config-L3-acl-test1)# rule 1 packet-action permit redirect-action ethernet 13
sonic(config-L3-acl-test1)# exit[J
sonic(config)# interface ethernet 13
sonic(config-if-13)# acl test1[J
sonic(config-if-13)# end[J
sonic# exit
stdout_lines: <omitted>

TASK [debug] ***********************
ok: [sonic1] =>
result.stdout: |-
Warning: Permanently added ‘192.168.1.102’ (RSA) to the list of known hosts.
…Entering cli view, please wait…
stty: ‘standard input’: Inappropriate ioctl for device
stty: ‘standard input’: Inappropriate ioctl for device
sonic# configure
sonic(config)# access-list L3 test1 ingress priority 500000
sonic(config-L3-acl-test1)# rule 1 packet-action permit redirect-action ethernet 13
sonic(config-L3-acl-test1)# exit[J
sonic(config)# interface ethernet 13
sonic(config-if-13)# acl test1[J
sonic(config-if-13)# end[J
sonic# exit

TASK [Push klish commands] *****************
changed: [sonic1 -> localhost] => changed=true
stdout: |-
Warning: Permanently added ‘192.168.1.102’ (RSA) to the list of known hosts.
…Entering cli view, please wait…
stty: ‘standard input’: Inappropriate ioctl for device
stty: ‘standard input’: Inappropriate ioctl for device
sonic# configure
sonic(config)# vlan 3003
sonic(config-vlan-3003)# end[J
sonic# exit
stdout_lines: <omitted>

TASK [debug] *********************
ok: [sonic1] =>
result.stdout: |-
Warning: Permanently added ‘192.168.1.102’ (RSA) to the list of known hosts.
…Entering cli view, please wait…
stty: ‘standard input’: Inappropriate ioctl for device
stty: ‘standard input’: Inappropriate ioctl for device
sonic# configure
sonic(config)# vlan 3003
sonic(config-vlan-3003)# end[J
sonic# exit

PLAY RECAP ************************
sonic1 : ok=4 changed=2 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0

PTP，简写自 Precision Time Protocol（精确时间协议） 。顾名思义，PTP 用于为时间同步敏感的系统和应用程序在局域网或广域网上创造高精度时间同步的环境，往往需要通过硬件辅助才能实现。

PTP 在 IEEE 1588 标准中定义，目前已发展到的 IEEE 1588 v2 具有双向通道、纳秒级精度、广泛适应不同接入环境。

PTP 网络的基本架构如下图所示：所有时钟都会按照主从（Master-Slave）关系组织在一起，以GMC为起始点，向各节点逐级同步时钟。

需要注意的是，这种主从关系是相对而言的，因为一些设备不但会从上层设备同步时钟（此时作为从节点/时钟），也会向下层设备发布时钟（此时作为主节点/时钟）。

• Grandmaster Clock：（GMC，大师钟）最高级别的时钟，作为时钟源为整个PTP域提供参考时间。设备一般需要具有GNSS（全球导航卫星系统，例如GPS，北斗等）接收器。GMC的产生方式，可以是手工配置一个静态的，也可以通过最佳主时钟 BMC（Best Master Clock）算法动态选举。
• Boundary Clock（BC，边界时钟）：提供两个或多个物理端口参与PTP域的时间同步，其中一个端口与上游设备同步时间，其他端口将时间发送给下游设备。
• Transparent Clock（TC，透明时钟）：不与其他设备同步时间，仅在其 PTP 端口之间转发 PTP 消息并测量消息的链路延迟。
• Ordinary Clock（OC，普通时钟）：仅提供一个物理端口参与PTP域内的时间同步，通常用作网络的终端节点，连接到需要同步的终端设备。

设备上运行 PTP 协议的端口称为 PTP 端口，其中发布同步时间的端口称为“主端口（Master Port）”，接收同步时间的端口则称为“从端口（Slave Port）”。此外，也有既不接收也不发送同步时间的“被动端口”（Passive Port），它只存在于边界时钟（BC）上。

实现时钟同步主要包括3个步骤：

1. 建立主从关系，选取大师时钟（GMC）、协商端口主从状态等。
2. 频率同步（Frequency synchronization），从节点时间与主节点同步，信号之间保持恒定相位差。
3. 相位同步（Phase synchronization），从节点时间与主节点同步，信号之间相位差恒定为零。

要实现高精度时间同步，很关键的一点是让“从时钟”通过 PTP 报文中携带的时间戳信息，计算与“主时钟”之间的偏移和延时，并据此调整本地时钟来实现时间同步。

根据报文是否携带时间戳，我们可以将PTP报文分为两类：

• 非时间概念报文，进出设备时不会打上时间戳；用于 PTP 网络系统主从关系的建立、时间信息的请求和发布，
• 时间概念报文，进出设备端口会打上精确时间戳；PTP 网络系统会根据报文携带的时间戳计算链路延迟。该类报文包含以下四种：Sync、Delay_Req、Pdelay_Req和Pdelay_Resp。

PTP 网络如何从 PTP 报文中计算得出偏移和延时信息呢？这里就必须说到延迟测量机制，主要有“端到端（E2E）”和“点对点 (P2P) ”两种。

E2E 机制下，中间设备（E2E TC）在转发计时消息的同时，会添加一个停留时间 (rt) ，E2E 机制使用双向消息计算总路径延迟作为时间补偿。

计算公式：
t₂ – t₁ = 偏移 + 延迟
t₄ – t₃ = 延迟 – 偏移
延迟 = (t₂-t₁)+(t₄-t₃)/2
偏移量 = (t₂-t₁)-(t₄-t₃)/2
T_OC_new = T_Master ± 偏移量

不同于 E2E 机制，P2P 的测量机制在会在每一跳交换消息以测量链路延迟，从而实时测量并纠正每跳延迟。

计算公式：
PD1 = (pt2-pt₁)+(pt₃-pt2)/2
PD2 = (pt₄-pt₁)+(pt₄-pt₃)/2
校正字段（correction field） = PD1 + rt
偏移量 = t₂ – t₁ – 校正字段 – PD2
T_OC_new = T_Master ± 偏移量

在 Linux 中，PTP 协议的实现称为 Linux PTP，它基于 IEEE 1588 标准，软件包有 ptp4l 和 phc2sys。

我们基于 ptp4l 和 Linux 网卡做了测试，可以看到：同步精度分布在 1000ns（1μs）以内，并且存在 8000ns（8μs）以上的不稳定跳变。

在没有额外调优工作的前提下，这样的同步精度对于个人爱好者或一般实验环境或许足够，但离企业级商用场景还远远不够。

作为参考，此处列出 ITU（国际电信联盟）提出的时间同步能力分类，

• A类：时间误差≤50ns，适用于对同步精度要求较低的一般电信网络。
• B类：时间误差≤20ns，适用于更严格的时间同步场景，如5G基站同步。
• C类：时间误差≤10ns，主要用于对同步精度要求极高的场景，例如5G前传。

深入研究上述原理和机制后，我们发现 SONiC 开放架构不但能够灵活地满足各种时间同步要求，还能为广大客户提供自由选择，消除供应商锁定。

早在2024年上半年，星融元就引领社区开始着手在 SONiC 中实现 PTP ，并优化其在企业级 SONiC 发行版 AsterNOS 上的性能。

下图是 AsterNOS 内的 PTP 子系统示意图，包含一个运行 Linux PTP / ptp4l 并与 RedistDB 和底层硬件驱动程序交互的 PTP 容器。此外这套系统还支持多种网络管理协议，例如 RESTful API、RESTconf 和 Netconf，给到更优的系统集成和互操作性。

通过硬件加速和软件算法优化的星融元 PTP 交换机的时间同步精度分布在 20ns 以内，并且不同延迟测量模式获得的偏差结果几乎相同。

• one-step：Sync 报文带报文发送时刻的时间戳
• two-step：Sync 报文不带报文发送时刻的时间戳，只记录本报文发送时的时间，由Follow_Up报文带上该报文发送时刻的时间戳。

目前，星融元 CX-M 交换机产品已经系列化地支持了 PTP ，兼容 E2E 和 P2P 模式和多种配置文件。

可在设备模拟器体验 PTP 功能特性 👉

该图展示了一个典型广播和媒体网络拓扑，采用星融元的 PTP 交换机提供多个 PTP 域和冗余时钟源（主备切换），为音频和视频分配单独的域号，在网络中实现 20ns 时间同步精度，确保音频、视频和其他数据流量的无缝对齐。