Re: [WIRELESS-LAN] blocking broadcast/multicast?

[Patrick Goggins]

From what we've seen the large amount of connections from a small number of 
users have either been virus/bot or p2p in nature with one case being a 
legitimate download manager.

~Patrick

On Jul 2, 2010, at 12:35 PM, "Holland, Stephen" 
mailto:s.holl...@neu.edu>> wrote:

Ryan,

You are correct that we are running M3's today. However, when we originally 
used the filter it was with the Sup2 cards. We were getting unexplained CPU 
spikes and we could not determine why.  One of the recommendations by Aruba was 
to create the following filter and apply to our secure and non-secure roles:

ip access-list eth DenyIPv6
  deny 0x86dd
  permit any


If anybody is following this thread and wants to try this APPLY THE FILTER TO 
THE LOCAL CONTROLLERS AND MASTER FIRST….Then apply filter to the appropriate 
roles.  If you don't do it in this order the controller will not associate the 
role with the filter correctly and it will not work. When we applied we saw CPU 
go down and not up but that was our experience.

In regards to the CPU spikes we found users in the initial captive portal role 
who had 300 - 400 sessions open with the controller. When we blacklisted the 
user the CPU went back down.  We never found out who the users were so we could 
not determine why they created so many sessions. We did however limit the 
number of sessions on the initial role to 50 (need enough sessions for DHCP, 
Portal and other things required to make the portal page operate) and the 
problem went away.

Stephen Holland
Network Engineer
Northeastern University




From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:wireless-...@listserv.educause.edu] On Behalf Of Ryan Holland
Sent: Wednesday, June 30, 2010 5:09 PM
To:  
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] blocking broadcast/multicast?

Stephen,

Ha!

I'm assuming you're running the M3 supervisor cards.  We're using SUP-IIs, and 
they get taxed easily.

==
Ryan Holland
Network Engineer, Wireless
Office of the Chief Information Officer
The Ohio State University
614-292-9906    
holland@osu.edu

On Jun 30, 2010, at 4:31 PM, Holland, Stephen wrote:


Ryan,

Believe it or not the filter does not dent the controller CPU in the least. 
Aruba was the one who recommended the filter to cut down CPU usage.  All of our 
controllers running under 1% on all CPU's.

BTW: I like the last name! We could be brothers………..

Thanks

Stephen Holland
Network Engineer
Northeastern University

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:wireless-...@listserv.educause.edu] On Behalf Of Ryan Holland
Sent: Wednesday, June 30, 2010 2:08 PM
To:  
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] blocking broadcast/multicast?

Stephen,

Blocking IPv6 via the policy enforcement firewall can add an incredible amount 
of processing on the controller, as each and every frame must be inspected. If 
you do not support v6 on wireless, it is much more efficient to just turn it 
off. You said "vlan pooling", so I assume you have Aruba. Issue the following: 
no ipv6 enable

==
Ryan Holland
Network Engineer, Wireless
Office of the Chief Information Officer
The Ohio State University
614-292-9906    
holland@osu.edu

On Jun 30, 2010, at 1:59 PM, Holland, Stephen wrote:



We found that IPv6 broadcast traffic contributed significantly to our wireless 
broadcast traffic. Since we don't support IPv6 on the wireless network we 
blocked the ethertype for IPv6 on our wireless controllers.  Also, running vlan 
pooling with /23's.

On a different topic related to bcast/mcast.   Our wireless controllers connect 
to a pair of 4948 switches which then connect to Cisco routers which provide 
the vlans for wireless users.  We use HSRP for redundancy. We realized there is 
no need to send the mcast traffic for HSRP out to the vlans which support our 
wireless users. As long as the routers see each other's HSRP updates it does 
not make sense to forward them to the wireless network. We created a filter to 
block the HSRP updates on the 4948 switches and applied it in the outbound 
direction toward the wireless controllers. For some reason the filter did not 
work. Doing some testing we found the filter is working because it drops 
updates if we apply it in the inbound direction. Does anybody know the filter 
would not work in the outbound direction?.

Thanks

Stephen Holland
Network Engineer
Northeastern University

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:wireless-...@listserv.educause.edu] On Behalf Of Marcelo Lew
Sent: Wednesday, June 30, 2010 10:05 AM
To:  
WIRELESS-LAN@LISTSE

RE: [WIRELESS-LAN] Guest Wireless Questions

[Winston Chow]

-Original Message-
From: Armstrong, Geoff 
Sent: Friday, July 02, 2010 12:18 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Guest Wireless Questions

Hi Tom,
 
We have an open unauthenticated SSID called ubcvisitor. Upon connecting, the 
guest is presented with a captive portal which displays our AUP and services 
they can access. The user must then enter an email address at the bottom of the 
disclaimer and hit accept in order to start their session. 
 
Outbound from the network we block all ports except for those used by these 
services; http, https, pops, imaps, smtps, pptp, l2tp, IPsec, ssh and ntp. 
 
On the wireless controllers this SSID is set to the lowest traffic priority 
setting (Bronze in Cisco WLC land).
 
We use publicly routable, commercial IP space. This makes it easier on us when 
it comes to logging and tracing. This also prohibits access to many services 
only available from our academic IP space which makes its use a deterrent to 
students, staff and faculty. 
 
We initially only intended to keep this network on for the 2010 Winter Olympics 
but due to popular demand we have turned it into a permanent fixture here at 
UBC. 
 
Geoff Armstrong
Network Support Analyst
Network Management Centre
University of British Columbia – Information Technology
(604) 822-1305
UBC Wireless
 
 
From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:wireless-...@listserv.educause.edu] On Behalf Of Neiss, Tom
 Sent: Friday, July 02, 2010 5:02 AM
 To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
 Subject: [WIRELESS-LAN] Guest Wireless Questions
 
Are you providing free guest wireless access on your campus?
How are you dealing with CALEA if you are?
Do you use your edu address?
Thanks,
 
Thomas R. Neiss
Director of ITS Telecommunications
University at Albany
1400 Washington Ave
Albany, NY 1
(518) 437-3803
 
 
 
** Participation and subscription information for this EDUCAUSE 
Constituent Group discussion list can be found at 
http://www.educause.edu/groups/. ** Participation and subscription 
information for this EDUCAUSE Constituent Group discussion list can be found at 
http://www.educause.edu/groups/. 

**
Participation and subscription information for this EDUCAUSE Constituent Group 
discussion list can be found at http://www.educause.edu/groups/.

Re: Guest Wireless Questions

[Devin Akin]

http://www.zcorum.com/caleafaq.php

http://www.askcalea.com/calea/103.html

Here's a couple of helpful links on CALEA.

Devin

Devin K. Akin
Chief Wi-Fi Architect
Aerohive Networks
E: de...@aerohive.com
C: +1.404.483.2681
O: +1.770.854.8554
W: www.Aerohive.com



Sorry it is the Communications Assistance for Law Enforcement Act.
tn
 
From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:wireless-...@listserv.educause.edu] On Behalf Of Peter P Morrissey
Sent: Friday, July 02, 2010 12:08 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Guest Wireless Questions
 
The CA in CALEA stands for “Computer Access.” We interpret that to mean 
providing a way for them to tap into our network to access any network traffic. 
Our understanding is that if you do your best to provide that and cooperate, it 
isn’t a big deal. We also track IP to user mappings for lots of reasons, that 
we could certainly make available under the correct legal proceedings.
 
Peter Morrissey
 
 
From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:wireless-...@listserv.educause.edu] On Behalf Of Trent Fierro
Sent: Friday, July 02, 2010 9:23 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Guest Wireless Questions
 
Out of curiosity regarding CALEA, do you need to provide law enforcement with a 
way to view where a user goes on your network while using wireless? Or do you 
just need to provide login details? I know that for telephony that you need to 
provide a way to tap a line, etc. but haven’t paid much attention to CALEA 
requirements recently.
 
Trent
 
 
Trent Fierro
Dir of Marketing
408.748.0902  x116
www.avendasys.com
http://twitter.com/Avenda_Systems
 
Security without Boundaries
 
 
 
From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:wireless-...@listserv.educause.edu] On Behalf Of Daniel Eklund
Sent: Friday, July 02, 2010 6:10 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Guest Wireless Questions
 
We provide free guest access, but not open access.  Guests must be vouched for 
by a faculty or staff member and that person takes responsibility for the 
actions of the guest while they use the network.  We have a simple online 
process that the faculty or staff member uses to create a temporary ID and 
password for their guest.  They can create as many IDs as they need and the ID 
can be requested to have a lifetime up to 1 week.  After that time the ID is 
deleted.

--
Daniel Eklund
Director, Networking
Wayne State University
313-577-5558


- "Tom Neiss"  wrote: 
> 
Are you providing free guest wireless access on your campus?
How are you dealing with CALEA if you are?
Do you use your edu address?
Thanks,
 
Thomas R. Neiss
Director of ITS Telecommunications
University at Albany
1400 Washington Ave
Albany, NY 1
(518) 437-3803
 
 
 
** Participation and subscription information for this EDUCAUSE 
Constituent Group discussion list can be found at 
http://www.educause.edu/groups/. 
** Participation and subscription information for this EDUCAUSE 
Constituent Group discussion list can be found at 
http://www.educause.edu/groups/. 
** Participation and subscription information for this EDUCAUSE 
Constituent Group discussion list can be found at 
http://www.educause.edu/groups/.

**
Participation and subscription information for this EDUCAUSE Constituent Group 
discussion list can be found at http://www.educause.edu/groups/.

RE: blocking broadcast/multicast?

[Osborne, Bruce W. (NS)]

Stephen,

You are a wealth of information. How do you limit the bunber of sessions on a 
role? I know you can limit the bandwidth used, but that is not the same thing.

Thanks,
Bruce Osborne
Liberty University

From: Holland, Stephen [s.holl...@neu.edu]
Sent: Friday, July 02, 2010 1:34 PM
Subject: Re: blocking broadcast/multicast?

Ryan,

You are correct that we are running M3's today. However, when we originally 
used the filter it was with the Sup2 cards. We were getting unexplained CPU 
spikes and we could not determine why.  One of the recommendations by Aruba was 
to create the following filter and apply to our secure and non-secure roles:

ip access-list eth DenyIPv6
  deny 0x86dd
  permit any


If anybody is following this thread and wants to try this APPLY THE FILTER TO 
THE LOCAL CONTROLLERS AND MASTER FIRST….Then apply filter to the appropriate 
roles.  If you don't do it in this order the controller will not associate the 
role with the filter correctly and it will not work. When we applied we saw CPU 
go down and not up but that was our experience.

In regards to the CPU spikes we found users in the initial captive portal role 
who had 300 - 400 sessions open with the controller. When we blacklisted the 
user the CPU went back down.  We never found out who the users were so we could 
not determine why they created so many sessions. We did however limit the 
number of sessions on the initial role to 50 (need enough sessions for DHCP, 
Portal and other things required to make the portal page operate) and the 
problem went away.

Stephen Holland
Network Engineer
Northeastern University




From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:wireless-...@listserv.educause.edu] On Behalf Of Ryan Holland
Sent: Wednesday, June 30, 2010 5:09 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] blocking broadcast/multicast?

Stephen,

Ha!

I'm assuming you're running the M3 supervisor cards.  We're using SUP-IIs, and 
they get taxed easily.

==
Ryan Holland
Network Engineer, Wireless
Office of the Chief Information Officer
The Ohio State University
614-292-9906   holland@osu.edu

On Jun 30, 2010, at 4:31 PM, Holland, Stephen wrote:


Ryan,

Believe it or not the filter does not dent the controller CPU in the least. 
Aruba was the one who recommended the filter to cut down CPU usage.  All of our 
controllers running under 1% on all CPU's.

BTW: I like the last name! We could be brothers………..

Thanks

Stephen Holland
Network Engineer
Northeastern University

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:wireless-...@listserv.educause.edu] On Behalf Of Ryan Holland
Sent: Wednesday, June 30, 2010 2:08 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] blocking broadcast/multicast?

Stephen,

Blocking IPv6 via the policy enforcement firewall can add an incredible amount 
of processing on the controller, as each and every frame must be inspected. If 
you do not support v6 on wireless, it is much more efficient to just turn it 
off. You said "vlan pooling", so I assume you have Aruba. Issue the following: 
no ipv6 enable

==
Ryan Holland
Network Engineer, Wireless
Office of the Chief Information Officer
The Ohio State University
614-292-9906   holland@osu.edu

On Jun 30, 2010, at 1:59 PM, Holland, Stephen wrote:



We found that IPv6 broadcast traffic contributed significantly to our wireless 
broadcast traffic. Since we don't support IPv6 on the wireless network we 
blocked the ethertype for IPv6 on our wireless controllers.  Also, running vlan 
pooling with /23's.

On a different topic related to bcast/mcast.   Our wireless controllers connect 
to a pair of 4948 switches which then connect to Cisco routers which provide 
the vlans for wireless users.  We use HSRP for redundancy. We realized there is 
no need to send the mcast traffic for HSRP out to the vlans which support our 
wireless users. As long as the routers see each other's HSRP updates it does 
not make sense to forward them to the wireless network. We created a filter to 
block the HSRP updates on the 4948 switches and applied it in the outbound 
direction toward the wireless controllers. For some reason the filter did not 
work. Doing some testing we found the filter is working because it drops 
updates if we apply it in the inbound direction. Does anybody know the filter 
would not work in the outbound direction?.

Thanks

Stephen Holland
Network Engineer
Northeastern University

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:wireless-...@listserv.educause.edu] On Behalf Of Marcelo Lew
Sent: Wednesday, June 30, 2010 10:05 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] blocking broadcast/multicast?

Hi Bruce, looks like we ha