hillstone现场故障处理指导手册
hillstone现场故障处理指导手册
目 录
1 Hillstone厂商联系方式... 4
2 进行用户环境调查... 5
3 故障处理基本思路... 6
3.1 检查设备工作是否正常... 6
3.1.1 查状态灯... 6
3.1.2 查能否管理... 7
3.1.3 口令丢失情况下的处理... 7
3.1.4 查故障现象... 7
3.2 查软件版本... 7
3.3 查设备周边情况，排除外围因素... 7
3.3.1 检测方法... 8
3.3.1.1 移除设备... 8
3.3.1.2 单独测试... 8
4 各类故障处理... 9
4.1 硬件故障... 9
4.1.1 扩展模块故障处理... 9
4.1.2 冷却系统故障处理... 9
4.1.3 电源系统故障处理... 9
4.1.4 Console配置系统故障处理... 9
4.2 不通... 10
4.2.1 二层及以下层... 10
4.2.1.1 物理链路... 10
4.2.1.2 数据链路... 11
4.2.1.3 Vlan. 14
4.2.1.4 ARP. 15
4.2.2 三层... 17
4.2.2.1 路由测试... 17
4.2.3 应用... 18
4.2.3.1 策略... 19
4.2.3.2 特殊应用... 20
4.2.4 设备测试License到期重启问题... 20
4.3 异常... 20
4.3.1 CPU占用率过高... 20
4.3.2 Session数过高... 21
4.3.3 HA异常处理... 21
4.3.4 内网用户丢包的处理... 21
4.3.5 目的NAT不生效的处理... 22
5 debug诊断与排错.. 23
5.1 debug数据流基本步骤... 23
5.2 各种情况下debug信息... 23
5.2.1 正常访问debug信息: 23
5.2.2 路由问题debug信息... 24
5.2.3 策略问题debug信息... 25
1 Hillstone厂商联系方式
Hillstone400服务热线——400 828 6655
2 进行用户环境调查
在解决用户故障前一定要清晰了解用户的现场环境，并生成《XXX客户服务过程记录》。
如果已经进行过调查则确认用户环境是否有变化，修改原有《XXX客户服务过程记录》，另存为一个新的文档。
3 故障处理基本思路
3.1 检查设备工作是否正常
3.1.1 查状态灯
|
指示灯 |
颜色 |
说明 |
|
PWR |
绿色常亮 |
系统电源工作正常 |
|
橙色常亮 |
电源工作异常 |
|
|
红色常亮 |
电源工作异常，此时系统处于关闭状态 |
|
|
熄灭 |
系统没有供电或处于关闭状态 |
|
|
STA |
绿色常亮 |
系统启动并正常运行 |
|
绿色闪烁 |
系统已启动并且正常工作 |
|
|
红色常亮 |
系统启动失败或者系统异常 |
|
|
ALM |
红色常亮 |
系统告警 |
|
绿色闪烁 |
系统处于等待状态 |
|
|
熄灭 |
系统正常 |
|
|
橙色闪烁 |
系统正在使用试用许可证 |
|
|
橙色 |
试用许可证到期，无合法许可证 |
|
|
HA |
绿色常亮 |
只有一台设备，工作在master状态 |
|
绿色闪烁 |
有一主一备两台设备，本设备工作master状态 |
|
|
橙色闪烁 |
有一主一备两台设备，本设备工作slave状态 |
|
|
红色闪烁 |
HA工作异常 |
|
|
LNK |
绿色常亮 |
端口与对端设备通过网线或光纤连接且连接正常 |
|
熄灭 |
端口与对端设备无连接或端口连接失败 |
|
|
ACT |
橙色闪烁 |
端口处于收发数据状态 |
|
熄灭 |
端口无数据传输 |
3.1.2 查能否管理
设备不能通过某些pc实现管理，原因：
l 查看设备时候配置有可信任主机，并且该地址是否在可信任主机列表中。
web下位置：系统-设备管理-可信任主机
cli下命令：show admin host
l 添加可信任主机及权限方法：
web下位置：系统-设备管理-可信任主机-新建
cli下命令：SA(config)# admin host A.B.C.D/M any
3.1.3 口令丢失情况下的处理
如果 Hillstone 山石网科数据中心防火墙的管理员口令丢失，请与当地代理商联系或通过系统复位的方法将密码恢复为出 厂默认值（警告：系统复位的同时所有设备信息都会恢复出厂设置，配置文件会被删除，请谨慎使用！）
3.1.4 查故障现象
3.2 查软件版本
l 使用 show vession 命令查看设备版本信息，如果版本低，是否存在BUG
l 如果条件允许建议升级到最新版本或最稳定版本
3.3 查设备周边情况，排除外围因素
确定是否是因设备引起的。
3.3.1 检测方法
3.3.1.1 移除设备
在移除设备不会影响网络应用或影响较小容易调整且用户允许的情况下，将怀疑有故障的设备从网络中移出，看应用是否正常。如果还不正常则要怀疑是否有其他故障。建议解决其他故障后再将设备还原回原来状态。
3.3.1.2 单独测试
单独测试故障部分链路及应用。
4 各类故障处理
4.1 硬件故障
4.1.1 扩展模块故障处理
扩展模块出现故障时，请对设备进行以下检查：
l 检查扩展模块是否与背板紧密接触，松不脱螺丝是否已经拧紧。
l 确认当前的 StoneOS 版本为 StoneOS 5.0。
l 使用 show module 命令查看扩展模块的状态信息，具体请查看《Hillstone 山石网科数据中心防 火墙命令手册》。
4.1.2 冷却系统故障处理
冷却系统包括风扇盘和过滤网。当风扇盘故障或过滤网堵塞时，机箱不能良好散热，导致温度升高， 如果温度过高，系统将自动关闭。
当冷却系统出现故障时，请对设备进行以下检查：
l 使用 show environment 命令查看设备的温度和风扇盘转速，具体请查看《Hillstone 山石网科 数据中心防火墙命令手册》。
l 查看风扇盘指示灯。风扇正常运行时，指示灯为绿色常亮；当指示灯显示红色，表示一个或更多的 风扇故障，请尽快更换风扇盘，避免系统过热，具体操作参阅冷却系统更换。
4.1.3 电源系统故障处理
用户可以根据电源指示灯的状态来判断产品电源系统是否发生故障，电源指示灯的状态及含义请参照 指示灯含义。电源系统工作正常时，电源指示灯应该保持绿色常亮；电源指示灯不亮时，请对设备进行以 下检查：
l 设备电源线是否连接正确。
l 设备的供电电源与所要求的电源是否一致。
4.1.4 Console配置系统故障处理
设备上电后，如果配置系统正常，将在配置终端上显示启动信息；如果配置系统出现故障，配置终端 可能无显示或者显示错误信息。
若配置终端无显示信息，请先进行如下检查:
l 电源是否正常。
l 配置电缆连接是否正确。
l 终端配置是否正确。 若以上检查未发现问题，则可能是配置电缆故障，请进行检查。
4.2 不通
4.2.1 二层及以下层
4.2.1.1 物理链路
此部分主要检查线路是否正常。
4.2.1.1.1 物理线路质量差
故障定位
双绞线：
l 检查网线线序是否符合规范。
l 检查网线接口是否插牢，是否正常。
l 检查指示灯状态是否正常。
l 网线内有断线情况，可能导致指示灯正常但线路不通。
l 检查线路所经路径上是否有大功率设备干扰。
l 检查线缆长度，是否超过105米。一般情况下，线路过长很容易引起信号强度下降、线路干扰过大。
光纤：
l 检查光纤接口是否插牢。
l 检查光纤类型和设备接口类型是否相符，单模、多模。
l 如果是单模光纤，如果激光功率太强或太弱也会导致通讯异常。检查是否需要使用衰减器。
解决办法
更换合格的线路。
如果是单模光纤激光强度异常，需要使用测试仪检测，调整强度即可。
如果是激光过强，可以用缠绕光纤的办法进行衰减，可以达到衰减器的效果。
参考资料
RJ45网线水晶头排线范参考如下：
1 2 3 4 5 6 7 8
T568A的线序为：白绿，绿，白橙，蓝，白蓝，橙，白棕，棕
T568B的线序为：白橙，橙，白绿，蓝，白蓝，绿，白棕，棕
不使用HUB或交换机两机连接，两端分别用T568A和T568B；
使用HUB或交换机则统一使用T568B。
一般情况下，网线只有1 2和3 6四根线起作用。
传输距离与速度：
超五类双绞线的最大传输距离为105米，平均传输速度为100M（最大峰值155M）。前提是双绞线的各项性能指标都要达到超五类双绞线的标准。
4.2.1.2 数据链路
4.2.1.2.1 数据链路问题
故障定位
检查线路通信状态。
使用PC或单独设备直连此链路，测试链路质量、速度。
检查用户接入设备状态，运行参数、跳线等是否正常。
如果是端到端设备检查两端设置是否一致。
SDH网络使用的协议转换器可能因局端作了环路，造成大量广播，现象类似于环路，可能造成防火墙不能正常收发。
案例：
ADSL：可能因ADSL提供商原因造成无法正常通讯，此时使用PC直接连接（可能是拨号，也可能是路由），测试线路是否能够正常传输，检查丢包率，测试接入速度。
专线：某单位采用SDH专线连接各分支，发现不通，经链路提供商测试物理线路正常。详细了解发现，此单位适用端到端的转换设备（SDH-ETH），但两端的转换设备的跳线设置不通，即两端设备的工作模式不同。将两端设备设成同一模式后线路通讯正常。
解决办法
请线路提供商调整线路；
调整接入设备的参数；
调整端到端设备的模式；
4.2.1.2.2 端口协商错误
故障定位
检查两端设备协商速率及全双工/半双工模式。
检查两端设备是否一致。
察看数据包收发数量，查看是否有只有发包没有收包，或收发包差距非常明显的情况。
察看校验错误包是否很多。
解决办法
调整两端设备配置，100兆链路推荐设为：两台设备都设为100M全双工。
调整设备其他参数。
4.2.1.2.3 MAC地址表错误
故障定位
检查是否学到真实的MAC地址。
本端和对端是否一致。
确认是否有地址冲突。
确认是否有ARP攻击。
解决办法
临时解决：
清理错误的MAC地址表。
手工绑定MAC对应关系。
最终解决：
找到MAC地址表错误的原因。
清理网络攻击源。
4.2.1.2.4 MTU值
故障定位
也请参考: ping
小包能ping通，但大包无法ping通，很可能是MTU问题。
部分应用不通，但其他应用正常也有可能与MTU值有关。
可以用Ping大包的方式测试是否有MTU问题。
故障原因
防火墙接口MTU值能小于嵒机MTU值，例如：
当防火墙的接口MTU值设为1300时，主机的MTU值缺省为1500时，主机穿过防火墙的连接能够打开服务器的相关页面，但修改相关的资料时无法提交成功。分析为防火墙接口MTU值比主机MTU值小，主机与服务器协商出合适的MSS值，但经过IP层封装后的某些数据包就会大于1300但不大于1500，并且对不大于1500的包DF位置1，这样的包到达防火墙后就被防火墙丢弃了。因此就会出现能够打开网页，但修改资料无法提交成功及通过网页收发邮件无法上传附件等现象。建议正常情况下要修改防火墙的MTU值。
解决办法
尝试调整防火墙MTU值，使之符合应用的要求。
可以通过抓包分析判断MTU值。
4.2.1.3 Vlan
4.2.1.3.1 Vlan号错误
故障定位
检查Vlan的设置，是否有需要的Vlan号；
检查接口设置，确认关联接口属于Trunk需要的Vlan范围。检查接口的NativeID。
检查前后设备的Vlan配置。
故障原因
防火墙在Trunk模式下，如果想要前后设备的Vlan通讯，必须在防火墙Vlan设置里绑定相应的Vlan号。
解决办法
4.2.1.3.2 相邻设备配置问题
故障定位
检查相邻设备Vlan配置，Vlan号、Trunk设置。
注意相邻设备Trunk类型。部分路由交换设备的默认协议是dot1q，但如果防火墙接入则可能造成无法正常穿越，需要手工将路由交换设备的协议指定为dot1q才可以。
解决办法
正确配置防火墙接口、Vlan等参数；
遇到前后设备采用默认Vlan类型，即便默认类型也是802.1q，也要手工设置为802.1q。
4.2.1.4 ARP
4.2.1.4.1 自身ARP表错误
故障定位
检查防火墙自身ARP表是否真实
确认网络中是否有ARP攻击，可能因ARP攻击造成IP-MAC地址对应错误。
部分网络监控、管理软件采用ARP攻击原理工作，确认网络是否有类似软件。如：网络执法官、P2P控制软件等。
故障原因
ARP攻击会造成受影响的防火墙及客户端ARP表错误，即造成IP地址与MAC地址对应错误，使得数据报不能正确地发送给真实的主机。
解决办法
在防火墙及所有客户端均进行ARP绑定。
清除网络内ARP攻击源。
参考资料
要了解故障原理，我们先来了解一下ARP协议。
在局域网中，通过ARP协议来完成IP地址转换为第二层物理地址（即MAC地址）的。ARP协议对网络安全具有重要的意义。通过伪造IP地址和MAC地址实现ARP欺骗，能够在网络中产生大量的ARP通信量使网络阻塞。
ARP协议是“Address Resolution Protocol”（地址解析协议）的缩写。在局域网中，网络中实际传输的是“帧”，帧里面是有目标主机的MAC地址的。在以太网中，一个主机要和另一个主机进行直接通信，必须要知道目标主机的MAC地址。但这个目标MAC地址是如何获得的呢？它就是通过地址解析协议获得的。所谓“地址解析”就是主机在发送帧前将目标IP地址转换成目标MAC地址的过程。ARP协议的基本功能就是通过目标设备的IP地址，查询目标设备的MAC地址，以保证通信的顺利进行。
每台安装有TCP/IP协议的电脑里都有一个ARP缓存表，表里的IP地址与MAC地址是一一对应的，如下表所示。
主机 IP地址 MAC地址
A 192.168.16.1 aa-aa-aa-aa-aa-aa
B 192.168.16.2 bb-bb-bb-bb-bb-bb
C 192.168.16.3 cc-cc-cc-cc-cc-cc
D 192.168.16.4 dd-dd-dd-dd-dd-dd
我们以主机A（192.168.16.1）向主机B（192.168.16.2）发送数据为例。当发送数据时，主机A会在自己的ARP缓存表中寻找是否有目标IP地址。如果找到了，也就知道了目标MAC地址，直接把目标MAC地址写入帧里面发送就可以了；如果在ARP缓存表中没有找到相对应的IP地址，主机A就会在网络上发送一个广播，目标MAC地址是“FF.FF.FF.FF.FF.FF”，这表示向同一网段内的所有主机发出这样的询问：“192.168.16.2的MAC地址是什么？”网络上其他主机并不响应ARP询问，只有主机B接收到这个帧时，才向主机A做出这样的回应：“192.168.16.2的MAC地址是bb-bb- bb-bb-bb-bb”。这样，主机A就知道了主机B的MAC地址，它就可以向主机B发送信息了。同时它还更新了自己的ARP缓存表，下次再向主机B发送信息时，直接从ARP缓存表里查找就可以了。ARP缓存表采用了老化机制，在一段时间内如果表中的某一行没有使用，就会被删除，这样可以大大减少ARP缓存表的长度，加快查询速度。
从上面可以看出，ARP协议的基础就是信任局域网内所有的人，那么就很容易实现在以太网上的ARP欺骗。对目标A进行欺骗，A去Ping主机C却发送到了DD-DD-DD-DD-DD-DD这个地址上。如果进行欺骗的时候，把C的MAC地址骗为DD-DD-DD-DD-DD-DD，于是A发送到C上的数据包都变成发送给D的了。这不正好是D能够接收到A发送的数据包了么，嗅探成功。
A对这个变化一点都没有意识到，但是接下来的事情就让A产生了怀疑。因为A和C连接不上了。D对接收到A发送给C的数据包可没有转交给C。
做“man in the middle”，进行ARP重定向。打开D的IP转发功能，A发送过来的数据包，转发给C，好比一个路由器一样。不过，假如D发送ICMP重定向的话就中断了整个计划。
D直接进行整个包的修改转发，捕获到A发送给C的数据包，全部进行修改后再转发给C，而C接收到的数据包完全认为是从A发送来的。不过，C发送的数据包又直接传递给A，倘若再次进行对C的ARP欺骗。现在D就完全成为A与C的中间桥梁了，对于A和C之间的通讯就可以了如指掌了。
4.2.1.4.2 对方设备有ARP绑定
故障定位
测试对方设备是否有ARP绑定。
询问对方管理人员是否有ARP绑定。
可能因对端设备压力较大、运行故障等原因造成对方ARP表不能及时更新，表现的现象和ARP绑定相似。
故障原因
如果对方存在ARP绑定会造成发过去的所有数据包均被丢弃，使得网络不通。
解决办法
要求对方重新绑定。
修改防火墙对应接口MAC地址为绑定的地址。
如果是假绑定，多等待一段时间、多重启几次防火墙，或重启对方设备都有可能解决。
4.2.2 三层
4.2.2.1 路由测试
4.2.2.1.1 故障定位
通过Ping、Tracert等方式确定整个路径上的各个节点的工作状态。
定位问题出现在那台设备上。
检查有问题设备的路由表。
检查传输过程中是否有NAT，转换是否正常。
一般按照下面的方法进行。
ping
可分为Ping小包、Ping大包两种方式。
要按照网络拓扑，由近及远，依次ping各个IP。
小包
ping x.x.x.x -t
大包
ping x.x.x.x -l 1472 -f
ping长度为1472的满包，-f表示不分片
ping x.x.x.x -l 1473
ping长度为1473的包，此包超过最大单包长度，测试MTU问题；
tracert
测试线路由近及远的各个节点，目前可能因中间设备导致不通。此方法仅在少数环境下有效。
4.2.2.1.2 路由分析
要从路由中明确数据包的传输路径，分析数据包是否能够正确的传出并返回。
检查静态路由表
检查动态路由
OSPF
发布出去
配置时需要用命令行将静态路由发布出去
发布静态路由命令
OSPF redistribute static
还有发布IP、发布直连路由
分析数据包来回路径
考虑双出口路由
4.2.2.1.3 解决办法
如果路由错误则调整路由表。
如果NAT设置错误则调整NAT策略。
MTU问题则须调整MTU值。
4.2.3 应用
首先确定服务所使用的协议及端口号；
4.2.3.1 策略
4.2.3.1.1 检查策略
故障定位
PF策略
检查防火墙PF策略中是否已将相应协议及端口号放开；
通讯策略
检查防火墙通讯策略中是否已将相应协议及端口号放开；
NAT策略
检查防火墙NAT策略中是否已将相应地址、协议及端口号进行了正确的转换；
有时会因地址转换后NAT和MAP不一致导致应用不通。
邮件服务
接收正常，发出的邮件经常被退。
可能因NAT和MAP不一致，导致地址反解析错误，地址被拒绝。
网上银行
也请参考: 考虑双出口路由
部分网络银行的验证比较严格，可能因地址转换导致登陆IP与访问的IP不同，造成访问被拒绝。
DPI策略
如果是HTTP、FTP、SMTP、POP3等服务，检查应用端口绑定中是否有此应用服务的端口。
检查防火墙DPI策略中是否已将相应服务放开；
如果策略全放开不通
先查路由表
也请参考: 路由分析
再查ARP表
也请参考: ARP
解决办法
搞清用户需求。
分析数据流程。
调整策略。
4.2.3.2 特殊应用
4.2.3.2.1 视频
4.2.3.2.2 组播
4.2.4 设备测试License到期重启问题
默认出厂设备有测试License，如果设备测试License到期后未导入正式License或续期测试License，重启后则防火墙恢复出厂配置（原配置文件保存在防火墙内，但无法引导）。
4.3 异常
4.3.1 CPU占用率过高
l 查看设备当前吞吐是否到达设备极限，如果到达设备极限，建议通过减少通过设备流量，或者更换其他高性能防火墙的方式来解决。
l 查看设备是否开启太多的统计集，如果统计集功能开启较多会占用较大cpu，建议通过关闭统计集的方法来降低cpu的使用率。如果确实需要开启统计集，建议在一定时间内开启，待结果统计出来后即刻关闭统计集。
l 查看设备是否开启debug，cli下输入 show debug 如果开启建议关闭debug，方法：使用命令undebug all。
l 设备开启太多占用cpu资源的功能，建议暂时关闭部分功能，或者更换高性能防火墙。
l 查看设备上是否有DoS/DDos攻击流量，开启攻击防护中的SYN Flood和UDP Flood攻击防护功能。
4.3.2 Session数过高
通过show session generic 或web 查看到设备session数使用过多，解决方法：
l 在统计集中开启基于用户的session数统计，查看具体session数字过大的ip，手动将该ip的session删除，命令：clear session src-ip ip-address，来暂时降低设备的session。
l 通过配置session-limit的形式来控制用户的session数
l 查看设备上是否有DoS/DDos攻击流量，开启攻击防护中的SYN Flood和UDP Flood攻击防护功能。
4.3.3 HA异常处理
在HA正常配置后，如果网络结果不发生变化，很少出现问题。如果出现问题一般是由于HA心跳线由于某种原因断开所致。
建议出现问题后先通过下面的几个命令查看HA状态，可以先暂时将备用设备的HA功能关闭，检查两台设备HA部分配置是否一致，确认无误后再开启备用设备的HA功能。
查看HA状态命令:
l show ha link status //查看HA link 状态 ，确认HA link接口状态是否正常。
l show ha group config //查看HA group 配置状态 ，确认HA group相关配置。
l show ha group 0 //通过查看HA group 0 状态 ，确认对端状态是否正常。
l show ha cluster //查HA簇配置信息。
l show ha sync state config //查看HA配置同步状态。
l no ha cluster //关闭HA配置。
4.3.4 内网用户丢包的处理
l 确认用户到到网关是否丢包，如果内网网关丢包请检查内网交换、路由问题。
l 确认到内网不丢包，到外网网关丢包，请检查从防火墙上到外网网关是否有丢包，如果丢包请联系线路供应商检查链路质量。
l 确认从防火墙上到外网网关不丢包，请检查防火墙cpu是否很高，如果cpu高请根据cpu高的处理方法操作。
l 确认cpu不高，请开启接口带宽统计集，查看接口带宽是否占满，如果带宽占满，请考虑通过配置qos功能对流量做控制。
l 确认带宽不高，请检查snat的转换后地址源端口占用检测，使用命令show snat resource vrouter trust-vr
4.3.5 目的NAT不生效的处理
l 检查服务器本身端口是否开启。
l 检查是否有从外到内的策略是否有放行，源地址为any 目的地址为映射后的公网地址。
l 检查内网服务器网关配置是否正确
5 debug诊断与排错
5.1 debug数据流基本步骤
1、关闭debug信息输出到console
no logging debug to console
2、清除缓存debug日志信息
clear logging debug
3、设置debug过滤器
debug dp filter {src-ip | src-port | proto | dst-ip | dst-port}
4、开启debug功能
debug dp basic
5、发起数据流访问
6、查看debug日志信息
show logging debug
7、关闭debug
undebug all 或 连击“ESC”两次 （必须退出，否则影响CPU性能）
8、查看调试功能开启或者关闭状态
show debug
9、查看debug 过滤器
show dp-filter
10、删除debug过滤器
undebug dp filter id
5.2 各种情况下debug信息
5.2.1 正常访问debug信息:
hostname(config)# sh log deb
2009-03-04 16:17:39, DEBUG@FLOW: core 0 (sys up 0x8e65ae ms): 001d.7294.e5f6->00
1c.5402.8c00, size 73, type 0x800, vid 0, port ethernet0/0
Switchid is 8(interface ethernet0/0) port ethernet0/0
Start l3 forward
Packet: 192.168.1.12 -> 202.106.0.20, id: 8369, ip size 59, prot: 17(UDP): 3332
-> 53
① No session found, try to create session
----------------First path creating new session-----------------
--------VR:trust-vr start--------
192.168.1.12:3332->202.106.0.20:53
② No DNAT configured for this VR
③ Get nexthop if_id: 10, flags: 0, nexthop: 10.188.9.1
④ Found the reverse route for force revs-route setting
⑤ Matched source NAT: snat rule id:1
Matched source NAT: source port3332->port3332
--------VR:trust-vr end--------
⑥ Pak src zone trust, dst zone untrust, prot 17, dst-port 53.
Policy 1 matches, ===PERMIT===
⑦ Identified as app DNS (prot=17). timeout 60.
flow0 src 192.168.1.12 --> dst 202.106.0.20 with nexthop 0.0.0.0 ifindex 0
flow1 src 202.106.0.20 --> dst 10.188.9.100 with nexthop 192.168.1.12 ifindex 8
flow0's next hop: 192.168.1.12 flow1's next hop: 10.188.9.1
crt_sess->revs_rres.nextop: 192.168.1.12, crt_sess->revs_rres.nexthop 10.188.9.1
Application 7 hasn't been registered, don't need do ALG
APP inited for application 7
The following session is installed
⑧ session: id 99962, prot 17, flag a, created 9332, life 60
flow0(if id: 8 flow id: 199924 flag: 801): 192.168.1.12:3332->202.106.0.20:53
flow1(if id: 10 flow id: 199925 flag: 800): 202.106.0.20:53->10.188.9.100:3332
Session installed successfully
-----------------------First path over---------------------
⑨ Found the session 99962
session: id 99962, prot 17, flag 4a, created 9332, life 60
flow0(if id: 8 flow id: 199924 flag: 811): 192.168.1.12:3332->202.106.0.20:53
flow1(if id: 10 flow id: 199925 flag: 810): 202.106.0.20:53->10.188.9.100:3332
Set fast code to fe proc
Go to fe proc directly
Got mac: ip:10.188.9.1, mac:001c.5400.1dc1
L3 forward, out if is ethernet0/2
msw_dsa_tag_encap_from_cpu: TX packet from interface ethernet0/2, vid 0 cos 0.
5.2.2 路由问题debug信息
-----------------First path creating new session-----------------
--------VR:trust-vr start--------
192.168.1.12:55577->10.188.7.10:53
No DNAT configured for this VR
Failed to get route to 10.188.7.10 (找不到路由存在)
Dropped: Can't find forwarding route. Abort!!
deny session:flow0 src 192.168.1.12 --> dst 10.188.7.10 Deny session installed s
uccessfully
--------VR:trust-vr end--------
-----------------------First path over (session not created)
Droppped: failed to create session, drop the packet
5.2.3 策略问题debug信息
-----------------First path creating new session-----------------
--------VR:trust-vr start--------
192.168.1.12:4716->202.106.0.20:53
No DNAT configured for this VR
Get nexthop if_id: 10, flags: 0, nexthop: 10.188.9.1
Found the reverse route for force revs-route setting
Matched source NAT: snat rule id:1
Matched source NAT: source port4716->port4716
--------VR:trust-vr end--------
Pak src zone trust, dst zone untrust, prot 17, dst-port 53.
No policy set in this ctxt, default ===DENY=== (找不到策略允许)
Dropped: Can't find policy/policy denied. Abort!!
deny session:flow0 src 192.168.1.12 --> dst 202.106.0.20 Deny session installed successfully
-----------------------First path over (session not created)
