Forum

I am trying to solve a problem with a user vlan and peer to peer blocking. This is with two 6500s and WiSMs. The p2p blocking only works on the controller itself. So clients can talk to other clients if they are on a different controller. If I am thinking about this correctly it also means all broadcast are being sent over the wireless. This is an HD design so airtime is valuable, I?d like to block client broadcasts other than to the gateway.

Here are the three things I have found that can be a solution but I don?t see being an option.
Set up the interface?s vlan/subnet for the wlan differently on each controller, basically same SSID but different vlan/subnet. This will cause a layer 3 roam if the client roams from an AP on one controller to an AP on a different controller. I?ve read a Cisco AS comment that this will cause problems in an HD design. The anchors drive up load on the controllers. It will also be a pain to setup on our gateway.

Next is an ACL on the controller. Not sure how you?d set this up, I guess you would just block all traffic that didn?t come from the gateway and then apply it to the user vlan interface? From what I have read this also causes a huge performance hit.

Last I have looked in to private vlans. This seems like a good option but it doesn?t look like you can configure it on the 6500 correctly. The 4500 have a setting for promiscuous trunks but the 6500 doesn?t. So on the 6500 you have a have a non-trunked port going to the gateway. We have a trunk with other vlans going to the gateway, no spare interfaces either. It also doesn?t look like there is a way to set the isolated vlan on the WiSM?

I am kind of disappointed that this isn?t built in. If anyone has a good way to block the peer to peer communication or any more info on the options I have listed I?d be interested in hearing it

thanks

Kevin,

A couple of things to note here, by default wireless communications are not forwarded across routed boundaries. You do have the option to specifically enable broadcast forwarding. If you don't want allow communications between two controllers you can also look at applying acls specfically to the wlans. In that case yo would need to identify that traffic.

I understand that broadcasts aren't forward across routed boundaries. So breaking up client vlans would work however it means that when a client roams it will be a "layer 3" roam. This means the original controller becomes an anchor. As user counts get high this starts to over load the controller. At least that is how I understand comment on High Density deployments from Cisco. They say not to have layer 3 roaming in HD designs.

Where is the broadcast forwarding setting in a WLC? Are you talking about the P2P Blocking Action foward-UpStream option? I don't know what you mean by having options to forward broadcast? What I'd like to see is that when a client broadcast the only thing that hears it is the gateway. I don't want the controller to drop the traffic on the vlan because if it does all the other controllers will hear it and forward the broadcast out all of their APs, wasting airtime. I don't really need to forward the broadcast I just want to block it from going to all of the clients.

It is my understanding that ACLs on the WLC take a huge performance hit. The WLC is the only place to apply the ACL. Since it is layer 2 to the other controllers there isn't a router in the middle to use with normal ACLs. I'd say maybe you could come up with a PACL but since the WiSM automatically builds it's interface and port channel I don't think you can configure the PACL to the WiSM port.

It could well be indeed that peer to peer blocking only works with intracontroller traffic (feature request?). The same is true for disabling management over wireless. You could still manage the other wism over wireless. You would probably not want a pepper and salt design in HD. So you can forecome most of the peer to peer (e.g. relatively close to eachother) by assigning APs per floor/building to a specific wism.
BC traffic is dropped by default, unless you specifically enable broadcast. I have seen implementations where IPv6 multicast traffic is a great deal of the total traffic because of enabling BC.

This is going to be in a stadium where all the APs and clients can see each other for the most part. Currently we can't put all the APs on the same controller for the coverage areas needed. WiSM2s should help with that...

So if the controller see a broadcast on the wire, say vlan 10 it won't forwarded it out any of the WLANs that have an interface in vlan 10? Where is that setting configured and do you have any links related to the topic?

I googled it and didn't find much. Looks like the show network summary pulls this up.

Ethernet Multicast Forwarding............... Disable
[b]Ethernet Broadcast Forwarding............... Disable[/b]
AP Multicast/Broadcast Mode................. Unicast

Which is good news if that means it doesn't forward any broadcasts from the ethernet.

I did find this also...
[quote]Before WLC firmware release 4.0.206.0, multicast packet forwarding enabled either in unicast or multicast mode, also enabled broadcast packet forwarding. In WLC firmware release 4.0.206.0, broadcast and multicast traffic must be enabled separately. Broadcast is disabled by default. Issue this command from the WLC CLI in order to enable broadcast:

config network broadcast enable[/quote]

Is it only configurable from the CLI?

[url=http://www.cisco.com/en/US/docs/solutions/Enterprise/Mobility/emob41dg/ch2_Arch.html#wp1028269]BC/MC behavior explained[/url]

You can configure it from the UI.

Thanks for the link Frans. At least I won't have to worry about the broadcast anymore. Still need to figure out how to block peer to peer communication for security purposes.

If peer to peer unwanted appears to work in intercontroler scenario's you should have the upstream component decide (ACL).

Kevin

Don't know if you've tried the following forum:

https://supportforums.cisco.com/community/netpro/wireless-mobility/begin-wireless

You can often get a reply literally within minutes. They really, really know their stuff. One of the guys from this forum ( George Stefanick ) has put up some excellent posts there. George has an incredible knowledge of Cisco Wireless gear and is very friendly.

I read over every post each day and keep a word document with the weblink as well as key points from each post. My little brain is buzzing by the end of the day, but it's all good stuff. Some nights if there is a really interesting problem, I can barely get to sleep. Pretty sad really, but there you go. The life of a nerd. Depending on time zones etc, you can often "see" a problem being resolved almost in realtime as the various people go back and forth.

If you haven't already done so, check them out. You won't be disappointed. They've won a number of awards for the forum.

As always with ACLs?location, location, location

Dave

The question is there but is "not answered"

https://supportforums.cisco.com/thread/2003194

This is where I read that ACLs on the WLCs causes a performance hit. Also the thought on trying to use private vlans.

I think the private vlans would be the solution but it seems like they are kind of limited in function on the 6500, as you can't configured trunks correctly (this feature is on 4500s though). Also since the WiSM auto configures it's own ports you can't apply the changes needed to ports.

PACL would be a good option for layer 2 ACLs but again you can't apply them to any ports because the WiSM doesn't have any physical ports.

I can't think of anyway in the 6500 to block layer 2 traffic. My SE tells me that all the layer2 traffic runs through the sup card and you can apply a L2 ACL there but it would require an ACL entry for every client. He tells me there isn't dynamic way to do it. So that isn't going to work. I am far from a 6500 expert but this SE is a CCIE R&S guy. I'd think you could make an ACL to only allow traffic to and from the router's MAC and then deny all? I'll have to dig in to it some more. The SE is going to ask his resources about this problem. I am not totally sure that the two WLCs on the WiSM1 don't talk directly, seems odd the traffic would go up to the sup and then come back.

Oh well. Good news is the 7.2 code on the WiSM2 is going to support 1000 aps. So I'll be able to just put all the APs on one WLC and the P2P will work. Not sure how long it will be before I'll have more than a 1000 aps per site. It also doesn't help me at my WiSM1 sites.

thanks for the help