TRIP REPORT

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.

Gilles Farrache (farrache@in2p3.fr), Jerome Bernier, Rolf Rumler (rumler@cc.in2p3.fr), Elisabeth Piotelat (piotelat@in2p3.fr), Chafia Tifra (tifra@in2p3.fr), Helene Jamet (jamet@in2p3.fr)

CCIN2P3 is the computer center for about 17 HENP centers (IN2P3) in France. They have a simulation farm, interactive farm, STK/Redwoods with tape servers, disk (RAID) server on ATM with PVC. There was a problem with SVCs in AIX 3.2 that has been fixed in 4.2. The machines are connected at 155Mbps (there is not a 622bps interface available for the IBM computers yet) and the interswitch (Cisco Lightstream 1010) connections are 622Mbps (there is no IP emulation on the 622 links). There is a direct connection between the data server and the compute server. They are using classical IP emulation. They do not have broadcast (not using LAN emulation). They do not expect to be able to connect machines at 622Mbps rates for some time (lack of interfaces), and even longer before they can have >= Gbps machine connections with ATM. They are thus planning to using Cisco 5500 and moving to Gbps Ethernet. They will keep the existing ATM and use LAN emulation. The C5500 will provide 100Mbps and 1Gbps connections to workstations and to each other. The existing LS1010s will not be connected together, they will be connected to the C5500s. The compute people are also looking at using Fiber Channel Standard (FCS) interfaces or HIPPI. Rumler reports that the limitations today appear to be the disk writing speed (for SSA disks) which appears to limit < 7 Mbytes/sec. They have big packets that should work OK for LAN emulation.

They are not using HSRP, or VLANs (they have only one building so the need for VLANs is minimal) or route switch modules, so far they have not played with fast Etherchannel, it could be interesting in future based on BaBar needs. They do not support DHCP yet, there has been little demand.

IN2P3 will be hosting BaBar (for 30 BaBar/France physicists out of 2000 French physicists) data (expect 100 Tbytes/year from BaBar), and also D0 (starting 2001). The storage work will be useful for LHC in future, but the BaBar requirement is very demanding early on. They can store up to 1.7Pbytes on the silos). IN2P3 are finding it hard to follow BaBar's change in emphasis from IBM (they are at AIX 4.1.5, and BaBar are promoting AIX 4.2) to Sun platforms (i.e. the builds are done on Sun first). There are also concerns with being able to distribute the data via Objectivity especially due to the security and reliability issues. IN2P3 have been asked (by Jurgen Mai/CERN) to look into an Intel farm, but they do not have any users clamoring for such a farm.

In the past PHYnet supported native DECnet, but now migrating to RENATER. RENATER supports IP only. There is DECnet phase IV or V internally. Before the end of June all international and WAN DECnet will not be supported by the computing center. There are no VMS nodes at IN2P3, there are some at other centers. They are using AppleTalk internally for special purposes such as printing. There is no support for AppleTalk over the WAN.

Started with AFS mail on IBM RS/6000 370 with RAID disk, was reliable but required people to logon. So they started to support POP for administrative folks with Macs & PCs. They are using the Netscape mail server (chose because thought would have good support etc., but not clear it has worked out this way). They also tested the CMU and Washington U servers. The Netscape version 3.1 server (it provides the SMTP service as well as IMAP/POP) does not appear to work well when it gets big bursts of email, and users see long times to read their mail. They will be testing a new version (current 3.1 moving to 3.5). They are thus not pushing the move to the Netscape server. Administering the Netscape server is very easy. A few people in the CC have moved to IMAP. They will also upgrade the machine to an IBM F40 (the IMAP server requires a lot of memory). Today they have about 10 simultaneous connections to IMAP (IN2P3 sees a need for about 2Mbytes memory per connection, Netscape say 700kbytes on this release, and 256kbytes on the next release) and 200-300 with POP. IN2P3 says that the initial CERN IMAP service got a bad name since it was slow, and IN2P3 wants to avoid getting a bad name from too early an introduction.

They are allowing a quota of 50Mbytes/user. There is no way for the user to know how much of their quota is in use. They use separate IMAP accounts from Unix (different userid and passwords). There is a database that keeps track of the IMAP and Unix accounts. They are supporting the Pine and Netscape IMAP clients, will look at Eudora. They have seen a lot of bugs with Netscape 4.0, Pine 3.96 has been fine. They have no current interest in an NT IMAP server.

Filtering IP broadcasts on the LAN (smurf attacks). They are blocking spoofing, IRC (Internet Relay Chat) was causing more problems that help, NFS will be stopped end of June on the WAN, it is allowed within the LAN, TFTP, ICMP (ping, about 2.5% of the trans-Atlantic link (of 600kbps) is used by ICMP) blocked except to one or two special machines (this could cause problems due to blocking ICMP quench and other things), don't block X, block Netbios to certain Labs (will be extended to all Labs), no restriction on machines which use SMTP.

They are looking at using a transparent cache server to provide HTTP offsite access. They will probably use the redirect in the Cisco router and use with a squid server - as opposed to the Cisco cache server. There are discussions on staleness of data. They are already running a squid server and requesting people to use proxy, but want to make transparent and users have to do nothing. They started out with a 5Gbyte cache. About 40 machines are using the squid caches (non transparent). They see the caches are quite well used (>40% today) and take this to reflect that people are not surfing but focussing on a specific sites. CCIN2P3 acts as a father to other IN2P3 sites (each IN2P3 sites will have their own squid servers eventually) which have their own squid server and will provide a cache server for server that do not have squid servers. They will only be fathers for sites that have the same routing policies (e.g. for IN2P3 sites but not for commercial sites).

They are not using any commercial tools to manage their routers. They have about 40 routers including border routers at remote sites such as Orsay. They monitor the WAN (but not the LAN). They take the IP accounting from Cisco routers and collect it on a machine at CCIN2P3. This provides destination/source and packets/bytes every 20 minutes. This is kept for security reasons. This information will be used for monitoring. They are working on analyzing this data and will generate alarms. They will tie it into an existing alarm enunciation system. They also use the SNMP alarms, and ping a router that does not have support for SNMP alarms. They do not have a 24x7 NOC, there is a computer center operator, who can call the networkers at home. The alarms will be able to be sent as email and also to pop up a window on a workstation and make an audible alert. The networkers also have ISDN lines to their homes, but do not carry a pager.

They have not looked at Netflow yet. Netflow has filter lists and can record a complete sessions, it needs a big link to the logging machine and a lot of disk space. Netflow runs on the Cisco and talks to a collection machine. FNAL use it to record suspicious sessions. On site (CCIN2P3) they have one person who worries about security (he is also a Unix system admin), there is one similar person in each Lab, plus there is a head located at Orsay for all of these activities.

They are part of the consortium that has a "fat pipe" (2*E1) across the Atlantic. They are guaranteed 600kbps and can burst to 1.54Mbps. The partners are CERN, WHO, UN, IN2P3 plus another. IN2P3 will upgrade its participation to 1Mps soon. They are very happy with the trans-atlantic service. The guarantees is implemented by Olivier Martin's Frame Relay IGX box.

If the CERN link goes down then it would be hard to redirect the traffic (Renater will not announce IN2P3 traffic outside France, so it has to go via CERN). National (French traffic) is routed via Renater. Some IN2P3 sites are still on PHYnet others are on Renater. Renater works well within France, apart from when France Telecom is working on the routing (e.g. 2 weeks ago, a couple of Labs were cut off from the network for 3 days over a weekend). Renater does not have enough capacity on it trans-atlantic connection so it does not work well to the U.S. The problems with Renater are greater than the problems when they had leased lines with star points at Lyon and Paris.

Like the idea of centralized special purpose machines (prefer to pinging general purpose machines) but would like to see some analysis or firm plans first.

They are evaluating the Sun and the Netscape LDAP servers. They ran into problems with sharing the directory between several Suns.

They support c=fr, o=in2p3. The goal is to have one server to ask within IN2P3 but with the organization of each organization unit located at each Lab (e.g. Orsay etc.) There is a problem with the Sun server that if there is a request to the top level LDAP server then it is not forwarded to the subsidiary server in particular if there is a common name at multiple sites (e.g. smith at ccin2p3, and smith at lal). The Netscape server does not suffer from this bug, but there are a lot of other problems that Netscape do not appear to be addressing very well. Elaine has spent more time so far on the Netscape server. No decision made on what product to go to. CERN did not see the Sun problems since there is only a single directory at CERN, and CERN is very happy with the Sun server. It is possible the Sun server could be made to work if all LDAP queries came to CCIN2P3 which then farmed them out to LDAP servers at the various IN2P3 sites.

CCIN2P3 are not looking at the ACAP, Michel Jouvin at LAL is looking at the Simeon ACAP server.

They have about 3 dial-in connections for physicists, 3 for engineers (both are PPP), plus an X.25 to Minitel (via an old Micom X.25 mulitplexer), and a ISDN/PRI into a Cisco router.

The official policy is that there are no private Web servers or private Web pages. This is a cross IN2P3 Lab policy. They want to restrict the number of Web servers. They scan for Web ports. They expect to restrict the usage of Web servers and will probably block at the border router.

The Local Area Network is based on FDDI concentrator in CC (Computer Center). It is only lightly loaded, most traffic stays within department. Most of the large buildings have a router. The demark is in the router in each building. The department pays for board in routers and the CC manages the routers. There are 7 main site routers. SW (Structured Wiring) has been deployed so far in the CC. Funding for SW comes from depts. Budget 80 English pounds/point (point = 1/2 of junction box), will use SW for voice also. Putting in about 4400 points eventually. Will be UTP cat 5 to desktop (not fiber at the moment). Voice will also use SW UTP cat5. Will keep department routers in buildings with switches (3COM) with managed hubs (24 port hubs mainly) for workstations & routers. The SuperJanet (ATM <= 34 Mbps) Router (RAL's) is currently a 3COM, will be Cisco (better accounting and control facilities).

Connectivity to SJ (SuperJanet the Academic & Research network n the UK) is at 16Mbps, plus managed network points for various small sites, plus ISDN, plus CERN 64kbps leased line with compressors (6K English pounds initial cost, they pay for themselves quickly) for interactive use (have to login to CERN).

They are using a Cisco 4000 with 1 PRI with 10-15 users. Mainly for telecommuters, plus a small site. Use Cisco 760 in the client end. ISDN is costly, 400 English pounds to install and 80 pounds /quarter. Usage varies with time of day and for local calls varies from about 1p to 3.4p. Calls can be charged in both directions since the second channel may be brought up from the client end or the server end.

They are looking at DHCP. They are concerned with integration with DNS. Also removal of security by IP address for single machine, in particular the Datastore uses IP addresses for security. They recommend using DHCP for static addresses. This helps management since people do not have to enter configurations. At the moment some "villages" are deploying DHCP servers with dynamic pools. There are 2 test ones that will go into production with static addresses. This also allows portables to migrate over the site with one pre-allocated IP addresses per subnet. Expect to have one DHCP sever/village for increased availability (each one will serve the one or more subnets in its village). Token life will vary. When client comes up it sends a request for renewal of the address. If the server is up and the client is on the same subnet, then it will renew the address, else it will get a new address. The lease is recommended to be 2 days. They are using the WNT4 DHCP server, since the RAL policy is to move to NT. Since they use static addresses they get the user to tell them what the MAC address. Typically many users say this is my IP address and then Tim Evans looks at the MAC address associated with it and adds it to DHCP server. The main requirement is coming from the portables. Expect demand from conference rooms, but some conference rooms are not cabled.

No easy way available yet for DNS integration. There are 3^rd party products, but not interoperable with other vendors, and fairly costly.

Issues with WNT 4 server. Tim does not recommend. Microsoft have a lot of room for improvement. WNT4 gives most of functionality they want. However, database is kept in 2 places. Part is in the registry and part in Jet, and need to reconcile, plus backup/restore is a challenge (e.g. restoring part of registry is challenging even Microsoft says don't touch registry). Tim has not had success with this in particular with the static mapping of IP to MAC address.

People typically are on their own. Admin ran CCMail, Daresbury ran MSMail, Unix ran Unix. The CC ran a POP server with Eudora client. Also running a POP compatible IMAP server. Particle Physics (PP) looked at IMAP servers and are considering moving. Then a year ago someone said need to look at a coordinated Email system. Quickly decided to focus on Microsoft Exchange (have 3-4 servers). Migration plan was to move MSmail first, followed by ccMail (both completed, ccMail closed down now). There were good migration tools. Then they want to migrate Eudora. Main problem of migrating from Eudora is the existing folders, nicknames etc. Want to close down POP server. They have a site wide mail redirector. Typically pass onto Microsoft Exchange server (which supports IMAP4). They have had problems with Pine (supports IMAP2, needs new Pine 4) not supporting fully IMAP4 (in particular in the area of folder support). PP are going to move from IMAP4 and moving to Exchange.

Exchange is claimed to support LDAP support. But have not explored yet. RAL does have as site directory. It used to be X.500 based. Information on RAL staff is kept in an Exchange directory, and Exchange is supposed to be LDAP capable. Not looked at ACAP yet.

Paul Kummer, Rob Bradshaw, Robin Tasker at Daresbury.

John MacAllister, Tim Evans, John Gordon, Allan Flavell, Paul Jeffries at RAL.

There is some overlap with monitoring already done by PPCNG, should they move to the ICFA PingER?

Networking mini agenda:

• NIMI,
• MRTG, Lat'Long,
• Netwflow
• Tracroute Ping
• Group Ping
• MapPing
• Classification of HEP traffuc
• 100 vs 1000 byte pings

NIMI

Concerns were raised about how to use the statistics. This meant more than just how to present but also how to use the measurements to understand and work with other identify and improve things.

Would like to have a pre-loaded NIMI. SLAC will look into pre-loading and shipping to RAL.

John Mac did some tests with FTP vs. Ping loss between sites in the US and the UK using tcpdump and there was a big correlation.

RAL would be willing to beta test. T.D.Evans@rl.ac.uk will be the contact person.

Rob is not fond of MRTG, nice student project. Good for providing a graphical output. Not easy to get at the database, e.g. if wish to run the data through another analysis program to provide collisions/frames. Idea of producing GIFs each minute that nobody looks at is questionable.

The UK PP folks are interested in characterizing the traffic, this is driven by new charging schemes. Would like to find a site with the physics department on a separate network then put something like Netramet on the subnet to see what the utilization is by particle physics site. Even then it would be for the one site only. They have done some work on the CERN-RAL TEN-34 link. Somebody (Jonathan) has done some work to identify the PP sites in the UK and has done a report to identify the bytes for each site pair.

John is porting TracePing on WNT and Perl. This will enable it to be system independent and portable. John hopes it will be ready by summer this year.

Roman Tirler's paper says the overall HEP traffic on the A&R nets is about 2%.

Allan Flavell & John Gordan will review.

Video Conferencing

Alan Flavell worked with CuSeeMe, but it is stuck with nv for MBONE use (the LBL folks have not made vic work with CuSeeMe), and if use nv does not work with the WhitePine extensions such as whiteboard. Alan thinks WhitePine are working on new releases including multicast for CuSeeme. Alan is therefore moving to vic and vat etc. But concerned about MBONE use and so want to migrate to reflectors. CERN's virtual room is based on RTPtrans. The HEPNRC are developing the MSB (Multi-Session-Bridge) which provides many features but had problems managing. The net result is that there are 2 tools that are migrating to one another but do not fully inter-work. HEPNRC claims to have developed a gateway between MSB and CERN's virtual rooms. He also said a Web page to configure the MSB will be available in the next couple of weeks. Gary Roedigger will be visiting CERN to talk about interworking. CERN (Christian Isnard) will be coming to RAL next week to discuss the CERN tools. CCLRC (RAL/Daresbury) puts in 1/3 FT for the PP community. There are others covering video conferencing

LAN Issues

Daresbury LAN had structured wiring installed starting about 6 years ago. It was a major contributor to improved availability (stopped people messing with it). Have fiber installed on site. Expect single mode to be important due to size of site. Will connect hubs to switches. At moment switches are in data center, will be deploying switches in buildings. Using Alantec switches that have been very reliable (one port out of 3 switches failed in 3 years). Gbit Ethernet is the way forward. Looked at ATM on site a few years ago, but do not intend to expand. They expect link aggregation to be important which is going through standardization in the IEEE 802.3 WG (finish end of year). Daresbury is largely a class B network. On site routing is done on Alantecs. They only run RIP not OSPF. The SuperJanet routers will be all 3COM gear. They are not using VLANs since standard is only just finished. Two of the three Alantecs are tied together with redundancy (via spanning tree). Buying 3COM 3000 switches for building switches.

They have invested heavily in network management. Believe it helps a lot. Knowing where machines are is critical. Looking at DHCP. Not clear whether it will make things easier for complex networks.

Have monitor to look at traffic on the network. Also run HP OpenView, find it hard work, it is complicated with a huge learning curve, but worthwhile. They also find it hard to know how to size the system to run OpenView on. It is very hard to keep it up to date, they have not updated for 2-3 years. They also run Transcend from 3COM, they have but don't use NetMetrix, they use Powersite for Alantecs, and DEC's hub management package. Gather statistics for each segment, 30sec RMON statistics (can display as raw data or as 10 minute means and peaks), also create average hourly, daily etc. data for trends with all kinds of selections. Looking at how to characterize in terms of usability of threshold (e.g. thresholds for utilization and how often it goes over the threshold). One of the more useful packages appears to be NetHelp from Concord. The NMS is used by the network support folk (4 folks on rota to support network). Backend on NMS to ticketing system to record and send out email. They have an informal call-out arrangement. Pagers to the operator who check and may call someone from network support up to 10pm at night. Have consistency checking software to correlate DNS entries, property control, OpenView map, which segment something is on. They have also got software for displaying. The statistics are kept at:

http://netshp.dl.ac.uk/stats.html (raw data) & trends.html (for HP probes) For more information contact r.g.bradshaw@dl.ac.uk.

Daresbury does not run DECnet. Native DECnet phased out. LocalTalk for a few Macs which can't upgrade.

Most security is reactive, want to be more proactive. Have reacted to denial of service ping attack. Running a large class B makes it worse than running a subnetted class B. Were seeing loads of 33Mbits on SuperJanet. DL does not have control over edge router so ACLs are put into Alantec.

Have a policy for SMTP to limited set of mail servers. They also block mail relay from outside to outside There is little central control at RAL. They had over 400 SMTP servers, now down to 50, by mid-April will block a lot more. Considering blocking IRC. No blocking for NFS or TFTP or spoofing. Glasgow & Oxford fixed spoofing.

They monitor for acceptable use, consist of 2 PCs with FDDI. They run Optimal Internet Monitor from Optimal networks, monitors FTP, HTTP, NNTP (looks inside packets, not just port) and produces a report with which sites are accessed. It is dumped each week, and run some analysis. Egregious inappropriateness can result in censuring of the individual (one was student who was banned from site, plus two others). There is a computing security officer for each site, but do not have much power (probably paid 2/3 time for security, and works 1/3 time on it). Security officer reports to Trevor Daniels (at RAL) the head of computing services. Experience of Grenoble was that the firewall was so onerous that people avoided it and placed themselves outside the firewall.

Daresbury, RAL & Oxford are moving to Microsoft Exchange. Glasgow looking at WebMail (a commercial product). They run a lot of POP into Microsoft Exchange. Oxford is happy with Microsoft Exchange.