We love Meraki products, easy to set up, easy to troubleshoot, easy to monitor, easy to maintain. Even though they are easy, you can still get tripped up.In this week’s vBlog, Raymond Lacoste, shares five things to have a much better, easier Meraki Security Appliance deployment experience.
Photo credit: Cisco Meraki
But first, why use Meraki to begin with?
(If you are already convinced to deploy Meraki Security devices, feel free to scroll down to the video and ignore this next part.)
Compared to other options, Meraki (and cloud-managed IT as whole) is praised for being easy to set-up, configure, and manage from anywhere. For IT teams with a few members for many locations, Meraki allows them to manage networks and troubleshoot from anywhere. Meraki helps cut down on on-site man-hours focused on troubleshooting, which allows IT teams more time for other tasks.
Meraki also touts “high levels of productivity and uptime” due to its capabilities in maintaining a secure stack. Most users on Spiceworks find that Meraki is unbeatable when it comes to their security options. Security updates launch automatically and admins have the option to view application usage on a per-client basis on a single dashboard. Meraki also limits the potential access points for threats in a way regular wireless networks are unable. Security becomes a very visible and automated process for IT teams using a cloud managed infrastructure.
Related article: How to Choose Between Autonomous Access Points and Lightweight Access Points
While Cisco Meraki has many benefits over other options, there are complaints about the subscription-based pricing for their products and services. We suggest looking over the benefits like advanced security, included support, and ease of use while weighing it against your specific budget and situation. Meraki has shown to lower the TCO of your investment over time, especially with their support network, but only if the subscription pricing makes sense for your company.
5 Things to Have an Easier Meraki Security Appliance Implementation
So you’re considering implementing Cisco Meraki, here are some tips on having a smooth security deployment. Even with the system’s advanced security capabilities and ease of use, there are still hiccups that can happen in any implementation. Raymond Lacoste will teach you in this video how to avoid the most common pitfalls he’s seen with security deployments:
Trying to decide what wireless access points to deploy at your company or trying to win a bet about what type is best? Download our Buyer’s Guide to Wireless Access Points! Within this guide, we’ve included: overviews of each Wireless Access Point Architecture, pros and cons to consider, and question sheets to make sure you choose the best option for your organization.
About this vBlog Instructor:
Raymond Lacoste has dedicated his career to developing the skills of others. His 17 years in the industry allow him to pull from experience in the areas of Amazon, Cisco, and Microsoft. For the last 8 years, he focused primarily on advanced IT instruction. He is also the Cisco Press author of the TSHOOT 300-135 Official Cert Guide. Raymond is a voracious learner and is constantly studying new technologies. To date, he has passed over 100 exams. His certification wall includes various certificates from Amazon, Cisco, Microsoft, ISC2, ITIL, and CompTIA. Over the past years he has also been awarded, on numerous occasions, the Cisco Sirius Top Quality Instructor Award and the Cisco Instructor Excellent Award.
Before becoming an IT instructor, Raymond was an aspiring golf professional, so golf is in his blood. When he is not teaching or designing and delivering the best in the industry training you can find him practicing or playing golf rain or shine or snow. Wanna join his next class? Learn more here.
Transcript of this video:
Greetings, everyone. Raymond Lacoste here with StormWind Studios and I want to share with you today five things you should know about Meraki Security Appliances. I love Meraki products, easy to set up, easy to troubleshoot, easy to monitor, easy to maintain. Even though they are easy, you can still get tripped up. I want to share with you five things that we feel that if you knew about, you would have a much better Meraki Security Appliance deployment experience.
First and foremost, let’s look at this topology. We have a single security appliance topology, and that single security appliance is what many of you might deploy. What we’re lacking in this deployment is high availability. I’m a big, big fan of dual security appliance deployment because we get high availability when we go with our dual security appliances.
However, we end up with many more caveats that many of us are not aware of, and that’s what I’m going to share with you right now. First and foremost, our security appliances don’t support spanning tree protocol. When we implement this dual high availability deployment with two security appliances, we could have a serious problem on our hands, and that is layer two loops.
Let’s really dive into where these loops could occur. Our security appliance, since it doesn’t participate in spanning tree protocol, doesn’t understand any of those spanning tree protocol [BPU’s 00:02:11]. Any of those links you see right there between the security appliances and our downstream switches are subject to layer two loops. We definitely want to make sure spanning tree protocol is running everywhere it can and if we recognize that a spanning tree loop could occur between any of the links up in this area of the topology, we’re going to want to manually control which VLANs, which traffic, is allowed to flow across each of the links, and that will allow us to make sure that the spanning tree loops do not occur at that point in time.
You might be saying, “Well, wait a second. Why are we running layer two up there?” Because these are all classified as trunk ports or access ports when it comes to the security appliance. There are not layer three rerouted ports. What that means is that if you have your typical layer three/layer two architecture, these are still layer two links and they are susceptible to loops. You’re going to have to identify the loops and stop them from happening.
In addition, if you are running layer three up here and layer two all down here, we have one large two domain, which is susceptible to loops in this portion of the network. You’ll want to be able to identify where those loops could happen and then prune the traffic as necessary on a VLAN by VLAN basis off the links to stop any loops from occurring.
You’ll see here that we have this link between the two appliances. This link is here not for passing traffic. It’s there as the VRRP heartbeat used for that high availability scenario, so they can see if each other exists. Why? Because we have an active standby scenario here when it comes to our high availability deployment. Only one of these security appliances is going to be active at any point in time. If the active one fails, the standby one learns about this through VRRP heartbeats and then it can promote itself to be the active one and forward the traffic as necessary.
This direct connection is there to make sure that we have the ability to communicate directly with each other and not end up in an accidental active/active scenario because the heartbeat is not successfully going through the downstream switches. The heartbeat will be running on all the links, however, this extra link, that dedicated link, is going to ensure that we never end up in that active/active type of scenario.
However, what you need to realize about this is that this link here definitely becomes a problem with spanning tree protocol loops. What we need to do is, we need to make sure that only VRRP traffic is going across that link. You don’t want any other traffic going across that link, you’re not using it forward any other types of traffic for any other types of VLANs. Only allow the VRRP heartbeat to go across that link and nothing else. That will help you avoid loops due to the fact that spanning tree protocol is not running on our appliance.
Next item on our list is dynamic routing protocols. That’s not a problem if you are running layer three up here and layer two down here, because you’re not going to have to worry about routing at all in this part of the network. The security appliances, they’re going to be your default gateway, so through layer two forwarding, using Mac addresses, we can get to the RD default gateways of those security appliances. No problem there whatsoever.
It’s when we have our typical setup of layer three, layer two. In this case, we don’t have the ability to run our dynamic routing protocol on our what? On our security appliance. The end result of that is, how do we even get traffic forwarded from here upstream, wherever we need it to flow? This is where we have to get creative with static default routing, set up some floating static default routes, maybe rely on some interface tracking through some sort of first-hop redundancy protocol we have at the distribution layer, maybe even rely on an IPSLA as well. We really have to get creative here, simply because they don’t support dynamic routing protocols.
Let’s also think about the fact that traffic has to come back. For traffic to come back, how are we going to forward traffic when it comes back in, depending on who’s active and who’s standby? Again, we’re going to have to rely on being creative at static routes on the security appliances and we’ll also have to make sure that we have some way to control which static route is being used at what time, and that’s where IPSLA can help us there as well. Even though they don’t run dynamic routing protocols, by being creative, we can still accomplish the goals that we need to accomplish.
Also, your spare config is assumed based on the primary config, so you’re not going to be configuring that secondary spare device. We configure our primary as need be, we push a button to activate a spare, we put in the serial number of that spare device in the dashboard, and everything’s done for us automatically behind the scenes. What that means is, whatever we configure on the primary is inherited by the secondary. Why do you care about that? You care because if you physically cable the spare incorrectly, then your high availability solution is not going to work.
The reason why that is, is because the config is based on, let’s say, this being port three. Then this better be port three as well. The config is based on this being port four. Then this better be port four as well. It’s based on that being port 5, so this better be port five as well. It’s based on this being port one, so this better be port one. Based on port two, this better be port two. I think you get the picture. The physical cabling also plays an extremely important role here. If port one on the primary goes to the primary ISP, then port one on the secondary better go to the primary ISP as well, whereas port two goes to secondary ISP, and so on and so forth. The cabling is extremely important because that config is inherited, so that way, they are exact matching copies of each other. That’s extremely important when you’re setting up the solution.
Next, regardless of whether you’re a high availability solution or a single security appliance solution, you want to used the advanced security license. The reason why is because the enterprise license, albeit it’s great, providing us with stateful firewall and VPN-ing and application control and web caching, I want more. I want you to have more as well. You want content filtering, you want IDS/IPS, you want advanced malware protection, you want Cisco Threat Grid, you want to sleep better at night.
For myself, I sleep better at night knowing that IDS and IPS is working for me. I sleep better at night knowing that I am amped up with advanced malware protection and Cisco Threat Grid. As my network keeps getting attacked at night, I am sleeping soundly and well, knowing that I’ve got a team out there, somewhere behind the scenes, that doesn’t even work for my company, but because I paid for the advanced security license, I’m getting all this extra stuff for me behind the scenes that my security appliance just learns about and knows about and can protect my organization. This is going to cost you more, potentially double what you were originally anticipating to spend, but definitely, it’s well worth the investment.
Lastly, you need to have the same models for NAT HA mode. Plain and simple. Why is that? Think about it. We already said we inherit the config, so if we don’t have the exact same models of security appliances, it’s not going to work for us. The reason why I bring this to your attention is because a lot of organizations think, “I am going to go with a high-end security appliance as the primary, and we’re going to get a low-end one as our standby, as our spare, because we can deal with slower through-put and slower processing and slower everything else during a fail-over scenario, as long as we still have connectivity.” It’s not going to work for you that way. You must wipe that mentality from your brain. They must match. If you go with an MX100 as the primary, you need to use an MX100 as your standby.
Folks, by keeping these five things in mind when transitioning from other security appliances to Meraki Security Appliances, or deploying security appliances for the first time using Meraki Security Appliances, knowing these, keeping them in mind, you’re going to have a much better, trouble-free deployment experience knowing all this ahead of time.
From all of us here at StormWind Studios, thank you very much for listening today, and until next time, keep on learning. Take care, folks, and bye for now.
