Thinking problem management!

A topic that I blocked about, VLANs in the DMZ was taken up both by Ivan Pepelnjak and Colin McNamara . Colin points out that security is more about what is done in the complete path and not at a single point. There are a few extra points I would mention: Data should not be stored in a DMZ terminating incoming external connections. These should be limited to processing. It is a theoretical physical exploit and not a remote one. There has been no major security incident attributed to VLAN hopping as a cause.  After all these years, with cloud and virtualization up to our eyeballs, I wonder if Ivan will admit I was right?

One morning I was driving in to work and was listening to a CD and switched to Radio 702 just before 7. The headline news was about major delays at Johannesburg International Airport (now called OR Tambo) that was caused by a computer problem. Read about what happened here .

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 tre e 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 visualizatio

There are two underlying fundamental problems in Cisco based networks that will always cause them to be the cause of a higher rate of major incidents compared to alternative vendors. The problems are related to the high number of features that the vendor shovels into it's code. The higher the count of features, especially those that are unused, the higher the potential for faults. Additionally, unlike JUNOS , IOS does not have a single linear code versioning methodology. This results in deployment and configuration issues. Nearly, 14 years ago, I learnt the benefits of a single linear code versioning methodology from Madge Networks adapter software, called LAN Support Software (LSS). Although, there were ISA, MCA, PCI and EISA adapters they were all supported by the same single version of LAN Support Software. This had a great impact on reducing the rate of major incidents, a lesson which Cisco still needs to learn. These are the benefits of LSS in which IOS has no relat

Many moons ago I was reading Terry’s blog when he was at Netcordia, where he posted about auralization which reminded me about my own experiments in using voice for monitoring a network. Not strictly auralization, but stay with me. A few years ago, I created a monitoring system based on Suse and using Argus . I created a call me system using text to speech and Openh323 . The voice integration was driven using an old Radvision H.323 gateway that Madge OEM'ed way back in the 90s. What this monitoring system did was phone me at a designated number and tell me in an automated voice message what the problem was. No SMS or pager bull, just a plain voice (I could never read a SMS at 2:00am!). I also had a feedback channel via DTMF. It cost zilch and worked like a charm! The gateway was an inheritance from when Madge went titsup, the server was an old Internet caching appliance and the software was open source . My code is long lost, but the strength of using audio and voice

Most companies do not realize that the priority in life for individuals lies elsewhere. Read about my views here .