华三交维

采集不到，看下通信时候存在问题还有quan"xi"an，实在不行，就直接手动拉出诊断上传Iserver上去做交维

# 华三交维（SeerAnalyzer）带外采集：仅一台管理机能采到，其余交换机采集不到

>
> 现象：同一套交维平台，**其中一台交换机带外采集正常，其余交换机全部采集失败**。说明交维平台本身采集组件、模板大体没问题，重点排查**其余交换机侧配置、带外网络路由、ACL、协议配置**wwwsg-prox...。

>
> 带外采集一般使用 SNMP（UDP‑161）+ NETCONF‑SSH（TCP‑830/22）两套协议。

## 一、优先对比：正常可采集交换机 vs 异常交换机

把采集正常那台交换机的配置作为参照样本，对比故障交换机：

```
#查看SNMP完整配置
display current‑configuration | include snmp‑agent

#查看VTY、ACL、NETCONF
display current‑configuration | include vty
display current‑configuration | include acl
display netconf status
```

## 二、网络层排查（带外管理网络）

1. **交维采集服务器南向 IP，ping 故障交换机的带外管理 IP；交换机反向 ping 交维采集 IP**，双向必须通。

>
> 很多现场：单台交换机带外在同一网段，其他交换机带外是别的网段，缺少回程静态路由，ping 不通直接采集超时H3C。

2. 中间防火墙 / 三层设备是否放通：UDP 161 (SNMP)、TCP 22/830 (NETCONF‑SSH)、ICMP；
3. 确认交换机使用**带外管理 IP**被纳管，不是业务内网 IP。

## 三、交换机设备侧高频故障点（绝大多数现场根因）

### 1）ACL 拦截交维采集 IP（最高概率）

交换机 VTY 视图、SNMP 视图绑定 ACL，**只放行那一台正常交换机对应的网段，拒绝交维采集服务器 IP**。

```
user‑interface vty 0 15
display this
#如果存在acl inbound，检查该ACL是否允许交维采集IP访问
display acl xxx
```

>
> SNMP 同样受 MIB‑view、ACL 控制；ACL 隐式 deny，没有允许就直接丢弃报文，表现为平台采集超时，正常那台交换机没有这条 ACL 限制。

### 2）SNMP 配置不一致

- 故障交换机没有开启 snmp‑agent；
- 团体字 v2c、v3 认证 / 加密参数，与交维协议模板不一致；
- MIB 视图限制，只读视图范围过小，交维读不到 OID；

```
display snmp‑agent mib‑view
```

### 3）NETCONF/SSH 问题

1. 故障交换机没有开启`netconf ssh server enable`；
2. VTY 会话数量不足，会话占满无法新建 NETCONF 连接；
3. 登录账号权限不够，没有 level‑3 管理员权限；
4. 账号带 ISP 域，交维模板没有填写域名，认证失败wwwsg-prox...。

### 4）交换机系统时间异常

设备时间偏差过大，SNMPv3、NETCONF SSH 会校验时间，时间差太大直接拒绝报文。

```
display clock
```

## 四、交维平台侧排查

1. 确认故障交换机使用**同一套协议模板**（SNMP、NETCONF 模板）；
2. 在交维平台采集页面，点开失败设备查看**采集失败日志**：超时 / 认证失败 / 连接被拒绝；
3. 不要把 “带外管理机” 和交维采集服务器搞混：能采集到那台交换机可能和采集服务器同网段，其余跨网段就不通。

## 五、快速定位验证手段

在交维服务器上，使用工具测试：

1. snmpwalk 测试 SNMP 连通；
2. ssh 手动测试 TCP‑830 端口 NETCONF 能否登录；

>
> 如果手动工具也连不上，问题在**网络或者交换机配置**；手动工具能通，则是交维平台模板参数错误。

## 简短总结

1. 单台正常、其余全部异常，平台组件基本无问题，优先拿正常交换机配置做对比；
2. 重点排查：**带外双向路由可达、交换机 ACL 是否拦截交维采集 IP（最高频）**；
3. 核对故障交换机 SNMP、NETCONF 是否开启，账号权限、团体字 / 加密参数；
4. 查看交维平台设备采集失败日志，区分是网络超时还是认证拒绝。

只有带外管理机能被采集到，而其他交换机不行，问题通常出在网络连通性、SNMP协议配置、安全策略或设备自身资源这几个方面。可以参考以下步骤逐一排查：

1. 🔌 检查网络连通性与路由

这是最基础的一步。如果采集服务器与交换机网络不通，后续一切免谈。

• 确认IP地址：首先确认那些采集不到的交换机，其管理IP地址（无论是带内VLAN接口地址，还是带外MGMT接口地址）配置是否正确。

• 测试连通性：从采集服务器上用 ping 命令测试这些交换机的管理IP。如果不通，需检查：

  • 交换机管理接口（或VLAN）是否为 up 状态。

  • 交换机的默认网关是否配置正确。

  • 沿途的路由器或防火墙是否有正确的路由。

  • 物理链路是否正常（网线、端口等）。

2. ⚙️ 核对SNMP配置一致性

SNMP配置不匹配是采集失败的常见原因。请逐一检查并确保采集服务器和所有待采集交换机的配置完全一致。

• 版本 (SNMP Version)：确认两边使用的是相同的版本（v1、v2c 或 v3）。

• 认证信息：

  • v1/v2c：核对团体名 (Community String) 是否完全一致。

  • v3：核对用户名 (Username)、认证算法/密码和加密算法/密码是否一致。

• SNMP服务状态：在交换机上执行 display snmp-agent status，确认SNMP Agent服务是 enabled 状态。

3. 🛡️ 审查ACL与防火墙策略

即使SNMP配置正确，安全策略也可能拦截请求。

• 交换机ACL：检查交换机上是否配置了ACL并关联到了SNMP，限制了只有特定IP能访问。

  bash

  display acl all # 查看所有ACL规则 display current-configuration | include snmp-agent.*acl # 查看SNMP是否绑定了ACL

  如果ACL的源地址没有包含采集服务器IP，需要修改ACL添加放行规则。

• 中间防火墙：检查采集服务器与交换机之间的防火墙，确保UDP 161端口（SNMP查询端口）是放行的。

• ACL与视图绑定：在Comware V7设备上，一个常见的“坑”是没有将团体名与正确的MIB视图绑定。请确保配置如下：

  bash

  snmp-agent group v2c <组名> read-view <视图名> # 创建组并绑定视图 snmp-agent usm-user v2c <团体名> <组名> # 将团体名加入到组

  只配置 snmp-agent community 而没有执行上述绑定，设备会拒绝所有查询。

4. ⚡️ 检查设备资源与性能

设备自身负载过高也可能导致无法响应SNMP请求。

• CPU利用率：执行 display cpu-usage 查看CPU使用率。如果持续高于70%-80%，设备可能因繁忙而无法及时响应。

• 内存状态：执行 display memory 检查内存使用情况，确保没有内存耗尽。

• SNMP进程：确认SNMP进程是否正常运行。

5. 🔧 排查采集工具与高级设置

• 检查采集工具配置：确认采集工具中添加的设备IP、SNMP版本、认证信息等参数都正确无误。

• 检查特定功能开关：如果采集的是端口流量数据，部分型号（如S5120、S6850）需要手动开启流量统计功能。

  bash

  system-view traffic-statistic enable # 在系统视图下开启

• 尝试使用SNMP工具测试：在采集服务器上，直接用 snmpwalk 命令测试，能快速定位问题。

  bash

  # 测试v2c，-v 指定版本，-c 指定团体名，<交换机IP>为目标地址 snmpwalk -v 2c -c <团体名> <交换机IP> 1.3.6.1.2.1.1.1.0

  如果这条命令能返回系统描述信息，说明SNMP通信是正常的，问题可能在采集工具配置或OID上。

6. 🔍 其他可能性

• 采集服务器经过NAT：如果采集服务器是通过NAT（端口映射）访问交换机，部分采集工具可能无法正常工作。

• MIB库与OID问题：如果采集工具有数据返回但数值不对，可能是MIB库不匹配或OID不正确。

• 存储空间不足：设备存储介质空间不足也可能导致无法处理SNMP请求。