Subject: 13. My connection won't stay down! Help!

When configured this way, the filters inform your unit which packets should be ignored as traffic.

Protocols such as LAT, DECnet, XNS, NetBIOS and Vines don't have pre-written filters, and have yet to be formalized. Appropriate filtering examples will be included in the FAQ as they come along, but if the intent is to block an entire protocol type (or prevent it from resetting the idle timer as a Call filter), a generic filter of the following form may be implemented:

Valid=Yes
Type=GENERIC
Generic:
  Forward=No
  Offset=12
  Length=4
  Mask=ffff
  Value=protocol ID
  More=No
    

UNIX System Tips

• If you're automounting remote filesystems via NFS, make sure processes aren't periodically accessing those directories. [Greg Grose]
• Don't run sendmail with a periodic queue-check interval (the '-q#m' option); instead, just put it in the background and run a cron process under root that only processes the mail queue after making sure the link is up first.[ Greg Grose]
• Run your local window manager with the "save under" option, which prevents it from bringing up the link on exposure events (e.g. every time you uncover the icon or window from the background, and the WM refreshes the display). [ John Galloway]
• Make sure syslog isn't pointing to a loghost across the ISDN link. [Rob Logan]

• 13a. Novell "spoofing"

  Ascend recently included a few software features to make bridging Novell IPX traffic less painful. The 4.4 release notes (dated 2 Feb 95) do a good job of explaining the feature.

  Some background: NetWare servers expect all connected client systems to be reachable, and expect to hear a watchdog "are you there" packet at regular intervals. If they don't for an extended period of time, the client connection is cleared, and the user is logged out. In addition, Netware servers send out announcements of various network services once per minute. Both of these attributes can cause the line to remain up even when there's no "interesting" user traffic. SAPs can be handled simply by ignoring them using a call filter (and Ascend provides a predefined filter to do just that), but watchdog keepalive packets must be sent. If not, users run into situations where, when the line idles out for a while (i.e. a file is being edited on their local system), and the next time they wish to access their fileserver, they find the server session has been logged out. Windows has been known to deal with this condition, umm, less than gracefully. :)

  Ascend's solution was to include a new connection profile menu (called "Ipx options..."). Setting "Handle IPX=Server" means this Ascend unit (the one on which the setting is applied) will send out keepalive packets for the remotely-bridged workstations connecting over the associated link. The "Netware t/o" value is the length of time (in minutes) that this spoofing will continue.

  The Ascend unit on the opposite side of the connection should set "Handle IPX=Client". This assumes there are only Netware clients on that local ethernet; if there are servers there as well, both should set "Handle IPX=None".