R80.20SP fw monitor -F issue

[bryanastudillo]

Hello folks,

About a year ago in a customer that has the Chassis 64k platform we began to notice that the acceleration cores suddenly began to increase their use until they reached 100%. This caused a drastic drop in communications. After several hotfix installations the problem was not solved, first we thought that the problem was caused when we executed a zdebug, but after several tests that I executed, I discovered that the massive consumption of the acceleration cores occurred after executing the tool " fw monitor -F "despite terminating it with the ctrl + c command, it seemed that the tool was still running underneath and when running a zdebug it caused the acceleration cores to reach 100% again. So the solution I found to the problem is to use the fw monitor -U command to disable the fw monitor and no longer use it with the -F flag but with the -e flag.

I have opened a case with the TAC but so far I have not had a response. Did the same thing happen to someone else?

[Timothy_Hall]

The fw monitor -F option is not really the typical fw monitor chain module insertion mechanism employed by the -e option, -F is merely setting a kernel debug in the sim driver which is why the filtering syntax is so limited with -F.  It sounds like some prior -F debugs were not properly terminated and you were allowed to start more.  In R80.40 (and possibly earlier versions, not sure) if any prior currently-running fw monitor captures (-e and/or -F) are detected the new capture attempt is rejected, and it tells you to run fw monitor -U first to kill the old one.

The other thing that may have happened to you is that there does not appear to be any syntax checking on the srcIP,srcPort,dstIP,dstPort,IPProto filter used with -F, and if you make a mistake it simply gives you the equivalent of 0,0,0,0,0 with no warning which is absolutely all traffic.  Concerning and quite dangerous in my opinion since a runaway debug inside SecureXL/sim is an easy way to thoroughly overload or at least severely impact the firewall.

[bryanastudillo]

Hello, I did the test by defining from fw monitor -F a filter with specific ip addresses. Also, before running it, I had disabled any type of debugging with the fw ctl debug 0 and fwaccel dbg resetall commands. The TAC is still investigating the case.

[bryanastudillo]

Hello,

The TAC and RnD team gave me a workaround to use "fw monitor -F" command without snd cpu problems, here is the workaround:

·       just before using the fw monitor run: fw ctl debug -x

·       run monitor

·       reset default debug flags by running: fw ctl debug 0

[Timothy_Hall]

Actually I believe just running fw monitor -U once your fw monitor -F command is complete will do the same thing.  As covered in my Max Capture course, the -U option hunts down any fw monitor commands that might still be running and exterminates them, and I believe resets any associated debug flags as well.