unisystem自动修改snmp trap ip

查了下已知问题，未见此情况。联络400报个单吧，让技术部门确定下。不过，如果真的BUG的话，应该有反馈的呀~~~版本：2.74是2025/1/2发的，现网也没听说有这个问题。

可能的原因
Bug类型分析：
功能逻辑缺陷：UniSystem可能错误地将"收集设备信息"与"配置SNMP Trap接收端"两个功能混淆。
代码逻辑错误：在收集设备信息过程中，代码可能误调用SNMP配置修改功能。
参数传递错误：UniSystem可能将自身的IP地址错误地作为SNMP Trap服务器地址推送给设备。
UniSystem 2.74版本已知问题：
这个版本可能存在一个已知缺陷：在进行设备发现或信息收集时，会错误地修改设备配置。
可能是为了实现"自动配置管理通道"的功能，但逻辑实现有问题。
解决方案
方案一：紧急处理措施
1. 阻止UniSystem的配置修改行为
# 在设备上设置配置保护（如果支持）
system-view
configuration lock by user-name unisystem # 锁定配置，防止被修改

# 或者在ACL中限制UniSystem的访问权限
acl advanced 3000
rule deny tcp source 192.168.1.100 0 destination any destination-port eq 161 # 阻止SNMP写操作
rule deny tcp source 192.168.1.100 0 destination any destination-port eq 22 # 阻止SSH修改
rule permit ip source any destination any
quit

# 应用ACL到接口
interface GigabitEthernet1/0/0
packet-filter 3000 inbound
quit
2. 批量恢复正确的SNMP配置
创建一个脚本，批量恢复所有受影响设备的SNMP Trap配置：
# restore_snmp_trap.sh
#!/bin/bash
# 设备列表
DEVICES=("192.168.1.1" "192.168.1.2" "192.168.1.3")
# 正确的Trap服务器IP
TRAP_SERVER="192.168.10.100"

for DEVICE in "${DEVICES[@]}"
do
echo "恢复设备 $DEVICE 的SNMP Trap配置..."

# 使用Expect脚本自动登录并修改配置
/usr/bin/expect << EOF
spawn ssh admin@$DEVICE
expect "password:"
send "your_password\r"
expect ">"
send "system-view\r"
expect "]"
send "undo snmp-agent target-host trap address udp-domain $DEVICE\r" # 删除错误的配置
expect "]"
send "snmp-agent target-host trap address udp-domain $TRAP_SERVER params securityname public v2c\r"
expect "]"
send "quit\r"
expect ">"
send "save force\r"
expect ">"
send "quit\r"
expect eof
EOF
echo "设备 $DEVICE 配置完成"
done
方案二：UniSystem端配置修正
1. 检查UniSystem的SNMP配置选项
在UniSystem管理界面中：
进入 "系统设置" → "采集设置"
查找 "自动配置SNMP"​ 或 "设备自动发现设置"​ 选项
取消勾选所有与 "自动配置"、"自动优化"、"自动修复"​ 相关的选项
2. 修改采集任务设置
如果UniSystem支持任务模板：
编辑设备信息采集任务
在 "高级选项"​ 中：
取消 "自动配置管理通道"
取消 "优化设备配置"
选择 "只读模式采集"
3. 使用低权限账号
在UniSystem中添加设备时，使用只读权限的SNMP community：
SNMP读共同体: public
SNMP写共同体: 留空或使用不存在的字符串
方案三：升级或降级UniSystem版本
1. 升级到最新版本
# 检查当前版本和可用更新
cd /opt/unisystem # UniSystem安装目录
./update_check.sh # 或类似脚本

# 备份当前配置
tar -czvf unisystem_backup_$(date +%Y%m%d).tar.gz /opt/unisystem/config/

# 从官网下载最新版本
wget http://download.h3c.com/unisystem/UniSystem-3.0.1.zip
unzip UniSystem-3.0.1.zip
cd UniSystem-3.0.1
./install.sh
2. 临时降级到稳定版本
如果最新版仍有问题，考虑降级到已知稳定的版本（如2.70版本）：
# 备份数据
mysqldump -u root -p unisystem_db > unisystem_backup.sql

# 卸载当前版本
./uninstall.sh

# 安装旧版本
rpm -ivh UniSystem-2.70.rpm # 或使用对应安装包
方案四：配置设备端防护
1. 配置SNMP访问控制
# 创建SNMP访问控制列表
system-view
snmp-agent community read cipher public
snmp-agent community write cipher private # 如果不需要写权限，可以不配置

# 配置ACL限制SNMP访问
acl basic 2000
rule 0 permit source 192.168.10.100 0 # 只允许真正的Trap服务器
rule 5 deny source any
quit

# 应用ACL到SNMP
snmp-agent community read public acl 2000
snmp-agent community write private acl 2000

# 配置Trap目标主机
snmp-agent target-host trap address udp-domain 192.168.10.100 params securityname public v2c
2. 配置配置归档和回滚
# 启用配置归档
archive configuration
location flash:/config_archive/
max-archive-files 10
quit

# 配置定期自动备份
scheduler job BACKUP_CONFIG
command 1 archive configuration
quit

scheduler schedule DAILY_BACKUP
job BACKUP_CONFIG
time repeating at 02:00
quit

# 配置配置变更告警
snmp-agent trap enable cfgmgr
info-center source CFGMGR channel 4 log level notifications
方案五：验证和监控
1. 验证配置保护
创建测试脚本，验证配置是否会被修改：
# test_snmp_change.sh
#!/bin/bash
DEVICE="192.168.1.1"
TRAP_COnFIG=$(snmpwalk -v2c -c public $DEVICE 1.3.6.1.6.3.12.1.2.1.5)
echo "当前Trap配置: $TRAP_CONFIG"

# 运行UniSystem采集任务
# 等待任务完成

TRAP_CONFIG_AFTER=$(snmpwalk -v2c -c public $DEVICE 1.3.6.1.6.3.12.1.2.1.5)
echo "采集后Trap配置: $TRAP_CONFIG_AFTER"

if [ "$TRAP_CONFIG" != "$TRAP_CONFIG_AFTER" ]; then
echo "警告: SNMP配置被修改!"
# 发送告警
mail -s "UniSystem修改设备配置告警" admin@***.*** <<< "设备 $DEVICE 的SNMP配置被修改"
fi
2. 部署配置监控
使用Zabbix或其他监控系统监控设备配置变化：
# 监控脚本示例
#!/bin/bash
DEVICE=$1
EXPECTED_TRAP="192.168.10.100"
CURRENT_TRAP=$(snmpget -v2c -c public -Ovq $DEVICE 1.3.6.1.6.3.12.1.2.1.5.1.2.192.168.10.100)

if [ "$CURRENT_TRAP" != "$EXPECTED_TRAP" ]; then
echo "1|Trap配置被修改: $CURRENT_TRAP"
else
echo "0|Trap配置正常"
fi
根本原因定位步骤
如果以上方案都不能解决问题，需要进行深入定位：
步骤1：抓包分析UniSystem的行为
# 在设备上抓取UniSystem的通信
tcpdump -i eth0 host 192.168.1.100 and port 161 -w unisystem_snmp.pcap
# 分析UniSystem是否发送了SNMP SET请求
步骤2：查看UniSystem日志
# 查看UniSystem操作日志
tail -f /opt/unisystem/logs/operation.log
# 或
grep -i "snmp\|trap" /opt/unisystem/logs/*.log
步骤3：联系华三技术支持
提供以下信息：
UniSystem版本：2.74
设备型号和版本
问题详细描述
抓包文件
UniSystem日志文件
预防措施
建立变更管理流程：
所有自动化工具的操作都必须经过测试
生产环境使用前，先在测试环境验证
配置基线管理：
# 定期备份设备配置基线
config baseline save H3C_Device_Baseline
# 定期检查配置是否偏离基线
config baseline compare current-configuration H3C_Device_Baseline
使用配置管理工具：
考虑使用Ansible、SaltStack等工具替代UniSystem的部分功能
确保所有配置变更都有审批记录
实施网络配置审计：
部署网络配置审计系统
实时监控配置变更并告警
总结
这个问题确实很像是UniSystem 2.74版本的bug。建议的解决步骤：
立即执行：方案一中的设备端防护，防止配置被修改
短期解决：在UniSystem中关闭所有自动配置选项
中期解决：升级UniSystem到最新版本
长期解决：建立完善的配置变更管理和审计流程
如果问题持续存在，建议收集证据（日志、抓包）后联系华三技术支持，这可能是一个需要官方修复的缺陷。