As an experienced Cisco network engineer, you have often saved yourself from being locked out of a router when you make a change with a “reload in x” command. This handy command reboots most Cisco devices (routers, switches, firewalls) in the x number of minutes that you had specified. Thus, if you made a change that killed your connection to it, then you just have to wait until the time expires and the device reboots back up with the last saved configuration, allowing you to reconnect and remove your palm from your forehead.
Recently, I have been working to upgrade Cisco network devices, mainly routers and switches, for a client. A recent network audit identified fragmentation in the IOSes and also security advisories. As a result, all the routers and switches required upgrades and it was a good opportunity for the client to standardize the IOSes for the different type of network devices in the environment.
Have you ever found yourself in a position where throughput between devices, either local or across a WAN, seemed lower than expected? You may start by checking the configuration and logs on the network devices along the path, hoping to identify something out of the ordinary or unusual. Often a smoking gun isn’t immediately identifiable which then requires a coordinated approach to troubleshooting and narrowing down the potential causes. This write-up aims to provide some of the practices and tools I’ve used in similar situations.
Hello, my loyal blog post readers, in this my third installment of our SD-WAN series I am going to walk you through how our vEdge router locates, communicates and authenticates itself onto our SD-WAN fabric. Along the way we will take a look at a few packets captures and command line output to see what is going on under the hood.
Subscribe to the informative Newsletter to be Notified Updates in the Technology world.