跳到主要内容

Appendix G. 与 RFC 2178 的差异 (Differences from RFC 2178)

        将主体中的掩码改为 NM1, 并插入新网络的代价. 然后为旧网络 [NA,NM2] 产生一个新的 LSA, 其 Link State ID 等于 NA 与 NM2 中未置位的位进行或运算后的值, 即网络 [NA,NM2] 的广播地址.

上述算法假定所有掩码都是连续的; 这确保当两个网络具有相同地址时, 其中一个掩码比另一个更具体. 该算法还假定不存在某个网络的地址等于另一个网络广播地址的情况. 在这两个假设下, 上述算法总能产生唯一的 Link State ID. 上述算法也可以改写如下: 产生 AS-external-LSA 时, 尝试使用网络号作为 Link State ID. 如果这产生冲突, 则检查冲突的两个网络. 其中一个会是另一个的子集. 对不那么具体的网络, 使用网络号作为 Link State ID; 对更具体的网络, 改用该网络的广播地址, 即把所有 "host" 位翻转为 1. 如果最具体的网络最先产生, 这会导致你一次产生两个 LSA.

作为该算法的示例, 考虑单个路由器 (Router A) 中发生以下事件序列时该算法的运行方式.


(1) Router A 想为 [10.0.0.0,255.255.255.0] 产生 AS-external-LSA:

    (a) 使用 Link State ID 10.0.0.0.

(2) Router A 随后想为 [10.0.0.0,255.255.0.0] 产生 AS-external-LSA:

    (a) 使用新的 Link State ID 10.0.0.255 重新产生 [10.0.0,0,255.255.255.0] 的 LSA.

    (b) 对 [10.0.0.0,255.255.0.0] 使用 Link State ID 10.0.0.0.

(3) Router A 随后想为 [10.0.0.0,255.0.0.0] 产生 AS-external-LSA:

    (a) 使用新的 Link State ID 10.0.255.255 重新产生 [10.0.0.0,255.255.0.0] 的 LSA.

    (b) 对 [10.0.0.0,255.0.0.0] 使用 Link State ID 10.0.0.0.

    (c) 网络 [10.0.0.0,255.255.255.0] 保持其 Link State ID 10.0.0.255.

F. 到同一网络/子网的多个接口 (Multiple interfaces to the same network/subnet)

至少有两种方式支持到同一 IP 子网的多个物理接口. 两种方法都能与 RFC 1583 的实现互操作, 当然也能与本备忘录互操作. 下面简要勾勒这两种方法. 这里假定每个接口都分配了独立的 IP 地址; 否则, 支持多个接口更多是链路层或 ARP 问题, 而不是 OSPF 问题.

Method 1:
    在两个接口上运行完整 OSPF 功能, 发送和接收 hellos, 执行泛洪, 为每个接口支持独立的接口 FSM 和邻居 FSM, 等等. 这样做时, 子网上的所有其他路由器会把这两个接口视为独立邻居, 因为在广播网络和 NBMA 网络上, 邻居由其 IP 地址标识.

    Method 1 有以下缺点:

    (1) 会增加邻居和邻接关系的总数.

    (2) 会丢失两个接口上的双向性测试, 因为双向性基于 Router ID.

    (3) 在 Designated Router 选举期间, 必须同时考虑两个接口, 因为如果同时宣布二者都是 DR, 会使基于 Router ID 的平局决策产生混乱.

Method 2:
    只在一个接口上运行 OSPF (称为 primary interface), 但在 Router-LSA 中同时包含 primary 和 secondary interfaces.

    Method 2 有以下缺点:

    (1) 会丢失 secondary interface 上的双向性测试.

    (2) 当 primary interface 失效时, 需要将 secondary interface 提升为 primary 状态.

G. 与 RFC 2178 的差异 (Differences from RFC 2178)

本节记录本备忘录与 RFC 2178 的差异. 所有差异都向后兼容. 本备忘录的实现可与 RFCs 2178, 1583 和 1247 的实现互操作.

G.1 泛洪修改 (Flooding modifications)

    Section 13 中的泛洪过程做了三处修改.

    第一处修改是 Section 13 的 step 4. 现在, 只有当 a) 没有该 LSA 的数据库副本, 且 b) 路由器的任何邻居都不处于 Exchange 或 Loading 状态时, MaxAge LSAs 才会被确认然后丢弃. 在所有其他情况下, MaxAge LSA 会像其他 LSA 一样处理: 当该 LSA 比数据库副本更新时, 将其安装到数据库中, 并从适当接口泛洪出去 (Section 13 的 Step 5). 这一修改也影响 Table 19 的内容.

    第二处修改是 Section 13 的 step 5a. MinLSArrival 检查只针对在泛洪期间收到的 LSA, 不应对路由器自身产生的 LSA 执行.

    第三处修改是 Section 13 的 step 8. 在链路状态协议中, 路由器之间对于哪个 LSA 实例更新产生混淆, 可能导致灾难性的泛洪量 (见 [Ref26]). OSPF 通过两种方式防范这个问题: a) 在泛洪中将 LS age 字段像 TTL 字段一样使用, 最终从网络中移除循环的 LSA (见 Section 13.3), 以及 b) 路由器拒绝以超过每 MinLSArrival 秒一次的频率接受 LSA 更新 (见 Section 13). 不过, RFC 2178 中仍有一种情况会因对于哪个 LSA 更新存在分歧而造成大量泛洪流量: 通过重新泛洪数据库副本来响应旧 LSA. 因此, Section 13 的 Step 8 已修订为只有当数据库副本在最近 MinLSArrival 秒内没有被放入任何 Link State Update 发送过时, 才用该数据库副本响应.
最后于 更新