According to one of the latest Gartner reports, only 5% of responders automate more than 50% of network engineering tasks. It seems that network automation has still a long way ahead to be fully embraced and become a vital part of any anchored strategy. It seems that for the majority of tasks in the network operations teams, the very first step is still waiting ahead - the data collection.
Every network automation process starts with data collection. That's all it takes to begin! It helps to kickstart the thought process, because why should anyone collect any data manually if the intent is to automate while using those data? And this mindset is important!
Before any automated change, we need to understand the network behavior so we can virtually simulate our intended impact. The most common tools for automation are Python scripts, Ansible, Jenkins, Netmiko, SaltStack, and more. But no matter what tool is used, the main goal remains:
The data collection process is an automation process with dilemmas on its own. It prevents many teams from starting the automation journey and the more complex the environment is, the more complex the first step is. The vendor diversity avoids the vendor lock, but it adds another layer of complexity. But it shouldn't be that way! If you ever wonder what the automation process may look like when the very first step is completely taken care of, then you are in the right place. The IP Fabric does exactly that. The data abstraction layer is all it takes to overcome this first step.
Juniper MIST is a cloud-based management service for Juniper devices including wireless APs. It can manage even standard “Junos” devices like SRX firewalls or EX switches that are already supported in IPF - the main benefit is that it brings Juniper wireless APs support to IP Fabric.
Like Meraki or Ruckus even MIST, the API doesn’t provide all the required details that we can get directly from the device via CLI (SSH/Telnet). From the API, we are not able to collect ARP or usable STP information for the path simulation process. The topology maps will be limited but will be available if IP Fabric discovers the switches that connect MIST Wireless APs (and if LLDP is enabled).
We had to limit the scope of MIST-based discovery to only wireless APs, otherwise, we could end up discovering e.g. SRX firewall via MIST which would result in overwriting data discovered via SSH.
The Ruckus Virtual SmartZone is an NFV-based and cloud-ready WLAN controller for service providers and enterprises ready to elevate their WLAN deployment to the next level of flexibility, resiliency, and scale. For IP Fabric, it is a new supported vendor discovered over API. Ruckus API is used to discover wireless access points and clients. (There is also the possibility of discovering switches, but it has not been tested in our environment yet).
Cisco is leaving VSS technology and moving towards StackWise. StackWise Virtual (SV) combines two switches into a single logical network entity from the network control plane and management perspectives. It uses Cisco IOS® Stateful Switchover (SSO) technology, as well as Non-Stop Forwarding (NSF) extensions to routing protocols, to provide seamless traffic failover when one of the devices fails over. To neighboring devices, a StackWise Virtual domain appears as a single logical switch or router.
We are adding support for StackWise Virtual which is an extended replacement for VSS on some newer Catalyst 9K family switches.
With different types of licensing for Cisco products, we have had a certain amount of requests to collect data to help our customers to get better oriented. Starting version 4.4.0, we are now collecting information about Cisco licensing with the new IP Fabric task. The primary command is 'show license (all)', which provides enough information about standard or smart license data. As a result of the new command, we have two new sections under Technology > Management: License and Smart License.
IP Fabric development effort around public or private cloud intensifies. In a traditional environment, servers and the network are usually two separated entities in terms of management. To successfully gather information about servers, you need to log in and get it, there's no way to collect it from the gateway (except for ARPs, MACs, and DNS records). That doesn't apply to the cloud. In general, public or private clouds' APIs provide more information about virtual machines. On the other hand, they might not provide network-level information we use for hosts calculations (ARP, MAC table).
That's why we decided to provide new tables with detailed information about cloud virtual machines including their interfaces. More at Technology > Cloud.
If you have found this article helpful, please follow our company’s LinkedIn or Blog, where more content will be emerging. If you would like to test our solution to see for yourself how IP Fabric can help you manage your network more effectively, please schedule a demo with our team: Request a Demo.
According to one of the latest Gartner reports, only 5% of responders automate more than 50% of network engineering tasks. It seems that network automation has still a long way ahead to be fully embraced and become a vital part of any anchored strategy. It seems that for the majority of tasks in the network operations teams, the very first step is still waiting ahead - the data collection.
Every network automation process starts with data collection. That's all it takes to begin! It helps to kickstart the thought process, because why should anyone collect any data manually if the intent is to automate while using those data? And this mindset is important!
Before any automated change, we need to understand the network behavior so we can virtually simulate our intended impact. The most common tools for automation are Python scripts, Ansible, Jenkins, Netmiko, SaltStack, and more. But no matter what tool is used, the main goal remains:
The data collection process is an automation process with dilemmas on its own. It prevents many teams from starting the automation journey and the more complex the environment is, the more complex the first step is. The vendor diversity avoids the vendor lock, but it adds another layer of complexity. But it shouldn't be that way! If you ever wonder what the automation process may look like when the very first step is completely taken care of, then you are in the right place. The IP Fabric does exactly that. The data abstraction layer is all it takes to overcome this first step.
Juniper MIST is a cloud-based management service for Juniper devices including wireless APs. It can manage even standard “Junos” devices like SRX firewalls or EX switches that are already supported in IPF - the main benefit is that it brings Juniper wireless APs support to IP Fabric.
Like Meraki or Ruckus even MIST, the API doesn’t provide all the required details that we can get directly from the device via CLI (SSH/Telnet). From the API, we are not able to collect ARP or usable STP information for the path simulation process. The topology maps will be limited but will be available if IP Fabric discovers the switches that connect MIST Wireless APs (and if LLDP is enabled).
We had to limit the scope of MIST-based discovery to only wireless APs, otherwise, we could end up discovering e.g. SRX firewall via MIST which would result in overwriting data discovered via SSH.
The Ruckus Virtual SmartZone is an NFV-based and cloud-ready WLAN controller for service providers and enterprises ready to elevate their WLAN deployment to the next level of flexibility, resiliency, and scale. For IP Fabric, it is a new supported vendor discovered over API. Ruckus API is used to discover wireless access points and clients. (There is also the possibility of discovering switches, but it has not been tested in our environment yet).
Cisco is leaving VSS technology and moving towards StackWise. StackWise Virtual (SV) combines two switches into a single logical network entity from the network control plane and management perspectives. It uses Cisco IOS® Stateful Switchover (SSO) technology, as well as Non-Stop Forwarding (NSF) extensions to routing protocols, to provide seamless traffic failover when one of the devices fails over. To neighboring devices, a StackWise Virtual domain appears as a single logical switch or router.
We are adding support for StackWise Virtual which is an extended replacement for VSS on some newer Catalyst 9K family switches.
With different types of licensing for Cisco products, we have had a certain amount of requests to collect data to help our customers to get better oriented. Starting version 4.4.0, we are now collecting information about Cisco licensing with the new IP Fabric task. The primary command is 'show license (all)', which provides enough information about standard or smart license data. As a result of the new command, we have two new sections under Technology > Management: License and Smart License.
IP Fabric development effort around public or private cloud intensifies. In a traditional environment, servers and the network are usually two separated entities in terms of management. To successfully gather information about servers, you need to log in and get it, there's no way to collect it from the gateway (except for ARPs, MACs, and DNS records). That doesn't apply to the cloud. In general, public or private clouds' APIs provide more information about virtual machines. On the other hand, they might not provide network-level information we use for hosts calculations (ARP, MAC table).
That's why we decided to provide new tables with detailed information about cloud virtual machines including their interfaces. More at Technology > Cloud.
If you have found this article helpful, please follow our company’s LinkedIn or Blog, where more content will be emerging. If you would like to test our solution to see for yourself how IP Fabric can help you manage your network more effectively, please schedule a demo with our team: Request a Demo.
