fw ctl fast_accel - some traffic still going slow path

[Rafal_N]

Hi Team,

I'm using fast_accel for few months and it works fine with backup traffic, cifs/smb etc but in heavy_conection there are still traffic to DB servers. Issue is with internal traffic ms sql (tcp 1433). It still produce some CPU spikes.

Some days ago I found out fw_mux command and it looks that every connection with tcp 1433 it is not accelerated. Can any one help me figure out what can cause that?? 

R80.30 take 219 kernel 2.6

fw ctl fast_accel show_state
fw fast_accel: The feature state is: enabled.

------------------------------------ FIREWALL FAST ACCEL TABLE ------------------------
# Source IP Destination IP D-Port Protocol Hit count
---- ------------------ ------------------ ------ -------- -----------
19) 192.168.184.0/22 192.168.184.0/22 any 6 9686885
20) 192.168.0.0/16 192.168.0.0/16 1433 6 0

Two examples form fw_mux

Connection: <dir 0, 192.168.184.90:41622 -> 192.168.186.20:1433 IPP 6>
VM_Connection: <dir 1, 192.168.184.90:41622 -> 192.168.186.20:1433 IPP 6>
Info:
Path: Slow, Streaming mode: PSL, InZone: INTERNAL_ZONE, OutZone: UNDEFINED_ZONE, Num of registered apps: 2
Rule id: 59, ref count: 2, mux state flags: VM_CONN_WAS_SET ,INSPECT_C2S ,INSPECT_S2C.
APPS:
ADVP: app_flags: INSPECT_BOTH, C2S byte skip: 0, S2C byte skip: 0
TIER1: app_flags: NO_FLAGS, C2S byte skip: 0, S2C byte skip: 0

Connection: <dir 0, 192.168.100.95:40600 -> 192.168.186.20:1433 IPP 6>
VM_Connection: <dir 1, 192.168.100.95:40600 -> 192.168.186.20:1433 IPP 6>
Info:
Path: Slow, Streaming mode: PSL, InZone: INTERNAL_ZONE, OutZone: UNDEFINED_ZONE, Num of registered apps: 2
Rule id: 59, ref count: 2, mux state flags: VM_CONN_WAS_SET ,INSPECT_C2S ,INSPECT_S2C.
APPS:
ADVP: app_flags: INSPECT_BOTH, C2S byte skip: 0, S2C byte skip: 0
TIER1: app_flags: NO_FLAGS, C2S byte skip: 0, S2C byte skip: 0

Any ideas? hints where should I look for?

Best regards,

Rafal 

[PhoneBoy]

Is it all connections on 1433 not being accelerated or specific ones?
Recommend a TAC case here.

[Timothy_Hall]

If traffic has to go F2F/slowpath, it cannot be forced into the SXL/accelerated path with fast_accel and will still go F2F.  If you can figure out why the SQL traffic is going F2F and fix that, fast_accel should start working. 

First off, may I ask how you are getting that "fw_mux" output?  I don't recognize it.

To get the traffic out of F2F, check the following two things:

1) In the service matching TCP port 1433 try removing any overrides like this, as it is fairly typical to override and increase the session timeout beyond the default on SQL services:

2) If you have IPS enabled, check for enabled IPS signatures involving SQL that have a Performance Impact rating of Critical or High.  Try disabling them in whatever IPS profile(s) your gateway is using, as one or more of these signatures may be pulling that SQL traffic into F2F.  Here are the relevant signatures I see here in my lab:

If neither of these suggestions help or are not relevant to your environment, please provide the output of command enabled_blades so I can see what features you have enabled.

Beyond that TAC will need to run a kernel debug to determine why this SQL traffic is going F2F.

[Rafal_N]

Hi Timothy,

I'm glad that once I can share something with You 🙂

Output is form fw_mux command that is not documented. I get know about it on TAC Academy with really good coach Alon form CheckPoint HQ. As You probably notice there is no connections with flag F listed any more in fwaccel conns. The only way I know to print all connections F2F and PXL is that new command (fw_mux all > file.txt)

I try to debug a little more with TAC because service looks very standard as in default settings, IPS exceptions between this internal networks is added and yet with 1433 there is a problem. Was hoping that somebody can read something more form that output. Later I try to play with kernel debug but I have to do it some filters.

Best regards,

Rafal

[miguel]

Hi Rafal,

Did you find any solution to this? I am just starting to try to accelerate ms-sql-s (1433) myself and see 0 hits in 'fw ctl fast_accel show_table' output. I'll open a TAC case as well.

Thanks,

[Rafal_N]

Just check history SR with TAC we had some remote sessions. Didn't find any solution other then clearing all connection form connections table. Please be careful because it will cause all connection to be reestablish. 

fw tab -t connections -x

I'm not sure if I solve it at all but I can share with You SR number (pm) and maybe there will be some internal notes made by TAC engineer.