Why not an easier way to block clients

[systemscsn]

I know im going to be talking about Extremes competition, but we used to have Rucks wifi where i work.  We had a lot of AP’s, as well as an onsite ZoneDirector.

if i found a client/device was doing something i didnt like, under the client/device view, i could click on a “x” next to the device i wanted to block, and it would block it.  It would stay blocked from wifi until i deleted the device.

Why doesnt Extreme have a way to do that?  really.

My understanding is that I have to create an Access List, add the client in there (by MAC address obviously), and then push that out to EVERY AP we have… right?

So, any plans on making this process a hell of a lot easier.  Like what Ruckus does?

thanks,

J

[systemscsn]

Hi Tomasz,

I think whatever makes it easier to block a client, versus creating an ACL and pushing it to every AP in your enterprise, is a great way to go.  Its a long winded and time consuming way to block a device.

Why not build something into the ExtremeIQ interface, where you enter the MAC address of what you want to block and when a client is attempting to connect to the AP, the AP knows to check against a “list” of blocked devices which are stored in up in the ExtremeIQ back end?  or probably a better way, the same method above you enter the MAC address into the ExtremeIQ web Interface, and the AP’s reach out (every 30 minutes, hourly, nightly, whatever) to the ExtremeIQ backend, and pull that “list” down to themselves locally. Know what im getting at?

I think the latter would be the best way to go.  

Thoughts?

Would something like this every be considered?

Thanks,

J

[Tomasz]

Hi,

Wouldn’t that be a thing to combine XIQ with Extreme Access Control to blacklist devices from there? I would aim to use XIQ-SE/EAC as the primary means of authentication for the entire network so in such case it would sound reasonable IMHO. I know it may not fit just-WLAN customers though.

Hope that helps,

Tomasz

[systemscsn]

Thanks Ovals for explaining this to me.  Shame there isnt some kind of middle-ground though for a solution to this, as pushing out a single change (albeit it a delta change) to 160 AP’s is a pain, as im sure you would agree.

But you are right, stopping it at the point of origin, versus traversing the network to be blocked, woudl save some bandwidth.  But thats bandwidth id happily forgo for a convenient, and easy way to block devices.

Thanks again.  I guess its safe to say, this is a feature that wont make it to Extreme, due to the nature of the hardware.  oh well.

J

[Ovais_Qayyum · Accepted solution]

Hi J,

One of the reasons why it is done the way it is in ExtremeCloud IQ is due to the difference in the WiFi solution architecture. ExtremeCloud IQ is based on distributed architecture where APs will enforce the network functions like FW rules, ACLs, Bandwidth throttle, Application Visibility and Control etc. at the edge of the network. Hence, you need to push the ACLs down to the APs where all the unwanted traffic is dropped.

As far as I know (unless Zone Directors have dramatically changed) this is done differently in Ruckus only because its based on centralized architecture and the Zone Director enforces the policies, the traffic needs to be inspected by the controller for it to be able to either allow/deny, apply bandwidth and application policies etc. Therefore, you only need to block a client on the controller and not create an ACL and push it to the APs.

It may be easier but dropping unwanted traffic at the edge of the network i.e. on the AP is a lot more secure and efficient instead of letting it traverse the network to reach the controller and then drop it. 

Regards,

Ovais