Forum Discussion

edvSDL's avatar
edvSDL
Level 4
14 years ago

Backup Exec Agent - how to change listening interface

Hi,

I need to change the listening interface on one of my BE agents. The reason for this is simple, when a backup job is run, beremote.exe and BE server for some reason communicate on a wrong network route.

 

C:\Users\Administrator>netstat -ano | findstr 10000
  TCP    0.0.0.0:10000          0.0.0.0:0              LISTENING       13228
  TCP    10.10.10.3:10000       192.168.7.14:21210     ESTABLISHED     13228
 

As you can see above, beremote.exe is listening on ALL interfaces (0.0.0.0) and a connection to the backup server (192.168.7.14) has been established on the 10.10.10.3 interface. Which means, the traffic is send to a router on the 10.10.10.0 network that is connected to another router on the 192.168.7.0 network.

The thing is, the server beremote.exe is installed on, is also directly connect to the 192.168.7.0 network by a secondary NIC. I have no idea why connections between beremote.exe and BE server are established on the 10.10.10.3 interface. Therefore I need to prevent beremote.exe from listeing on the 10.10.10.3 interface.

I can confirm ICMP packets as well as SMB connections are being established as intended on the secondary NIC.

 

Any help would be greatly appreciated!

  • You can't stop RAWS from listening on all NIC's however to get secondary networks to work you usually have to either use the IP address as the selection list or disable publishing from the remote agent and then sort out your name resolution so that the media server can only work out where the remote server is by the correct IP address.

    You then have to specify the secondary NIC card on the media server in the backup job properties

     

  • You can't stop RAWS from listening on all NIC's however to get secondary networks to work you usually have to either use the IP address as the selection list or disable publishing from the remote agent and then sort out your name resolution so that the media server can only work out where the remote server is by the correct IP address.

    You then have to specify the secondary NIC card on the media server in the backup job properties

     

  • Thank you,

    publishing is probable the cause of all this, gonna check this out on the next maintanance window.

  • Here is a quick update.

    Even though my simualtions have shown connections were still established on the wrong interface, today I noticed a scheduled backup task ran way much faster as usual during the night. This indicates the correct interface was used by the backup task.

  • When I disable publishing on the agent I can not add it to the selection list at all. An error message appears telling me to enable publishing.

    The name resolution is fine.

    There is no option to choose a specific network adapter in BE 2010 R2.

    I tried to remove the server from the selection list, but when I add the server by using its IP address it is listed by its FQDN again.

    So far.... no luck.....

  • Hello Colin,

    Disabeling publishing does not seems to be working in this case.

    Ca you please suggest some other way or work around by which we can get this working.

    Thanks in advance.

    -Clubguy

  • I tested all of this recently with a clustered remote server (to add complication to the backup network scenario, ignore the clsuter information if you just have stand alone remote servers) and saw it work and initiate both NDMP control and data connections on the secondary network - My exact workaround sent to the customer for the clustsred scenario - which did work were:

    BE 2010 R2 can backup using a secondary network on a cluster but there is a small defect restricting how you do it.
    1) Shared Cluster resources must have an IP address on the backup network
    2) If Remote agent publishing/advertising is enabled on the nodes of the cluster then you must use a User Defined Selection of just the IP Address (i.e. \\192.168.1.50)
    3) If Remote agent publishing/advertising is disabled on the nodes then you can use User Defined Selections of FQDN or DNS (short) name but name resolution must then resolve to the correct address for the Backup LAN (which in most configurations would need a host file change on the media server so as to not affect DNS for systems not on the Backup LAN)
    4) You must specify the NIC of the Backup LAN in the "Network Interface" drop down inside the "Network and Security" section of the Backup Job properties. NOTE: it helps if you give your networks useful names in the operating system.
    5) You must enable the option "Allow use of any available network interface, subnet, or protocol for remote agents not bound to the above interfaces, subnet or protocol"
    - Note you probably think you don't want to enable this option, however we have a small defect to do with the logic we use to detect that something is available on a specific network. As the logic returns an incorrect error condition even when it can use the specified network, if you tick this box and run the job and then look at the established network connections in the backup job logs you will see that both control and data connections have gone over the backup network.

    As a final Note: I tested backing up data of the local drives of one of my nodes using the secondary network and saw the same problem with that configuration as such the defect in our network resource detection is not specific to clusters and relates to any use of Backup Networks. Information on defect can be found http://www.symantec.com/docs/TECH7397