Skip to main content

Network visualizations

Many moons ago on the Netcordia blog, I read an interesting blog by Terry about useful visualizations. This triggered my thoughts about network visualization.
There are two distinct types of visualizations and I'll provide my opinion about both, i.e. real-time and static. Unluckily, there is no network management vendor who really provides a decent visualization. In reality the best I have seen was dated pre-1995, written as a DOS application by Madge Networks. It provided real-time visualization of source routed spanning tree networks. It was a great tool in troubleshooting problems in token-ring networks, and displayed bubble, stick and lollipop diagrams. (Damned if I can remember the name of the app!)
I have specified two types of visualizations as each serves as different functional requirement. The real-time visualization is useful when the !@#$%^ has hit the fan, and the static visualization is useful to prevent the !@#$%^ from hitting the fan.

Real-time visualizations
The best visualization is RADAR. This type of visualization has been around since WWII, but hasn't found it's way into a network management product. The basic idea is there, see this post about the history of ping, but a product to fully emulate radar in networks has not been done.
Radar as used in air traffic control provides height, speed, direction and location to a controller. The controller also creates on his scope a depth by stipulating the radius being monitored. Importantly, radar does not monitor all aircraft. It sequentially scans the skies.
How does a network radar look:
  • the controller determines the depth by stipulating the maximum latency to a network device that will appear on the scope.
  • the height of the network devices are the aggregated packet / byte count for the designated monitoring period.
  • the speed of the network device is the packet / byte rate at the time of the poll.
  • the location is the IP address which also determines the radius on which the network device appears.
  • the direction of the network device is the direction of the single biggest flow, with the direction being determined by the IP address.
Static visualizations
The best static visualizations are street maps. The routers are the roads, the links are the buildings, the campuses are the office parks, and the traffic load determined the height of the building.
Routers that are directly connected to each other are represented as cross roads.
How does a network street map look like:
  • the width of the road is determined by the router's processing ability.
  • the size of the building is determined by the link's speed.
  • the height of the building is determined by historic traffic load.
  • colour is used to designate topology types.

There is a related blog post, taking the theme further using auralization (visualizations using sound.)

Comments

Popular posts from this blog

Why Madge Networks, the token-ring company, went titsup

There I was shooting the breeze with an old mate. The conversation turned to why Madge Networks which I wrote about here went titsup. My analysis is that Madge Networks had a solution and decided to go out and find a problem. They deferred to more incorrect strategic technology choices. The truth of the matter is that when something goes titsup, its not because of one reason only, but a myriad of them all contributing to the negative consequence. There are the immediate or visual ones, which are underpinned by intermediate ones and finally after digging right down, there are the root causes. There is never a singular root cause for anything but I'll present my opinion and encourage everyone else to chip in. All of them together are more likely the reason the company went titsup. As far as technology brainfarts go there is no better example than Kodak . They invented the digital camera that killed them. However, they were so focused on milking people in their leg

Flawed "ITIL aligned"​ Incident Management

Many "ITIL aligned" service desk tools have flawed incident management. The reason is that incidents are logged with a time association and some related fields to type in some gobbledygook. The expanded incident life cycle is not enforced and as a result trending and problem management is not possible. Here is a fictitious log of an incident at PFS, a financial services company, which uses CGTSD, an “ITIL-aligned” service desk tool. Here is the log of an incident record from this system: Monday, 12 August: 09:03am (Bob, the service desk guy): Alice (customer in retail banking) phoned in. Logged an issue. Unable to assist over the phone (there goes our FCR), will escalate to second line. 09:04am (Bob, the service desk guy): Escalate the incident to Charles in second line support. 09:05am (Charles, technical support): Open incident. 09:05am (Charles, technical support): Delayed incident by 1 day. Tuesday, 13 August: 10:11am (Charles, technical support): Phoned Alice.

Updated: Articles by Ron Bartels published on iot for all

  These are articles that I published during the course of the past year on one of the popular international Internet of Things publishing sites, iot for all .  These are articles that I published during the course of the past year on one of the popular international Internet of Things publishing sites, iot for all . Improving Data Center Reliability With IoT Reliability and availability are essential to data centers. IoT can enable better issue tracking and data collection, leading to greater stability. Doing the Work Right in Data Centers With Checklists Data centers are complex. Modern economies rely upon their continuous operation. IoT solutions paired with this data center checklist can help! IoT Optimi