SONIC NOS介绍（官方文档完美翻译）

已于 2024-03-04 19:40:30 修改
阅读量1k 收藏 27
点赞数 25
分类专栏： 云原生网络 文章标签： 系统架构 云原生 网络
于 2024-03-04 19:38:23 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/SuperMan_liy/article/details/136459868
版权

Referenced Documents 参考文献

#Document Title 文档标题Document和链接
1SONiC official wiki官方维基Home · sonic-net/SONiC Wiki · GitHub
2SONiC architecture https://github.com/sonic-net/SONiC/wiki/Architecture
3SAI APIGitHub - opencomputeproject/SAI: Switch Abstraction Interface
4Redis documentation https://redis.io/docs/
5Click module Welcome to Click — Click Documentation (5.x)
6JSON的介绍JSON
7SONiC支持的平台https://github.com/sonic-net/SONiC/wiki/Supported-Devices-and-Platforms
8SONiC软件架构2018研讨会Videos Slides 

一、SONIC系统架构

        SONiC系统的架构由各种模块组成，这些模块通过一个集中的和可扩展的基础设施相互交互。这个基础设施依赖于redis数据库引擎的使用：一个键值数据库，提供一个语言独立的接口，一种数据持久性的方法，在所有SONiC子系统之间进行复制和多进程通信。

        通过依赖redis引擎基础设施提供的发布者/订阅者消息传递范式，应用程序可以只订阅它们需要的数据视图，并避免与它们的功能无关的实现细节。

        SONiC将每个模块放在独立的docker容器中，以保持语义相似组件之间的高内聚性，同时减少不相干组件之间的耦合。这些组件的编写完全独立于与底层抽象交互所需的特定于平台的细节。

        截至今天，SONiC 将主要的功能组件分解为以下 docker 容器：Dhcp-relay、Pmon 、Snmp、Lldp 、Bgp 、Teamd 、Database 、Swss 、Syncd 。

        下图显示了每个docker容器中封装的功能的高级视图，以及这些容器之间如何相互作用。请注意，并不是所有的SONiC应用程序都与其他SONiC组件交互，因为其中一些组件从外部实体收集它们的状态。我们使用蓝色箭头来表示与集中式redis引擎的交互，黑色箭头表示所有其他的交互(netlink，/sys文件系统等)。

        尽管SONiC的大部分主要组件都保存在docker容器中，但仍有一些关键模块位于linux主机系统中。例如SONiC的配置模块(sonic-cfggen)和SONiC的CLI。

        所有可能的组件交互和相关状态转移的更完整的图景将在本文档的后续章节中介绍。

二、SONiC子系统描述

本节旨在描述每个docker容器中包含的功能，以及从linux主机系统中操作的关键SONiC组件。这里的目标是为读者提供一个高级介绍；在后续章节中将提供更图形化和(希望)更直观的方法。

Teamd container: 在SONiC设备中运行链路聚合功能(LAG)。“teamd”是一个基于Linux的LAG协议开源实现。“teamsyncd”进程允许“teamd”和南向子系统之间的交互。

Pmon container: 负责运行“sensord”，一个后台程序，用于周期性地记录来自硬件组件的传感器读数，并在发出警报时发出警报。Pmon 容器还托管“fancontrol”进程，以便从相应的平台驱动程序收集与风扇相关的状态。

Snmp container:  托管snmp 特性。在这个容器中有两个相关的进程：

  • Snmpd:实际的snmp服务器，负责处理来自外部网络元素的传入snmp轮询。

  • Snmp-agent (sonic_ax_impl): 这是SONiC的实现一个 AgentX snmp子代理。这个子代理提供主代理(snmpd) 与信息收集从SONiC数据库集中redis引擎。

Dhcp-relay container: dhcp-relay 代理允许从没有 DHCP 服务器的子网中转 DHCP 请求到其他子网中的一个或多个 DHCP 服务器。

Lldp container: 顾名思义，这个容器托管 lldp 功能。以下是运行在这个容器中的相关进程：

  • Lldp: 具有 lldp 功能的实际 lldp 守护进程。这个进程与外部对等体建立 lldp 连接，以发布/接收系统功能。

  • Lldp_syncd: 负责上传lldp的发现状态到集中式系统的消息基础架构(redis-engine)的进程。 通过这样做，lldp状态将被传递到对使用该信息感兴趣的应用程序(例如snmp)。

  • Lldpmgr: Lldpmgr进程为lldp守护进程提供增量配置功能；它通过订阅redis引擎中的STATE_DB来实现。有关本主题的详细信息，请参阅下面的内容。

Bgp container: 运行一个受支持的路由栈：Quagga 或 FRR。尽管该容器是以使用的路由协议命名的(bgp)，但实际上，这些路由栈可以运行各种其他协议(如ospf, isis, ldp等)。

BGP容器的功能分解如下：

  • bgpd: 常规bgp实现。来自外部的路由状态通过常规tcp/udp套接字接收，并通过zebra/fpmsyncd接口下推到转发平面。

  • zebra: 充当传统的IP路由管理器，也就是说，它提供内核路由表更新、接口查找和跨不同协议的路由重分发服务。Zebra还负责将计算出的FIB下推到内核(通过netlink接口)和转发过程中涉及的南向组件(通过转发平面管理器接口FPM)。

  • fpmsyncd: 负责收集zebra生成的FIB状态，并将其内容转储到redis引擎中的应用数据库表(APPL_DB)的小型守护进程。

Database container: 托管redis数据库引擎。 SONiC应用程序可以通过redis守护进程为此目的公开的UNIX套接字访问这个引擎中保存的数据库。 这些是redis引擎托管的主要数据库：

  • APPL_DB: 存储所有应用程序容器生成的状态——路由、下一跳、邻居等。这是所有希望与其他SONiC子系统交互的应用程序的南向入口点。

  • CONFIG_DB: 存储由SONiC应用程序创建的配置状态——端口配置、接口、vlan等。

  • STATE_DB: 存储系统中配置的实体的“关键”操作状态。这个状态用于解决不同SONiC子系统之间的依赖关系。例如，LAG portchannel(由teamd子模块定义)可以潜在地引用物理端口，这些物理端口可能存在，也可能不存在于系统中。另一个例子是VLAN的定义(通过vlanmgrd组件)，它可以引用端口成员，这些端口成员的存在在系统中是未确定的。 本质上，这个DB存储所有被认为是解决跨模块依赖关系所必需的状态。

  • ASIC_DB: 存储驱动asic配置和操作所需的状态——这里的状态以asic友好的格式保存，以便于syncd(见下面的详细信息)和asic SDK之间的交互。

  • COUNTERS_DB: 存储系统中与每个端口相关的计数器/统计信息。这种状态可以用来满足CLI本地请求，或者为远程消费提供遥测通道。

Swss container: Switch State Service(SwSS)容器由一系列工具组成，允许所有SONiC模块之间进行有效的通信。如果说数据库容器擅长提供存储功能，那么Swss主要专注于提供各种机制，以促进所有不同方之间的通信和仲裁。

Swss还承载负责与SONiC应用层北向交互的进程。但也有例外，如前所述，fpmsyncd、teamsyncd和lldp_syncd进程分别在bgp、teamd和lldp容器上下文中运行。 不管这些进程在哪个上下文中运行(在swss容器内部或外部)，它们都有一个共同的目标：提供允许SONiC应用程序和SONiC的集中式消息基础设施(redis-engine)之间连接的方法。这些守护进程通常通过所使用的命名约定来识别：*syncd。

  • Portsyncd: 监听与端口相关的netlink事件。在启动期间， portsyncd通过解析系统的硬件配置文件来获取物理端口信息。在所有这些情况下，portsyncd最终将所有收集到的状态推入APPL_DB。属性如端口速度、通道和MTU通过这个通道传输。 Portsyncd还将状态注入STATE_DB。更多细节请参阅下一节。

  • Intfsyncd: 监听与接口相关的netlink事件，并将收集到的状态推入APPL_DB。与接口相关的新/已更改的IP地址等属性由该进程处理。

  • Neighsyncd: 监听由ARP处理结果中新发现的邻居触发的邻居相关的netlink事件。属性，如MAC地址和邻居的地址族由这个守护进程处理。这个状态最终将用于构建数据平面中用于L2重写目的的邻接表。 再一次，所有收集到的状态最终被转移到APPL_DB。

  • Teamsyncd: 之前讨论过，在Teamd docker容器中运行。和之前的例子一样，获取到的状态被推入到APPL_DB中。

  • Fpmsyncd: 之前讨论过，在bgp docker容器中运行。同样，收集到的状态被注入到APPL_DB中。

  • Lldp_syncd: 之前也讨论过，在 lldp docker 容器中运行。

上面的进程很明显是作为状态生产者，因为它们将信息注入redis引擎所代表的发布者-订阅者管道中。但显然，必须有另一组进程作为订阅者，愿意使用和重新分发所有这些传入的状态。这正是以下守护进程的情况：

  • Orchagent:Swss子系统中最关键的组件。 Orchagent包含提取所有由syncd守护进程注入的相关状态的逻辑，相应地处理和发送这些信息，并最终将其推向其南向接口。 这个南向接口也是redis引擎中的另一个数据库(ASIC_DB)，因此我们可以看到，Orchagent既作为消费者(例如来自APPL_DB的状态)，也作为生产者(被推入ASIC_DB的状态)运行。

  • IntfMgrd: 响应来自APPL_DB,CONFIG_DB和STATE_DB的状态，以配置linux内核中的接口。只有当被监控的任何数据库中没有冲突或不一致的状态时，才能完成此步骤。请参阅上面的数据库容器部分，以了解这种不希望的行为的示例。

  • VlanMgrd: 响应来自 APPL_DB,CONFIG_DB 和 STATE_DB 的状态，在linux内核中配置vlan接口。在IntfMgrd的情况下，只有当没有依赖状态/条件未满足时才会尝试这个步骤。

Syncd container:简而言之，syncd容器的目标是提供一种机制，允许交换机的网络状态与实际的硬件/ASIC同步。这包括初始化、配置和交换机的ASIC当前状态的收集。

容器中的主要逻辑组件如下：

  • Syncd: 负责执行上述同步逻辑的进程。在编译时，syncd 链接到硬件供应商提供的 ASIC SDK 库，并通过调用为此提供的接口向 ASIC 注入状态。Syncd 订阅 ASIC_DB 以从 SWSS 参与者接收状态，同时注册为发布者以推送来自硬件的状态。

  • SAI API: 交换机抽象接口(SAI)定义了API，以提供一种独立于供应商的方式来控制转发元素， 例如以统一的方式控制交换ASIC、NPU或软件交换机。有关SAI API的更多细节，请参阅[3]。

  • ASIC SDK: 硬件供应商被期望提供SAI友好的SDK实现，以驱动其ASIC。该实现通常以动态链接库的形式提供，该库挂接到负责驱动其执行的驱动进程(在本例中为syncd)。

CLI / sonic-cfggen: 负责提供CLI功能和系统配置功能的SONiC模块。

  • CLI组件严重依赖于Python的Click库，为用户提供一种灵活和可定制的方法来构建命令行工具。

  • Sonic-cfggen 组件由 SONiC 的 CLI 调用，以执行配置更改或任何需要与 SONiC 模块进行配置相关交互的操作。

SONiC Subsystems InteractionsSONiC子系统交互

本节旨在为读者提供对发生在各种SONiC组件之间的一组交互的详细理解。 为了使信息更易于理解，我们已经捆绑了所有我们可以想象到的系统交互，关注每个主要功能所交换的特定状态。

LLDP-state interactions

下图描述了在LLDP状态转移事件期间观察到的交互集。在这个特定的示例中，我们正在迭代发生在携带状态更改的LLDP消息到达时发生的步骤序列。

(1) 在LLDP容器初始化期间，lldpmgrd订阅STATE_DB以获得系统中物理端口状态的实时提要——lldpmgrd的轮询周期每5秒运行一次。基于此信息，Lldpd(及其网络对等体)将保持对系统端口状态的变化和任何影响其操作的配置变化的意识。

(2) 在某个时刻，一个新的LLDP包到达内核空间的lldp进程的socket。内核的网络栈最终将相关的有效负载传递给lldp进程。

(3) lldp解析并消化这个新状态，最终由lldp_syncd在执行lldpctl cli命令时获取—— 通常每10秒运行一次。

(4) Lldp_syncd 将这个新状态推入 APPL_DB，具体到表LLDP_ENTRY_TABLE。

(5) 从此刻起，所有订阅了这个表的实体都应该接收到新状态的一个副本(目前，snmp是唯一感兴趣的侦听器)。

SNMP-state interactions. SNMP状态交互。

如前所述，snmp容器同时拥有snmp主代理(snmpd)和SONiC特有的agentX进程(snmp_subagent)。 这个子代理与所有redis数据库/表格交互，这些数据库/表格提供信息，可以从中获得MIB状态。具体来说，snmp-agent订阅以下数据库/表格：

  • APPL_DB: PORT_TABLE, LAG_TABLE, LAG_MEMBER_TABLE, LLDP_ENTRY_TABLE

  • STATE_DB: *

  • COUNTERS_DB: *

  • ASIC_DB: ASIC_STATE:SAI_OBJECT_TYPE_FDB*

下图描述了在系统处理传入的snmp查询期间，各种SONiC组件之间的典型交互。

(0) 在初始化不同的MIB子组件支持在snmp-subagent进程，这一个建立连接与各种DB上所述。从此刻起，从所有这些DB获得的状态缓存本地snmp-subagent。此信息每几秒钟刷新(< 60)以确保DB和snmp-subagent完全同步。

(1) 一个snmp查询到达内核空间的snmp套接字，内核的网络栈将数据包传递给snmpd进程。

(2) 解析snmp消息，并向SONiC的agentX子代理发送一个相关请求(即sonic_ax_impl)。

(3) snmp-subagent 将缓存在本地数据结构中的状态用于查询，并将信息发送回 snmpd 进程。

(4) Snmpd最终通过通常的套接字接口将一个应答发送回发送者。

Routing-state interactions.路由状态交互。

I在本节中，我们将重复执行SONiC中处理从eBGP对等端接收到的新路由的步骤序列。我们将假设该会话已经建立，并且我们正在学习使用直接连接的对等端作为下一跳的新路由。

下图显示了这个过程中涉及的元素。 请注意，我故意省略了与 SONiC 体系结构描述无关的细节。

(0) 在BGP容器初始化期间，zebra通过一个常规的TCP套接字连接到fpmsyncd。在稳定/非瞬态条件下， zebra、linux内核、APPL_DB和ASIC_DB中的路由表被期望完全一致/等效。

(1) 一个新的TCP包到达内核空间bgp的socket，内核的网络栈最终将相关的有效负载传递给bgpd进程。

(2) (2) Bgpd解析新的数据包，处理bgp-update，并通知zebra这个新前缀的存在及其相关协议next-hop。

(3)  在zebra确定这个前缀的可行性/可达性(例如现有的转发nh)后，zebra生成一条route-netlink消息，将这个新状态注入内核。

(4) Zebra 使用 FPM 接口将这个 netlink-route 消息传递给 fpmsyncd。

(5) Fpmsyncd处理netlink消息并将此状态推入APPL_DB。

(6) 被orchagentd为APPL_DB订阅者后，它将接收到先前推送到APPL_DB的信息的内容。

(7) 处理完接收到的信息后，orchagentd 将调用 sairedis APIs 将路由信息注入到 ASIC_DB。

(8) 由于是 ASIC_DB 订阅者，它将接收到由 orchagentd 生成的新状态。

(9) Syncd 将处理信息并调用 SAI API 将此状态注入到相应的 asic-driver 中。

(10) 新的路线终于被推向硬件。

Port-state interactions. 端口状态交互。

本节描述在端口相关信息的传输过程中发生的系统交互。考虑到 portsyncd 所扮演的关键角色，以及它在其他 SONiC 子系统中所施加的依赖性，我们从它的初始化过程开始本节。

这个练习的目标有两个。首先，我们正在公开系统中对产生或使用端口相关信息感兴趣的多个组件。其次，我们正在通过一个图形示例向读者介绍如何在系统中使用 STATE_DB，以及不同的应用程序如何依赖其内部操作的信息。

(0) 在初始化期间，portsyncd建立与redis引擎中主要数据库的通信通道。portsyncd声明其意图是作为对APPL_DB和STATE_DB的发布者，以及作为CONFIG_DB的订阅者。同样，portsyncd也订阅了负责携带端口/链接状态信息的系统的netlink通道。

(1) Portsyncd 首先解析与系统中使用的硬件配置文件/SKU 相关的端口配置文件(port_config.ini)(更多细节请参考配置部分)。与端口相关的信息，如通道、接口名、接口别名、速度等，通过这个通道传输到 APPL_DB。

(2)Orchagent 会接收到所有这些新状态，但是会推迟对它的操作，直到 portsyncd 通知它已经完全解析完 port_config.ini 信息。一旦发生这种情况，orchagent 将开始在硬件/内核中初始化相应的端口接口。Orchagent 调用 sairedis API 通过通常的 ASIC_DB 接口将这个请求传递给 syncd。

(3) Syncd通过ASIC_DB接收到这个新请求，并准备调用满足Orchagent请求所需的SAI API。

(4) Syncd使用SAI APIs ASIC SDK创建内核主机接口，这些接口与初始化的物理端口相关。

(5) 前一步将生成一个netlink消息，该消息将被portsyncd接收。在与之前从port_config.ini(步骤1)解析的所有端口相关联的消息到达portsyncd时，portsyncd将继续声明“初始化”过程已完成。

(6) 作为前一步的一部分，portsyncd 将一个记录条目写入到 STATE_DB 中，这个记录条目对应于每个成功初始化的端口。

(7) 从此刻起，以前订阅了STATE_DB内容的应用程序将收到一个通知，允许这些应用程序开始使用它们所依赖的端口。换句话说，如果在STATE_DB中没有找到一个特定端口的有效条目，则没有应用程序能够使用它。

<span style="color:#24292f"><span style="background-color:#ffffff"><span style="color:var(--fgColor-default, var(--color-fg-default))"><span style="background-color:var(--bgColor-muted, var(--color-canvas-subtle))"><code>NOTE : As of today, these are the applications actively
listening to the changes in STATE_DB: teamsyncd, intfmgrd, vlanmgrd
and lldpmgr. We will cover all these components in subsequent
sections -- lldpmgr has been already tackled above.
</code></span></span></span></span>

现在，让我们重复当物理端口关闭时发生的步骤序列：

(0) 正如前面概述部分提到的，syncd 在 ASIC_DB 上下文中既作为发布者又作为订阅者。 “订阅者”模式显然是由于 syncd 需要从北向应用程序接收状态，这是迄今为止看到的所有模块交互的情况。需要“发布者”模式，以允许 syncd 通知高级组件硬件产生的事件的到来。

(1)  当相应的ASIC的光模块检测到载波丢失时，向相关驱动程序发送通知，该驱动程序将该信息传递给syncd。

(2) Syncd调用适当的通知处理程序，并向ASIC_DB发送端口关闭事件。

(3)Orchagent使用它的通知线程(专门用于这个任务)从ASIC_DB收集新状态，并执行'port-state-change'处理程序：

<span style="color:#24292f"><span style="background-color:#ffffff"><span style="color:var(--fgColor-default, var(--color-fg-default))"><span style="background-color:var(--bgColor-muted, var(--color-canvas-subtle))"><code>a.  Generate an update to APPL\_DB to alert applications relying on
    this state for their operation (e.g. CLI -- "show interface
    status").

b.  Invoke sairedis APIs to alert syncd of the need to update the
    kernel state associated to the host-interface of the port being
    brought down. Again, orchagent delivers this request to syncd
    through the usual ASIC\_DB interface.
</code></span></span></span></span>

(4) Syncd通过ASIC_DB接收到这个新请求，并准备调用SAI API来满足orchagent的请求。

(5) Syncd使用SAI APIs ASIC SDK来更新内核，使其具有受影响的主机接口的最新操作状态(DOWN)。

(6) 在 portsyncd 接收到与前一步相关的 netlink 消息，它被悄悄地丢弃，因为现在所有的 SONiC 组件都完全知道端口关闭事件。

Interface-state interactions.接口状态交互。

Neighbor-state interactions.邻国互动。

LAG-Interface-state interactions.LAG-接口状态交互。

Configuration-state interactions.配置-状态交互。

一只理智毅
关注
  • 25
    点赞
  • 踩
  • 27
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
sonic visualiser用户指南使用说明文档（备注版）
06-04
sonic visualiser官方给出的使用说明，存为pdf格式。无奈说明全是英文，且讲的不是特别清楚，初学使用的时候只能摸索着学。pdf中添加了我自己的一点学习笔记，仅供参考。软件新手，有大神请多赐教。
go-sonic:用Go编写的Sonic驱动程序
05-25
为声音搜索后端转到客户端 这个软件包实现了所有与音速一起使用的命令。 如果缺少一个，请打开一个问题！ :) 音速： ： 安装 go get github.com/expectedsh/go-sonic 例子 package main import ( "fmt" "github.com/expectedsh/go-sonic/sonic" ) func main () { ingester , err := sonic . NewIngester ( "localhost" , 1491 , "SecretPassword" ) if err != nil { panic ( err ) } // I will ignore all errors for demonstration purposes _ = ingester . BulkPush ( "movi
SONiC镜像编译指南
筋斗云计算
05-30 7268
1.准备工作 在一台Linux系统的主机或服务器上安装最新版本的 docker CE，然后再进行接下来的操作。 创建Linux操作系统用户nocsys，且该用户要加入docker 用户组中： sudo useradd -d /home/nocsys -m -g docker nocsys 设定nocsys用户的密码： sudo passwd nocsys 编辑 /etc/sudoers...
开放网络操作系统介绍(2)、SONiC
热门推荐
筋斗云计算
04-23 2万+
在2015年3月举行的OCP（Open Compute Project，开放计算项目）峰会上， 微软向OCP贡献SAI （Switch Abstraction Interface，交换机抽象接口）。当年7月，OCP正式接纳了SAI 。 2016年3月9日，微软在这届OCP峰会上，正式发布了SONiC ( Software for Open Networking in the Cloud)。SON...
开源网络操作系统SONIC安装配置说明
05-31
开源网络操作系统SONIC安装配置说明
sonic的架构
07-12
简单介绍一下sonic的架构，从sonic的官网上获取资源并翻译。
Sonic 开源移动端云真机测试平台 - windows系统下的sonic快速部署演示
最新发布
HRD的博客
01-10 435
Sonic 开源移动端云真机测试平台 - windows系统下的sonic快速部署演示。
SONiC系统架构
Greyplayground
02-20 3961
SONiC系统由两部分组成： 1.彼此交互的模块 2.用于交互的基础设施（集中式，可扩展） 其中用于交互的基础设施主要是一个非关系型数据库Redis引擎： 1.提供了一个无视语言的接口 2.是一种数据保持，复制和多进程交互的手段 每个模块只订阅自己关注的数据 每个模块都存在于各自的Docker容器里形成独立的组件，每个组件都与平台细节完全解耦 SONiC由一下几个容器组成： Dhcp-relay Pmon Snmp Lldp Bgp Teamd Database Swss Syncd 下图描绘出了每个模
SONiC系统的散热控制
weixin_44316184的博客
05-21 105
现在的网络设备功耗越来越大，动辄几百瓦的功耗对设备内部的散热设计提出了很大的挑战。极端的解决方案是把整个设备浸泡在液体里面，通过液体相变散热，或者液体的流动带走热量。这样做可以达到非常高的功率密度，但是对电子设备的设计和用于导热的液体也提出了很高的要求。或者采用水冷的方式，通过管道将低温的水引导到每个芯片上的水冷散热器上，通过管道内部的水流经散热器带走热量。这种方式对管道接头提出了很高的要求，需...
【翻译】西川善司 SONIC1
08-03
角色和背景的交互时的姿势控制的IK处理上，要利用HAVOKAnimation。把游戏图形做出皮克斯（Pixar）CG 电影的环境感经常可以听到[在 3D 游戏图
音频倍速播放之sonic
04-10
音频倍速播放，不变音，不变调，sonic，调用简单不复杂，可以看我的github上也有免费的https://github.com/xhc2/MyFFmpeg
sonix：Sonic Search的Elixir客户端
02-05
sonix：Sonic Search的Elixir客户端
sonic-express：在swagger上自动生成API文档
02-05
加速您在Express上熟练的文档体验。 这是做什么的？ 这将与Express res和req API挂钩，并为您自动记录每个响应，因此您不必这样做。 想象一下编写100个API并将其完整记录下来，这对您有帮助。 如何使用它 安装...
Spring Security-3.0.1中文官方文档(翻译版)
03-08
Spring Security-3.0.1 中文官方文档（翻译版） 这次发布的Spring Security-3.0.1 是一个bug fix 版，主要是对3.0 中存在的一些问题进 行修 正。文档中没有添加新功能的介绍，但是将之前拼写错误的一些类名进行...
2021-01-07 SONiC系统管理1 SONiC Management framework
weixin_44316184的博客
01-07 1498
SONiC系统管理 SONiC Management framework SONiC系统提供多种管理接口，包括CLI人机接口，REST/RESTCONF接口，gNMI接口和SNMP接口，SNMP属于传统的设备管理协议，但是在SONiC里面处于待研究状态。 SONiC支持标准的YANG模型和自定义的YANG模型，SONiC支持的CLI也是业界统一的CLI风格。 用户认证方面SONiC支持多种认证方式。 SONiC上的设备管理功能的开发遵循基于数据模型(Data Model)的自动化开发方法，开发者根据设备的功
Centos7部署Sonic前后端和Agent 端
檬柠wan
02-17 1277
Sonic是一款开源、支持分布式部署、在线自动化测试的私有云真机平台
SONiC系统的告警和事件管理
weixin_44316184的博客
08-13 241
SONiC系统的告警和事件管理
SONiC sai的官方文档在哪
05-27
SONiC的SAI官方文档存储在GitHub上。你可以通过以下链接来访问官方文档： https://github.com/opencomputeproject/SAI/tree/master/doc 在这里，你可以找到有关SAI API的详细说明、示例代码、常见问题解答和其他相关文档。这些文档都是开放源代码的，可以帮助你更好地了解SAI的实现和使用方法。此外，如果你有其他关于SONiC和SAI的问题，可以到SONiC的官方GitHub页面上寻找答案，或者在SONiC社区论坛上提问，社区里的成员会很乐意帮助你。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值