Capsman forwarding usually adds some delay and that's it. In theory local forwarding and capsman forwarding should be both fine. VLAN is not in scope of this topic, I'm looking for a VLAN-less solution for such isolation. So I'm challenging/questioning those statements "enable all if you want CC/Sonos to work" to be over-permissive (based on "suspicion" and somewhat relevant statement made by do remember about horizons. I've mentioned it only to emphasize that throughout the forum, everyone suggests to enable both to get CC/Sonos working. I know that client-to-client-forwarding is a different thing and it's not in the picture for me as in topic subject. I'm only interested in knowing impact of disabled "local forwarding" property (that exists even without CAPsMAN in interface/ACL) and a solution to get CC/Sonos working with "forwarding" OFF. Sorry, I wasn't specific enough - I have only one physical AP/router (Audissey), though there are two wireless interfaces (2.4GHz and 5GHz) and I'm considering to drop use of CAPsMAN.
SONOS CHROMECAST MAC
You can use the wireless access-list rules also to assign a VLAN tag per MAC address for clients associated to the same wireless AP interface (using the same SSID). So using one VLAN for devices that should be able to each other, and another VLAN for devices that should not, is the only way covering all cases.
And, of course, it cannot override bridge horizon or switch chip rules. You can override the basic client-to-client-forwarding setting of a wireless interface for selected clients using /interface wireless access-list or /caps-man access-list, but this only works if the clients have a stable MAC address (not the case with recent mobile phones that use randomly generated MAC addresses to prevent tracking). So if you want to prevent all your wireless clients from talking to one another, and you have got more than a single AP, you have to use also bridge horizon (or switch chip rules on Routerboard models that support them). Even with CAPsMAN, there is no synchronisation of information about associated clients between the individual AP interfaces.
However, if two such APs are bridged together, and each of the two clients is associated to another one, setting client-to-client-forwarding to no doesn't prevent a frame from getting from one client to another, as from the point of view of each of the AP receiving it, the destination MAC is on at the wired side. The client-to-client-forwarding controls whether the wireless interface running in AP mode forwards a wireless frame sent by one of its clients to the MAC address of another one. When set to yes, it means that the conversion between wireless and Ethernet takes place right at the CAP, when set to no, it means the conversion takes place at the CAPsMAN. The local-forwarding one controls where CAPsMAN creates the virtual wireless interface, hence where received wireless frames emerge as Ethernet ones. client-to-client-forwarding (on any wireless interface, no matter whether CAPsMAN is used or not).
0 kommentar(er)
