Screencast: Knowledge Management in Technology – Part 3

Screencast-Logo-1

Network Engineers have to manage a lot of information. Products, technologies, textbooks, study notes and research material as well as new protocols and features. Just simple tasks like keeping product manuals handy for 40 or 50 products is a real problem. How do you keep the information organised, referenced, accessible and useful ? Your employer […]

Screencast: Knowledge Management in Technology – Part 2

Screencast-Logo-1

Network Engineers have to manage a lot of information. Products, technologies, textbooks, study notes and research material as well as new protocols and features. Just simple tasks like keeping product manuals handy for 40 or 50 products is a real problem. How do you keep the information organised, referenced, accessible and useful ? Your employer […]

Screencast: Knowledge Management in Technology – Part 1

Screencast-Logo-1

Network Engineers have to manage a lot of information. Products, technologies, textbooks, study notes and research material as well as new protocols and features. Just simple tasks like keeping product manuals handy for 40 or 50 products is a real problem. How do you keep the information organised, referenced, accessible and useful ?

This three part screencast is about how I manage all the “inputs” so I don’t feel lost in information after many, many people asked.

Rant: Our Vendor Partners Dont Have an SDN Vision

1126962_cheshire_matterhorn_2.jpg

There is an old saying “A man with his eyes fixed on Heaven doesn’t see where he is going”. It’s an almost perfect description of how the major vendors are bringing Software Defined Networking to the market.

The consistent message from all the vendors and especially the Cisco, Juniper and Brocade is that there are “no use cases for SDN”. In the last three months, this has been a constantly repeated statement both publicly and privately. This beggars belief that vendors can’t see immediate needs that deliver long term gains.

I suspect that the root of this problem is the big companies want to solve big problems. And by solving big problems they figure that they can make big revenue. Alright, I get that. It’s understandable that large organisations need a constant revenue stream to feed the insatiable maws of their shareholders. However, the vendors re also missing the most real and immediate problem of networking today. Simply, Networking is too hard.

Vendors haven’t developed tools that keep the complexity of networking under control. Complexity can be reduced to this: “I don’t have big problems, I have lots of small problems.” You can have debates about addressing complexity and how to attack it, but it nearly always boils down to this: start small.

Basics: Cisco VLAN Trunking Protocol – Transparent discard and passing VTP Packets

It’s a common discussion about when Cisco VTP protocol is actually forwarded through Cisco switches and when it’s isn’t. I’ve always gotten it somewhat confused and when I stumbled across some old notes on the topic I had an ah-hah moment. I’m answering the equation about when using VTP in your network, which versions are risky – that’s risky is terms of how do you prevent VTP updates from ‘crossing’ a switch.

My Way of Selecting a Cisco IOS Release with a Bug Scrub

bug

Cisco is known for shipping products early to deliver new features quickly. But this leads to a reputation for buggy code which has customers report bugs (and Cisco fixing them). This means that you should never buy a newly released Cisco product unless you are willing to take this risk. This post looks a my process for analysing this risk and then selecting an IOS version by performing a bug scrub. In this case, I’ve been asked whether the Cisco C3750-X switches are ready for live deployment.

Routing Protocols and Computation in Silicon

I got this question and I guess it may not be obvious to everyone so I’ll have a shot at answering it.

Technology advances in ASIC hardware have resulted in substantial improvements in switching performances of routers and switches. However, the routing processes are still dependent on CPU speeds. What are the existing limitations in router/switch models which prevent route computations from being performed in hardware?