VPC modified the native behaviour both on layer 2 and layer 3 aspects. The configurations guide and best practice guide are beyond hundred of pages.
There are so many network incidents are posted for incorrectly implemented VPC configurations. If a technology is so hard to implement correctly and prone to human error, do you think the technology can last long?
Also, there are so much gochas and different scenarios, lots of limitations such as routing, multicast and MPLS. Lots of protocols need to be specifically considered for VPC.
My concern is that VPC does not work natively and seamlessly with other protocols. Lots of protocol, such as muticast, implementations need to be modified to work in a VPC environment. How about new protocols?
My question to the forum are:
1. Do you think VPC is too complex to accomplish a layer 2 virtualization?
2. Do you think VPC can last long or be replaced by other technologies soon?
I'm coming out of the closest. I don't like Nexus, VPCs and their related technologies and problems.
I'm sticking with the Catalyst family.
Thank you Philip for the opinion.
In theory, VPC should be better than VSS since it has independent control plane. But I saw so many posts about the big incidents caused around VPC. Some are caused by not properly configuring the VPC. As a dual CCIE, I personally think VPC is really complex, it has at least 30 more scenarios to consider and it is easier for the users to be trapped in one of the not working situations! And it is not open standard, so the behaviour of VPC may change from time to time.
I am still with VPC and Nexus for Data Centre deployment. But just feel the VPC adds more complexity and limitations in spanning tree design, multicast, MPLS, dynamic routing, and also the layer 2 interconnect.
I anticipated that Cisco will eventually replace SCCP with SIP for IP phones. I am thinking, with the way how VPC works (which isn't naturally work with other protocols), will someday Cisco just abandons VPC?
It depends on your use case but I have used double-sided vPC successfuly for several years and found no problems when making changes. It has also proved to be robust in the face of power failures when one or more of the switches in the vPC domains have failed.
VSS has it's own challenges and it is not an open standard either.
For the Nexus familiy one alternative to vPC is FabricPath but this is more expensive to implement since you need to purchase an additional license. Furthermore it may not be economically justified for a small DC deployment.
While both VSS and vPC are proprietary, you don't read about people getting into trouble all the time using VSS .... it just works - as expected.
It depends on how big your VSS deployment is and what version code you are running.
I worked on a large VSS network and on occasion the switches would on spike to up 100% CPU. We also experienced etherchannel problems with downstream switches.
Thanks Sean and Philip for the comments.
Thanks for the comment. I did hear VSS issue (large deployment in university, CPU overloaded) in person. I am not anti-proprietary. Lot's of good innovations started from proprietary.
VSS is a virtualization of both layer 2 and layer 3. It is transparent for the network design. A pair of VSS switches are shown as a single switch to the outside world. Their is no special, or very few, configuration consideration, are required for dynamic routing, spanning tree, multicast, MPLS.
In contrast, lots of rules need to be followed and configuration adjustments are required to make VPC working with multiple technologies in a unnatural way.
I am not saying VSS is better, I am just thinking VPC isn't naturally fitting with standard protocols. And the tweaks required are too much.
Also, based on how it fundamentally works, it may need to be tweaked with other new technologies. That means stability and compatibility challenges. I think the amount of caveats related to VPC shows how complex it is even for the development team.
I think it needs to be accepted that VPC is the current 'traditional' DC design for Nexus platform. I am just not very impressed by it.