K

28 Messages

 • 

520 Points

Mon, Oct 18, 2021 2:47 AM

vSZ & vSZ-D Tunnel mode not broadcasting SSID

Hello,

I have both vSZ & Data Plane instances installed. I have an issue where when enabled in tunnel mode, it stops broadcasting the SSID for some strange reason. However when I do disable the tunneling method in vSZ - the AP starts to broadcast the SSID again. I have these instances installed on a bare metal @ a colocation center.

Any ideas about what it could be? I read a post on here about doing the:

get tunnelmgr

However I'm not entirely sure what it is that I'm looking for in this output. It says on that post that the AP may not be able to see the controller when doing data plane functionality? 

I'm currently running this environment in Essentials mode. 

kristphr

28 Messages

 • 

520 Points

2 m ago

So after turning on the tunneling mode, I did more digging to see what has changed. And here's what I'm seeing:

------ TUNNELMGR Information ------

tunnelmgr Service:Enabled

Tunnel Establishment: Enabled

Tunnel IPSec: Disabled

Tunnel Authentication:Enabled

Tunnel Cipher:Disabled

Tunnel Cipher Key Len:

Tunnel Forward Bcast: Disabled

PMTU: Auto

PMTU Discovery: Enabled

Node Affinity:Disabled

Force Fragmentation:Disabled

Offload:Disabled

Tunnel Type: Ruckus-GRE

SCG-D IP List: +1@[192.168.8.10]:23233

SCG-D Subject List: [C=US, ST=CA, L=Sunnyvale, O=Ruckus Wireless Inc., E=service@ruckuswireless.com, CN=redacted]

Internal Subnet:10.255.0.0

GRE over UDP: AP/SCG-D UDP port # 23233/23233

Keep Alive Interval/Retry-limit: 10/6

Keep Alive Interval2: N/A

Keep Alive Count: N/A

Force Primary Interval: N/A

------- Run Time Status (Debug) -------

Current tunnel ID: N/A

Current failover mode: 0

Current connected SCG-D: N/A

Current connected SCG-D subject: N/A

Current connected SCG-D serial: N/A

Current Session UpTime: N/A

Current Keep Alive retry count: N/A

Number of tunnel (re)establishment: 0

FIPS mode: Disable

Reason on last re-establishment:

Suggested action:

Ipsec state : IPSEC_BEGIN

Ping default gateway from last disconnection: N/A

------ Logging parameters ------

Log Console:Disable

Log Level:3

----------- gre1 status -----------

gre1: RX packets N/A errors:N/A dropped:N/A

gre1: TX packets N/A errors:N/A dropped:N/A

OK

I noticed a few things changed from previously:

------ TUNNELMGR Information ------

tunnelmgr Service:Enabled

Tunnel Establishment: Disabled

Tunnel IPSec: Disabled

Tunnel Authentication:Enabled

Tunnel Cipher:Disabled

Tunnel Cipher Key Len: 128

Tunnel Forward Bcast: Disabled

PMTU: Auto

PMTU Discovery: Enabled

Node Affinity:Disabled

Force Fragmentation:Disabled

Offload:Disabled

Tunnel Type: Ruckus-GRE

SCG-D IP List:

SCG-D Subject List:

Internal Subnet:10.255.0.0

No GRE over UDP

Keep Alive Interval/Retry-limit: 10/6

Keep Alive Interval2: N/A

Keep Alive Count: N/A

Force Primary Interval: N/A

------- Run Time Status (Debug) -------

Current tunnel ID: N/A

Current failover mode: 0

Current connected SCG-D: N/A

Current connected SCG-D subject: N/A

Current connected SCG-D serial: N/A

Current Session UpTime: N/A

Current Keep Alive retry count: N/A

Number of tunnel (re)establishment: 0

FIPS mode: Disable

Reason on last re-establishment:

Suggested action:

Ipsec state : IPSEC_BEGIN

Ping default gateway from last disconnection: N/A

------ Logging parameters ------

Log Console:Disable

Log Level:3

----------- gre1 status -----------

gre1: RX packets N/A errors:N/A dropped:N/A

gre1: TX packets N/A errors:N/A dropped:N/A

OK

I noticed in the first output it's trying to contact the local LAN IP @ the Datacenter. I'm assuming this could be the issue. 

Also worth mentioning, I don't have an active license on file (only testing prior to buying the vDP licensing. But could that also be the issue as well? (lol)

(edited)

19 Messages

 • 

244 Points

2 m ago

Hi kristphr,

could you execute this command on the vDP?

show status

you will see if the vDP is in fact connected to the vSZ

From your screenshots the AP is not creating the WLAN tunnels for some reason, It looks like a networking issue. You need to check the networking inside the vDP infrastructure.

Thanks.

David.

kristphr

28 Messages

 • 

520 Points

@david_saez It may be a networking issue. I do have my port forwards set on the router as followed:

The show status output: 
Any ideas what it is that I may be doing wrong? 
kristphr

28 Messages

 • 

520 Points

It does show the vSZ & Data Plane are connected. And I did approve of them via the vSZ GUI. 

478 Messages

 • 

5.9K Points

2 m ago

SSID isn't broadcasted, because connection to vDP is not established. I am quit sure that it is some firewall or routing issue. 

kristphr

28 Messages

 • 

520 Points

@eizens_putnins 

I have the port forwards for this. in the above reply. Any ideas what else it could be? 

vSZ: 192.168.8.7

vDP (ctrl): 192.168.8.10

vDP (mgmt): 192.168.9

is this setup not advisable? I see where a lot of the data is on an entirely separate network. 

478 Messages

 • 

5.9K Points

For your SSID to work, you need 2 separate things to happen:

AP must establish SSH tunnel to vSZ (for management)

AP must establish tunnel to vDP (for SSID traffic)

So what is the status of AP? Is it shown in vSZ as online? If yes, than SSH tunnel to vSz is established. I suppose, it is 

But tunnel for SSID data is not established, and seems that it shows wrong IP (tunnel can't be established to internal IP, it must show routed IP). Do you have configured external IP in vDP configuration? It is neccessary same way, as external IP for vSZ. 

19 Messages

 • 

244 Points

2 m ago

Try these pings to discard a networking issue:

  1. Inside vSZ-D CLI, ping the GW of DATA Interface using -I <DATA interface IP address>   --- > ping -I 192.168.8.1
  2. Inside AP CLI, try to ping the default GW
  3. Inside AP CLI, try to ping GW of DATA interface. -- > ping 102.168.8.1
  4. Inside AP CLI, try to ping DATA interface. -- > ping 192.168.8.10

(edited)

Official Rep

 • 

1.3K Messages

 • 

17.7K Points

1 m ago

There will be 3 tunnel formed.

  1. Controller/management tunnel between v/SZ to v/SZ-D
  2. Controller tunnel between v/SZ - AP
  3. Data tunnel between AP - vSZ-D

Make sure these devices can reach each other for each tunnel.

kristphr

28 Messages

 • 

520 Points

@syamantak_omer 

I'm able to ping the vSZ from the vDP. As well as from vDP to vSZ.

Doing the "Get scg" command via the AP: 


------ SCG Information ------
SCG Service is enabled.
AP is managed by SCG.
State: RUN_STATE
Server List: 192.168.8.7,PUBLIC-IP
SSH tunnel connected to PUBLIC-IP
Failover List: Not found
Failover Max Retry: 2
DHCP Opt43 Code: 6
Server List from DHCP (Opt43/Opt52): Not found
SCG default URL: RuckusController
SCG config|heartbeat intervals: 30|30
SCG gwloss|serverloss timeouts: 1800|7200
Controller Cert Validation : disable

From the AP itself, these are located remotely. It shows the LAN IP 192.168.8.7 (vSZ) in the server list, but that's the LAN IP from the controller itself behind a router located at our colo.  

(edited)

kristphr

28 Messages

 • 

520 Points

My server is a different IP than the NAT IP I assigned my vSZ. So do I need to remove the PUBLIC-IP of the controller above, and make that the server IP (which is my router) ?

Colo Topology:

Router <--- 123.45.6.7 - 123.45.6.11 (5 IP Block)

vSZ <---- LAN 192.168.8.7 -- (WAN)123.45.6.10

vDP <---- LAN 192.168.8.11

Port Forwards:

  • vSZ >> 22,443
  • vDP >> 23233

Remote Location: 

My H510 (at a location) is pointed at the controller: 123.45.6.10

The LAN side behind my router

(edited)

Official Rep

 • 

1.3K Messages

 • 

17.7K Points

@kristphr if APs are reaching controller over the public IP then that is what you have to assign on the AP.

AP will fetch local and public both the IPs, if it can reach controller on one of them.

Regards,

Syamantak Omer

Official Rep | Staff TSE | CWNA | CCNA | RASZA | RICXI

Follow me on Linkedin

Important Announcement