Has anyone else experienced this?
Example MX is set to VLANs and has one or more VLANs defined. (May also happen with Single LANs I just don't ever set them up that way)
Static Routes exist pointing other subnets across that VLAN to another layer 3 device.
I make sure all dependencies for the statically routed subnets are gone/disabled (DHCP, firewall rules, etc)
I try to change the VLAN on the MX and the static routes at the same time.
MX gives error saying the static route has an invalid next hop and lists the old next hop IP.
This used to work, but I've seen the error multiple times over the past few months. It seems the order of operations or validation criteria on the backend have changed.
I intend to open a case but was just wondering if anyone else has noticed. It's just a few extra steps but deleting also loses the DHCP info that I would usually just edit instead of having to recreate.
And before anyone asks Templates are not an option for us.
It's not possible. The static route is directly related to the VLAN Interface.
In other words, it is the expected behavior.
An update, I have tried here and it worked. What version are you running?
The MXs aren't live yet but the network is currently set to 18.107.2. I pushed them to 18.210 with same result.
Can you show what exactly are you trying modify?
I changed VLAN 500 to a new subnet and then modified the next hop for the static routes.
I used to be able to do this.
Really just seems like some sort of logic is missing from the operations the page is doing and either it was there before or some sort of constraint was added.
The error message says : 10.15.12.254 but your static route points to 10.16.12.254. Am I missing something ?
10.16.12.254 is the next hop.
Ok, this is strange, I believe he is trying to change the interface IP for that network and at the same time change the Route, I believe this should not work.
Yes this is exactly what I am trying to do. It used to work. It's certainly possible with the proper logic on the backend but it definitely doesn't work now.
The MXs aren't live yet
This is probably the key part. THIS is one of the millions check the dashboard is doing that prevents true ZTP. You can't configure syslog ( dhcp relay and probably many other ) either if there is no reachability , same goes for your static route that you are trying to provision.
I am always doing this when staging things, but I'm not sure if I've ever tried since the behavior changed when things were live. 🤔
I did a test and currently my MX has been offline for a little over a month and it worked, so I think the problem is something else.