3. Junos操作系统基础与DCI配置框架

在QFX数据中心互联（DCI）工程中，所有设备行为最终都落到Junos操作系统的配置与提交机制上。理解Junos CLI、配置层次、提交模型和回滚机制，是后续编写DCI互联策略、EVPN/VXLAN参数、跨域路由策略的基础。本节从实际操作视角出发，把Junos的配置框架与DCI场景的组织方式串起来。

一、Junos CLI的两种模式与配置层次

登录QFX后，默认处于操作模式（Operational Mode），提示符为 >，用于查看状态、执行ping/traceroute、查看路由表和接口统计。输入 configure 进入配置模式（Configuration Mode），提示符变为 #，此时编辑的是候选配置（candidate configuration），尚未生效。

Junos配置是一棵严格的层次树，从顶层 edit 开始，主要层级包括：

• system：主机名、管理地址、DNS、NTP、登录认证等；
• interfaces：物理接口、逻辑单元（unit）、VLAN、IP地址；
• protocols：BGP、OSPF、IS-IS、MPLS、EVPN等路由协议；
• routing-options：路由表、静态路由、自治系统号；
• policy-options：路由策略、前缀列表、社区属性；
• vlans、switch-options：二层VLAN与交换参数。

在DCI场景中，这种层次结构带来一个直接好处：跨域互联的配置可以按“物理链路—逻辑隧道—路由协议—策略控制”分层组织，而不是把所有命令堆在一个平面里。例如，底层接口配置放在 interfaces，VXLAN隧道端点放在 protocols evpn，跨域路由过滤放在 policy-options，各层职责清晰，便于排障时逐层定位。

二、提交模型：commit、commit check与commit confirmed

Junos最核心的设计是候选配置 + 显式提交。在配置模式下修改的内容只存在于候选配置中，必须执行 commit 才会真正生效。这一模型对DCI工程尤为重要，因为跨域链路一旦配置错误，可能同时影响两个数据中心的路由可达性。

常用提交命令及其用途：

命令	作用	DCI场景典型用途
commit check	仅做语法与依赖检查，不生效	提交前验证BGP策略语法
commit	正式提交并生效	常规配置变更
commit confirmed 5	提交后5分钟未再次确认则自动回滚	远程修改管理接口或跨域链路
commit and-quit	提交并退出配置模式	批量变更后收尾
rollback 1	回滚到上一版本候选配置	误改策略后快速恢复

其中 commit confirmed 是DCI远程运维的“安全绳”。假设你在北京机房远程修改上海QFX的跨域BGP邻居，若新配置导致邻居中断且你无法再登录，commit confirmed 5 会在5分钟后自动恢复到修改前状态，避免设备失联。确认无误后，再执行一次 commit 或 commit confirmed 即可固化。

三、回滚机制与配置版本管理

Junos每次成功提交都会生成一个配置版本，保存在 /config 下，命名如 juniper.conf.1.gz、juniper.conf.2.gz。当前运行配置是 juniper.conf.gz，候选配置是 juniper.conf.0。回滚操作本质上是把历史版本重新加载为候选配置并提交。

show system rollback compare 1   # 比较当前配置与回滚版本1的差异
rollback 1                        # 将版本1载入候选配置
commit                            # 提交使其生效
rollback 0                        # 回到当前候选配置（放弃回滚）

在DCI工程中，回滚机制常用于三类场景：一是跨域策略调整后路由异常，快速恢复；二是软件升级前的配置基线保存；三是多机房批量变更时，逐台保留可回退点。建议在每次重大DCI变更前执行 commit 形成新版本，并记录版本号与变更内容，形成可追溯的配置基线。

四、DCI相关配置的组织方式

QFX作为DCI边缘设备，配置通常按“基础层—互联层—控制层—策略层”组织。基础层包括 system 与 interfaces；互联层包括VXLAN隧道接口 vt-0/0/0 与底层物理口；控制层包括 protocols evpn、protocols bgp；策略层包括 policy-options 中的路由策略与社区属性。

一个典型的DCI配置片段如下（示例参数，非实测）：

set interfaces xe-0/0/0 unit 0 family inet address 10.10.1.1/30
set interfaces vt-0/0/0 unit 0 family inet address 192.168.100.1/32
set protocols bgp group DCI type external
set protocols bgp group DCI peer-as 65002
set protocols bgp group DCI neighbor 10.10.1.2
set policy-options policy-statement DCI-IMPORT term 1 from community DCI-COMM
set policy-options policy-statement DCI-IMPORT term 1 then accept

这种组织方式让配置具备可读性和可维护性：接口层负责“通”，协议层负责“学”，策略层负责“控”。当跨域路由出现问题时，可以按层排查——先看接口是否up，再看BGP邻居是否Established，最后看策略是否过滤了目标前缀。

五、DCI配置组织中的实践要点

第一，先分层再提交。DCI变更往往涉及接口、隧道、BGP、策略四层，建议逐层提交并观察，而不是一次性提交全部改动。例如先提交接口与隧道，确认 show interfaces vt-0/0/0 状态up，再提交BGP与策略。

第二，善用commit confirmed保护远程操作。对跨机房设备的任何可能影响管理可达性的变更，都应使用 commit confirmed，确认窗口建议设为5～10分钟，留出验证时间。

第三，建立配置版本基线。每次DCI割接前记录当前版本号，割接后对比 show system rollback compare，确认改动范围与预期一致。若出现异常，直接 rollback 到基线版本，再逐项分析。

第四，策略层与协议层解耦。把跨域路由过滤、社区属性匹配放在 policy-options 中独立定义，在 protocols bgp 中引用。这样调整策略时不必改动BGP邻居配置，降低误操作风险。