This can be done.  You need to configure netbackup to use the hostnames associated with the fibre NIC's rather than the hostnames associated with the LAN NIC's. 

  fix the network problem?

Have you looked in to the SAN client option?  This will allow your backups to occur over fiber.

We will try that and post the outcome...

I can't find any setting to change that. Can you tell me where it is?

Well this is where things can get a little tricky. 

You would need to follow steps on decomissioning a media server for the old names. 

for 6.5:
seer.entsupport.symantec.com/docs/306838.htm

for 6.0:
seer.entsupport.symantec.com/docs/289139.htm

I would advise you read this thread in it's entirety:
www-secure.symantec.com/connect/forums/how-correctly-decommission-netbackup-media-server-and-remove-it-netbackup-v60

To add entries for the new media server names use the host properties section of the admin GUI, select the master host properties and then in the new window choose "servers".  Her you can add entries for the new server names, and remove the entries for the older ones.

And finally seriously consider whether going this route is worth it.  It may be worth your while to fix your network problems. 

Couldn't you add the new names and simply leave the old ones for a couple of months until you no longer need those backups?

Well thats the approach people usually take when the old and new media servers are different physical servers.  Not sure about the impact of both the old and new media servers being the same physical box.

Using SAN client, data transfer happen over SAN, but control information is transferred over LAN. If you're LAN is buggy you will have problems with SAN client as well. SAN client cost you extra licenses as well.

I never see TCP/IP enabled over Fibre Channel network, so the robustness of the implementation is possible questionable.

NetBackup server and clients will not communicate over the SAN as matadata and client-server communication will always happen over LAN.

You can leverage on your existing SAN infrastructure to send the backup data over the SAN. For doing this you will need to go for additional Enterprise client licenses and convert your NBU client into Enterprise clients.

You will also need to share your FC based tape library to the so-called enterprise client by creating zones on the FC-SW.
 
Also for sharing the same TL amongst master server and so-called ent client you will need Shared Storage Option (SSO) as well

By doing all this your master server will communicate to your so-called ent client over the LAN. In turn ent client will start the backup and will send the data to tape library which is shared to him. And metadata will be send to master server over the LAN.

Achieving this backup infrastructure many times is very costly affair for those who are not having SAN infrastructure available. But since you already have SAN you can achieve this...

Hope this clarifies the questions and queries...

How about this instead. Can't I set the retry for more then 2 times and change the intervals between attempts? Or is it once the TCP/IP connection is lost it never tries to re-connect to the Master again?

you can increase the retry count ...

for doind so refer to the NBU Admin Guide, Page Number 378

but instead that I would suggest that you first resolve the network issue....

Creating seperate backup VLAN sounds good many times :)

As many people have pointed out, you really need to fix the instability in your Ethernet LAN.  Personally, I would place a higher priority on fixing the LAN than on finding a job timeout value or job retry value in NetBackup that you can adjust to accomodate the unstable LAN.

Also, as many people have pointed out, the "LAN-free" backup methods available in NetBackup with additional licenses (such as the SAN Client option or the SAN Media Server / SSO option) don't completely isolate you from a flaky LAN.  NetBackup still uses the LAN to send control and metadata information between the master server, media server, and clients.  SAN Media Server / SSO environments in particular can be a real nightmare to troubleshoot in an unstable LAN environment, and can lead to inconsistencies and possible corruption of the NetBackup databases.

Additionally, the client computer doesn't initiate the TCP connection to the NetBackup master server.  Since the NetBackup master server handles all of the job scheduling functions, the NetBackup master server is the host that contacts the media server and client and tells the client to start a backup.  The NetBackup client software doesn't have the intelligence or logic necessary to attempt to reconnect to the NetBackup master server or media server if the network connection fails during the backup.