topic Re: High latency on CPAP-SG3600 HA-cluster running Gaia R81.20. HCP complains about 99.26% F2F traff in Firewall and Security Management

High latency on CPAP-SG3600 HA-cluster running Gaia R81.20. HCP complains about 99.26% F2F traffic.

RamGuy239 — Fri, 24 Mar 2023 14:26:29 GMT

Greetings,

I'm facing issues with high latency on a CPAP-SG3600 HA-cluster. I have a TAC-case on this topic, but I wanted to check if anyone has some pointers.

This HA-cluster has been doing just fine until mid-February. Then we started facing periods with extreme latency through the active firewall (3000 ms+), and forcing a failover would always solve it. Then the issue would just re-occur a few hours later. Rinse and repeat.

The HA-cluster has been running Gaia R81.20 GA since November without issues until mid-February. In late February, we applied R81.20 JHF Take 8, but it made no difference. Last week I did a clean install from USB on both gateways. I did also run HDT (Hardware Diagnostic Tools). But still the same behaviour.

After digging through /var/log/messages I noticed messages pointing towards issues with PrioQ. After disabling PrioQ the latency issues went away. But they keep returning, not as frequently as earlier, but it still happens often. I also stumbled upon sk180437 - Unexpected traffic latency or outage on a Security Gateway / Cluster after policy installation. Noticed we had similar messages in /var/log/messages as referenced in the SK, so I applied the solution. This didn't seem to change anything.

https://support.checkpoint.com/results/sk/sk180437

Upon reviewing my latest Health CheckPoint (HCP) report, I noticed it complaining about:

F2F rate is high. Can be reduced by optimizing rule-base, changing blades or additional configurations - check 'sk98348' section (3-5). packets in the last 5 seconds: 214177, slow path packets: 212613, percentage: 99.269762859690815%

This struck me as quite odd. We don't have anything in our firewall policy that should hamper SecureXL in such a way:

Accept Templates : enabled
Drop Templates : enabled
NAT Templates : enabled
LightSpeed Accel : disabled

But we are clearly having issues with accelerated traffic as pretty much all traffic is hitting F2F:

[Expert@:0]# fwaccel stats -s
Accelerated conns/Total conns : 22/687 (3%)
LightSpeed conns/Total conns : 0/687 (0%)
Accelerated pkts/Total pkts : 96180156/7276233558 (1%)
LightSpeed pkts/Total pkts : 0/7276233558 (0%)
F2Fed pkts/Total pkts : 7180053402/7276233558 (98%)
F2V pkts/Total pkts : 3707650/7276233558 (0%)
CPASXL pkts/Total pkts : 188774/7276233558 (0%)
PSLXL pkts/Total pkts : 87362563/7276233558 (1%)
CPAS pipeline pkts/Total pkts : 0/7276233558 (0%)
PSL pipeline pkts/Total pkts : 0/7276233558 (0%)
QOS inbound pkts/Total pkts : 0/7276233558 (0%)
QOS outbound pkts/Total pkts : 0/7276233558 (0%)
Corrected pkts/Total pkts : 0/7276233558 (0%)

[Expert@:0]# fwaccel stats -p
F2F packets:
--------------
Violation Packets Violation Packets
-------------------- --------------- -------------------- ---------------
Pkt has IP options 12 ICMP miss conn 1625812
TCP-SYN miss conn 4770065 TCP-other miss conn 24372326
UDP miss conn 3562308642 Other miss conn 242
VPN returned F2F 1106 Uni-directional viol 0
Possible spoof viol 0 TCP state viol 109
SCTP state affecting 0 Out if not def/accl 0
Bridge src=dst 0 Routing decision err 0
Sanity checks failed 0 Fwd to non-pivot 0
Broadcast/multicast 0 Cluster message 25468811
Cluster forward 9483581 Chain forwarding 0
F2V conn match pkts 4707 General reason 0
Route changes 0 VPN multicast traffic 0
GTP non-accelerated 0 Unresolved nexthop 29

[Expert@:0]# fwaccel stats
Name Value Name Value
---------------------------- ------------------- ---------------------------- -------------------

LightSpeed Accelerated Path
--------------------------------------------------------------------------------------------------------
hw accel inbound bytes 0 hw accel packets 0
hw accel outbound bytes 0 hw accel conns 0
hw accel total conns 0 hw accel tcp conns 0
hw accel non-tcp conns 0

Accelerated Path
--------------------------------------------------------------------------------------------------------
accel packets 96203817 accel bytes 65663576815
outbound packets 96203313 outbound bytes 65787905840
conns created 3423544 conns deleted 3422909
C total conns 635 C TCP conns 486
C non TCP conns 149 nat conns 2671316
dropped packets 7704 dropped bytes 775666
fragments received 592 fragments transmit 0
fragments dropped 0 fragments expired 592
IP options dropped 0 corrs created 0
corrs deleted 0 C corrections 0
corrected packets 0 corrected bytes 0

Accelerated VPN Path
--------------------------------------------------------------------------------------------------------
C crypt conns 2 enc bytes 780268880
dec bytes 50958400 ESP enc pkts 1050432
ESP enc err 136 ESP dec pkts 554343
ESP dec err 0 ESP other err 1
espudp enc pkts 0 espudp enc err 0
espudp dec pkts 0 espudp dec err 0
espudp other err 0

Medium Streaming Path
--------------------------------------------------------------------------------------------------------
CPASXL packets 188774 PSLXL packets 87384461
CPASXL async packets 188774 PSLXL async packets 78909801
CPASXL bytes 179631938 PSLXL bytes 61559666392
C CPASXL conns 0 C PSLXL conns 613
CPASXL conns created 450 PSLXL conns created 3416719
PXL FF conns 0 PXL FF packets 8473823
PXL FF bytes 6982538553 PXL FF acks 3525076
PXL no conn drops 0

Pipeline Streaming Path
--------------------------------------------------------------------------------------------------------
PSL Pipeline packets 0 PSL Pipeline bytes 0
CPAS Pipeline packets 0 CPAS Pipeline bytes 0

QoS Paths
--------------------------------------------------------------------------------------------------------
QoS General Information:
------------------------
Total QoS Conns 0 QoS Classify Conns 0
QoS Classify flow 0 Reclassify QoS policy 0

FireWall QoS Path:
------------------
Enqueued IN packets 0 Enqueued OUT packets 0
Dequeued IN packets 0 Dequeued OUT packets 0
Enqueued IN bytes 0 Enqueued OUT bytes 0
Dequeued IN bytes 0 Dequeued OUT bytes 0

Accelerated QoS Path:
---------------------
Enqueued IN packets 0 Enqueued OUT packets 0
Dequeued IN packets 0 Dequeued OUT packets 0
Enqueued IN bytes 0 Enqueued OUT bytes 0
Dequeued IN bytes 0 Dequeued OUT bytes 0

Firewall Path
--------------------------------------------------------------------------------------------------------
F2F packets 7182789713 F2F bytes 1378432955760
TCP violations 109 F2V conn match pkts 4707
F2V packets 3709013 F2V bytes 239565290

GTP
--------------------------------------------------------------------------------------------------------
gtp tunnels created 0 gtp tunnels 0
gtp accel pkts 0 gtp f2f pkts 0
gtp spoofed pkts 0 gtp in gtp pkts 0
gtp signaling pkts 0 gtp tcpopt pkts 0
gtp apn err pkts 0

General
--------------------------------------------------------------------------------------------------------
memory used 40405632 C tcp handshake conns 243
C tcp established conns 218 C tcp closed conns 25
C tcp pxl handshake conns 243 C tcp pxl established conns 203
C tcp pxl closed conns 25 DNS DoR stats 21

(*) Statistics marked with C refer to current value, others refer to total value

As a temporary workaround, we have disabled all threat-prevention blades. These gateways aren't crazy powerful. I guess it makes sense for it to start showing performance issues when barely any traffic is getting accelerated. And I suppose the problems related PrioQ is most likely a result of other things, not a trigger for the latency issues.

The question is why so much traffic is hitting F2F. I have examined the firewall policy, which consists of 116 rules. The first rule containing applications is rule 107, an in-line layer for outbound traffic for a specific subnet. All rules having applications are within in-line layers towards the bottom of the policy package. I have a really hard time understanding why so little of the traffic is being accelerated.

Does anyone else have any experience with this? Any pointers to what I should look for to figure out and solve this behaviour?

Re: High latency on CPAP-SG3600 HA-cluster running Gaia R81.20. HCP complains about 99.26% F2F traff

Chris_Atkinson — Fri, 24 Mar 2023 15:02:33 GMT

Do any of the following apply to your configuration / policy as these all impact SecureXL?

PPPoE interfaces aren't supported by SecureXL

Rules with RPC / DCOM / DCE-RPC services.

Rules with Client Authentication or Session Authentication.

When IPS protection "SYN Attack" ("SYNDefender") is activated in SmartDefense / IPS.

When IPS protection "Small PMTU" is activated in IPS.

When IPS protection "Network Quota" is activated in IPS (refer to sk31630).

When IPS protection "Malicious IPs" (DShield.org Storm Center) is activated in IPS (because it uses Dynamic Objects).

Refer also: sk32578

Re: High latency on CPAP-SG3600 HA-cluster running Gaia R81.20. HCP complains about 99.26% F2F traff

RamGuy239 — Fri, 24 Mar 2023 15:02:43 GMT

None of this should be relevant. The four IPS-related things might apply when running Threat Prevention as we run Autonomous Threat Prevention using the "Perimeter" profile. Not sure how we would verify that as we have so little control when using Autonomous Threat Prevention. But this statistic is with only the following blades currently enabled:

[Expert@:0]# enabled_blades
fw vpn urlf appi

There is no PPPoE. Rules disabling acceleration would be showing from the "fwaccel stat" command. Currently, we are using none of those.

Re: High latency on CPAP-SG3600 HA-cluster running Gaia R81.20. HCP complains about 99.26% F2F traff

the_rock — Fri, 24 Mar 2023 15:12:22 GMT

Hey @RamGuy239

I think it would help us big time if you could generate below:

https://community.checkpoint.com/t5/Scripts/S7PAC-Super-Seven-Performance-Assessment-Commands/td-p/40528

and

https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk171436

Btw, hcp is so easy now in R81.20, as you can access it once done via https://x.x.x.x:portnumber/hcp link

Cheers mate.

Andy

Re: High latency on CPAP-SG3600 HA-cluster running Gaia R81.20. HCP complains about 99.26% F2F traff

Chris_Atkinson — Fri, 24 Mar 2023 15:22:45 GMT

Any SQLNET2 traffic per sk179919 ?

Re: High latency on CPAP-SG3600 HA-cluster running Gaia R81.20. HCP complains about 99.26% F2F traff

the_rock — Fri, 24 Mar 2023 15:37:03 GMT

@Chris_Atkinson made a good point in his last response. In the old days of CP, R77 and before, TAC would always suggest to customers to use service with protocol "NONE", not default one, so there is no IPS inspection taking place. Is it ideal, I would say no, BUT, if it works, at least its good workaround. Though, you need to confirm 100% what service might be a "culprit"

To clarify my point, this is ONLY advisable if you know what service is causing the problem, no need to fiddle with it otherwise.

Do you have TAC case open for this or not yet?

Andy

Re: High latency on CPAP-SG3600 HA-cluster running Gaia R81.20. HCP complains about 99.26% F2F traff

RamGuy239 — Fri, 24 Mar 2023 19:44:19 GMT

Hmm, sk179919 has me somewhat confused. When I try the command "fw tab t connections -z" I'm just getting this:

[Expert@:0]# fw tab t connections -z
-z option must be used with connections table

I don't expect this to be relevant. Shouldn't be a lot of SQL traffic in this environment at all.

Re: High latency on CPAP-SG3600 HA-cluster running Gaia R81.20. HCP complains about 99.26% F2F traff

RamGuy239 — Fri, 24 Mar 2023 19:51:13 GMT

HCP is great, HCP was the test that pointed my towards the F2F issue to begin with.

I have never heard about S7PAC, looks liks a nice tool:

Accept Templates : enabled
Drop Templates : enabled
NAT Templates : enabled
LightSpeed Accel : disabled

+-----------------------------------------------------------------------------+
| Command #2: fwaccel stats -s |
| |
| Check for : Accelerated conns/Totals conns: >25% good, >50% great |
| Accelerated pkts/Total pkts : >50% great |
| PXL pkts/Total pkts : >50% OK |
| F2Fed pkts/Total pkts : <30% good, <10% great |
| |
| Chapter 9: SecureXL throughput acceleration |
| Page 287, Packet/Throughput Acceleration: The Three Kernel Paths |
+-----------------------------------------------------------------------------+
| Output: |
Accelerated conns/Total conns : 21/643 (3%)
LightSpeed conns/Total conns : 0/643 (0%)
Accelerated pkts/Total pkts : 114950023/8029316457 (1%)
LightSpeed pkts/Total pkts : 0/8029316457 (0%)
F2Fed pkts/Total pkts : 7914366434/8029316457 (98%)
F2V pkts/Total pkts : 4081912/8029316457 (0%)
CPASXL pkts/Total pkts : 188774/8029316457 (0%)
PSLXL pkts/Total pkts : 95956257/8029316457 (1%)
CPAS pipeline pkts/Total pkts : 0/8029316457 (0%)
PSL pipeline pkts/Total pkts : 0/8029316457 (0%)
QOS inbound pkts/Total pkts : 0/8029316457 (0%)
QOS outbound pkts/Total pkts : 0/8029316457 (0%)
Corrected pkts/Total pkts : 0/8029316457 (0%)

+-----------------------------------------------------------------------------+
| Command #3: grep -c ^processor /proc/cpuinfo && /sbin/cpuinfo |
| |
| Check for : If number of cores is roughly double what you are excpecting, |
| hyperthreading may be enabled |
| |
| Chapter 7: CoreXL Tuning |
| Page 239 |
+-----------------------------------------------------------------------------+
| Output: |
4
HyperThreading=disabled

+-----------------------------------------------------------------------------+
| Command #4: fw ctl affinity -l -r |
| |
| Check for : SND/IRQ/Dispatcher Cores, # of CPU's allocated to interface(s) |
| Firewall Workers/INSPECT Cores, # of CPU's allocated to fw_x |
| R77.30: Support processes executed on ALL CPU's |
| R80.xx: Support processes only executed on Firewall Worker Cores|
| |
| Chapter 7: CoreXL Tuning |
| Page 221 |
+-----------------------------------------------------------------------------+
| Output: |
CPU 0:
CPU 1: fw_2 (active)
cprid lpd mpdaemon fwd core_uploader wsdnsd fwucd rad in.acapd in.asessiond topod vpnd scrub_cp_file_convertd watermark_cp_file_convertd cprid cpd
CPU 2: fw_1 (active)
cprid lpd mpdaemon fwd core_uploader wsdnsd fwucd rad in.acapd in.asessiond topod vpnd scrub_cp_file_convertd watermark_cp_file_convertd cprid cpd
CPU 3: fw_0 (active)
cprid lpd mpdaemon fwd core_uploader wsdnsd fwucd rad in.acapd in.asessiond topod vpnd scrub_cp_file_convertd watermark_cp_file_convertd cprid cpd
All:
Interface eth5: has multi queue enabled
Interface Mgmt: has multi queue enabled
Interface eth1: has multi queue enabled
Interface eth2: has multi queue enabled
Interface eth3: has multi queue enabled
Interface eth4: has multi queue enabled

+-----------------------------------------------------------------------------+
| Command #5: netstat -ni |
| |
| Check for : RX/TX errors |
| RX-DRP % should be <0.1% calculated by (RX-DRP/RX-OK)*100 |
| TX-ERR might indicate Fast Ethernet/100Mbps Duplex Mismatch |
| |
| Chapter 2: Layers 1&2 Performance Optimization |
| Page 28-35 |
| |
| Chapter 7: CoreXL Tuning |
| Page 204 |
| Page 206 (Network Buffering Misses) |
+-----------------------------------------------------------------------------+
| Output: |
Kernel Interface table
Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg
Mgmt 1500 0 0 0 0 0 0 0 0 0 BMU
bond0 1500 0 111712603 0 0 0 109914171 0 0 0 BMmRU
bond0.100 1500 0 21204368 0 0 0 18533468 0 0 0 BMRU
bond0.200 1500 0 89 0 0 0 5219 0 0 0 BMRU
bond0.208 1500 0 2341439 0 0 0 3421902 0 0 0 BMRU
bond0.224 1500 0 1855780 0 0 0 1972088 0 0 0 BMRU
bond0.302 1500 0 56764963 0 0 0 78537570 0 0 0 BMRU
bond0.304 1500 0 269 0 0 0 11378 0 0 0 BMRU
bond0.305 1500 0 599 0 0 0 43714 0 0 0 BMRU
bond0.306 1500 0 1038214 0 0 0 1283056 0 0 0 BMRU
bond0.666 1500 0 28071813 0 0 0 6091292 0 0 0 BMRU
bond1 1500 0 87779393 0 0 1756 94961630 0 0 0 BMmRU
eth1 1500 0 3939682497 0 0 0 3932095607 0 0 0 BMRU
eth2 1500 0 95412972 0 0 0 56903145 0 0 0 BMsRU
eth3 1500 0 16266273 0 0 0 53004939 0 0 0 BMsRU
eth4 1500 0 51309094 0 0 0 55634926 0 0 0 BMsRU
eth5 1500 0 36414301 0 0 1756 39274963 0 0 0 BMsRU
lo 65536 0 2094776 0 0 0 2094776 0 0 0 LNRU

interface eth1: There were no RX drops in the past 0.5 seconds
interface eth1 rx_missed_errors : 0
interface eth1 rx_fifo_errors : 0
interface eth1 rx_no_buffer_count: 0

interface eth2: There were no RX drops in the past 0.5 seconds
interface eth2 rx_missed_errors : 0
interface eth2 rx_fifo_errors : 0
interface eth2 rx_no_buffer_count: 0

interface eth3: There were no RX drops in the past 0.5 seconds
interface eth3 rx_missed_errors : 0
interface eth3 rx_fifo_errors : 0
interface eth3 rx_no_buffer_count: 0

interface eth4: There were no RX drops in the past 0.5 seconds
interface eth4 rx_missed_errors : 0
interface eth4 rx_fifo_errors : 0
interface eth4 rx_no_buffer_count: 0

interface eth5: There were no RX drops in the past 0.5 seconds
interface eth5 rx_missed_errors : 0
interface eth5 rx_fifo_errors : 1756
interface eth5 rx_no_buffer_count: 0

+-----------------------------------------------------------------------------+
| Command #6: fw ctl multik stat |
| |
| Check for : Large # of conns on Worker 0 - IPSec VPN/VoIP? |
| Large imbalance of connections on a single or multiple Workers |
| |
| Chapter 7: CoreXL Tuning |
| Page 241 |
| |
| Chapter 8: CoreXL VPN Optimization |
| Page 256 |
+-----------------------------------------------------------------------------+
| Output: |
ID | Active | CPU | Connections | Peak
----------------------------------------------
0 | Yes | 3 | 352 | 3492
1 | Yes | 2 | 367 | 1346
2 | Yes | 1 | 389 | 1288

Processors load
---------------------------------------------------------------------------------
|CPU#|User Time(%)|System Time(%)|Idle Time(%)|Usage(%)|Run queue|Interrupts/sec|
---------------------------------------------------------------------------------
| 1| 0| 22| 78| 22| ?| 36976|
| 2| 40| 45| 15| 85| ?| 36977|
| 3| 40| 44| 16| 84| ?| 36977|
| 4| 35| 49| 15| 85| ?| 36977|
---------------------------------------------------------------------------------

Processors load
---------------------------------------------------------------------------------
|CPU#|User Time(%)|System Time(%)|Idle Time(%)|Usage(%)|Run queue|Interrupts/sec|
---------------------------------------------------------------------------------
| 1| 0| 21| 79| 21| ?| 68428|
| 2| 37| 38| 26| 74| ?| 34211|
| 3| 37| 35| 28| 72| ?| 68420|
| 4| 31| 39| 30| 70| ?| 68424|
---------------------------------------------------------------------------------

Processors load
---------------------------------------------------------------------------------
|CPU#|User Time(%)|System Time(%)|Idle Time(%)|Usage(%)|Run queue|Interrupts/sec|
---------------------------------------------------------------------------------
| 1| 0| 23| 77| 23| ?| 72900|
| 2| 39| 41| 20| 80| ?| 36454|
| 3| 39| 38| 22| 78| ?| 72921|
| 4| 37| 42| 22| 78| ?| 36459|
---------------------------------------------------------------------------------

+-----------------------------------------------------------------------------+
| Thanks for using s7pac |
+-----------------------------------------------------------------------------+

HCP as already been utilized as i mentioned in my original post. It was HCP that was pointing me to there being a terrible SecureXL utilization.

Re: High latency on CPAP-SG3600 HA-cluster running Gaia R81.20. HCP complains about 99.26% F2F traff

the_rock — Fri, 24 Mar 2023 19:53:14 GMT

Will review it in a bit.

Andy

Re: High latency on CPAP-SG3600 HA-cluster running Gaia R81.20. HCP complains about 99.26% F2F traff

RamGuy239 — Fri, 24 Mar 2023 19:56:17 GMT

I have a ticket with TAC going. But it's moving slowly and the latest recommendation was to add traffic to fast acceleration, which seems like a strange thing to bring up in my opinion. Fast accel is a great tool to have specific traffic bypass inspection. But this is a scenario where SecureXL doesn't seem to really engage at all. Looking into fast acceleration seems more like a desperate attempt at tossing enough traffic into the accelerated path in order to have the issue go away. It doesn't really make much sense in terms of figuring out why barely anything is being accelerated in the first place.

Re: High latency on CPAP-SG3600 HA-cluster running Gaia R81.20. HCP complains about 99.26% F2F traff

RamGuy239 — Fri, 24 Mar 2023 19:59:38 GMT

Here is the latest HCP report as well. From the current active member.

Re: High latency on CPAP-SG3600 HA-cluster running Gaia R81.20. HCP complains about 99.26% F2F traff

PhoneBoy — Fri, 24 Mar 2023 20:33:22 GMT

I assume it’s because the command should be fw tab -t connections -z

Re: High latency on CPAP-SG3600 HA-cluster running Gaia R81.20. HCP complains about 99.26% F2F traff

RamGuy239 — Fri, 24 Mar 2023 20:38:45 GMT

Funny how the SK shows the wrong command. When running "fw tab -t connections -z" I get a rather extensive output. Nothing showing anything SQLNET2 though.

Re: High latency on CPAP-SG3600 HA-cluster running Gaia R81.20. HCP complains about 99.26% F2F traff

the_rock — Fri, 24 Mar 2023 22:06:41 GMT

I agree, you got 98% F2F packets, that may explain some of your issues, for sure. Can you run cpview and just tab between fields and look for heavy connections/services. Also, can you run -> fw ctl multik print_heavy_conn

Andy

Re: High latency on CPAP-SG3600 HA-cluster running Gaia R81.20. HCP complains about 99.26% F2F traff

Timothy_Hall — Sat, 25 Mar 2023 22:08:30 GMT

It is unlikely your rulebase configuration is causing the high F2F, output of fwaccel stat says accept templates are fully enabled which have nothing to do with forcing traffic F2F anyway. All disabling priority queueing did was reduce the extra CPU load caused by re-prioritization of traffic when a worker core hits 100% (which is happening often), but the underlying cause of the high CPU load for the workers in the first place is excessive F2F.

This may seem a rather silly question, but are you sure these reports and commands were run on the active cluster member? It is expected behavior to see near 100% F2F on the standby member in ClusterXL HA.

At this point the only way to conclusively determine why so much traffic is going F2F is to run a kernel debug which will show you the reason; I'm a bit surprised TAC hasn't suggested this yet. This topic is covered in my Gateway Performance Optimization class, here are the relevant pages from the class for all current situations I know of that can cause heavy F2F (feedback on any missing ones from anyone reading is always welcome!), as well as the debug procedure itself. One you have the needed debug output in f2f.log run the command:

grep "accelerated, reason" /var/log/f2f.log (note there is a single space between the ","and "reason"):

Re: High latency on CPAP-SG3600 HA-cluster running Gaia R81.20. HCP complains about 99.26% F2F traff

Ilya_Yusupov — Sun, 26 Mar 2023 06:17:08 GMT

hi @RamGuy239,

few questions in order to understand the case better.

1. when you had R81.20 GA was the traffic also goes to F2F?

2. Any chance your GW is configured as a proxy?

3. any chance you are using IPS Redundancy in Load Sharing mode?

Thanks,

Ilya

Re: High latency on CPAP-SG3600 HA-cluster running Gaia R81.20. HCP complains about 99.26% F2F traff

Chris_Atkinson — Sun, 26 Mar 2023 11:52:50 GMT

Indeed good suggestion regarding proxy, refer:

sk92482: Performance impact from enabling HTTP/HTTPS Proxy functionality

(Irrespective of relevance here, have asked for the SecureXL mechanism SK to be updated to reference the above as a factor impacting performance.)

Re: High latency on CPAP-SG3600 HA-cluster running Gaia R81.20. HCP complains about 99.26% F2F traff

RamGuy239 — Mon, 27 Mar 2023 06:26:39 GMT

1. Difficult to say. I don't have any statistics as I did a clean install from USB.

2. No proxy enabled.

3. No ISP Redundancy or Load Sharing.

Re: High latency on CPAP-SG3600 HA-cluster running Gaia R81.20. HCP complains about 99.26% F2F traff

RamGuy239 — Mon, 27 Mar 2023 06:27:10 GMT

There is no proxy functionality enabled.

Re: High latency on CPAP-SG3600 HA-cluster running Gaia R81.20. HCP complains about 99.26% F2F traff

Ilya_Yusupov — Mon, 27 Mar 2023 06:31:25 GMT

@RamGuy239 ,

can you share the support case you opened i would like to review it?

Thanks,

Ilya