Switching

Hi All,

Just to start a conversation, I would like to know how clear the difference between traditional stacking  and VC technology is for everybody in the field (partners/ end-users) ?

/Ralph

Hi Ralph,

No offence, but for me we are talking about marketing terminology here. 

Don't see any reason why a VC is not a stack.

KR,

 Thomas

Hi Thomas,

Good to hear from you.

In terms why a VC differs from a stack, I would say the following: it has more high-availability capabilities (think of GRES / NSR / ISSU) then a regular stack can ever have from a architectural point of view. Another thing is the deployment advantages a vc has over a stack. Think of extension over distance, inserting new members just somewhere in the VC and ISIS will find out the "shortest path" to reach other members, ease of replacing damaged members by new ones, single config accross the entire VC.

/Ralph

This is negated, somewhat, but the fact that best practice is to preprovision switches in a VC.  We normally want to ensure which switches are primary and backup routing engines in a VC.

I like to think that there are both data plane and control plane differences between most stacking implementations and Juniper's Virtual Chassis:

From a data plane perspective, each VC ingress port can directly address any VC destination port regardless of member location, and all features apply VC-wide (including features such as link aggregation).  This is how traditional chassis operate, and is much different than simply stitching multiple boxes together in a ring.

From a control plane perspective, the traditional JUNOS master/backup routing engine architecture is preserved, and all members have a consistent view of the forwarding database.  This provides a substantial improvement in management and availability.

Finally, the internal data flow uses a shortest-path, cost-aware and multicast-aware protocol, ensuring optimal use of the VC backplane resources and allowing multipath and extended reach topologies, allowing customers new degress of flexibility in network architecture, resulting in substantial capital and operational expense reduction...

Regards, Dave