Frrouting学习笔记（四）——OSPF API

本篇翻译自doc/developer/ospf-api

一、免责声明

        OSPF守护进程包含一个API，用于应用程序访问LSA数据库。这个API和文档是由Ralph Keller创建的，最初是Zebra的补丁。遗憾的是，包含API文档的页面已不再在线。此页面尝试为API重新创建文档（借助WayBackMachine的大量帮助）。

        Ralph已将本文档授权给GPLv2+。请保留本文档底部的致谢信息。

二、介绍       

        本页描述了一个API，它允许外部应用程序访问OSPF守护进程的链接状态数据库（LSDB）。该实现基于FRRouting（从Quagga和以前的Zebra派生而来）路由协议套件的OSPF代码，并受GNU通用公共许可证的约束。OSPF API为您提供以下功能：

1. 检索OSPF后台进程的完整或部分链路状态数据库。这允许应用程序获得LSDB的精确副本，包括路由器LSA、网络LSA等。每当新的LSA到达OSPF守护进程时，API模块立即通过发送消息通知应用程序。通过这种方式，应用程序始终与OSPF守护进程的LSDB同步。
2. 源自自己的不透明LSA（类型9、10或11），然后将其透明地分发给洪泛范围内的其他路由器，并由其他应用程序通过OSPF API接收。

        不透明LSA在：rfc:`2370'中进行了描述，允许您使用OSPF协议在网络中分发特定于应用程序的信息。不透明LSA中包含的信息对于路由过程是透明的，但它可以由其他模块处理，例如流量工程（例如，MPLS-TE）。

三、体系结构

        下图描述了Quagga/Zebra协议套件的体系结构。OSPF守护进程扩展了不透明的LSA功能和用于外部应用程序的API。OSPF核心模块通过发现邻居和交换邻居状态来执行OSPF协议。不透明模块由远藤正彦实现，提供在路由器之间交换不透明LSA的功能。不透明LSA可以由多个模块生成，例如MPLS-TE模块或API服务器模块。然后，这些模块调用不透明模块将其数据洪泛到洪泛范围内的邻居。

        客户端是一个可能在与OSPF守护进程不同的节点上运行的应用程序，它链接到OSPF API客户端库。此客户端库与OSPF后台程序的API服务器模块建立套接字连接，并使用此连接检索LSA和发起不透明LSA。

        OSPF API服务器模块的工作方式与任何其他内部不透明模块（如MPLS-TE模块）类似，但会侦听来自希望与OSPF守护进程通信的外部应用程序的连接。API服务器模块可以同时处理多个客户端。        

        实现的主要目标之一是尽可能少地更改现有的Zebra代码。

四、安装和配置

        下载FRRouting并解压。配置和构建FRR（请注意，`--enable opaque lsa``还启用ospfapi服务器和ospfclient）。

        这还应该编译ospfclient中的客户端库和示例应用程序。这也应该编译ospfclient中的客户端库和示例应用程序。

        请确保在配置中启用了不透明LSA。将`ospf opaque lsa`语句添加到您的：file:`ospfd.conf`：

五、用法

        在下文中，我们将描述如何使用示例应用程序来创建不透明LSA。示例应用程序首先向OSPF守护进程注册它想要注入的不透明类型，然后等待，直到OSPF守护程序准备好接受该类型的不透明LSA。然后客户端应用程序发起一个不透明LSA，等待10秒，然后用新的不透明数据更新不透明LSA。再过20秒，客户端应用程序将不透明LSA从LSDB中删除。如果客户端意外终止，则OSPF API模块将删除应用程序注册的所有不透明LSA。由于不透明LSA被淹没到其他路由器，我们将根据不透明LSA的淹没范围在所有路由器中看到不透明LSA。在下文中，我们将描述如何使用示例应用程序来创建不透明LSA。示例应用程序首先向OSPF守护进程注册它想要注入的不透明类型，然后等待，直到OSPF守护程序准备好接受该类型的不透明LSA。然后客户端应用程序发起一个不透明LSA，等待10秒，然后用新的不透明数据更新不透明LSA。再过20秒，客户端应用程序将不透明LSA从LSDB中删除。如果客户端意外终止，则OSPF API模块将删除应用程序注册的所有不透明LSA。由于不透明LSA被淹没到其他路由器，我们将根据不透明LSA的淹没范围在所有路由器中看到不透明LSA。

        我们有一个非常简单的演示设置，只有两个路由器通过ATM点对点链路连接。在两个相邻的路由器上启动修改后的OSPF守护进程。首次在msr2上运行：

        在相邻的路由器msr3上：

        现在，这两个路由器形成了相邻关系，并开始交换它们的数据库。查看msr2（或msr3）的OSPF守护进程，可以看到：

        现在，我们启动示例主应用程序，该应用程序源自一个不透明的LSA。

        这产生了一个类型为10（区域本地）的不透明LSA，不透明类型为250（实验），不透明id为20（任意选择），接口地址为0.0.0.0（仅用于不透明LSA类型9），区域为0.0.0.1

        再次查看OSPF数据库，您会看到：

        您可以仔细查看这个不透明的LSA：

        请注意，主应用程序在10秒后更新不透明LSA，然后它看起来如下：

        请注意，不透明LSA的有效载荷已经发生了变化，正如您在上面看到的那样。

        然后，又过了20秒，不透明LSA从LSDB中被刷新。

重要提示: 为了发起不透明LSA，必须至少有一个活动的具有不透明能力的邻居。因此，如果不存在邻居，则不能发起不透明LSA。如果您尝试在没有邻居准备好的情况下发起，您将收到一条未准备好的错误消息。这种限制的原因是，一些路由器可能在其LSDB中有一个来自以前发起的相同的不透明LSA，不幸的是，由于崩溃，该LSA无法刷新。现在，如果路由器再次出现并开始发起一个新的不透明LSA，则新的不透明LSA被认为是较旧的，因为它的序列号较低，并且被其他路由器忽略（这些路由器认为停滞的不透明ls是最近的）。然而，如果始发路由器在始发不透明LSA之前首先同步数据库，它将检测到较旧的不透明LSA，并可以首先刷新它。

六、协议和消息格式

        如果您正在开发自己的客户端应用程序，并且不想使用客户端库（由于GNU许可证限制或其他原因），则可以实现自己的客户端消息处理。OSPF API使用客户端和OSPF API服务器之间的两个连接：一个连接用于同步请求/回复协议，另一个连接则用于异步通知（例如LSA更新、邻居状态更改）。

        每条消息都以以下标题开头：

        消息类型字段可以采用以下值之一：

        同步请求和回复具有以下消息格式：

                原点字段允许使用以下原点类型进行基于原点的过滤：

        回复消息包含以下错误代码之一：

        异步通知具有以下消息格式：

七、Ralph Keller的致谢原件（不要删除这些致谢）

        我要感谢不透明LSA扩展模块的作者远藤正彦的大力支持。他精彩的ASCII图形解释了该代码的内部工作原理，以及他宝贵的输入被证明对于设计一个有用的API访问OSPF守护进程的链接状态数据库至关重要。有一次，他甚至决定从东京坐飞机去苏黎世，这样我们就可以真正见面并进行面对面的讨论，这很有趣。显然，没有Masahiko，API就永远不会完成。我还要感谢Daniel Bauer，他也编写了一个不透明的LSA实现，并愿意在他的一个项目中测试OSPF API代码。