02-21-2013 11:30 AM
With FOS7.0.0, understanding that detection of duplicate wwpn is much more robust (previous versions only logged errors) in that it will disable the port or based on a policy will decide the action. Our existing EDL vendor is stating that when they support automatic engine fail-overs, the surviving engine will take-over the failed engines wwpn, however if the failed engine is still powered on, it too will also have the same wwpn trying to login to the switch. So before we moved our switch FW to 7.0.0x, the fail-overs seemed to work in most cases and the switch would not disable the port.
My question is as I'm very new to FC and Fabrics, is that has Brocade made these changes in FOS7.0.0 to enforce more completely the FC Spec's of not supporting duplicate WWPN and also allow for the new FA-WWN features, and that my EDL vendor should be changingto meet these specs (they should'nt have been producing duplicate WWPN's in the first place?) Are there workarounds to support this behavior in the switch (specifically FC-AL and MIB connections )? Can someone help me understand if I should be pushing back on the vendor or do I now have to do more policy or workarounds on the switch to support this kind-of behavior? Thanks for any education you can give me,
02-21-2013 02:33 PM
My first suggestion would be to test this offline before committing, as it will completely depend on your EDL vendor's exact behavior. Technically speaking if they do produce duplicate WWPN, they are in violation, but i will check (with the product manager) to see if their is a delay before FOS 7.x pulls any triggers and shuts down the port.
So before pushing back on the vendor, hang tight until i get a firm answer on the exact Brocade behavior as this may be a none issue.
More to follow...
02-22-2013 06:47 AM
Hi douglas.irion. Thanks for your patients while i confirmed the exact behavior.
So the question is answered by two different possible scenarios.
The question: "Does FOS take immediate action on the duplicate WWPN or is there a slight delay to accommodate these failover scenarios?"
Case 1 – same switch: If the duplicate login is on the same switch (i.e. in this case device failed over to a different port on the same switch) – the action is immediate as in when the second device (with same WWPN) is attempting login.
Case 2 – different switches with in the fabric: switches with devices logged in exchange some information (to confirm duplicates indeed exist) after devices have successfully logged in – so there’s slight delay before action is taken.
02-22-2013 07:49 AM
Thanks so much for your quick response. So to be clear, on the same switch my EDL vendor should not be producing "Duplicate" wwpn's from two different sources during a engine failover (or anytime for that matter) at the same time. The fact that FOS 7.0.0x and grater now strictly enforces this spec by disabling the port, where previous FOS OS levels only logged these violations, now should require my EDL vendor to adhere to spec.
One last question then, workarounds for this issue. We have found that if you Persist Enable the port, the port will at least not lock down when duplicate wwpn's are found. We are testing this in the lab today to verify if this workaround will at least support the current EDL failover functionality. Is this a valid workaround for now to Persist Enable the ports? Specifically we are using FC-AL with MID on these ports.
Understand there are ways you can set policy's like always use the existing source wwpn when a duplicate wwpn is generated, but it seems unlogical that a policy could determine which EDL engine was valid. So were trying to understand if we can workaround this issue with 7.0.0x, or that we may be required to down grade the FOS OS level to support the EDL Vendor until fixes can be implemented.
Thanks for your help.
02-22-2013 09:18 AM
Hmmm... the action taken by FOS in the event a condition match triggers is to persistently disable a port, so your proposed idea may work, but without testing i cannot say and there is no documentation on what you describe I'm afraid.