- Depending on how ISL LAG has been set-up, native vlan 1 may not be tagged. At the time the best practice has been written, this was automatically set to tag. May be it has changed. However, it should not be the cause of your issue, as untagged should work as well.
- be careful about potential L2 loop happening on native VLAN (so the best practice to avoid single native vlan everywhere).
Original Message:
Sent: Dec 16, 2021 11:32 AM
From: Robert Großmann
Subject: Aruba-CX VSX ISL Link: native VLAN 1 is not tagged, is it valid to use another VLAN as native?
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 regards
Robert
------------------------------
Robert Großmann
Original Message:
Sent: Dec 16, 2021 11:22 AM
From: Davide Poletto
Subject: Aruba-CX VSX ISL Link: native VLAN 1 is not tagged, is it valid to use another VLAN as native?
Hi Robert,
"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?"
AFAIK 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.
"Or is it a valid design not to use vlan 1 as native VLAN?"
It's absolutely a best practice not to use the Default VLAN id 1 (AKA avoiding it as much as possible).
------------------------------
Davide Poletto
Original Message:
Sent: Dec 16, 2021 08:53 AM
From: Robert Großmann
Subject: Aruba-CX VSX ISL Link: native VLAN 1 is not tagged, is it valid to use another VLAN as native?
Hello,
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 hosts
Ping 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 2000
Right 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 lag53
interface lag 53 multi-chassis
no shutdown
description csw-bu
no routing
vlan trunk native 998
vlan trunk allowed all
lacp mode active
exit
csw-rz-r08# sh run int lag256
interface lag 256
no shutdown
description ISL link
no routing
vlan trunk native 1
vlan trunk allowed all
lacp mode active
exit
----
csw-rz-r09# sh run int lag53
interface lag 53 multi-chassis
no shutdown
description csw-bu
no routing
vlan trunk native 998
vlan trunk allowed all
lacp mode active
exit
csw-rz-r09# sh run int lag256
interface lag 256
no shutdown
description ISL link
no routing
vlan trunk native 1
vlan trunk allowed all
lacp mode active
exit
--------------------------------
VSX pair side B (Room BU):
interface lag 53 multi-chassis
no shutdown
description csw-rz
no routing
vlan trunk native 998
vlan trunk allowed all
lacp mode active
exit
csw-bu-r02# sh run int lag 256
interface lag 256
no shutdown
description ISL link
no routing
vlan trunk native 1
vlan trunk allowed all
lacp mode active
exit
---
csw-bu-r03# sh run int lag 53
interface lag 53 multi-chassis
no shutdown
description csw-rz
no routing
vlan trunk native 998
vlan trunk allowed all
lacp mode active
exit
csw-bu-r03# sh run int lag 256
interface lag 256
no shutdown
description ISL link
no routing
vlan trunk native 1
vlan trunk allowed all
lacp mode active
exit
csw-bu-r03#
--------------------------------
------------------------------
Robert Großmann
------------------------------