This document is intended to answer frequently asked questions about system administration and networking issues at MTU. The intended audience is system administrators. The current copy of "how-to-network" is located on the web at http://www.tc.mtu.edu/data/policies_docs/faq.shtml.

1) How do I get on the network?

Getting a device connected to the network has (at least) three steps.

1. The device needs a physical connection.  
2. It must be registered with Telcom to receive an IP address.  
3. It must be configured.  

If at all possible, inform Telcom of your intention to connect a device to the network before acquiring it.

2) How do I get a physical connection?

An official procedure for this is under development. For now, the system administrator responsible for the device to be networked should contact Telcom Customer Service through the on-line request form at http://www.tc.mtu.edu/, at 487-2000, or at telcom-request@mtu.edu.

3) How do I register my host (and get an IP address)?

If at all possible, you should add new hosts via the MTUNet Portal.

If a host absolutely must go into the NED, the administrator should send the information to dns-request@mtu.edu using the format:

IP address:The address you would like to assign to the device. The program newip is useful for discovering free IP addresses. Usage: newip x.y, where x and y are the last two parts of an IP address. The 141.219 is assumed. Example: newip 20.30 will display all available IP addresses in the range 141.219.20.30-141.219.20.254.

The source code for newip is in /local/telcom/src/newip.c. If you request a specific address, please make sure it isn't being used. Telcom reserves the first group of addresses with the fourth octet < 30 in each subnet. These addresses are used for networking equipment.

MAC address:The ethernet address of the device (usually obtained via ifconfig or card diagnostics). It is 12 digits (single-digit octets should be padded with zeros; no colons or other separators) and in upper case.

Hostname:Should begin with a letter, end with a letter or digit, and contain only letters, digits, and hyphens. Since case is not significant, please use only lower case letters. The length of the name should be 3 or more characters excluding the domain and up to 30 characters including the domain.

Host type:Should first contain a generic label for sorting purposes, such as "Printer hp 4m+", "PC IBM 486", "MAC Powermac", "Sun 3/50", etc. See the current ned_dump info for examples.

Bldg/Room:The number of the building, and room where the equipment is located.

Index:The Banner Index that will be billed monthly for the cost of the connection.

Conn Type:Please select a connection type and description from the table below:

Other rates are listed at http://www.tc.mtu.edu/customerservice/adminservices/rates/.

Owner:Usually the primary user of the device.

Techid:MTU ID number of Owner above or responsible party. The techid must belong to someone who is full-time and permanent staff or faculty.

To request a new CNAME alias or a non-alias additional hostname, please use the following format:

NEW ALIAS:

----------

Master hostname: host.dom.mtu.edu

          Alias: alias.dom.mtu.edu

Substitute "Additional Hostname" for "Alias" if you do not wish for this new hostname to be an alias. The "master hostname" is the name of a host with a 6-digit serial number in the ned_dump file. A hostname with a 5-digit serial is acceptable in the case of CNAME aliases or MX records, provided that the parent of the hostname with the 5-digit serial has a 6-digit serial.

For MX records, the necessary information is

NEW MX RECORD:

--------------

Master hostname: host.dom.mtu.edu

      Mail name: dom.mtu.edu

        MX pref: 10

The "mail name" is the host/domain that e-mail is addressed to, such as (user@)lib.mtu.edu or (user@)calvin.tc.mtu.edu. It may be a domain suffix or a full hostname, depending on your needs. In the above example, the host host.dom.mtu.edu handles mail addressed to anyuser@dom.mtu.edu. The MX preference helps mail transports decide the next hop for relaying a message, with lower numeric values indicating more desirable next-hop destinations.

To request a new hostname/address pair for use with a virtual interface, please use the following format:

NEW HOSTNAME/ADDRESS PAIR:

--------------------------

Master hostname: host.dom.mtu.edu

     IP Address: 141.219.12.92

       Hostname: virtual.dom.mtu.edu

The IP address corresponds to the hostname below it, not the master hostname. The master hostname *must* have a 6-digit serial number in ned_dump.

To request NS entries for an Active Directory nameserver,

NEW ACTIVE DIRECTORY NAMESERVER:

--------------------------------

Master hostname: host.dom.mtu.edu

         Domain: dom.mtu.edu

The master hostname is the host that will be acting as the AD nameserver for the specified domain.

When ANY of this information changes, you should report the change to Telcom. If it is an IP address or hostname change, send it to dns-request@mtu.edu. For any other change, send it to ned-request@mtu.edu. In either case, please use the following format:

or

"Serial" is the unique identifying "number" of the entry in the database. This and all other information currently in the database can be looked up in the file /local/telcom/info/billing/ned_dump, optionally using the script /local/telcom/info/billing/nedgrep or a derivative thereof. The output of nedgrep is suitable for a change template.

When submitting changes, only include the items that changed in the "TO" column, or add an asterisk in front of the changed item as shown above.

To delete a connection, include the "FROM" information, and put the word "DELETE" in the "TO" column in place of the connection number. Leave the rest of the "TO" column empty.

4) What are my subnet mask and broadcast address?

Currently, most departmental networks use a 22-bit or 23-bit netmask. This means the first 6 bits (7 bits with a 23-bit netmask) of the third number in the IP address determine what sub-network you are on. Sub-networks (subnets) may span multiple buildings, or there may be multiple subnets in one building. Most departments only have one subnet.

                  141       219
                10001101.11011011.SSSSSSHH.HHHHHHHH (22-bit netmask)
                10001101.11011011.SSSSSSSH.HHHHHHHH (23-bit netmask)

                S=subnet number  H=host number

Hosts on the same subnet must have the same subnet number in their address. Example: host 141.219.5.38 is on the same subnet as 141.219.6.66.

                10001101.11011011.SSSSSSHH.HHHHHHHH

                   141      219       5       38                 10001101.11011011.00000101.00100110

                   141      219       6       66                 10001101.11011011.00000110.01000010

They both share "000001" as the first 6 bits in their address. The subnet number is usually identified with the host portion being all zeros. Host 141.219.5.38 is on subnet 4:

                   141      219                 10001101.11011011.SSSSSSHH.HHHHHHHH

                   141      219       5       38                 10001101.11011011.00000101.00100110

                   141      219       4        0                 10001101.11011011.00000100.00000000 (zero host part)

The subnet mask identifies which part of the address is a network (or subnet) number, and which part is the host number. If the bit is set, it is part of the network address. If it is zero, is it part of the host address. At MTU we use a subnet mask of 255.255.252.0, or FFFFFC00 in hex.

                   255      255      252       0                 11111111.11111111.11111100.00000000                                     ^                                     |                                   six '1' bits

The broadcast address is the address used to send an IP broadcast to every host on the same subnet. This is done by setting the host portion to all 1s. Note that some old networking implementations (Berkeley 4.2, from which SunOS 4.1.x networking code is derived) used to use 0s instead of 1s. This has long since been obsolete.

The broadcast address for the host 141.219.5.38 would be 141.219.7.255.

                  141       219                 10001101.11011011.SSSSSSHH.HHHHHHHH

                   141      219       5       38                 10001101.11011011.00000101.00100110

                   141      219       7      255                 10001101.11011011.00000111.11111111 (host part all 1s)

The addresses 141.219.255.255 and 255.255.255.255 are also acceptable broadcast addresses. While they do not reveal what network you are on, they are easy to use and are the same on every subnet. Routers will not forward such broadcasts to other subnets. Note that your TCP/IP software should automatically determine the broadcast address from your IP address and subnet mask.

See RFC1122 and RFC0950 for more information.

5) What and where are RFCs?

RFC stands for "Request for Comment." Many protocols and procedures such as IP, TCP, and subnetting are documented in RFCs. They can be found in /local/mtusysadm/rfc or on the web at http://www.ietf.org/rfc.html.

6) Should I run routed?

To contact hosts on other networks (subnets), you need to go through a router. There are two ways your host can find the router:

• the administrator can hardcode the address of the router.
• the host can receive this information from some routing protocol.

While hardcoding the address is easy, it is prone to error when moving hosts and requires the administrator to change all hosts if the address of the router changes. In some cases, it is unavoidable, as with many non-Unix(like) operating systems.

Receiving the information from a routing protocol allows hosts to find backup routers, renumbered routers, etc. It does consume some CPU, but the amount of CPU should be insignificant.

Telcom currently uses the convention that the first unicast address on a subnet is the address of the router for that subnet. For example, 141.219.4.1 is the address of the router on subnet 4. Telcom has every intention of continuing this practice.

IPv4 Routing information can be distributed from the routers via either or both of two protocols, RIP (routing information protocol) and ICMP router discovery. These protocols are only enabled where requested by system administrators.

The programs in.routed (just routed in some operating systems) and gated implement RIP, and Solaris 2.x's ICMP router discovery client is in.rdisc.

Make sure you never advertise routes. If your host has multiple interfaces, it may try to do this by default. You should disable this by using the "-q" option with in.routed or the "-s" option with in.rdisc. Solaris 2.x also allows the creation of the empty file /etc/notrouter to force in.routed to run with the "-q" option and to force in.rdisc to run with the "-s" option (though in.routed will only attempt to start if in.rdisc receives no responses or is disabled in /etc/init.d/inetinit and if no /etc/defaultrouter file is present).

An ICMP router discovery client works by sending out a solicitation to the "all routers" multicast address (and therefore requires a multicast-capable IP stack). The router immediately replies to the soliciting host and then continues its periodic advertisements (every 7-10 minutes), which the host client processes to adjust the routing table if necessary. An advertisement from a router implies that it is the default gateway for a network, so only a host's default route is affected by a router discovery client. A host that is attached to multiple networks that provide ICMP router discovery should not run a router discovery client, as having two default routes can cause problems.

A RIP client works similarly to a router discovery client. It solicits information at startup via an IP broadcast and then listens for advertisements from the network, which a router will generally repeat every 30-35 seconds. RIP advertisements (also transmitted via IP broadcast) from MTU routers contain a default route as well as routes to many campus subnets. All routes other than the default route are redundant unless there are multiple routers on a subnet, which is generally not the case here. If you dislike the extra routes in your routing table, you can use the "-S" option with in.routed under Solaris to ignore all non-default routes learned via RIP.

Currently, the only supported IPv6 route-advertisement protocol is ICMPv6 router advertisement, which is very similar to IPv4 ICMP router discovery. IPv6 router advertisement is currently enabled by default on all IPv6-enabled VLANs. Setting up static routes is possible as well, though this may be easier in some operating systems than in others.

As with IPv4, Telcom currently uses the convention that the first unicast IPv6 address on a subnet is the router address. For example, 2001:48a8:3:14::1 is the router address for IPv6 subnet 2001:48a8:3:14::.

7) What should I do when I want to move a piece of equipment?

Whenever possible contact Telcom BEFORE the move. We can then work with the administrator to make sure the destination site is ready. It may be the case that a communications jack needs to be connected, or that connecting a different device to communications jack will cause it to be disabled.

As usual, any changes to hosts in MTUNet should be requested through the MTUNet Portal, and information regarding changes to a host in the NED should be sent to ned-request@mtu.edu.

8) What should I do about DNS?

9) How do I make mail work?

Contact Distributing Computed Services for guidance in this matter.

10) What protocols should I run?

Some protocols used at MTU are:

• Physical Layer: IEEE 802.3 (10Base-T, 100Base-TX)
• Data Link Layer: DIX (Blue Book) Ethernet
• Network Layer:IPv4, IPv6, ARP, RARP
• Transport Layer: TCP and UDP (ports < 1024 considered "privileged"), ICMP
• Physical Address Resolution: DHCP/DHCPv6, BOOTP
• Routing: RIP, ICMP Router Discovery (both by request only), IPv6 router advertisement
• Network Management: SNMP
• Remote Procedures: RPC, XDR
• Network Information: NIS (YP), LDAP, Windows Active Directory
• File Sharing: NFS, SMB (CIFS)
• Remote Access: Secure Shell, RDP, Telnet, Rlogin
• Mail: SMTP, IMAP, POP-3
• Display: X11

11) How do I get a userid/uid for a user?

Just as all hosts on the network must be registered with Telcom, ALL userids and uids MUST be registered in the NID (Network Information Database). See http://www.it.mtu.edu/nid/for more details.

12) How do I report a problem?

If you experience a network problem, first try to isolate it. Can you ping hosts (by IP address) on your own network? Can you ping devices that are on the same subnet, but behind a bridge or packet switch? Can you ping your subnet's router address? Can you ping hosts on other subnets? If you think you have isolated the problem to a networking issue, contact Telcom via telcom-request@mtu.edu. If the matter is serious, call 483-9966 to hear information about known problems; if your issue is not addressed there, call 483-9964 to report the problem. If you are having a problem reaching a specific host, contact the administrator of that host.

13) What happens if a host is causing problems?

If the problem is causing loss of service to other customers, the host will be removed from the network. If the problem is less severe, the administrator will be notified and asked to correct the problem. If after sufficient time the problem is not corrected, the host will be removed from the network.

Examples of problems are: creating "bad" packets, using invalid/unregistered IP addresses, not following MTU standards such as registering users in the NID, security problems on a host.

14) Can I modify the network?

No. In general, Telcom is responsible for all equipment up to the communications jack. Only Telcom should be servicing this equipment. Administrators may remove their equipment from the network. If the equipment is to be removed permanently, you should inform Telcom.

See other Telcom FAQs for more details.

15) How do I get on the mtusysadm list?

Use this web form to submit a subscription request: http://lists.mtusysadm.mtu.edu/mailman/listinfo/mtusysadm-info-l

16) How are my connections billed?

The information supplied by administrators is put in a database. This database is used to determine network charges. It is the responsibility of administrators to provide current information. Please send billing information changes to telcom-request@mtu.edu.

A copy of the monthly charges is updated quarterly in the directory /local/telcom/info/billing with the name mtunet_quarterly.<date> (or ned.by.account.quarterly.<date> for NED information), and the most up-to-date report has the filename mtunet_dump (or ned_dump for the NED report). When reporting changes (including deletions), please supply the "serial" number found in the file.