Static vs Dynamic IPs for Meraki Equipment

Solved
DerikA
Getting noticed

Static vs Dynamic IPs for Meraki Equipment

Hello, I've been at my place of employment for a little over a year now and I am starting some restructuring of how the old Network Admin had things done (he was not a Net Admin by trade).

 

I have created a new IP scheme that includes a block of management vlans for all the network equipment in each location and in the past with any traditional Cisco network I would assign every network device a static IP according to company wide IP numbering system but here in the Meraki world is that needed?

 

Obliviously MX devices and any layer 3 MS switches would need static IPs but what do you do about layer 2 MX switches, MRs and other such Meraki devices? Is it even worth them having static IPs? What do you see as the pros and cons of static to dynamic IPs for these kind of devices?

 

I'm the only one on the network team so I have no one to bounce thoughts off of so thanks in advance for any comments and sorry if this has been hashed over before.

1 Accepted Solution
Bruce
Kind of a big deal

My thoughts are, ‘what are you going to use the management IP address for?’ With traditional Cisco you’d have used it for managing the specific device, and having a DHCP address that may change wouldn’t make sense in this case. In the Meraki world you manage through the Dashboard and rarely (if ever) do you connect directly to the device - and even if you do want/need to, it’s easy to find the IP address from the Dashboard.

 

The other benefit of using DHCP is zero touch deployment. If you’re using DHCP there is no pre-provisioning of devices. Even for your Layer 3 switch I’d consider using a DHCP assigned address for the management interface.

 

The only partial reason I can see for static IP addresses is for protocols such as RADIUS where you may need to define the NAS/NAD on the RADIUS server. But even then you can normally define a subnet, so often a static IP address would be hard to justify there too.

 

I can’t think of a good justification for static IP addresses on the management VLAN for a Meraki network. I’d do DHCP wherever you can.

View solution in original post

3 Replies 3
cmr
Kind of a big deal
Kind of a big deal

@DerikA as you have said L3 routing devices need static IP addresses, as for the L2 MSs and all MRs I go dynamic these days as there really is very little point in having static IPs from a management point of view as you don't manage them by directly connecting them.  The only reason you might, is if you have a legacy SIEM solution or SNMP monitoring solution that you want to talk directly to the individual devices. 

If my answer solves your problem please click Accept as Solution so others can benefit from it.
Bruce
Kind of a big deal

My thoughts are, ‘what are you going to use the management IP address for?’ With traditional Cisco you’d have used it for managing the specific device, and having a DHCP address that may change wouldn’t make sense in this case. In the Meraki world you manage through the Dashboard and rarely (if ever) do you connect directly to the device - and even if you do want/need to, it’s easy to find the IP address from the Dashboard.

 

The other benefit of using DHCP is zero touch deployment. If you’re using DHCP there is no pre-provisioning of devices. Even for your Layer 3 switch I’d consider using a DHCP assigned address for the management interface.

 

The only partial reason I can see for static IP addresses is for protocols such as RADIUS where you may need to define the NAS/NAD on the RADIUS server. But even then you can normally define a subnet, so often a static IP address would be hard to justify there too.

 

I can’t think of a good justification for static IP addresses on the management VLAN for a Meraki network. I’d do DHCP wherever you can.

DerikA
Getting noticed

Thanks @cmr and @Bruce, years of habit are hard to break sometimes. I needed to hear others saying the same thing the voice in my head was to help override the habit.

Get notified when there are additional replies to this discussion.