Ansible 2.5 just came out, and with it comes new network modules (and the network_cli and netconf connectivity methods). The new modules allow us to manage certain IOS configurations without always depending on the "ios_config" module, while the network_cli connectivity method means we don't always need to configure a "provider" for every network playbook. These new modules and connectivity methods allow networking configuration management to look and feel similar to our server
A couple years ago I posted how to Optimize Ruckus Configuration, and since then I've been continually tweaking so that my dense, multi-story WiFi environment performs well with Windows, Mac OSX, and mobile devices. Here are my current optimizations:
Note: This is based on Ruckus ZoneDirector 10.0.1.0 build 44
- Channel Optimization: Optimize for Performance. This enables all the 5GHz channels, which is especially useful in a dense environment.
- Self-Healing: Automatically adjust 2.4Ghz and 5Ghz
If you have worked with AWS networking, you know there is a laundry list of items that need to be initally configured so the environment is ready for use:
- Internet Gateway
- VPN Gateway
- Public Subnets
- Private Subnets
- Public Route Tables
- Private Route Tables
- NAT Gateways
- and more depending on your environment
Since AWS is a software defined cloud datacenter, you will get more and more requests for a Prod environment, then Dev environment, then QA environment, then DevOps environment
When executing an ansible playbook, you may get the following error:
An exception occurred during task execution. To see the full traceback, use -vvv. The error was: paramiko.BadHostKeyException: Host key for server switch-name does not match!
This probably happened after you changed the name of your network device, and generated new RSA keys. Or, if you are using DNS device names in ansible, resolve the name of your network device from your ansible server and verify the DNS resolution
On day two of Networking Field Day, Pluribus Networks gave us a rundown on what is possible with their Netvisor OS, whitebox hardware, and a distributed architecture. I was impressed with the flexibility of the solution, but like any design choice, there are some limitations to be aware of.
As a relative newcomer to the Pluribus world, I wanted to know what Pluribus was made of. The answer?
- Whitebox (or Pluribus branded) switch hardware
- Layer 3 connectivity between switches
A couple years ago, my coworker wrote a great post on finding disk space issues in Linux and how to resolve them. Helped me out this weekend when a critical server was having issues, so wanted to post it here:
For future reference (after reading the post above)
Show filesystem usage:
~$ df -h
Show files/directories consuming space:
~$ du -kx / | sort -nr | more
List files in directory:
~$ ls -larth
List and then delete any .log
Note: There is a newer guide for VLAN provisioning with Ansible 2.5
Ansible is such a powerfull tool that it can be easy to get lost in all the possibilities. Running your "network infrastructure as code" with full configs auto-generated and checked into git is the dream, but we can start simple with automating time-consuming tasks. This post will focus on getting ansible up and running with a playbook to configure new vlans across your switches.
This is my first post in a series I'm calling Cisco Config Basics. These posts will serve as a reference for anyone new to Cisco, or those of you just looking to compare your current configs. After the full config, I will explain each config item line-by-line.
In a campus network, the User Port has a lot riding on it - vlan config, security controls, DHCP protection, PoE settings...not to mention new IPv6 policy that is needed even if
Formal verification. Two words unfamiliar to me before Networking Field Day. To provide a brief summary, formal verification uses mathematical proofs to verify a system is working as designed – the same process used to create hacker-proof code. Veriflow has taken this method and applied it to networking to verify the intended design or operation of the network.
But what does this actually mean to us as network operators? Instead of monitoring isolated metrics like an interfaces’ utilization, we can monitor