MR32 intermittently fails to forward IP traffic

Solved
skendric
Here to help

MR32 intermittently fails to forward IP traffic

I have a building containing ~150 MR32/33/36.  ~70 MR32.  5GHz only (we disabled 2.4GHz early this year)

 

I believe that the MR32 sometimes quit forwarding ARPs and IP traffic

- I have captured on the WiFi side; I can see ARP Requests for the IP default gateway arriving from the Client

- I have captured on the Wired side:  I don't see those ARP Requests being forwarded

- I have (3) WiFi monitoring probes (Netscout nGeniusPulse 'nPoints'); poking through their logs, I estimate that two of them experience this "cannot send IP traffic" every day or two, for periods of ~1-5 hours, with the occasional larger window (as large as ~10 hours).  The third one experiences this issue less frequently -- less than once/week

 

I have demonstrated that rebooting the MR32 resolves the issue.  Or, just waiting, per above

 

I have a ticket open with Meraki; Support has suggested downgrading the MR32 flock from v28.5 to v25.14, which we have done, no obvious change in behavior.

 

I suspect I have more work to do with Support.   And we have a consultant joining us next week to verify my work.  But in the meantime, I figured I would post here -- anyone seen this?

 

--sk

 

Stuart Kendrick

1 Accepted Solution
skendric
Here to help

OK, I have run for a least a week at a time under various combinations of code rev and Layer 2 Isolation enabled / disabled.  Here are my conclusions:

 

- The MR32, running v25.14, v26.82, or v26.83 hits a bug in which it intermittently quits forwarding ARP Frames (possibly IP frames as well).  Rebooting the MR32 resolves the issue.  Or, you can just wait:  the issue auto-resolves after some number of hours, typically 1-10 hours

- Disabling Layer 2 Isolation (we run our WAPs in Bridge mode) fixes the issue

- The issue does not affect MR33 running v28.x

 

I suspect that Meraki won't fix this bug -- the MR32 is well along its end-of-life trajectory.  Time to disable Layer 2 Isolation or replace the MR32

 

--sk

View solution in original post

6 Replies 6
RaphaelL
Kind of a big deal
Kind of a big deal

Hi , 

 

So your issue is only present on the MR32 ? Do you have any L2 protection features such as DAI ?

SysAdmin
New here

Not on the Wired network.  However, we have enabled Layer 2 LAN isolation on this SSID .... hmm, that seems like it is worth a try.  I have disabled it, will see if this change influences symptoms

 

--sk

skendric
Here to help

Only (1) incident thus far, which is a substantial improvement.  --sk

skendric
Here to help

OK, I have run for a least a week at a time under various combinations of code rev and Layer 2 Isolation enabled / disabled.  Here are my conclusions:

 

- The MR32, running v25.14, v26.82, or v26.83 hits a bug in which it intermittently quits forwarding ARP Frames (possibly IP frames as well).  Rebooting the MR32 resolves the issue.  Or, you can just wait:  the issue auto-resolves after some number of hours, typically 1-10 hours

- Disabling Layer 2 Isolation (we run our WAPs in Bridge mode) fixes the issue

- The issue does not affect MR33 running v28.x

 

I suspect that Meraki won't fix this bug -- the MR32 is well along its end-of-life trajectory.  Time to disable Layer 2 Isolation or replace the MR32

 

--sk

I am having the same problem with our MR32s but we use them like layer 3 roaming mode. We have found a reboot to be the fastest solution. Do you feel like moving to a different client assignment fixed the issue for you?

skendric
Here to help

We didn't experiment with changing client assignment, so I don't know.

 

FWIW:  we replicated the same issue (MR32 quits forwarding ARP frames) for clients connecting at 2.4GHz ... we resolved this by disabling 2.4GHz network-wide

 

--sk

Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.
Labels