[j-nsp] Unequal bandwidth on virtual chassis ports?

[Chris Kawchuk]

As VC uses IS-IS as it's underlying protocol (last time I checked), I believe there is a metric associated with each VC link. show virtual-chassis adjacency/database/etc.. should show those metics.

VC IS-IS will calculate the lowest-metric to the far-end PFE, and use that. I also recall that it counts packet-forwarding-engines inside the switch itself, and not switches per se as a hop/link count. For example, an EX4200 has 3 x PFEs inside the box, and depending on where/how you connect the back-side VC cables or front-side revenue ports as VC will affect how it sees the topology.

VC will not load balance across unequal-costs (a-la RSVP-TE or something), and doesn't use multiple paths (even if they're ECMP) to the destination either last time I played with it; but it's been a while ;)

VCF will do the ECMP-trick, BTW.

- CK.


On 27 Oct 2017, at 8:05 am, Jonathan Call <lordsith49 at hotmail.com> wrote:

> Typically when I build virtual chassis I set up the recommended "ring" topology and give path an equal amount of bandwidth. Would there be any technical problems if I give one of the virtual chassis links more bandwidth than the others?
> 
> 
> The Virtual Chassis Feature Guide for the QFX Series doesn't suggest there is anything wrong with this, but it doesn't really discuss the scenario either.
> 
> 
> 
> Jonathan
> 
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp