I have MS120 switches that will not learn the MAC address of a specific device, a ShopperTrak, if the port's access policy is "MAC whitelist" or "Sticky MAC whitelist." If the policy is "Open," the switch will learn the MAC. The error displayed in the failing scenario is "Port not forwarding traffic due to access policy." But again, I don't see the MAC in the MAC forwarding table. Sticky MAC works just fine for ShopperTraks on Catalyst 3650s.
Does anyone have any experience with Meraki switches and ShopperTrak? Or has anyone had a similar issue with a different device?
Thanks
With "Mac Whitelist" it won't learn, you have to define it. But with Sticky it should learn and store the MAC... What are you setting the Whitelist Size to?
Size was set to 1 for sticky. Yes, I added the MAC address when set to MAC whitelist. Changed to Open and the switch learned the MAC. Switched back to the other two options, received the error below.
You could try running a capture on the port and see what MACs are present. Maybe that device is doing something funky that doesn't show up with a Catalyst switch?
Otherwise, it sounds like you're setting it up properly, so this one might need to be called into support so they can look at what's triggering the error.
Yeah, we have sticky on most of our ports. Works fine with other devices, and again, worked fine previously for ShopperTrak on the 3650s.
I do have a case open for this and just got this response moments ago:
"When the Access Policy is applied to the port, the switch locks the port down until the client device initiates the traffic. Without any traffic coming from the client device, the access policy cannot be validated and port remains shutdown."
This may explain the problem, but I'll have to confirm with our vendor. A server may pull the information from the host, rather than the host sending info.
I appreciate the responses, thanks!
@mjheaberlin wrote:
I do have a case open for this and just got this response moments ago:
"When the Access Policy is applied to the port, the switch locks the port down until the client device initiates the traffic. Without any traffic coming from the client device, the access policy cannot be validated and port remains shutdown."
Ah! That seems like a reasonable explanation to me. Thanks for sharing that response. Good to know.