Novell is now a part of Micro Focus

My Favorites

Close

Please to see your favorites.

Troubleshooting TCP/IP Bind Problems

(Last modified: 30Jan2003)

This document (10018662) is provided subject to the disclaimer at the end of this document.

goal

Troubleshooting TCP/IP Bind Problems

fact

Novell NetWare 4.2 Support Pack 9 (NW4SP9.EXE)

Novell NetWare 4.2 Support Pack 8A (NW4SP8A.EXE)

Novell NetWare 5.0 Support Pack 6A (NW5SP6A.EXE)

symptom

Duplicate IP address detected

Support for all 1 and all 0 subnet masks

Cannot bind multiple IP addresses

Cannot bind secondary IP addresses

fix

Bind algorithm on NetWare

Gratuitous ARP feature

Common BIND Problems and solutions

Reference TIDs

1. Bind algorithm on NetWare
2. Gratuitous ARP feature
3. Common BIND Problems and solutions
4. Reference TIDs

1. Bind algorithm on NetWare
============================

When IP is bound to the LAN card, the following steps are taken before the IP address is successfully bound. A failure at any step in the process will lead to a message being displayed at the server console, and a IP not being bound to the LAN card.

a) Make sure an address exists:
        This is a simple check to make sure that an IP address is specified along with the BIND command.
b) Check for special addresses (Class D or greater):
        These addresses are not legal and the BIND request will fail.
c) Check for loopback address:
        This address is not legal and the BIND request will fail too.
d) Check for conflicts with IP addresses bound to other card on the same server:
        This involves looking at subnet masks to make sure that the subnet portions of addresses do not overlap.
f) Check if default gateway on the same subnet:
        If the default route does not belong to the same subnet as the BIND address it will not get added to the routing table.
g) Check flags for poison reverse, broadcast address, proxyarp, arp.
h) Assuming arp enabled for that interface (default):
        Do a gratuitous ARP request (see below) to verify no one is using our IP address.

2. Gratuitous ARP feature
=========================

Novell's TCPIP.NLM can generate a gratuitous ARP request packet when IP is bound to any of its interfaces. The gratuitous ARP packet is an ARP request with both sender's and the target's IP address fields containing the configured IP address. This de-facto behavior allows any other host following the original protocol to detect the duplication and to send an ARP reply. Once the stack, having sent the gratuitous ARP, receives the unexpected ARP reply, it will display a warning on its console that an IP address duplicate has been detected (see below) and remove the IP Binding. The Novell stack can also be configured to ignore reply's to the gratuitous ARP request and continue to BIND the configured IP address if the "SET Allow IP Address Duplicates=ON" command has been SET at the server console. This should only be used in a test environment, or may be used in cases where a fault tolerant environment is being setup.


3. BIND Problems and solutions
==============================

Problem 1:- IP Address conflicts

When trying to BIND an IP address to a LAN card, the following message appears on the system console if
a) an IP address duplicate is detected (valid detection), or
b) a Switching device is incorrectly proxy'ing ARP responses on behalf of an IP host (invalid detection).

"TCPIP-5.20-112: Bound to board 1 with IP address 130.57.61.55 and mask
 FF.FF.FC.00.
TCPIP-5.20-78: This Server and the system having hardware address
 0-0-39-a6-f3-15 have conflict for IP address 130.57.61.55."

Solution:

a) Valid Detection of duplicate IP address

In the case where an IP address conflict is actually occurring, the MAC address of the other IP host having the same address is included with the error. For example, in the above case, the host having the 0-0-39-a6-f3-15 MAC address has the 130.57.61.55 IP address already bound. The Novell stack will, by default, NOT BIND the same IP address to it's LAN card when this IP address conflict occurs. To bind the IP Address even if it conflicts with another node on the network, set the "SET Allow IP Address Duplicates" variable to On.

a) Invalid Detection of duplicate IP address

In the case where a hardware device or switch Proxy's an ARP response back to the Novell TCPIP stack, IP will not BIND to the LAN card by default. The problem here though is that the ARP response from the switch claims that our own MAC address is the conflicting host! To verify that this indeed is the problem, the following could be used:

        * SET TCP ARP DEBUG = ON. This will dump all incoming/outgoing ARP requests at the server console. Make sure that the initial gratuitous ARP request goes out. Assuming that no one on the segment has the same IP address, there will be no response obtained. If         there is a response, check if the source IP address corresponds to the proper IP address. There         is likely to be a switch that is responding incorrectly to the ARP requests.

        * Network trace will also show the same information. Note that ARP requests are Broadcasts at the MAC layer so make sure that filters are not set to ONLY capture Unicast packets.

The solution to this problem is twofold:-

        * Contact the switch manufacturer and check to see if a solution or configuration parameter exists that will switch off the proxy ARP responses.

        * Temporarily use the "SET Allow IP Address Duplicates=ON" command at the server console so that the TCPIP stack goes ahead with the BIND.


Problem 2:- Cannot BIND multiple card to same subnet

Server has two LAN cards. Want to bind both cards to the same IP subnet. When attempting to bind the second card get "TCPIP-5.20-44 You already bound that IP Network to the interface with address <xxx.xxx.xxx.xxx>".

Solution:

It is not possible to bind multiple LAN cards to the same IP subnet. However, a secondary IP address (or addresses) can be added to the existing LAN card. This will result in one LAN card bound to multiple IP addresses. Users will be able to access the server using either a
address.


Problem 3:- Memory Allocation failures

Anytime the system console reports an "Could not allocate resource ..." message, it is simply saying that there are not enough system resources to allocate.

Specific BIND related examples include:-
        "Cannot allocate resources to add secondary IP address <xxx.xxx.xxx.xxx>"
        "Could not allocate resource tag for ARP."
        "Could not allocate memory for the ARP interface block."
        "Could not allocate resource tag for configuration. Will run without configuration file"
        "Could not allocate memory for Inverse ARP interface block."
        "Could not allocate memory for IP interface block."

Solution:

Verify the system resources through MONITOR. There should be at least 20% available cache buffers (viewed in main screen). If the value is below that, add more memory to the system as behavior can be unpredictable.


4. Reference TIDs

10013578 - How to bind IP to the server?
10008987 - How do I change the bind order of a NetWare?
10011261 - How do I create variable length subnets?
2946345 - Can't Bind Multiple LAN Cards to Same Subnet
2931253 - TCPIP Address Bind Message - Same Network
2919430 - Cannot bind IP to second LAN card
1004750 - NETCFG handles the gate= bind parameter
2939746 - System rejected IP bind request with NetWare for Small Businesses
2917431 - Can't bind IP with subnet mask for NW4.1
2927188 - bind failed duplicate entry / csl rejected.

disclaimer

The Origin of this information may be internal or external to Novell. Novell makes all reasonable efforts to verify this information. However, the information provided in this document is for your information only. Novell makes no explicit or implied claims to the validity of this information.
Any trademarks referenced in this document are the property of their respective owners. Consult your product manuals for complete trademark information.

  • Document ID:
  • 10018662
  • Solution ID: 1.0.33877216.2355297
  • Creation Date: 08Oct1999
  • Modified Date: 30Jan2003
    • NovellGroupware

      NetWare

      BorderManager Services

Did this document solve your problem? Provide Feedback