Notes de mise à jour de Veritas NetBackup™

Problème d'expiration de connexion avec le serveur maître NetBackup purement IPv6 et l'hôte double pile

Dans un environnement mixte d'adresses IP dans lequel le serveur maître NetBackup est un serveur purement IPv6 et le serveur de médias (ou l'hôte client) est un serveur double pile, la connexion entre le serveur maître et le serveur de médias (hôte client) arrive à expiration. Cela peut provoquer un problème d'expiration de validation de l'hôte pair par rapport à une communication sécurisée. La commande bptestnetconn -w -H <nom du serveur maître purement IPV6> a besoin de beaucoup plus de temps pour se connecter (parfois plus de 120 secondes pour exécuter la commande).

Le message d'erreur suivant s'affiche :

Lorsque la commande bptestnetconn -w -H <nom du serveur maître purement IPV6> est exécutée à partir d'un hôte de médias ou client, le délai de connexion au serveur maître est beaucoup plus long.

Les entrées du journal de débogage nbutils vxul affichent la sortie suivante :

Connecting to [10.210.71.166]:[1556].,35:nbclnt_curl_prefnet::helper_connect,5
NON-Blocking connect in progress. Watch WRITE.,35:nbclnt_curl_prefnet::helper_connect,5
New sockfd is [5].,35:nbclnt_curl_prefnet::helper_connect,5
Returning VN_STATUS_SUCCESS,35:nbclnt_curl_prefnet::helper_connect,5
Returning VN_STATUS_SUCCESS,42:nbclnt_curl_prefnet::tryeach_iface_connect,5
Returning rc,49:nbclnt_curl_prefnet::establish_initial_connection,5
Returning VN_STATUS_SUCCESS,33:nbclnt_curl_prefnet::nbio_connect,5
RC [0] STAT [-1] MAXFD [5] TIMEOUT [150].,32:nbclnt_curl_prefnet::bio_connect,5
Non-blocking connect attempt failed. errno=[110]=[Connection timed out],48:
   nbclnt_curl_prefnet::helper_check_connect_status,1
:For host [pdqebl26vm12.pne.ven.veritas.com] already tried connecting to [10.210.71.166],
   now trying[2620:128:f0a1:9006::167].,39:nbclnt_curl_prefnet::iterate_next_iface,5
[vnet_addrinfo.c:9125] vnet_configured_stacks(), remote_ipv4_supported flag:
   1 0x1,20:vnet_adjusted_family,1
[vnet_addrinfo.c:9126] vnet_configured_stacks(), remote_ipv6_supported flag:
   1 0x1,20:vnet_adjusted_family,1
[vnet_addrinfo.c:5173] using interface  ANY,27:vnet_get_pref_netconnection,4
Returning VN_STATUS_SUCCESS,44:nbclnt_curl_prefnet::usable_prefnet_settings,5
Returning VN_STATUS_SUCCESS,39:nbclnt_curl_prefnet::iterate_next_iface,5
Connecting to [2620:128:f0a1:9006::167]:[1556].,35:nbclnt_curl_prefnet::helper_connect,5

La recherche DNS du serveur maître purement IPv6 renvoie deux adresses IP (IPv4 et IPv6) au lieu de l'adresse IPv6 seule. Cela est possible si le serveur maître a déjà été configuré en mode double pile. Tandis que la connexion est établie entre le serveur de médias (ou l'hôte client) et le daemon du serveur maître, les API VNET trient les adresses IP. Toutes les adresses IPv4 sont triées en premier lieu, puis les adresses IPv6 sont triées indépendamment de la famille d'adresses IP définie dans le fichier bp.conf. Pour cette raison, le serveur de médias (ou l'hôte client) essaye d'abord l'adresse IPv4, mais expire car le serveur maître est un serveur purement IPv6, puis il essaie l'adresse IPv6. Finalement, l'opération de validation de l'hôte pair expire avant la connexion IPv6.

Solution de contournement : évitez les tentatives de connexion IPv4 (adresse IP inutilisable pour le serveur maître purement IPV6) en paramétrant PREFERRED_NETWORK dans le fichier bp.conf du serveur de médias (ou de l'hôte client) à partir duquel la connexion est lancée. Définissez le paramètre PREFERRED_NETWORK comme suit :

PREFERRED_NETWORK = <adresse du serveur maître purement ipv4> PROHIBITED