Why OTV and not Fabricpath for DCI,

Cisco has been fast at implementing the near-TRILL standard calling it Fabricpath which is an easy and simple way of using all of the available links. It is more of a LAN cloud, where all available links are made available & the forwarding of the frame is based on switch-id. ISIS is the protocol used to calculate the shortest path to the switch that has the efficient link to deliver the packet to the destination switch where the destination mac address is connected to.

Now lets remember to enable fabricpath you need a license which is very expensive. If you want to run OTV again you need a license. Clients often ask me why not we use the fabricpath for the interconnect also.

Now lets understand mac forwarding topology is built using fabricpath. while it might be very efficient to use within a datacenter it is not advisable to use across the DC. Here's why;

• If there is any flooding in one datacenter it is carried to the other datacenter also which is completely not desirable, needless to say if there are multiple datacenter interconected you have one hell of a problem. OTV has the upper hand as it localizes all this to a single datacenter.
• Both datacenter need to run fabricpath & all vlans needs to be configured, because it becomes one single topology. when we use OTV we only extend the required vlans and not all vlans
• Gateways cannot be local on the datacenter and there will be a single forwaring HSRP gateway for both datacenter making it inefficient in every way & the DCI link will forwarding traffic full fledged.
• The arp optimization that OTV delivers cannot be leveraged when using the fabric path

Taking into consideration the above mentioned important factors we definetly cant use fabricpath as a DCI solution. OTV is the way to go. So the use of fabricpath and OTV protocol, in their diversities, advantages and disadvantages have to be clearly understood before we design the DC