nyu-net technical handbook

NYU-NET Technical Handbook

Search the ITS Site

Help & Information > Computer Security > Documentation > Multi-User Guidelines

NYU-NET TECHNICAL HANDBOOK

First Edition, Revised, August 26, 1994

[Ed: This document is for reference only. Much of the information contained within is now outdated. Please note especially that ACF is now known as Information Technology Services.

If you have questions about the accuracy of information contained within this document, please write to [email protected].]

Table of Contents

● Audience

● Acknowledgment

● 1. Introduction● 2. Overview of NYU-NET

❍ 2.1 Description ❍ 2.2 Connection to Internet ❍ 2.3 The Management of NYU-NET ❍ 2.4 The Network Operations Center

● 3. History of the NYU-NET Infrastructure● 4. Standard Practices and Policies

❍ 4.1 Local Network Manager Obligations ❍ 4.2 Network Changes ❍ 4.3 Security Issues ❍ 4.4 Internet Access ❍ 4.5 Host Configuration Issues

● 5. Major Protocol Suites on NYU-NET ❍ 5.1 TCP/IP ❍ 5.2 DECnet and Related Protocols ❍ 5.3 Novell IPX/SPX ❍ 5.4 AppleTalk

● 6. Configuration Guidelines ❍ 6.1 Summary of Requirements ❍ 6.2 Network Management Aspects - SNMP

● 7. Configuration Guidelines: TCP/IP Hosts ❍ 7.1 General Points ❍ 7.2 Fundamental TCP/IP Information ❍ 7.3 Unix Workstation ❍ 7.4 Apple Macintosh ❍ 7.5 IBM PC

● 8. Configuration Guidelines: Routers ❍ 8.1 General Router Issues ❍ 8.2 IP Router Configuration

● 9. Configuration Guidelines: AppleTalk Routers ❍ 9.1 General Configuration Aspects ❍ 9.2 Shiva Fastpath Configuration ❍ 9.3 Novell NetWare Configuration

● 10. Configuration Guidelines: Novell NetWare ❍ 10.1 NetWare File Server ❍ 10.2 NetWare PC Client

http://www.nyu.edu/its/security/handbook.html (1 of 55)8/31/2006 1:23:12 PM

http://www.nyu.edu/

http://www.nyu.edu/its/security/

http://www.nyu.edu/its/security/docs.html

mailto:[email protected]


● 11. Guidelines for Setting Up Departmental LANs ● 12. NYU-NET Purchasing Guidelines

❍ 12.1 Advisory: Peer-to-Peer Networking ❍ 12.2 Advisory: Network Modem Products ❍ 12.3 Standard Brands on NYU-NET

● Glossary

● Appendix A: A Description of NYU-NET● Appendix B: Obtaining Network Names and Numbers ● Appendix C: Notes on Peer-to-Peer Networking at NYU ● Appendix D: MacTCP - Availability and Installation ● Appendix E: Recommended Readings

● Addendum 1.9: Changes to the NYU-NET Technical Handbook● Addendum 2.0: Primary NYU-NET Contacts ● Addendum 3.0: NYU-NET Architecture Diagram ● Addendum 4.0: NYU Staff with Network Responsibilities● Addendum 5.0: Recent NYU-NET Developments ● Addendum 6.0: List of TCP/IP Subnets ● Addendum 7.8: Current Microcomputer Networking Software ● Addendum 8.0: AppleTalk on NYU-NET ● Addendum 9.0: Viruses and Novell NetWare ● Addendum 10.0: NetWare 4 and NYU-NET. ● Addendum 11.0: Policy on Internet Access

Audience

The primary audience for this handbook is NYU staff members responsible for planning, purchasing, configuring, and managing the systems and network infrastructure devices which collectively form NYU-NET, New York University's campus-wide data communications network.

Acknowledgment

Portions herein are based on internal ACF networking documentation developed by Bill Russell, senior networking engineer. Technical review has been performed by staff of the Academic Computing Facility's technical services group.

This document has also been reviewed for accuracy and acceptability by representatives of the university's Data Communications Task Force. Corrections or suggestions should be directed to Gary W. Chapman; send electronic mail to [email protected].

1. Introduction

This handbook describes technical aspects of NYU-NET, the university's campus-wide data communications network. Two basic kinds of information are contained here:

● technical details relevant to configuring various types of devices and systems attached to the network, and

● descriptions of standard practices and policies that must be observed on a large and complex network like NYU-NET. Chapter 4 on Standard Policies and Practices, in particular, describes many of the obligations of computer and network managers at New York University.

In the 1990s, a communications network like NYU-NET is a complex and evolving system: countless hardware and software components are used by a rapidly increasing number of students, faculty, research, and support staff as an integral part of their academic lives.

NYU-NET intermixes computer and communications technologies spanning two decades of technological evolution, with no end of new developments in sight. As a cooperative venture -- both at the level of human use and at the level of interrelated hardware and software components -- every new addition or modification to NYU-NET must fit into the established system in a conformant, seamless fashion.

It is the task of the university's computing and networking staff to preserve the smooth running of




NYU-NET while extending its use and its capabilities. The primary audience for this handbook are such staff members: network and system managers responsible for planning, purchasing, configuring, and managing the systems and network infrastructure devices which collectively form NYU-NET. These staff members are often referred to here as "local network managers."

The Network Operations Center (NOC) of the Academic Computing Facility is the focal point for NYU-NET coordination, information, and central network management activities.

To reach the NOC:

Via E-Mail (preferred): [email protected] Telephone: (212) 998-3450 or 998-3333 (the ITS Helpline)

This first edition of a NYU-NET handbook does not attempt the impossible: a complete description of all technical aspects of configuring and managing elements of the network. It does attempt to touch upon the most fundamental issues relating to configuration of the most popular protocols and kinds of devices currently used on the network.

Please note that some portions of this handbook, especially its addenda, are subject to frequent update as changes to NYU-NET take place. The handbook, and the latest versions of these sections, may be obtained electronically via anonymous ftp from acfcluster.nyu.edu in files nyunet/handbook.* It will also be available from the NYU Gopher-based Campus-Wide Information System in the NYU-NET section (gopher to gopher.nyu.edu, port 70).

2. Overview of NYU-NET

2.1 DescriptionNYU-NET is New York University's campus-wide data communications network. A computer network - especially one the size of NYU-NET - is a complex assemblage of wiring, network infrastructure devices, computer systems, and software which together allow for communications between the connected computers - and therefore between computer users.

The different kinds of communications which take place between computers and computer users are, collectively, termed "network services". Examples include: electronic mail, data file transfer, access to local and remote library catalogs and databases, and access to campus-wide information systems.

As of January 1993, NYU-NET interconnects more than 3500 computer systems located in over 40 NYU buildings. The network encompasses the Washington Square campus, the Dental Center, and Medical Center facilities in Manhattan and Sterling Forest. NYU-NET is a rapidly evolving and growing communications network, with steady addition of new locations, infrastructure devices, computers, services, and users.

A good way to understand NYU-NET is as a hierarchy of computer networks: small departmental networks in buildings; buildings tied together at each campus; each campus connected to the other campuses; and the whole of NYU-NET connected to the national and international communications network, the Internet.

See Appendix A for a more technical definition and description of NYU-NET. Addendum 3 contains an overview diagram of some major NYU-NET elements.

2.2 Connection to InternetNYU-NET is one of the thousands of computer networks which, together, comprise the Internet. Universities, private companies, government agencies, research installations and, increasingly, private individuals are interconnected via this world-wide network of networks. More than 1.3 million computers are connected world-wide to the Internet with the number growing at an apparently geometrical rate.

2.3 The Management of NYU-NETNYU-NET and its link to the world-wide Internet are managed by the Academic Computing Facility's network operations staff at our Network Operations Center - in cooperation with the cross-university Data Communications Task Force and scores of local, departmental network management staff.

The network, therefore, is maintained in a collaborative, cooperative fashion by computer and networking experts from many divisions of the university.

The Academic Computing Facility operates the Network Operations Center, which contains a variety of monitoring and fault-detection tools used to maintain NYU-NET; the staff works closely with computing professionals from around the university to ensure the smooth workings of the network,




and to quickly solve problems if they arise.The ACF also provides many educational, consulting, installation, and management services for members of the community who wish to learn about and begin to use NYU-NET, and to departmental representatives who wish to attach departmental computers to the campus-wide network.

2.4 The Network Operations Center A network operations center is a fundamental resource for managing a large and diverse internet like NYU-NET. It is concerned, from a central vantage point, to:

● Maintain network standardsThe NOC seeks to ensure that technical standards are established, understood and observed throughout NYU-NET in order to guarantee the integrity and smooth functioning of the network. Central coordination for network-related naming and numbering is an important component of this function.

● Assist in solving network-related problemsThe NOC is directly responsible for some of the network infrastructure and its services (e.g. gateways to external networks, central name service), but a large portion of the network is under the direct management control of school and departmental network managers.

The NOC does not have the resources to solve all manner of network problems for local network managers: the NOC staff will assist to the degree possible, with special concern for problems in any area of the network which may negatively affect others. In such cases, the NOC acts as a coordinating intermediary amongst the involved staff.

3. History of the NYU-NET Infrastructure

The origins of NYU-NET date back to the early 1970's - the days of early experiments with networking and the establishment of the government-sponsored ARPANET, the forerunner to today's worldwide Internet. Staff at the Courant Mathematics and Computing Laboratory were involved in those early days with research and experimental implementation to explore the feasibility and capabilities of computer networking.

In the early 1980's, New York University was among the first institutions to install Ethernet technology, attaching DEC VAX mini-computers to a Warren Weaver Hall cabling system which represented the first portion of NYU-NET. In 1982-83, cabling was extended to 715 Broadway. Protocols in use in this period were XNS, DECnet, and IP.

By late 1983 a fiber-optic link replaced the original coaxial cable between Warren Weaver Hall and 715 Broadway, and in 1984 a T1 microwave link was established between the Square and the Business school down-town. NYU-NET had become a full multi-media, multi-protocol network.

In 1985, NYU decided to install its own voice telephone system, managed by the Office of Telecommunications. A Data Task Force - forerunner to today's Data Communications Task Force - was established to investigate the possibility of using the occasion of the telephone system installation to also provide data communications infrastructure wiring from offices to phone closets throughout the campus. The Task Force recommended and supervised the installation of a multi-purpose broadband cable plant, initially connecting 35 buildings.

This CATV cable system - a.k.a. the "broadband" - is managed by a Network Operations Group (NOG); it has become a backbone cable for NYU-NET at Washington Square, providing a 5 MB Ethernet channel as well as a channel for point-to-point SNA connections via broadband modems and up to 23 cable television channels. Since this time, many additions, modifications, and enhancements have been made to the NYU-NET wiring infrastructure, including:

● fiber-optic cabling links to the Third North Residence, and to the Dental and Medical Centers● fiber-optic cabling links amongst many buildings at the Medical Center● additional broadband points of presence added in several Washington Square buildings● fiber-optic link to the newly-acquired Fairchild Building on 12th St.● establishment of leased-line links to the Public Health Research Institute and the Sterling

Forest outpost of Environmental Medicine● establishment of numerous Ethernet and LocalTalk installations within NYU buildings and

departments

For the most part, NYU-NET is currently a bridged, as opposed to routed, local area network. In the early 1990s, however, NYU-NET is making a transition to a fully-routed network.

4. Standard Practices and Policies

Because our network is managed in distributed fashion, local computer and network managers must



understand, and agree to follow, the basic practices and policies in effect on NYU-NET.

4.1 Local Network Manager ObligationsThe managers of portions of NYU-NET must be quickly reachable by the NOC, via phone and/or E-mail, in the event of a network emergency - for example a malfunctioning device negatively affecting other systems, or a security event such as a system break-in, or virus epidemic. In the event of a sufficiently serious network event caused from within a locally managed sub-network of NYU-NET, the NOC staff might be forced to disconnect that sub-network from the rest of the network until the problem can be resolved.

Local network managers must have electronic mail accounts to assist in communications with the NOC.Local network managers should take a lively interest in computer and network security issues. The sections below on Security Issues and Host Configuration Issues describe the basic security standards on NYU-NET; more detailed security measures can be explored with the NOC and ACF staff members who have significant experience in this area.

Personnel changes which affect management of the network must be communicated to the NOC.

4.2 Network ChangesThe NYU-NET Network Operations Center must be notified of the attachment of new wiring extensions to NYU-NET and of the procurement of any "network infrastructure devices" prior to their attachment to NYU-NET. Such devices include all:

● repeaters● hubs/concentrators● bridges, routers, and brouters● network modems/asynchronous gateway devices● hosts, workstations, file servers capable of routing

All such devices must be procured with SNMP capabilities and then configured with SNMP enabled in order to participate in basic NYU-NET management efforts.

When a computer or network infrastructure device (such as a hub, bridge, or router) is ready for attachment to NYU-NET, an Internet name and numeric address must be assigned by the Network Operations Center, or by an authorized NYU-NET sub-domain authority. The "database" of such Internet names and numbers is part of the "DNS" (Domain Name Service).

This rule applies to all equipment, including Novell NetWare file servers, with the general exception only of Macintoshes being attached to a LocalTalk network (which are 'named' and 'numbered" for TCP/IP purposes via the router which attaches them to NYU-NET).

4.3 Security Issues The Network Operations Center maintains liaison with the Internet CERT/CC (Computer Emergency Response Team Coordination Center at Carnegie Mellon University) and receives advisories and alerts relating to computer and network security events and issues. Any departmental or school network manager who wishes may receive copies of these advisories. (Send request via E-mail to [email protected]).

Local network managers are, in a general sense, responsible for security concerns within the portion of NYU-NET which they manage - and therefore should seek to ensure good system security within their domains. It must be realized that a given hosts's lack of integrity can potentially affect the integrity of other systems on the campus network. Basic security guidelines for local network and system managers are as follows:

● Recognize that physical security is a key to good system and network security: locate systems (including file servers and shared-access hosts) in physically secure (locked!) locations whenever possible.

● Attempt to create or utilize secure communications pathway for network cabling in so far as is practical.

● Restrict "root" or "supervisor" privileges to the minimum number of system users; turn off the ability to perform remote logins as "root" on UNIX systems. When initially configuring a new system and its accounts, provide users with the minimum necessary privileges; add account privileges over time as necessary.

● All user accounts should require both "username" and "password" authentication - avoid use of "anonymous" accounts whenever possible. Give all accounts an expiration date, and purge expired accounts after a reasonable amount of time. Actively discourage users from sharing their user names/passwords with others. Require passwords to be periodically changed, and whenever possible prevent old passwords from being re-used. When possible, require passwords to be non-trivial and of substantial length. Disable accounts of staff members who leave your department or the university. If cross-network password encryption is a viable option, use it.

● Recognize that peer-to-peering networking (as in Macintosh System 7 file sharing between




microcomputers) presents potential problems if microcomputer users do not configure their machines to prohibit 'guest' access: individual machines within departments must be carefully set up to require username/password access. Otherwise, the date on hard disks will be available to snoopers (playful or otherwise) anywhere on the network. A related problem arises when microcomputer Telnet programs are run: this programs typically allow FTP access to the microcomputer; such access should be limited through use of username/password controls.

● Employ anti-viral software on all microcomputer systems. Free software for Macintosh and IBM PC-type microcomputers is available from the ACF). Be sure to obtain updates of these programs as they become available.

● Speak to NOC and ACF staff members about security issues specific to the platforms in use in your area.

4.4 Internet AccessAnonymous - i.e. unauthenticated - access from NYU-NET to the rest of the Internet is prohibited: access to machines and services outside of NYU-NET may ONLY be made available to known and authorized account holders on shared-access machines within NYU. NYU-NET practice extends this policy to include microcomputers belonging to well-known members of the community - users who have registered their computers with the domain name service authority ([email protected]) or with delegated sub-domain name service authorities within divisions of the university.

In particular, laboratorymicrocomputers which do not require user login authentication (username/password login to a file server for example) are prohibited from direct Internet access.Local network managers are obligated to follow procedures in accordance with this policy.

4.5 Host Configuration IssuesIn accordance with Internet requirements for electronic mail service, every host computer system involved in SMTP mail delivery must have an electronic mail address of the form:

postmaster@hostname

from which users and network authorities at other institutions can seek assistance in answering mail-related questions and solving mail-related problems involving that host. As RFC-1123 "Requirements for Internet Hosts" states: 'A host that supports a receiver-SMTP MUST support the reserved mailbox "Postmaster".' As a rule, it is expected that inquiries to "postmaster" be answered within twenty-four hours of receipt.

The ACF maintains a staff "postmaster" function for the university at large, reached by the SMTP mail address [email protected]. All network-attached hosts which present a text-based display upon user login (e.g. traditional terminal-type access to VMS, UNIX machines) should provide a banner notification to users of the system, according to the following form:

"Access to this computer system is restricted to authorized account holders and its use is limited to approved educational, research or administrative activities."

The recommended form of this notification is expected to change in recognition of legal and security aspects of computer use (and misuse). Check the addenda to this handbook to see if an updated recommendation for banner notifications is available.

5. Major Protocol Suites on NYU-NET

A communications or networking protocol is a set of rules describing how hardware and software elements of the network exchange information. A protocol suite is a set of interrelated protocols.

Many such protocols and protocol suites have been (are being) developed, and NYU-NET, unlike some networks, does not mandate use of only a single protocol suite. NYU-NET is a multi-protocol network.

(It should not be thought, however, that NYU-NET is suitable now or in future for all networking protocols. The viability of Netbios, for example, is highly questionable given its non-routed design.)

The primary protocol suites in use on NYU-NET are TCP/IP, DECnet, Novell IPX, and AppleTalk.

5.1 TCP/IPTCP/IP represents, in a sense, the most important protocol suite on NYU-NET: the widest range of network services utilize TCP/IP protocols and virtually all network communications to and from the external Internet are conducted using these protocols. TCP/IP protocols can be viewed as occupying one of three basic levels, where higher-level protocols/ services (i.e., the "application" and "transport" protocols) rely on the lower-level protocols:





Application: TELNET FTP SMTP SNMP NFS RIP DNS BOOTP Transport: TCP UDP Network: IP Physical: [Assorted media access protocols, such as Ethernet 2, 802.3 Ethernet, FDDI, 802.5 Token Ring, etc.)

Protocol... Is an acronym for... providing...

TELNET -- terminal emulation

FTP File Transfer Protocol error-free file transfer

SMTP Simple Mail Transport mail transfer

SNMP Simple Network Management network management Protocol

NFS Network File System sharing disks among computer systems

RIP Routing Information Protocol routing information exchange

OSPF Open Shortest Path First routing information exchange

IS-IS Intermediate System - Intermediate System

routing information exchange

DNS Domain Name Service name/numbering information

BOOTP Boot Protocol obtaining network info at machine boot time

TCP Transmission Control Protocol reliable byte-stream data transmission

UDP User Datagram Protocol unverified packet delivery

IP Internet Protocol connectionless, best-effort packet delivery service

TCP/IP also contains various support protocols used by IP over broadcast media. These protocols are NOT routable: if two cable segments are connected by an IP-level router, these protocols are not bridged (passed) through the router - even if the router bridges all other protocol types:

ARP Address Resolution Protocol find MAC-level address when host knows IP addr

RARP Reverse Address Resolution Protocol acquire IP address when know Mac-level address

Two protocols are defined for asynchronous (serial) communications support of IP: SLIP (serial line internet protocol) and PPP (Point-to-Point Protocol). SLIP is a de facto (not official) standard protocol, with numerous host and microcomputer implementations. PPP, an emerging standard as defined in RFC-1331, "provides a method for transmitting datagrams over serial point-to-point links... and is comprised of three main components:

● A method for encapsulating datagrams over serial links.● A Link Control Protocol (LCP) for establishing, configuring, and testing the data-link

connection.● A family of Network Control Protocols (NCPs) for establishing and configuring different

network-layer protocols.

NCPs, such as for Novell NetWare's IPX/SPX, are currently in development.



5.2 DECnet and Related ProtocolsDECnet is a collection of protocols providing all the normal network service requirements. It was originally developed on and for DEC computer systems but the specifications for all of DECnet and many of the related protocols are publicly available and they have been implemented on many other systems, all the way down to MS-DOS and Apple Macintosh microcomputers.

Application level protocols include CTERM for remote login over a wide area network, DAP for transparent file access, MAIL-11, MAILbus Transport, and X.400 for electronic mail transport. These are layered on NSP, the Network Services Protocol, which provides Session and Transport layer services which are in turn layered on various transport protocols such as Asynchronous or Synchronous DDCMP, Ethernet, Token Ring, etc.

The level of DECnet currently implemented on NYU-NET is DECnet Phase IV which supports two levels of routers, adaptive least-cost routing, and a maximum of 63K nodes. A new level of DECnet being planned is DECnet Phase V which moves many services to the OSI networking protocol suite (including FTAM, X400, etc.) DECnet also include a set of auxiliary protocols such as MOP and Remote Console which exist to support downline loading, upline dumping, and remote operation of various devices, most often network infrastructure elements. DECnet protocols can be routed, but the auxiliary protocols such as MOP are parallel to the routing layer and typically must be bridged.

Associated with, but not actually part of, the DECnet protocol suite are a set of high performance local area network protocols. These protocols are designed to sit directly on a Data Link (or Data Link + lower-network) layer protocol such as Ethernet. These protocols have been optimized for local services and generally offer very high performance even under heavy loads. There is some work underway to experiment with layering them on top of IP.

The remote terminal protocol from this family is LAT (Local Area Terminal) which includes both name services and bi-directional support, and is especially efficient at handling the case of many users on a single terminal server sending data to the same host.

The remote data access protocol suite in the family is commonly called LAD/LAST (Local Area Disk/Local Area Storage Transport). It supports access to shared read-only blocked storage devices such as CD-ROMs and single-Writer multiple-Reader disks, with support recently added for sequential allocation and use of tape devices. The principle use of LAD/LAST services on NYU-NET are the DEC Infoservers which are used to provide general access to CD-ROMs as well as remote booting and paging disk services to DEC X-window terminals.

LAT and LAD/LAST protocol spaces define 255 valid groups. Group numbers must be centrally assigned and service names other than DECnet names (already coordinated) must be coordinated through the NYU-NET Network Operations Center. LAT and LAD/LAST services need to be bridged at this time.

Another important DEC protocol used on NYU-NET is the Local Area VMScluster (LAVc) protocol. This layers the DEC software which permits a group of VMS systems to act like one large system in all important respects onto an Ethernet transport layer. It too must be bridged. The LAVc protocol defines two subranges of a 16-bit cluster number space. This number space is password protected, but for best performance it should be coordinated.

5.3 Novell IPX/SPX (Novell NetWare)Novell NetWare, and associated products, use a variety of protocols collectively referred to as the "IPX/SPX" protocols.

IPX, the Internetwork Packet Exchange, is a network-layer protocol, responsible for forwarding IPX packets through IPX routers (such as Novell servers) and to end clients and servers. SPX, the Sequenced Packet Exchange, is one of two transport-layer protocols and is occasionally used for client-client guaranteed packet delivery.

More commonly, clients use the NetWare Core Protocol (NCP) packets atop a simple "Packet Exchange Protocol" for client<->server communications:



A variety of other protocols are used:

RIP the Routing Information Protocol used by IPX routers to exchange routing information

Error used to tell a destination IPX socket of an error

Echo used to test end-to-end connectivity between nodes

SAP the Service Advertisement Protocol, used by servers to advertise services (such as file or print services) or clients to find such services on the network

Netbios not a part of the "IPX/SPX" protocol suite, but implemented by Novell on top of IPX in order to provide compatibility for applications which are built to rely on Netbios capabilities.

The "NetWare Core Protocols" form a programming API for providing services to end-user applications. NCP is used to provide basic operating system services such as file and queue system access, as well bindery access, locking and synchronization capabilities, and printer access.

In recent years, NetWare systems have come to also support AppleTalk and TCP/IP protocols for native support of Apple Macintosh and Unix-based clients and for network management purposes. The NetWare Management System, for example, uses a combination of IPX and SNMP-based services for locating and monitoring network nodes.

5.4 AppleTalkAppleTalk is Apple Computer's proprietary (but licensed) network architecture, closely modeled on the OSI 7-Layer Reference Model:



There is often confusion over the differences between AppleTalk-related terms; here are the "Talk" terms and their meanings:

AppleTalk Apple's networking protocols (and software) for communications among computers systems, printers, and other peripherals attached to a network.

LocalTalk the name given to AppleTalk protocols when they are utilized over Apple's low-cost, medium-speed (230,400 bps) coaxial cabling system (or third-party twisted-pair equivalents). The "localtalk" icon in a Macintosh's Network Control Panel directs the system to use the built-in LocalTalk hardware (the printer port).

EtherTalk the name given to AppleTalk protocols when they are utilized over Ethernet media. The "EtherTalk" icon (or icons) in a Macintosh's Network Control Panel directs the system to use an Ethernet interface on the system for network communications.

Ethernet a packet delivery system (and data link-level protocol) for local area network, developed by Xerox, Intel, and DEC; today run at 10 megabits per second.

Note: In the MacTCP Network Control Panel, both "EtherTalk" and "Ethernet" icons are typically found. In this context, "EtherTalk" refers to encapsulating TCP/IP inside of AppleTalk packets on the Ethernet; "Ethernet" refers to direct use of IP on "top" of Ethernet - the norm on NYU-NET.

6. Configuration Guidelines

6.1 Summary of Requirements



Computer hardware elements on NYU-NET fall into two categories:

● End-user computing systems (e.g. microcomputers, workstations)● Infrastructure devices (e.g. repeaters, hubs, bridges, routers, file servers capable of routing)

Both kinds of computing devices must be configured for proper cooperative use on NYU-NET. Later sections of this document go into some degree of detail, but since many particulars vary from device to device or vendor to vendor, it will sometimes be necessary for network managers to consult with the Network Operations Center (NOC) to determine various configuration parameters.

Infrastructure devices, in particular, require special care from time of selection through configuration and ultimate attachment to NYU-NET in order to guarantee that they have no negative impact on the network.

Both end-users and local network managers must observe the following general rules:

● When a new end-user computing system, such as a UNIX workstation or PC, is intended for attachment to NYU-NET, its networking software must be properly configured. Most important, TCP/IP connectivity requires assignment by the NOC of a numeric address and name for the system. See the section below on Congiguration Guidelines: TCP/IP Hosts and Appendix B: Obtaining Network Names and Numbers.

● File servers, such as Novell NetWare file servers, also require careful configuration in order to coexist on NYU-NET. See the section below on Novell NetWare file server configuration.

● All new infrastructure devices to be attached to NYU-NET must be procured with SNMP capabilities, and then must be configured with SNMP enabled in order to participate in basic NYU-NET management.

● The NOC must be notified prior to the attachment of new infrastructure devices. ● Any proposed augmentation of the NYU-NET cabling system must be discussed with

networking staff members at the NOC.

6.2 Network Management Aspects - SNMPSNMP (the Simple Network Management Protocol) is the primary network management protocol used on NYU-NET. All capable systems should run an SNMP daemon (SNMPD) which allow the equipment to be asked questions about its setup, traffic counts, routing information, and so on. All new network infrastructure devices (e.g. hubs, bridges, routers) and hosts (including workstations and file servers) MUST be equipped at time of purchase with SNMP.

If there is not a local, well-maintained, SNMP network management station used by a school or department network manager, then:

1. All SNMP-manageable devices which can send traps should be configured do so. 2. Traps should be sent to the NOC, to address 128.122.128.24.

If there is a local SNMP management console, then the following rules govern the sending of traps:

1. All SNMP-manageable devices which can send traps should be configured to do so.2. Devices which can send traps to multiple management consoles should send to both the NOC

(128.122.128.24) and to the local console.3. For devices which can only send traps to a single management console:

❍ if the device is a network infrastructure device like a bridge or router, it should trap to the NOC (128.122.128.24)

❍ if the device is a purely locally managed device (e.g. a local workstation) it should trap to the local management console.

The community string "public" is used on NYU-NET.

7. Configuration Guidelines: TCP/IP Hosts

7.1 General PointsThe precise details of network hardware and software configuration depend, in every case, on the specifics of machine hardware configuration, operating system version, and network software to be used.

In general, however, it is necessary to follow these steps before connecting a TCP/IP-enabled machine to NYU-NET:

1. Prior to purchase, make sure that your networking hardware (typically Ethernet board plus cabling) is of the correct type for your local connection to the NYU-NET cabling system. For example, there are three different types of Ethernet connections: "thick", "thin", and



"twisted-pair".2. When a new machine (or network interface board) is ready to be installed, an Internet (IP)

name and numeric address must be assigned. See Appendix B: Obtaining Network Names and Numbers for details on the procedure to follow. (This step is not necessary if you are installing a Macintosh on a LocalTalk network.)

If you are installing a Macintosh on an Ethernet, see Appendix D which describes MacTCP and its installation, including the procedure used to obtain the Ethernet address (firmware address) of a Macintosh Ethernet interface.

3. The Academic Computing Facility and Network Operations Center wish to guarantee that all workstations and other TCP/IP devices be configured correctly for NYU-NET, and will provide assistance to assist departmental staff in configuring and attaching these devices to the network.

7.2 Fundamental TCP/IP Information for NYU-NET

Q. What is the name of the network?

A. NYU-NET. The Internet domain name for NYU-NET is "NYU.EDU".

Q. What is the network number?

A. NYU-NET is assigned a Class-B Internet network number: 128.122.0.0 (in hex: 80.7A.00.00)

Q. How are network addresses and names assigned?

A. For TCP/IP address and name assignment, send E-mail to [email protected] or to your local school authority for network address and name assignment. For details, see Appendix B: Obtaining Network Names and Numbers.

Q. Is subnet routing done on NYU-NET?

A. To a limited (but growing) degree. The numeric address space of NYU- NET's class B network (128.122.0.0) is sub-divided into 254 8-bit subnets (128.122.x.0), where x can range between 1 and 254.

For the most part, these are "logical" subnets, since the physical network segments for these subnets are not yet, for the most part, behind IP routers. As more routers are introduced, "logical" subnets become true, physical, routed subnets. Addendum 6 provides a complete listing of NYU-NET subnets which are currently in use, with indication of whether or not they are currently "logical" or "routed" subnets.

Q. Within subnet "x", what addresses can be assigned to nodes on NYU-NET?

A. Address 128.122.x.2 through 128.122.x.253 may be used. 128.122.x.0 means the subnet itself. 128.122.x.1 is the bridge/router connecting this subnet to NYU-NET 128.122.x.254 is reserved for test equipment 128.122.x.255 is reserved for IP broadcasting

Q. What is the network mask?

A. For logical subnets, 255.255.0.0 (FF.FF.00.00). For routed subnets, 255.255.255.0 (FF.FF.FF.00).

Q. What is the broadcast address?

A. For logical subnets, 128.122.0.0 (80.7A.00.00) For routed subnets, 128.122.x.255 (80.7A.XX.FF)

Q. Why isn't the broadcast address 128.122.255.255 for logical subnets?

A. Because of a technical problem with various implementations of TCP/IP that are derived from the BSD 4.2 UNIX distribution. Once the last group of Suns running SunOS 3.2 through 3.5 are gone from the bridged backbone, we will be able to switch universally to the official IP broadcast address form (all-1s in the host portion).




Q. What is the default router for machines on NYU-NET?

A. For logical subnets, 128.122.128.44 (NYEGRESS.NYU.EDU) For routed subnets, 128.122.X.1 (the router which attaches subnet X to NYU-NET)

Q. What domain are NYU-NET machines in?

A. All NYU-NET machines are in the domain "NYU.EDU". But most machines are identified specifically in a "sub-domain" of NYU.EDU such as "med.nyu.edu" or "stern.nyu.edu" or "acf.nyu.edu". The use of sub-domains continues the hierarchical Internet naming scheme into NYU-NET, and allows greater precision in naming machines to indicate their ownership.

Q. What are the official NYU-NET names servers?

A. The Academic Computing Facility operates the primary NYU.EDU domain name servers:

EGRESS.NYU.EDU 128.122.128.24 CMCL2.NYU.EDU 128.122.128.2 NYUNSB.NYU.EDU 128.122.129.2

The Stern School of Business and the Medical Center also maintain domain names servers for their delegated subdomains MED.NYU.EDU and STERN.NYU.EDU.

EXCHANGE.STERN.NYU.EDU 128.122.130.1 CAMBIO.STERN.NYU.EDU 128.122.188.145 MCCLB0.MED.NYU.EDU 128.122.135.4 MCHIP00.MED.NYU.EDU 128.122.205.115

In the case of machines in 'med.nyu.edu', the ACF's name servers (EGRESS, CMCL2, NYUNSB) act as secondary name servers; med.nyu.edu hosts may be configured to use ACF name servers in case of local name service failure.

The proper TCP/IP configuration for workstations (/etc/resolv.conf typically) and microcomputers with respect to domain name service depends, therefore, upon the location of the computer on NYU-NET.

Q. What TCP/IP routing protocol is used on NYU-NET?

A. RIP, the "Routing Information Protocol".

Q. What external TCP/IP routers are there on NYU-NET?

A. There are two routers to external networks:

128.122.128.44 NYEGRESS.NYU.EDUNYSERNet/PSINet IP router connects network NYU-NET (128.122.0.0) to network NYU-EXT-NET (199.76.177.0), and thence to the rest of the Internet.

Only routers and multi-homed network service hosts are found on NYU-EXT-NET.

128.122.128.129 ENTRADA.NYU.EDURouter to ESnet (Energy Science network), to IP network 134.55.0.0

7.3 Unix WorkstationAll UNIX computers, including both workstations and minicomputers, come equipped for TCP/IP networking. You will need to consult the operating system documentation in order to learn the precise and full details (and commands) for performing the networking configuration. The examples below pertain to a traditional, BSD-type machine and attempt only to provide the "highlights" of performing its networking configuration.

When first booting a UNIX machine, you can expect its console to display the

● Ethernet device designation



(e.g. "le0" for a Lance Ethernet Interface or "ie0" for a Intel Ethernet Interface)

and the● firmware Ethernet address in the form NN:NN:NN:NN:NN:NN.

The Ethernet device designation is needed (on some machines) for its configuration; when obtaining an IP name and number from the Network Operation Center (see Appendix B), report the firmware address.

The basic steps which need to be accomplished are:

● configure the Ethernet interface (set basic TCP/IP parameters) ● configure the loopback address ● configure for IP routing ● configure the internet daemon (inetd) ● configure the domain name resolver ● edit configuration files

Configure the Ethernet InterfaceIn this example, the ifconfig (interface configure) command is used to assign the IP address, subnet mask and broadcast address to the interface.

Given the following features, and assignment of IP address by the NOC,

● Ethernet Interface: le0 ● IP Address: 128.122.x.y ● Name: newmachine.nyu.edu ● Location: on logical subnet 128.122.x.0

then the correct netmask is 255.255.0.0 and the broadcast address is 128.122.0.0. The ifconfig command is:# ifconfig le0 128.122.xx.yy netmask 255.255.0.0 broadcast 128.122.0.0

If subnet "x", on the other hand, was a "routed" subnet (i.e. behind an IP router), then the correct netmask would be 255.255.255.0 and the broadcast address would be 128.122.x.255:# ifconfig le0 128.122.x.y netmask 255.255.255.0 broadcast 128.122.x.255

Configure the Loopback AddressIt is sometimes necessary to configure the IP address of the "loopback" interface, which is used for troubleshooting purposes. The ifconfig command for this purpose is:# ifconfig lo0 127.0.0.1

127.0.0.1 is used on all machines for the loopback address.

If your machine has the netstat command installed, you can use it to identify and check the configuration of its network interfaces:# netstat -ain

Ifconfig displays configuration and status information for a known interface, e.g.# ifconfig le0

might display something like:le0: flags=63< UP,BROADCAST,NOTRAILERS,RUNNING > inet 128.122.x.y netmask ffff0000 broadcast 128.122.0.0

Configure for IP routingIf the machine is diskless, you should set a default route. For example, on a BSD-based machine you can do this as follows.

For a machine on a logical subnet:% /etc/route add default 128.122.128.44 1

For a machine on routed subnet X:% /etc/route add default 128.122.X.1 1

If the machine is not diskless, and you can spare a process slot and some memory and CPU cycles,



you can run a routing daemon to listen (only) for dynamic routing information. Again, on a BSD-based machine you do this with the command:% /etc/routed -q

This command will configure the machine to listen only, and not itself propagate IP routing information.

Configure the Internet Daemon The internet daemon (inetd) is started at boot time, reading its configuration from the file /etc/inetd.conf. This file contains the identities of the TCP/IP services which the internet daemon will run upon client request.

You should comment out the line which configures tftp, since tftp is rarely used and, if improperly configured, can represent a security hole.

Configure the Domain Name ResolverThe domain name resolver is software which allows TCP/IP applications to translate between IP names and numbers, e.g. to determine that the user command:# telnet ACF1

means to telnet to the IP address 128.122.128.11.

Typically, the resolver configuration is kept in the plain-text file /etc/resolv.conf and consists of only a few lines:# Sample domain name resolver configuration file # domain NYU.EDU nameserver 128.122.128.24 nameserver 128.122.128.2 nameserver 128.122.129.2

A machine at the Medical Center or Stern School (which have their own primary name servers) would have a different /etc/resolv.conf file which first lists local nameservers.

Edit Configuration FilesTCP/IP implementations traditionally also use a variety of text configuration files, especially:

● /etc/hosts ● /etc/networks ● /etc/protocols ● /etc/services

Since the advent of the domain name service (DNS) the importance of /etc/hosts is vastly reduced. The NOC discourages you from attempting to build up an old-style, huge hosts file. You should, however, make an entry in this file for the machine itself: # sample /etc/hosts file # 127.1 localhost 128.122.x.y newmachine.nyu.edu

The /etc/networks file should contain, minimally, the following two lines:# sample /etc/networks file # 127 loopback-net 128.122 nyu-net

The /etc/protocols and /etc/services files typically require no special configuration.

7.4 Apple Macintosh Every Apple Macintosh which is to communicate via TCP/IP on NYU-NET must be assigned an internet name and number by the Network Operations Center. See Appendix B: Obtaining Network Names and Numbers.

The NOC strongly recommends the use of BOOTP to provide network-related information at boot/run-time to all microcomputers on the network. Information provided includes the IP address of the requesting microcomputer, as well as the identity of name servers and external routers - thereby reducing the necessity for management of ASCII configuration files on individual microcomputers.

Use of BOOTP also assists network managers in limiting off-campus Internet access to authorized



members of the community.

TCP/IP applications for Apple Macintosh rely upon Apple's MacTCP drivers: use of MacTCP frees the software developer from a great deal of work implementing the core TCP/IP protocols. The Academic Computing Facility has licensed MacTCP on behalf of New York University for use on machines connected to NYU-NET. See Appendix D: MacTCP - Availability and Installation for a detailed discussion of installing MacTCP on NYU- NET Macintoshes.

The majority of Macintoshes on NYU-NET which utilize TCP/IP protocols do so with non-commercial (no cost!) software developed primarily at other universities on the Internet, including:

● TELNET: Telnet from NCSA/BYU TN3270 from Brown University

● FTP:Fetch from Dartmouth College

● E-Mail: Eudora (originally from U. Illinois, now from Qualcomm, Inc.) Pegasus Mail with Clarkson University's Charon SMTP gateway

● Gopher:Gopher Client to NYU Campus-Wide Information Service from University of Minnesota

Here is a portion of a configuration file for NCSA/BYU Telnet, showing valid TCP/IP-related settings. Be sure to observe the FTP-related settings, as this version of Telnet also can act as an FTP server (incoming file transfer requests to your Mac); at a minimum, this capability should be password protected.



7.5 IBM PCEvery IBM-type PC which is to communicate via TCP/IP on NYU-NET must be assigned an internet name and number by the Network Operations Center. See Appendix B: Obtaining Network Names and Numbers.

The NOC strongly recommends the use of BOOTP to provide network-related information at boot/run-time to all microcomputers on the network. Information provided includes the IP address of the requesting microcomputer, as well as the identity of name servers and external routers - thereby reducing the necessity for management of ASCII configuration files on individual microcomputers.

Use of BOOTP also assists network managers in limiting off-campus Internet access to authorized members of the community.

The majority of IBM-type PCs on NYU-NET which utilize TCP/IP protocols do so with non-commercial (no cost!) software developed primarily at other university's on the Internet, including:

TELNET: Telnet/TN3270 from Clarkson UniversityNCSA TelnetMS Kermit from Columbia University

FTP: Clarkson University FTPNCSA FTP

E-Mail: NUpop from Northwestern UniversityPegasus Mail with Clarkson University's Charon SMTP gateway

Gopher Gopher Client to NYU Campus-Wide Information Service from University of Minnesota

The capabilities of all these software packages are based upon PC use of a "packet driver". The original packet driver concept was to develop Ethernet board drivers which would allow multiple



protocols to co-exist in a PC - especially to allow a NetWare client to run TCP/IP software packages while attached to a file server.

Packet drivers were originally distributed by Clarkson University, but are now distributed by Crynwr Software on a no-cost basis.

It should be noted that many commercial TCP/IP software offerings for PCs are not compatible with Crynwr packet drivers; use of such software on a PC might preclude ready use of the non-commercial TCP/IP software listed above.

For users of Novell ODI network board drivers, there is a special packet driver (ODIPKT) which allows packet driver-based TCP/IP software to run on top of ODI.

A typical PC packet driver configuration (e.g. in autoexec.bat) would be:

1. wd8003e 0x7f 0x0A 0x300 0xCC00 2. winpkt 0x7e 0x7f

Line [1] loads the packet driver for Western Digital Ethernet boards, grabbing software interrupt 0x7f for subsequent communications between software and the packet driver. In this particular case, the Ethernet board is set up for IRQ 10, I/O port 300, RAM (paragraph) address of CC00. IRQ 10 is a good choice on AT-class (or above) PCs, as it does not conflict with standard PC hardware devices (e.g. serial and parallel ports).

Line [2] is a special packet-driver "shim" which is designed to allow the basic WD packet driver to function safely under Microsoft Windows. Note that software interrupt 0x7e is now used for applications to communicate with the packet driver.

A TCP/IP application would then be configured for packet driver use. Here is a portion of a configuration file for Clarkson Telnet, showing valid packet driver and TCP/IP-related settings. Be sure to observe the FTP-related settings, as this version of Telnet also can act as an FTP server (incoming file transfer requests to your PC); at a minimum, this capability should be password protected.



8. Configuration Guidelines: Routers

8.1 General Router IssuesRouters are networking devices which "route" or "forward" data packets from one machine to another and from one network to another network. There are many different kinds of routers, depending upon the specific functions desired and the type of software and hardware used to perform them. One special type of router is called a "brouter" - a device which "routes" some protocols, and "bridges" others.

Above all it should be remembered that routers route specific protocols: there are IP routers for communications via TCP/IP; there are IPX routers for communications via the Novell IPX protocol; there are AppleTalk routers for communications via AppleTalk protocols used by Apple Macintosh computers. There are routers which only route one kind of protocol; there are multi-protocol routers which can handle many protocols simultaneously.

Note the following facts:

● Almost any UNIX workstation or minicomputer can be (mis)configured as a router. See the section above on Unix Workstation Configuration for basic guidelines in this regard.

● Any AppleTalk device which interconnects AppleTalk networks may be an Appletalk router. A Macintosh can run software (e.g. Apple's Internet Router software) and become an AppleTalk router.

● A Novell server is automatically an IPX router. A Novell server may also be configured as an AppleTalk or as an IP router.

Routers and brouters require special care in their selection, configuration, and installation. The Network Operations Center must be advised of and consulted on all bridge, brouter, and router procurement and installation prior to purchase.



The most prevalent types of routers on NYU-NET are:

● Novell file servers (IPX, AppleTalk, potentially TCP/IP) ● Shiva "Fastpath" AppleTalk routers ● Multi-Protocol dedicated routers (for TCP/IP above all)

Novell server and Shiva router configurations are discussed in sections below.

8.2 IP Router ConfigurationBecause of the importance of the TCP/IP protocol suite on NYU-NET and the intricacies of TCP/IP routing, IP routers require careful attention.

IP routers, for routed physical subnets of the form 128.122.x.0, must be configured according to the following guidelines:

Subnet mask: 255.255.255.0 Broadcast address: 255.255.255.255

The network address of a router's interface that is attached to the NYU- NET backbone MUST HAVE an address on the 128.122.128.0 subnet (to allow proper routing information exchange among routers).

The network address of a router's interface to routed subnet x should be 128.122.x.1.

Note that a host on a subnet "x" can only directly communicate with other hosts on the same subnet "x". Thus, for example, two hosts

128.122.x.4 (on routed subnet 128.122.x.0)128.122.y.4 (on logical subnet 128.122.y.0)

cannot "see" or communicate with each other (even if they are located on the same physical cable segment): they require a router to forward packets between them.

During NYU-NET's transition from bridged to fully-routed network this situation arises frequently: the need to forward packets between a routed subnet "x" and an un-routed "logical" subnet "y".

(See the section above Fundamental TCP/IP Information for a discussion of subnet routing on NYU-NET and an explanation of the distinction between "logical" and "routed" subnets).

So router 128.122.x.1 must forward packets to logical subnet "y" - which requires the router to have an "interface" (an address) on the logical subnet. For example, it can be assigned 128.122.y.253.

For each and every logical subnet to and from which the router needs to forward packets, such a "secondary IP address" from the logical subnet must be assigned to the router.

So during this transitional period, IP routers must be assigned a number (not predictable) of secondary IP addresses within logical subnets, so that they can "pretend" to have interfaces on



those "subnets", so they can "route" packets between their subnet interfaces.

9. Configuration Guidelines: AppleTalk Routers

All network infrastructure devices which utilize AppleTalk protocols must be assigned AppleTalk network numbers by the Network Operations Center ([email protected]) in order to guarantee uniqueness across the campus.

Such devices are:

● Shiva Fastpath or other Ethernet/LocalTalk routers ● Novell NetWare file servers and external bridges ● Macintoshes running Apple (or other) internet routing software ● Shiva LanRover or other AppleTalk Remote Access servers ● Multi-Protocol (e.g. Cisco) routers ● Any device which is capable of "defining" an AppleTalk "zone"

All such devices must be configured correctly in several respects in order to co-exist on the network.

The majority of AppleTalk routers on NYU-NET are Shiva Fastpath routers (formerly Kinetics Fastpath) and Novell NetWare 3.11 file servers. Shiva Fastpaths require especially careful configuration, as they are versatile devices which can perform several functions beyond basic AppleTalk routing (e.g. encapsulation of TCP/IP packets within LocalTalk packets).

9.1 General Configuration AspectsConsider NYU-NET as having a "backbone" Ethernet cabling system to which routers are attached. NYEGRESS.NYU.EDU and ENTRADA.NYU.EDU are the two "external routers" which lead to networks outside of NYU. All other routers are "internal routers" which segment NYU-NET into subnetworks; there is no "external router", at this time, which routes AppleTalk protocols to the outside world.

From the AppleTalk point of view, the NYU-NET "backbone" is a pure AppleTalk Phase 2 internet, i.e. all routers which attach to the backbone are configured for Phase 2-only with zone "NYU Ether" on the backbone side.

All Macintoshes, and any other systems which "speak" AppleTalk which are connected to Ethernet cabling systems on NYU-NET must be configured to use "Phase 2" drivers. Macintoshes on "localtalk" cabling systems continue to use their "built-in" LocalTalk network drivers.

As of winter 1992-1993, the AppleTalk network numbering range for the "backbone" is

10-20

and

NYU Ether

is the only AppleTalk zone defined for this range.

Important: please note that zone names are "case-sensitive"; routers on NYU-NET must be configured with "NYU Ether" - not "NYU ETHER" or any other variation.

9.2 Shiva Fastpath ConfigurationThe Shiva Fastpath 5 is the most prevalent AppleTalk internet router on NYU-NET; the most commonly-used capabilities of this device are as a gateway between LocalTalk and Ethernet cabling segments, and as a provider of dynamic IP addresses to Macintoshes on a LocalTalk segment. The discussion below for properly configuring a Shiva Fastpath is based on its standard use for these functions; configuration issues for less commonly used functions should be discussed with the NOC staff.

Any router has two or more ports; the Shiva Fastpath 5 has two: an Ethernet port and a LocalTalk port, each of which must be configured correctly. In the configuration process, a new AppleTalk "zone" may or may not be defined: the devices on the LocalTalk side of a Fastpath may be defined as part of a new zone, or as part of an existing zone on NYU- NET. It is thus possible for a geographically dispersed unit of the university (like the ACF) to have all of its LocalTalk devices appear in the same zone ("NYU ACF" in the case of the ACF).

As of Spring 1993, only a single AppleTalk zone appears on the NYU-NET Ethernet backbone - "NYU




Ether". As Ethernet-Ethernet routers are introduced into NYU-NET, multiple Ethernet sections of the campus network will be assigned one or more zones. See Addendum 8, AppleTalk on NYU-NET, for up-to-date information on this subject.

Here are guidelines for setting the various parameters for a Shiva Fastpath; please note that, at several points, information is required which must be obtained from or discussed with the NOC (e.g. AppleTalk network numbers, TCP/IP network numbers, new zone names).

When viewed with the Shiva NetManager application, several major configuration sections are found:

● Gateway ● At Startup ● LocalTalk Configuration ● Ethernet Configuration

The "Show LocalTalk Configuration" and "Show Ethernet Configuration" buttons are used to expand these configuration sections allowing viewing and setting of the relevant parameters.

In describing parameter settings below, only "selected" items (selected with a "check" next to the item) are described; unless mentioned here, check boxes should be left empty (unselected).

At the very top of the Shiva NetManager configuration screen, a box is available for entering the "name" of the FastPath. The NOC recommends DNS-style naming (using the assigned TCP/IP name of the device), e.g. WWH-MGW.ACF.NYU.EDU is used for ACF's FastPath located in Warren Weaver Hall.

Gateway section:

Serial Number Every Fastpath is labeled with a serial number sticker. Enter the serial number here.

This section also shows various information about the FastPath, such as its Ethernet address, the date of last configuration, and versions of the software last used to download it.

At Startup section: Register "Fastpath" in...

The Fastpath must be "registered" in "LocalTalk". This means that the device will appear as a device in the zone on the LocalTalk side of the Fastpath. LocalTalk Configuration section: AppleTalk Zone: .......

The AppleTalk zone defined by this Fastpath, or in which this FastPath is to be registered, is entered here. Creation of new zones on NYU-NET must be done in coordination with the NOC.

AppleTalk Network Number: ..... AppleTalk network numbers must be unique across NYU-NET. Obtain a valid network number

for the LocalTalk side of the FastPath from the NOC.

As a rule, "Use DDP Checksums" option should be selected. However, there is a known problem with this setting and Apple LaserWriter NTR printers installed on the LocalTalk side of Fastpaths. If you have LaserWriter model NTR printers so located, "Use DDP Checksums" should not be selected at this time.

Ethernet Configuration section: EtherTalk Phase 2

The "EtherTalk Phase 2" box should be checked; "EtherTalk Phase 1" must NOT be checked.

Start Net.../ End Net... / Default Zone... The values should be left BLANK. This makes the FastPath a non-seed AppleTalk router. (If

the parameters were set they would be set to 10 / 20 / NYU Ether as of Spring 1993).

DECnet (sub-section): As a rule, the DECnet configuration section should be left BLANK.

IP Configuration (sub-section): The following values are correct as of Spring 1993; some of these values will change in the

future as TCP/IP routers are introduced. (Check addenda to this document to see if different values are recommended).

IP Address of FastPath: 128.122.mmm.nnn An IP address must be assigned by the NOC to new FastPaths.



IP Subnetwork Mask: 255.255.0.0 This will be different in future for FastPaths behind TCP/IP routers.

IP Broadcast Address: 128.122.0.0 This will be different in future for FastPaths behind TCP/IP routers.

IP Address of Default Router: 128.122.128.44 This will be different in future for FastPaths behind TCP/IP routers.

IP Address of Name Server: 128.122.128.24 Medical Center FastPaths can use a local name server if desired.

IP Address of File Server: 0.0.0.0 The "Use BSD 4.2 Broadcast address" should not be checked. "Address Gleaning" should be

checked.

IP Forwarding (sub-section): In most cases on NYU-NET, FastPaths are used to provide IP forwarding services for

Macintoshes located on their LocalTalk side; the FastPath provides dynamic IP address assignment as well for as many Macintoshes as desired. The set of dynamically assignable IP addresses is pre-allocated in the DNS, and configured into the FastPath with the settings typically as follows, where "N" represents the agreed-upon number of IP addresses:

N Dynamic IP Clients 0 Static IP Clients

IP Forwarding Options: Normal Forwarding

The "Disable Proxy NBP ARP" item SHOULD be checked.

IPTalk (sub-section): Typically NOT selected.

SNMP (sub-section): FastPaths are SNMP-manageable. In this section, basic identification and contact information

is provided:

● Contact: (Name of responsible person, phone number)● Name: (Name of FastPath; the NOC recommends DNS-style naming, e.g. WWH-MGW.ACF.

NYU.EDU is used for ACF's FastPath located in Warren Weaver Hall)● Location: (The building/floor/office location of the FastPath)● Host Address: 128.122.mmm.nnn (the IP Address of the FastPath)● Trap Address: 128.122.128.24 (the standard SNMP trap address on NYU-NET).

Atalkatab (sub-section): As a rule, NOT selected.

9.3 Novell NetWare ConfigurationAny Novell NetWare 3.x (or greater) file server which has NetWare for Macintosh NLMs loaded will function as an AppleTalk router. Several lines in the configuration file AUTOEXEC.NCF determine the AppleTalk configuration.

In particular, the "load appletlk" command assigns an Appletalk network number to the server _itself_ and designates the AppleTalk zone in which the AFP file server will be advertised; for example,

load appletlk net=9876 zone={"NYU SERVERSZONE"}

On NYU-NET, AppleTalk network numbers and zone names are centrally assigned by the NOC.

See the section below on Configuration Guidelines: Novell NetWare for an annotated example of the AUTOEXEC.NCF file.

10. Configuration Guidelines: Novell NetWare

10.1 NetWare File ServerTwo versions of Novell NetWare are in common use at New York University: NetWare 2.x and NetWare 3.1x. These two versions differ substantially in their features and manner of configuration.

NetWare 2.x requires a "generation" or "re-generation" process to set its parameters; NetWare 3.1x



is far easier to configure and re-configure (if necessary): only its AUTOEXEC.NCF configuration file needs to be edited and (at most) the server be restarted.

Several NetWare configuration parameters relate to NYU-NET standards:

1. Ethernet packet type

NYU-NET exclusively uses "Ethernet 2" (ethernet_ii) packet types for Novell NetWare, as opposed to the default Novell 802.3 packet type. Ethernet 2 is the standard because Novell's 802.3 is not correctly formatted 802.3. A server (and client PCs) which did not use Ethernet 2 would be unable to communicate with the majority of Novell devices on campus, would possibly cause problems with third- party NetWare print servers, and would possibly conflict with systems which utilize correct 802.3 packets.

NetWare 3.x file servers are configured for Ethernet 2 in the "AUTOEXEC.NCF" configuration file; NetWare 2.x file servers require that, after "netgen" is run, the ECONFIG program be used to change the packet type. The following command is used:

econfig net$os.exe a:e 8137

This example assumes that the servers primary (first, "a") interface is connected to the NYU-NET backbone.

Similarly, the NetWare workstation software (IPX.COM) must be set to use Ethernet 2 packets, if a standard, old-fashioned WSGEN shell is used:

econfig ipx.com shell:e 8137

This is not the case, however, if the PC uses a packet driver-based ipx.com or if Novell's ODI drivers are used.

2. Backbone IPX network address

The IPX network address of the NYU-NET backbone is 807A0000; during a NetWare 2.x "netgen" this number is used when you are prompted for the network "address". This number is also used in the NetWare 3.x "AUTOEXEC.NCF" configuration file (see below for an example).

3. Internal IPX network address

NetWare 3.x file servers require an "internal" IPX network address which needs to be unique across the campus network. NYU-NET practice is to assign an IP address to each server and derive the internal IPX network address from this IP address (see below).

4. NetWare also "does" AppleTalk and TCP/IP

The sample "AUTOEXEC.NCF" file below illustrates proper configuration of a NetWare 3.x server for AppleTalk and TCP/IP purposes.

The following template AUTOEXEC.NCF file illustrates the proper configuration of a NetWare 3.1x server on NYU-NET. Explanatory notes explain many of the parameter settings. ; Template AUTOEXEC.NCF file for NetWare 3.1x file servers ; on NYU-NET ; ; This file illustrates configuration commands for a server ; supporting both PCs and Macintoshes (via NetWare for Macintosh) ; [1] ; System Supervisor: Susan Q. Expert ; E-Mail address: [email protected] ; [2] file server name NYUFILESERVERNAME



[3] ipx internal net 807A0502 ; [4] set allow unencrypted passwords=on load nmagent [5] load ups type=mouse discharge=8 recharge=36 ; [6] load NE2 slot=3 frame=ethernet_ii name=ipx_ip load NE2 slot=3 frame=ethernet_snap name=etalk2 ; [7] load appletlk net=9876 zone={"NYU SERVERSZONE"} ; [8] load tcpip rip=no trap=128.122.128.24 load snmplog ; [9] bind IPX ipx_ip net=807A0000 ; [10] bind APPLETLK etalk2 net=10-20 zone={"NYU Ether"} ; [11] bind IP ipx_ip addr=128.122.5.2 mask=0xff.0xff.0x0.0x0 \ bcast=128.122.0.0 ; load remote load rspx mount all ; [12] load afp ncpw delay300 load atps -v ; [13] patchit.ncf ; load monitor

Explanatory notes: [1] ; System Supervisor: Susan Q. Expert ; E-Mail address: [email protected] All departmental network managers must obtain campus electronic mail addresses in order to facilitate communications with other NYU-NET networking groups and staff members. [2] file server name NYUFILESERVERNAME

The file server name is decided upon by the system supervisor for that server. There is no authoritative server naming scheme, but the following guidelines follow from NYU-NET tradition and common sense: use relatively short names which attempt to capture the ownership of the server;



where a department has more than one file server, a number can be used as part of the name. For example, the Controller's Division has file servers named:

CDVFS01 (file server) CDVGW01 (SAA gateway)

The ACF has used file server names which reflect the locations of the server, e.g.

ACFSE - ACF Server at the Education building ACFSW - ACF Server at 14 Washington Place

Names of more than 10 or 12 characters may not display well by programs which assume that file servers will have short names. [3] ipx internal net 807A0502

The internal IPX network address of each NetWare file server must be unique across NYU-NET. In order to guarantee this uniqueness, the following scheme is used: A. Obtain a TCP/IP address for the file server from the NYU-NET Network Operations Center. See Appendix B for a description of the information required to accomplish this. The assigned addressed is guaranteed to be unique across NYU-NET. B. Take the assigned address - e.g. 128.122.5.2 - and convert each of its elements from decimal to hexadecimal pairs:

128.122.5.4 --> 80 7A 05 02

C. The resultant number - 807A0502 in this example - is used as the internal ipx network number. [4] set allow unencrypted passwords=on

Most Novell servers on NYU-NET do not use encrypted passwords, because this makes a variety of third-party print servers unusable, and complicates logins from Apple Macintoshes. [5] load ups type=mouse discharge=8 recharge=36

Using a 'ups' (Uninterruptable Power Supply) on file servers is strongly recommended. [6] load NE2 slot=3 frame=ethernet_ii name=ipx_ip load NE2 slot=3 frame=ethernet_snap name=etalk2

In this example, the network board driver 'NE2' is loaded twice, once for 'ethernet_ii' packets (used by IPX and IP protocols) and again for 'ethernet_snap' packets (used by AppleTalk protocols).

All Novell file servers on NYU-NET MUST be configured to use the "ethernet_ii" packet type for standard PC-to-server communications. This is a departure from Novell's out-of-the-box 802.3 packet-type, done because Novell's 802.3 uses non-standard, pseudo-802.3 data packets which might cause problems with networking equipment on campus which utilizes correct 802.3. [7] load appletlk net=9876 zone={"NYU SERVERSZONE"}

9876 (just an example!) is the internal AppleTalk network number for this server; this number is centrally assigned by the NYU-NET Network Operations Center (or delegated local authorities) in order to guarantee uniqueness across NYU-NET.

The zone name - the AppleTalk zone in which this file server will "appear" - is also centrally assigned; if the server is not being configured to appear in a pre-existing AppleTalk zone, than a request must be sent to 'hostmaster' regarding the establishment of a new AppleTalk zone. (Send E-Mail to [email protected]). [8] load tcpip rip=no trap=128.122.128.24load snmplog

Every Novell 3.1x server on NYU-NET MUST load these TCP/IP and SNMP NLMs in order to provide minimal compliance with campus- wide network management via SNMP.




[9] bind IPX ipx_ip net=807A0000

The IPX protocol is used on net 807A0000, the network address for the NYU-NET backbone cabling system.

The number 807A0000 MUST be used. [10] bind APPLETLK etalk2 net=10-20 zone={"NYU Ether"}

The server communicates over the backbone via AppleTalk protocols using network range 10-20; the name of the "backbone zone" is "NYU Ether". Routing for AppleTalk Phase 2 ONLY is permitted on the NYU-NET backbone. [11] bind IP ipx_ip addr=128.122.5.2 mask=0xff.0xff.0x0.0x0 \bcast=128.122.0.0

This command configures the server for TCP/IP protocols. Substitute the correct internet (IP) address for the server for "addr=128.122.5.2" (just an example number!). [12] load afp ncpw delay300

When loading "afp" (AppleTalk Filing Protocol) to support Macintosh file service, a "delay" parameter like "delay300" reduces the frequency of server updates of Mac workstation desktops.

(The ACF uses the 'ncpw' - no change password - parameter, which prohibits Macintosh users from changing their passwords. This is done because ACF servers are part of a NetWare name service domain in which passwords changed from PCs are synchronized across servers in the domain; passwords from MACS are not similarly synchronized, thanks to insufficient Macintosh support by Novell.) [13] patchit.ncf

Load NetWare operating systems patches from another .ncf file; the ACF uses one called "PATCHIT.NCF".

10.2 NetWare PC ClientThere are several software alternatives for DOS clients to Novell servers. In all cases, the workstation software necessary for PCs to communicate with servers is "terminate-and-stay-resident". Special provision must be made for PCs running Microsoft Windows (i.e. extra software elements are used), and particular care should be taken to always run the _latest_ version of Windows/NetWare-related software components.

A key consideration when using Novell (or other network operating system software) in the NYU-NET context is the availability (and possible cost) of compatible TCP/IP-based network applications. This is because a majority of campus-wide network services (e.g. electronic mail, campus- wide information service access, library catalog access) are offered via TCP/IP protocols and not NetWare protocols (IPX).

The PC workstation software for Novell server access is generically called the NetWare "shell". The various possible configurations which may be used are:

1. Old-fashioned custom-generated workstation shell

One component of the workstation software (IPX.COM) is customized by the network manager for the specific network board and its settings for each individual PC. This is the least flexible option, and Novell no longer recommends it. TCP/IP-based software (like Clarkson Telnet and Kermit) cannot generally be used while such a workstation shell is loaded.

If this option is used on an Ethernetted PC at NYU, it is necessary for the IPX.COM file to be set to use "Ethernet II" framing. This is done with a utility called ECONFIG. (The NET$OS.EXE server operating system executable for NetWare 2.x file servers must also be ECONFIG'ed.)

2. Packet driver-based standard workstation shell

Here, a pre-configured Crynwr "packet driver" (specific to the model of network board being used) underlies a pre-configured, traditional-style IPX.COM. Originally the IPX.COM used for this purpose was generated by BYU; a more up-to-date version comes from Intel, and is found under the name of PDIPX.COM. As found on Internet archives and bulletin boards,



PDIPX.COM needs to be 'econfiged' for the Ethernet 2 packet type; this step has already been performed in ACF-distributed copies.

This solution was originally designed to allow the use of TCP/IP applications (like NCSA Telnet) while a NetWare shell is loaded on a PC, and is probably the most common Novell client configuration found on NYU-NET in early 1993.

This may be the optimal configuration for users who primarily use packet driver-based TCP/IP software, but also need some NetWare server access.

3. New-fashioned Novell standard shell sitting atop an ODI (Open Data- Link Interface) network board driver; a PC-based configuration file (NET.CFG) sets any network, PC, or board-specific parameters. This is the official Novell-recommended configuration.

Here are extracts from typical configuration files for PCs using ODI:

AUTOEXEC.BAT FILE:lslsmc8000 <-- for SMC (Western Digital) boardsodipkt 0 127 <-- packet driver atop ODI; interrupt 0x7Fwinpkt 0x7E 0x7F <-- packet driver shim for Windows useipxodi <-- if using Novell NetWarenetx.exe <-- if using Novell NetWareNET.CFG FILE:Link supportbuffers 10 2048 Link driver SMC8000 <-- for SMC (Western Digital) boardsFrame ETHERNET_IIPort #1 300 20 <-- board set to I/O 300Mem #1 CC000 2000/10 <-- board set to RAM CC000Int #1 10 <-- board set to IRQ 10Protocol IPX 8137 ETHERNET_IIProtocol IP 0800 ETHERNET_IIProtocol ARP 0806 Ethernet_II <-- if using Novell NetWare, thenSHOW DOTS = ON <-- use this sectionREAD ONLY COMPATIBILITY = ON LONG MACHINE TYPE = IBM_PC SHORT MACHINE TYPE = IBMIPX RETRY COUNT = 50SPX ABORT TIMEOUT = 4000FILE HANDLES = 99 <-- should match config.sys files=99PRINT HEADER = 255PRINT TAIL = 50CACHE BUFFERS = 0GET LOCAL TARGET STACKS = 10PREFERRED SERVER = ACFS1 <-- substitute local file server

Novell's TCP/IP workstation software, Lan WorkPlace, is one of several networking products which is compatible with ODI drivers. There is also a special "packet driver" (ODIPKT.COM used in the example above) which sits atop ODI drivers and allows use of networking software written to the packet-driver specification (like Clarkson Telnet).

This may be the optimal configuration for users whose primary concern is NetWare access, but sometimes use packet driver-based TCP/IP programs.

4. Microsoft Windows for Workgroups NDIS-based NetWare client software.

Microsoft's peer-to-peer PC networking software, Windows for Workgroups, is distributed with Novell NetWare compatible software. At initial release (late Fall 1992) this software uses a modified NDIS protocol stack which is not compatible with ODI- or packet driver-based software. As a result, commercial TCP/IP based application software must be run. In the future, Microsoft promises Windows for Workgroups software which runs directly atop TCP/IP, which would better fit into the NYU-NET context than the initial Netbios-based networking software.

Please see Appendix C: Notes on Peer-to-Peer Networking at NYU for more information on the viability of Windows for Workgroups on NYU-NET.

11. Guidelines for Setting Up Departmental LANs

Establishing a new departmental local area network (LAN) involves many choices and tradeoffs. It is recommended that departmental representatives take the following steps:



● inventory current department computer hardware and software, and determine if any NYU-NET connections are already in place; make a departmental floor-plan indicating the locations of telephones, computers, printers.

● survey department staff to determine their communications/networking needs, bearing in mind that the full versatility and value of a departmental network may not be known to people unfamiliar with the technology.

● gauge the availability of funds for enhanced computing/networking purposes, both at this time and in coming years.

● gauge the availability and ability of internal school/departmental staff to competently manage a LAN, given the following minimum responsibilities: participate in initial installation; train/assist departmental staff; perform basic hardware and software troubleshooting; obtain and install software updates; maintain departmental computing procedures, especially with regard to backup; act as departmental liaison to the NYU-NET Network Operations Center.

● bring this information to a consultation with staff members at the Academic Computing Facility who will discuss with you benefits and costs of various networking alternatives. Installation and maintenance services performed by the ACF may also be available.

● In the past, some departments have engaged outside consultants to design, install, and even manage departmental networks. Problems have developed in some cases when the outside consultants were unfamiliar with NYU-NET conventions or characteristics. The ACF will gladly work cooperatively with consultants and departmental representatives to prevent any such problems.

NYU-NET standard practices should serve as models for new installations; departmental network planners should therefore consider the following points:

● Ethernet is the predominant physical connection method on NYU-NET; token-ring is reserved for the exceptionally stout of heart, Arcnet should be avoided entirely.

● New Ethernet installations within departmental offices are typically twisted-pair (10BASET) Ethernet; occasionally thin Ethernet (10BASE2) is utilized in laboratory or other contexts where a number of machines are located in the same room; all 10BASET hubs or other concentrators must be purchased with SNMP (network management) capabilities.

● Novell NetWare is the predominant network operating system used by departmental networks, so quite a bit of local expertise exists.

● Finite bandwidth across the NYU-NET backbone exists; therefore any cross-building departmental networks must be very carefully planned in conjunction with the ACF and the Network Operations Center.

● Four to six years after installation, a departmental network is likely to be at least partially "obsolete". Within this interval, various components will require replacement or enhancement, and software may be upgraded many times. Planners are advised to consider both short and long-term budgetary implications of computer networking.

12. NYU-NET Purchasing Guidelines

With few exceptions, the choice of networking devices and software is up to the school/department making the purchase; the Network Operations Center staff is ready to advise on the compatibility and suitability of a wide variety of infrastructure and end-user computing devices.

In some cases, such as basic infrastructure objects like routers and bridges, it is customary for the Academic Computing Facility to purchase the devices (with departmental transfer of funds) and install them on behalf of schools and departments.

12.1 Advisory: Peer-to-Peer NetworkingProspective purchasers of peer-to-peer network operating system products such as:

● Windows for Workgroups ● Lantastic ● NetWare Lite

should be sure to consult with the Network Operations Center staff as there may be serious limitations to the use/utility of such products on NYU-NET. If such a product is based on standard routed protocols such as TCP/IP, IPX, or AppleTalk then they should function well at NYU; if, however, they are based on Netbios like Windows for Workgroups and Lantastic, then they may not function well at all in a routed network environment like NYU-NET.

12.2 Advisory: Network Modem ProductsProspective purchasers of network modem-service devices such as NetModems, LanRovers, and so on should consult with the Network Operations Center. The ACF maintains a large network modem pool which is growing in size and flexibility; local network modem services will not be necessary if the central pool can satisfy a department's requirements.



12.3 Standard Brands on NYU-NETThe most common, standard brands of networking hardware and software used on NYU-NET are as follows:

Ethernet boards:

● IBM-type PC - SMC (formerly Western Digital) ● Apple Macintosh - Apple, Asante; transceiver connectors from Asante ● Novell Server - Novell (typically 16- or 32-bit)

10BASET hubs:

● Digital Equipment Corporation ● David Systems ● Cabletron Systems

● LocalTalk hubs: ● Farallon

Bridges/Routers:

● ACC (brouters) ● Cisco ● Digital Equipment Corporation ● Shiva (Fastpath)

File Server Operating Systems:

● Novell NetWare 3.11 ● Apple AppleShare file server

Novell NetWare Backup Software:

● Cheyenne ArcServer NLM (version 4.0)

3270 Gateway Support:

● NetWare for SAA 3270 Gateway (server portion) ● 3270 LAN Workstation for DOS/Windows/Macintosh (Client portion) ● Rumba 3270 for Windows and OS/2 (client portion)

Uninterruptable Power Supply (UPS):

● American Power Conversion Smart-UPS w/Power Shute Plus 386

Glossary

ACFcluster The Academic Computing Facility's group of VMS-based minicomputers, unified through the Local Area VMScluster (LAVc) protocol. This collection of machines is a major provider of network-based services to the NYU user community, especially electronic mail services.

Address A unique code assigned to each device connected to a network. A device may have different and multiple kinds of addresses associated with it: (a) physical address - e.g. the Ethernet address built-in to an adapter; (b) network address - e.g. the IP address assigned to a network interface of a computer for IP purposes, the DECnet address assigned for DECnet purposes.

AppleTalk Apple's networking protocols (and software) for communications among computers systems, printers, and other peripherals attached to a network.

BOOTP (BOOTstrap Protocol) A client-server, UDP-based protocol for providing network-related startup information including IP host, domain name server, and gateway addresses. This protocol is heavily used at New York University by IBM PC-type and Macintosh microcomputers. The ACF maintains a



set of redundant BOOTP servers.

Bridge A device which interconnects (at the data link layer) two sections of network cabling; a data packet is retransmitted from one side of a bridge, typically, if the packet's destination is on the other side. A bridge, therefore, constrains unnecessary traffic across a network.

Brouter A device which contains characteristics both of bridges and routers: a brouter will bridge some protocols, and route others.

Broadband A network technology which multiplexes multiple, independent network carriers (channels) onto a single cable. The NYU "broadband" is a CATV- type coaxial cable plant, carrying a 5 megabit "Ethernet" channel, a channel for multiplexing point-to-point connections via RF modems, and multiple video channels. A "buffered repeater" is a device used to attach a baseband Ethernet cable segment to the broadband cabling system.

CCITT The Comite Consultatif International Tekegraphique e Telephonique International; a standards-making body administered by the International Telecommunications Union.

Client A software or hardware component of a system which obtains services from other components, called servers. For example, the user of a client PC can access files over a network from a file server, and may print to a shared printer via a print server.

DCTF (Data Communications Task Force) At New York University, the interdepartmental organization which coordinates operation of NYU-NET.

DECnet A full set of network service protocols, quite distinct from the TCP/IP protocols but providing many of the same capabilities, originally developed on and for DEC computer system but now implemented on many other platforms. The level of DECnet currently implemented on NYU-NET is DECnet Phase IV; DECnet Phase V, now under development, moves many services to the OSI networking protocol suite.

Domain Name System (DNS) The application protocol offering naming service in the Internet suite of protocols.

Ethernet A best-effort packet delivery system for local area networks, invented by Xerox in the mid-1970s and formalized by DEC, Intel and XEROX (DIX). Notable for its use of a "collision detection" mechanism in which simultaneous transmissions by network devices are detected and retransmissions performed.

Ethertalk The designation given to AppleTalk protocols when utilized on Ethernet media.

FTP (File Transfer Protocol) The application protocol in the Internet suite of protocols offering file services.

Gateway A computer system, typically a dedicated special-purpose device, which attaches to two or more networks and routes packets among them. More commonly referred to as a "router" today. The term "gateway" is also commonly used for a variety of devices which route network information from one type of system to another, such as a "mail gateway" which converts and transfers electronic mail from one type of mail system to another.

Gopher A distributed information-service protocol (and set of implementations); increasingly used for deploying network-accessible campus-wide information services and other repositories of data. Developed and maintained by the University of Minnesota.

Host Any computer system that connects to a network; typically used in the context of TCP/IP network where it usually refers to end-user systems.

Internet A set of networks interconnected via routers into a single virtual network. An IP internet is connected by IP routers; an AppleTalk internet is connected by AppleTalk routers. NYU-NET is a member network of the worldwide TCP/IP "Internet".

IP (Internet Protocol) The network layer protocol in the TCP/IP protocol suite, providing connectionless, best-effort packet delivery service across a TCP/IP internet. Defines the IP datagram as the fundamental unit of information passed between systems.

IPX/SPX



Network layer (Internetwork Packet Exchange) and transport layer (Sequenced Packet Exchange) protocols used by Novell NetWare for communication among clients and servers.

Kermit A file transfer protocol (and set of implementations) developed originally at Columbia University, now implemented for most commonly- used computers and operating systems. Requires only a 7-bit data path, allowing its use over and through virtually all communications systems.

LAN (Local Area Network) Any one of a number of technologies providing high-speed, low-latency transfer and being limited in geographic size.

LocalTalk The name given to AppleTalk protocols when they are utilized over Apple's low-cost, medium-speed (230,400 bps) coaxial cabling system (or third-party twisted-pair equivalents).

MacTCP Apple Computer's standard implementation of the TCP/IP protocol stack for Apple Macintosh computers. Most Macintosh TCP/IP applications are written to sit atop MacTCP.

MIME (Multi-purpose Internet Mail Extensions) The emerging standard for incorporating multi-media mail contents into Internet (SMTP-based) electronic mail; a set of extensions to SMTP now in the early stages of development and deployment.

Netbios A network protocol, typically used for peer-to-peer network communications, which allows a client to communicate with a server process. Not supported as an NYU-NET protocol.

Network A collection of inter-connected computer systems, typically composed of end-user computers, wiring (or other communications medium), and infrastructure connection devices (such as hubs, bridges, routers).

NIC (Network Information Center) An organizational focal point for providing network information to end- users. Often association with a "network operations center" (NOC).

NIU (Network Interface Unit) A terminal server - connecting asynchronous communication devices such as terminals, modems, and microcomputers to an Ethernet - manufactured by Ungermann-Bass and widely used at New York University. Many NIUs on NYU-NET connect physically to the "broadband" cabling system, but more specifically to the Ethernet channel on that cable. A few NIUs are "baseband" NIUs, and connect to Ethernet cables.

NNTP (Network News Transfer Protocol) The application protocol offering news article transfer service in the Internet suite of protocols. Thousands of news "groups" (each on a different topic) are read and contributed to by people all over the world.

NOC (Network Operations Center) A network operations center is a computer network's focal point for network coordination, information, and central management activities. The NOC for NYU-NET is managed by the university's Academic Computing Facility.

NOG (Network Operations Group) At New York University, the group which maintains the University's "broadband" cable system - a cable TV-type cabling system with multiple "channels" for different kinds of data; some channels are used for computer data communications and some are used as video channels.

NetWare The flagship product of Novell Incorporated, using Intel-based PCs as file and print servers. An extremely versatile product, NetWare can support a wide range of client systems: DOS and OS/2 PCs, Macintoshes, and UNIX machines.

NYU-NET New York University's campus-wide data communications network.

Operating System The primary program which runs in a computer and allows other programs to run and use the machine's hardware capabilities. Most IBM-type PCs run the DOS operating system; a newer operating system for PCs is IBM's OS/2. Most minicomputers and workstations use the UNIX operating system.

OSI (Open Systems Interconnection) A collection of standards and protocols, developed by the ISO (International Standards Organization), for the interconnection of computer systems from different vendors.



Physical layer That portion of a network system responsible for the electro-mechanical interface to a communications medium and that communications medium itself.

POP (Post Office Protocol) An application protocol in the Internet suite of protocols offering mailbox retrieval.

Protocol / Protocol Suite A "protocol" is a set of rules describing and formalizing some aspect of a communications process between computer system elements. A "protocol suite" (such as TCP/IP) is a set of interrelated protocols.

RARP (Reverse Address Resolution Protocol) A TCP/IP protocols which a client (e.g. a diskless) machine can use to obtain IP information at boot time. Little used on NYU-NET.

Router A computing device attached to one or more physical networks responsible for forwarding packets from one network to another as necessary. A router typically works at the "network" layer, as compared with a bridge, which works at the data-link layer. On NYU-NET, one finds:

Network Layer Device

Network Router

Data Link Bridge

Physical Repeater, Buffered Repeater

A "multi-protocol" router is capable of routing multiple protocols (e.g. IP and AppleTalk and IPX) and can typically act as a bridge for protocols which are non-routable.

SMTP (Simple Mail Transport Protocol) The application protocol in the Internet suite of protocols offering message transfer and submission service.

SNMP (Simple Network Management Protocol) The application protocol in the Internet suite of protocols offering network management service.

Subnet A physical network within an IP network.

Subnet Mask A 32-bit quantity indicating which bits in an IP address identify the physical network.

TCP/IP (Transmission Control Protocol/Internet Protocol) The two fundamental communications protocols in the Internet suite of protocols, providing for error-free communications of an arbitrarily large inter-connection of computer networks (the Internet). End-user service programs, like Telnet and FTP, are built "on top of" TCP/IP.

Telnet The application protocol offering virtual terminal service in the Internet suite of protocols.

Terminal Server A communications device which connects multiple asynchronous communication devices such as terminals, modems, and microcomputers to a network.

UNIX The multi-user, multi-tasking operating system used on most workstations and minicomputers. There are many variants of UNIX.

VMS The Digital Equipment Corporation (DEC) operating system which runs on DEC workstations and minicomputers (such as the ACFcluster). A multi- user, multi-tasking, virtual memory-based system.

XNS The Xerox Network System, a network architecture which survives today, primarily, as the source and basis for Novell NetWare's IPX/SPX protocol suite.

X.25 The CCITT standard for packet-switched networks.

X.400 The CCITT standard for message handling services (electronic mail).

X.500 The CCITT standard for directory information on an X.400 network.



Appendix A: A Description of NYU-NET

NYU-NET may be characterized as a

multiple media The networking infrastructure of NYU-NET is composed of many building blocks: cabling of different kinds (e.g. fiber-optic, coaxial, copper twisted-pair) and infrastructure devices which interconnect the wiring of different types. The resulting "multiple media" cabling plant is flexible and adaptable to new users and new technologies.

multi-protocol A multi-protocol network is one that can be used by different communications protocols simultaneously. "Protocols" are the "rules" for communications between computers, and many sets of such rules are currently in wide use. Some computer networks are restricted to using a single communications protocol; NYU-NET, by comparison, has been designed for the greater flexibility afforded users of a multi-protocol network.

standards-based The hardware, software, and communications protocols used on NYU-NET are "standards"-based. That is, they are defined and designed in accordance with "standards" (some official, some de facto; some written, some not) which thereby permit a wide variety of equipment to cooperatively interoperate. The core (but not sole) standards observed by NYU-NET equipment are those of the TCP/IP protocol suite.

multi-campus NYU is comprised of several different campuses; NYU-NET ties together these locations using different media depending on the needs of users at a particular campus. Some of the connections are via high speed fiber-optic cable, and some are via slower leased telephone lines.

multi-building At each campus center of the university, a different wiring media may be used to interconnect the various buildings, thus forming a "backbone network" at that campus. At Washington Square the backbone wiring currently is a CATV broadband cabling system; at the Dental Center, an Ethernet backbone is used; at the Medical Center a complex collection of fiber optic and coaxial cabling forms the backbone tying buildings together.

evolving NYU-NET is an evolving, rapidly-growing entity. As technology has advanced, and continues to advance, the network adapts to changes in the computer field and in end-user needs.

bridged extended local area network. NYU-NET is, for the most part, a bridged - as opposed to a routed - network. Bridging technology was adopting in the early years of NYU-NET (mid 1980s) for cost and convenience reasons. At selected locations, however, routers have recently been introduced as the first steps in the evolution of NYU-NET from a bridged to a routed network. A full transition to a routed network may not take place until 1994, since this evolution must be slowly and carefully implemented in order that network users not be negatively impacted by the transition.

Appendix B: Obtaining Network Names and Numbers

When a computer or network infrastructure device (such as a workstation, PC, hub, bridge, or router) is ready for attachment to NYU-NET, an Internet name and numeric address must be assigned by the Network Operations Center, or by a authorized NYU-NET sub-domain authority.

This rule applies to all equipment, including Novell NetWare file servers, with the general exception only of Macintoshes being attached to a LocalTalk network segment. The "database" of such Internet names and numbers is part of the "DNS" (Domain Name Service).

Most NYU-NET protocols require coordinated networking naming and numbering: TCP/IP, AppleTalk, Novell IPX, and DECnet.

For address and name assignment, send E-mail to [email protected] or to your local school authority for network address/name assignment.

The following information is required:

● Proposed name of machine: ● Type of machine: ● Machine operating system: ● Location of machine: ● Person responsible for machine:




● E-mail address of responsible person: ● Ethernet address of machine:

All PC and Macintosh microcomputers which are assigned IP addresses and names by the NOC are required to use the BOOTP protocol to obtain authoritative IP information at the runtime. When the addresses and names are assigned, entries in BOOTP tables are also made. Other divisions of the university are strongly encouraged to adopt the use of BOOTP as well.

In the case of machines at the Medical Center, the Stern School, and several smaller locations, sub-domain naming authority has been delegated to network managers at those locations:

● Medical Center - send E-Mail to [email protected] ● Stern School - send E-Mail to [email protected] ● 10th/12th Floors - send E-Mail to [email protected] ● 715/719 Broadway (this is 128.122.129.0 subnet) ● CIMS - send E-Mail to [email protected] subnets 153 and 140 in WWH and 715/719

Broadway)

Appendix C: Notes on Peer-to-Peer Networking at NYU

Microcomputer networks fall into two rough categories: server-based and peer-to-peer. In a server-based network, there's one or more rather powerful machines (servers) which individual PCs or Macintoshes can access - e.g. they can store files on the server's hard disk or print on a printer attached to the server. In a peer-to-peer network, individual microcomputers can access the resources of other microcomputers - e.g. user A can print on user B's printer.

There are various gradations between these two poles: for example, with Macintosh System 7, "file sharing" between Macintoshes is a built-in operating system feature. This capability can be used in combination with a file server - there is no conflict between Macintosh peer-to-peer file sharing and file server access.

In the case of Macintosh peer-to-peer networking, the only problems which arise in the larger NYU-NET context are security- related: individual machines must be carefully set up to require username/password access. Otherwise the data on hard disks will be available to snoopers (playful or otherwise) anywhere on the network.

Third-party add-on products (such as Lantastic or NetWare Lite) typically provide peer-to-peer networking for IBM-type PCs. With the release, however, of Microsoft's Windows for Workgroups, peer-to-peer networking is for the first time an "operating system feature" on IBM- type PCs. While peer-to-peer networking of PCs is not very common at New York University, there are various departmental networks - unattached to NYU-NET - which use such products (particularly Lantastic).

There are serious problems using IBM PC peer-to-peer networking on machines or departmental networks attached to NYU-NET. These derive from the protocols used:

Peer-to-peer products like Windows for Workgroups typically use the Netbios protocol for network communications. Unfortunately, Netbios was not designed with large internets (like NYU-NET) in mind; it is unlikely that Netbios-based products will work across the NYU-NET multiprotocol routers planned for installation in 1993.

In order to use TCP/IP-based utilities (such as TELNET) in conjunction with such products, it is typically necessary to purchase additional commercial TCP/IP software - the standard "free" TCP/IP software commonly used at NYU doesn't work in combination with peer-to-peer networking products.

Windows for Workgroups - although basically Novell NetWare compatible - is not compatible with Novell ODI drivers, the recommended data-link drivers for Novell NetWare.

Many organizations have banned Windows for Workgroups on their networks as a result of the technical, support, and security issues involved in its use. In fact, as of Winter 1992-93, Microsoft has released information on how to disable various networking features of the product and has announced that peer-to-peer networking features will not be a standard part of MS-DOS 6. These changes resulted from wide-spread concerns about integrating Windows for Workgroups into pre-existing networks.

If Microsoft releases TCP/IP transport support for Windows for Workgroups, as promised, then it should fit into NYU-NET as well as does Macintosh System 7: primary concerns at that point will be privacy of local data and the possible necessity still for commercial TCP/IP utilities to be purchased



for full NYU-NET functionality.

As of March 1993, the ACF and the Network Operations Center strongly recommend AGAINST purchasing or using Windows for Workgroups on machines attached via network connections to NYU-NET; if end-users deploy the product and later wish to attach their departmental networks to NYU-NET, it may be required that the product's networking capabilities be disabled.

Appendix D: MacTCP - Availability and Installation

MacTCP is Apple Computer's TCP/IP networking software for Macintosh computers. This software provides the necessary foundation for other Mac networking software (such as the Eudora electronic mail program and the NCSA Telnet terminal emulator).

The Academic Computing Facility has licensed MacTCP on behalf of New York University for use on machines connected to NYU-NET.

MacTCP, as configured and distributed by the ACF, requires that Macintoshes obtain their fundamental networking information via the network itself at the time that the software is used. For a Mac on a localtalk network, this means that a Shiva Fastpath gateway (to the rest of NYU-NET) provides IP information to the Mac; for a Mac on a Ethernet which is part of NYU-NET, MacTCP is configured to obtain IP information via the BOOTP protocol. This configuration policy is designed to simplify installation and configuration for end-users, and reduce the possibility that misconfigurations will occur.

If your Mac is directly connected to an 'Ethernet' network, a unique Internet address must be assigned it prior to your being able to use MacTCP-based networking software. Note the instructions in step 4 (B), below.

To obtain MacTCP:

A copy the MacTCP software - properly configured for use on NYU-NET - can be obtained from the Academic Computing Facility, Faculty Micro- computer Laboratory, Room 312 Warren Weaver Hall (212-998-3044). A floppy disk is required. Hours 12 noon - 8 PM.

Note: When using MacTCP 1.1 (now outdated) on a Macintosh Plus running System 7, be sure to use Apple's MacTCP+ Tool to overcome serious performance problems with MacTCP on that system. MacTCP version 1.1.1 or later rectifies the problem with MacTCP 1.1, and the MacTCP+ Tool is no longer required.

To install MacTCP:

1. Turn off any virus protection software you have installed on your Macintosh (with the exception of Disinfectant, which presents no problems).

2. On a System 6 Macintosh, drag the MacTCP control panel into your System Folder. Continue with step 3 below.

On a System 7 Macintosh, drag the MacTCP control panel on top of the closed System Folder, and watch it go into the System Folder's Control Panels folder. Continue with step 3.

3. Restart your Macintosh.

4. Select Control Panel(s) from the Apple Menu. ❍ If your Mac is on a 'localtalk' network, make sure that the Network control panel has

'LocalTalk' (Built-In) selected. Continue with step 5 below.

❍ If your Mac is on an 'Ethernet' network, make sure that the Network control panel has 'Ethertalk' selected. On the Ethernet, your Macintosh _must_ be assigned its own, unique Internet address. If this has not already been done, send electronic mail to [email protected] and provide the following information:

■ Your name ■ Your departmental affiliation ■ Your phone number ■ Location of your machine, and model of Macintosh ■ Proposed name for your machine (e.g. 'smithmac' or 'jonesmac') ■ Built-in Ethernet address of your Macintosh

You obtain the built-in Ethernet address of your Macintosh by performing 'option-click' on the 'Ethernet' icon in the MacTCP control panel. The numerical Ethernet




address will materialize just below the Ethernet icon.❍ Open the MacTCP control panel, and click on the "More..." radio button. Observe the

"Domain Name Server Information" in the lower right-hand quadrant of the display. Two entries should appear, as follows:

Domain IP address Default

nyu.edu 128.122.128.2 *

. 128.122.128.24

Note the "." (period) below "nyu.edu".

These settings must be correct, in this fashion, for MacTCP to be able to correctly query NYU-NET's redundant name servers. If you find different settings, you will want to obtain an updated version of the MacTCP control panel from the Academic Computing Facility.

5. If you disabled Virus protection in step 1 above, re-enable it now.

6. At this point, MacTCP-based networking applications (such as NCSA Telnet) can be installed.

Appendix E: Recommended Readings

Comer, Douglas E. Internetworking with TCP/IP, Volume I: Principles, Protocols, and Architecture, Second Edition, Prentice-Hall, 1991.

The classic textbook for gaining basic knowledge about the TCP/IP protocol suite and a fundamental understanding of internetworking principles and issues.

Hunt, Craig. TCP/IP Network Administration, O'Reilly & Associates, 1992. A practical guide for UNIX system managers, which detailed specific examples drawn from Berkeley, SCO, and UNIX System 5 versions of UNIX.

Kosiur, Dave and Nancy E. H. Jones. MacWorld Networking Handbook, IDG Books Worldwide, Inc., 1992.

An excellent practical guide to understanding, setting up, and managing AppleTalk networks.

Malamud, Carl. Analyzing Novell Networks, Van Nostrand Reinhold, 1990. A now-aging, but still excellent, overview of Novell NetWare and its protocols. Emphasis is on NetWare 3.x and related products.

McCann, John. NetWare Supervisor's Guide, M&T Books, 1992. A practical guide to Novell NetWare management, covering both NetWare 2.2 and NetWare 3.11 versions. Provides both background networking information as well as many practical hints.

Sidhu, Gursharan. Inside AppleTalk, Second Edition, Addison Wesley, 1990. The authoritative guide to the AppleTalk protocol suite.

Stallings, William. Handbook of Computer-Communications Standards, Volume 2: Local Area Network Standards, Second Edition, Howard W. Sams & Company, 1990.

An authoritative and fairly technical reference source for understanding the basic IEEE 802 standards; also covers such diverse topics as network topologies, FDDI standards, MAC-layer bridges and the Spanning Tree algorithm, the OSI reference model, and error detection.

Addendum 1, Revision 9, 8/26/94

Changes to the NYU-NET Technical Handbook9. 8/26/94 Updated: Addendum 7.8 - Current Microcomputer Networking Software - Update of some NetWare components and SMC SuperDisk 6.5 and Win32S 8. 7/01/94 Updated: Addendum 7.7 - Current Microcomputer Networking Software - Addition of Microsoft Windows software Update of WINPKT and ODIPKT 7. 11/14/93 Updated: Addendum 7.6 - Current Microcomputer Networking Software - Addition of Novell updates 6. 09/27/93 New: Addendum 11.0 - Policy on Internet Access 5. 09/27/93 Updated: Addendum 7.5 - Current Microcomputer Networking Software - Addition of many updates 4. 09/11/93 Updated: Addendum 7.4 - Current Microcomputer Networking Software Addition of 3 NetWare updates: seclog.exe, pserv5.exe, isa311.exe 3. 08/06/93 New: Addendum 10.0 - NetWare 4 on NYU-NET



2. 08/02/93 Updated: Addendum 7.1 - Current Microcomputer Networking Software - Addition of many NetWare updates 1. 06/23/93 New: Addendum 9.0 - Viruses and Novell NetWare 0. 06/01/93 Edition 1 published


Primary NYU-NET Contacts

In order to... Contact...

Obtain general end-user informationand assistance

ACF HelpLine(212) 998-3333

Contact Network Operations Center on NYU-NET and external network issues

E-Mail: [email protected](212) 998-3450

Request network numbers/names E-Mail: [email protected]

Arrange for consulting assistance on setting up departmental networks

Gary W. Chapman, Coordinator Systems & Networks Services, ACF(212) 998-3045E-Mail: [email protected]

Discuss aspects of networking at New York University with other members of the community

Network news group: nyu.nyunet

Discuss NYU-NET policies and future developments

George Sadowksy, ChairData Communications Task Force(212) 998-3040E-Mail: [email protected]


NYU-NET Architecture MapIt is impossible, in a simple diagram, to fully indicate the architecture of NYU-NET with its many connection media, sub-nets, service hosts (such as routers and name servers), and end-user equipment. The following sketch shows the basic connection of NYU-NET to the Internet and some of the basic media connections to different NYU areas.






NYU Staff with Network Responsibilities

[Ed: This list is no longer current or accurate.)



Name E-Mail Affiliation

Carlo Cernivani [email protected] ACF/NOC

Gary Chapman [email protected] ACF/NOC

Mario Clagnaz [email protected] ACF

Eray Ekici [email protected] ACF

Edi Franceschini [email protected] ACF

Larry Mingione [email protected] ACF

Gary Rosenblum [email protected] ACF/NOC

Bill Russell [email protected] ACF/NOC

George Sadowsky [email protected] ACF

Stephen Tihor [email protected] ACF

Scott Baker [email protected] Admin/Personnel/Ctrller

Gillian Carter [email protected] Admin/Faculty Records

Jeff Dong [email protected] Admin/Purchasing

Alex Garrison [email protected] Admin/Sponsored Programs

Jim Gibby none at present Admin/Reprographics

Amy O'Hara [email protected] Admin/Sponsored Programs

John Johnson none at present Admin/Career Services

Irene Zabarkes [email protected] Admin/Office- President

Diane Aquila [email protected] BOBST

Scott Yates [email protected] BOBST/Microlab

Susan Kallenbach [email protected] BOBST

Tim O'Connor [email protected] BOBST

Kathy Bear [email protected] Book Center

Andy Hagerty [email protected] CIMS

Andy Howell [email protected] CIMS

Matthew Smosna [email protected] CIMS

Bob Picardi [email protected] CNS/Psychology

Jeff Fookson [email protected] CNS

Ariel Spivakovsky [email protected] CNS

David Tanzer [email protected] CNS

Eric B Buvron [email protected] DENTAL/AIS

David Romand [email protected] DENTAL



Frank Boyer none at present FAS/Expository Writing

Dan Chusid none at present FAS/Journalism

Allan Gottlieb [email protected] FAS/CS Ultra Lab

Cathy Moran Hajo [email protected] FAS/History

Edward J. Huff [email protected] FAS/Chemistry

Robert Jackson [email protected] FAS/Sociology

Helen Jones [email protected] FAS/Applied Science

Richard Kenner [email protected] FAS/CS Ultra Lab

Ken Rogoza [email protected] FAS/Economics

Steve Wilson [email protected] FAS/Chemistry

Moy Wong [email protected] FAS/Psychology

Julie Baker [email protected] LAW

Kina Leitner [email protected] LAW/MIS

Stuart Spore [email protected] LAW/Library

Joe Dorn [email protected] NOG

Basil Katradis [email protected] NOG

Serf Aguas [email protected] MED/MIS

Kenny Chu [email protected] MED/Medical Library

Michael Downs [email protected] MED/MIS

Suzy Gottesman [email protected] MED/Cell Biology

John Graefe [email protected] MED/Sterling Forest

John Hill [email protected] MED/Cell Biology

Sanj Hiranandani [email protected] MED/MIS

DJ James [email protected] MED/Sterling Forest

Sara Kranczer [email protected] MED/Pharmacology

Jim Kyriannis [email protected] MED/PHRI

Pierre Landau [email protected] MED/Brain Research Labs

Peggy Lim [email protected] MED/Medical Library

Ravi Narsipur [email protected] MED/GCRC

Marilyn E. Noz [email protected] MED/Nuclear Med

David Ohlmer [email protected] MED/Sterling Forest

Danny Orellana [email protected] MED/CC/Pediatrics

Frieda Pavel [email protected] MED/Cell Biology

Edwin Ramirez [email protected] MED/Library



Keith Ruskin [email protected] MED/Anaesthesiology

Ross Smith [email protected] MED/Cell Biology

Roy Smith [email protected] MED/Microbiology

Mark Waldman [email protected] MED/Environmental Med

Zelda Owens Waters [email protected] MED/ADARC

Ron Wood [email protected] MED/Sterling Forest

Troy Downing [email protected] SEHNAP/Art

Nixy Kuttemperoor [email protected] SEHNAP/HEOP

Flo Ragusa [email protected] SEHNAP/Metro Center

Don Plym [email protected] SEHNAP/Music

Bob Corre [email protected] Stern/CIS

Rafael Esparra [email protected] Stern/CNS

Stanley Fogg [email protected] Stern/CNS

Daniel Graham [email protected] Stern/CNS

Binh Ho [email protected] Stern/ATG

Manny Ho [email protected] Stern/CNS

Damir Mijacika [email protected] Stern/CNS

Carlos Webb [email protected] Stern/CNS

Karl Wieman [email protected] Stern/ATG

Jeffrey Berg [email protected] TSOA/ITP

Bill Bruns [email protected] TSOA/Student Affairs

Catherine Holter [email protected] TSOA/Cinema Studies

Michael Keeler [email protected] TSOA/Info Services

Phil Sanders [email protected] TSOA/ITP

Joe DiMeo [email protected] UCC

Ted Dzierzynski [email protected] UCC

Kwong Kam [email protected] UCC

Efim Rubenchik [email protected] UCC

Sharif Samman [email protected] UCC


Recent NYU-NET Developments Transition to Phase 2-only AppleTalk Routing Complete, 2/19/93 AppleTalk NYU-NET Backbone Re-Numbering Performed

In early February, the last remaining Phase 1 - Phase 2 transitional AppleTalk routers were reconfigured for Phase 2 routing only. At that point the backbone network range remained "3-3", allowing a maximum of 253 Ethertalk devices on the campus network as a whole. This number was



achieved during February, leading to intermittent AppleTalk problems on the network. On February 19, all AppleTalk routers were reconfigured to use network range "10-20" (except a few configured as non-seed routers). This new range would permit over 2500 Ethernet devices on "the backbone" - a number which will never be achieved due to planned segmentation of NYU-NET by multi-protocol routers. The mid- to long- range vision is that the NYU-NET backbone will consist only of routers and service hosts, and not end-user computing systems (such as PCs or Macintoshes). The move to network range "10-20" can thus be seen as a short term solution for a serious problem due to rapid network growth.

Transition to Phase 2-only AppleTalk Routing on NYU-NET, 1/15/93

As of January 15, 1993 the changeover of NYU-NET from AppleTalk transitional routing (Phase 1 and Phase 2 both present on the campus backbone), is almost complete. Only four Phase 1 devices remain, three ACF Novell servers which act as transitional routers, and one departmental NetWare 2.15 server (NYU_REPRO) which only has software (presently) for Phase 1 AppleTalk. As soon as updated AppleTalk software is procured for that server, it will be updated to use a Phase 2 driver, and the ACF Novell servers will be reconfigured as Phase 2- only AppleTalk routers. Estimated time of completion: 2/1/93

10 MBPS from Washington Square to the Dental/Medical Centers, 1/15/93

The link from Warren Weaver Hall to the Dental Center, and thence to the Medical Center, has been upgraded to a full 10 MBPS as a result of installation of a new fiber-optic link at 8 Washington Place (replacing the broadband link there). The broadband now provides a partial backup link for access to NYU-NET from the Dental/Medical centers.


List of TCP/IP Subnets

IP Speed/Type B/R Router Manage

128 10MB EN Bridge 128.122.128.44 ACF - routers/servers

129 10MB EN Bridge 128.122.128.44 CIMS - Robotics / Ultra

130 10MB EN Bridge 128.122.128.44 Stern - misc

131 10MB EN Bridge 128.122.128.44 Stern - misc

132 10MB EN Bridge 128.122.128.44 Pyschology - Meyer Hall

133 10MB EN Bridge 128.122.128.44 Chemistry - Brown / Main

134 10MB EN Bridge 128.122.128.44 Physics - Meyer Hall

135 10MB EN Bridge 128.122.128.44 MC - various

136 10MB EN Bridge 128.122.128.44 PHRI & ADARC - various

137 56KB SL Route 128.122.137.1 PHRI (NC)

138 5MB BB Bridge 128.122.128.44 ACF - WSQ Broadband

139 10MB EN Bridge 128.122.128.44 MC - Bellevue C&D

140 10MB EN Bridge 128.122.128.44 CIMS - CS

141 10MB EN Bridge 128.122.128.44 ACF - Education Site

142 10MB EN Bridge 128.122.128.44 ACF - 3rd Ave North Basement

143 10MB EN Route 128.122.143.1 MC - Sterling Forest



144 10MB EN Route 128.122.144.1 MC - Bellevue MIS

145 10MB EN Bridge 128.122.128.44 FAS - Journalism

146 4MB TR Route 128.122.146.1 ACF - Test Token

147 10MB EN Bridge 128.122.128.44 UCC - Broadway

148 10MB EN Bridge 128.122.128.44 FAS - EW in 269 Mercer

149 10MB EN Bridge 128.122.128.44 Bobst - Library

150 10MB EN Bridge 128.122.128.44 ACF - 14 Wash Site

151 10MB EN Bridge 128.122.128.44 ACF - Tisch Hall LC Site

152 10MB EN Bridge 128.122.128.44 OSP - 15 Wash Site

153 10MB EN Bridge 128.122.128.44 CIMS - CS

154 10MB EN Bridge 128.122.128.44 Pyschology - CNS - Meyer Hall

155 10MB EN Bridge 128.122.128.44 Dental - Weismann

156 10MB EN Route 128.122.156.1 MC - NucMed Ether

157 10MB EN Route 128.122.157.1 Stern - spare (NC)

158 10MB EN Bridge 128.122.128.44 FAS - Economics & Sociology

159 10MB EB Bridge 128.122.128.44 LAW - Vanderbilt Hall

160 10MB EN Bridge 128.122.128.44 Pyschology - CCS - Meyer Hall

161 10MB EN Bridge 128.122.128.44 ACF - 25W4th Street various

162 10MB EN Bridge 128.122.128.44 MC - Kips Bay

163 10MB EN Bridge 128.122.128.44 MC - Schwartz HCC

164 10MB EN Bridge 128.122.128.44 ADMIN - Bobst Exec Offices

165 10MB EN Bridge 128.122.128.44 ADMIN - Shimkin Info (NC)

166 3MB BP Route 128.122.166.1 CIMS - Robotics

167 10MB EN Bridge 128.122.128.44 MC - Milhauser

168 10MB EN Bridge 128.122.128.44 MC - Bellevue

169 10MB EN Bridge 128.122.128.44 TSOA - Film / Photo

170 10MB EN Bridge 128.122.128.44 ADMIN - Kimball Hall (RG)

171 10MB EN Bridge 128.122.128.44 ADMIN - 269 Mercer (PURCH)

172 10MB EN Bridge 128.122.128.44 MC - 25th Street





175 10MB EN Route 128.122.175.1 Pyschology - CNS - Meyer Hall

176 10MB EN Bridge 128.122.128.44 Bobst - Library Micro Lab

177 10MB EN Bridge 128.122.128.44 ADMIN - Kimball Hall (PERS)


179 10MB EN Route 128.122.179.1 Stern - MEC G Students

180 10MB EN Route 128.122.180.1 Stern - MEC UG Students


182 10MB EN Route 128.122.182.1 Stern - TH Servers





187 10MB EN Route 128.122.187.1 Stern - TH Faculty

188 10MB EN Route 128.122.188.1 Stern - TH Faculty


190 10MB EB Bridge 128.122.128.44 LAW - Vanderbilt Hall

191 10MB EB Bridge 128.122.128.44 LAW - Fuchsberg Hall

192 10MB EB Bridge 128.122.128.44 LAW - DAG Hall

193 10MB EB Bridge 128.122.128.44 LAW - Mercer Hall (NC)

194 10MB EN Route 128.122.194.1 Stern - MEC Faculty





199 100MB FR Route 128.122.199.1 Stern - TH FDDI

200 10MB EN Route 128.122.200.1 Stern - Shimkin Dean

201 10MB EN Route 128.122.201.1 Stern - Admin

202 16MB TR Route 128.122.202.1 MC - MIS Token Ring

203 16MB TR Route 128.122.203.1 MC - MIS Token Ring

204 10MB EN Bridge 128.122.128.44 ADMIN - Kimball Hall (CDV)

205 10MB EN Bridge 128.122.128.44 MC - Ehrman-Library



206 10MB EN Bridge 128.122.128.44 ACF - WWH 2nd Floor (NC)

207 10MB EN Bridge 128.122.128.44 ACF - WWH 3rd Floor

208 10MB EN Bridge 128.122.128.44 ACF - WWH RISC

209 100MB FR Bridge 128.122.128.44 ACF - WWH FDDI (NC)

210 10MB EN Bridge 128.122.128.44 ACF - 25W4th Street various

211 10MB EN Bridge 128.122.128.44 FAS - EW in Wing Building

212 10MB EN Bridge 128.122.128.44 ADMIN - Health Services

213 10MB EN Route 128.122.213.1 MC - MRI Ether

214 10MB EN Route 128.122.214.1 MC - MIS Ether

215 10MB EN Route 128.122.215.1 MC - MIS MVS

216 10MB EN Route 128.122.216.1 MC - MIS Test Ether (NC)

217 56KB SL Route 128.122.217.1 MC - 2 Penn Plaza (NC)

218 16MB TR Route 128.122.218.1 MC - 30th Street

219 56KB SL Route 128.122.219.1 MC - 30th Street

220 16MB TR Route 128.122.220.1 MC - Food Service

221 16MB TR Route 128.122.221.1 MC - spare (NC)

222 16MB TR Route 128.122.222.1 MC - NYC CME (NC)

223 10MB EN Bridge 128.122.128.44 Dental - Schwartz (NC)

224 10MB EN Bridge 128.122.128.44 ADMIN - 7E12th Street (REG)

225 10MB EN Bridge 128.122.128.44 ADMIN - Wash Square North

226 10MB EN Bridge 128.122.128.44 SE - Press Building

227 10MB EN Route 128.122.227.1 SE - HEOP - Admin

228 10MB EN Bridge 128.122.128.44 ACF - Goddard Hall

229 10MB EN Bridge 128.122.128.44 SE - Wash Square East

230 10MB EN Bridge 128.122.128.44 ACF - Third Ave North Res Tower

231 56KB SL Route 128.122.231.1 MC - Sterling Forest

232 10MB EN Route 128.122.232.1 MC - Tisch Hospital OR (NC)

233 10MB EN Route 128.122.233.1 MC - Bellevue NeuroSurg (NC)

234 10MB EN Route 128.122.234.1 MC - Bellevue Radiology (NC)

235 10MB EN Route 128.122.235.1 MC - spare (NC)



236 10MB EN Route 128.122.236.1 Physics - HEP (NC)

237 10MB EN Route 128.122.237.1 ACF - WWH RISC Switch

238 10MB EN Route 128.122.238.1 SE - HEOP - PCs

239 10MB EN Route 128.122.239.1 SE - HEOP - PCs

240 10MB EN Bridge 128.122.128.44 SE - ALT

241 10MB EN Route 128.122.241.1 ACF - spare (NC)

242 10MB EN Bridge 128.122.128.44 LEOB - Students

252 10MB EN Route 128.122.252.1 ACF - Test Ether



Notes:

56KB 56 Kilobits / Second1.5MB 1.5 Megabits / Second4MB 4 Megabits / Second10MB 10 Megabits / Second16MB 16 Megabits / Second100MB 100 Megabits / Second

BB = BroadbandEN = Ethernet (Baseband)FR = FDDI RingSL = Serial LineTR = Token Ring


Current Microcomputer Networking SoftwareThe following list gives the most recent version numbers of microcomputer networking software in use on NYU-NET. Obtain these items via "anonymous FTP" to acfcluster.nyu.edu; 'cd' to directory NYUNET/.

Changes for Revision 8 of this addendum are:For IBM PCs: New: NET33X.EXE 11/17/93 Current NetWare shellsNew: WINUP9.EXE 01/20/94 Netware-related Windows componentsNew: DOSUP9.EXE 01/21/94 Netware DOS componentsNew: SUPR65.ZIP 03/17/94 SMC SuperDisk version 6.5Updated: WIN32S.ZIP WIN32s extensions for Windows, version 1.15

For Microsoft Windows: (directory 'windows')

Product Version File

WINSOCK-based TCP/IP stack 1.0b6 winsock.zip

WIN32s extensions for Windows 1.15 win32s.zip



Describes ACF collection of software --- wnyunet1.txt

ACF collection of TCP/IP software 1 wnyunet.zip

GV gif, jpeg graphics viewer 0.58x gv057.zip

LVIEW gif, jpeg graphics viewer 3.1 lview31.zip

MPEG movie viewer (requires win32s) 3.2e mpegw32e.zip

QTW quicktime movie viewer 1.1 qtw11.exe

Sound file player (for audio boards) 1.31 wham131.zip

BCgopher client 0.8b3 bcgo8ba3.zip

Cello WWW browser 1.01a cello.zip

Eudora mailer 1.4 eudora14.exe

Eudora mailer update 1.42b16 weudora.exe

HGCSO (Ph client) 1.1 hgcso.exe

TN3270 for Windows 3.1e qws3270.zip

Telnet/FTP (QVTNET, shareware) 3.97 qvtws397.zip

Telnet (Peter Tattam, not very good) 0.6 trmptel.exe

TCP/IP applets (Tattam, not very good) --- winapps.zip

Mosaic WWW browser 1.0 wmos1_0.zip

Mosaic WWW browser, version 2 2.0a5 wmos20a5.zip

WSgopher client 1.0 wsg-10.exe

Trumpet netnews reader (shareware) 1.0a wtwsk10a.zip

Trumpet netnews reader (shareware) 1.0b wt_wsk.exe

For Apple Macintosh (directory mac):


Utils to find Mac Ethernet Address ------ enetaddress.sithqx

Eudora (Qualcomm) 1.3.1 eudora131.sithqx

Eudora (Qualcomm) - System 7 only 1.4 eudora14.sithqx

Fetch (Dartmouth College) 2.1.1 fetch211.sithqx

K-Star (Shiva) 9.1.2 shiva24.sithqx

MacTCP CDEV (Apple) 1.1.1 (NYU site use)

NCSA Telnet (NCSA) 2.5 ncsa25.sithqx

Network Installer Disk (Apple) 1.4 netinstall14.seahqx

Pegasus Mail for Macintosh 2r4 pmail204.sithqx

Shiva NetManager (Shiva) 2.4 shiva24.sithqx

TN3270 (Brown University) 2.3d26 tn327023.sithqx



TN3270 (Brown University) 2.4 tn327024.sithqx

TurboGopher (U. Minnesota) 1.0.7c turbogopher.sithqx

Xferit 1.5b4 (NYU site use)

MacTCP and Xferit are available from the ACF to members of the NYU community. Contact the ACF Faculty Microcomputer Lab at 998-3044.

For IBM PC (directory msdos):


Charon SMTP Gateway (Clarkson Univ) 4.0a charon40.zip

Clarkson Telnet (Clarskon Univ) 2.2E tn3270.zip

HYTELNET 6.5 hyteln65.zip

Mercury 1.1 1.1 merc110.zip

MS-Kermit (old) 3.12 kerm312.zip

MS-Kermit (as distributed by ACF) 3.13 kerm313.zip

MS-Kermit (full as distrib by Columbia) 3.13 msvibm.zip

NCSA Telnet (NCSA) 2.305 ncsa2305.zip

NUpop (Northwestern University) 1.0.3 nupop103.zip

NUpop (Northwestern University) 2.0 nupop20.zip

ODIPKT (Harvard) 3.0 odipkt30.zip

Packet Driver collection (Crynwr) 10.x packet10.zip

PC Gopher III (U. Minnesota) 1.1.2 pcgopher.zip

PDIPX (Intel) 1.03 pdipx103.zip

Pegasus Mail (David Harris) 2.3.5 pmail235.zip

Pegasus Mail, latest version 3.0.1 pmail301.zip

Pegasus Mail, Windows version 2.3.5 winpm201.zip

Rutgers/Clarkson Telnet/TN3270 1.0 rucutcp.zip

SMC SuperDisk (SMC) 4.6 supr46.exe

SMC SuperDisk (SMC) 6.5 supr65.zip

Trumpet News Reader 1.06b trmp106b.zip

WINPKT (from Crynwr) 11.2 winpkt.zip

For Novell NetWare:

NetWare patches and updates (in reverse chronological order) Released:

DOS Client Files Update Kit #9 9 dosup9.exe 01/21/94



Windows Update Kit #9 9 winup9.exe 01/20/94

NetWare DOS shell files 3.32 net33x.exe 11/17/93

DOS utility FILER.EXE version 3.76 3.76 fil376.exe 11/10/93

IPX RIP/SAP filter update for MPR+ 2.1 ----- ripsap.exe 11/04/93

LANalyzer for Windows fixes ----- lzfwdi.exe 10/15/93

Updated Server LAN drvers ----- landr3.exe 10/06/93

Adds software compression to MPR+ 2.1 ----- pppcmp.exe 10/04/93

NDS Patches for NetWare 4.01 ----- dspat.exe 09/24/93

Corrected ROUTE.NLM for Netware 3.11/4 ----- srtfx.exe 09/15/93

Novell's Black Screen of Death fix ----- bsdup1.exe 9/13/93

PSERVER/RPRINTER updates ----- pserv5.exe 9/10/93

Updated NW 3.11 ISA disk driver ----- isa311.exe 8/xx/93

ATTOKLLC.NLM update 3.1 atok31.exe 7/29/93

TCPIP.NLM v2.02j and SNMP.NLM v2.08 ----- tcp162.exe 7/28/93

FLeX/IP update for NW 3.11 and NW 4.0 ----- flx146.exe 7/28/93

NW/NFS 1.2b update for NW 3.11 and NW 4.0 nfs153.exe 7/28/93

New style, modular server drivers ----- landr2.exe 7/20/93

NetWare DOS printing utilities 3.75 putil4.exe 7/19/93

Patch to update SIDEWIND.NLM 1.5 sidewd.exe 6/23/93

Novell NetWare Update Kit ----- upd311.exe 6/03/93

Updated versions of SPX-related NLMS ----- strtli.exe 5/24/93

Appletalk Support Package / NWfMAC 3.011 atsup.zip 4/23/93

PS/2 SCSI 2/4/93, ESDI 4/08/93 drivers ----- ps2311.ZIP 4/08/93

IPCONFIG.NLM 2.02 ip129.zip 3/25/93

FLeX/IP 1.2A patch 1.2A flx135.zip 3/24/93

Updated DOS utils for NW Name Service ----- secnns.exe 3/16/93

Appletalk NLM 3.06a 3.06a atk306.exe 3/16/93

Novell NetWare 3.11 patches D 311ptd.zip 2/22/93

ODI Driver Update Kit 5 odiup5.zip 1/31/93

NCOPY.EXE utility updated 3.58 ncy358.zip 1/25/93

NDIR.EXE utility update 3.45 ndr345.zip 1/25/93

USERDEF.EXE utility updated 3.55 udf355.zip 1/22/93

LOGIN.EXE updated 3.70 log370.zip 1/15/93

NW311 monitor.nlm updated 1.75 mon175.zip 11/25/92

NLM to clear not-logged-in attachment ----- nliclr.zip 9/21/92



IDE.DSK 6/11/92 server driver update ----- ide386.zip 9/10/92

NETBIOS.EXE updated 3.10 nb310.zip 8/28/92

Relevant to NetWare 4.x:

DOS Client Files Update Kit #9 9 dosup9.exe 01/21/94

Windows Update Kit #9 9 winup9.exe 01/20/94

Updated Server LAN drvers ----- landr3.exe 10/06/93

NDS Patches for NetWare 4.01 ----- dspat.exe 09/24/93

Corrected ROUTE.NLM for Netware 3.11/4 ----- srtfx.exe 09/15/93

Novell's Black Screen of Death fix ----- bsdup1.exe 9/13/93

Novell NW4 DOS/Windows Requestor (VLM) 1.02 wkstndos.zip 8/30/93

Updated LOGIN.EXE 4.02 seclog.exe 8/02/93

NW4.0->NW4.01 ElectroText stylesheets ----- sty401.exe 7/26/93

Updated VNETWARE.386 for VLM clients 2.02 vnw202.exe 7/01/93

VLM components update 1.02 vlmup1.exe 6/15/92


AppleTalk on NYU-NETAs of February 1993, all AppleTalk routers on the NYU-NET backbone must be configured to use AppleTalk network number range 10-20. (The former network range 3-3 was eliminated in late February 1993).


Viruses and Novell NetWareManagers of Novell NetWare servers are often concerned about computer virus threats to their servers. A study of this issue was recently conducted by David Stang, Director of Research at the Virus Research Center, International Computer Security Association, and written up as a white paper and as an article "Virus Dangers to NetWare Lans" in the Jan/Feb 1993 "NetWare Connection", the bimonthly magazine of NetWare Users International. The white paper entitled "Viruses and NetWare" can be ordered from:

NetWare Users InternationalVirus White PaperP.O. Box 19007Provo, UT 84605-9007

Enclose a $15 check or money order to cover production and handling costs.

[Note: I tend to view this as reasonably reliable and reassuring information on this subject - with the caveat that the survey is based on study of a small number of, presumably, representative DOS computer viruses. It tends to indicate that strong anti-viral protection on DOS workstations, in combination with common-sense server protection measures, will provide good security against a server participating in the spread of viruses. Believing the conclusions of this article does not, however, relieve NYU-NET Novell system managers of the obligation to seriously consider deploying server-based anti-viral software. - Gary Chapman]

The study seems to have focused on the DOS client/NetWare 3.11 server context. Here is a more-or-less verbatim summary of the findings as described in the article.

● If a common file virus is memory-resident at the time of running IPX, NETX, and LOGIN,



NetWare will permit the login, but many viruses will be disabled. ● If IPX and NETX are resident when a memory-resident virus is first executed, login may be

successful, or the workstation may hang, depending upon the virus. ● If IPX or NETX are infected, login will proceed smoothly with the● NetWare is never attacked by a workstation boot virus, it never contributes to the spread of

that virus, it does not disable the virus, and the virus is not disabled by the login process. ● All of the file viruses we tested were NetWare compatible, permitting them to be run from

server directories. ● The only way that some viruses can get into files on the server (Frodo and Yankee Doddle,

for instance) is by infecting a file on a local drive that is later copied to the server. Other viruses (Jerusalem, Cascade, Green Caterpillar) are able to infect files on the server.

● The Read-Only attribute provides protection against viruses only when the user is also denied Modify rights in the directory in question.

● The Execute-Only attribute stops all viruses cold. ● A virus cannot infect any file in any directory in which the user does not have write

permission.


NetWare 4 on NYU-NETNovell recently released a major new version of NetWare - version 4.0 - and superseded almost immediately by version 4.01 in July 1993.

Proper deployment of NetWare 4.x, both within a department and across NYU-NET as a whole, requires even more attention to planning and coordination than earlier versions of NetWare. The purpose of this addendum is to alert network managers of the most important issues involved in implementing NetWare 4.x at NYU.

Important features of NetWare 4.x

1. NetWare Directory ServicesNetWare 4.x replaces the "bindery" (database of users, groups, queues, etc.) with the "NetWare Directory Services" (NDS). NDS is an enter- prise-wide, distributed, hierarchical database of NetWare entities, modeled upon X.500 principles. The database is viewed as a tree in which all servers, volumes, users, groups, queues, and so on have a place. "Bindery emulation" is an option, however, allowing older software which depends upon bindery access (through old APIs) to continue working.

The overall NDS hierarchy must be centrally coordinated for purposes of consistency and addition/deletion of network objects. While it is possible to have more than one NDS tree on NYU-NET, this option requires careful consideration: an object in one tree is invisible to objects in another tree; a workstation oriented toward one tree cannot access objects such as servers in another tree. The primary application for multiple trees would be situations where a group intentionally wished to hide (to some degree) their network resources.

A key notion of NDS is that a user/workstation no longer logs in to specific servers, but rather "logs into the network" of NetWare devices, and has access then to all resources (servers, print queues, etc.) for which he has privileges.

2. File compressionNetWare 4.x improves various aspects of its file system; e.g. under the configuration control of the server administrator, the operating system will transparently compress and de-compress data files on disk.

3. Hierarchical storageThere is new provision for file migration through a hierarchy of storage media: server hard disk -> read/write optical storage -> tape.

4. NetWare for MacintoshEach copy of NetWare 4.x comes with a 5-user version of NetWare for Macintosh. Aside from that, NetWare for Macintosh is available only in a 1000-user version. The first release of NetWare for Macintosh is not fully NDS compatible.

5. Windows-based management toolsWhile DOS tools for server and NDS management are present, there are now Microsoft Windows-based management tools as well. Novell has reduced the number of DOS utilities, although at the price of adding numerous parameters to the remaining commands!

Important Facts

1. Server installation / NDS coordinationThe ACF has installed the first NetWare 4.x server (NYUACF1) on NYU- NET, and thereby



created the primary NYU directory tree (NEW_YORK_UNIVERSITY in name). Subsequent servers installed on NYU-NET will attempt to join this tree, but this will only be possible through coordination with an ACF staff member.

During installation various configuration decisions must be made. In particular, ethernet frame type and network time synchronization parameters must be chosen in conformity with the first server, NYUACF1.

The implementations of NDS in NetWare 4.0 and 4.01 are NOT compatible; only NetWare 4.01 (or later) may be installed on NYU-NET at this time.

2. New DOS/Windows workstation softwareNetWare 4.x uses a new generation of modular workstation drivers; ODI data link drivers are now required, and the NETX series shells are replaced by the new "VLM" (virtual loadable module) drivers. Potential deployers of NetWare 4.x are advised to gain experience with ODI and VLM drivers (which are NetWare 3.x compatible) prior to server installations.

The biggest observable effect of the new drivers is that NetWare 4.x allocates DOS drives _up to_ LASTDRIVE, and not _after_ LASTDRIVE. An explicit config.sys LASTDRIVE setting is now required. A second notable features is that, upon initial server attachment, the server drive is "root mapped" to the SYS:LOGIN directory: one no longer sees F:\LOGIN, but simply F: instead.

Happily, ODIPKT works fine with the new workstation software; so packet-driver based software (e.g. NCSA Telnet, PC Gopher, NUPop) continues to work.

3. CD-ROM distribution of software and manualsNetWare 4.x software and documentation are distributed on CD-ROM; floppy disks and paper manuals are added-cost options. The ACF has purchased one paper copy of the manuals, which may be inspected by NYU staff members. Third-party books are starting to appear in quantity.

4. Planning of NDS tree criticalEach unit or department installing NetWare 4.x needs to carefully plan the organization of their part of the NDS tree, in order to organize things in a good way for their use and to minimize the likelihood of making frequent or major changes in the structure of the NYU-wide NDS. NDS is a distributed database with portions replicated on several servers on campus; unnecessary changes to the database (involving wholesale re-synchronization of the database) should be avoided. Novell has included substantial documentation on NDS concepts and planning which should be examined carefully prior to NetWare 4.x installation.

5. Potential incompatibilitiesNetWare 4.x is quite compatible with software designed for NetWare 3.x. There are, however, many examples of DOS-based tools or server- based NLMs which require update to either work compatibly with the new operating system or take full advantage of it.

Less predictably, however, it is possible for local configuration methods or tools to break under NetWare 4.x. The ACF finds, for example, various aspects of its login and logout process to be "broken". Work will be required to restore similar functionality, and it's not clear if a single set of scripts/programs can work on both NetWare 3.x and NetWare 4.x servers (during a period of transition).


Policy Statement on Providing Internet Access, September 2, 1993[The following policy statement was adopted by the New York University Data Communications Task Force at its September 1993 meeting. It is intended to provide guidelines for NYU departments and schools which receive requests from outside organizations requesting computer accounts which thereby provide Internet access. The general policy is that outside groups, including non-profit ones, need to obtain Internet access through a commercial service provider - and that it is no longer appropriate for the university to provide this access unless there is a strong collaborative and programmatic affiliation between the requesting (non-profit) organization and the university.]

Policy Statement:In the past, computing organizations at New York University have provided accounts on our machines to specific not-for-profit institutions having a programmatic affiliation with the University that depends upon access to NYU computing and network services. We will continue to consider such requests and evaluate them on their merits.

Under the terms of our agreement with CREN, such organizations may have access to Bitnet only if they become affiliate members of CREN. There is a yearly charge for such affiliation.



Historically, universities have often offered the only convenient way to obtain Bitnet and Internet connectivity. There are now an increasing number of commercial IP service providers offering a variety of connectivity and service options. Performance Systems International and Advanced Networks and Services are examples of firms operating in this new industry. We recommend that not-for- profit institutions having no programmatic affiliation with NYU contact these IP service providers to obtain the connectivity that they require.

Selected Commercial Network ProvidersPSIPerformance Systems International, Inc.(800) 82PSI82(703) 620-6651E-mail: [email protected]

NYSERnet New York State Education and Research Network (NYSERnet) Jim Luckett (315) 453-2912 E-mail: [email protected]

ANSAdvanced Networking and ServicesJoel Maloff(313) 663-7610E-mail: [email protected].

For further help and information, contact ITS Technology Security Services at [email protected].

Questions or comments about this site? Send e-mail to: [email protected].




nyu-net technical handbook

Technology

nyunet r

nyunet infrastructure

nyunet q addendum9

net q appendixb

nyunet q glossary q

nyu q appendixd

appletalk q

introduction q