MX warm spare loss of configuration

[MartinSeitz]

Hey anybody. 

General Description: 

I have a customer having issues with Auto VPN due to the fact that the MX changed the UPlink IP address.

Detailed Description:

In the scenario we have a MX working as a VPN concentrator behind a 3rd party vendor FW (FW-A). 

The MX has two Uplinks to FW-A onto WAN1 (10.10.1.2) and WAN2 (20.20.1.1). 

On FW-A there is a NAT rule for the IP of WAN1 to be transformed into a specific public IP Address.

For WAN2 there is no specific NAT rule. 

In the past I think it is almost one year in the past it was planned to set up the MX as a warm spare cluster. And for a short period of time there was a 2nd MX. Therefor a warm spare was configured and a virtual IP (10.10.1.1) was set. So the NAT rule on FW-A was changed to reflect this setting. SNAT 10.10.1.1 to public IP.

Once the 2nd MX was put of the cluster, nobody reversed thechange and the MX continued to work with its virtual IP. Now after a longer period of time it changed his interpretation of the Cluster Situation and uses his WAN1 IP address for uplink communication. This causes the NAt rule not to match and results in a failure for the VPN. 

To solve the VPN issue we have changed the NAT rule, works. 

❓ Question: 

But I like to know,

- why was the change of the "warm spare cluster situation" now? (The MX was able to hold its virtual IP live for such a long time without seeing the spare partner for months)

- Is there a known Timer behind it?

- Is there any kind of notification that should appear?

- does anybody know if this is recognizable in any kind of logging?

[cmr]

Was the warm spare device removed from the inventory, or assigned elsewhere?

Was a firmware upgrade applied?

Was the remaining primary MX rebooted?

[MartinSeitz]

hello cmr, 

thanks for your counter questions. I have check in the data what I was able to do. 

- No firmware update to that time. 

- No reboot of the MX to this time. 

- and the change log also shows no relevant changes. 

But you question about inventory bringt me to an idea. 

The Spare mashine that was installed in the passt was borrowed from Meraki it self and of cause was sent back to them. So even when the customer did not remove the serialnumber from inventory. In the moment when the serialnumber is added to another organization the serialnumber must disappear from inventory.

That would also match to the event-time which was 3:30 am in Germany which could be day light elswer in the world. 

The question remains whether removing the serial number of the spare machine from the inventory leads to the observed behaviour. This means that the WAN1 address is used for VPN communication instead of the configured VIP address.

[PhilipDAth]

There has been no change in behaviour in this area.

If you have a VIP configured it will use it for all inbound and outbound VPN communications.  The WAN1/WAN2 IP address will still be used for talking to the Meraki cloud, but this is seperate and has nothing to do with the operation of AutoVPN.