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.
The device needs a physical connection.
It must be registered with Telcom to receive an IP address.
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)?
Add new hosts via the
MTUNet Portal.
Select "add service to subscriber" to begin new service on a jack,
"move service" to move all hosts on one jack to another jack that is not
already in service,
"disconnect service" to remove all hosts from a service and disconnect the
jack from the network, or
"change service" for all other operations.
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.
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:
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.
8) What should I do about DNS?
You should run a secondary nameserver and have all of your hosts resolve addresses through it. This
way, you can still operate if you lose contact to the primary nameserver. See the administrators
guide for your system on how to do this. Contact Jeff Blank at 7-1788 or via email at
jfb@mtu.edu for MTU-specific details. If running your own secondary
nameserver is a problem or if you would like to list nameservers other than your own in case yours
fails, use 141.219.70.130 and 141.219.100.30 (mtu-ns.mtu.edu and dns2.mtu.edu, respectively).
General use of DNS server dns.mtu.edu, 141.219.4.30, is discouraged.
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
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.
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.
17) Can Telcom restrict network traffic to my subnet/host/service?
Telcom can usually create router filters for you to protect your entire subnet from problematic
traffic, and exceptions to these filters can be made for individual hosts. For example, you may wish
to prevent Resnet or off-campus hosts from communicating with your subnet; you may at the same time
need to allow traffic from a certain host or two that would otherwise be blocked, or you may need to
allow traffic to a certain host or two of yours from all of the otherwise-blocked hosts.
Telcom can usually also filter traffic to a host or service when host-based or service-based
access control is not available (often for printers or other appliances with non-configurable web
servers, telnet servers, or similar), but in general, if you can restrict access to your hosts by
way of host configuration, Telcom will not provide you with a router filter to accomplish the same
action.
