OSPFV2 资源模块入门

OSPFV2 资源模块入门

随着现代企业网络规模和复杂性的不断增加，简化网络管理的需求也变得更加强烈。Ansible 2.9 引入了资源模块，为用户提供了一种简化网络管理的途径，尤其是在跨多个不同产品供应商的情况下。

过去，我们已经介绍了用于 VLAN 管理和 `ACL` 的资源模块。但是，简化网络管理并不局限于相对局部的网络设置：开放最短路径优先 (OSPFv2) 是一种用于在单个自治系统 (AS) 中分发 IP 路由信息的协议。它用于较大的网络设置，正如 维基百科页面恰如其分地指出的那样。

OSPF 是大型企业网络中广泛使用的 IGP。IS-IS 作为另一种基于 LSR 的协议，在大型服务提供商网络中更为常见。

手动管理网络设备的 OSPFv2 可能是一项非常困难且繁琐的任务，而且通常需要谨慎操作，因为手动过程更容易出现人为错误。

这篇博文将介绍 VyOS 网络平台的 OSPFV2 资源模块。我们将逐步介绍几个示例，并描述每个状态参数的用例以及我们如何设想在现实世界场景中使用它们。

OSPFV2 资源模块示例：Vyos

OSPFV2 资源模块的目标是确保以更少的精力在整个基础设施中一致地应用配置。它简化了管理，并使扩展变得更快更容易，而无需担心底层网络平台的实际实现细节。

2019 年 10 月，作为 Red Hat Ansible Engine 2.9 的一部分，Ansible 网络自动化团队引入了资源模块的概念，以使网络自动化对于那些在生产环境中自动化各种网络平台的用户来说更加轻松和一致。

Ansible 内容指的是 Ansible playbook、模块、模块实用程序和插件。基本上，用户利用所有 Ansible 工具来创建他们的 Ansible，而 OSPFv2 资源模块就是 Ansible 内容集合的一部分。

让我们仔细看看 OSPFv2 资源模块是如何工作的。例如，我们选择 vyos_ ospfv2 资源模块。在本博文中，我们将使用版本为 1.1.8（helium）的 VyOS 路由器进行所有特定于配置管理的操作。此外，为了更好地展示模块的效果，我们将从一些 已配置的 OSPF 版本 2 特定属性 开始。请查看链接列表以获取更多详细信息。

访问和使用 VyOS 集合

要下载 VyOS 集合，请参阅 Automation Hub（完全支持，需要 Red Hat Ansible Automation Platform 订阅）或 Ansible Galaxy（上游社区支持）。

• Automation Hub 集合：vyos.vyos
• Ansible Galaxy 集合：vyos.vyos

在我们开始之前，让我们快速解释一下网络资源模块命名背后的原理。请注意，对于配置 OSPFV2 路由的资源模块，新添加的模块将基于 IP 地址类型命名。这样做是为了确保使用现有网络模块的用户不会导致他们的 Ansible playbook 停止工作，并有足够的时间迁移到新的网络自动化模块。

以下支持的平台也提供了用于配置 OSPFv2 的模块。

• Arista EOS (arista.eos.eos_ospfv2)
• Cisco IOS (cisco.ios.ios_ospfv2) 
• Cisco IOSXR (cisco.ios.iosxr_ospfv2)
• Cisco NXOS (cisco.nxos.nxos_ospfv2)
• Juniper junos (junipernetwork.junos.junos_ospfv2)
• Vyos (vyos.vyos.vyos_ospfv2)

OSPFV2 资源模块提供了与用户在 VyOS 设备上手动配置时相同级别的功能，并具有 Ansible 的所有优势，此外还增加了 Ansible 事实收集和资源模块方法的优势，这与网络专业人员的日常工作更加吻合。

用例：OSPFV2 配置更改

使用收集的状态 - 构建 Ansible 清单

资源模块允许用户读取现有的网络配置并将其转换为结构化数据模型。**state: gathered** 等效于为此特定资源收集 Ansible 事实。此示例将读取现有的网络配置并将其存储为平面文件。

这是一个使用 **state: gathered** 并将结果以 YAML 格式存储到 host_vars 中的 Ansible playbook 示例。如果您不熟悉 Ansible 清单，并且想了解 group_vars 和 host_vars，请参阅 此处的文档。

---
- name: convert configured OSPFV2 resource to structured data
  hosts: vyos
  vars:
    inventory_dir: "lab_inventory"
    inventory_hostname: "vyos"
  gather_facts: false
  tasks:

  - name: Use the OSPFV2 resource module to gather the current config
    vyos.vyos.vyos_ospfv2:
      state: gathered
    register: ospfv2

  - name: Create inventory directory
    file:
      path: "{{ inventory_dir }}/host_vars/{{ inventory_hostname }}"
      state: directory

  - name: Write the OSPFV2 configuration to a file
    copy:
      content: "{{ {'ospfv2': ospfv2['gathered']} | to_nice_yaml }}"
      dest: "{{ inventory_dir }}/host_vars/{{ inventory_hostname }}/ospfv2.yaml"

使用 ansible-playbook 命令执行 Ansible playbook

$ ansible-playbook example.yml

这是从读取/收集操作在现存配置中创建的数据结构。

$ cat nw_inventory/host_vars/vyos/ospfv2.yaml
ospfv2:
  areas:
  - area_id: '2'
    area_type:
      normal: true
    authentication: plaintext-password
    shortcut: enable
  - area_id: '4'
    area_type:
      stub:
        default_cost: 20
        set: true

您可以在 state: gathered 参考 gist 中查看此示例输出的完整详细列表。

使用 state merged - 推送配置更改

state merged 将获取您的 Ansible 配置数据（即 Ansible 变量），并将它们合并到网络设备的运行配置中。这不会影响 Ansible 配置数据中未指定的现有配置。让我们逐步介绍一个示例。

我们将使用 要合并的配置 修改第一个示例中创建的平面文件。

以下是最重要的部分

areas:
 - area_id: '2'
   area_type:
     normal: true
   authentication: "plaintext-password"
   shortcut: 'enable'
 - area_id: '3'
   area_type:
     nssa:
       set: true

现在让我们创建一个 Ansible playbook 以将此新配置合并到网络设备的运行配置中

---
- name: Merged state play
  hosts: vyos
  gather_facts: false
  tasks:
    - name: Merge OSPFV2 config with device existing OSPFV2 config
      vyos.vyos.vyos_ospfv2:
        state: merged
        config: "{{ ospfv2 }}"

使用 ansible-playbook 命令执行 Ansible playbook

$ ansible-playbook merged.yml

并且，一旦我们运行相应的合并 play，所有提供的参数都将在 VyOS 路由器上配置，并且 Ansible **changed=True**。

请注意合并操作后的网络配置

vyos@vyos:~$ show configuration commands | grep ospf
set protocols ospf area 2 area-type 'normal'
set protocols ospf area 2 authentication 'plaintext-password'
set protocols ospf area 2 shortcut 'enable'
set protocols ospf area 3 area-type 'nssa'
set protocols ospf area 4 area-type stub default-cost '20'

请注意，此列表仅显示了一些重点内容；完整的列表可在 合并的 gist 中找到。

让我们看看通过此操作发生了哪些变化：如果我们查看设备输出，有一些观察结果

• area_id 为 '3' 的属性区域已添加到 OSPF 区域列表中。
• 已为 OSPF 配置了 redistribute 和参数属性。
• 如果已配置了一个包含区域的 OSPF，并且用户想要更新该特定区域的任何参数，则用户也可以使用 Merged 状态来更新 OSPFV2 下的区域。

在第二次运行时，相应的合并 Play 再次运行，并且 Ansible 的幂等性特性发挥作用。如果没有任何更改，play 运行结果将为 changed=False，这向用户确认 play 中提供的所有配置已在 IOS 设备上配置。

使用 state replaced - 替换配置

如果用户希望使用提供的 OSPFV2 配置完全重新配置已预先配置 OSPFV2 的 VyOS 设备，则资源模块的 replaced 状态将发挥作用。

replaced 操作的范围取决于各个进程。在 VyOS 的情况下，仅支持单个进程。因此，replaced 状态的行为类似于 overridden 状态。出于这个原因，VyOS 模块不需要专用的 overridden 状态。支持多个 OSPFV2 进程的其他网络平台确实具有 overridden 状态操作。

使用 overridden 状态，用户可以使用用户提供的 OSPFV2 配置覆盖所有 OSPFV2 资源属性。由于此资源模块状态会覆盖资源模块的所有预先存在的属性，因此应谨慎使用 overridden 状态，因为 OSPFV2 配置非常重要；如果所有配置错误地被 play 输入配置替换，则可能会给网络管理员造成不必要的麻烦。

在这种情况下，OSPF 与 'n' 个区域已在 VyOS 设备上配置，现在用户希望使用一组新的区域更新区域列表，并丢弃所有已配置的 OSPF 区域。在这里，资源模块的 replaced 状态将是理想的选择，并且顾名思义，replaced 状态将用用户作为输入提供的新区域集替换 OSPF 现有的区域列表。

如果用户尝试配置设备上尚不存在的任何新的 OSPFV2 区域/属性，则它将充当合并状态，并且 vyos_ospfv2 模块将尝试在替换 play 中配置用户作为输入提供的 OSPF 区域。

我们将修改第一个示例中创建的平面文件

areas:
 - area_id: '2'
   area_type:
     normal: true
   authentication: "plaintext-password"
   shortcut: 'enable'
 - area_id: '4'
   area_type:
     stub:
      default_cost: 20

如果您想了解更多详细信息，请查看 完整的输入配置结构。

同样，我们创建一个 Ansible playbook 以将此新配置合并到网络设备的运行配置中

---
- name: Replaced state play
  hosts: vyos
  gather_facts: false
  tasks:
    - name: Replace OSPFV2 config with device existing OSPFV2 config
      vyos.vyos.vyos_ospfv2:
        state: replaced
        config: "{{ ospfv2 }}"

一旦我们运行相应的替换 play，所有提供的参数都将覆盖 VyOS 路由器上所有现有的 OSPFv2 资源特定配置，并且 Ansible **changed=True**。

替换操作后的网络设备配置

vyos@vyos:~$ show configuration commands | grep ospf
set protocols ospf area 2 area-type 'normal'
set protocols ospf area 2 authentication 'plaintext-password'
set protocols ospf area 2 shortcut 'enable'
set protocols ospf area 4 area-type stub default-cost '20'
set protocols ospf area 4 network '192.0.2.0/24'

查看 相应的 gist 以获取更多详细信息。

如果我们深入研究上述输出，我们会注意到以下更改

• Replaced 会否定所有预先存在的 OSPFV2 资源特定属性，并删除替换 play 中不存在的那些配置。在上述示例中，ospfv2 area-id 3 已被删除。
• 对于预先存在且也在 play 中的 OSPFV2 配置，vyos_ospfv2 replaced 状态将尝试删除/否定所有预先存在的 OSPFV2 配置，然后配置 play 中提到的新 OSPFV2 配置。
• 对于任何不存在的 OSPFV2 特定属性，replaced 状态将以与合并状态相同的方式配置 OSPFV2。在上述示例中，为 OSPFv2 area-id 4 配置了一个新的网络地址。

在上述 play 的第二次运行中，没有报告任何更改，这满足了 Ansible 的幂等性。

使用 state deleted - 删除配置

既然我们已经讨论了如何使用vyos_ospfv2资源模块合并和替换状态来配置VyOS设备上的OSPFV2特定属性，那么现在该讨论如何删除预配置的OSPFV2属性以及用户可以使用哪些级别的粒度来删除操作状态了。

一次性删除**所有OSPFV2**配置会导致删除VyOS设备上所有预配置的**OSPFV2特定属性**。但话虽如此，这是一个非常关键的删除操作，如果使用不当，它有可能会删除所有预配置的**OSPFV2**，并可能导致生产环境中的路由器**没有**预配置的**OSPFV2属性**。

让我们创建一个Ansible Playbook，将此新配置合并到网络设备的运行配置中

---
- name: Deleted state play
  hosts: vyos
  gather_facts: false
  tasks:
    - name: Delete ALL OSPFV2 config
      vyos.vyos.vyos_ospfv2:
        state: deleted

执行剧本后，网络设备配置发生了更改

vyos@vyos:~$ show configuration commands | grep ospf
vyos@vyos:~$

请务必查看更改值的完整列表。如果我们简要分析以上输出，可以看到所有与ospfv2资源相关的配置都已从网络配置中删除。

使用状态rendered - 开发和离线工作

Ansible将任务中提供的配置渲染成设备原生格式（例如，VyOS CLI）。Ansible在结果的rendered键中返回此渲染后的配置。请注意，此状态不会与网络设备通信，可以在离线状态下使用。

要渲染配置，请修改在第一个场景中创建的YAML文件。例如，如果是vyos_ospfv2模块，您可以添加几个属性来表明我们再次更改了数据模型。

areas:
 - area_id: '2'
   area_type:
     normal: true
   authentication: "plaintext-password"

在相应的渲染gist中查看完整列表。

我们创建一个剧本执行此操作

---
- name: Rendered state play
  hosts: vyos
  gather_facts: false
  tasks:
    - name: Render the provided configuration
      vyos.vyos.vyos_ospfv2:
        config: "{{ ospfv2 }}"
        state: rendered

这会产生以下输出

"rendered": [
       "set protocols ospf log-adjacency-changes 'detail'",
       "set protocols ospf max-metric router-lsa administrative",
       "set protocols ospf max-metric router-lsa on-shutdown 10",

查看相应的gist以获取更多详细信息。

如果我们深入分析以上输出，我们可以看到根本没有任何变化；rendered甚至不需要与实际网络设备建立连接。

使用状态parsed - 开发和离线工作

Ansible将running_configuration选项中的配置解析成Ansible结构化数据，并将其存储在结果的parsed键中。请注意，这不会从网络设备收集配置，因此此状态可以在离线状态下使用。

作为要解析的配置，我们采用设备原生格式的配置

set protocols ospf area 2 area-type 'normal'
set protocols ospf area 2 authentication 'plaintext-password'
set protocols ospf area 2 shortcut 'enable'
set protocols ospf area 4 area-type stub default-cost '20'
set protocols ospf area 4 network '192.0.2.0/24'
set protocols ospf area 4 range 192.0.3.0/24 cost '10'

应用此配置的剧本为

---
- name: Parsed state play
  hosts: vyos
  gather_facts: false
  tasks:
    - name: Parse the provided OSPFV2 configuration
      vyos.vyos.vyos_ospfv2:
        running_config:
           "set protocols ospf area 2 area-type 'normal'
            set protocols ospf area 2 authentication 'plaintext-password'
            set protocols ospf area 2 shortcut 'enable'
        state: parsed

执行剧本会生成以下输出

"parsed": {
        "areas": [
            {
                "area_id": "2",
                "area_type": {
                    "normal": true
                },
                "authentication": "plaintext-password",
                "shortcut": "enable"
             }

                ]
            }
...

如果我们深入分析以上输出，我们可以看到根本没有任何变化，parsed操作甚至不需要与实际网络设备建立连接。

注意：parsed输入需作为running_config键的值提供。

要点和后续步骤

如上所示，借助资源模块，可以极大地简化OSPFV2的资源特定配置管理。用户无需过多关注每个平台的OSPFV2实现细节，只需输入实际数据即可。通过使用合并、替换和覆盖参数，我们为网络工程师提供了更大的灵活性，以便他们能够以增量步骤采用自动化。其他操作（如gathered、rendered和parsed）允许更好地、更友好地处理这些任务中管理的事实和数据。