Wired Intelligent Edge

 View Only

  • 1.  Redundant VTEPs for L2 VxLAN setup

    Posted Mar 21, 2022 12:34 PM
    This is a simplified diagram of my network:

    network diagramAll three switches can ping each other and there are no firewalls.  Switches Core-01 and Core-02 are 6300M's which both have VLANs 30 and 96 configured and connected between them.  I'm trying to setup switch Edge-01 (which is a 6200F) with VxLAN so that it can have ports on VLAN 30 or 96.  Because of the L3 network in between I can't just extend the VLANs to switch Edge-01.  Here's my current configuration:

    Core-01:
    vlan 30,96
interface vxlan 1
   source ip 10.1.0.1
   no shutdown
   vni 30
      vlan 30
      vtep-peer 10.3.0.1
   vni 96
      vlan 96
      vtep-peer 10.3.0.1​
interface 1/1/28
   no routing
   no shutdown
   vlan trunk native 1
   vlan trunk allowed 30,96

    Core-02:

    vlan 30,96
interface vxlan 1
   source ip 10.2.0.1
   no shutdown
   vni 30
      vlan 30
      vtep-peer 10.3.0.1
   vni 96
      vlan 96
      vtep-peer 10.3.0.1​​
interface 1/1/28
   no routing
   no shutdown
   vlan trunk native 1
   vlan trunk allowed 30,96
    Edge-01:
    vlan 30,96
interface vxlan 1
   source ip 10.3.0.1
   no shutdown
   vni 30
      vlan 30
      vtep-peer 10.1.0.1
   vni 96
      vlan 96
      vtep-peer 10.1.0.1
interface 1/1/47
   no shutdown
   no routing
   vlan access 30
interface 1/1/48
   no shutdown 
   no routing
   vlan acces 96​
    Everything works.  On Edge-01 I can even change the vtep-peers to be 10.2.0.1 to connect to Core-02 instead of Core-01.  What I want to be able to do is connect to BOTH so that I have a redundant connection.  As soon as I change the configuration on Edge-01 to connect to both cores the clients connected to 1/1/47 and 1/1/48 on Edge-01 start getting excessive packet loss.  How do I get redundant vtep-peers in a situation like this?

    Edge-01 (with redundant vtep-peers):

    vlan 30,96
interface vxlan 1
   source ip 10.3.0.1
   no shutdown
   vni 30
      vlan 30
      vtep-peer 10.1.0.1
      vtep-peer 10.2.0.1
   vni 96
      vlan 96
      vtep-peer 10.1.0.1
      vtep-peer 10.2.0.1
interface 1/1/47
   no shutdown
   no routing
   vlan access 30
interface 1/1/48
   no shutdown 
   no routing
   vlan acces 96​​


    ------------------------------
    David King
    ------------------------------


  • 2.  RE: Redundant VTEPs for L2 VxLAN setup

    Posted Mar 22, 2022 05:26 AM
    Edited by vincent.giles Mar 22, 2022 06:09 AM
    Static VXLAN tunnels are simple/easy deployment but comes with associated limitations.
    Here, it seems to me that the dual remote VTEP set-up that you tried, simply created a L2 loop, as VLANs are trunked between core01 and core02.
    Native split-horizon rule on VXLAN is performed between VXLAN tunnels ending on same switch. When broadcast arrives on core01 from VXLAN sourced by edge01, this broadcast is forwarded to regular trunked ports, to core02. Core02 forward this back to edge01, as there is no way this packet can be identified as coming from edge01.

    1) The redundancy can be set-up by merging core01 and core02 into a single VSF stack.
    2) spanning-tree over VXLAN is not supported.
    3) You may think about other alternative like using an anycast IP from core01 and core02 for VXLAN interface, that anycast IP being advertised to edge01 with different cost (like OSPF cost), so that you may have a active core01 VTEP and a standby core02 VTEP. This anycast IP being the one used on edge01 as unique remote VTEP IP. But it does not prevent L2 loop from core02 to edge01.

    VSF VTEP or VSX VTEP are, for time being, the only redundancy options we can propose.
    For roadmap please contact your local Aruba contact.

    ------------------------------
    Vincent Giles
    ------------------------------

    Original Message


  • 3.  RE: Redundant VTEPs for L2 VxLAN setup

    Posted Mar 22, 2022 08:04 AM
    Thanks, Vincent.  That all makes sense.  Merging the two cores into a single VSF stack doesn't meet the uptime requirements for them and VSX isn't supported on the 6300's so those options won't work in this situation.  The idea about using anycast is interesting but we don't have IPv6 rolled out enough to make that work.  Would it work to use VRRP instead of anycast for the VTEP on the core side?

    The other option I had thought about was removing the vlans in question from the direct connection between core-01 and core-02 and using VxLAN for that connectivity as well.  That would form a VxLAN loop but the native split-horizon should take care that, right?  It seems silly to use VxLAN between two switches which are directly connected but, in this situation, would that solve my problem?  If VRRP works that would be my preferred solution, I was just trying to think through all the options.

    Thanks!

    ------------------------------
    David King
    ------------------------------

    Original Message


  • 4.  RE: Redundant VTEPs for L2 VxLAN setup

    Posted Mar 23, 2022 04:21 AM
    Indeed, what you suggested makes sense, and the native split-horizon rule will protect against L2 loop.
    However, I don't know the consequences on your downstream design below core01 and core02. If there is no switch with spanning-tree below, then it might be a good option for time being.

    ------------------------------
    Vincent Giles
    ------------------------------

    Original Message


Related Content