Policy on network devices

Policy on network devices

Les Cottrell and Gary Buhrmaster, Page created: 5 October 1999. Last Update: October 5, 1999

Central Computer Access | Computer Networking | SCS | Network Group | WWW support

This page provides the policies for production network devices connected to the SLAC network.
For a French translation see: here.

Inventory and access

Rationale

The network switches, routers and hubs provide quite an array of advanced features that interoperate with other network devices. Changes, both intentional and unintentional, to one device can cause indirect changes to others. Because of the propagation of information from one device to another it is sometimes necessary to be able to view the state of the entire enterprise network. SCS thus needs to be able to access all network devices on the SLAC network for problem determination. This includes both the public SLAC network and infrasture and private SLAC networks such as SSRL, BSDnet and MCC.

Policy

All network devices (routers, switches, hubs etc.) connected to the SLAC network must follow the following policy:

The devices must be inventoried. By inventoried is here meant that they must be entered into the CANDO database and the SLAC domain name service.
If a password is needed to access the device for querying its configuration, understanding its operation or setting parameters in the device, then the passwords (including the privileged password) to all the devices need to be in escrow(*) so that if it becomes necessary SCS Networking can manage the network in an emergency, or on special request.

Equipment on SLAC public networks is owned, managed, maintained etc. centrally. Equipment for public networks in new buildings or for major moves is purchased by the project. After completion of the project, the equipment is owned, managed, maintained etc. centrally.

Central services are responsible for keeping public network equipment current (not ahead of the curve), and expanding as needed unless the expansion is part of a major move/expansion that has project funding.

Test network devices

Rationale

From experience the switched network we have now is very sensitive to poor software, misconfigurations, etc. A test device can inadvertently seriously disrupt production services several switches (or even routers) away. In the near future we may have many new services and/or functionalities to test, both hardware and software related (for example Windows 2000, IPv6, QoS, new protocols such as multicast, new routers, switches etc.), thus this policy is becoming increasingly necessary to preserve the production network environment.

Policy

Before any test network device (a test device is a new, to SLAC, network device, or one with pre-production software) is connected to the SLAC network, the central networking group must be notified and approval granted (if appropriate). The following information will be required:

purpose of the test
duration of the test
person(s) responsible
devices involved (hw, sw, passwords, etc)
proposed set-up

In addition, these test devices must meet the policies given above concerning inventorying and password escrow.

If at all possible, (approved) tests with pre-production software, devices, etc (e.g. including new services like IPv6, Win2000, new multicasting protocols/services, QoS et al.), will be made in a test network environment. The test environment should be clearly separated (by a router, controlled by the SCS network group) from the production network. Often SCS will be able to provide the test environment.

When running in a test environment is not feasible, then formal definition and approval of the tests, should provide at least an estimate of the risks involved for the production network. This should reduce troubles diagnosing and solving network-related problems.

* Escrow is a system whereby the "secret" can be kept in a secure location, and only authorized individuals, after providing a PGP passphrase, can access the "secret". Escrow allows designated parties to update the "secret". So, in this case, Hector would manage the "secret", and Networking could view it if they were authorized, and were able to enter their PGP passphrase. We currently manage the BaBar unix root passwords this way. SCS has access to the BaBar unix root passwords via escrow, and would access this password only if necessary.

[ Feedback | Reporting Problems ]

Owners: Cottrell and Buhrmaster