Christopher
Stoll

Network Taken Down by a Cable

Today at work we experienced a very serious network issue. Initially it seemed that the network just went down, we couldn’t get outside of our facility, neither to the internet nor to our other facilities via the MPLS connection. But, nslookup (domain resolution via UDP) was working. We noticed that we could get to things on the network as long as they were in the same network (10.x.y.n/255.255.0.0 could connect to 10.x.z.n/255.255.0.0), so it seemed that the core switch was not able to route requests. I opened up a simple network monitor and saw that there were two devices flooding the network with broadcasts (10.x.x.x port 138 -> 10.x.255.255 port 138 and 10.x.x.y port 1985 -> 224.0.0.2 port 1985). The networking group found that the core switch was running at 100% processor. So, they identified which ports on the core these packets were coming from, then unplugged that cable. From there we tracked it to the next closet, and to the next closet. From there it was narrowed down to a room with thin clients that were not turned on. In the process of trying to identify which hardware might be causing the problem they found a small switch with an Ethernet cable plugged into it in an unussual manner.


Software Development Guidelines 03e

At my company I have seen a lot of bad software development practices over the years, so I have created a set of software development guidelines to help establish a set of best practices and baseline software requirements. I am publishing a series of experts from those guidelines here so that I might get some useful feedback that will help improve them.

Uncoupled Configuration

Configuration options should be separated from the program. A program should be able to be configured using external configuration information whenever possible. This is especially true for file paths and network locations.


Software Development Guidelines 03d

At my company I have seen a lot of bad software development practices over the years, so I have created a set of software development guidelines to help establish a set of best practices and baseline software requirements. I am publishing a series of experts from those guidelines here so that I might get some useful feedback that will help improve them.

Quality

Any software written for use in the Company should not only perform in a consistent manner, but it should also perform reliably and in accordance with the users’ expectations. In order to accomplish this programmers must plan how the software should work, continually test the application as it is developed (unit testing, integration testing, functional testing, etc.), and must thoroughly test the application to ensure that it is operating as planned before it is released into a production environment.


Software Development Guidelines 03c

At my company I have seen a lot of bad software development practices over the years, so I have created a set of software development guidelines to help establish a set of best practices and baseline software requirements. I am publishing a series of experts from those guidelines here so that I might get some useful feedback that will help improve them.

Security

There are several layers of security used in the Company’s computing environment, none of which is likely to change for any single applications, so it is important to have at least a basic understanding of some of the general constraints. This section provides an overview of IT security concerns across multiple IT groups, check the intranet or ask an IT analyst for more detailed information on any of the following sections.


Software Development Guidelines 03b

At my company I have seen a lot of bad software development practices over the years, so I have created a set of software development guidelines to help establish a set of best practices and baseline software requirements. I am publishing a series of experts from those guidelines here so that I might get some useful feedback that will help improve them.

Documentation

All software must be documented. In addition to the specification documents outlined above, there normally should be at least two levels of documentation: the user level documentation and the administrator level or technical documentation. Some very small programs are so intuitive that user level documentation is not really required, but administrator level documentation should always be provided.


Software Development Guidelines 03a

At my company I have seen a lot of bad software development practices over the years, so I have created a set of software development guidelines to help establish a set of best practices and baseline software requirements. I am publishing a series of experts from those guidelines here so that I might get some useful feedback that will help improve them.

Development

Accessibility

It is important when writing programs to allow access to people with disabilities. Creating software that is accessible by people with disabilities is relatively easy since most modern operating systems have already incorporated these features. The main goal of the developer in this regard should be simply not to interfere with the features already provided by the operating system.


Software Development Guidelines 02e

At my company I have seen a lot of bad software development practices over the years, so I have created a set of software development guidelines to help establish a set of best practices and baseline software requirements. I am publishing a series of experts from those guidelines here so that I might get some useful feedback that will help improve them.

Software Repository

Before development begins a source code repository needs to be created in an established source code repository area. Source code repositories must reside on a mass storage devices, such as a NAS or SAN, that is regularly backed up and maintained by the server group. Source code repositories must reside on equipment maintained outside of the development group.


Software Development Guidelines 02d

At my company I have seen a lot of bad software development practices over the years, so I have created a set of software development guidelines to help establish a set of best practices and baseline software requirements. I am publishing a series of experts from those guidelines here so that I might get some useful feedback that will help improve them.

Platform Specification

The platform specification, sometimes referred to as system requirements, should clearly describe all of the technologies that will be utilized in order to implement the solution. The specification should include the programming language, the development tools to be used and the client and server systems to be developed for.