Core XL cpu type

[Atle]

Hi.

I have some issues with vpn instability in p2 re-key, between a cluster and a gateway in Azure. Cluster and azure gateway are both running R81.20

If I disable CoreXL on the Azure gateway, the site to site tunnel is stable.

In cpview, under cpu -> overview I see the workers, but the SND isn't listed, instead I just see the cpu as "other", just as described in sk181241. However setting the affinity and rebooting does not resolve this issue. I was expecting to see "CoreXL_SND" for one of the cpu's

Any ideas on why the SND isn't being assigned?

[AkosBakos]

Hi @Atle 

You use R81.20, but you didn't mention the JHF take number.

Now take 76 is recommended, first install it before the further investigation.

Dou you use IKEv1 or IKEv2? 

Did you try to change something on both side? Eg.: DH group or something else?

Akos

[Atle]

Hi. It's pretty recent, and I have not seen anything in the documentation that suggest hfa 76 would resolve this. I had the same issue on R81.10, and therefore upgraded to R81.20  I get the same results if I use ikev1 or Ikev2, different Dh versions, etc. In my experience ipsec between to Check Point gateways just works, regardless of version. Disabling core xl resolves it, so I believe it is related to that.

Atle

[Chris_Atkinson]

What did / do you see with "show dynamic-balancing state" on the Azure GW?

[Atle]

I thought it could be related to dynamic balancing too, but it isn't supported on virtual gateways. So I just get the"Dynamic Balancing is currently Off" message.

[Chris_Atkinson]

Which JHF take is installed on this Gateway?

JHF70 and above adds multi-queue support for Microsoft Azure Network Adapter accelerated network interfaces further to Amit's comments. 

[Atle]

Hi.

I have installed hfa 76 now.

[Lesley]

Is this VSX? Please share: fw ctl affinity -l -v -a

[Atle]

No, it is a single gateway running in Azure.

[Lesley]

As long as the SND and the fwkern are not shared by the same CPU you are good. Then you can get performance issues. 

If it shows other and the other config shows it is good, it is a cosmetic issue. I had the same on a VSX setup. 

[AmitShmuel]

Are you using Multi-Queue? Pls share 'mq_mng -o' output, it could be that CPView does not recognize the interfaces (as this is an Azure GW)

If not, pls share 'sim affinity -l' output, we would want to see that each interface is affined to a single CPU.

[Atle]

Yes, mq is in use:

[AmitShmuel]

Pls run "cat /proc/interrupts | grep eth0"
I would like to see what is the name of the irq, and if the code handles it correctly.

Alternatively, we can debug cpview and look for any related errors/warnings:

1. Stop cpview daemon using cp watchdog
   1. cpwd_admin stop -name CPVIEWD
2. Run cpview daemon with debugs and output them to cpview.dbg file
   1. TDERROR_ALL_ALL=5 cpviewd > cpview.dbg 2>&1
3. Check for any errors related to interface parsing in the file (e.g. "no interrupt for interface eth0")
4. Start cpview daemon using cp watchdog
   1. cpwd_admin start -name CPVIEWD -path $CPDIR/bin/cpviewd -command cpviewd

[Atle]

I resized the azure vm to a 4 core VM. After that, SND and workers appear correct. However, the vpn issue remains.

[Wolfgang]

@Atle  do you have a license for 8 cores ?

How are you disableddisable CoreXL ?

[Atle]

Hi.

It's licensed for 7 cores. I have configured Core XL for 6+1

I disabled Core XL in cpconfig.

[Wolfgang]

In the past we could observe some strange problems if the licensed cores does not match the existing. Your Azure gateway shows 8 cores, you need a license for 8 cores. Maybe you can try to set the core count of your gateway to the same or less then the license includes.

[Atle]

I resized it down to 4 cores now, but the vpn issue still persists.

But at least cpview shows the SND and workers correct now. 🙂