Hello all,
Reading the old Aruba 8320 Link Aggregation Guide for ArubaOS-CX 10.00 (Edition 1 of March_2018 or Edition 2 of April 2018) now superseded by the newer ArubaOS-CX Virtual Switching eXtension Guide for ArubaOS-CX 10.01 (Edition 1 of July 2018) I noticed that ISL troubleshooting on VSX, compared to ISL troublehooting on MCLAG, doesn't list the case of "Traffic redirect failure" (described as "When one side of the MCLAG is down, traffic is redirected through the ISL. Sometimes the redirection does not
occur." on older Aruba 8320 Link Aggregation Guide for ArubaOS-CX 10.00 guides).
So my question: considering current ArubaOS-CX VSX implementation (say ArubaOS-CX 10.01.0020 to stay on the very latest) is "Traffic redirect failure" an event that is not going to happen anymore?
If I actually check both VSX nodes (Primary and Secondary), I respectively find this:
Aruba-8320-1:/home$ sudo ovs-appctl vsx/show_global
ISL bundle configuration:
Bundle name: lag128
MAC learning: Disabled
Flood block: Disabled
Redirect traffic to: None
Egress blocked VSXs: lag1
lag2
lag3
lag4
lag5
lag6
lag7
lag8
lag9
lag10
lag11
lag12
lag13
If the Traffic Redirect failure is still a possible event also on VSX implementation, shouldn't I find something different than None/Disabled outputs for options like MAC learning, redirect traffic's destination and flood block state on each node (at least on the node owning the Secondary role) OR the redirect (through ISL) traffic's logic in case of VSX-LAG fault on one side changed substantially between MCLAG and VSX implementations and those options are not more relevant when dealing with VSX?
Clearly the output of actual ovs-appctl vsx/show_global shell command can't be equal to the one of (superseded) ovs-appctl -t hpe-mclagd mclag_filter_dump shell command but I saw some similarities so I asked.