报文示踪应用(二)

发布时间:  2012-12-14 浏览次数:  78 下载次数:  0
问题描述
某客户web服务器无法访问,ping该服务器地址不通。
告警信息
处理过程
可从路由查起,先查看本设备的路由配置及实际生效的路由。
使用disp cur | inc ip rout 来查看配置的静态路由,
使用disp ip routing来查看实际生效的动态和静态路由,
当路由表项很大时,查阅起来比较费事,可使用过滤条件来筛选路由,本文介绍另一种方法来定位路由问题。
配置一个acl
acl number 3330 
rule 5 permit ip destination 100.1.1.11 0 
在用户视图下
<usg2210>debug ip packet-trace acl 3330
<usg2210>t m
<usg2210>t d
发现有如下输出:
*0.114939110 USG2200 DEBUG/7/Debug_trace: 
Datetime: 2012/12/13 15:38:7 
Debug type: CPU debug trace.
4996:99.1.1.2:43990-->200.1.1.1:2048,1,EthType:0x800,Len:84,MF:0,Offset:0. 
packet passed valid check.   
receive from G0/0/0 zone:trust VFW<public>
search route (99.1.1.2-->200.1.1.1) in VFW<public> 
no route, packet dropped.
发现转发时因查不到路由而将报文丢弃。  
根因
业务不通问题与网络链路、网络设备、服务器等诸多因素相关,一般建议先从网络查起,再查设备,逐步缩小范围,例如:先从路由查起,使用ping 确定路由是否可达,如不可达使用tracert确定路由在哪里中断,如果路由可达再进一步确认关键节点的设备配置及访问策略是否有问题。关键节点如NAT网关、防火墙等。
建议与总结
通过报文示踪可以方便的定位报文在穿越设备时的转发情况和丢包原因,建议在排查故障时多使用这种手段。

END