Cisco → Network Maintenance Procedures

Hello,

I had a question on establishing a kind of network maintenace procedure. Is there a template that is available from cisco that I can fill in or follow to create some kind of procedure? Maybe something that can point me in the right direction? I need something straight forward that I can easyily understand and implement.

Thank you

It depends entirely on the situation. For example, in a 24/7 "always on" environment, your requirements are a lot different than in a 9-5 m-f office. In the former, you cannot turn anything off, ever. (think "CO phone switch") In the latter, you could power off the entire building all day over a weekend.

I work somewhere in the middle... there are numerous automatic processes that run outside office hours every day -- and there are a few people in Israel (+6 hr) that access our lab setup. If I've taken something offline during one of those times, those processes will obviously fail. It's usually not a problem, but it can raise questions as to why it failed.

Thanks, it is something sort of similar. I found answers to do with ITIL and change management. I think its a more complicated than I thought. I will need to do some more reading.

As cramer notes, depends what "network maintenace procedure" refers to, and what kind of "template" you're looking for.

Are you looking for a Standard Operating Procedure, or are you looking more for a "best practices" kind of thing?

Speaking from personal experience, here's my 00000010bits :

- determine the hour(s) that changes / maintenence can occur without negatively impacting users / business.
- determine the kind(s) of maintenence that is occuring -- power, hardware, break/fix, project-related, IMAC, etc.
- draft up guideline(s) when each can occur, and which group(s) need to be involved in reviewing the change
- make a point of setting up regular change meetings to discuss upcoming changes with the interested parties --
can be facilities, business unit(s), users / managers, other IT depts, etc. The whole point is making sure everyone
is aware of WHAT is going on, WHAT will be impacted, and for how long.
- keep a papertrail, paper or otherwise, of change approvals for later review
- DOCUMENT, DOCUMENT, DOCUMENT! I can't stress this enough!

In terms of SOPs for maintenence, your imagination's the limit. In general, any change / maintenence I do
breaks down into the following steps :

a) did I notify someone I am starting the change?
b) did I gather my prechange so that I know what the environment looks like prior to starting, and in case I have to
back out my change I can put it back the way it ways?
c) execute and validate the change -- did it accomplish what I needed to do, and did I only affect what I needed to touch?
d) did I gather my postchange and verify the above?
e) did I notify someone I have completed the change, and whether it was successful or not?

Regards

^^ awesomeness right there. Dont think I could have said that better myself.

Short version. Submit change to change management. Get told no. Enjoy your free time.

Or get told "do it next week, but we need to work these things in the interim..."

Regards

I'm all for change management but it often hinders getting work done in a timely matter. Probably because we have no general maintenance window.

I don't even want to know what it must take to try and get a change thru in an environment like that carp.
I'm guessing full mouth, a few limbs and a critical organ for the black market is the minimum that must
be donated?

Regards

In some small companies, network changes on the fly are the norm. Basically the network administrator has to have the following to curb chaos (and to keep his sanity ).
* Detail documentations (i.e. IP address assignment, network topology and design)
* Thoroughly understand the entire network
* Have advanced network knowledge
* Willing to take a little risk (i.e. testing network reliability on production network)
* Have all architects, engineers, developers, and technicians on speed dial (note: it will help when all of them sit in the same room)
* Keep communication between technical people (architects, engineers, developers, technicians) open and two way especially when someone decides to make changes on network, software, servers, or scripts
* Be conservative in making changes (read: do not make too many changes at a time) in case something goes wrong and need to reverse change
* Plan ahead on everything
* Have a thorough concept of how design the network to be reliable, scalable, and simple to manage
* Continuously work with vendors and providers in regards of issue and new product testing (note: having them on speed dial helps tremendously in emergency situations)
* Always be ready to get down and dirty (note: for those that are not used to run cable or rack/stack, better get used to it)
* Keep all cable run nice and neat at all time (note: having the same understanding and commitment of how one should run cable helps tremendously)
* Go through all project planning down to little details (note: assume nothing is agreeable and make sure all parties involves are within the same page would help tremendously)
* Willing to defend the network with all mights when other teams (i.e. server or developers) try to blame the network, especially when they made you to do things to simply validate what you have been saying all along during the network defending process
* Have all network tools handy (i.e. tcpdump, and any network latency detection tool) in addition to your usual laptop, cables, and Google search
* Willing to take any BS from management or business units even though they are not your issue or your fault (note: have very thick skin helps tremendously)
* Willing to do little politics (read: white lie) as long as you can defend them or to very least make people forget and move on
* Being proactive in front of management or business units to cover yourself in case network infrastructure is crippling
* Document all email communication (note: direct people to send email in addition to oral communication helps tremendously) to cover yourself
* Lastly, make sure that all comes down to not about who is to blame but what everyone can contribute in order to get resolution quick and long term.

• Requests for changes (additions, deletions, modifications) in processes and procedures documents currently being used to support the BCP Plan
• Reports of problems in actual use or testing of the BCP Plan processes, procedures and reporting
• Requests for developing new processes, procedures, reports, and other documents