EBS OPERATIONAL RECOMMENDATIONS Tony Bates University of London Computer Centre ABSTRACT This paper defines a set of operational recommenda- tions for an Ebone Boundary System (EBS) and the responsi- bilities of an EBS operating site. This is based on dis- cussions within the Ebone Operations Team (EOT). This should act as guide when adding any new EBS sites. February 1, 1993 EBS OPERATIONAL RECOMMENDATIONS Tony Bates University of London Computer Centre 1. INTRODUCTION This short- paper lists some operational recommendations for an EBS in its configuration and operation. This paper is meant to be used as a basic guide when configuring your EBS. It follows discussions within the EOT regarding a collaborative operational approach to the manage- ment of the Ebone backbone. Refer to separate papers for a detailed description of the routing implementation used [1],[2] and the overall management model of Ebone [3]. 2. ACCESS TO THE EBS By ``access to the EBS'' I mean access for operational and administra- tive purposes. Currently all the EBSs in use are based on cisco routers--. These routers support two methods of access for management and operation, an interactive terminal (telnet) interface and an SNMP interface. The next two sub-sections describe the way these methods should be used and configured in the EBSs. 2.1. TELNET ACCESS The routers support multiple telnet sessions and have the ability to run an authentication service known as TACACS---. TACACS is a client/server based protocol that allows the router to interact with several servers holding account information for users of the router. It works on the basis of the normal Unix password file scheme with the advantage that you can hold the password file on several servers for backup. It is recommended that all the EBSs run TACACS. This gives extra functionality when looking at operational aspects of the router. You can actually see who did what and at what time by use of TACACS logging information. + Recommendation 1 - Each EBS must run TACACS. _________________________ - Short being the operative word. ;-) -- cisco AGS+ routers - See [4] for more details. --- TACACS code available from ftp.cisco.com as xtacacsd.shar. February 1, 1993 VERSION 1 Page 2 The higher level enable password will only be known by the EBS opera- tor and the Ebone NOC. 2.1.1. TACACS SCHEME With all the EBSs running TACACS it should be possible to create a flexible and resilient scheme for making sure that access to the EBS is possible at all time. It is recommended that each EBS site run at least one TACACS server locally to them. + Recommendation 2 - Each EBS site must run at least one TACACS server locally. With local servers in place each EBS can then use the other EBS site's TACACS server as backup in case of failure. By use of a simple update procedure it should be possible to all the TACACS password files at the EBS sites consistent. A mechanism for this is left for later dis- cussion. To make it easier for an EBS site an example of a possible TACACS con- figuration is given. The text in bold type represents the areas of possible change in your local EBS configuration. ! ! TACACS commands needed ! enable last-resort password tacacs-server host 128.86.1.20 tacacs-server timeout 10 tacacs-server extended tacacs-server authenticate connections tacacs-server notify connections ! 2.1.2. DISTRIBUTED TACACS PASSWORD SCHEME When operating and managing several routers in such a collaborative way the consistency of the password database is very important. Even- tually an automated scheme for the update mechanism should be avail- able to take care of this. In the interim it is recommended that all EBS operators update their EBS TACACS password by making use of the Ebone NOC mahine tftp.ebone.net. Each local TACACS machine could then rcp or NFS mount the TACACS password file. + Recommendation 3 - Keep TACACS password file consistent with tftp.ebone.net. 2.2. SNMP ACCESS TO THE EBS The cisco router has a very large suite of ``private enterprise'' variables as well as the standard MIBII set which are very useful in terms and management and statistics. It has been agreed that all EBS February 1, 1993 Page 3 VERSION 1 operating sites should have SNMP access to all the EBSs. This would be done by having an ``access-list'' for a selected ``read-only'' (RO) community string. The obvious string appears to be public. The access-list should have an entry for any requested host address that an EBS operator uses for SNMP management. + Recommendation 4 - Each EBS site must run an access-list controlled public RO community. 2.3. STATISTICS GATHERING Each EBS site must collect statistics for its local EBS. It is recom- mended that the data is stored according to the current IETF OPSTAT recommendation [6]. The statistics must be made publicly available so that the NOC can then analyse and present the statistics. As soon as there exists a publicly available statistics collection package using the OPSTAT format each EBS should run this. Until then however, ad-hoc packages should be used. For complete traffic information ip accounting should be run on the EBSs. However, until we have CSC/4 processors in the EBSs this will not be implemented. + Recommendation 5 - SNMP statistics should be stored in IETF OPSTAT format. + Recommendation 6 - Each EBS should run ip accounting as soon as CSC/4 processors are fitted. 3. TROUBLE TICKETS For a well run and well maintained network, a ``Trouble Ticket'' sys- tem is essential. Currently, there appears to be a lack of a good gen- eric trouble ticket system available-. However, several EBS sites have already adopted there own somewhat ad-hoc systems. This is not a problem providing they conform to the same standard presentation for- mat as described in the RIPE recommendation on operational contacts [5]. All ticket information should be archived and made available to the Ebone NOC for reference. + Recommendation 7 - Each EBS site must issue tickets in the RIPE recommended format. They should be made available via a local archive. A trouble-ticket research group has been set up within the EOT to review this matter in more depth. _________________________ - The ones that are available, currently rely too much on a proprietary RDMS. February 1, 1993 VERSION 1 Page 4 4. OUT-OF-BAND ACCESS Each EBS must provide some form of out-of-based access to the EBS or EBSs at there site. This should direct access to the console port of the EBS. This information should be made available to the Ebone NOC. + Recommendation 8 - Each EBS site must provide out-of-band access to the EBS. 5. EBS LOGGING All EBS logging information should be written to a local file using syslog. It is recommended that the logging level is set to debug. + Recommendation 9 - Each EBS must log router messages to a local syslog server. The text in bold type represents the areas of possible change in your local cisco configuration followed by your local syslog configuration. ! ! Local syslogger logging 128.86.1.20 logging monitor debugging ! # # Write all cisco logging messages to file # local7.debugging /usr/adm/cisco/log # 6. OPERATIONAL MAILING LISTS All EBS operators should be on the EOT list eot@ebone.net. This list should be used whenever discussing generalised Ebone operational issues. For reaching the EBS operators at the local EBS site it is recommended that the local EBS site maintain a mailing of the relevant EBS operators. It is recommended that this list is known as ``ebs- ops@EBS.site''. This information can then further be distributed by the EBS if required. + Recommendation 10 - Each EBS site must support a local mail fan-out of ebs-ops@EBS.site For an outage that will effect more than just the Ebone core it is recommended that the RIPE provided mailing list ripe-op@ripe.net be used. 7. MAINTENANCE WINDOWS It has been decided that a ``maintenance window'' be created whereby essential engineering and configuration can take place at a local EBS February 1, 1993 Page 5 VERSION 1 site. This should be done in such a way as not to clash with any other EBSs window. The table below shows the current Ebone Maintenance win- dows. All times are in UTC. _______________________________________________________ |______________________________________________________| | ULCC Friday Tuesday 07:00 - 09:00 | | CERN Monday Wednesday 16:00 - 18:00| | CNUSC Friday Tuesday 04:00 - 06:00 | | SARA Thursday Monday 16:00 - 20:00 | | KTH Tuesday Thursday 18:00 - 20:00 | |______________________________________________________| The warning deadline means noon of the day quoted which is at least one full working day before the maintenance day when notice should be given of any outage at a particular EBS. It is recommended that any outage outside of these time is restricted only to extremely critical problems that cannot be resolved inside the maintenance window. + Recommendation 11 - Each EBS site must publish it's maintenance window and announce any changes before the warn- ing deadline. 8. REFERENCES [1] T. Bates, P. Lothberg, "Ebone-92 IP routing model", June 1992. [2] J. Heinanen, "Ebone CLNS routing model", September 1992. [3] B. Stockman, "Mangement and Operations of the EBONE", April 1992. [4] B. Stockman, "EBONE Boundary System Technical Specification", April 1992. [5] D. Karrenberg, "RIPE Recommendation on Operational Contacts", April 1992. [6] B. Stockman, "A Model for Common Operational Statistics", March 1992. RFC 1404. February 1, 1993