Remote Communications During A Crisis Can Be Challenging – Some Things To Think About
It doesn’t morph your network into something that fights the bad guy, or hurl cars at the enemy to hold them back, but it does help you use bits and bytes to organize and fortify your network.
I recently took the NMENPIv3 class and it opened my eyes to what Cisco Prime Infrastructure can do. Not everyone wants everything Prime can do however. Another popular industry enterprise Network Management System platform is Solar Winds Orion, which is marketed heavily on the simplicity of setup and ease of use. Naturally, it makes sense to compare the two to see where your value line is drawn.
There are many editions of Prime. For the purpose of this comparison we’ll stick to the version meant for the business enterprise network, Prime Infrastructure.
I’ve always held the contention that most businesses buy a software package because it does one thing they really need, they set it up and then take the Ron Popeil chicken rotisserie approach once the fire on their front porch is out. After all, it’s rare that the company can afford to dedicate people to becoming the product expert. You could Set and Forget either of these options, but you’d be paying a serious premium for something you might otherwise find for free in an open source one-function whirligig.
You’ve seen them all before, so I’m not going to dump another feature chart on you. Instead I’ll try to lay this out in use case terms, leaning towards how each affects your cost of ownership in terms of time and effort.
You’ll find Prime offers all functions in a single installation and the licensing level determines which features are turned on. It’s all there. Solar Winds is modular, so you’ll need an add-on for Network Configuration Manager, IPAM, Netflow, Wireless management and more, along with additional product licensing requirements. Some might argue that both are à la carte though since even under the Cisco licensing plan you’re purchasing a base license for Prime Infrastructure and then by node count for each device you manage. Either way your network isn’t free, so you’ll need to pick a model you can live with.
If you have Cisco One on your support contract, each of those devices are already licensed for Prime.
If we only look at the basics of each platform, you’ll see the commonalities. They both do network discovery, network inventory, configuration backups, UP / DOWN notifications, logging, permissions-based views / dashboards, job scheduling / approvals, and both on-the-fly or scheduled reporting.
Solar Winds Orion is known for being the easy setup product and supports a multitude of vendor products. Along with that comes the potential to overlook some important organizational criteria and get stuck with a very poorly organized inventory navigation problem if one of your objectives is to organize inventory by location. The SNMP location string is an important part of this and something I’ve seen left blank in many cases, or worse, a lot of inconsistent entries that will affect the sorting. Getting this right may entail a lot of installation prerequisite work on your part, and even then a few cycles of tweaking to get it right. I’ve seen some very stylish and intuitive Orion dashboards based on this, and I’ve seen some that took many days to get the hang of navigating it. Otherwise, the standard make / model node sorting in device management is fairly straightforward and the same across all installations.
Location-based organization in Prime Infrastructure is closely tied to the Campus hierarchy you establish after the initial installation and discovery. Floor maps in the Campus hierarchy would directly correlate to the device group location menus in other views. Something they call Civic Location in combination with Google Maps can be used as well. It’s the virtual groups you can build from any of the inventory resources that provides the power of “use flexibility”, without affecting the base inventory. These groups can be used as the basis of a lot of other product features. Port groups made up of router or switch ports across network design boundaries for reporting purposes are a good example. Maybe you want to see performance stats on ISP circuits across all data centers.
Both offer VM options.
Both products support centralized authentication. The difference is that Prime offers canned / templated user / group roles that tie directly into TACACS+ authorization task definitions for device management. This is good for NOC environments where you have an authorization-based hierarchy of roles that extends to the GUI functions. In a nutshell, Prime Infrastructure is very TACACS+ aware. Prime Infrastructure is very suitable for heavily segmented operational groups in a company. The one problem I too often see in existing deployments is everyone logging in with ROOT permissions. Bad idea.
To do this in Solar Winds, you need to define or build the authentication and authorization sets per user / group and would need to understand TACACS+ intimately. This is a bit of a development effort.
A Security Note: When using either Prime Infrastructure or NCM, the service account is what shows up in the device logs as having configured a device although both platforms show the configuration job as belonging to the user. Configuration forensics will always circle back to the management platform to review configuration job ownership. In both Prime Infrastructure and Solar Winds Orion installations, I’ve run across too many times the default user role is Admin, which would negate any backtracking in the NMS.
Network device discovery for both Prime Infrastructure and Solar Winds both need a CLI account and SNMP configuration with ACL entries in each network device permitting them to poll the device and login. Mismatches here are where most incomplete network inventories originate and continue to be a problem over the life of the network.
Backup jobs in Prime Infrastructure are available in the standard licensing and offers dated configuration archive access for review or restoring to a previous config. The tools to do so are very easy to use and can be done from the GUI provided the device is alive and can be logged into by Prime service account. The Network Configuration Manager (NCM) in Solar Winds is required for config backups. Automatic configuration archiving works in both platforms, but the process needs to be manually seeded with a baseline in Solar Winds NCM to get it to work “right out of the box”. The scheduled startup and running configuration difference reporting can take a fair amount of tweaking to get it right, but once you do, it seems pretty smooth.
I find the configuration “diff” interface in NCM is nice though and allows you to create regex exclusions against the comparison to override un-matching OS comments between startup-config and running-configs. You can run diff reports against any of the historical configuration versions in the archive. Differences show up as colored highlighting. Very nice tool.
The importance of knowing your inventory on either platform comes into play when you need to renew your device support contracts at renewal time, or determining your vulnerability based on the latest PSIRTs.
This will separate Solar Winds and Prime Infrastructure pretty quickly.
In Solar Winds, the canned reporting capabilities are full of templates you can apply or roll your own using the Report Manager. However, Solar Winds Orion can’t pull the serial numbers from some Cisco Nexus or UCS devices, so if you have a lot of Nexus devices you might be out of luck. The workaround I could find on Thwack didn’t work for me. You’ll find yourself having to hunt those down to append your reports. You can compare your inventory against the Cisco vulnerability lists using Solar Winds, but it will only tell you if you are vulnerable. It won’t tell you what version to upgrade to mitigate the vulnerability. For this reason, if you use Solar Winds you’ll need to rely on the Cisco Smartnet Total Care portal.
Prime Infrastructure has no problems with this that I’m aware of. There are loads of canned reports to choose from or you can create your own.
Personally, I don’t think either product is a great Netflow platform, but then Netflow specific applications are becoming a product unto themselves lately. Both require remote devices that can send Netflow data of course.
Solar Winds requires the add-on Netflow (software) Module and licensing while Prime only requires the Assurance level of licensing, which also enables a host of other features as a package.
Overall, I’d go with the Netflow reporting and application analysis capabilities of Prime Infrastructure over Solar Winds. What I like most is the ability to create flow templates similar to the way you would do it in a product like AppNetta. Create a flow reporting widget and leave it there for eternity to pull statistics as needed on a network link, traffic flow or whatever you want can be had from the Netflow data specific to that flow set. You can do this for any traffic type sent to Prime from your network devices provided it could see the source and destination flows.
A solid layer 3 network design is required no matter which Netflow reporting platform you use. An expansive layer 2 network diameter will hamper your ability to see the data you really need.
Both are capable of listing performance statistics on APs and wireless devices. Cisco Prime Infrastructure has much more extensive wireless support though. Logging and alerting from the WLC plug into the dashboard widgets with visual alerting levels and incident counts let you drill into device status. The same information can be found in Solar Winds, but you have to dig for it.
What Prime Infrastructure does better than Solar Winds though is heat maps. If you’re a GUI person, then the heat maps can provide just about everything you need from there. Holding your mouse over a client or AP on the floor plan offers detail menus to help you get the info you need from the 360 View. Everything related to that object is visible in one place. In Solar Winds, it’s just a graphic on the floor plan with no context menu.
Client placement or positioning on the floor map is much more accurate in Prime Infrastructure as well. I’ve seen Solar Winds heat maps place clients well outside the bounds of the floor plan. Accuracy here is where a wireless deployment would rely heavily on the deployment being based on a wireless survey. No coverage holes and a client being somewhere within a triangle of wireless cells or a grid of cells is key. Prime wireless analytics can be extended or offloaded using the Mobility Services Engine as well if the utmost in accuracy is critical, especially in security conscious enterprises.
Here’s where the future of networking is going. Cisco is already deploying intelligent networks managed by applications like Prime Infrastructure and APIC-EM. Other than being a management station managing individual devices, I’m not aware of this capability in Solar Winds at this same level.
What Prime Infrastructure does well in the automation realm aside from configuration job scheduling is deployment automation. It contains a complete library of device-specific configuration templates or you can create custom templates. Deployments can be as simple as an ACL change or a full switch configuration. Simple configuration jobs can be performed using Solar Winds NCM as well but doesn’t cover deployment automation.
This is where it gets interesting. Using the Prime Infrastructure device template, you can build a router or switch config and a bootstrap. The bootstrap contains a minimal configuration needed to get the device on its local network while allowing it to reach out to the Prime Infrastructure Plug and Play server or alternatively, APIC-EM. This will even work across firewalls and the internet. The bootstrap can be delivered to remote personnel by email, using a cell phone app, or on a USB stick. They boot the device from a factory default un-configured state to the bootstrap and the configuration built in Prime is automatically installed. The configuration is saved locally and the device is rebooted. This cannot be done at this level of complexity in Solar Winds NCM, only restoring device configurations from backup with a fair amount of chassis staging up front.
This is functionality that’s best suited to environments where you are deploying multiple devices of the same model. For the time invested in building templates, it’s not worth the time for only one or two devices. Deployments of 10 or more are needed before you’re likely to see your return on time investment.
Prime can be used as the management center with APIC-EM as the deployment center, or APIC-EM can be used standalone.
Both can do most of what you need in a Cisco centric network. Even though Solar Winds offers more in terms of vendor coverage, you still need to purchase add-on modules. If you start to scale up in modular functionality comparable to what comes with the Assurance license level in Prime Infrastructure, the price gap starts to close. Kind of like the cable TV subscription add-ons do at home. Before you know it, your recurring costs don’t give you comfort anymore.
Keep in mind that Solar Winds offer an API. I haven’t delved into the functionality in Orion or other modules that can be extended by writing your own APIs, but it might be worth exploring if you have the in-house expertise and enthusiasm. They have a repository on GitHub. If you don’t have the personnel or the time to dig into those sorts of things, then it’s not worth thinking about.
It pays to anticipate your company’s growth trend so you’re not working yourself towards a platform migration when you outgrow your initial investment. We’re really talking about cost and scalable functionality over time. With the advent of tightening security requirements in the form of regulatory compliance, you might need more advanced features. It pays to think ahead a few years.
Comments are welcome, both in agreement or constructive disagreement about the above. I enjoy hearing from readers and carrying on deeper discussion via comments. Thanks in advance!
Remote Communications During A Crisis Can Be Challenging – Some Things To Think About
Need for Speed
Container-Based WAN Monitoring
Nick has over 20 years of experience in Security Operations and Security Sales. He is an avid student of cybersecurity and regularly engages with the Infosec community at events like BSides, RVASec, Derbycon and more. The son of an FBI forensics director, Nick holds a B.S. in Criminal Justice and is one of Cisco’s Fire Jumper Elite members. When he’s not working, he writes cyberpunk and punches aliens on his Playstation.
Virgilio “Bong” has sixteen years of professional experience in IT industry from academe, technical and customer support, pre-sales, post sales, project management, training and enablement. He has worked in Cisco Technical Assistance Center (TAC) as a member of the WAN and LAN Switching team. Bong now works for Tech Data as the Field Solutions Architect with a focus on Cisco Security and holds a few Cisco certifications including Fire Jumper Elite.
John is our CTO and the practice lead for a talented team of consultants focused on designing and delivering scalable and secure infrastructure solutions to customers across multiple industry verticals and technologies. Previously he has held several positions including Executive Director/Chief Architect for Global Network Services at JPMorgan Chase. In that capacity, he led a team managing network architecture and services. Prior to his role at JPMorgan Chase, John was a Distinguished Engineer at Cisco working across a number of verticals including Higher Education, Finance, Retail, Government, and Health Care.
He is an expert in working with groups to identify business needs, and align technology strategies to enable business strategies, building in agility and scalability to allow for future changes. John is experienced in the architecture and design of highly available, secure, network infrastructure and data centers, and has worked on projects worldwide. He has worked in both the business and regulatory environments for the design and deployment of complex IT infrastructures.