IPX Routing
151
User’s Guide: Version 1.2
• The server and router on the remote network may have gone down
at the same time (e.g. due to loss of power). Although the router
has rebooted, it can’t inform the V!CAS of the change since it
doesn’t know the server exists yet. The V!CAS can’t acknowledge
the change either if the aging mechanism has been disabled for the
PPP interface.
Suggestion: Briefly set the ifAdminStatus for this interface to “down”
then back to “dialup”. This will force all routes and services, avail-
able over this interface, to be deleted.
Can’t change to a network drive from the client station.
• The file server may be “invisible” to the client, see above.
• The number of user licenses on the server as been exceeded. This is
not a routing problem.
ISDN connections constantly reconnecting.
In general, RIP/SAP packets do not force ISDN to be established on the
V!CAS.
• Is there an entry in the ipxDenyTable that is preventing Novell se-
rialization packets from being sent over the dialup interface?
• Is SPX spoofing enabled (see ipxAdmSpxSpoofing)? Also, if the re-
mote SPX router does not support SPX spoofing, then the V!CAS
will disable SPX spoofing (as long as the interface is up).
• Is IPX spoofing enabled? (see ipxAdmIpxSpoofing)
• Is RCONSOLE running somewhere with a constantly changing
screen (e.g., MONITOR, IPXCON, TCPCON, a screensaver, etc.)?
• Is somebody using NetBIOS over IPX (Windows f. Workgroups,
NT, Win95)? You may need to set ipxAdmNETBIOSRepl to “off” or
“lan_only”.
• Are NDS Replica Synchronization running?
(For Netware 4.1 servers)
• Set the biboAdmSyslogLevel = debug and check the syslog table. The
IPX messages sent to the biboAdmSyslogTable will tell you why
(by packet type and socket) a connection is being established. It
may be possible to filter these packets.