MX400 as a gateway

Solved
hkholghi
Comes here often

MX400 as a gateway

Hello all,

 

Our current network consists of a couple of VLANs.  The default Vlan #1 is the management Vlan and all these Vlans inter-route except for one.  It is a basic routing (not an OSPF).  The DHCP server runs on Windows 2019 and provides IP addresses for all these VLANs.  Our main core switch is an HP Procurve 5406 that does the basic routing and also it is the gateway, with an IP address of 192.168.2.1.  We’re in the process of retiring this switch and replacing it with a Meraki switch (MS425-32).  The Hp Procurve 5406  also has over 14 fiber module connections that connect various parts of our campus.

 

We also have an MX400 with two connections to the Internet.  As part of the migration, I created the VLANs on the MX400 and connected the MX400 LAN #2 (trunk) to a trunk port on the MS425-32.  There is also a trunk port that connects MS425-32 to the HP Procurve 5406.  Everything is working fine so far.   The next step is assigning the IP address 192.168.2.1 to a new gateway.  I tried to assign this IP address to the MS425-32 switch (I had already changed the HP Procurve switch address), but Meraki did not let me use the same IP address for the gateway address.  I did all these on the Meraki dashboard.  So, I had to assign the 192.168.2.1 back to the HP Procurve switch and select the DHCP option for the MS425-32 switch.  The network is back online.

 

Is it possible to use the MX400 as my new gateway with the IP address of 192.168.2.1?  If so, how do I go about changing it?  We added MX400 to our network about 2 years ago and then I assigned the IP address of 192.168.2.2.  Since LAN #1 of MX400 is no longer alive, I do not see the LAN IP address.  I can launch a browser and enter the IP address 192.168.2.2 and see WAN configurations and connections, but no LAN address.

 

Thanks for all your help.

1 Accepted Solution
Bruce
Kind of a big deal

Hi @hkholghi, it’s difficult to know what the issue is without knowing the error message or understanding the network. I’m assuming that currently you have a single VLAN configured on the MX that acts as a transit VLAN to the Procurve, and then all other VLANs and their Layer 3 interfaces exist on the Procurve. If this is about right, then I’d do the following:

 

  1. First create a new Meraki management VLAN (and subnet) on the MX and add this to the trunk to the Procurve. Add this VLAN on the Procurve, but don’t give it a Layer 3 interface on the Procurve. I know you have a current management VLAN, but I’d set up a new one for Meraki, it’ll be easier, especially if you’re planning to add more Meraki devices over time. At this point you should only have two VLANs on the MX, the original transit VLAN and the new Management VLAN.
  2. Create a trunk between the Procurve and the MS425 that carries all VLANs and make the new Meraki management VLAN the native VLAN. Having the Meraki management VLAN as the native will just make things easier from the respect of bringing new devices online. You can either statically configure the management IP address via the MS425 local status page, or setup a DHCP server on the MX for that VLAN.
  3. Hopefully now the MS425 is online and registered with the Dashboard. Now you should be able to move your access switches over to the MS425 with the Layer 3 routing still occurring on the Procurve. Or you can do the next step first, then come back to moving the access switches over.
  4. Now move the Layer 3 interfaces from the Procurve to the MS425. Remove the Layer 3 interfaces from the Procurve and recreate them on the MS425. For the existing management interface on the Procurve (which you should do last) you can just change the IP address, rather than remove it, so you can maintain manageability of the Procurve, whilst still migrating the Layer 3 interface to the MS425 with the same IP address (this assumes the management IP address and Layer 3 interface are one of the same). Now the Procurve is really just acting as a piece wire between the MX and the MS425, and swapping native VLANs between ports.
  5. Remove the Procurve from the network. To do this configure a MX port as a trunk with the new Meraki management VLAN as the native VLAN. This port should only need to carry the Meraki management VLAN and the transit VLAN. Now take the link that is currently between the Procurve and the MS425 and move it to connect the newly configured MX port to the MS425 directly. Once you’re happy it’s all working you can disconnect the Procurve.

This is an overview of how I’d tackle it. I’m sure there are some minor points I’ve missed in the description but hopefully it gives you a basis to work from. You should essentially end up with all the Layer 3 interfaces on the MS425, with the exception of the Meraki management VLAN, which has its Layer 3 interface on the MX, and the transit VLAN that has interfaces on both the MX and the MS425.

 

Hope this helps.

View solution in original post

1 Reply 1
Bruce
Kind of a big deal

Hi @hkholghi, it’s difficult to know what the issue is without knowing the error message or understanding the network. I’m assuming that currently you have a single VLAN configured on the MX that acts as a transit VLAN to the Procurve, and then all other VLANs and their Layer 3 interfaces exist on the Procurve. If this is about right, then I’d do the following:

 

  1. First create a new Meraki management VLAN (and subnet) on the MX and add this to the trunk to the Procurve. Add this VLAN on the Procurve, but don’t give it a Layer 3 interface on the Procurve. I know you have a current management VLAN, but I’d set up a new one for Meraki, it’ll be easier, especially if you’re planning to add more Meraki devices over time. At this point you should only have two VLANs on the MX, the original transit VLAN and the new Management VLAN.
  2. Create a trunk between the Procurve and the MS425 that carries all VLANs and make the new Meraki management VLAN the native VLAN. Having the Meraki management VLAN as the native will just make things easier from the respect of bringing new devices online. You can either statically configure the management IP address via the MS425 local status page, or setup a DHCP server on the MX for that VLAN.
  3. Hopefully now the MS425 is online and registered with the Dashboard. Now you should be able to move your access switches over to the MS425 with the Layer 3 routing still occurring on the Procurve. Or you can do the next step first, then come back to moving the access switches over.
  4. Now move the Layer 3 interfaces from the Procurve to the MS425. Remove the Layer 3 interfaces from the Procurve and recreate them on the MS425. For the existing management interface on the Procurve (which you should do last) you can just change the IP address, rather than remove it, so you can maintain manageability of the Procurve, whilst still migrating the Layer 3 interface to the MS425 with the same IP address (this assumes the management IP address and Layer 3 interface are one of the same). Now the Procurve is really just acting as a piece wire between the MX and the MS425, and swapping native VLANs between ports.
  5. Remove the Procurve from the network. To do this configure a MX port as a trunk with the new Meraki management VLAN as the native VLAN. This port should only need to carry the Meraki management VLAN and the transit VLAN. Now take the link that is currently between the Procurve and the MS425 and move it to connect the newly configured MX port to the MS425 directly. Once you’re happy it’s all working you can disconnect the Procurve.

This is an overview of how I’d tackle it. I’m sure there are some minor points I’ve missed in the description but hopefully it gives you a basis to work from. You should essentially end up with all the Layer 3 interfaces on the MS425, with the exception of the Meraki management VLAN, which has its Layer 3 interface on the MX, and the transit VLAN that has interfaces on both the MX and the MS425.

 

Hope this helps.

Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.
Labels