Forum Discussion

Johncu's avatar
Johncu
Level 3
16 years ago

cannot telnet to 13782 to a DMZ server from new Netbackup system, but can on old.

Hi

I have 2 Netbacvkup systems, one legacy Solaris based, and one new Redhat based.

I have successfully moved many clients to backup up from the old to the new, including several Windows DMZ clients but I have a problem with one.

I can backup and connect via telnet to the 13782 port from the old master server, but I cannot via the new one.

When I try to backup I get an error 54.

When I try to telnet to port 13782 it just hangs.

I on the client I have changed the Master server name to be the new masterserver, and also updated C:\WINDOWS\system32\drivers\etc\hosts to include the new master server and all new media servers.

I have been seen on the firewall setting on the client that access to 13782 is allowed, and I have proved this by telnet'ing to 13782 via the other system.

I can ping and nslookup/reverse lookup from the new Master server ok.

The network team have assured me that I should be able to connect, and I am inclinded to beleve them as I can connect via the old system.

Is there any settings on the Master server in Netbackup, or Linux that I need, or is there anywhere else I may have to set something on the Windows client??

I am running 6.5.4 on my linux server and the client software on the client is up to date.

Thanks

John
7.1.x and Earlier
Backup and Recovery
Configuring
NetBackup
Windows
  • Johncu's avatar
    Johncu
    16 years ago
    Hi

    Many thanks for the replys, it turned out to be simple, on Windows firewall on the client, the ports NBU requires were entered as exceptions, but I did not realise there was an option to click through and add a subnet mask. Changed the subnet mask for the NBU ports to the subnet that the new Master and Media servers for that policy use, and it is all working.


    cheers John
  • Andy_Welburn's avatar
    Andy_Welburn
    Level 6
    16 years ago
    server ok"

    Can you from the client to the new Master?

    Have you tried using bpclntcmd to test connectivity/name resolution?

    Any typos in your 'hosts' file(s)?
  • Nicolai's avatar
    Nicolai
    Moderator
    16 years ago

    Be aware of NBU 6.5 now operates default on the firewall compliant  VNETD port (13724).

    Try to run tcpdump on the master server and compare a working client VS a non-working one.

    #  tcpdump -n -f -i eth???  ip host {name or IP of client}

    If you see no incoming  packets, check with the network admin again. 


  • Omar_Villa's avatar
    Omar_Villa
    Level 6
    16 years ago
    Remember that you only need to test vnetd and bpcd between media server and client, the master doesnt need to connect with the client.
  • Nicolai's avatar
    Nicolai
    Moderator
    16 years ago

    If the client need to initiated restores, it must be able to connect to the master server.
  • Johncu's avatar
    Johncu
    Level 3
    16 years ago
    Hi

    Many thanks for the replys, it turned out to be simple, on Windows firewall on the client, the ports NBU requires were entered as exceptions, but I did not realise there was an option to click through and add a subnet mask. Changed the subnet mask for the NBU ports to the subnet that the new Master and Media servers for that policy use, and it is all working.


    cheers John