Wired Intelligent Edge

 View Only
  • 1.  VSX Expected Behavior with MCLAG

    Posted Jun 12, 2023 10:22 AM

    Hello All,

    I'm seeing, what I believe to be an odd behavior, but wanted to see if anyone could help explain. We have a pair of 8325s in a VSX Pair. Port 1/1/7 on each member is part of a multi-chassis lag (lag7)

    When both links are up, everything works as you would expect. The weirdness I am seeing, is if I administratively shut one of the ports. (For example, if I shut 1/1/7 on the VSX Primary, but leave 1/1/7 on the secondary online and available), I still see MAC-Address learnt on the port

    What I see, is the VSX Primary is still showing MAC-Addresses on LAG7.

    That seems strange to me because the physical link is down, I would have expected it to show all the MAC-Address to then come from the ISL?. This issue still occurs even if I physically disconnect the module/fiber.

    I do have a case open for this and am going to test in our lab, but just curious if this is an expected behavior.

    Thanks all,
    Chris



    ------------------------------
    Chris Wickline | ACCA |
    ------------------------------


  • 2.  RE: VSX Expected Behavior with MCLAG

    Posted Jun 12, 2023 11:57 AM
    AOS-CX release?





  • 3.  RE: VSX Expected Behavior with MCLAG

    Posted Jun 12, 2023 04:15 PM

    We are on version 10.10.1060




    ------------------------------
    Chris Wickline | ACCA |
    ------------------------------



  • 4.  RE: VSX Expected Behavior with MCLAG
    Best Answer

    Posted Jun 13, 2023 03:15 AM

    I would see this behaviour as normal.

    If you consider a single switch with a two member LACP link. If you shut one physical member of the LAG then you still see the MAC addresses. This is because that switch can still pass traffic. In VSX, the primary in your example holds the MAC table and I would hope would be able to pass traffic via the VSX inter-link and down the secondary LACP link.

    If that isn't the case (VSX isn't quite that good) then at the very least the MAC table would take less time to populate when the primary link is returned to service.

    I don't know the command but if you could get the forwarding table from the primary I would expect it to say: MAC aaaa.bbbb.cccc via  ISL-link or similar.




  • 5.  RE: VSX Expected Behavior with MCLAG

    Posted Jun 13, 2023 05:40 AM

    In https://www.arubanetworks.com/techdocs/AOS-CX/10.10/PDF/vsx.pdf

    you find:

    VSX has similar benefits as Virtual Switching Framework (VSF), however, VSX also offers better high
    availability required in core and data center environments. VSX binds two AOS-CX switches of the same
    model type to operate as one device for layer 2. VSX also operates as independent nodes for layer 3.

    show mac-address-table 

    and

    show mac-address-table vsx-peer

    should show the same table if they are in sync.



    ------------------------------
    Arne Opdal
    ------------------------------



  • 6.  RE: VSX Expected Behavior with MCLAG

    Posted Jun 19, 2023 07:25 AM

    Thanks Everyone,

    I wish there was a diagnostic tool to view the forwarding table (looks like maybe 10.11 has that?) regardless, I confirmed on a few different VSX setups we have this is intended behavior.

    Was seeing some strange issues downstream and wanted to verify.

    Thanks again, everyone



    ------------------------------
    Chris Wickline | ACCA |
    ------------------------------



  • 7.  RE: VSX Expected Behavior with MCLAG

    Posted Jun 20, 2023 03:57 AM

    From a VSX cluster point of view, the egress interface is still LAG7. Then, as a second stage you consider which physical ports are up or doan on this VSX LAG, as if it was a regular LAG on a single node.

    On 8335 you can use show forwarding-info 

    example: show forwarding-info mac ingress-interface 1/1/17 source-mac-address <mac>