企业官网建设流程全解析

OSPF路由引入策略“误杀”测试流量：一次AP离线故障的排查复盘
一、故障背景与现象
近期，为了配合新业务上线，我们将某宿舍区域的部分AP配置到了测试环境的华为NCE-CampusInsight（以下简称CI分析器）。然而，配置下发后，运维人员发现CI上始终无法看到这些AP上报的数据。
初步排查情况：
AC侧正常： AC设备数据上报正常，说明AC到CI的基础链路没有问题。
生产环境正常： 同样的AP在生产环境的CI上可以正常看到数据，说明AP本身的硬件和基础配置无误。
问题聚焦： 故障点锁定在“测试环境CI”与“宿舍AP”之间的网络连通性上。
二、排查过程：从应用层到网络层

1. 检查AP与CI的建链状态
   登录问题AP，进入诊断视图查看HTTP2客户端状态：
   [XXX-XXX-LY1-221-diagnose]dis http2-client item 4
   uiSourceIP = 0.0.0.0 <-- 关键异常点：源IP未获取到
   uiDestIP = 10.xxx.xxx.101 <-- 测试CI地址
   ucConnStatus = 2, CONN_INITRETRY <-- 状态：正在初始化重试
   分析： AP无法获取源IP且处于重试状态，说明底层TCP连接尚未建立成功。这通常意味着路由不可达或中间链路阻断。
2. 检查核心交换机路由表
   登录校园网核心交换机（XXX-XXX-XYW-CORE），查询去往AP网段（10.xxx.xxx.60）的路由：
   dis ip routing-table 10.xxx.xxx.60
   Destination/Mask Proto Pre Cost Flags NextHop Interface
   0.0.0.0/0 Static 60 0 RD 10.xxx.xxx.10 Vlanif4062
   发现： 核心交换机上没有去往10.xxx.xxx.0/20网段的明细路由，只有一条默认路由指向了出口网关。这意味着核心交换机不知道如何把数据包发给宿舍的AP，只能盲目地往默认路由扔，导致回程包丢失或路径错误。
   三、深入分析：OSPF引入策略的“陷阱”
   既然核心没有路由，我们需要往上追溯，看是谁负责把宿舍的路由告诉核心的。
3. 检查宿舍核心（XXX-XXX-DC01-CORE）
   在宿舍核心上检查OSPF链路状态数据库（LSDB）：
   [XXX-XXX-DC01-CORE]dis ospf lsdb | include 10.xxx.xxx
   Type LinkState ID AdvRouter Age Len Sequence Metric
   External 10.xxx.xxx.0 10.xxx.xxx.128 940 36 8000439E 1
   发现： 宿舍核心确实通过OSPF Process 1宣告了外部路由（Type 5 LSA），且Router ID为10.xxx.xxx.128的设备正在发布这条路由。
4. 检查校园网核心的OSPF接收情况
   回到校园网核心，发现虽然宿舍核心发了路由，但校园网核心并没有学到。这通常是因为路由引入策略（Route-Policy）过滤了该路由。
5. 定位罪魁祸首：静态路由引入策略
   检查宿舍核心的OSPF配置，发现了关键配置段：
   ospf 10 router-id 10.xxx.xxx.114
   import-route static route-policy XXX <-- 关键点：引入静态路由时应用了策略xxx
   …
   network 10.xxx.xxx.81 0.0.0.0
   …
   逻辑推断：
   管理员原本的目的是将特定的静态路由引入OSPF 10进程并分发出去。但是，配置的route-policy XXX可能过于严格，或者没有包含本次测试环境所需的10.xxx.xxx.0/20（包含AP网段10.xxx.xxx.x）网段。导致这条关键的测试网段路由被策略“拒之门外”，未能成功注入OSPF域，最终导致上层核心交换机学不到路由。
   四、解决方案与优化
   为了快速恢复业务，同时保留原有的策略逻辑，我们采取了“补洞”的方式：
   操作步骤：
   在宿舍核心交换机上，手动添加一条指向测试环境下一跳的静态路由，并确保该路由能被正确识别：
   [XXX-XXX-DC01-CORE] ip route-static 10.xxx.xxx.0 255.255.240.0 10.xxx.xxx.253 description to-XXX
   注：此处需确认route-policy JLH是否允许匹配这条新加的静态路由。如果策略是deny all或者只permit特定列表，加静态路由后还需调整策略。假设原策略是基于前缀列表匹配，需确保新路由在匹配范围内；或者此处的修复隐含了策略已同步调整。
   后续验证：
   在校园网核心再次执行 dis ip routing-table 10.xxx.xxx.60，确认出现了OSPF路由条目。
   确认CI平台成功接收到AP上报的数据。
   五、运维总结
   本次故障是一个典型的“路由策略变更引发的次生灾害”。
   变更管理的严谨性： 在进行OSPF路由引入（Import-route）时，务必清楚Route-Policy的具体匹配规则。任何新增的网段如果需要被引入，都必须同步更新策略。
   测试环境与生产环境的隔离与互通： 测试环境往往因为网络架构调整频繁，最容易出现路由遗漏。建议在测试初期就进行端到端的连通性测试（Ping/Tracert），而不是等到业务上线才发现路不通。
   排错思路： 从应用层状态（HTTP2 Retry） -> 网络层路由（Routing Table） -> 路由协议细节（LSDB/Policy），层层递进是解决复杂网络问题的标准范式。