MS350's unpingable

SOLVED
GB
Here to help

MS350's unpingable

So our design consists of two MS350's in a stack which uplinks to a firewall as the default gateway for all traffic. In regular Cisco switches it was no problem to assign the IP address of the switch in vlan 1 (mgmt) , create the routed interface for mgmt (ie 10.0.0.1) and have all management traffic. and have the default gateway (firewall) interact with the switches address on that VLAN 1. Create the rest of the routed interfaces and bam you're done..right. Yes, I do this all the time in home labs with real firewall equipment and Cisco L3 Catalysts.

However Meraki dictates when you first setup your switch that you define its IP address (which is not used for routing), which by the way HAS to be in the IP subnet as your uplink (the firewall) which makes sense. After the switch turns white and all seems happy I create the first routed interface for the management network. Let me give you a quick example as to explain myself thoroughly

 

Brand new setup Meraki it asks:

 

Choose VLAN: I add:  VLAN 1

Choose switch address: I add: 10.0.0.150

Choose netmask: I add: 255.255.255.0

Choose uplink:  I add: 10.0.0.254 (firewall / gateway)

BAM Healthy Switch. Good. Firewall has static routes to reach all of L3 interfaces and all is happy...BUT...

 

The problem with ping lies after I create the first routed interface which is the mgmt network. 

 

Name: Management Network

Subnet: 10.0.0.0/24

Interface IP: 10.0.0.1

VLAN: 1

Next hop: 10.0.0.254 (my Default GW / FW)

 

Again the topology works. Routed interfaces will reach each other however the MS350's will not respond to pings from other subnet. So a ping from another routed interface to the Meraki IP address 10.0.0.150 will fail and rightfully so. 

 

Again all is fine, I can reach of my routed interfaces and they can reach the internet with this configuration. However a ping to the switches mgmt address of 10.0.0.150 will fail from other routed interfaces. Meraki tech support told me a transit VLAN is needed and no management routed interface needs to be created, contrary to the standard non-cisco config I'm used to. When I asked to tech to show me the topology he would not get into details and the case was left unsolved.

 

It seems however from traceroutes they half the pings go to the default gateway of 10.0.0.254 and then ends up dropped with only half the pings succeeding the first try and then from thereout all pings from another subnet to 10.0.0.150 will end up failing completely. Can anyone elaborate on the tech's understanding of the management interface and how this can be resolved by different configuration. To this day I've not seen much or any Meraki documentation on the 'Transit VLAN' configuration and the issue I've described. Can anyone guide me with this and provide a *proper* explanation of what is going wrong here. 

 

Thank you

 

1 ACCEPTED SOLUTION
PhilipDAth
Kind of a big deal
Kind of a big deal

The management interface uses its own separate routing table.  That routing table only contains a default route via your firewall.

 

So a ping to that management IP address from a machine will indeed be routed via the switch - but the reply will go back via your firewall (unless the host is in the same subnet as the management interface).

View solution in original post

15 REPLIES 15
PhilipDAth
Kind of a big deal
Kind of a big deal

The management interface is only used to talk to the Meraki cloud.  Why do you need to talk to it?

Well I don't need to talk to it actually, but... I've been told by techs I'm wrong and it should be pingable as they can produce it in labs. So I'm looking for the logic and reasoning on this.

PhilipDAth
Kind of a big deal
Kind of a big deal

I just tested one, and it did respond to pings.

 

Overall - I wouldn't worry about it.  You don't ever talk to that IP address, so I don't see anything that you can achieve.

So the switch management IP address will send traffic to your firewall by default.  Perhaps the firewall is not routing the traffic back to your internal network, or perhaps it needs a rule added to allow this.

You mean from another routed subnet (layer 3 interface) you were able to traverse subnet and ping the cloud mgmt address of MS350 SW? Was your design similar to mine? Just curious as to why I can't get pings and everyone else can... strange... 

 

Did you have to setup the managment network (not *cloud management network) which I was told NOT to do by Meraki techs?

 

Just interested.

PhilipDAth
Kind of a big deal
Kind of a big deal

Yes I did ping it from a different subnet.

 

No, it is not in a special transit vlan.  It is simply in the uplink vlan.

 

I am running firmware 9.32.

GB
Here to help

I don't see why the traffic would hit my firewall. The other subnets should know that to reach the (mgmt) network of 10.0.0.0/24 the next hop should be 10.0.0.1  which is the Interface IP of L3 Interface.

PhilipDAth
Kind of a big deal
Kind of a big deal

The management interface uses its own separate routing table.  That routing table only contains a default route via your firewall.

 

So a ping to that management IP address from a machine will indeed be routed via the switch - but the reply will go back via your firewall (unless the host is in the same subnet as the management interface).

Okay there's the logic I'm looking for!  So just because my FW and First network coincides with the "Cloud" network, the 'special' routing table is screwing its paths...very interesting...

GB
Here to help

But how can I separate my own internal mgmt network for Meraki's? If I'm required to assign an address in the same subnet as the default gateway and I'm required to make my first L3 interfaces a next hop in the same subnet, how can I avoid this? 

 

BTW...THANK YOU SO MUCH. 

PhilipDAth
Kind of a big deal
Kind of a big deal

I wouldn't do it.

 

You would create a separate management VLAN off the firewall, and put the Meraki management IP into that (and configure the management VLAN as well).  The switch would not have a layer 3 interface in this VLAN.

Thank you for your help Phillip. I'm going to try just that tomorrow. As for now, you are the accepted solution because unlike other techs you were actually able to explain the logic behind the instance. 

 

You're a true network engineer and that's kind of a big deal.

 

Thank you so much and happy new years to you and yours.

 

-m

GB
Here to help

Too bad Meraki doesn't give more information about this topic.

GreenMan
Meraki Employee
Meraki Employee

This is obviously quite some time after the original post, but adding, for anyone also finding their way to this thread:   https://documentation.meraki.com/MS/Layer_3_Switching/MS_Layer_3_Switching_and_Routing#Notes_regardi...

1

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