Trip Report by Les Cottrell

They have 30 users of ISDN at the moment. They are using a Cisco 4500 with 2 PRI lines. They use call back and support IPX (as well as IP). Home users have the Cisco 75x routers and the Cisco recommended PC card (there is also a PCMCIA ISDN card). The call back works OK with the Ciscos for Windows '95. It took longer to make it work for Linux and Windows NT. There were also problems with making IPX work properly. They are not using the RADIUS security yet, but plan to, they can manage the security for the current level of users in the 4500 router itself. In the last 2 months they saw 600 hours of ISDN use.

For modem dial they see 14kHours/month. They use call back here also. They have about 1000 active users out of 1800 registered users. The use doubled in the last year. The modem terminal server is a Cisco 2511, it support 33.4 kbps, they are looking at Shiva with digital modems for higher speed (56kbps).

They also support AppleTalk Remote Access (ARA) via a Shiva LANRover, and expect to continue the support for some time. They also support AppleTalk over PPP though it may not provide the full functionality of ARA.

The call back is driven by the desire for centralized billing and charge back. The phone company (Alcatel-France) gives detailed reports including number called ad they (CERN) put it together with the account to be charged, which is kept in an Oracle database.

The main motivation for the existance of DHCP is to allow temporary outside visitors quick and easy access to the Internet without needing knowledge of CERN's internal network. DHCP is only configured on the so called "portable outlets". These are in conference rooms and public places, such as in front of the Help Desk. In order to provide a quality service on the internal network at CERN, portable outlets are not normally provided in offices. They cause problems for network management, debugging and security. A portable outlet can be requested if someone feels greatly incovenienced by (too) regularly having to re-configure your ethernet address. Use of DHCP in offices is strongly discouraged.

CERN is heavily subnetted with typically about 40 stations aximum per subnet (the mask allows 63), so the do not expect to have to split subnets further, so this is not one of the rationales for deploying DHCP. Further most desktop network configuration issues   were solved by NICE95 (CERN's version of W95).

They are looking at using NAT and private addresses for people with networks at home, this will conserve addresses. For home users they have concerns with using NAT for Unix platforms which use AFS mounting. There are also issues with with X terminals.

DECnet is not routed, just bridged, on the LAN. Continuing DECnet needs are driven by LP on the site. The work involved to support DECnet is minimal at the moment.

They use Spectrum (from Cabletron). They like the ease of adding enterprise MIBs, the alarm hndling is reasonable with nice hooks for Unix scripts. Support takes <~ 50% FTE and comes in leaps and bounds. The maps provide views of equipment by organization within CERN, since this is the way users report problems. Other views of the data are by whether they have an alarm associated with the equipment/server etc. or not.

They have a CERN developed alarm system that allows applications or systems (e.g. DNS servers, Unix servers) to send alerts to a central place. The central place also has a watchdog function that can raise alarms. They characterize alarms as being diagnostic, warning or panic levels. Either the client has to cancel the alarm, or a human operator has to do it. They are migrating the central alarm server to Windows NT, and have added extra capabilities, including providing the ability to report the alarms via a TCP connection (for extra reliability) and are looking to tie it into the tracking system.. They will also provide check-pointing so they can recover messages if the alarm server goes down.. They are working on a PC interface and a Web interface. Due to the stateless nature of HTTP the Web interface is limited in its ability to set filters.

The machine controls people run HP OpenView.

Most of the network security is handled by a screening router. They started off early on blocking everything and only allowing a few things through. They have set up their B class subnets (the subnet mask specifies 64 addresses/subnet) with three address ranges: no access with outside of CERN (8 addresses), outgoing access only,(8 addresses) and incoming & outgoing service access (48 addresses). In the latter one they allow FTP, telnet, X11, port 80 (WWW), 79 (Gopher), Talk, ICMP and IDENT. A few specified host can receive Email & News. Windows is blocked at the moment. The screening router has about 4 pages of ACL rules, they put the accept lists first to speed things up. They want to block all high order ports by default. They don't log failed attempts as seen by the screening router.

Charley Granieri is evaluating some firewall servers (Firewall-1) on a Sun dual cpu UltraSparc 168Mhz and a three CPU UltraSparc 450 298Mhz machine. It appears the firewall software cannot keep up with 100Mbps especially with smaller packets (e.g. with 250 byte UDP packets the maximum rate the firewall can receive packets is 13.4Mbps on the 168MHz Sun and 26Mbps on the 296MHz Sun). Even not running the Firewall software, the 296MHz Sun server can only support 64mbps when both sending & receiving. They are going to look at the functionality of the Cisco firewall next.

They do have a machine (an Alpha) that is used to passively monitor traffic on the CERN side of the screening router. It cords connection calls for TCP. It can also look at the text in the session for suspicious strings (e.g. "permission denied") and start logging the complete session when it sees them. When enough suspicious things are see alarms can be raised. They log about 150Mbytes/day of raw data, the data is saved in Oracle and they have about 25Gbytes of data. There is no proactive monitoring for misuse. I have a CERN publication "CERN's Network Security Monitor" for those interest in security.

CERN does not support ssh due partially at least to concerns over France's laws on encryption. They have paswword expiration for AFS. They provide a CRACK service for system managers. They have not put in a SATAN like scanning service.

CERN have had success with LDAP and will use it as an interface to the phone list. They would like to set up a global LDAP for HENP users. They are not happy with the Netscape LDAP server.

The IMAP server is a Solaris Enterprise 550. They recommend the U Washington IMAP server. They have 3 servers one of which is for testing. They balance the servers by using cnames. Users are registered with one or other of the servers (but not both). They have tools to migrate users from server to server (I have a document on "How to migrate users from one Mail Server to another one") to facilitate balancing. They started on IMAP in 1995, which in hindsight may have been a bit early in adopting, but were driven by the demise of CERNVM. They have given a lot of thought on how to make the service scalable to 8000 users. In particular they are using a scheme from Uwash that assigns a unique DNS name for each user's IMAP server. This is hard on the DNS but provides several added benefits when one has a lot of users. They are concentrating on the Netscape MAP client (I have several user documents on CERN's email service and "Mail Service System Administrators Documentation", and "mail Service Netscape Communicator Issues" all of which could be very useful at SLAC).They have listed 39 bugs of which 4 are critical. One critical one they mentioned is the opening of multiple connections between the client and server, which causes locking problems. It may be fixed in Netscape Communicator 5. A by-pass is to move to the mbx format but it is not trivial to migrate a lot of users. They say Eudora suffers from a similar problem. They have about 500 POP users, and 3500 IMAP users. The default server quota is 10Mbytes/user (at Uwash it is 5Mbytes/user.) and have tools to show the quotas to users.

For LDAP they are using the Sun LDAP directory service, they do not recommend the UMich server. For the ACAP server they are using IMSP from Cyrus, but are looking at the CMU server).

They will retire QuickMail, and MSMail and have already retired AFSMail. VMSMail is still available.

For spamming they prevent relays. They are using sendmail 8.8.8. There are some special rules they apply to sendmail from Klaus Asman of the University of Kiel. They block the IP addresses of banned sites, but can't block aol and compuserve. There is an extra filter to compare the sender address on the envelope to see that it matches the relay address.

CERN is experimenting with voice over IP together with DESY (Andrew Bobyshev & Michael Ernst) and FNAL (Phil Demar and Vyto). Each site has Vocaltec software (http://www.vocaltec.com/) on a PC to act as the voice to IP gateway and special interfaces (Dialogic) to the PBX. The Vocaltec PC sits between the CERN Ethernet and the CERN PBX. The user calls a special CERN extension which then provides a voice prompt (from the Vocaltec) to the user to enter the phone number. After entering the phone number, a series of sound "dots" are sent to the user (while the IP connection to the Vocaltec at the other site is set up), then one hears the ringing from the remote PBX and (hopefully is connected). I used it to call home a few times, and it worked well most of the time. Occasionally one got kind of squelched echoes of one's own voice, drop outs of a fraction of a second of the voice of the person at the other end. Denise hasn't identified the causes of the drop outs. It was definitely usable, but not something one would want to pay for yet.

Denise said it was very easy to setup. They have two interfaces on the Vocaltec PC. The 200MHz PC running Windows NT can support up to 16 interfaces. The user interface is customizable to provide more friendly messages (especially in the case of problems), but this has not been done yet, also some of the messages that need modifying are in the PBX.

FNAL are going to look at the Cisco voice over IP offering, an CERN will help in the evaluation when the current Vocaltec tests are completed. The choice of Vocaltec was driven by IBM who did their own evaluation and picked Vocaltec as the market leader and recommended that CERN try it.

CERN has over 200 Web servers (FNAL has about 100) which are visible worldwide (SLAC has about 70 servers but only about 15 are visible worldwide). CERN have been told to reduce this number due to the wasted overlap in effort it presumably results in. They have set up a voluntary CERN Web club with donated hardware to allow personal (non-business related) pages. They are running 2 proxy servers. They are also using the InfoSeek engine for searches and are happy with it. It supports searching .ps, .pdf etc. type files. CERN is moving to the Apache server, but are unsure about the FrontPage helpers at the moment. There are big problems in migrating from the CERN server to the Apache server (or probably any other server) due to CERN's heavy use of the htaccess protection mechanism in the CERN server.