Switching

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.

#srx340
#EX2300

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.

You may isolate the issue as follows. I assume you have SRX acting as gateway and EX 2300 are cascaded one by one to it. 1. Hence, to check the default gateway reach ability issue, you may plug your endpoint on SRX in the same vlan where they are connected on switch and use static ip to test. See if you are getting the same issue on SRX as well.
1. a. - if you having the issue with default gateway ping with SRX as well then you need to check the SRX to troubleshoot further. Paste the configuration of SRX.

1.b - if you are not facing the same issue of default gateway ping with static ip then you may connect your endpoint with the switch immediately connected to SRX and check. Similarly, you may go till the last switch at least to isolate the issue. 1.c. - if you are successful with switch 1 (immediately connected EX 2300) using static ip then try DHCP and see the results. I believe this way, you are should be able isolate the issue. Post which, do paste the configuration of the troublesome device to troubleshoot it further.

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.

Louisk,

 

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.

 

Cheers!