How to activate 2nd FC port on NSR2402

[Eric van Dijken]

We are trying to connect a NSR 2402 redundant to our SAN. The NSR has 2 FC ports, wouldn't it be nice if we could connect each port to a different fabric of our SAN. So far all our efforts have failed. The light on the 2nd FC port will not become active.

Anyone done this and if so, whats the trick?

[John Griffith_3]

Hello,
Yes, I've utilized both ports on the NSR. My configuration was not HA however, and you have to be sure your software understands what you're trying to do with multiple paths.

In terms of what you're seeing, I suspect that the port is not configured correctly. Notice that on the NSR each port is independent and needs to be configured individually.

Are both Fabrics running the same topology (N-Port, 1 Gig or 2, etc).

Your best bet may be to just try and copy the settings from one port to the second. The next step would be looking at the other side of your fibre link.

Thanks,
John

[Eric van Dijken]

Yes, as far as i tell, both ports are configured the same.

But on Port 0: the Link is UP, on Port 1: the link is DOWN. Switching the FC cables doesn't help either. And connecting Port 1 only, also gives no joy.

Don't think its a hardware problem, as we have 3 of them and they all act the same. So my best guess is thats somehow "Software" related.

Fibre Channel Configuration : Module 0, Port 0

Link Status: UP/FABRIC
Port Name: 0x100000E0 02028B4A
Port Mode: N_Port Mode
Use Hard ALPA: No
Discovery Mode: Auto Discovery on Reboot Events
Buffered Tape Writes: Enabled, Queue Depth = 1
Current Default Map: 'Indexed'
Performance: 2 GigaBit

Fibre Channel Configuration : Module 0, Port 1

Link Status: DOWN
Port Name: 0x100000E0 02028B4B
Port Mode: N_Port Mode
Use Hard ALPA: No
Discovery Mode: Auto Discovery on Reboot Events
Buffered Tape Writes: Enabled, Queue Depth = 1
Current Default Map: 'Indexed'
Performance: 2 GigaBit

[David Ruska]

Eric, I think I may have the answer.

From the 5.3.0b release notes:
"FC Link will not initialize if multiple FC ports are in use". The 4.03.25 firmware introduced an issue where the controller FC link might not initialize after a controller reboot (cold or warm) if multiple ports are in use.

Here's a link to the 5.3.0b firmware:
ftp://ftp.hp.com/pub/softlib/software2/COL3566/co-12621-3/5.3.0b_fw_winston_x.dlx

This firmware is for use with the telnet/ftp/serial interface (not HP LTT).

[Eric van Dijken]

One again i have switched the FC connected to Port 0: to Port 1: and rebooten the NSR.

No joy, the link on Port 1: just wont come up.

Ill have to try the 5.3.0b firmware, i'll update this thread when i have done that.

[David Ruska]

The engineering team said they would like to look at the report page output.

On the NSR Web Interface, select "Report" from Main menu.
Select "Printable View".
From explorer, use "File -> Save as" and save as "web page complete" to whatever name you want.

You can email the .htm file to ltt_team@hp.com

The engineers are divided as to whether 5.3.0b will resolve your problem, but it is certainly worth trying.

Given their uncertainty, you might want to generate the report page before updating firmware and we'll get started reviewing it.

[Eric van Dijken]

Report file has been send to HP.

While checking the report, i came upon a lot of errors (why didn't i check that before....)

66ms 653us >>> Received a Link Failure on port: 0x1
0ms 0us >>> LOSS OF SIGNAL, or Out of Sync. Check Link Module and its connections.
0ms 0us >>> LASER FAULT
0ms 0us >>> Out of Sync. Resetting iTR
50ms 9us >>> Tachyon port: 0x1 entered non-participating mode!
0ms 0us >>>Elastic store ERROR(s) on port: 0x1


Not that it would change anything ofcourse, we have 3 of them and they all have these errors. And as mentioned above, switching cables that work on port 0: doens't help.

And while i am add it, some more information from our NSR.

Vendor HP
Product StorageWorks Modular Router
Firmware Level 4.03.19
Bios Version BIOS 4.23
Booter Version BOOTER 4.11
MCU PLD Version 0x3
CPU PLD Version 0x2

[Eric van Dijken]

If i didn't see it myself, i wouldn't have believed it. On all our NSR's (3), the 2nd GBic was defective.

Switching GBic's made me find the real problem, with the help from HP support (thanks don)

[David Ruska · Accepted solution]

We will have Eric return us the failing SFP transcievers for testing. If anyone else is seeing problems similar to this, let us know.

- hp engineering