Templates and VLANs

[ELobato]

Hi! 

First time posting! We have been managing an organization for the last year and basically did a full infrastructure change to Meraki. So we are quite fresh with some things, here is the deal:

We have currently a little less than 100 sites (networks) but we are planning on growing larger during the next few years. However, the current IP plan we have will change since right now there is no segmentation. So to make it better we are adding VLANs to all sites, these include for example phones and cctv cameras, regardless if they actually have phones or cctv cameras in the site just to keep a standard configuration and flexibility and hopefully take advantage of the templates.

After reading the documentation and some other community posts, I understand that the addressing gets assigned randomly and uniquely from the selected subnet. We want to assign each site a /16 network and then hand out each VLAN a /24 from that /16 network. We don't really care with this scenario that Site 1 gets for example 10.89.0.0/16 and Site 2 10.1.0.0/16 which would be the random unique /16 from a 10.0.0.0/8. However, and here comes the question, is it at all possible to keep a VLAN order so that it gets further split into the VLANs, but always on the same way for all sites. For example, this is what we want:

Organization: 10.0.0.0/8

Site 1: 

Random /16: 10.89.0.0

VLAN 1 (ie clients): 10.89.1.0/24

VLAN 2 (ie phones): 10.89.2.0/24

.

.

.

VLAN X: 10.89.X.0/24

Site 2:

Random /16: 10.1.0.0/16

VLAN 1 (ie clients): 10.1.1.0/24
VLAN 2 (ie phones): 10.1.2.0/24
.

.

.

VLAN X: 10.1.X.0/24

And so on...Then we know exactly what something is by IP. The reason for this is because we run a hub and spoke scenario with Auto VPN Site-to-Site. Other than that, all firewall rules will be configured to limit inter-VLAN communication and the template will handle those by name without problems so all sites have the same rules. All other settings on each site are basically the same as well: SSIDs, Access policies, authentication methods, etc., that is why we are considering templates instead of independent network creation. Is this something possible? Or is there another way you recommend doing this? I guess maybe with API it could be mass configured, but we have no experience with API so that would set us back a bit.

Sorry for the wall of text, just trying to make it as clear as possible.

Thanks a lot in advance!

[PhilipDAth]

No that is not possible.

I can tell you I have transitioned off using this approach quite a bit.  I still use VLANs, but I tend to use per-device group policies enforced by the MX for security.

Then you can have three different devices all on the same VLAN but all with different firewall rules.

https://documentation.meraki.com/zGeneral_Administration/Cross-Platform_Content/Creating_and_Applyin... 

If you are using group policies in a template this can be very powerful.  Let's say device type "x" gets compromised.  You can make one change in one place, and block just that device at every location from having network access.

[ELobato]

Thanks for the reply Philip!

I'll have a deeper look at this suggestion, it could be quite interesting. As for manually changing the assigned VLANs, my colleague mentioned something earlier, and I am guessing this must be it. I was thinking overnight though, that in the end, if we have all sites "be the same" logically (regardless of if they are in reality or not), then we could probably just go ahead with full /24 random assignation then we wouldn't be limited to 255 sites with the /16 then 255 VLANs with the /24 that we obviously would never use for each site. If Meraki is handling all this anyway and policies, and rules we can use by VLAN name and device types, then I guess the actual addressing wouldn't matter if we assign a /24 to every VLAN from a /8. Sure looks like a nightmare in management since we wouldn't ever know what 10.191.30.0/24 belongs to exactly as we would with the first proposal, but then maybe we don't need to care when everything is Meraki and centralized in Dashboard anyway. Thoughts?

Anyhow, we will consider both options for now, and I'll get some more reading on the documentation you sent. Thanks again!

[PhilipDAth]

One thing you can do is allow a template to randomly assign subnets to the site VLANs, and then you can go in and just change them to what you want.

At least this way you would keep all the other benefits of using templates.

Also note that you will need to open a case with support to disable AutoVPN strict IP address checking.  Otherwise, you won't be able to sub-allocate a /16 into smaller chunks to use in one site for different VLANs.

[ELobato]

Hi!

So we have looked into letting all addressing be random and just going for a unique /24 out of a /8 and handle all the VLAN firewall rules with the name tags and host bits when applicable. However now we are stuck on the Site to Site VPN firewall rules. When doing the firewall rules on the template we would say for example VLAN clients won't talk to VLAN production, but when both VLANs are going on the AutoVPN they will be able to talk to each other across networks, right? So the L3 firewall rule will block that per site, but not on the VPN. How could that work? We would like to limit and control the interVLAN traffic going through the VPN, but as far as I can see we would need to have a huge list of outbound organization wide rules for Site to Site since that one is not supporting VLAN name tags. Are there any suggestions regarding this scenario?

Thanks again in advance for any input!

[PhilipDAth]

I would use one supernet for all your clients, and another for the production networks.

For example, 10.16.0.0/16 for clients and 172.16.0.0/16 for production.  Make the third tuple the site identifier.  For example, a single site might use 10.16.34.0/24 for clients and 172.16.34.0/24 for production.

Then you can create broad VPN firewall rules like 10.16.0.0/16 is denied access to 172.16.0.0/16.  Instantly with one rule, every client network is denied access to every production network.