跨 VPN 的 OSPF 路由类型：并不总是外部路由

客户前缀以 BGP VPN 路由的形式穿越运营商云，到达远端站点时看起来像一条 OSPF 外部路由，这是许多工程师的预期，却并非唯一可能的结果。远端 CE 看到什么，取决于该前缀来自哪个 OSPF 域以及它原本的路由类型，而这两者都随 VPN 路由一起传递。假设每条被重新分发的前缀都会变成 Type 5，会导致无法成立的优先级调整。应首先比较域标识符，而不是管理距离。

PE-CE 模型携带足够的上下文，使接收端 PE 能够重建 OSPF 通告，而不是凭空编造。

随路由一起传递的内容

RFC 4577 定义了随 VPN 路由携带的 OSPF 属性：域标识符、度量值以及源站点的路由类型。接收端 PE 用这些属性来决定一条符合条件的前缀应如何呈现给本地 OSPF 进程。缺少这些属性，远端 PE 除了做外部重分发之外就没有任何依据。正因如此，即使 BGP 在中间承载过，路由仍可能以区域间 LSA 的形式到达。

区域类型同样重要。Stub 或 NSSA 区域会限制哪些 LSA 可以进入，因此同一条 VPN 路由会因接收端 OSPF 实例所处位置不同而呈现不同结果。配置的导出策略也能覆盖默认呈现，这是有意的选择而非副作用。

同一域，不同呈现

来自同一域的区域内或区域间路由，通常以区域间路由即 Type 3 LSA 的形式到达远端站点。来自其他域的前缀、从未运行过 OSPF 的来源，或最初就是外部的 OSPF 通告，则会遵循外部规则，Type 5 及其 NSSA 等价类型正出现在这里。两种行为都是正确的，区别只在输入。在调整优先级之前，先比较域标识符与通告的属性。

管理距离只在一台路由器上选择来源。它不会改写 LSA 类型，也不会补出缺失的域关系。

何时 sham link 才是正确答案

设想同一区域内的两个站点由一条直连后门链路相连。即使配置开销会让经运营商的道路更有吸引力，OSPF 仍保留这条区域内路径，而不是运营商提供的区域间路径。sham link 在 VPN 之上表示一种区域内关系，使开销能够参与决策。它只为这一特定的选路问题而存在，并不是为了让同一域的所有路由都显得像内部路由。

sham link 需要可达的端点，并且两端 PE 都要做对称配置。只在一边配置会产生一种永远无法形成的关系，路由表也保持原有优先级，看起来就像该功能毫无作用。

不要破坏环路保护

PE-CE 模型会在其分发的路由上设置 DN 位，使前缀无法经另一台 CE 返回并再次被重分发。正是这一保护防止前缀在共享同一 OSPF 域的站点之间成环。为了把路由伪装成内部路由而移除或忽略它，恰恰可能制造出它本要防止的环路。当前缀看起来不对时，应把 DN 位当作信息而不是障碍。

同样的谨慎适用于剥离 community 的重分发过滤器和路由映射。它们各自移除远端所需的上下文，结果通告可能看似合理实则有误。一次只改一个属性，并核实远端 CE 实际安装了什么。

然后从远端站点验证：LSA 类型、通告路由器以及它选择的路径。这些证据才能回答工单提出的问题。