Environment
Products:
Novell NetWare 6.5 Support Pack 6
Novell Business Continiutiy Clustering
Configuration Information
Cluster resources have virtual IP Addresses bound to them using the bind command instead of using the "add secodary ip address X.X.X.X" command
When using the login script sys volumes are mapped before cluster resources
Novell NetWare 6.5 Support Pack 6
Novell Business Continiutiy Clustering
Configuration Information
Cluster resources have virtual IP Addresses bound to them using the bind command instead of using the "add secodary ip address X.X.X.X" command
When using the login script sys volumes are mapped before cluster resources
Situation
Symptons:
- When mapping to a cluster resource the mapping shows nodename\volumename instead of virtualncpserver\volumename.
- Clients cannot reconnect after resource failover.
- Lan trace shows mapping done to primary address of node instead of virtual IP address
- When using Virtual IP Addressing, users are unable to reconnect to a cluster resource after a failover has occurred.
Resolution
Cause:
When an IP address is bound to a server using the "bind" command we will populate this address in the network addresses field of the NCP Server object. The Novell client is designed to limit concurrent connections to server resources. It performs this function by reading the registered NCP addresses registered by NCP at the server. Therefore if an existing mapping exists to a server (even with a different resource name or address) and we try to map to another address that is bound to the same server, the Novell client, will perform the drive mapping using the existing connection. In summary we could conclude that the following occurs.
1. The Novell client connects to the server with it's primary IP address
2. The client then queries the server for all registered NCP addresses
3. The server returns all registered IP addresses. By default the server would return all IP addresses bound to the server. This means that both the primary IP address and any virtual IP addresses.
4. The Novell client now stores the registered IP addresses in it's internal connection table.
5. When the new connection request for the virtual server is received by the Novell client, it first looks at the NCP connection table. It locates the virtual IP address as a valid address to the existing connection via the primary IP address.
6. The Novell client prefers the existing NCP connection and performs the mapping of the virtual IP address over the primary addresses current connection.
The following is an example of the problem login script:
Map s1:=my_server_primary_ip_address/sys:
Map f:=virtual_server/resource_1:
Map g:=virtual_server/resource_2:
This behavior does not occur when using secondary ip addresses. Secondary IP addresses are not added to NDS as registered network addresses in the NDS Server object of the node in question.
Fix:
A set parameter called " NCP INCLUDE IP ADDRESS" exists on the server. This, by default, is set to "all". This means that NCP will advertise/register all bound addresses. This would include both the primary IP address and any bound virtual IP addresses.
Change this setting to reflect only the primary IP address of the server using the command "set NCP include IP address= X.X.X.X" .
Changing this set parameter to only the primary IP address will instruct the server to only use this IP address as the registered IP address for the server. All other bound IP Addresses will not be registred with NDS. However, NCP will still be listening and avaiable on those IP addresses. This modification changes the behaviour of the binding of the Virtual IP addresses, to act the same as if they were secondary IP Addresses.
Another possible solution for this issue is to map to the virtual server resources first and then to perform mappings to local resources after the virtual server connections have been established.
For example:
Map f:=virtual_server/resource_1
Map g:=virtual_server/resource_2
Map s1:=my_server_primary_ip_address/sys:
By moving the mapping to the local resource (my_server_primary_ip_address) to the bottom of the mappings, then when the client encounters the mapping, it looks in the current connection table and cannot locate the address. At this time, the client will make a new connection to the local resource via the supplied primary IP address.
Note that this problem would also exist in cases where a name is resolved to an address via DNS or SLP. For example, our object my_server_primary_address, could be the actual DNS name of the server object. When the client encounters this name it performs a name resolve to the network. So this activity could also occur depending on what address is returned to the Novell client.
When an IP address is bound to a server using the "bind" command we will populate this address in the network addresses field of the NCP Server object. The Novell client is designed to limit concurrent connections to server resources. It performs this function by reading the registered NCP addresses registered by NCP at the server. Therefore if an existing mapping exists to a server (even with a different resource name or address) and we try to map to another address that is bound to the same server, the Novell client, will perform the drive mapping using the existing connection. In summary we could conclude that the following occurs.
1. The Novell client connects to the server with it's primary IP address
2. The client then queries the server for all registered NCP addresses
3. The server returns all registered IP addresses. By default the server would return all IP addresses bound to the server. This means that both the primary IP address and any virtual IP addresses.
4. The Novell client now stores the registered IP addresses in it's internal connection table.
5. When the new connection request for the virtual server is received by the Novell client, it first looks at the NCP connection table. It locates the virtual IP address as a valid address to the existing connection via the primary IP address.
6. The Novell client prefers the existing NCP connection and performs the mapping of the virtual IP address over the primary addresses current connection.
The following is an example of the problem login script:
Map s1:=my_server_primary_ip_address/sys:
Map f:=virtual_server/resource_1:
Map g:=virtual_server/resource_2:
This behavior does not occur when using secondary ip addresses. Secondary IP addresses are not added to NDS as registered network addresses in the NDS Server object of the node in question.
Fix:
A set parameter called " NCP INCLUDE IP ADDRESS" exists on the server. This, by default, is set to "all". This means that NCP will advertise/register all bound addresses. This would include both the primary IP address and any bound virtual IP addresses.
Change this setting to reflect only the primary IP address of the server using the command "set NCP include IP address= X.X.X.X" .
Changing this set parameter to only the primary IP address will instruct the server to only use this IP address as the registered IP address for the server. All other bound IP Addresses will not be registred with NDS. However, NCP will still be listening and avaiable on those IP addresses. This modification changes the behaviour of the binding of the Virtual IP addresses, to act the same as if they were secondary IP Addresses.
Another possible solution for this issue is to map to the virtual server resources first and then to perform mappings to local resources after the virtual server connections have been established.
For example:
Map f:=virtual_server/resource_1
Map g:=virtual_server/resource_2
Map s1:=my_server_primary_ip_address/sys:
By moving the mapping to the local resource (my_server_primary_ip_address) to the bottom of the mappings, then when the client encounters the mapping, it looks in the current connection table and cannot locate the address. At this time, the client will make a new connection to the local resource via the supplied primary IP address.
Note that this problem would also exist in cases where a name is resolved to an address via DNS or SLP. For example, our object my_server_primary_address, could be the actual DNS name of the server object. When the client encounters this name it performs a name resolve to the network. So this activity could also occur depending on what address is returned to the Novell client.