wan_failover_clab_labs

遵循以下最佳实践的项目将能够自愿的自我认证，并显示他们已经实现了核心基础设施计划（OpenSSF）徽章。

没有一套可以保证软件永远不会有缺陷或漏洞的做法；如果规范或假设是错误的，即使合适的方法也可能失败。也没有哪些做法可以保证一个项目能够维持健康和运作良好的开发者社区。但是，遵循最佳做法可以帮助改善项目的成果。例如，一些做法可以在发布之前进行多人评估，这可以帮助您找到其他难以找到的技术漏洞，并帮助建立信任，并希望不同公司的开发人员之间进行重复的交互。要获得徽章，必须满足所有“必须”和“禁止”的条款，满足所有“应该”条款或有合适的理由，和所有“建议”条款必须满足或未满足（至少希望考虑）。欢迎通过 GitHub网站创建问题或提出请求进行反馈。另外还有一个一般讨论邮件列表。

如果这是您的项目，请在项目页面上显示您的基准徽章状态！基准徽章状态如下所示： 项目12370的基准徽章等级为in_progress 以下是如何嵌入基准徽章：
您可以通过将其嵌入到Markdown文件中来显示您的基准徽章状态：
[![OpenSSF Baseline](https://www.bestpractices.dev/projects/12370/baseline)](https://www.bestpractices.dev/projects/12370)
或者将其嵌入到HTML中：
<a href="https://www.bestpractices.dev/projects/12370"><img src="https://www.bestpractices.dev/projects/12370/baseline"></a>


这些是基准等级2的标准。 这些是标准版本 v2026.02.19。

Baseline Series: 基准等级1 基准等级2 基准等级3

        

 基本

  • 常规

    请注意，其他项目可能使用相同的名称。

    🤖 AI-Driven WAN Failover Agent

    An autonomous AI agent that manages Wide Area Network (WAN) failover in a simulated Hub-and-Spoke environment.

    Instead of relying on traditional, rigid SLA tracking scripts (e.g., "failover if 3 pings drop"), this project uses an LLM (Google Gemini 2.5 Flash) to act as a virtual network engineer. It analyzes real-time network telemetry to make intelligent, dynamic routing decisions.

    💡 Why Build This? (Motivation)

    While dynamic routing protocols (like BGP or OSPF) are undeniably the best approach for WAN failover, the reality is that many firms still rely on static routing for Hub-to-Spoke route advertisement due to legacy constraints, strict security policies, or architectural simplicity.

    I decided to use this common real-world networking constraint as an opportunity to get my hands dirty with Artificial Intelligence. While this AI-driven static failover agent isn't perfect, it serves as a practical, hands-on first leap into bridging the gap between traditional Network Engineering and Generative AI!

    📖 What It Does

    This project simulates a Hub-and-Spoke network topology with dual WAN links (Primary and Backup). An external Python AI Agent constantly monitors the health of the primary link.

    If the primary link degrades or fails, the AI Agent evaluates the telemetry (packet loss and latency) and autonomously rewrites the static routing tables on the virtual routers to seamlessly shift traffic to the backup link. Once the primary link stabilizes, the AI safely fails the traffic back.

    🧠 How It Works (Architecture & Flow)

    1. The Network (Containerlab): * Routers: Two Linux containers running FRRouting (FRR) act as the Hub and Spoke routers.
      • Endpoints: Two Alpine Linux containers act as the hub-server (172.16.11.10) and spoke-host (192.168.10.9).
      • Links: The routers are connected by two distinct point-to-point links (Primary and Backup).
    2. The Telemetry: The Python agent continuously sends ICMP echo requests across the primary link and parses the raw output to extract packet loss percentages and average latency metrics.
    3. The AI Decision Engine: The agent feeds this telemetry into Google's Gemini LLM using strict Boolean logic prompts.
    4. Dynamic Routing: Based on the AI's response (FAILOVER, FAILBACK, or STAY), the Python script uses docker exec to inject or delete ip route commands inside the FRR containers, altering the path of the internal LAN traffic.

    ⚙️ Prerequisites

    To run this lab locally, you will need a Linux environment (Ubuntu/Debian recommended) with the following installed:

    • Docker: Engine to run the containers.
    • Containerlab: Network topology orchestration tool.
    • Python 3.8+: With the python3-venv package installed.
    • Google Gemini API Key: You can get a free API key from Google AI Studio.

    🚀 Step-by-Step Deployment Guide

    Follow these steps to deploy the network, start the AI agent, and test the failover mechanism.

    Step 1: Deploy the Network Topology

    Ensure you are in the root directory of the project where topology.clab.yml is located. Deploy the virtual network using Containerlab:

    sudo clab deploy -t topology.clab.yml
    请使用 SPDX许可证表达格式;例子包括“Apache-2.0”，“BSD-2-Clause”，“BSD-3-Clause”，“GPL-2.0+”，“LGPL-3.0 +”，“MIT”和“(BSD-2-Clause OR Ruby)”。
    如果有多种语言，请将它们列为逗号分隔值（可选空格），并将它们从最多到最少使用。如果有长列表，请至少列出前三个最常见的列表。如果没有语言（例如，这是仅文档或仅测试项目），请使用单个字符“ - ”。请使用每种语言的常规大小写，例如“JavaScript”。
    通用平台枚举（CPE）是用于信息技术系统，软件和软件包的结构化命名方案。在报告漏洞时，它可用于多个系统和数据库。

 控制 0/19 ●

  • 控制


    未知的所需信息，不足以用于徽章。

    当执行CI/CD任务且未指定权限时，CI/CD系统必须将任务的权限默认为管道中授予的最低权限。 [OSPS-AC-04.01]
    配置项目的设置，默认情况下为新管道分配最低可用权限，仅在特定任务需要时才授予额外权限。

    未知的所需信息，不足以用于徽章。

    当创建正式发布时，该发布必须分配一个唯一的版本标识符。 [OSPS-BR-02.01]
    为项目生成的每个发布分配一个唯一的版本标识符，遵循一致的命名约定或编号方案。示例包括SemVer、CalVer或git提交id。

    未知的所需信息，不足以用于徽章。

    当创建正式发布时，该发布必须包含功能和安全修改的描述性日志。 [OSPS-BR-04.01]
    确保所有发布都包含描述性的变更日志。建议确保变更日志是人类可读的，并且包含超出提交消息的详细信息，例如安全影响的描述或与不同用例的相关性。为确保机器可读性，请将内容放在markdown标题下，例如"## Changelog"。

    未知的所需信息，不足以用于徽章。

    当构建和发布管道摄取依赖项时，它必须使用标准化工具（如果可用）。 [OSPS-BR-05.01]
    为您的生态系统使用通用工具，例如包管理器或依赖项管理工具，以在构建时摄取依赖项。这可能包括使用依赖项文件、锁文件或清单来指定所需的依赖项，然后由构建系统拉入。

    未知的所需信息，不足以用于徽章。

    当创建正式发布时，该发布必须进行签名或在包含每个资产加密哈希值的签名清单中进行说明。 [OSPS-BR-06.01]
    在构建时使用加密签名或证明（例如GPG或PGP签名、Sigstore签名、SLSA来源或SLSA VSA）对所有发布的软件资产进行签名。在签名清单或元数据文件中包含每个资产的加密哈希值。

    未知的所需信息，不足以用于徽章。

    当项目发布版本后，项目文档必须包含项目如何选择、获取和跟踪其依赖项的描述。 [OSPS-DO-06.01]
    建议在可公开查看的资源（如源代码存储库、项目网站或其他渠道）上与项目的技术和设计文档一起发布此信息。

    未知的所需信息，不足以用于徽章。

    项目文档必须包含如何构建软件的说明，包括所需的库、框架、SDK 和依赖项。 [OSPS-DO-07.01]
    建议将此信息与项目的贡献者文档一起发布，例如在 CONTRIBUTING.md 或其他开发者任务文档中。也可以使用 Makefile 目标或其他自动化脚本来记录此信息。

    未知的所需信息，不足以用于徽章。

    在活动期间，项目文档必须包含有权访问敏感资源的项目成员列表。 [OSPS-GV-01.01]
    通过项目源代码存储库中的members.md、governance.md、maintainers.md或类似文件等工件记录项目参与者及其角色。这可以简单到在维护者列表中包含姓名或账户句柄，或者根据项目的治理更复杂。

    未知的所需信息，不足以用于徽章。

    在活动期间，项目文档必须包含项目成员的角色和责任的描述。 [OSPS-GV-01.02]
    通过项目源代码存储库中的members.md、governance.md、maintainers.md或类似文件等工件记录项目参与者及其角色。

    未知的所需信息，不足以用于徽章。

    在活动期间，项目文档必须包含代码贡献者指南，其中包括可接受贡献的要求。 [OSPS-GV-03.02]
    扩展项目文档中的CONTRIBUTING.md或CONTRIBUTING/的内容，以概述可接受的贡献要求，包括编码标准、测试要求和代码贡献者的提交指南。建议将该指南作为贡献者和批准者的真实来源。

    未知的所需信息，不足以用于徽章。

    处于活跃状态时，版本控制系统必须要求所有代码贡献者在每次提交时断言他们有合法授权提交相关的贡献。 [OSPS-LE-01.01]
    在项目的代码库中包含一个DCO，要求代码贡献者在每次提交时断言他们有合法授权提交相关贡献。使用状态检查以确保完成此断言。CLA也满足此要求。某些版本控制系统（例如GitHub）可能会在平台服务条款中包含此项。

    未知的所需信息，不足以用于徽章。

    当向主分支提交时，必须通过或手动绕过提交的任何自动化状态检查。 [OSPS-QA-03.01]
    配置项目的版本控制系统，要求所有自动化状态检查通过或在提交合并到主分支之前需要手动确认。建议不要将任何可选状态检查配置为批准者可能会绕过的通过或失败要求。

    未知的所需信息，不足以用于徽章。

    在接受提交之前，项目的CI/CD管道必须运行至少一个自动化测试套件，以确保更改符合预期。 [OSPS-QA-06.01]
    应在每次合并到主分支之前运行自动化测试。测试套件应在CI/CD管道中运行，结果应对所有贡献者可见。测试套件应在一致的环境中运行，并应以允许贡献者在本地运行测试的方式运行。测试套件的示例包括单元测试、集成测试和端到端测试。

    未知的所需信息，不足以用于徽章。

    当项目发布版本时，项目文档必须包括设计文档，展示系统中的所有操作和参与者。 [OSPS-SA-01.01]
    在项目文档中包括说明操作和参与者的设计。参与者包括可以影响系统中另一段的任何子系统或实体。确保为新功能或重大更改更新此文档。

    未知的所需信息，不足以用于徽章。

    当项目发布版本时，项目文档必须包括对已发布软件资产的所有外部软件接口的描述。 [OSPS-SA-02.01]
    记录已发布软件资产的所有软件接口（API），解释用户如何与软件交互以及期望或产生什么数据。确保为新功能或重大更改更新此文档。

    未知的所需信息，不足以用于徽章。

    当项目发布版本时，项目必须执行安全评估，以了解软件中可能发生的最可能和最具影响力的潜在安全问题。 [OSPS-SA-03.01]
    执行安全评估可以告知项目成员和下游消费者，项目了解软件中可能出现的问题。了解可能实现的威胁有助于项目管理和应对风险。此信息对下游消费者很有用，可以证明项目的安全敏锐度和实践。确保为新功能或重大更改更新此文档。

    未知的所需信息，不足以用于徽章。

    处于活跃状态时，项目文档必须包括协调漏洞披露（CVD）的政策，并有明确的响应时间框架。 [OSPS-VM-01.01]
    在目录根目录创建一个SECURITY.md文件，概述项目的协调漏洞披露政策。包括报告漏洞的方法。设定项目将如何响应和处理报告问题的期望。

    未知的所需信息，不足以用于徽章。

    处于活跃状态时，项目文档必须提供一种方法，用于直接向项目内的安全联系人私下报告漏洞。 [OSPS-VM-03.01]
    为安全研究人员提供一种方式，以私下向项目报告漏洞。这可能是专用电子邮件地址、Web表单、VCS专用工具、安全联系人的电子邮件地址或其他方法。

    未知的所需信息，不足以用于徽章。

    处于活跃状态时，项目文档必须公开发布有关已发现漏洞的数据。 [OSPS-VM-04.01]
    在可预测的公共渠道（例如CVE条目、博客文章或其他媒体）中提供有关已知漏洞的信息。在可能的情况下，此信息应包括受影响的版本、消费者如何确定他们是否容易受到攻击以及缓解或修复的说明。


该数据可在社区数据许可协议 – 许可性，版本 2.0 (CDLA-Permissive-2.0)下获取。这意味着数据接收方可以共享数据，无论是否经过修改，只要数据接收方在共享数据时提供本协议文本。请注明Pradeep Babar和OpenSSF最佳实践徽章贡献者。

项目徽章条目拥有者： Pradeep Babar.
最后更新于 2026-04-04 19:03:11 UTC, 最后更新于 2026-04-04 19:29:42 UTC。