8 Rules for Network Autobahn Engineers

To run a network can be a har8Rulesd challenge sometimes. It helps a lot when you stick to some generell rules and apply these to all the work and devices for that you are responsible. I have seen networks that had no standards at all, every device was configured somehow in a different way. This ends in an unmangeable desaster, where you can not predict anything. I prefer that you have one standard that is appllied to all devices, it need to be consistant, so that you have a stable and predictable network. Besides the techniacal challanges a network can only run as good as the Engineer has designed and installed it. So the main goal is to have the complete package.

1: Make standards where ever you can

Not everything can be equal configured on all devices thats for sure. It is depending on the device type, site or software version. Where ever you can make standards that can be applied over all your devices try to do it. For me it is important that general paramater like NTP Server, Syslog Server, SNMP Trap Reveiver etc. are configured identically. So that you have the same time on all devices, and all the logs/traps on one central log server , that helps a lot when you have to troubleshoot a network problem.  Also very important is that you have the same protocols and versions on all devices. To have standard STP , PVSTP, MSTP and RSTP all configured in the same network does not make sense at all. A very difficult aspect is the sofware version that runs on your devices. I prefer that it is the same on all devices. We all know that most software releases have bugs inside, if you have on all devices the same software you know at least these bugs. In an given network where you have 20 devices with 20 different versions of software code inside it can be pretty hard to predict what is going on. A second point here is that often tiny little details have changed like CLI commands or SNMP MIBs.

2: Documentation

The goal is a valid up to date documetation of the entire network. That isn´t the case in most real world deployments. As an external consultant you end up often in the situation that you have no documentation at all from a network and have to start discovering the network as the first task. I try to achieve a good level of documentation with a simple policy , no changes without documentation. In the process of the change like e.g. adding a new switch to the network, it has to be part of the workflow to update the documentation. If it is not done at the installtion date it is in most cases never done.

3: Monitoring

All devices that are in production have to be monitored.  If something brakes that is not monitored you will get calls very soon and have no clue of what is going on. Here it is also a good idea to implement monitoring in the workflow. When a new device is added to the network, the monitoring should be setup within this process. I have always a better feeling for the network when I know what is going on. With a good monitoring in the backround you know what is going on before somebody calls you. When you can react before something breaks the monitoring is working perfect.

4: Testing

Do extensive testing of all new stuff before you implement it in a production enviroment.  New stuff can mean Device types, protocols, network designs, software code…. or other thinks that you haven´t seen or tested before. Not everthinks works in the real world exactly the same way that it is discribed by the vendor documentation. Rebuild as much as possible in the lab and try to break it. Make your expierences and get comfortable with the technology. If it does not work in the Lab you should not role it out to your production network.

5: Educate yourself

In IT time is always running. Try to keep up with new technologys and trends. Sometimes a new technology or feature can solve a problem that bothered you for a long time. To invest time in research can lead you into great new opportunitys.

6: be Open Minded

Sometimes I am stucked with an particular problem and have no idea how I can fix it. Here it helps to think out of the box and discover new ways to solve problems. Keep contact to other IT departments, sometimes the server or storage guys can give you input from an other point of view that leads to a solution of a problem that you haven´t thought of before.

7: Chose your weapons wisely

You will need a wide range of tools for all the different task in your daily work. Sometimes it makes sense to use a swiss army knife tool that can do a lot of different tasks and sometimes you need a much more specialised tool that is disgned only for a particular task. Here it is important to know wich tool you need for a task. I also try to review my tools on regular bases, sometimes you find a new tool that gives you some extra features.

7: Never stop Optimizing

Don´t get stuck with an configuration or protocoll that is outdeted. Only because we had used something in the past for a long time does not mean that this it is still the best way to do it today. Technolgy is evolving every day , leverage this in your advantage. An good example is HSRP. On most Cisco devices are 3 first hop redundancy protocolls supported: HSRP, VRRP and GLBP. VRRP has the benefit that it is an open source standard and GLBP gives you active-active load balancing over multiple L3 routers.  In real world deployments I still see that HSRP is used in most networks, wich is not the best choice in my opinion. Don´t be scared about Changes, when you get a benefit from a change, test it, roll it out and have a better system at the end of the day.

8: Share your Knowledge

If you have solved a problem , share your expierence with your co-workers and the network community. A post in a network related forum is done in a few minutes and can help someoneelse with the same problem.




About Dominik

Network problem solver
This entry was posted in All. Bookmark the permalink.

Leave a Reply

Your email address will not be published.

fourteen − 11 =

This site uses Akismet to reduce spam. Learn how your comment data is processed.