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:
vlan access <vlan-id>
spanning-tree bpdu-guard 
spanning-tree port-type admin-edge 
spanning-tree tcn-guard 
 the spanning-tree bpdu-guard enables the BPDU guard on the switch interface. When BPDU guard is enabled, interfaces receiving MSTP BPDUs remain disabled.
 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.
 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:
!actual flow-control none
vlan trunk native <vlan-id> tag 
vlan trunk allowed <vlan-id> 
spanning-tree link-type point-to-point 
spanning-tree ignore-pvid-inconsistency enable 
 the vlan trunk native <vlan-id> tag enables tagging on native VLAN id <vlan-id>.
 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.
 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.
 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?
vlan trunk native <vlan-id>
vlan trunk allowed all
I feel silly to ask those questions but experts opinions would be great to hear.
There is no good or bad pratices about native tag vlan... only some preference...
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).
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
At Aruba, we believe that the most dynamic customer experiences happen at the Edge. Our mission is to deliver innovative solutions that harness data at the Edge to drive powerful business outcomes.
© Copyright 2021 Hewlett Packard Enterprise Development LPAll Rights Reserved.