Meraki and Cloud Management

The cloud is taking over IT…. What are we all going to do when everything is cloud managed? Will we all be out of a job?  It is true the the Cloud is becoming a big thing, but like all changes in technology the devices and applications in the cloud still need to be managed and maintained by someone.

Meraki have taken the Cloud  a step further by providing a Cloud Managed Network. This is a great concept and can really simplify the deployment process. The Piece that is missing from this concept is that the Cloud doesn’t actually manage the network. The skilled technical folks that have that ability to isolate a problem and solve it are still required, regardless of the platform for Management. Meraki have made it easier and certainly the less technical would find some benefits in the Meraki approach, but like so many technologies they are sometimes too complex to simplify, or the process of simplifying the technology leaves it missing some key elements.

Cisco’s purchase of Meraki  shows that Cisco really believe in the Cloud, but I am curios how they plan to integrate, if at all. Cisco’s attempt at moving down market with Linksys was a mistake, as I think most Cisco savvy folks would balk at any Linksys Product.

In looking at Meraki’s  products, it would appear that they are well ahead of any Linksys product and slightly behind Cisco Traditional IOS products from a feature standpoint  but obviously well ahead of any Cisco product from a Network Management standpoint, an area that I think Cisco have always struggled with. It will be interesting to see if Cisco try and merge their IOS into Meraki’s cloud Management.

Either way, this has next to no effect on the business of Network Management, as these networks still require Management, regardless of the management platform in which they reside.

 

Uncontrolled Network Growth

When companies find themselves growing faster than they had planned their network grows with them. Keeping up with the day-to-day tasks of running an organization that is growing obviously requires focus and dedication and the network almost always gets left behind.  I don’t mean left behind from a Bandwidth or Capacity standpoint, as those things must keep up with the business, what I mean by left behind is the planning, maintenance and overall architecture standpoint.

The result can be overwhelming: Where does one start? Do you rip it all out and start fresh? Do you employ a phased approach? What Vendor do you go with? Do you need to hire a Consultant or Project Manager?

When I come into these situations I must be  careful not to insult the person or people who let it get to this stage, after all they were just responding to the needs of the business. So, where does one start……

I have found that if the organization focused on anything it was the server infrastructure and the network infrastructure is nothing more than a number of BIG BOX store items from various manufacturers.

So, I start with this Foundation and based on the business goals segment the network to allow for Stability, Security and Scalability. Spend a few dollars on this infrastructure and you will save yourself a ton of time and effort in the long run. Employ a logical distribution of servers, services and there tasks across different VLAN’s. Think about some of the longer term goals  like VoIP… Maybe putting in PoE switches now is the right thing to do even if VoIP isn’t in your immediate plans. Think about the industry you’re in and if it hasn’t already developed some form of compliance requirement, will it in the future? Build your network as if you are a bank. Build your network based on best practices.

You will find that once this foundation is in place, the task to add, remove or change any aspect of your network becomes just a task and not some unattainable goal.

Document and monitor your network!!!!!! Purchase a maintenance contract on your equipment (it’s called insurance)… And Finally – if you’re not a network professional give us a call to help you design, build and maintain your network because it is what we do for a living…

Outsourcing Network Management and Monitoring

Outsourcing to some, is a bad word. Almost as bad as “consulting”…. a word that makes me cringe. The fear of losing control seems to be the driving factor in steering IT folks clear of outsourcing. But it doesn’t have to be that way at least not with End to End. Now I don’t want to sound like a commercial, but I do see a significant advantage to our services over the competition. I will start by addressing the control factor.

Recently we were working with a prospect that had an existing Internet service with one of the big Canadian Carriers, I won’t mention names. As part of our engagement, we needed to gather some information regarding the configuration of the Cisco Router that terminated the Internet connection. The customer engaged their Carrier to provide configuration information and the carrier refused!!! Who’s network is this anyway? They played the “security card” and indicated that everything was provisioned and working as expected… After a couple of emails back and forth with the customer and carrier, I explained that this configuration was required for auditing purposes and that a “scrubbed” configuration, that is, a configuration that removes any reference to the carriers own security, would be fine. They still refused. Now I know we will eventually get a copy of the configuration, we just haven’t pushed hard enough yet. Since we have gone through this before, once we pull the compliance card, they will likely give in, but what a waste of everyone’s time.

Our Differentiator:

Like most MSP’s End to End provides a portal, where customers can access statistical information regarding their network and it’s performance. Unlike others however, End to End also provides access to all configuration files. Configurations are captured nightly and saved in our database. Access to scrubbed configurations are provided only to authorized users and they can be compared against previous configurations. In my previous example, access to these configurations would have saved countless emails, telephone calls and about two weeks.

Security appears to be another factor that shy’s IT folks away from Managed Services, but why is it then, that these same IT professionals allow a Carrier to control their Internet Gateway? I have had a lot of experience working with all of the carriers and I can guarantee you that Security is not their strong suit. In fact, I know the “default” password used by most of the Canadian carriers and I know that they never change it!!! Can you imagine this? Does it scare you? It would scare me!

Our Differentiator:

End to End uses RADIUS to control access to all devices that we Manage. This allows us to quickly add and remove user access to all devices that we manage. It allows us to track access by username, and to give customer either read only access or write access in a shared support model, AKA, co-source.

You have your own tool?

Unlike other Network Management tools our eView Portal is completely agent less. There is nothing to install at the customer premises. There is nothing to install anywhere, all we need is network connectivity – SNMP, Ping, SSH, HTTPS. Similar to the Salesforce.com model for CRM the eView portal can be up, Monitoring, Alarming and Capturing your Network in less time than it takes to install a competitor’s product.

Whats Next?

Our development team is working on an exciting new device access method that will truly be the most secure and functional means of network management, flexibility and control. Already in Beta, we expect the first release of this new access method to be in production by Q4 of 2010.

Perhaps you don’t want to outsource your network management and you just need a tool. End to End has already deployed this model to a number of our wholesale partners and as the need grows, the features are growing along with it.

So while the word “Consulting” still makes me cringe, I hope I have helped to convince you that Outsourcing is only a bad word when done by the wrong people.

Network Monitoring and Management (Not just PING anymore)

How times have changed. In the past network management was all about polling or pinging a device to determine if it is alive or reachable. Though this is still a requirement there is so  much more that needs to be done to ensure your network is running optimally. A perfect example of this is the ever popular dual internet circuit scenario. More and more companies today have two internet connections and attempt to utilize both of them by techniques such as load balancing/sharing (see previous post on load sharing).

There are two popular methods that we run into quite often. The first of these being the Multilink connection – where a carrier provides two identical circuits and distributes the load across them equally. In this configuration your network is not completely impervious to failure as you are most likely utilizing the same cable run to reach the carriers POP (point of presence) and you are using the same carrier and any failures within that carrier would affect both circuits. It does however, allow you to maximize the use of the available bandwidth. In this case the traditional method of polling (pinging/SNMP poll) is not good enough. If only one of the circuits go down, the poll is still successful and therefore no alarms are generated. Users may experience slower response, but many times this goes unreported.

The second popular method is utilizing BGP (Border Gateway Protocol). In short BGP can allow you to run in a fully redundant configuration, where the IP Addresses assigned to one circuit will be routed over a second circuit in the event that the first circuit fails. I won’t go into all the details of BGP in this post as it is a relatively complex protocol and requires quite a bit of carrier involvement to deploy. As with the Multilink connection, when one circuit goes down, polling is still successful and no alarms are generated.

This issue in both of these cases is that if the failure goes unnoticed, you are down to having only one circuit, for days, weeks, even months and eventually the second circuit will fail and you will be completely down. Something that you were trying to avoid in the first place.

The solution to both of these is quite simple to deploy and depending on the hardware involved there is certainly more than one method of achieving this. The way in which the circuits have been deployed by the carrier will most certainly determine which of these methods you use.

A very rudimentary method is to poll the WAN interface IP’s of each of the connections from an external source. Do not attempt to do this from inside the network, as it is not guaranteed that the poll with fail when the circuit goes down.  

Using an SNMP management system and enabling traps can be an effective method, provided the hardware supports the generation of  specific traps that can alarm on Route changes, Interface State changes, BGP or Multilink state changes. In many devices traps cannot be limited to forward only the information you require and your management system will get flooded with messages that are of no use. If  traps are not supported on your device or if traps cannot be limited to forward only the information you require look into using SNMP to poll the device for the same type of information.

Be sure to test not just your failover configuration, but the effectiveness of you Monitoring and Reporting system. There is nothing worse than investing in a redundant architecture only to find yourself explaining to your Management team why it didn’t work as promised.

How to determine what is NOT supported!!!

Much of my time is spent researching data sheets and release notes to determine the capabilities of a product and you can learn a lot about the capabilities of the product by reading these documents. However, the most important thing I’ve learned is how to read a document in such a way that you can determine what the product does not support. The vendors of course never tell you what isn’t supported, they tell you what is supported.

This I have found is the most challenging task in product research and without the skill you can find yourself in a difficult position after the product is already sold into the promises have been made. I don’t think this something you can teach but it is something you learn over time after being burned. Who pays for these mistakes? It is certainly not the vendors and it’s not the customer, it is the person responsible for the implementation.

 

Recently after discussing with a new customer requirements for a the firewall VPN URL filtering IPS device [all in wonder box] I did a little research and came up with a solution utilizing a Cisco IOS ISR router. I had thought I had done all my research, but during deployment we ran into some real snags!

First issue: not enough flash to run SSL VPN at IPS concurrently.
Second issue: URL filtering not supported using C B A C- must use zone-based configuration.

In reading through the data sheets for this router I read nothing about the flash limitations on the router that is sold to support SSL VPN and IPS concurrently. A flash upgrade was obviously required but this could not be determined until we had already ran into the issue. For the second issue, I have no one to blame but myself for I just assumed that URL filtering was supported using Cisco’s original IOS firewall technology. Had I done just a little more research I would’ve found the document to talk about URL filtering and how it’s configured in a zone-based firewall deployment. Nowhere does it say that URL filtering is not available using CBAC.

Live and learn as they say. I won’t be making that mistake again but at the rate that technology changes I probably wouldn’t have the opportunity to make that mistake again. I’m sure a new one is on the horizon but I’ll be sure to read all the documents so that I can determine what they have not told me.

Cisco Zone Based IOS Firewalls

It is about time that Cisco came out with this. I was never really a fan of CBAC – it worked but never really gave me the control I desired. Lets hope they add this functionality to the ASA to allow for Interface to Interface Control.

My testing started off with a basic CBAC configuration for a Secure Router connected to the Internet. Once I was happy with the configuration I migrated to a Zone based Configuration and although in the beginning is was a little confusing I soon got the hang of it…. I must admit that in a very large configuration this could get quite complex, but gives you the kind of control you need in todays environment.

Once I had the basic configuration running I was able to implement a more complex configuration and thats where I started to run into some snags…

For now stay away from the nested class-maps – altohugh they work they don’t currently support statistics, so you can’t really see your configuration in action.

WebVPN anyconnect client also isn’t supported (today) as the SSL SVI interface cannot be configured via command line and therefore can’t have a zone added to it. I am told by Cisco that they should have a fix for this in May in the 12.4(24)T2 software.

I really like the ability the Zone Based Firewall gives you of being able to block P2P data and even data embedded inside the HTTP protocol….

Nice work Cisco – keep it up.

Heath