It’s 2:15am. You are tucked away in your bed and sweetly dreaming of fruity coconut drinks and a beach in the South Pacific. Somewhere, out there, gremlins are targeting your network. And just like that, your fruity coconut drink turns to sadness and your beach melts away in a rain of bitter tears.
In this last installment of this four-part series, we take a look at Aruba Network Analytics Engine (NAE) and NetEdit working in tandem to tackle a thorny connectivity failure.
Houston, we have a problem
In a traditional network, when something bad happens, like losing connectivity to a critical endpoint, savvy engineers rush to their computers, SSH into a bunch of devices and start issuing commands right and left and center. Something like this list:
- ping
- traceroute
- show interface
- show interface transceiver
- show lldp neighbor-info
- show spanning-tree
- show vlan
- show ip route
- show ip ospf
Of course, this list goes on and on, and the same command might be issued multiple times, but for an everyday engineer in a traditional CLI-based environment, troubleshooting a connectivity issue means a painful process of issuing command after command, staring at the output in hopes of gleaning some clues as to what went pear-shaped, and repeating the process on every device in the network.
With NAE and NetEdit on Aruba CX switches, engineers have two powerful intelligent aids to get to the root of a problem and get to a fix, fast. Let’s walk through how NAE and NetEdit tag-team a connectivity failure.
Springing into Action: NAE and NetEdit
Within seconds, NAE will detect the outage. NAE will respond by noting the time and date of the outage, as well as the interface and device. NAE can also snoop the traffic to gather important clues about the nature of the outage. Alerts go out immediately by email, Slack, or any other ITSM tool.
Here’s a look at the dashboard of one NAE monitor. This one monitors OSPF health. Right away, you can see this monitor has detected a status change and that an OSPF adjacency has gone from P2P to down.
Aruba NAE alerting on a change in OSPF status.
Drilling deeper by clicking on the alert, you get the exact time and date of the outage, and the interface, device and VRF that is the source of the alert.
NAE pinpointing the interface, device, and VRF that is the source of the alert. You can also see that NAE has identified the problem as a change in status from P2P to down to DR Other.
On the other side, NetEdit subscribes to the NAE agent and can correlate the telemetry to changes in configuration. Of course, if NetEdit was used to make the change in the first place (in this case from network type P2P to broadcast), it would raise all sorts of red flags. If you were foolish enough to make the config change despite NetEdit’s warnings, it (probably) won’t tell you “I told you so” when you use it to rollback your mistake.
Closing the loop, let’s say the config change was made locally. In this case, NetEdit isn’t going to be able to catch it pre-implementation, but NAE will catch it when the adjacency drops. In comparison to traditional CLI-based troubleshooting, the intelligence built into NAE and NetEdit takes most of the heartburn out of troubleshooting and reduces troubleshooting time from days and hours to mere moments.
I hope you have enjoyed our exploration into Aruba’s better mousetrap—the CX switching portfolio featuring ArubaOS-CX.
Keep learning... Just for Fun!
Read My Other Blogs
Building a Better Mousetrap: Aruba CX Switches
I Spy with My Big Eyes: Aruba Network Analytics Engine…Just for Fun!
One-Eyed Cats, Ratholes and the Suffering of Engineers: Aruba NetEdit…Just for Fun!
