I have a relatively simple office network. This is in part, a new deployment. The SRX (and config) come from a working environment. We're trying to replace the existing cisco sg300 switches with ex2300's. Everything else stays the same (same wireless, clients, etc).
* srx340 (cluster) that is both L2 and L3 (2 VLANS, 1, 24 as LAN and DMZ respectively)
* 6 ex2300 daisy chained off the srx with twinax cables (xe-0/1/0 xe-0/1/1 are trunks)
* 7 Ruckus APs plugged into switch6 (last in the chain, also trunk ports)
When clients roam across APs, they lose connectivity. At first, it seemed like a DHCP problem, but after doing tcpdumps, we find that the client sends a dhcp request, and never gets the reply. The reply is sent to the AP that the client used to be associated with. Still thinking this was DHCP, we tried using static IPs on the client. No joy. They couldn't ping anything including gateway, or even AP they were connected to). Thought this might be an issue with Ruckus, but we've since been able to duplicate it with wired clients. Plugging them into a switch port, they get DHCP the first time (quickly). Move to a different switch, no DHCP, no success with static IP. Moving back to the first switch, same thing. No DHCP, no success with static IP. Waiting 5m seems to reset something, allowing the client to function again (whether dhcp or static). Tried changing the MAC timeout and it didn't appear to make a difference.
We've tried different kinds of clients (laptop, desktop, mac, windows, android, ios) and they all behave the same way.
The mac-learning-log shows the switch learning/deleting MAC on linkup/down, and the entry is not in the ethernet-switching table.
I can provide sanatized configs, but there isn't much to them.
Why would roaming to another AP cause your clients to send a dhcp request?
The SRX340 does not have SFP+ interfaces so it's not clear to me how you are connecting it to the switches over 10Gb DAC. You should probably attach a topology and configs.
Apologies for not getting back to this sooner. We have a solution, after many hours of working with JTAC.
We had 2 bugs that were biting us:
1) PR1321612 (against 15.1X53-D57) for the first 24 ports (on a 48 port unit) act like a hub and flood unicast traffic in the VLAN, traffic ingested by the upper half has the same problem, but traffic egresses in the upper half normally.
2) PR1326857 (against 15.1X53-D56) for packet duplication - each switch doubles some of the packets that are coming in/transiting. Some cases a client would send 1 dhcp request packet, and would get 4096 replies (all the same transaction id, verified that the server didn't send that many, etc) - the more switches you chain together, the more amplified the problem becomes.
We're currently running D55 and things have been stable for a couple days.
Just wanted to drop in and say thank you for posting this along with the resolution. We were experiencing a similar situation and your effort made an impact here.