");
if (points.length > 5) {height = points.length*20;}
else {height = 100;}
height = height * scale; width = 200 * scale;
hintwin = window.open("","hintwin","width="+width+",height="+height+",scrollbars=no,resizable=yes,status=0");
hintwin.document.write("Hint!");
hintwin.document.write(""+text.fontsize("-2"));
if (closetype == 'timer') {
var hint_to = window.setTimeout("unWinHint()",3000);
}
else if (closetype == 'button') {
hintwin.document.write("
");
}
// Note the default closetype is to close the window onMouseOut
hintwin.document.close();
}
function unWinHint() {
if (navigator.appName.indexOf("Netscape") != 0) return;
if (hintwin != null) {
if (hintwin.document != null) { hintwin.close()}
}
}
function clicked(ev) {
if (hintwin != null) {
if (hintwin.document != null) { hintwin.close()}
}
// unWinHint();
return true;
}
document.onclick=clicked;
//--->
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