CERN Accelerating science

How to stay clear of the ethernet anti-pollution taskforce!

  Mike Gerard CN/CS

The CERN Ethernet is a very large and very busy network: the busiest segments have been seen with a constant 60%+ activity and peaks of up to 90%. This means that we check the network very carefully almost all of the time for what we consider as unnecessary traffic, i.e. network pollution. We are particularly vigilant at watching for packets of type broadcast or multicast, since these must be sent all over CERN. One of the tools that we use checks on the number of such packets from a single source: if this number gets above a few hundred in 10 seconds then the source system concerned is blocked in every FDDI backbone bridge, thus leaving the system concerned only able to talk locally. Currently there are about 45 blocked addresses.

We also look at less extreme cases of pollution and warn the user(s) concerned about their pollution. Mostly, these warnings are heeded: in cases where they are not we reserve the right to block the source system(s) manually.

How can you avoid our attention, supposing that you have a system attached to the CERN Ethernet? Well, there are certain things which are bound to catch our attention one day, so here is a reasonably complete list of things to avoid:-

1.

Certain user commands on Unix, or even VMS, systems are particularly bad. Beware of commands starting with the letter 'r', such as rwho, rstat, rdate, rwho, ruptime: these commands may give nice looking output but are very polluting: please do not use them.

2.

X-terminals, or PCs running X-Vision are sometimes configured by default to broadcast a request for any system willing to supervise them with the XDMCP protocols: several hundred workstations will answer this request (starting with a broadcast). Please configure your X-terminal or PC to specify exactly the required supervisory system.

3.

Many Unix systems are by default configured to run ``daemons'' such as rwhod or routed. These are useless at CERN, so in any installation of new systems please specify not to run them.

4.

Any setup of TCP/IP on the site must correctly specify the IP address mask: for systems on the ethernet the IP address is of the form 128.141.x.y and the mask is 255.255.0.0. Systems which have no mask configured sometimes broadcast a request for the mask, for which around 1000 systems answer!

5.

Any specific attempt to use the IP addresses
128.141.0.0, 128.141.255.255, 0.0.0.0 or
255.255.255.255 is a risky business. For instance, the command ``ping 128.141.255.255'' gets a few thousand answers immediately, plus a later communication from the anti-pollution task force.

6.

Beware of manufacturer-supplied software which claims to do a network test: for at least one make of workstation on site (HP) this test causes a lot of pollution. If you think you have network problems then ask the specialised support services.

7.

There are games which work in a multi-user fashion, and which often scan the network for other players of the same game. The well-known game xpilot is the worst: it is fairly sure to get your workstation automatically blocked.

8.

Installation of the Solaris software on Sun workstations, especially the initial boot installation, can easily lead to auto-blocking if not done correctly. Consult the specialised Sun support at CERN for more details.

9.

Beware of anything that acts like network management software, especially products that give a nice-looking screen map of connected systems, traffic and so on. Used by non-experts (and even sometimes by experts) such products can be very polluting.

10-99.

All the other things that we, or you, have not yet discovered!

P.S.

You also make us happier if you correctly set the DECnet Hello timer and LAT service multicast timer to the recommended 120 seconds: this is regularly announced in Vax user meetings and is just as regularly forgotten each time some new software version is installed.