IP Costing in Client for Open Enterprise Server 2 SP4

  • 7018281
  • 16-Nov-2016
  • 16-Nov-2016


Client for OES 2 SP4 (IR1)


IP Address Costing is not working correctly; the Client is not connecting to the closest available eDirectory server.


Prior to Novell Client 2 SP4 for Windows (IR1), the IP Address Costing feature was not working correctly. This problem was resolved in Novell Client 2 SP4 for Windows (IR1) and subsequent releases, including Client for Open Enterprise Server.

The Novell Client/Client for Open Enterprise Server IP costing mechanism is being utilized at any point where we have “a list of addresses to choose from.” That kind of event happens in response to two things, essentially:
  • A name resolution request through NSNS (i.e. SLP and/or DNS), or 
  • An eDirectory resolve that returns referrals for which replica(s) hold the object resolved. 
If either of these operations return more than one address, we will use costing to sort the list of addresses before we begin attempt making or using an NCP connection. Such that if making or using the NCP connection to the first address in the list works, we will have chosen the best address according to the current costing information.

(Note any NSNS resolve or eDirectory resolve could potentially return multiple addresses. NSNS is sending us the address results from all the name resolution methods, and even within a single resolution method, multiple addresses can be returned from either DNS or SLP. In DNS this would happen when multiple addresses for the same name have been defined in DNS. For SLP it just depends on what you’re resolving. If resolving a single server name in SLP then the multiple addresses represent all the address types and interfaces the server is bound to. If resolving an eDirectory partition boundary or eDirectory tree name in SLP, you can get dozens or hundreds of matching entries for all the various eDirectory replica servers that exist in the tree.)

IP Costing uses a TCP SYN connection establishment to measure whether the server is actually listening on the NCP port (typically, but not always, TCP port 524) as well as the time it took for the server to respond to establishing the TCP connection. This TCP connection attempt “is for costing purposes only” and will not cause an actual NCP-level connection to be established. We just establish the TCP-level connection and then tear it down, both to measure the operation time and to prove the NCP server is actually available at this address.

What you will see in a LAN trace is that, whenever an SLP query returns two or more TCP address attribute values, or whenever a DNS resolve returns more than one address, or whenever an eDirectory resolve returns more than one referral, the FIRST TIME we encounter those addresses you will see a bunch of TCP SYN connection attempts go out to those addresses, which are then just immediately torn down. Those costing results are then cached, so you shouldn’t see the same activity occur again for the exact same addresses, until the cached results expire. During future resolution attempts, only addresses which aren’t already in cache will have new costing TCP connections created.

Whichever address was recorded as having the fastest overall TCP SYN round trip time should be selected as our first NCP connection to attempt using or establishing in response to the resolve. (Best cost.) Any addresses for which the TCP SYN attempt timed out (NCP server not running or not responsive, even if the host itself is up) should be the last addresses we allow to be attempted. (Worst cost.)

Additional Information

The related registry setting for the IP Address Costing policy is

Value Name: IP Address Costing
Type: DWORD 32
Data Range: 0 (disabled) or 1 (enabled)