MS390 OSPF uplink subnet in OSPF domain?

Toby
Getting noticed

MS390 OSPF uplink subnet in OSPF domain?

Hello!

 

I'm brand new to L3 Meraki/Meraki OSPF and have a question. I also tried reading this documentation without understanding why the thing I'm trying to do does not work:
https://documentation.meraki.com/MS/MS_Installation_Guides/MS390_Series_Installation_Guide

 

https://documentation.meraki.com/Architectures_and_Best_Practices/Cisco_Meraki_Best_Practice_Design/...

 

https://documentation.meraki.com/MS/Layer_3_Switching/MS_Layer_3_Switching_and_Routing

 

https://documentation.meraki.com/MS/Layer_3_Switching/MS_OSPF_Overview#MS_OSPF

 

 

Is it possible to set up the uplink network which the MS390 use to communicate with the cloud for participation in the OSPF routing domain?

 

I tried setting up another IP on the same subnet/VLAN under "Routing & DHCP", this newly created interface cannot reach anything, not even the mgmt IP of the MS390 itself. Is there some VRF going on under the hood? I tried this because the mgmt subnet cannot be configured for OSPF participation otherwise.

 

I'm guessing I have to set up the mgmt/cloud uplink outside of the OSPF process with the subnet terminating in a border device?

3 Replies 3
WirelesslyWired
Meraki Employee
Meraki Employee

Hey, these are good questions. Your L3 switch or switch stack will need to have it's management IP within the uplink subnet with a default gateway that is routable to the internet. This does NOT mean that it cant be in the same L3 segment, but you have to have a control plane MGMT IP & Data-plane IP. Example. 

 

Northbound uplink is 10.0.0.0/29. 

 

  • Neighbor is 10.0.0.1
  • switch SVI is 10.0.0.2 and default static is 10.0.0.1
  • switch management is 10.0.0.6 and default gateway is 10.0.0.1

You can absolutely peer with 10.0.0.1 using OSPF for dynamic routing, but the management interface (10.0.0.6) must be able to statically point to 10.0.0.1 and reach the internet. 

 

CCIEw# 45253 / CWNE# 249 / Principal TME - Meraki Product
Toby
Getting noticed

Okay, thanks for the clarification. That why the SVI and MGMT IP cant reach each other I guess, because of the controlplane vs dataplane (I'm a bit rusty it would seem).

 

I'll have some more labbin done on this, cheers!

Toby
Getting noticed

Hello!

 

I've been doing some more testing and thinking about this and I've run into a design consideration issue.

 

I've concluded (unless I'm mistaken) that it's not possible to reach the IP address the MS390 use for communication with the cloud via the route which I distribute through OSPF. It is possible to reach the IP address of the interface I've setup as an additional interface on the MS390 which is part of the same subnet as the IP used for cloud communications which is setup so that I may redistribute the subnet throughout the OSPF domain. Is this behavior specific to MS390?

 

EDIT: Since MS390 isolates the control traffic from the data traffic it is not possible to reach the mgmt IP via the OSPF route (even if the SVI created in the MS390 to enable the route to be propageted throught OSPF lies within the same subnet), you're essentially creating a dual-purpose subnet/VLAN with some form of segmentaion invisible to the user, it would make more sense not to allow it at all I think. This also creates a little bit of a problem regarding management since you have to resort to static routing for the mgmt features to work as expected. I can see the benefit regarding security, but it should be an option to let the designer of the network take proper measures to secure the mgmt plane themselves.

 

Imagine we'd like to use the subnet which is used for cloud communications for some internal service, for example SNMP. This means that we have to setup an additional IP address for every MS390 used as a L3 device on the subnet which means that we have to use 2x IP addresses per device if we want to achieve this, is this correct?

 

We could also define a new subnet which is used for internal management services such as SNMP, but if we consider that we might want to expand to using MR devices which can only hold a single IP address. Then we'd have to use different designs regarding management of these devices based on what the hardware is. So for example 1 subnet for cloud communications and another for the internal services on MS390 (or dual IP addresses) and then a single subnet for cloud communications and internal services for MR type devices. Would this be the correct assumption?

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