从你贴的配置来看,日志发不出去很可能不是因为路由不通,而是日志功能的全局开关没开,或者是日志发送的规则被限制了。
这是最关键的一步。就像总电闸没开一样,info-center enable 命令是日志功能的总开关,缺省情况下是关闭的。
检查命令:display info-center,查看 Information Center 字段。
状态解读:如果显示 enabled,则跳过;如果显示 disabled,需要开启。
修复命令:
你需要确认 loghost 通道已经“放行”了你要发送的日志信息。
检查命令:display info-center,查看 loghost 行的信息。
操作建议:为快速测试,可以先允许所有模块的所有信息输出,确认能收到日志后,再根据实际需求收紧规则。
测试命令:
“Ping通”只能说明ICMP协议畅通,无法证明UDP端口可用。最直接的办法是在服务器上抓包。
Linux服务器:执行 sudo tcpdump -i any udp port 514。
Windows服务器:使用Wireshark抓包,过滤规则 udp.port == 514。
分析结果:如果在抓包时拔插网线,能看到来自交换机IP的UDP包,说明网络没问题;否则说明包根本没发到服务器,问题在交换机或中间网络。
交换机发送的Syslog是UDP 514端口的报文。如果中间有防火墙或ACL,可能会阻断UDP 514端口的通信。
排查思路:
检查路径上的防火墙、ACL规则,确认没有阻断UDP 514端口。
可以尝试临时将日志端口改为一个非常规端口(如 info-center loghost 192.168.1.100 port 20000)绕过可能的限制。
部分日志服务器在接收到时间戳严重错误的日志时,会将其丢弃。
检查命令:display clock。
修复命令:建议配置NTP服务,确保双方时间同步。
如果只是收不到部分日志(如接口UP/DOWN),很可能是日志记录级别太高,细节信息被过滤了。
检查命令:display info-center。
修复命令:测试时可将级别临时调至 debugging。
极少数情况下,日志服务器无法解析H3C的非标准格式。
修复命令:将日志格式设置为标准Syslog格式。
确认路由:执行 display ip routing-table,检查到日志服务器的路由下一跳是G1/0/16,避免出现路由环路。
确认端口UP:display interface GigabitEthernet 1/0/16,确保端口状态为UP。
CPU利用率:display cpu-usage。如果CPU过高,可能因性能问题导致日志丢失。
暂无评论
security-policy
rule name LOG_TO_SERVER
source-zone local
destination-zone trust
service udp-514
action pass
info-center loghost 192.168.1.100 vpn-instance public
info-center enable
info-center source default loghost level informational
ping -a 192.168.1.x 192.168.1.100
# 开启日志
info-center enable
# 输出级别
info-center source default loghost level informational
# 日志服务器(关键:vpn-instance public)
info-center loghost 192.168.1.100 vpn-instance public
info-center loghost source GigabitEthernet1/0/16
# 必配安全策略
security-policy
rule name SYSLOG
source-zone local
destination-zone trust
service udp-514
action pass
display info-center
display loghost
display security-policy rule name SYSLOG
debugging info-center send // 可看到是否发送失败
暂无评论
亲~登录后才可以操作哦!
确定你的邮箱还未认证,请认证邮箱或绑定手机后进行当前操作
举报
×
侵犯我的权益
×
侵犯了我企业的权益
×
抄袭了我的内容
×
原文链接或出处
诽谤我
×
对根叔社区有害的内容
×
不规范转载
×
举报说明
暂无评论