In the Brocade Virtual Symposium hosted by Packet Pushers and Tech Field Day, Part 3: Multi-Path vs. Multi-Chassis shows us an interesting case of using ECMP and VCS with different size ISL links. Ivan Pepelnjak asks a question. If Brocade is using ECMP as dictated by TRILL, will there be underutilised bandwidth as each of the links have the same cost? I feel the answer was not made clear, so I want to explain it more fully.
Let’s take the simplest example of this – just two switches in a VCS fabric, with two ports groups per switches in use for ISLs.
We can see that we have two ISLs, and ECMP defined cost is based on speed and not bandwidth. Both ISL’s are a cost of 500. At this point as far as TRILL/IS-IS standards are concerned, we are done. We have two paths, and we can do flow-based load balancing via hashes across these two paths. What Brocade has done beyond this is to add frame-based load balancing across ISL Link 1 – not flow based. This was covered well in the Brocade Virtual Symposium.
Now the point I want to make (and to answer Ivan’s question – more fully I hope), really is this: since Brocade is using FSPF for both FCoE and TRILL, that ALSO takes into account the bandwidth of the ISLs. This means in the above example that on a flow-based load balancing, Brocade will take the total bandwidth of both ISL’s – 40G in this case – and balance the flows in a 3:1 ratio. Say 8 flows come in. ISL 1 will handle (and then frame-based load balance) 6 flows, while ISL 2 will take the remaining 2 flows.
I would also like to say that these features have been in VDX products since they were launched. So, this is not new anymore and came from the FC side a long time before that.
What happens when vendor interoperability of TRILL arrives? My guess is that Brocade will continue to do load balancing their own way for their own equipment (as this offers a much better use of the links), but will offer a standards-based TRILL port running IS-IS to create non Brocade ISLs.