As it often happens, everything begins with a call from a customer with a problem. The problem is related to WiFi roaming in a warehouse with clients disconnecting from RDP sessions. The clients are industrial PCs installed on forklifts that move quite fast (and dangerously). Second rule of troubleshooting: measure As the first rule is clearly identify the problem, I skip to the second one. How can we measure roaming problems?
Scripts, usually I write some because I don’t like repetitive tasks and I’m lazy, meaning I prefer automation over useless hard work. Don’t know where I found this quote but I like it: Don't spend your time doing work a well-trained monkey could do. Today’s request was quite simple: get model and serial number from a bunch of Cisco switches. I now NEDI , Observium and LibreNMS can do that but I preferred to write a quick script I could use as a one shot tool instead of a complete software solution.
When you see an hacker movie you see people typing on the keyboard very fast. Actually the toughest the hacker is the faster he types very long commands and all of them work the first time. Want to impress friends and colleagues? Type on the hackertyper ;-) More experienced network engineers, as I learned during my CCIE studies, type in a text editor then copy/paste on the CLI. This approach make easier to spot typos, faster to reuse configuration snippets and to change portions of configuration.
Quite often I have to debug a wireless client roaming across lighweight Cisco APs to confirm it moves between APs as expected in the network design. On the WLC the command is “debug client MAC”. The command shows all the events related to the specific client including: Reassociation received from mobile on AP 00:23:ab:ba:YY:XX that means client moved to the AP with radio MAC 00:23:ab:ba:YY:XX. Since I’ve named all the APs and and I’ve a map with all the positions, I’d like to see the names in the debug instead of MAC.