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

[Jonathan Call]

Interesting. The two important devices of the three are qfx5100-24q. The majority of traffic flows will go through them.  The third is a qfx5100-48t which will have more endpoint destinations (i.e. servers, out-of-band equipment) Since the qfx5100 series are single RE/FPC there shouldn't be a scenario where one 24q would see a better topology to the other 24q by going through the 48t. The extra bandwidth would be set up between the two 24q.


Jonathan

________________________________
From: Chris Kawchuk <juniperdude at gmail.com>
Sent: Thursday, October 26, 2017 3:16 PM
To: Jonathan Call; juniper-nsp at puck.nether.net
Subject: Re: [j-nsp] Unequal bandwidth on virtual chassis ports?

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
juniper-nsp Info Page - puck.nether.net<https://puck.nether.net/mailman/listinfo/juniper-nsp>
puck.nether.net
To see the collection of prior postings to the list, visit the juniper-nsp Archives. Using juniper-nsp: To post a message to all the list members ...