多厂商蛇形拓扑自动化配置脚本
背景
最近正好有个RFC2544测试，之前都是L2蛇形居多，这次测试下路由蛇形。在此类测试中，“路由蛇形拓扑”（Snake-like Routing Topology）是一种具有代表性的测试模型。该模型要求流量按照预先规划的逻辑顺序，在一台交换机上创建多个虚拟路由转发（VRF）实例，通过一系列指定端口进行有序转发。然而，此类拓扑手动配置较复杂，逻辑需要逐一捋顺，重复工作多，比较费时间。
为应对上述挑战，我请AI（grok -> gemini）开发一个自动化的Python脚本。此脚本旨在通过程序化方式生成网络配置，从手动配置工作中解放出来，显著提升测试环境部署的效率与准确性。其最终交付成果是一个能够根据用户提供的基础拓扑信息，自动生成适用于多种主流网络设备操作系统（包括H3C, Huawei, Cisco, Juniper, SONiC）完整配置文件的软件工具（目前只测试了H3C的系统，其他系统待测试，估计使用时需要些许调整，后面用到了再完善吧）。
脚本概要
本文档对该自动化脚本的设计理念、架构及实现细节进行了详细的阐述。通过多轮迭代优化，该脚本展现出以下三个核心特性：
- 路径驱动的IP规划：脚本的IP地址与网段分配逻辑，严格遵循由入口至出口的流量路径，而非基于简单的数字或名称排序。这一设计确保了生成的网络配置在逻辑上具有高度的直观性和可追溯性。
- 多厂商支持与模板化设计：脚本通过将厂商特定的命令语法（表现层）与核心的配置逻辑（业务逻辑层）进行解耦，实现了对多种主流网络操作系统的支持。此模块化设计赋予了脚本强大的可扩展性。
- 数据与逻辑分离：脚本的运行由用户定义的纯数据结构驱动。用户仅需在指定的区域内定义网络拓扑参数，无需修改核心的算法与逻辑代码，从而极大地降低了使用门槛并提高了工具的复用性。
核心网络逻辑实现
跨VRF物理互联：不同VRF，同一子网，eBGP邻居
网络设计原则：当两个物理端口通过点对点链路互联，且分别属于不同的VRF时，为实现第三层网络的连通性，这两个端口必须被配置在同一个IP子网之内。同时，必须在这两个端口间建立eBGP邻居关系，以实现路由信息交换和跨VRF的流量转发
脚本实现机制：
- 脚本接收用户在connections_data列表中定义的物理连接，例如(“400GE1/0/1”, “400GE2/0/2”)。
- 在路径发现阶段，该算法将此端口对识别为一个离散的“路径段”。
- 在IP规划阶段，此“路径段”被分配一个唯一的、共享的IP子网（例如 192.168.1.0/24），其内部的两个端口则被赋予此子网内的主机地址（如 .1 和 .2）。
- 在BGP配置生成阶段，脚本检测到这对端口分属于不同的VRF实例（因此具有不同的AS号），随即自动生成peer <对端IP> as-number <对端AS>的eBGP邻居配置指令，当然需要结合fake-as来实现多AS互联的假象。
VRF内部路由：同一VRF，不同子网，路由转发
网络设计原则：在单一VRF实例内部，承载不同网络功能的端口（例如，一个用于连接外部测试仪的端口与一个用于内部蛇形互联的端口）应当被划分到不同的IP子网。这些子网间的通信通过VRF内部的路由表进行转发，无需建立BGP邻居关系。
脚本实现机制：
- 根据vrf_port_groups_data的定义，vrf1同时包含port1（内部互联端口）和port2（测试仪接口）。
- 脚本的路径发现算法将port1本身视为一个独立的“路径段”（作为流量的入口），而将port2与其对端port1的连接视为另一个独立的“路径段”。
- 因此，在IP规划阶段，port1和port2所在的链路被自然地分配了两个不同的、在地址空间上连续的IP子网（例如，port1链路获得192.168.1.0/24，port2链路获得192.168.2.0/24）。
- 此机制确保了在同一VRF内部，不同功能的端口使用不同网段，符合网络隔离与路由设计的最佳实践。
拓扑灵活性与适配性
该脚本的一个显著优势在于其对物理布线拓扑的高度适应性。其核心的“路径发现”算法关注的是端口之间的逻辑连接关系，而非其物理布局。只要用户在connections_data中准确地定义了物理连接，脚本即可自动识别并适配相应的拓扑结构。以下为两种典型的受支持拓扑。
Topology1，斜向蛇形互联
VRF1/AS1 VRF2 VRF3 VRF4
┌───┐ ┌───┐ ┌───┐ ┌───┐
┤ 1 ├----. ┤ 3 ├----. ┤ 5 ├----. ┤ 7 ├──
└───┘ \ └───┘ \ └───┘ \ └───┘
\ \ \
\ \ \
┌───┐ \ ┌───┐ \ ┌───┐ \ ┌───┐
--┤ 2 ├ '┤ 4 ├ '┤ 6 ├ '┤ 8 ├
└───┘ └───┘ └───┘ └───┘
VRF1/AS1 VRF2 VRF3 VRF4connections_data 定义示例:
[("1","4"), ("3","6"), ("5","8"), ("7","2"), ...]Topology2，垂直蛇形互联
VRF3 VRF3/AS3 VRF1 VRF1/AS1
┌───┐ ┌───┐ ┌───┐ ┌───┐
┤ 35├ ┤ 33├ ┤ 31├ ┤ 29├──--
└───┘ └───┘ └───┘ └───┘
| | |
┌───┐ ┌───┐ ┌───┐ ┌───┐
┤ 36├ ┤ 34├ ┤ 32├ ┤ 30├──--
└───┘ └───┘ └───┘ └───┘
VRF4/AS4 VRF2 VRF2/AS2 VRF4connections_data 定义示例:
[("31","32"), ("33","34"), ("35","36"), ...]脚本的get_network_data函数通过追踪port_to_peer映射关系，能够可靠地解析出完整的逻辑路径，从而保证了对不同物理连线方式的普适性。
脚本执行与扩展
操作流程
用户的主要交互点被严格限定在脚本末尾的if __name__ == "__main__":代码块内的三个特定区域：
- 拓扑定义: 用户需根据实际物理连接，修改connections_data, tester_ports_data, 和 vrf_port_groups_data这三个列表。
- IP地址规划: 用户需通过修改start_ipv4_addr和start_ipv6_addr变量，来指定起始IP地址段。
- 厂商选择: 用户需修改selected_vendor变量的值（例如 ‘h3c’, ‘sonic’ 等），以选择目标配置文件的输出格式
扩展性说明
得益于模板化的设计，为脚本添加对新厂商的支持流程清晰。以添加Arista EOS为例，操作步骤如下（本人还未尝试，后尝试后再反馈）：
- 复制模板: 复制一份现有的模板字典（如H3C_TEMPLATES），并重命名为ARISTA_TEMPLATES。
- 适配语法: 修改新字典中的命令字符串，使其符合Arista EOS的命令行语法。
- 创建/复用渲染函数: 若Arista的CLI结构与H3C类似（层级式），可复用render_hierarchical_config函数。若其结构差异显著（如Junos的set命令），则需为其创建一个新的render_arista_config函数。
- 注册至主程序: 在main函数底部的vendor_map字典中，添加一个新条目，将 ‘arista’ 字符串映射到为其准备的渲染函数和模板上
前提与限定条件
- 数据一致性: 输入的拓扑数据必须保证其完整性与逻辑一致性。例如，在connections_data中引用的所有端口，必须在vrf_port_groups_data中均有归属定义，否则程序将引发错误。
- 拓扑结构: 当前版本的路径发现算法假定拓扑为一个连续且无分叉的蛇形链，其两端分别连接至一个测试仪。
- 端口命名规范: parse_port函数当前依赖于400GE1/0/1这样的命名格式。若目标设备的端口命名规则不同，需相应地修改此函数内的正则表达式。如果不会改，那么生成后统一改下端口名也是可以的
结论
综上所述，该Python脚本已经从一个针对特定问题的解决方案，通过迭代反馈与架构重构，演进为一个通用的、支持多厂商的网络配置自动化平台。其设计具有良好的结构化特性，表现为高内聚与低耦合。该脚本不仅精确地实现了复杂的跨VRF及VRF内部的路由逻辑，同时凭借数据驱动的设计理念，确保了对多样化物理拓扑的灵活适配能力。此文档旨在为该工具的后续使用、维护与扩展提供清晰、全面的指引。