OSPF Uplinks Setup and Vlan Accessibility

mcbrown
Comes here often

OSPF Uplinks Setup and Vlan Accessibility

I have a stack of MS425s connecting to a stack of MS350s. 

 

I have the following VLANs setup on the MS425 (network core)

19 (172.20.19.0/24 - 172.20.19.1) - transit between the 425s and the 350s

219 (172.20.219.0/24 - 172.20.219.1)- management VLAN for the 350s

10 (172.20.10.0/24 - 172.20.10.1) - test VLAN at the network core

110 (172.20.110.0/24 - 172.20.110.1) - AP Management at the core

 

I have the following VLANs on the 350s (remote building)

19 (172.20.19.0/24 - 172.20.19.2) - transit between the 425s and the 350s

110 (172.19.110.0/24 - 172.19.110.1) - AP management at the remote building 

 

The uplink from the 350s to the 425s is setup as a trunk with allowed 19,219 and no native VLAN

 

I have enabled OSPF on both the 425s and the 350s. 

On the 425s OSPF is enabled on:

19 (passive false, area 0)

110 (passive true, area 0)

 

On the 350s OSPF is enabled on:

19 (passive false, area 0)

110 (passive true, area 10 Stub)

default route 172.20.19.1

 

First question is does this setup look correct?  

 

Second question is if I run a ping from the 350s from int 172.19.110.1 to 172.20.10.1 (VLAN 10 on 425s) it is successfully pinging. VLAN 10 is not part of OSPF and VLAN 10 is not an allowed VLAN on the uplink from the 350s to the 425s so why are the 350s able to ping 172.20.10.1?  

 

Last concern is when I run the Routing Table tool on the 350s or the 425s it just spins forever and never shows the results? 

 

Thanks for the help.

 

 

4 Replies 4
Brash
Kind of a big deal
Kind of a big deal

With no additional context, the routing logic seems fine. The only change I'd consider making is using a different vlan for AP management at the remote site and just trunking the transit vlan but that's more of a personal choice.

 

You're getting successful pings because of the default route.

The 350 will send unknown destination traffic to the 425, and the 425 has a 172.20.10.1 directly connected.

 

Can't help you on the third one

mcbrown
Comes here often

Ok good.  It's the same vlan number at the remote site but it is a different subnet.  Core vlan 110 is 172.20.110.0/24 and at the remote site it is 172.19.110.0/24. 

 

Got it.  

 

Thanks for the confirmation Brash.  

mcbrown
Comes here often

Have a follow up on this. I am trying to figure out the best way to isolate VLANs at my spokes?

 

I have guest VLANs for WIFI and also have IOT VLANs that I want to fully isolate and only allow access to the internet.

 

My MS425s at the hub/core are trunked to a pair of active/passive Palo Alto firewalls. The way I have isolated guest and IOT VLANs in the past is with VRFs that default route to a dedicated guest interface on the Palo Altos at the Core/hub. I know VRFs are not an option on Merakis so was wondering if there are any options on the Merakis to fully isolate a VLAN other than ACLs?

 

Thanks.

Brash
Kind of a big deal
Kind of a big deal

The only way to do this in Meraki is with ACL's.

That said, they're pretty simple to setup.

 

Depending on what works best for your scenario you can apply them via SSID, Vlan, Group Policy.

 

The below doc might be a useful reference

https://documentation.meraki.com/MR/WiFi_Basics_and_Best_Practices/Configuring_Simple_Guest_and_Inte...

Get notified when there are additional replies to this discussion.