Hi again,
Sorry for late summary, but it took a while before I could try anything as
the servers are off-site.
Thanks to Selden E. Ball Jr. for his response (below). This is followed by
the original (& very tedious) questions. The font was so tiny I guess no-one
else could read it.
This question really boiled down to two opposing trains of thought:
1. "I'm new to the job, but I don't know why joind is running on these 2
boxes - seems like it's just for bootp for a few NCD terminals & is creating
some BIG log files - can I get rid of it???"
2. "If it ain't broke, don't fix it!!"
What I (eventually) did was discover that the NCD "Explora" X-terms would
happily use tftp, so all I needed to do was ensure there was no other
reliance on bootp/DHCP from elsewhere, e.g. printers, and comment joind out
of /etc/inetd.conf, reset inetd & try booting the NCD boxes. Hey presto -
fixed. And no more log files. Did this on Box A, will do box B in a couple
of weeks.
I was curious about where the weird packets were coming from....... but not
that curious. The network people had a look and couldn't figure it.
There was a sort of part 2 - why is /nsr/logs/messages being written to with
these messages also - but I suspect this will go from /etc/syslog.conf when
I de-install networker.
Selden's reply (edited slightly):
Tony,
I can't help directly with joind: we're using Multinet's dhcp server under
VMS to handle our NCD X terminal bootp requests. Many of our NCDs have their
addresses configured in the local NVRAM, so they don't use bootp at all.
Since your bootptab shows that they're loading Xncdxpl,
I'm assuming by "thin-client" you mean Explora X terminals.
NCD has also made other thin-client systems that are not X terminals.
(We have none of them, though.)
The only extra network traffic should be the spurious bootp requests,
which are tiny. Your servers won't respond to them on the net.
Eliminating the bootp requests would eliminate the joind log entries,
of course. If the logs are going to a remote syslog server, that
traffic would be eliminated, too.
Even so, the tftp traffic to download fonts and software to the NCDs
is much greater.
Since you have only 6 NCDs (so it wouldn't be a lot of work),
you might want to consider configuring them to use NVRAM settings
instead of "network" (bootp). The NCD X terminals that we have can be
set to request files from a list of tftp servers: I'm guessing that
whould meet your reliability goals. You could then turn off joind
altogether. (We also use dhcp for networked printers.)
Usually dhcp/bootp is needed if you're going to be moving client
systems among subnets or otherwise changing their configurations
frequently. It doesn't sound like you're doing that.
>From your description, it seems to me that the bootp requests
that are seen on your .94. subnet must be caused by broken equipment.
That would explain the invalid MAC address field in the network packets
seen by your joind servers. You'll have to involve your network support
folks to trace them down. The symptoms you're seeing may be just the
tip of the iceberg (failing switches, maybe).
Please let me know if you learn something different.
USE OF BOOTP?????
Yes. It's in /usr/opt/obsolete/usr/sbin if you've installed
the kit OSFOBSOLETE###.
STOP/START of JOIND......
You probably should use the start/stop script instead of kill:
/sbin/init.d/dhcp stop
/sbin/init.d/dhcp start
Also, the X terminals do need a nameserver (ds) so their users can connect
to a system using its name instead of the numeric address. Having
a nameserver on your .93. subnet would be best, of course.
The nameserver address can be included in the NVRAM settings.
If bootp doesn't provide one of the configuration values required by
the NCDs (like a nameserver address), they'll use the NVRAM setting.
You can configure joind to only honor requests from a specific subnet,
which isn't quite the same. The design of the bootp and dhcp protocols
allows requests and responses to pass through routers to different
subnets if the routers have been configured appropriately. In other
words, a single dhcp server can provide information to systems on several
different subnets. (That's what we do.)
If I understand you correctly, you must have one or more
FDDI-to-Ethernet bridges between the NCDs and your joind servers
since the NCDs are on your FDDI subnet and I'm unaware of any NCDs
that have FDDI interfaces. I think this is probably irrelevant,
though.
> Any suggestions greatly appreciated, but I won't hold my breath!!!
I hope this helps a little.
Selden
======
Hi,
I have 2 sets of 2-host Clusters on site with a similar setup off-site,
linked by an FDDI ring. All boxes are 4xEV5/533 1Gb RAM AS4100 4.0D/pk3
ASE1.5 Production Server, using DMQ3.2B.
Each box has memory channel card = 10.?.?.?, FDDI = 123.69.93.?, Eth1 =
123.69.94.?, Eth2 = 123.69.94.?
This part of the network is separated from the site network by a firewall,
and from the outside world by 2 more. It has it's own DNS, and there are
various VMS (VAX & Alpha), Tandems, and some NT x86.
One of the on site servers & one off-site server is running joind to
facilitate 6 "thin-client" NCD boxes to connect via bootp.
My questions:
Any ideas on an alternative? I am concerned that a lot of traffic is being
generated for little reason (There is no other reason for using joind, DHCP
is not being used).
Any ideas what might be causing this 16-field MAC address (see below) or
what it might relate to? There are zillions of these entries in this log
file. (The log files had grown to over 500Mb in one case).
Can I use bootp instead of joind?
Messages are ALSO being written to /nsr/logs/messages but Networker is not
being used (it's installed, but not licensed so I intend to de-install it).
/var/join/log on FRED:
received on address 123.69.94.127
BOOTP/DHCP packet with "chaddr"
52:41:53:20:70:73:be:ab:79:95:bf:01:01:00:00:00 and htype 1 has hlen field
of 16 which isn't the expected value of 6 : packet discarded
/var/join/log on BARNEY:
received on address 123.69.94.63
BOOTP/DHCP packet with "chaddr"
52:41:53:20:70:07:06:fd:f3:93:bf:01:01:00:00:00 and htype 1 has hlen field
of 16 which isn't the expected value of 6 : packet discarded
BARNEY# cat /etc/bootptab
#
# /etc/bootptab: database for bootp server (/etc/bootpd)
# Blank lines and lines beginning with '#' are ignored.
#
# Legend:
#
# first field -- hostname
# (may be full domain name and probably should be)
#
# hd -- home directory
# bf -- bootfile
# cs -- cookie servers
# ds -- domain name servers
# gw -- gateways
# ha -- hardware address
# ht -- hardware type
# im -- impress servers
# ip -- host IP address
# lg -- log servers
# lp -- LPR servers
# ns -- IEN-116 name servers
# rl -- resource location protocol servers
# sm -- subnet mask
# tc -- template host (points to similar host entry)
# to -- time offset (seconds)
# ts -- time servers
#
# Be careful about including backslashes where they're needed. Weird (bad)
# things can happen when a backslash is omitted where one is intended.
#
# First, we define a global entry which specifies the stuff every host uses.
global.template:\
:sm=255.255.255.0:\
:td=/tftpboot:\
:hd=/tftpboot:\
:ds=123.69.94.131:\
:to=18000:\
:ht=ethernet:
# Individual entries (could also have different servers for some/all of
these)
xterm1:\
:tc=global.template:\
:ha=0000a7027961:\
:bf=Xncdxpl:\
:ip=123.69.93.1:
xterm2:\
:tc=global.template:\
:ha=0000a702f3da:\
:bf=Xncdxpl:\
:ip=123.69.93.2:
xterm3:\
:tc=global.template:\
:ha=0000a702f418:\
:bf=Xncdxpl:\
:ip=123.69.93.3:
xterm4:\
:tc=global.template:\
:ha=0000a70421ff:\
:bf=Xncdxpl:\
:ip=123.69.93.4:
xterm5:\
:tc=global.template:\
:ha=0000a70421ed:\
:bf=Xncdxpl:\
:ip=123.69.93.5:
xterm6:\
:tc=global.template:\
:ha=0000a7042f49:\
:bf=Xncdxpl:\
:ip=123.69.93.6:
xterm7:\
:tc=global.template:\
:ha=0000a70421e4:\
:bf=Xncdxpl:\
:ip=123.69.93.7:
xterm8:\
:tc=global.template:\
:ha=0000a702f43a:\
:bf=Xncdxpl:\
:ip=123.69.93.8
/etc/inetd.conf:
bootps dgram udp wait root /usr/sbin/joind joind -d4
I guess if I take out the -d4 that this will reduce the debugging and hence
the messages, but this won't resolve the cause.
If you've read this far, you may have some idea of what's going on (!),
so...what I have tried so far -
I couldn't see any reason for have the "ds" entry in the global.template in
bootptab - quite the reverse in fact, as the only boxes using BOOTP are the
aforementioned NCD boxes, which all have an entry with their MAC address. So
I commented it out, and did a kill -1 on joind, but this didn't make any
difference. Should I do a kill -1 on inetd to stop joind & restart it?
Also of note - all the NCD boxes are on the same subnet as the server FDDI -
123.69.93, but the messages are coming from a 123.69.94.? address. What is
also interesting is that the addresses in the log file 123.69.94.63/127 are
according to the network people, "BROADCAST" addresses. Can I restrict bootp
to look at one NIC (123.69.93.?) only?
Any suggestions greatly appreciated, but I won't hold my breath!!!
TIF & Rgds,
Tony.
Tony McElhill.
Unix Systems Manager.
ISMA,
7 Limeharbour,
London E14 9NQ.
Tel : +44 (0)20 7510 2617.
Fax: +44 (0)20 7538 1368.
This e-mail is confidential and may well also be legally privileged. If you have received it in error, you are on notice of its status. Please notify us immediately by return e-mail to the originator and then delete this message from your system. Please do not copy it or use it for any purpose, or disclose its contents to any other person: to do so could be a breach of confidence.
Received on Tue May 22 2001 - 15:39:12 NZST