Forum Discussion

f_buirey's avatar
f_buirey
Level 3
9 years ago

Netbackup appliance 5230 & Fibre Channel Autonegotiation

HI,

I have deployed a 5230 appliance with 2.6.1.2 release. During the configuration of FibreTransport media server, I had several issues with the link between SAN Switch (Brocade 16Gb FABOS 7.3.0c ) and  the target ports on the appliance (port 1 on slots 5 & 6). Looking at the porterrorshow on my switchs I saw a lot of loss of sync on the Switchs ports.

I have solved theses issues by setting the speed to 8 Gbs on the switch.

Does anybody experiment the same issue with Appliance (for my part, it was the very first time after many deployement) ?

 

regards

 

  • In my experience and, as far as I know, the best practice from vendors of OEM equipment (e.g. HP) is to always set fixed speed on SAN switch ports.  I have personally never left a SAN switch port in auto-negotiate mode.  It's just something that we learnt, long ago, to not do.

    It's better to have fixed speed and to enable monitoring of port errors, than it is to leave a port to negotiate downwards in speed.  Both ends can then concentrate on data traffic handling rather than spending time and traffic negotiating speeds.  And you get to nip problems in the bud sooner, because more errors will be detected sooner.

    One of the best tests is to simply check the light signal / power levels.  Any signal loss greater than -12dB on a standard server to switch connection really should be investigated and rectified.  SANs should on the whole be really very very clean indeed, with the only known signal loss events being server reboots.  Flapping up/down ports can be quite disruptive.  More best practice is to persitently disable known unused ports - and only re-enable them when zoning/adding new cabling/patching and connectivity.

  • In my experience and, as far as I know, the best practice from vendors of OEM equipment (e.g. HP) is to always set fixed speed on SAN switch ports.  I have personally never left a SAN switch port in auto-negotiate mode.  It's just something that we learnt, long ago, to not do.

    It's better to have fixed speed and to enable monitoring of port errors, than it is to leave a port to negotiate downwards in speed.  Both ends can then concentrate on data traffic handling rather than spending time and traffic negotiating speeds.  And you get to nip problems in the bud sooner, because more errors will be detected sooner.

    One of the best tests is to simply check the light signal / power levels.  Any signal loss greater than -12dB on a standard server to switch connection really should be investigated and rectified.  SANs should on the whole be really very very clean indeed, with the only known signal loss events being server reboots.  Flapping up/down ports can be quite disruptive.  More best practice is to persitently disable known unused ports - and only re-enable them when zoning/adding new cabling/patching and connectivity.

  • Yes I faced the similar issue with 5330 and than we have to fix link speed at switch level from autonegotiate to 4GB. (Since switch in my environment were having 4GB ports only). In my case Appliance version was 2.6.1 because customer was not ready to upgrade Master server beyond 7.6.1.

  • Fixing the speed at the switch would be my preferred option, on a 5230 the max support speed is 8GB for the fabric. The other advantage in my experience with fixing the speed is that if there is a future issue with the link, rather than auto-negotiation dropping the speed to 4 then 2 and 1 and this resulting in performance related symptoms which are hard to troubleshoot you will get a clear break and hence identify the fault sooner.