Wired Intelligent Edge

last person joined: 18 hours ago 

Bring performance and reliability to your network with the Aruba Core, Aggregation, and Access layer switches. Discuss the latest features and functionality of the ArubaOS-Switch and ArubaOS-CX devices, and find ways to improve security across your network to bring together a mobile first solution.
Expand all | Collapse all

ArubaOS-CX: access/trunk interface configuration common/good practices

This thread has been viewed 62 times
  • 1.  ArubaOS-CX: access/trunk interface configuration common/good practices

    MVP GURU
    Posted Feb 17, 2020 10:06 AM

    Hi all!

     

    Wondering if we can briefly validate/discuss about ArubaOS-CX's configuration good practices when an interface is going to be used as access (used to connect an host, as example) or as trunk (used to connect a peer 3rd party switch, as example).

     

    From what I was able to understand an interface 1/1/<n> (or a Layer 2 VSX-LAG or Standard-LAG) connected to an edge Host would probably have a configuration similar to this one:

     

    interface 1/1/<n>
    no shutdown
    mtu 9198
    description "Link-to-Edge-Host"
    no routing
    vlan access <vlan-id>
    loop-protect
    spanning-tree bpdu-guard [1]
    spanning-tree port-type admin-edge [2]
    spanning-tree tcn-guard [3]
    exit

     

    [1] the spanning-tree bpdu-guard enables the BPDU guard on the switch interface. When BPDU guard is enabled, interfaces receiving MSTP BPDUs remain disabled.

     

    [2] the spanning-tree port-type admin-edge specifies the port type as administrative edge. During spanning tree establishment, ports with admin-edge enabled transition immediately to the forwarding state.

     

    [3] the spanning-tree tcn-guard disables propagation of topology change notifications (TCNs) to other STP ports. Use this when you do not want topology changes to be noticed by peer devices.

     

    The same interface configured in trunk mode (used to connect a peer 3rd party switch, as example) would be probably configure as:

     

    interface 1/1/<n>
    no shutdown
    no routing
    mtu 9198
    flow-control rx
    !actual flow-control none
    description "Link-to-Remote-Switch"
    vlan trunk native <vlan-id> tag [4]
    vlan trunk allowed <vlan-id> [5]
    spanning-tree link-type point-to-point [6]
    spanning-tree ignore-pvid-inconsistency enable [7]
    exit

     

    [4] the vlan trunk native <vlan-id> tag enables tagging on native VLAN id <vlan-id>.

     

    [5] the vlan trunk allowed <vlan-id> is used to specify exactly and only VLAN id <vland-id> as permitted. Eventually vlan trunk allowed all will allow instead all possible VLAN ids.

     

    [6] the spanning-tree link-type point-to-point sets the spanning tree link type as point-to-point. Use this for full-duplex ports that provide a point-to-point link to devices such as a switch, bridge, or end-node. That's default.

     

    [7] the spanning-tree ignore-pvid-inconsistency enable shouldn't be necessary if other end's port permits tagged only traffic (no untagged traffic will flow).

     

    Clearly spanning-tree relevant configuration (and loop protect too) depend on other parameters set globally (e.g. spanning-tree needs to be enabled or, as examples, the loop-protect action tx-rx-disable - which is default - and loop-protect re-enable-timer 3600 or the like).

     

    I've some doubts with regard to the best approach to follow in configuring an interface in trunk mode (access looks quite simple) from the VLAN tagging standpoint...I mean if a standalone/VSX ArubaOS-CX switch needs to be connected to a 3rd party switch using Layer 2, will:

     

    vlan trunk native <vlan-id> tag
    vlan trunk allowed <vlan-id>

     

    simply require that the other end peer interface is configured to be a tagged member of VLAN id <vlan-id> (to use a ProCurve jargon) only to work?

     

    Or - instead - will be better (or more common, less unusual) to avoid requesting that Native VLAN as tagged and also allow all VLAN ids on the trunk instead of exactly specifying one ore more VLAN ids?

     

    As example:

     

    vlan trunk native <vlan-id>
    vlan trunk allowed all

     

    I feel silly to ask those questions but experts opinions would be great to hear.



  • 2.  RE: ArubaOS-CX: access/trunk interface configuration common/good practices

    MVP GURU
    Posted Feb 17, 2020 10:34 AM

    Hi,

     

    There is no good or bad pratices about native tag vlan... only some preference...



  • 3.  RE: ArubaOS-CX: access/trunk interface configuration common/good practices

    MVP GURU
    Posted Feb 17, 2020 10:51 AM

    Yes, I know that Alexis!

     

    Mine was an attempt to have a working (and non limiting) configuration considering I'm in a position I can set the rules to my peering switches (so, you know, preferring tagged traffic only over a trunk mode interface and no untagged traffic is, as you correctly wrote, just a matter of taste but, in my view, it's also a way to ensure I can add and allow more VLAN ids - all tagged - on that very trunk in future).



  • 4.  RE: ArubaOS-CX: access/trunk interface configuration common/good practices

    MVP GURU
    Posted Feb 17, 2020 01:02 PM

    i prefer to kept vlan 1 by default on trunk (and no tag..)

     

    it is always specific stuff for native tagged vlan on differents switch