ask-don-blog
ask-don-blog
Anuta Networks
5 posts
Don't wanna be here? Send us removal request.
ask-don-blog · 6 years ago
Link
Ryan Lynn, VP of Emerging Architecture at Trace-3 discusses the latest in network analytics such as streaming telemetry, machine learning, AI and how network practitioners can get a head-start to deploy them.
In this video, below following topics were covered
1.  Challenges with Traditional Analytics Solutions
2.  About Innovations in Network Analytics
3.  About Streaming Telemetry
4.  About Machine Learning and AI
5.  About Embracing the New Technologies
6.  About Anuta ATOM’s approach to Network Analytics
7.  About the Massively Scalable Anuta ATOM platform
8.  About The Future of Network Operations
If you need to find out more about how Anuta can help you with network assurance and orchestration. 
You can head on over to anutanetworks.com/collective. There you will find lots of great information. Some white papers, case studies and you could even demo the platform for yourself.  
0 notes
ask-don-blog · 6 years ago
Text
Unlock your network's potential with in-depth analytics and meaningful insights
Tumblr media
0 notes
ask-don-blog · 6 years ago
Text
Should you build or buy a network automation solution?
As networks grow in complexity, the demand for automation is ever increasing. Every network architect is looking for ways to eliminate tedious, error-prone manual operations and embrace automation to free time for more value-added activity. From onboarding multi-vendor,  multi-domain devices to monitoring, troubleshooting, and remediating network issues – automation has the capability to revolutionize networking.
When do you require network automation?
Are you excited about an entirely self-driven autonomous smart car?  Probably not. However, you probably appreciate automatic transmission as well as cruise control and other features that facilitate easy driving.  Much like smart cars, the journey towards network automation will be gradual. Are network architects and network administrators ready for a  self-driving network? Possibly, but most architects want some level of control in steering network operations and are unwilling to take the back seat. However, solutions that can automate mundane tasks are overwhelmingly welcomed. In a network world of multi-vendor infrastructure and devices, on-boarding, maintaining configuration, and detecting and remediating compliance violations becomes a daunting task. It is nearly impossible to monitor and troubleshoot a vast network manually or draw any insights given the lack of scalability. Automation tools have been trying to solve this challenge and have been successful in providing some value to the administrators. Tools such as Ansible help you push configuration changes to devices automatically. Netbox,  Github, and others help track configuration drifts, and Python is used to add intelligence into the automation framework. Collected network data can also be stored in open source time-series databases like  Prometheus and Influx, which when integrated with Grafana help provide visibility and insights into the network. While you can get started quickly with these tools and achieve some level of automation, what is required in the long run is a more robust and comprehensive automation solution.
What constitutes a comprehensive network automation solution?
Network administrators and architects have been test-driving various in-house,  open-sourced and commercial automation solutions for quite some time.  While some solutions are low code and easy to deploy, many lack the capacity and scalability for long term needs. On the other end of the spectrum, there are robust offerings equipped with shock absorbing and disaster recovery features, but they require a large footprint and have limited compatibility with only a small subset of vendors. A comprehensive network automation solution automates the complete end-to-end device and service lifecycle. Moreover, it can scale to support a large number of vendors as well as provision devices, collect specific network information, and provide analytics distinct to particular use cases. An easily scalable solution with a small footprint, allows network operators to start small and grow with automation confidence. Constant monitoring of all devices anticipates possible configuration, compliance or other network issues and automatically remediates issues with known solutions. The solution also integrates with ServiceNow, Jira, and other ticketing and billing systems to provide you a complete end to end closed-loop automation platform.
Look before you leap
The first instinct towards automating your network is the confidence that it can be done in-house with standard tools or custom scripting. Some common pitfalls include: Let’s try it ourselves. There is a ton of free automation tools. Many companies have done it internally. We have already automated a part of our network so why should we waste money by buying a packaged solution? While a homegrown automation solution might appear plausible initially, it may be wiser to ask the following questions:
How many automation tools can we learn and handle?  Each tool is specialized in its area – such as Ansible for configuration, Netbox for IPAM, Prometheus for database, and Python for intelligence. Comprehending and maintaining every tool can become cumbersome.
How much integration support do we get?  For a complete closed loop automation integration with ticketing/billing/OSS/BSS are the fundamental underlying requirements.  If the tools do not comprehend these capabilities, is the support readily available or will it have to be built?
How do I develop automation scripts? Developing an automation framework itself becomes a project on its own.  Significant resources will have to be allocated in order to plan for software versioning, maintenance, and upgrades of automation scripts.
How do we handle scripting issues? You have to worry not only about your network but also your script bugs that can adversely impact your automation system. You will have to learn low-level OS integrations to optimally scale scripts.
How many resources can I dedicate towards automation? A project of significant size and scope requires dedicated resources to create and maintain various automation scripts.
How much risk am I willing to take? A  project of this scale may take years to complete. Even then, it may not meet intent or expectations of the lines of businesses that are supported. Are you willing to risk failure?
Will my network get locked to a single vendor?  It’s easy to automate when there is uniformity. If all scripts are tailored towards a particular single vendor, it could become exceedingly difficult to move to other vendors that might bring a best of breed approach for a particular workflow or set of applications.
What happens if key team members leave? This is perhaps one of the most challenging questions to answer. If your key team members that designed and developed the automation system leave  the organization, how could it impact ongoing network operations?
When should you consider deploying a packaged automation solution?
Smaller networks might lend themselves to an internally developed automation solution, but maintenance and future scalability are still risk points.  On the other hand, larger, more extensive multi-vendor and multi-domain networks will benefit greatly from a packaged, microservices based automation solution. The following checklist might provide insight into determining the fit of a packaged solution:
Is there a need to automate more than 500 devices on a given network?
Are there more than 2 vendors in a given network?
Do network operations need to be tied to business operations? I.e. integration of network workflows with ServiceNow/Jira, etc.
Is a single pane of glass desired to manage a given network, or can it be managed with multiple, distributed interfaces?
Is efficient provisioning required to effectively scale an automation framework as a network grows?
Is network enhancement and future proofing a long term objective?
If the answer is yes to any of these questions, consider Anuta Networks ATOM for your network automation needs. Wantto learn more? Visit
www.anutanetworks.com
.
10 notes · View notes
ask-don-blog · 6 years ago
Text
Analytics and Closed-Loop Automation for Ultra Low Latency Networks
A leading financial services provider that delivers real-time information to global banks needed to introduce network analytics and closed-loop automation that delivers capacity management, performance and latency optimization, predictive analytics, network assurance, and SLA compliance.
Anuta Networks Overview
Anuta networks, we’re based in San Francisco Bay Area with customers and partners worldwide. Some of our leading customers as you can see here, very large Telcos and enterprise customers all over the world. And what we offer is called closed-loop automation that delivers orchestration, analytics, and telemetry for multi-vendor networks. We support 45 different vendors, and we orchestrate and automate networks across multiple domains whether it’s your data center, Campus, branch, the MPLS core network, and the SD-WAN as well.
Customer Profile & Requirements
So the case Sturdy today is about a financial services customer. They deliver financial news – stock data, as well as disclosure data to their customers and their main challenges, is about delivering this financial data within milliseconds to their customers. And their network engineers said “our network is a slave of the applications. Whatever the application wants, the network has to respond within milliseconds.” So they want to implement real-time network analytics, and they want to make the network very responsive to the application demands, and they want to do this within 500 milliseconds. So we’ll go into details as to how the Anuta’s ATOM is helping him deliver this demand from the applications.
Customer Requirements
So – a little bit more in detail; the requirements. The solution, the automation should be able to collect the data whether its streaming telemetry or traditional SNMP based data. And this all has to be analyzed and has to create reports and notifications within milliseconds. And this has to scale to thousands of devices and millions of interfaces and this has to be stored for more than a year for compliance purposes. And they want to make sure the platform is fully redundant, and there is no single point of failure. And this has to support open standards.
Analytics and Closed-Loop Automation: Interface Flapping
So the solution we offer as I said is closed loop automation. It’s best to explain using an example, let’s say you can define the baseline behavior for any network. Let’s say you’re looking at the interfaces – you can say I don’t expect this interface to flap more than two times in a day. Now you can define what you mean by that metric and how you want to collect it and how frequently you want us to monitor it.
And then the correlation engine is comparing the current behavior with the baseline behavior and based on the various deviations that are happening; it can automate the corrective actions. So for example, if the interfaces are flapping once or twice in an hour, you can open it as a ticket in a Service Now system. But if it’s like excessive flapping, then you can immediately shut down that interface. So we can introduce automatic remediation that works across multiple vendors using a workflow engine, and we can also integrate with tools like Grafana so we can visualize all the metrics and generate reports and compliance reports as well.
Anuta ATOM Architecture
This is a bit of detailed slide. It tries to explain how we achieved this. The ATOM platform is composed of many microservices. All of these are Docker containers. They provide individual functionality like discovering the devices, building the topology, collecting the telemetry data, creating a service chain across multiple vendor devices as well as delivering analytics and visualization of the network infrastructure. We integrate with 45 different vendors – all the leading vendors: Cisco, Arista, F5, Citrix, Juniper – you name it. We have it. All the networking related devices we can configure either using CLI, NETCONF, API or REST as well. And all of this data is stored in a time series database with which you can query their data and generate all kinds of reports. And we use kubernettes to manage the various Docker containers within the ATOM platform, so these can be deployed on-prem, or these can be deployed in public clouds like AWS and Azure as well.
Deployment Architecture
So here is the customer deployment – as you can see it’s a fully redundant design. They have multiple data centers – The two instances of the ATOM are synchronizing with each other. The policy data, as well as the times series data, is constantly synchronized so that you have a fully redundant design. And we will go through a short demo of how this whole integration looks like.
Device Onboarding and Topology
So let me switch to the demo. This is a recorded demo so I’ll try to pause it so you can follow along. So first we are going to show a dashboard of all the devices. We then discovered the devices; we can see the various devices, and the config and the ATOM is sucking up all the configuration data from all these vendors, and it normalizes it into a JSON object. So now it builds a topology of your network – it creates this concept of resource pools, and you can look into details of each of their devices. As you can see it overlays operational data on top of this topology. So that gives you full visibility into your entire geographical distribution.
Configure Pre-defined Telemetry Sensors
And then we are configuring telemetry data, the sensors – on this case we are configuring the interface statistics metric on the Cisco IOS-XR. You can decide exactly which data you want from this particular IOS. We are looking for interface status stats, and we can push this config across hundreds of devices. Now from a single GUI, you are configuring the Arista, the Cisco, the Juniper and ATOM will go through a workflow engine. It’s going to show you now the model that it is going to push to the device. As an operator, you can look at the model and verify that everything is working correctly and you can approve it and schedule to push this config at any particular time.
So once it is approved the ATOM is going to auto-generate the commands for various devices whether it’s the Cisco or Arista or Juniper as you can see it’s going to show you the Cisco CLI that it is going to push to the devices. Now the devices start sending that telemetry data to the ATOM platform. And you can see the data in the Grafana dashboard. So here we collect various metrics like interface Utilization and CPU utilization, interface drops and things like that – the dashboard is highly customizable, you can build your own reports and have different alerts created out of it.
Latency Results
And because this customer is so particular about the latency, we have collected the latency within the ATOM platform. You can see that in 26 milliseconds we are able to take the network state like something happens on the network and that data will be stored in the database for applications to access within 25 milliseconds. That’s the kind of latency we are dealing with. The ATOM platform optimizes the overall end to end latency by using the latest software stack, and it works across multiple domains. So it’s a really short demo.
Anuta ATOM Delivers
The main takeaway is that the ATOM platform is able to meet the latency requirements and help the customer deliver very fast and responsive networks that are working across multiple vendors and that has a very fully redundant design using open standards.
Why Anuta ATOM?
So here is the final slide – as you can see, the ATOM scales to millions of devices using micro services-based architecture. It introduces closed-loop automation that delivers analytics, remediation, monitoring as well as orchestration for multi-vendor infrastructure. And it also can be deployed on-prem or in the public cloud like AWS and Azure.
Additional Resources
You can check out the website Anuta Networks for more case studies as well as datasheets. Thank you.
0 notes
ask-don-blog · 6 years ago
Text
Should you build or buy a network automation solution?
As networks grow in complexity, the demand for automation is ever increasing. Every network architect is looking for ways to eliminate tedious, error-prone manual operations and embrace automation to free time for more value-added activity. From onboarding multi-vendor,  multi-domain devices to monitoring, troubleshooting, and remediating network issues – automation has the capability to revolutionize networking.
When do you require network automation?
Are you excited about an entirely self-driven autonomous smart car?  Probably not. However, you probably appreciate automatic transmission as well as cruise control and other features that facilitate easy driving.  Much like smart cars, the journey towards network automation will be gradual. Are network architects and network administrators ready for a  self-driving network? Possibly, but most architects want some level of control in steering network operations and are unwilling to take the back seat. However, solutions that can automate mundane tasks are overwhelmingly welcomed. In a network world of multi-vendor infrastructure and devices, on-boarding, maintaining configuration, and detecting and remediating compliance violations becomes a daunting task. It is nearly impossible to monitor and troubleshoot a vast network manually or draw any insights given the lack of scalability. Automation tools have been trying to solve this challenge and have been successful in providing some value to the administrators. Tools such as Ansible help you push configuration changes to devices automatically. Netbox,  Github, and others help track configuration drifts, and Python is used to add intelligence into the automation framework. Collected network data can also be stored in open source time-series databases like  Prometheus and Influx, which when integrated with Grafana help provide visibility and insights into the network. While you can get started quickly with these tools and achieve some level of automation, what is required in the long run is a more robust and comprehensive automation solution.
What constitutes a comprehensive network automation solution?
Network administrators and architects have been test-driving various in-house,  open-sourced and commercial automation solutions for quite some time.  While some solutions are low code and easy to deploy, many lack the capacity and scalability for long term needs. On the other end of the spectrum, there are robust offerings equipped with shock absorbing and disaster recovery features, but they require a large footprint and have limited compatibility with only a small subset of vendors. A comprehensive network automation solution automates the complete end-to-end device and service lifecycle. Moreover, it can scale to support a large number of vendors as well as provision devices, collect specific network information, and provide analytics distinct to particular use cases. An easily scalable solution with a small footprint, allows network operators to start small and grow with automation confidence. Constant monitoring of all devices anticipates possible configuration, compliance or other network issues and automatically remediates issues with known solutions. The solution also integrates with ServiceNow, Jira, and other ticketing and billing systems to provide you a complete end to end closed-loop automation platform.
Look before you leap
The first instinct towards automating your network is the confidence that it can be done in-house with standard tools or custom scripting. Some common pitfalls include: Let’s try it ourselves. There is a ton of free automation tools. Many companies have done it internally. We have already automated a part of our network so why should we waste money by buying a packaged solution? While a homegrown automation solution might appear plausible initially, it may be wiser to ask the following questions:
How many automation tools can we learn and handle?  Each tool is specialized in its area – such as Ansible for configuration, Netbox for IPAM, Prometheus for database, and Python for intelligence. Comprehending and maintaining every tool can become cumbersome.
How much integration support do we get?  For a complete closed loop automation integration with ticketing/billing/OSS/BSS are the fundamental underlying requirements.  If the tools do not comprehend these capabilities, is the support readily available or will it have to be built?
How do I develop automation scripts? Developing an automation framework itself becomes a project on its own.  Significant resources will have to be allocated in order to plan for software versioning, maintenance, and upgrades of automation scripts.
How do we handle scripting issues? You have to worry not only about your network but also your script bugs that can adversely impact your automation system. You will have to learn low-level OS integrations to optimally scale scripts.
How many resources can I dedicate towards automation? A project of significant size and scope requires dedicated resources to create and maintain various automation scripts.
How much risk am I willing to take? A  project of this scale may take years to complete. Even then, it may not meet intent or expectations of the lines of businesses that are supported. Are you willing to risk failure?
Will my network get locked to a single vendor?  It’s easy to automate when there is uniformity. If all scripts are tailored towards a particular single vendor, it could become exceedingly difficult to move to other vendors that might bring a best of breed approach for a particular workflow or set of applications.
What happens if key team members leave? This is perhaps one of the most challenging questions to answer. If your key team members that designed and developed the automation system leave  the organization, how could it impact ongoing network operations?
When should you consider deploying a packaged automation solution?
Smaller networks might lend themselves to an internally developed automation solution, but maintenance and future scalability are still risk points.  On the other hand, larger, more extensive multi-vendor and multi-domain networks will benefit greatly from a packaged, microservices based automation solution. The following checklist might provide insight into determining the fit of a packaged solution:
Is there a need to automate more than 500 devices on a given network?
Are there more than 2 vendors in a given network?
Do network operations need to be tied to business operations? I.e. integration of network workflows with ServiceNow/Jira, etc.
Is a single pane of glass desired to manage a given network, or can it be managed with multiple, distributed interfaces?
Is efficient provisioning required to effectively scale an automation framework as a network grows?
Is network enhancement and future proofing a long term objective?
If the answer is yes to any of these questions, consider Anuta Networks ATOM for your network automation needs. Wantto learn more? Visit
www.anutanetworks.com
.
10 notes · View notes