Wired Intelligent Edge

You are aware that the management VLAN is exempt from L3 switching?

If you activate management-vlan 10 you need to either connect the management consoles directly to VLAN 10 or provide routing via other means, e.g. a firewall.

Hi Zac67, thanks for answer.

Yes I know and I think it's a feature and not a problem, that's why I intend to use it to further isolate the management network.
In fact, if you see from the show run, port 1/33 is untagged for vLAN 10 and that's where the console is connected.
The problem is that with the current IP (172.16.11.121) the console is unable to connect either in SSh or in HTTPS to the IP 172.16.11.222 which I assigned to the vLAN10 of the switch.
If I change the IP at the console (e.g. 172.16.11.123) then everything works.
I think the switches don't allow access to management's IP from IPs that have already accessed vLAN 1 IP before.
Since I can't change the IP of the other console, the virtual one (172.16.11.21) I wanted to know if there is a command to "reset" the cache or whatever it is that prevents me from connecting.

You are aware that the management VLAN is exempt from L3 switching?

If you activate management-vlan 10 you need to either connect the management consoles directly to VLAN 10 or provide routing via other means, e.g. a firewall.

Hi, could you share a sanitized running configuration of one of your three Aruba 2930M backplane stacks? are you testing SSH (or HTTPS) access within a stack (example: workstation connected to - say - interface 1/n untagged member of Management VLAN 10 with proper IP addressing of the stack where you defined VLAN 10 as the "Management (non-routable) VlAN")?

Hi Zac67, thanks for answer.

Yes I know and I think it's a feature and not a problem, that's why I intend to use it to further isolate the management network.
In fact, if you see from the show run, port 1/33 is untagged for vLAN 10 and that's where the console is connected.
The problem is that with the current IP (172.16.11.121) the console is unable to connect either in SSh or in HTTPS to the IP 172.16.11.222 which I assigned to the vLAN10 of the switch.
If I change the IP at the console (e.g. 172.16.11.123) then everything works.
I think the switches don't allow access to management's IP from IPs that have already accessed vLAN 1 IP before.
Since I can't change the IP of the other console, the virtual one (172.16.11.21) I wanted to know if there is a command to "reset" the cache or whatever it is that prevents me from connecting.

You are aware that the management VLAN is exempt from L3 switching?

If you activate management-vlan 10 you need to either connect the management consoles directly to VLAN 10 or provide routing via other means, e.g. a firewall.

Hi parnassus,

below I send you an ipconfig of the console and the show run of a stack.
The console is a physical workstation directly attached to port 33 of stack member 1 and as you see port 1/33 is untagged for vlan 10.

There is no doubt that this works at the connection/network level because if I simply change the workstation's IP to, for example, 172.16.11.122, I manage to administer everything correctly.

The problem is that with the IPs 172.16.11.121 of the workstation and 172.16.11.21 of the server dedicated to management (which also acts as the DNS of 172.16.11.0/24 Network) I can't connect to the IPs of the stacks that I gave to vLAN 10.

As strange as this is, I think it's because the switches somewhere wrote that the IPs 171 and 21 have so far been used to administer the switches using the native vLAN IPs (192.168.0.234 in this example) and for some reason I don't allow for the change to new IP.

C:\Users\Admin.Console>ipconfig

Configurazione IP di Windows

Scheda Ethernet Ethernet:

   Suffisso DNS specifico per connessione:
   Indirizzo IPv4. . . . . . . . . . . . : 172.16.11.121
   Subnet mask . . . . . . . . . . . . . : 255.255.255.0
   Gateway predefinito . . . . . . . . . : 172.16.11.254

C:\Users\Admin.Console>

SW-A-CED02# sh run

Running configuration:

; hpStack_WC Configuration Editor; Created on release #WC.16.07.0003
; Ver #14:01.4f.f8.1d.9b.3f.bf.bb.ef.7c.59.fc.6b.fb.9f.fc.ff.ff.37.ef:02

stacking
   member 1 type "JL323A" mac-address 883a30-a15d00
   member 1 priority 250
   member 1 flexible-module A type JL083A
   member 2 type "JL323A" mac-address 883a30-a03d80
   member 2 priority 200
   member 2 flexible-module A type JL083A
   member 3 type "JL323A" mac-address 883a30-a0af40
   member 3 priority 150
   member 3 flexible-module A type JL083A
   exit
hostname "SW-A-CED02"
trunk 1/A1,2/A1 trk1 lacp
trunk 1/A2,2/A2 trk2 lacp
trunk 2/44,3/44 trk6 lacp
timesync ntp
ntp unicast
ntp server 193.204.114.232
ntp enable
telnet-server listen data
time daylight-time-rule western-europe
time timezone 60
web-management listen data
ip default-gateway 192.168.0.252
ip ssh listen data
snmp-server community "public" unrestricted
snmp-server host 192.168.0.4 community "public" trap-level critical
snmp-server listen data
snmp-server contact "*************" location "Divisione Attrezzature - Rack02 CED"
oobm
   disable
   ip address dhcp-bootp
   member 1
      ip address dhcp-bootp
      exit
   member 2
      ip address dhcp-bootp
      exit
   member 3
      ip address dhcp-bootp
      exit
   exit
vlan 1
   name "DEFAULT_VLAN"
   no untagged 1/29-1/30,1/32-1/43,2/29-2/30,2/32-2/43,2/48,3/32-3/42
   untagged 1/1-1/28,1/31,1/44-1/48,1/A3-1/A4,2/1-2/28,2/31,2/45-2/47,2/A3-2/A4,3/1-3/31,3/43,3/45-3/48,3/A1-3/A4,Trk1-Trk2,Trk6
   ip address 192.168.0.234 255.255.255.0
   ipv6 enable
   ipv6 address dhcp full
   exit
vlan 10
   name "Management"
   untagged 1/33,1/43,2/43
   tagged Trk1-Trk2
   ip address 172.16.11.222 255.255.255.0
   exit
vlan 20
   name "DMZ"
   untagged 2/33,3/33
   tagged Trk1-Trk2
   no ip address
   exit
vlan 30
   name "Fonia"
   untagged 1/29-1/30,1/32,1/41-1/42,2/29-2/30,2/32,2/41-2/42,3/41-3/42
   tagged Trk1-Trk2
   no ip address
   exit
vlan 40
   name "Sorveglianza"
   untagged 1/35-1/37,2/35-2/37,2/48,3/35-3/37
   tagged 3/47,Trk1-Trk2
   no ip address
   exit
vlan 50
   name "ProdA"
   untagged 1/34,1/38-1/40,2/34,2/38-2/40,3/32,3/34,3/38-3/40
   tagged 3/47,Trk1-Trk2
   no ip address
   exit
vlan 90
   name "Isolamento"
   no ip address
   exit
management-vlan 10
spanning-tree Trk1 priority 4
spanning-tree Trk2 priority 4
spanning-tree Trk6 priority 4
no tftp server
tftp server listen data
no autorun
no dhcp config-file-update
no dhcp image-file-update
password manager

Hi, could you share a sanitized running configuration of one of your three Aruba 2930M backplane stacks? are you testing SSH (or HTTPS) access within a stack (example: workstation connected to - say - interface 1/n untagged member of Management VLAN 10 with proper IP addressing of the stack where you defined VLAN 10 as the "Management (non-routable) VlAN")?

Hi Zac67, thanks for answer.

Yes I know and I think it's a feature and not a problem, that's why I intend to use it to further isolate the management network.
In fact, if you see from the show run, port 1/33 is untagged for vLAN 10 and that's where the console is connected.
The problem is that with the current IP (172.16.11.121) the console is unable to connect either in SSh or in HTTPS to the IP 172.16.11.222 which I assigned to the vLAN10 of the switch.
If I change the IP at the console (e.g. 172.16.11.123) then everything works.
I think the switches don't allow access to management's IP from IPs that have already accessed vLAN 1 IP before.
Since I can't change the IP of the other console, the virtual one (172.16.11.21) I wanted to know if there is a command to "reset" the cache or whatever it is that prevents me from connecting.

You are aware that the management VLAN is exempt from L3 switching?

If you activate management-vlan 10 you need to either connect the management consoles directly to VLAN 10 or provide routing via other means, e.g. a firewall.

Hi, could you share a sanitized running configuration of one of your three Aruba 2930M backplane stacks? are you testing SSH (or HTTPS) access within a stack (example: workstation connected to - say - interface 1/n untagged member of Management VLAN 10 with proper IP addressing of the stack where you defined VLAN 10 as the "Management (non-routable) VlAN")?

Hi Zac67, thanks for answer.

Yes I know and I think it's a feature and not a problem, that's why I intend to use it to further isolate the management network.
In fact, if you see from the show run, port 1/33 is untagged for vLAN 10 and that's where the console is connected.
The problem is that with the current IP (172.16.11.121) the console is unable to connect either in SSh or in HTTPS to the IP 172.16.11.222 which I assigned to the vLAN10 of the switch.
If I change the IP at the console (e.g. 172.16.11.123) then everything works.
I think the switches don't allow access to management's IP from IPs that have already accessed vLAN 1 IP before.
Since I can't change the IP of the other console, the virtual one (172.16.11.21) I wanted to know if there is a command to "reset" the cache or whatever it is that prevents me from connecting.

You are aware that the management VLAN is exempt from L3 switching?

If you activate management-vlan 10 you need to either connect the management consoles directly to VLAN 10 or provide routing via other means, e.g. a firewall.