Wired Intelligent Edge

Hello all,

How to check if VSX LAG traffic, in case one side of the VSX LAG is entirely down on a VSX peer, is correctly automatically redirected through the VSX ISL (VSX ISL LAG)?

Then I've another question: when VSX is synchronized (so VSX in running normally), Keepalive is OK and peers are reacheable each others, VSX LAGs are up and running on both VSX peers...is there a way to quantify how much traffic can flow through VSX ISL LAG in the East-West direction (so not only locally South-South or South-Nord between VSX LAGs belonging to the same peer) especially if data is expected to be distributed on all downstream (or upstream) links from/to various VSX LAGs destinations?

I ask the question above to understand if all links of a VSX LAG (say 2 on Primary and 2 on the Secondary) can be involved concurrently in managing traffic (so involving also VSX ISL) with destination (or source) on another similar VSX LAG...or we should expect that no traffic will preferentially traverse the VSX ISL LAG and so the VSX LAGs are only partially used?

Hi Parnassus

I will start by explaining the "normal" behavior (you 2nd and 3rd paragraphs) for north>south unicasts. 

A unicast packet arrives at one switch on its way to a client (let's say to the "left" VSX member). The LAG traffic distribution algorithm will only select ports on that switch ("left"), we call this Local-first, to forward the packet. So, in normal conditions no unicast traffic (except for control traffic) should traverse the ISL.

In the future this will apply also to multicast. Today, all multicast is forwarded by a single port on the VSX LAG.

So, only multicast should traverse the ISL (plus VSX control traffic: hellos, synch, etc.). Unless you have other devices connected to only one of the VSX members.

As for your first paragraph, the basic would be to test connectivity using the traditional methods: ping and traceroute. But let me analyse it a bit more and get you the answer.

Regards, Ruben Iglesias.-

Hello Ruben! nice to hear you...and thanks for answering.

OK for North-South unicast (and multicast) traffic flow. Thanks for clarifying that.

My doubts are more related to the case South-South (in our VSX scenario we haven't any North-South traffic path since our VSX deployment is totally isolated and used only for Layer 2 connectivity through a lot of VSX LAGs connecting various Servers/Storages....up to VSX LAG having a grandtotal maximum of 4+4 10Gbps links on entire VSX): from what I've understood each member link on each VSX LAG side (one VSX LAG has legs on VSX Primary peer and legs on the VSX Secondary peer) should be involved in traffic forwarding...clearly traffic forwarding will happen accordingly to LACP hashing results calculated on the source side (downstream hosts/switches see "just" an uplink switch so their sole contribution is to decide which LAG legs to use to send traffic)...so it will be interesting to understand which path the originating data (say a Server) is going to use "inside the VSX" to reach its final destination (say a Storage)...will there be corner cases in which the VSX ISL "fat pipe" will be used or the logic underlying the VSX LAG functionality (once the traffic arrives into and is managed by each VSX Peer) will prevent that by letting the data to flow only locally between VSX LAGs' legs belonging to the same VSX peer?

I think that's the question I've in mind...and I hope it is not silly (it's late night here!).