VPN inspi_to_instance and why is it increasing when inbound and outbound spi does not?

[JHJohansen]

We're having issued with a Google Cloud VPN tunnel and managed to see an increase in inbound and outbound SPI when it happens.

To counter the problem we've scripted a IPSEC SA reset every day at 03:00. So far we've had no VPN issues after the scripted reset.

But what I noticed is that the number of inSPI_to_instance increases dramatically 30-45 minutes after each reset.
For some reason the inSPI value for today is a fraction of what it has been earlier this week. No idea why.

The values for the graph is collected from the values you get when running:

vsenv X
fw tab -s | grep -i SPI

Can someone shed some light as to what inSPI_to_instance is used for and maybe why this delayed sudden increase after the reset?

Before setting up the automated job I tested the script manually during work hours and did not encounter the same increase.

The only thing the script does is to log on to the node running the VPN gateway, change VS environment and delete IPSEC SA for the specified Google Cloud gateway (x.x.x.x)

vsenv X
vpn tu del ipsec x.x.x.x

[Timothy_Hall]

SPI is just a unique identifier for a specific IKE or IPSec tunnel.  I would assume the inSPI_to_instance table is maintaining a mapping of which Firewall Worker/Instance each tunnel will be handled on, which is part of MultiCore VPN: sk118097: MultiCore Support for IPsec VPN

Not sure exactly why you are concerned about an increase in SPIs as they may not be related to your stability problems.  However if you are using IKEv2 I suppose the sudden increase in SPIs could be related to tunnel narrowing which absolutely, most definitely has caused all kinds of nasty problems: sk166417: IKEv2 Site to Site VPN instability when tunnel is narrowed

Beyond that you need to figure out who is initiating the spike in SPIs, my guess is the google side unless some of your lifetime timers are shorter that 60 minutes which is unlikely.