When I (somewhat jokingly) wrote about the dense- and sparse-mode FCoE, I had no idea someone would try to extend the analogy to all possible FCoE topologies like Tony Bourke did. Anyhow, now that the cat is out of the bag, let’s state the obvious: enumerating all possible FCoE topologies is like trying to list all possible combinations of NAT, IP routing over at least two L2 technologies, and bridging; while it can be done, the best one can reasonably hope for is a list of supported topologies from various vendors.
Does it process the FCoE frame based on FC addresses?
No – it’s not really an FCoE device, it’s a fancy Ethernet bridge. The very minimum the bridge must support is ETS (802.1Qaz) and PFC (802.1Qbb) with QCN being optional (unless you want to deploy sparse-mode FCoE with plenty of devices between FCoE nodes).
If the device supports FIP snooping (like Cisco’s Nexus 4000 or Juniper’s QFX3500), it’s marginally more useful and can provide some additional security in sparse-mode FCoE environments (where FCoE nodes are separated by DCB-capable bridges).
Yes – it might actually be an FCoE-capable device. Let’s dig further.
When in doubt check the device documentation (starting with the configuration guides). If it doesn’t tell you how to configure VSANs, NPIV or FSPF, I would remain dubious.
Can it connect to a host CNA through a DCB-capable bridge (not that this would be a good idea)?
No – Too bad. Your connectivity options might be limited.
Yes – Sounds great, but be careful. Check whether you can group the ENodes into VLANs/VSANs based on their MAC addresses (you can do that on Nexus 5000, but not on QFX3500). Without this functionality, you’ll have hard time implementing SAN-A/SAN-B separation when the hosts are not directly connected to the FCoE switches.
In both cases, proceed to the next question.
Does it run FSPF?
No – it’s not really an FCF (FCoE Forwarder), but a gateway running NPIV (in IP lingo: a NAT device with static default route), like Juniper’s QFX3500 or Cisco’s Nexus switches in NPV mode (HP’s Virtual Connect seems to be in this category as well).
It’s also worth asking what the uplink options are. Cisco’s switches (excluding Nexus 6100 for the moment, see comments) support FCoE uplinks, Juniper and HP require FC uplinks.
Yes – congratulations. It’s actually an FC router supporting FCoE. Now let’s get into connectivity details. Oh, and it might be a good idea to check whether NPIV is supported as it just might come handy (it’s not on Brocade’s VDX switches).
Can it connect to another FCF over FCoE (can it create VE_ports)?
No – Too bad. No multihop FCoE today, but it might still be a good option if you want to connect servers with 10GE CNA to existing FC SAN.
Yes – Sounds great. You might have stumbled across a full-blown FCoE FCF. To my knowledge, Cisco’s Nexus family and Brocade’s VDX switches (VCS fabric) are the only two in this category.
Does the packet forwarding follow VE_port-based links and FSPF topology information?
Yes – seems like the FCF you’re looking at follows FC-BB-5 pretty closely.
No – Weird. This is not how FC-BB-5 is written (but it’s how Brocade’s VCS fabric works).
Anyway, this was just a trick question to annoy a few people out there. Let’s move on.
Can you insert DCB-capable bridges between two FCFs (VE_ports running across bridged Ethernet)?
No – No sparse-mode multihop FCoE for you today. Whether that matters is a good topic for another discussion.
Yes – You’ve found a truly versatile FCoE device that supports both sparse-mode and dense-mode multihop FCoE. Unless I’m mistaken, it’s still as common as unicorn tears.
Disclaimer: the examples sprinkled throughout the post are based on my understanding of the functionality of devices that are actually shipping as of late August 2011. Your corrections are most welcome.
2011-08-30 16:45 GMT - fixed Nexus 6100 FCoE uplink information. Thank you, J Metz!.