FICON License required on all switches?

Answered Question
Nov 21st, 2008

If I have multiple switches (all connected together) but only need FICON functionality on two of them, do I only need to license the two boxes?

Clearly I wouldn't be able to configure FICON ports on the unlicensed switches, but would there be any issues regarding trunking (ISL/EISL)?

Thanks

I have this problem too.
0 votes
Correct Answer by Michael Brown about 8 years 1 month ago

You are correct, you would need the FICON license on both switches where the FICON devices are to be attached. Since FICON only supports 1 hop, (swtich--isl--switch) I'm not sure what you mean by trunking ISLs. It is perfectly okay to have a 6 switch fabric, and run FICON on only 2 of them. The FICON VSANs can only exist on the 2 FICON switches, and FICON devices can only be attached to them. You can not trunk a FICON VSAN from a FICON switch to a non-FICON switch, then onto a FICON switch. All switches in the path must be FICON enabled...and the path is limited to 2 switches.

If possible, you might want to have dedicated ISLs for the FCION traffic. FICON requires in-order-delivery, and a by product of this is that if a frame is dropped on an ISL carrying FICON traffic, the entire ISL is frozen for 1/2 second. SCSI traffic is not hat picky, and can usually survive a drop, but if the SCSI traffic is traversing the same ISL as FICON traffic, it will be impacted by the 1/2 second freeze. Just a design point to consider. There are many ISLs out there carrying both SCSI and FICON traffic.

Hope this helps,

Mike

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4 (2 ratings)
Loading.
Correct Answer
Michael Brown Fri, 11/21/2008 - 13:16

You are correct, you would need the FICON license on both switches where the FICON devices are to be attached. Since FICON only supports 1 hop, (swtich--isl--switch) I'm not sure what you mean by trunking ISLs. It is perfectly okay to have a 6 switch fabric, and run FICON on only 2 of them. The FICON VSANs can only exist on the 2 FICON switches, and FICON devices can only be attached to them. You can not trunk a FICON VSAN from a FICON switch to a non-FICON switch, then onto a FICON switch. All switches in the path must be FICON enabled...and the path is limited to 2 switches.

If possible, you might want to have dedicated ISLs for the FCION traffic. FICON requires in-order-delivery, and a by product of this is that if a frame is dropped on an ISL carrying FICON traffic, the entire ISL is frozen for 1/2 second. SCSI traffic is not hat picky, and can usually survive a drop, but if the SCSI traffic is traversing the same ISL as FICON traffic, it will be impacted by the 1/2 second freeze. Just a design point to consider. There are many ISLs out there carrying both SCSI and FICON traffic.

Hope this helps,

Mike

stephen2615 Sat, 11/22/2008 - 01:04

Mike,

I am considering moving from our McData FICON switches to the MDS'es. I have been trying to convince our Mainframe person that it has to be done sometime in the future but he is resisting it. I did not know about this IOD setting. Is there a decent article on FICON and the MDS that I could read up on and perhaps give to our MF owner..

We had lots of issues with Brocades 48000's and our HDS arrays (at both ends) using native fibre channel for True Copy (sync and async) over about 35 km's. Something would barf in the fabric and we occasionally had horrible timeouts that were normally around the 400 to 500 ms. Brocade (and the IBM cronies) insisted on IOD being turned on. When I started using the MDS switches, we never have experienced any timeouts or at least I haven't seen one yet.

Brocade and HDS both had some very strange ideas on sync and async traffic over distance and I still don't believe that the Brocades VC's are as good as VSAN's.

Stephen

Michael Brown Mon, 11/24/2008 - 09:57

Stephen,

There is a good IBM redbook on FICON and Cisco MDS. http://www.redbooks.ibm.com/redpapers/pdfs/redp4392.pdf is the link. The only time I believe that IOD is required is for FICON only. I think that HP has a replication application and they also are recommending IOD be enabled. The problem is that when it is enabled for a trunking ISL or trunking port-channel, all traffic suffers the 500 millisecond timeout if a drop occurs. This is how IOD ensures that no frames arrive out of order since each FC switch must discard any frame that is held in the switch after 500 milli seconds.

If you do end up migrating ro the MDS from McData be aware that you can re-assign the MDS FICON port number to match the existing port numbers so that the MF guys do not have to regen the IOCDS. That's usually a nice selling point when trying to convince them.

Also be aware that true FICON channel extension is not available in the MDS. That's where a local device will spoof CE and DE (channel and device end). As far as I know, it is not on the roadmap either.

Hope this helps,

Mike

Mike

Actions

This Discussion

 

 

Trending Topics: Storage Networking