命名式与编号式DMVPN中心：FQDN改变了什么

在支持该功能的平台上，DMVPN分支可以通过主机名找到自己的中心，而人们最先想到的，是把该主机名当作中心隧道地址的另一种写法。事实并非如此。名字解析到的是传输端点，而中心的协议地址标识的是overlay内部的下一跳，这两种角色在任何配置形式下都不会改变。正是这一区分，决定了重命名能修复什么、不能修复什么。

两个地址，两种职责

在一个已公布的示例中，hub.example.net 告诉分支把传输流量发往何处，而 10.90.0.1 标识隧道内部的NHS。发现作用于前者，注册与路由作用于后者。改名字影响的是通往端点的路径，而改协议地址影响的则是overlay关系本身。

把两种角色分开，正是命名式配置便于排查的原因。当分支注册失败时，你可以问两个不同的问题：名字是否解析成了我预期的地址，该地址是否与配置所声明的协议地址一致？这两个答案互不蕴含。

比较两种配置形式

一种形式在名字旁边显式配置NHS协议地址。另一种则让分支从注册应答中学习该协议地址。两者都有文档记载，成功时也都会形成同一种NHS关系。

显式形式有一个值得记住的限制：解析出的传输地址若未映射到所配置的协议地址，注册就会被阻止。这不是DNS故障，尽管症状会紧跟在DNS变更之后出现。名字解析是正确的，结果却因另一原因被拒绝。请把解析出的地址与配置的协议地址并排阅读。

学习式形式省去一个手工步骤和一个漂移来源，代价是依赖应答来建立映射。当中心地址稳定、且你希望不匹配时大声失败，就选显式形式。当中心协议地址可能变化、且你希望分支跟随它时，就选学习式形式。无论哪种，都要记录设计采用的是哪一种。

比较DNS缓存与静态中心

静态中心地址在有人修改配置时发生变化。命名式中心则在DNS变化时变化，而DNS应答会在其生存期内被缓存。文档指出，缓存的信息在过期之前一直可用，之后的查询才可能返回新地址。

这一差别是时序差别，而不是瞬时迁移。较长的缓存生存期会推迟对已重命名端点的采用，而如果你只盯着DNS记录，这种延迟是看不见的。要围绕缓存生存期和所安装版本的注册行为来规划重命名，而不是假定每条隧道会同时迁移。

静态形式当然也有自己的滞后：在每条分支都被修改之前，什么都不会变。真正的比较，是协调一致的配置推送与带缓存的发现刷新之间的比较，而不是快与慢的比较。

比较保持不变的部分

对等体认证不会移动。定位传输端点的主机名，并不取代已配置的IKE身份，也不取代验证对等体的认证策略。如果身份有误，成功的DNS解析只会让你更快地走到一条被拒绝的隧道。

受保护流量同样没有变化。NHS有应答，并不能证明客户路由存在，也不能证明应用流被允许。注册、路由与策略是三项检查，而名字只影响为它们提供输入的第一步。

一项可以验证的比较

Cisco分别记录了会话与NHS关系的观察方法。用 show dmvpn 读取对等体与会话状态，用 show ip nhrp nhs 读取NHS注册视图。按此顺序比较解析出的传输地址、overlay对等体与注册状态。

IOS XE FQDN-DMVPN一章记录了这项比较背后的发现、缓存与限制行为。在把命名式中心当作编号式中心的直接替代之前，请对照你安装的版本阅读该章。