Python is the programming language to learn if you are a Network Engineer. It’s just one of the new skills you’re going to need to stay relevant and to be more than just a simple worker that adds no value beyond basic config.  

With Python scripts you can repeat complex tasks in exactly the same way as many times as you like. You can build in variations so that the same job is dynamic when the need arises. For example you could deploy 20 access layer switches with identical configuration except each might have a unique management IP address. Think of the benefits of this type of automation at scale - 1000 switches by CLI is asking for trouble with misaligned configuration and it’s just down right inefficient use of time.

Old school engineers would promote Perl for network scripts and automation - but its old school, less popular and harder to read. Python, as I understand it, can do anything Perl could do and is a much more accessible language in that it’s easier to read and begin working with.

The use cases for scripting or programming will extend far beyond just replacing the legacy technique for the same tasks we perform today. The network is full of useful data that can be extracted for use elsewhere or to help inform the decisions for design tomorrow. All good technology products or services should contain an API which is a very easy way to have Python scripts interact with devices and software. Aruba Networks have released ArubaOS-CX on a core/aggregation switching platform that will allow Python scripts to run right on the switches. The analytics and automated troubleshooting capabilities show huge promise.

​I’ve been learning Python to perform some work in real life scenarios. If you can do it that way, like with most learning opportunities, you will be able to make better associations with the new skills you learn with the benefits of those skills in hobbies and work.

Along the way I have been posting examples of my work in the Aruba Airheads Community, they are relevant to the Aruba Meridian solution.
Using the Meridian API: Output Beacons info to CSV
Using the Meridian API: Checking Beacon Battery Levels
Using the Meridian API: Storing the JSON Output (Local Caching)
Using the Meridian API: Caching Beacons Data in a file
Using the Meridian API: Caching Maps Data in a file

The posts include python files and a step by step break down describing the lines of programming so you can learn how they work. My hope is someone might either make use of the python scripts in their entirety or be able to use sections (or particular functions) for their own projects.

There are so many resources around to help you to get started with Python. If you’re using a MacOS X as your computer operating system then Python is even pre-installed. There are countless books and paid or free online tutorials and courses. Now is the time to get some experience, see if there is any way you could take one of your current tasks and include a bit or Python training in to it.

If you read this post by Steven Iveson in April 2013 you might feel a bit late to the game. There is no time like now to start. https://packetpushers.net/programming-101-for-network-engineers-why-bother/

Search the web for "python for network engineers" and you'll come across countless Udemy courses and other sources. Let me know if you find any good ones.

Today I am sitting in on the first Asia Pacific #WiFiDesignDay - kindly brought to Sydney, Australia by @ekahau. Here is a brief play by play as it runs...

Mark Krischer from Cisco kicked off the day of guest presentations explaining the fundamentals of RF. The key take away was revealed nice and early. “You have two levers” which are increasing signal and reducing noise. This is a great lesson for newcomers to the WiFi space but equally important as a reminder to old-hats. To the new comer it creates new questions about how you might go about achieving positive outcomes with these levers. For old hats it should keep their minds wizzing around the concepts and realities of what these levers truly encompass.

Matt Fowler (Mist) Discussed A.I. I’m not a fan of using the term A.I. to-date because it simply is a misnomer in the context it’s used. To be fair he also spoke a lot of Machine Learning which is actually the technology being implemented today (and called often wrongly labelled A.I.). It was great to see where Machine Learning can, Will and does improve our Wi-Fi networks and the workflows of those managing Wi-Fi networks.

Jim Steinbacher from WatchGuard talked us through the present day threats and reality of hacking WiFi. The climax of Jim’s presentation was when he admitted he had been running a Karma attack using a discreetly placed Wi-Fi Pineapple. Jim was able to demonstrate how the attendees clients were sharing too much as he listed off the SSIDs many thought were private at their homes. It was cool to see the disbelief across the room. A lot of the attendees were initially stumped as to how this was happening.

Having Keith Parsons (WLAN Professionals) in town was a treat. These days Keith comes to Australia a lot more than he used to to run various training courses (ESCE and CWNA). Keith started by encouraging those in the room who weren’t on Twitter or blogging to start both today. It was the classic hands up to solemnly swear they’ll get on it.

Then Keith got to the meat... He explained that WiFi is working, even when the experience is bad.
Keith showed the group that a system can be brittle if you don’t follow design rules. His analogy was brilliant, utilising LEGO and a simple set of requirements. What a great introduction. Keith is a master of story telling - and this is why you should do whatever it takes to go and sit in on one of Keith’s training courses. Even (if not especially) if you think you know it all about Wi-Fi.

More to come after lunch...

Aaron Scott (Aruba) has been spending a lot of time designing and overseeing the installation of a sports stadium in Sydney. He shared today some of his experiences on this project. After overcoming some extreme voice attenuation caused by a massive flame-red beard Aaron kicked off by outlining the great variation in requirements across the different areas and user scenarios in a stadium (from Media personnel to spectators lining up for food). Not everyone will have the pleasure of designing Wi-Fi for a stadium but a lot of the theory that goes in to planning this type of environment can be very useful across other designs. Aaron explained a method to calculating the total system throughput which can aid the backhaul planning requirements wired and Internet connectivity.

From multi-stage stadium deployments (over years) to half covered, half non covered stadiums - Aaron has met many challenges which had to be overcome. Cost considerations and engineering experiences were great insights throughout the presentation.

The day’s formalities were finalised with an expert panel prepared to answer the toughest attendees questions. Matt Fowler, Aaron Scott, Stephen Cooper, Keith Parsons and Jussi Kiviniemi sat up front and shared knowledge and opinion about:

• LTE-U as a threat to Wi-Fi
  • Keith reminded the room that LTE-U is NOT the same as 5G
  • He also stated that it poses a great threat to Wi-Fi and that carriers are only interested in ARPU aka Average Revenue Per User
  • LTE-U has the potential to completely overwhelm the frequency we currently have available for Wi-Fi
• 6GHz as an unlicensed Wi-Fi spectrum (more than 1 GHz of channel)
  • The FCC could possibly have auctioned that spectrum off for half a trillion dollars, but they saw the economic benefit of making it free
  • This frequency is not available for use in Australia or New Zealand to date
• Packet Captures to deeper understand issues
• Further standards to simplify client behavior
• Shaving minimum basic rates, check retry rates
  • Keith explained at pace how you can use WireShark to grab the key data from a packet capture. MetaGeek’s Eye PA, OmniPeek can all help to show this data. MCS, Data Rate and Retry rates are all valuable knowledge.
• Will 802.11ax help in high density designs? Should we drop backwards compatibility?
  • The PHY is referred to as High Efficiency
  • .11ax will bring better efficiencies of airtime use, but it is reliant on client capability
  • We aren’t efficient today because we have to be backwards compatible. Two preambles are required today for VHT packets. People are lobbying for the dropping of backwards compatility  6GHz space.
• Will Wi-Fi Alliance (WFA) test interoperability testing for roaming?
  • The practicality of this was questioned. Roaming is highly proprietary.
  • Is there a benefit to the WFA? 
• Is there anything exciting you would like to see come from the industry?
  • Jussi wanted to see 60GHz hit the indoor space for high throughput. Surprising the only vendor to do this in the enterprise space was Aruba with an outdoor point to point AP.
  • 60GHz is covered by 802.11ad and 802.11ay. The latter may have more benefits indoor according to Stephen.
  • Matthew is excited about complementary technologies including BLE or gateway type devices. Analytics and health data communicated by API out of the WiFi system in to other systems.
• Will we see a new standard that allows us to move away from the pre shared key?
  • Maybe, but we’re stuck with it for a while (Jim)
• Will we see tri-radio chipsets or clients?
  • This is largely outside of the decision making of the AP vendors as they use third party chips. It’s about waiting and seeing what comes.
  • You are good to survey for .11ax with your sidekick because .11ac chips are good at this
• Can we do something within the wireless network to help overcome the difficiencies of Internet (think nbn) here in Australia?
  • Knowledge sharing and use of tools to prove that these issues are not occurring at the WiFi. 
  • Keith says the worlds beat WiFi looks terrible with the worlds worst backhaul. WiFi is simply a transport for these other services. We cannot do anything on WiFi to improve the experience of bad backhaul.
• Can we help the end user troubleshoot and understand where in the infrastructure issues exist?
  • Jussi hinted that he cannot comment on roadmap! Yay!
  • Then we heard a tip about an Easter egg in the Ookla speedtest app
  • A reminder to mark QoS appropriately throughout the link.
• What benefits does WPA3 bring?
  • Vendors need to better work together.
• Could you use Cloud check to better understand the link?
  • Cloud check is good, but not a trustable data. But it does provide assistance in understanding the ratio between local vs internet traffic.
  • The use of some of Adrian Granados tools can help too.
• Can things like 802.11k or vendor proprietary roaming “fixes” help?
  • Focus on the basics first. Channel and transmit powers can have an enormous effect on roaming.
  • Clients must be capable of using .11k v or r and then the way that is implemented may different between client types.
  • Seperate band SSIDs can reduce these issues.
• Thoughts on Single Channel Virtual Cell?
  • There is a certain amount of frequency space and air time and a limitation of bits that can be sent within those realms. But roaming can be fantastic with this type of design.
  • A representative from Fortinet spoke and stated that the roaming decision is taken away fro the client, roaming can go down to as fast as 3ms. It’s not utilised in high density scenarios.
  • Keith said it’s a really neat trick for roaming but as long as you are under the capacity of a single channel.

There is an Easter Egg on the iOS version of the Ookla Speedtest app. Hold down the Go button for a long period of time until your phone starts vibrating.

Then there was Beer! Thanks for following along.