In an earlier post I stated that we (Lekker Foods) were moving on to Meraki firewalls; well, we are there!  This post is going to detail the things I discovered on my journey from Sonicwall to Meraki.

The biggest thing I discovered or, at least, re-learned is that the various networking gear manufacturers can’t agree on terminology.  The majority of issues that I ran into during the migration process were almost solely related to misunderstandings around terms used by Meraki, HP (network switch), Ubiquiti (network switch) and Netgear (network switch).  HP and Ubiquiti were close to Meraki in terminology but not exactly the same, Netgear was waaay off.  All of this had me chasing my tail for awhile but I did get things sorted out in the end.

Terminology messed me up first and foremost because Meraki is much more “enterprise” oriented than is Sonicwall.  By that I mean Meraki tends to make you think much more in “enterprise” networking terms than does Sonicwall.  Sonicwall, out of the box, does not “enforce” VLAN’s; their nertworking configs are more “traditional” (read as “simple”) and their Portshield process allows you to carve up the box into numerous simple “switches”.  Nowhere in Sonicwall documentation do they refer to this port configuration with terms such as “host port” or “trunk port” or “access port”.

Meraki, on the other hand, wants you to configure VLAN’s right up front and then configure ports for the manner in which they are going to handle the VLAN’s assigned to them.  This is not particularly hard to understand once you realize what they are looking for BUT, if you look at it coming from a Sonicwall “view”, it’s a bit weird.  And, yes, I do realize that Sonicwall DOES handle VLAN’s, it’s just not pushed on you up front.

So how did this mess me up?  Simple, I truly misunderstood basic configuration which then lead me down any number of dead ends.  And, to add insult to injury, a query to Meraki support up front was misunderstood and I received misleading information.  Yeesh.

So, let’s look at what my problems were and what I had to do to figure them out.

VLAN Terminology

My first mistake was not completely understanding some VLAN terminology which, once again, is not necessarily consistent across all network vendors.

The terms tagged and untagged are pretty well universal.  Tagged traffic carries the VLAN ID as part of its identifying information.  Untagged traffic carries no such ID.  Normal traffic from regular network clients (PC’s, printers, etc) generates untagged traffic.  Specialized network clients such as VoIP phones can generate tagged traffic.

Where things start to get muddy is in the VLAN ID config.  Some vendors will refer to a native VLAN ID and other vendors will refer to a PVID.  Both are referring to the exact same thing which is what VLAN ID is the default VLAN ID assigned to a given port.  The default VLAN ID (native or PVID) is the VLAN ID that will be assigned to traffic flowing through the port by default unless otherwise tagged.

 

Port Types

From a Meraki point of view this was the biggie and the one that made me fall over more than once. The Meraki supports the following port types:

– TRUNK: passes ALL VLAN’s  or at least two or more over the port.  Think of it as a multiplexed bus or the main conduit.  Some networking vendors (I’m pointing at you, Netgear) use the term TRUNK to refer to a bonded-port configuration (two or more ports are bonded together to form a “fatter” link) but that is NOT how Meraki (Cisco) and other enterprise vendors use the term.

– ACCESS: passes a single VLAN over the port.  This is much like the typical Sonicwall port or a typical switch port.  From the point of view of the network behind it it is the gateway and has the gateway IP address assigned to it.  I didn’t understand this up front and this was the mis-information that I got from Meraki support; I was told that I had to VLAN meaning my switches all needed to totally understand VLAN’s and VLAN tagging.  Patently wrong!!  If you set a Meraki port as Access then you can have a completely dumb switch behind it.

So I was under the impression that I had to have ALL my switches behind ALL my Meraki ports (I have three Meraki firewalls) fully VLAN capable and configured and capable of understanding TAGGED and UNTAGGED traffic.

In the case of a TRUNK port off the Meraki my understanding was true.  The switches downstream from the Meraki TRUNK port do need to be able to handle proper VLAN configuration.  For instance, if a switch is sitting behind a Meraki trunk port that has the native VLAN ID as 10 and VLAN’s 2 and 10 are allowed to pass over it then the switch needs to have its TRUNK port set the same way.  Ports on the switch can then be individually configured to handle the VLAN’s as required.  Certain traffic can be tagged, other traffic can be untagged and the switch handles appropriately based on port configuration.

In the case of an ACCESS port off the Meraki my understanding was muddied.  An ACCESS port in essence passes only UNTAGGED traffic downstream of the port (just like any other “dumb” port”).  So, in my case, I have a dumb Planet switch that supports my internal backup network (192.168.72.0/24) hanging off the Meraki.  The Meraki port is configured as ACCESS with a VLAN ID of VLAN 30 assigned to it.  Downstream of the Meraki port (on the switch) traffic is UNTAGGED.  Upstream of the Meraki port (internal to the firewall itself) all traffic coming from the 192.168.72.0/24 network is TAGGED as VLAN 30.  I really didn’t “get” this piece and I blew my brains out for some time until the lights came on.

The big thing to understand is that if you set the Meraki port to ACCESS then the switch downstream of the port needs to essentially be configured as “dumb” meaning you do not do any VLAN configuration on the switch.  You have stripped VLAN’s out of the equation at least as far as your switch is concerned as soon as you set the Meraki to ACCESS.  Conversely, if you set the Meraki port to TRUNK then you better have the switch downstream of it configured properly or all sorts of grief will ensue!

And this brings me to the next piece of the story, describing how the switch vendors made me crazy!

My HP and Ubiquiti switches both understand TRUNK port settings so they were pretty simple to configure.  However, there are subtle differences between them as to how you then configure individual ports to handle tagged and untagged and how you “mask” individual ports from unwanted VLAN traffic.  You have to read the docs for each and play a bit to understand how each vendor expects you to make your settings.

My Netgear switches DON’T understand TRUNK port’s at least in the sense of having TRUNK as a configuration type that creates a proper TRUNK port.  You can create a proper TRUNK port, you just have to understand that there are a series of manual steps that you have to perform in order to apply the correct settings to a port to make it function as a TRUNK.  And, of course, they muddy the waters further by offering a “TRUNK” config option that is actually a bonded-port creation.  Yeesh.

Once I got all of the VLAN stuff figured out it was actually a very quick and easy process to migrate over to the Meraki firewalls.  In a future post I’ll discuss the relative ease of configuration of the firewall settings (over that of the Sonicwall).

Meraki Firewalls (Security Appliance) and VLAN’s
Tagged on:                         

Leave a Reply

Your email address will not be published. Required fields are marked *