I set up my VSX Pais as described in the Best Practices Guides.
But after reviewing the config (regarding to problems) I see, that the native vlan 1 is not being tagged about the ISL links.Is that or could that be a problem?Or is it a valid design not to use vlan 1 as native VLAN?vlan 1 is our main vlan (with a mixture of client and servers). That was a historical design decision flat network long before i started to work in that company...Migrating was planned a long time ago but it was never getting started. Of course it is a pain (firewall rules, VPN connections, depencies because of static IP addressing instead of DNS...).My problem is the following:I do have several pairs of Aruba CX Switches as new network equipment.It is connected to the old network equipment.Ping to dst network 192.168.22.0/24 from a vlan 1 src on side A (RZ, VSX csw-rz-r08 and csw-rz-r09) and the other VSX pairs on side A are okay = ~240 hostsPing to dst network 192.168.22.0/24 from a vlan 1 src on side B (BU, VSX csw-bu-r02 and csw-bu-r03) and the other VSX pairs on side B are NOT okay = ~30 hosts
Using a src host in another vlan than 1 on side B, then the ping to dst network 192.168.22.0/24 is okay = ~240 hosts.Or if we change the testing variables, the result is the same.Bringing the Firewall on side B active and using a host in vlan 1 on side A pinging dst network 192.168.22.0/24 (network is a VPN Network behind the firewall) results to ~30 hosts instead of the expected ~240 hosts.The problem can be solved immediately with switching back to the firewall on side A.The problem is reproducible. We do also have some kind of performance and connection issues when the traffic traverses side A to side B and back. But this is very difficult to measure and showing....Traffic Debug/Capture on the VPN gateway and on the Firewall show the returning traffic on the outgoing interface.What we also did for troubleshooting:- isolating the links between csw and firewall (shutting down the physical port on the primaryVSX Member, reenabling and then shutting down the physical port on the secondary VSX member)- isolating the links between side A and side B (shutting down 3 of 4 links, repeated for testing every single link as standalone)- isolating the links between VSX pair csw-bu on side B (shutting down 1 of 2 links, repeated for testing every single link as standalone)- shutdown the members of the VSX pair csw-bu (at first the secondary, then reenabling, then the primary)Nevertheless, the result was everytime the same... As mentioned about the results of an network scan shows only a few of the expected hosts.
Graphical example:Left side: Ping result src side B vlan 2000Right side: Ping result src side B vlan 1
My next step will be to change the CST Root Bridge from old "Core 3" to new VSX Pair csw-rz.But I don't think, that this can be the problem, because checked the topology and vlan configuration on all interfaces.And think of that some Hosts are reachable and some not, should not be a STP problem. But also could not be a LAG/LACP Problem because I have isolated/tested every single link :-(
relevant configuration:I already changed the native vlan on all uplinks (between Aruba-CX devices) other than the ISL Links to an unused dedicated native vlan 998.For Connecting to Aruba OS Switches the vlan 1 has been maintained because of native vlan mismatch errors.
I did not adjust the native VLAN on the ISL, because I don't know if it is valid. And i did not change it to tagged manually to avoid interrupting services
VSX pair side A (Room RZ):csw-rz-r08# sh run int lag53interface lag 53 multi-chassisno shutdowndescription csw-buno routingvlan trunk native 998vlan trunk allowed alllacp mode activeexitcsw-rz-r08# sh run int lag256interface lag 256no shutdowndescription ISL linkno routingvlan trunk native 1vlan trunk allowed alllacp mode activeexit----csw-rz-r09# sh run int lag53interface lag 53 multi-chassisno shutdowndescription csw-buno routingvlan trunk native 998vlan trunk allowed alllacp mode activeexitcsw-rz-r09# sh run int lag256interface lag 256no shutdowndescription ISL linkno routingvlan trunk native 1vlan trunk allowed alllacp mode activeexit--------------------------------VSX pair side B (Room BU):interface lag 53 multi-chassisno shutdowndescription csw-rzno routingvlan trunk native 998vlan trunk allowed alllacp mode activeexitcsw-bu-r02# sh run int lag 256interface lag 256no shutdowndescription ISL linkno routingvlan trunk native 1vlan trunk allowed alllacp mode activeexit---csw-bu-r03# sh run int lag 53interface lag 53 multi-chassisno shutdowndescription csw-rzno routingvlan trunk native 998vlan trunk allowed alllacp mode activeexitcsw-bu-r03# sh run int lag 256interface lag 256no shutdowndescription ISL linkno routingvlan trunk native 1vlan trunk allowed alllacp mode activeexitcsw-bu-r03#--------------------------------
Hi Davide,"FAIK in a default VSX configuration the VSX ISL logical interface (lag x) the VLAN id 1 is set native tagged, this despite that VLAN id is then used or not."That with the ISL Link is curious. The VSX Guide tells that the native option will be set automatically, when using a interface for ISL. But that obviously did not happen on my VSX pair..."It's absolutely a best practice not to use the Default VLAN id 1 (AKA avoiding it as much as possible)."That is the very general best practice, but I did not find anything about best practice native vlan for ISL Link.Before changing the native vlan on my production aruba-cx switches I want to verify that an other native vlan id than 1 is valid.As I have written in the post before, we do experience performance and connectivity troubles, I do not want to increase that problems...
thanks and kind regardsRobert
Hi together,I changed the native vlan on all VSL Links from vlan 1 untagged to vlan 998 tagged, as I have done it at all other Uplink Ports, too (except to old network infrastructure).Also I have adjusted the Spanning Tree, so that the VSX Cluster csw-rz-r08/csw-rz-r09 is the spanning-tree root for all the MSTP Regions. Topology is stable since the configuration, but the problem with vlan 1 still exist. Problems from side B to reach all host for example in one remote VPN network.I do not have any case at aruba tac, yet. But because I don't know I can do further, I will and have to contact our local dealer (we do have Aruba Partner Support).But if someone of you has an idea I will try this with thanks,Kind Regards Robert
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.