Management IPs on Hub and Spoke WAN

mcbrown
Comes here often

Management IPs on Hub and Spoke WAN

Hi Everyone,

 

We have a hub and spoke WAN. I am doing a full conversion over to Meraki with a combination of 425s, 350s and 225s. 

 

A 425 stack is installed at the “hub” and is basically the core of the network. The 425 stack connects to our firewalls via a trunk.  The management IPs of the 425s are in the 172.20.254.0/24 network and the gateway of this vlan is the IP of the firewall. The 350s are the core of the “spoke” and will connect to our 425s via a trunk and ospf will be enabled on both the 425s and 350s. I have a transit vlan setup on both the 425s and the 350s that will be used for ospf. 

 

I am having a problem with the management IPs on the 350s. It appears that the only way the 350s can get out to the internet is if they get an IP from the 172.20.254.0/24 network. I would like the 350s to get an IP from the 172.19.254.0/24 network that is defined on the 350s.  That second octet is how I define what building the devices are in. Is it possible to set up the management IPs on the 350s this way?

 

Thanks for your help. 

6 Replies 6
ww
Kind of a big deal
Kind of a big deal

Meraki switches dont like to get a management ip from its own svi/vlan.

 

That gateway ip for that vlan should be on the ms425 or on the firewall and then l2 to the ms425-ms350

DarrenOC
Kind of a big deal
Kind of a big deal

Upvote for @ww .  Meraki switches don’t respond well when the mgmt vlan resides on itself. Learnt this the hard way.

 

Youll have to use an upstream device.

Darren OConnor | doconnor@resalire.co.uk
https://www.linkedin.com/in/darrenoconnor/

I'm not an employee of Cisco/Meraki. My posts are based on Meraki best practice and what has worked for me in the field.
JacekJ
Building a reputation

cmr
Kind of a big deal
Kind of a big deal

With Meraki you have an organisation that is subdivided into networks.  If you use the networks as sites or buildings then you don't need to worry about IP ranges to know where a switch is.

 

For example an alert for one of our switches would say something like:

 

The following settings have changed on the sitename - switch  network.

Switch ports
  • Players bar / 2 was changed.
    • Old value:
      • Name: Castle
      • VLAN: 210
    • New value:
      • Name: IoT
      • VLAN: 17
mcbrown
Comes here often

Thanks to everyone for their responses.
 
Couple follow up questions.
 
Is it correct to say that the switch management IP should come from a VLAN defined on the closest layer 3 switch in the uplink chain?
 
If using OSPF between the 425s and the 350s should the management VLAN be advertised on OSPF or is it better to not advertise?
 
I am going to open up a can of worms with the next couple of questions but here we go:
 
If I define a Meraki network for each site/building, is it best practice to place all Meraki devices (switches, access points) in that building's Meraki network or should a site for each type of device be defined for each site/building?
 
I had planned to use OSPF and create stub areas for each spoke.  We only have about 35 switches total and most resources are at the data center in the hub so one area will work but I don't see a downside in creating the additional areas for each spoke.  Is there a downside to creating the additional areas?
 
Last thing, creating the management VLAN for the 350s on the 425s got me thinking, is there any advantage to creating all of my VLANs for the network on the 425s and then sending them over the layer 2 trunk to the 350s as opposed to using OSPF between the 425s and the 350s and defining VLANs on both the 350s and 425s?  
 
Thanks again for everyone's input.  

 

cmr
Kind of a big deal
Kind of a big deal

@mcbrown a few answers:

 

  1. The gateway should just be on any other device, not that one.  Our devices may have another switch or two, before they get to the gateway.
  2. I'll leave that for someone else
  3. One combined network per site/building, you get the best visibility that way
  4. as 2
  5. It depends on your traffic routes.  In general, if traffic on a switch is predominantly heading to devices on another switch, do the routing there, if traffic is staying local to the switch but across VLANs, route on the local switch.  Obviously the larger your network gets the more grey these decisions become.
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