02-26-2010 02:15 AM
could you help me with one question? What does "Address Error" mean on switch E-port and how to eliminate it? Look at the output from the port "Error Details":
Link Failure 1
Loss of Sync : 14
Loss of Signal 1
Protocol Error, 0
Invalid Transmitted Word 0
Invalid CRC 0
Delimiter Error 0
Address Error 1
Inbound Link Reset 4
Outbound Link Reset 7
Inbound Offline Sequence 7
Outbound Offline Sequence 0
FC switch = Brocade 3850 (FOS - 5.3.2a)
03-01-2010 07:46 PM
I'm no authority on FC theory, but this is what I know.
This occurs when the DEST port or the fabric is temporarily busy, and this port where you see the error is not able to send the frame. Could be related to lack of buffers on the destination port or on any other connected ISL port.
If you think this answer is satisfactory, kindly mark one of the answers correct and close this thread.
03-02-2010 01:22 AM
thanks for the answer, but, as I understand, there is no problem with buffers allocation to ports in my case (look at the "PortBufferShow" output attached below).
03-02-2010 02:22 AM
Q1: Is there any problem in the fabric that worries you??? Do you see any impact on host performance etc??
To ascertain whether you have any problems due to lack of BB credits, collect the following over a period of time on all ISL ports only.
portstats64show - check for tim64_txcrd_z and stat64_ftx
See if the number increases. Report the deltas here and I will TRY to analyse if you really have problems. Again its just a TRY.
03-02-2010 06:24 AM
03-02-2010 07:47 AM
These ports look fine to me. The delta of the counters isn't enough to be worried about.
To confirm if your fabric has no problems, requires a lot of analysis from multiple log files from multiple switches over a period of hours/days, which I do not intend to do on this forum None of your counters, even the one you posted earlier are any cause of concern.
I suggest you look for other factors that may be affecting IO performance and look to troubleshoot the SAN only later.
If you do not see IO timeout errors on the host, just perform the basic checks on the porterrshow counters. You need to be worried only if you see the counters incrementing at a fast pace.
Note : This note may be of help to you and others on the forum.
Loss of connectivity to a Host, Storage or another Switch can be caused by a faulty SFP or a cable. The Switch error Log would show an error similar to the following:
2007/12/06-23:50:56, , 7682,, WARNING, SWITCH_1, Switch status changed from HEALTHY to MARGINAL 2007/12/06-23:50:56, , 7683,, WARNING, SWITCH_1, Switch status change contributing factor Marginal ports: 1 marginal ports. (Port(s) x )
To determine whether the SFP or a cable is the cause of the loss of connectivity, perform the following:
Check the output of "porterrshow " from the switch.
"enc out " errors alone imply primarily cable problem.
"enc out " and "crc err " combination imply primarily GBIC/SFP problem.
To find out if source or destination SFP is causing the error, Check the Output of "portshow x" where x is the port number.
If the pair of "Lr_in " and "Ols_out " as well the "Lr_out " and "Ols_in " values are "quite" equal, it is a normal case.
If one counter is significantly higher than the other, the link problems either "reached" the switch ("in" > "out") or are caused by the switch ("out" > "in").
Note: If the “Ols_in ? value is higher than the “Lr_out ? one, then the “problem source? is, in most cases, more related to the attached device (sending those offline sequences) and the switch responds to them with a "link reset".
enc_out -> Encoding error outside of frames crc err -> Frames with CRC errors Lr_in -> Link reset In (primitive sequence), does not apply to FL_Port Lr_out -> Link reset Out (primitive sequence), does not apply to FL_Port Ols_in -> Offline reset in (primitive sequence), does not apply to FL_Port Ols_out -> offline reset out (primitive sequence), does not apply to FL_Port