cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
9987
Views
50
Helpful
12
Replies

P2P Blocking Action Blocking inconsistently.

Shide607
Level 1
Level 1

I wonder if anyone has had this issue before and if I am just missing something in the configuration. For the guest network I enabled P2P blocking with Drop and I have flex connect local switching enabled.

The problem that I run into is that it seems like it is working on most devices except on my phone I can still scan and see other devices that are connected which are usually phones and pings are able to get through.

Anyone help me here and shed some light on this?

2 Accepted Solutions

Accepted Solutions

Prateek Saxena
Cisco Employee
Cisco Employee

P2P blocking in flexconnect local switching only works for clients on the same AP. If you have 2 clients both on different AP's with local switching then they will be able to communicate. Expected behaviour.

 

Refer to restrictions:

https://www.cisco.com/c/en/us/td/docs/wireless/controller/8-2/config-guide/b_cg82/b_cg82_chapter_01010001.html

 

Unified solution for central switching clients supports peer-to-peer blocking for clients associated with different APs. However, this solution targets only clients connected to the same AP. FlexConnect ACLs can be used as a workaround for this limitation.

View solution in original post

There have been multiple topics within the community regarding this subject, like this one for example. The documentation on this subject is lacking detail. People are using this feature to isolate there guests and might believe that it is working based on their (lab) testing with just one access-point or purely based on the documentation.

My advice is to provide at least a warning within the GUI & CLI of the WLC during the activation of this feature in case also local-switching has been activated. Ideal situation would be that end-point information is shared within flexconnect groups so that P2P blocking actually provides real end-point isolation.

Please rate useful posts... :-)

View solution in original post

12 Replies 12

@Shide607

Is it this phone under the same SSID as the other devices? If so, you may have a bug.

 

 

 

 

-If I helped you somehow, please, rate it as useful.-

Yeah, they are both under the same SSID. I also had this with a previous IOS version as well and just recently updated hoping it would fix the issue.

Scott Fella
Hall of Fame
Hall of Fame

Are you hitting the same controller(s).  P2P blocking only works when clients are on the same controller.

-Scott
*** Please rate helpful posts ***

Yeah, sorry I forgot to mention this is all on the same controller.

Open TAC case.

Prateek Saxena
Cisco Employee
Cisco Employee

P2P blocking in flexconnect local switching only works for clients on the same AP. If you have 2 clients both on different AP's with local switching then they will be able to communicate. Expected behaviour.

 

Refer to restrictions:

https://www.cisco.com/c/en/us/td/docs/wireless/controller/8-2/config-guide/b_cg82/b_cg82_chapter_01010001.html

 

Unified solution for central switching clients supports peer-to-peer blocking for clients associated with different APs. However, this solution targets only clients connected to the same AP. FlexConnect ACLs can be used as a workaround for this limitation.

The statement is unclear ie., its applicable when client is connected Vs standalone.
If it works on only one AP at 'connected mode' then its not good solution and makes no sense as feature/function per-site as WLC should have the client database, Maybe its applicable when AP is 'standalone' as AP might not have info of other clients on the same wlan. Most of the flexconnect function were aligned to work per site/flex-group in connected mode, in general.

Agreed but I think that can be a limitation since the traffic is switched locally from the AP and all the client entry database does not exist on the AP

Correct and agree, looks like only we're snooping/centrally switching certain flex control frames like 802.1x, web-auth, central dhcp, CWA,......Maybe this solution is not applicable/scalable as some APs on same site can be connected Vs standalone where client goes untrackable and ineffective.

Saravanan Lakshmanan
Cisco Employee
Cisco Employee

Here is the breakup, per scenario.

 

WLAN 1) Flexconnect AP Central Switching

#Traffic from/to clients in the same WLAN on same AP managed by same WLC
P2P Blocking drop action can drop unicast packets

 

#Traffic from/to clients in the same WLAN on different APs managed by same
WLC.
P2P Blocking drop action can drop unicast packets

 

WLAN 2) Flexconnect AP Local Switching

#Traffic from/to clients in the same WLAN on same AP managed by same WLC
P2P Blocking drop action can drop unicast packets

 

#Traffic from/to clients in the same WLAN on different APs managed by same WLC.
P2P Blocking drop action CANNOT drop unicast packets
In this situation, flexconnect ACL can be used to drop unicast packets
between those clients.

There have been multiple topics within the community regarding this subject, like this one for example. The documentation on this subject is lacking detail. People are using this feature to isolate there guests and might believe that it is working based on their (lab) testing with just one access-point or purely based on the documentation.

My advice is to provide at least a warning within the GUI & CLI of the WLC during the activation of this feature in case also local-switching has been activated. Ideal situation would be that end-point information is shared within flexconnect groups so that P2P blocking actually provides real end-point isolation.

Please rate useful posts... :-)

WLAN 2) Flexconnect AP Local Switching

In my case, how to block traffic on the same wlan, different APs ? 

Review Cisco Networking for a $25 gift card