vsx fwaccel output

[dj0Nz]

I've got some weird behavior here, maybe somebody can explain: Customer has a VSX cluster that we upgraded to R80.20 JHF 118 recently. After we upgraded, we noticed that fwaccel stat doesn't show the rule which disables templating any more. I noticed that one vs has about 19% F2F traffic but no clue which rule is causing that.

Any ideas?

Oh, I forgot: There is one vs where fwaccel stat states that templating is disabled by rule 650 but there are only 630 rules in that ruleset. This is the only vs in which fwaccel stat displays anything at all.

Looks like we should open a case, isn't it?

[PhoneBoy]

What did you upgrade from?
And yes might be worth opening a case.

[dj0Nz]

We upgraded from R77.30. Support case is on the way. I am really curious what comes of it.

Additionally, we have some CoreXL issues on the same cluster (CPAP-15400 platform): After upgrading we noticed that the upgrade obviously activated hyperthreading which caused performance issues. All virtual systems have been running without CoreXL in R77.30 without issues. After the upgrade, we had to activate CoreXL on some machines because they started to show high CPU usage which was logical somehow. One of the cluster members still doesn't spawn multiple instances although configured. The other does. Strange. But I don't think this is related to the SecureXL issue, maybe we will open a separate case for that.

Oh, and there is more: After the R80.20 upgrade, the MAC address of one of the bond interfaces changed. That was really nasty because proxy arp was configured. sk98219 explaines what might have happened but it took a while until we found out why certain services do not work any more. 😅

[Chris_Atkinson]

sk32578 outlines improvements to SXL in R80.10 above and what things to look for in the policy that may impact templating / acceleration.

TAC may assist to further validated the outputs the gateway is producing in this regard taking into consideration implied rules etc. 

[dj0Nz]

Thank you very much for your message. But the point is: normally fwaccel stat prints a message saying which rule disables templating:

Accept Templates   : disabled by Firewall
                     Layer <Name_of_Layer> disables template offloads from rule #<N>
                     Throughput acceleration still enabled.

This message is missing here although we have a significant amount of F2F traffic. Sure we may investigate that manually, but I rather like to know why this is happening. We'll see what comes out of the tac case. I am curious. 

[Timothy_Hall]

> I've got some weird behavior here, maybe somebody can explain: Customer has a VSX cluster that we upgraded to R80.20 JHF 118 recently. After we upgraded, we noticed that fwaccel stat doesn't show the rule which disables templating any more.

Good, that means that the relaxing of the templating rules in R80.10+ via constructs such as NMR/NMT templates is allowing your entire rulebase to use Accept templates.

> I noticed that one vs has about 19% F2F traffic but no clue which rule is causing that.

Separate issue, status of SecureXL rule templating has no impact on SecureXL Throughput Acceleration (i.e. which path the traffic is processed in).  Would need to see which blades are enabled in the VS with 19% F2F (command enabled_blades) to hazard a guess about that.  Less than 10% F2F is generally OK though, so 19% F2F is not the end of the world and reducing it probably won't make a huge difference.

> Oh, I forgot: There is one vs where fwaccel stat states that templating is disabled by rule 650 but there are only 630 rules in that ruleset. This is the only vs in which fwaccel stat displays anything at all.

Is the VS being managed by an MDS?  Are you using Global Rules and objects?  That may account for the "extra" rules at the end.  It sounds like templating is being stopped well past the end of your local rulebase, so resolving that once again probably won't make much difference.  Also this SK is old but may be relevant to your situation: sk62323: Output of 'fwaccel stat' shows that SecureXL Accept Templates are disabled from rule, whose...

[Timothy_Hall]

> I've got some weird behavior here, maybe somebody can explain: Customer has a VSX cluster that we upgraded to R80.20 JHF 118 recently. After we upgraded, we noticed that fwaccel stat doesn't show the rule which disables templating any more.

Good, that means that the relaxing of the templating rules in R80.10+ via constructs such as NMR/NMT templates is allowing your entire rulebase to use Accept templates.

> I noticed that one vs has about 19% F2F traffic but no clue which rule is causing that.

Separate issue, status of SecureXL rule templating has no impact on SecureXL Throughput Acceleration (i.e. which path the traffic is processed in).  Would need to see which blades are enabled in the VS with 19% F2F (command enabled_blades) to hazard a guess about that.  Less than 10% F2F is generally OK though, so 19% F2F is not the end of the world and reducing it probably won't make a huge difference.

> Oh, I forgot: There is one vs where fwaccel stat states that templating is disabled by rule 650 but there are only 630 rules in that ruleset. This is the only vs in which fwaccel stat displays anything at all.

Is the VS being managed by an MDS?  Are you using Global Rules and objects?  That may account for the "extra" rules at the end.  It sounds like templating is being stopped well past the end of your local rulebase, so resolving that once again probably won't make much difference.  Also this SK is old but may be relevant to your situation: sk62323: Output of 'fwaccel stat' shows that SecureXL Accept Templates are disabled from rule, whose...

[dj0Nz]

Well, this explains a lot. Maybe I should spend some (more) time to read about the SecureXL changes in R80+. Indeed, the machine showing 19% F2F traffic doesn't have any performance issues, But still I a missing the "normal" fwaccel stat hint because there is only firewall and ips blade active in that vs.

And yes, this is a MDM environment and we have global rules, but the mentioned rule numbers don't show up in the files that are mentioned in sk62323. I will have to investigate this further. Because we have no real malfunction there, I don't think we will open a case for that.

Thank you very much.