MX Virtual IPs and a too-small IP block

Solved
SpfZero
Here to help

MX Virtual IPs and a too-small IP block

I'm trying to set up virtual IPs on an HA pair of MX250s. The problem is, while I have enough external IPs to assign IPs to each MX and one for the virtual, I don't have enough in the same block. Perhaps exposing some fundamental lacking knowledge here, but is there a reason I can't have the IP address and Gateway of one of the pair in a different IP block from the other MX and the virtual IP?

 

For example:

Virtual IP 204.x.x.4


MX1 IP 204.x.x.2
Gateway 204.x.x.1

 

MX2 IP 209.x.x.30

Gateway 209.x.x.29

 

Additional notes: the virtual IP I'm trying to use was the assigned IP of MX1 before the move to a virtual IP. We have a lot of external vendor whitelisting going on and it would be a large undertaking. MX2 has always had this assigned IP, but failovers between the 2 were causing issues because of the IP changing.

1 Accepted Solution
SpfZero
Here to help

Stopping back by to update, 

Got it deployed and configured as mentioned above with the MX-2 IP in a different subnet from MX-1 and the vIP. And it's working. Ran through a solid set of failover tests last night and didn't hit any issues with connectivity.

View solution in original post

9 Replies 9
alemabrahao
Kind of a big deal
Kind of a big deal

It's actually quite logical, for example if your WAN 1 is defined for the 200.19.4.0/29 network, the IP of each interface + Virtual IP and Gateway IP must belong to the same network, as both MXs will share the IP virtual, so there is no logic in them being configured with an IP prefix in another address range.

I am not a Cisco Meraki employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.

Please, if this post was useful, leave your kudos and mark it as solved.
cmr
Kind of a big deal
Kind of a big deal

@SpfZero when you set the shared IP it has to be in the device's WAN subnet.  There is no option to do anything else.

If my answer solves your problem please click Accept as Solution so others can benefit from it.
SpfZero
Here to help

So what have I done wrong and why is it working right now? I don't have the second device online right now (it would be a 208.x.x.141), but this is the current (and functional) config.

config.png

 At this point, it's academic for me. I have found a free address so I can configure this one correctly. But I would like to understand why this is working as it will help me understand how much IP shuffling and vendor change requests I'll have on a couple future projects.

cmr
Kind of a big deal
Kind of a big deal

Here is an example of the config page with some test private addressing, as you can see, you cannot choose the subnet, only select the vIP

1000007442.jpg

If my answer solves your problem please click Accept as Solution so others can benefit from it.
SpfZero
Here to help

Oh sure! I guess to put my root question another way, is there any downside to what I have in my screenshot up there where the vIP is in a different WAN subnet than the device WAN subnet?

Ryan_Miles
Meraki Employee
Meraki Employee

If your VIP is in another subnet from the interface's real subnet it has no reachable next hop/gateway IP. If you try ping from the tools tab you'd see successes with the "Internet" interface and fails with the "Internet Virtual" interface.

 

Unless perhaps the gateway is a device that supports sub interfaces? I have no way to test that here.

Ryan

If you found this post helpful, please give it Kudos. If my answer solves your problem please click Accept as Solution so others can benefit from it.
SpfZero
Here to help

That is not the case for me. Both interfaces ping fine out to 8.8.8.8. Is it possible that it's working due to something on my ISP's side, with how they've configured their stuff in providing me the additional block of external IP addresses?

Ryan_Miles
Meraki Employee
Meraki Employee

Gotcha. So yeah if they allow multiple routed interfaces then perhaps this would work fine. You'd have to add the spare MX and fully test it out.

 

And you could of course validate things with a couple of pcaps of the MX WAN interfaces.

 

If you end up deploying this and it works fine please update the thread.

Ryan

If you found this post helpful, please give it Kudos. If my answer solves your problem please click Accept as Solution so others can benefit from it.
SpfZero
Here to help

Stopping back by to update, 

Got it deployed and configured as mentioned above with the MX-2 IP in a different subnet from MX-1 and the vIP. And it's working. Ran through a solid set of failover tests last night and didn't hit any issues with connectivity.

Get notified when there are additional replies to this discussion.