Re: [WIRELESS-LAN] How big are your wireless segments?

[Jeremy Gibbs]

Extreme Networks recommends we use a setting of 2 for the DTIM value.




*--Jeremy L. Gibbs*
Sr. Network Engineer
Utica College IITS

T: (315) 223-2383
F: (315) 792-3814
E: jlgi...@utica.edu
http://www.utica.edu

On Thu, Aug 4, 2016 at 9:34 AM, Jake Snyder  wrote:

> In 60 seconds I was just over 100 (107) arp requests. This is a test
> network.  I can definitely ramp that up to do more testing.
>
> Thanks
> Jake Snyder
>
>
> Sent from my iPhone
>
> > On Aug 4, 2016, at 1:45 AM, James Andrewartha <
> jandrewar...@ccgs.wa.edu.au> wrote:
> >
> > Hi Jake,
> >
> >> On 04/08/16 14:19, Jake Snyder wrote:
> >> Slightly different test, Meraki SSID, with a MBA13 running 10.10.5.
> >
> > Thanks for giving it a test.
> >
> >> I did a packet capture on the AP filtered for arp and used wireshark on
> the Mac with the same capture filter.  I'm only tracking arp requests,
> since that's all I should see on the MBA.  100% arp requests sent OTA from
> the AP were seen by the MBA.  But this is an older 11n MBA.  I'll get my
> hands on an 11ac device tomorrow and rerun the test.
> >
> > How many ARP requests were on the network? In one case in 75 seconds I
> > saw 598 on the 10.9.5 laptop, with the 10.11.5 laptop seeing 184.
> > Filtered with (arp.opcode==1) && (eth.addr==ff:ff:ff:ff:ff:ff).
> >
> > Filtering just on eth.addr==ff:ff:ff:ff:ff:ff I see 1863 vs 564 packets,
> > roughly evenly split between NBNS, NetBIOS Browser and ARP requests with
> > a touch of Dropbox LAN Sync and BOOTP (DHCP). Extending it out to
> > eth.ig==1 (all broadcast/multicast traffic) it's 4353 vs 1310, with the
> > addition of mDNS and IPv6.
> >
> >> Is it possible you are in promiscuous mode in Windows?  You shouldn't
> see the arp responses for anything that client didn't send, or in responses
> to the clients request unless promiscuous mode is enabled.  which then
> isn't a fair test of what the laptop did or did not hear.
> >
> > My baseline hardware was a 15" Mid-2012 rMBP running 10.9.5, which is
> > only 11n capable. When rebooted into 10.11 it also exhibits the problem.
> >
> > Thanks,
> >
> > --
> > James Andrewartha
> > Network & Projects Engineer
> > Christ Church Grammar School
> > Claremont, Western Australia
> > Ph. (08) 9442 1757
> > Mob. 0424 160 877
> >
> > **
> > 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: [WIRELESS-LAN] How big are your wireless segments?

[Jake Snyder]

In 60 seconds I was just over 100 (107) arp requests. This is a test network.  
I can definitely ramp that up to do more testing.

Thanks
Jake Snyder


Sent from my iPhone

> On Aug 4, 2016, at 1:45 AM, James Andrewartha  
> wrote:
> 
> Hi Jake,
> 
>> On 04/08/16 14:19, Jake Snyder wrote:
>> Slightly different test, Meraki SSID, with a MBA13 running 10.10.5.
> 
> Thanks for giving it a test.
> 
>> I did a packet capture on the AP filtered for arp and used wireshark on the 
>> Mac with the same capture filter.  I'm only tracking arp requests, since 
>> that's all I should see on the MBA.  100% arp requests sent OTA from the AP 
>> were seen by the MBA.  But this is an older 11n MBA.  I'll get my hands on 
>> an 11ac device tomorrow and rerun the test.
> 
> How many ARP requests were on the network? In one case in 75 seconds I
> saw 598 on the 10.9.5 laptop, with the 10.11.5 laptop seeing 184.
> Filtered with (arp.opcode==1) && (eth.addr==ff:ff:ff:ff:ff:ff).
> 
> Filtering just on eth.addr==ff:ff:ff:ff:ff:ff I see 1863 vs 564 packets,
> roughly evenly split between NBNS, NetBIOS Browser and ARP requests with
> a touch of Dropbox LAN Sync and BOOTP (DHCP). Extending it out to
> eth.ig==1 (all broadcast/multicast traffic) it's 4353 vs 1310, with the
> addition of mDNS and IPv6.
> 
>> Is it possible you are in promiscuous mode in Windows?  You shouldn't see 
>> the arp responses for anything that client didn't send, or in responses to 
>> the clients request unless promiscuous mode is enabled.  which then isn't a 
>> fair test of what the laptop did or did not hear.
> 
> My baseline hardware was a 15" Mid-2012 rMBP running 10.9.5, which is
> only 11n capable. When rebooted into 10.11 it also exhibits the problem.
> 
> Thanks,
> 
> -- 
> James Andrewartha
> Network & Projects Engineer
> Christ Church Grammar School
> Claremont, Western Australia
> Ph. (08) 9442 1757
> Mob. 0424 160 877
> 
> **
> 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: [WIRELESS-LAN] How big are your wireless segments?

[Chuck Anderson]

One thing you might want to consider is sending the DHCP options to
tell clients to not broadcast NetBIOS packets:

https://support.microsoft.com/en-us/kb/121005

We've been using the following options for years without problems:

option netbios-node-type 2;
option netbios-name-servers 0.0.0.0;

Especially if you are going to filter the broadcasts anyway, you might
as well have the clients not send them in the first place.

On Thu, Aug 04, 2016 at 03:45:47PM +0800, James Andrewartha wrote:
> Hi Jake,
> 
> On 04/08/16 14:19, Jake Snyder wrote:
> > Slightly different test, Meraki SSID, with a MBA13 running 10.10.5.
> 
> Thanks for giving it a test.
> 
> > I did a packet capture on the AP filtered for arp and used wireshark on the 
> > Mac with the same capture filter.  I'm only tracking arp requests, since 
> > that's all I should see on the MBA.  100% arp requests sent OTA from the AP 
> > were seen by the MBA.  But this is an older 11n MBA.  I'll get my hands on 
> > an 11ac device tomorrow and rerun the test.
> 
> How many ARP requests were on the network? In one case in 75 seconds I
> saw 598 on the 10.9.5 laptop, with the 10.11.5 laptop seeing 184.
> Filtered with (arp.opcode==1) && (eth.addr==ff:ff:ff:ff:ff:ff).
> 
> Filtering just on eth.addr==ff:ff:ff:ff:ff:ff I see 1863 vs 564 packets,
> roughly evenly split between NBNS, NetBIOS Browser and ARP requests with
> a touch of Dropbox LAN Sync and BOOTP (DHCP). Extending it out to
> eth.ig==1 (all broadcast/multicast traffic) it's 4353 vs 1310, with the
> addition of mDNS and IPv6.
> 
> > Is it possible you are in promiscuous mode in Windows?  You shouldn't see 
> > the arp responses for anything that client didn't send, or in responses to 
> > the clients request unless promiscuous mode is enabled.  which then isn't a 
> > fair test of what the laptop did or did not hear.
> 
> My baseline hardware was a 15" Mid-2012 rMBP running 10.9.5, which is
> only 11n capable. When rebooted into 10.11 it also exhibits the problem.

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

Re: [WIRELESS-LAN] How big are your wireless segments?

[James Andrewartha]

Hi Jake,

On 04/08/16 14:19, Jake Snyder wrote:
> Slightly different test, Meraki SSID, with a MBA13 running 10.10.5.

Thanks for giving it a test.

> I did a packet capture on the AP filtered for arp and used wireshark on the 
> Mac with the same capture filter.  I'm only tracking arp requests, since 
> that's all I should see on the MBA.  100% arp requests sent OTA from the AP 
> were seen by the MBA.  But this is an older 11n MBA.  I'll get my hands on an 
> 11ac device tomorrow and rerun the test.

How many ARP requests were on the network? In one case in 75 seconds I
saw 598 on the 10.9.5 laptop, with the 10.11.5 laptop seeing 184.
Filtered with (arp.opcode==1) && (eth.addr==ff:ff:ff:ff:ff:ff).

Filtering just on eth.addr==ff:ff:ff:ff:ff:ff I see 1863 vs 564 packets,
roughly evenly split between NBNS, NetBIOS Browser and ARP requests with
a touch of Dropbox LAN Sync and BOOTP (DHCP). Extending it out to
eth.ig==1 (all broadcast/multicast traffic) it's 4353 vs 1310, with the
addition of mDNS and IPv6.

> Is it possible you are in promiscuous mode in Windows?  You shouldn't see the 
> arp responses for anything that client didn't send, or in responses to the 
> clients request unless promiscuous mode is enabled.  which then isn't a fair 
> test of what the laptop did or did not hear.

My baseline hardware was a 15" Mid-2012 rMBP running 10.9.5, which is
only 11n capable. When rebooted into 10.11 it also exhibits the problem.

Thanks,

-- 
James Andrewartha
Network & Projects Engineer
Christ Church Grammar School
Claremont, Western Australia
Ph. (08) 9442 1757
Mob. 0424 160 877

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

Re: [WIRELESS-LAN] How big are your wireless segments?

[Jake Snyder]

Slightly different test, Meraki SSID, with a MBA13 running 10.10.5.

I did a packet capture on the AP filtered for arp and used wireshark on the Mac 
with the same capture filter.  I'm only tracking arp requests, since that's all 
I should see on the MBA.  100% arp requests sent OTA from the AP were seen by 
the MBA.  But this is an older 11n MBA.  I'll get my hands on an 11ac device 
tomorrow and rerun the test.

Is it possible you are in promiscuous mode in Windows?  You shouldn't see the 
arp responses for anything that client didn't send, or in responses to the 
clients request unless promiscuous mode is enabled.  which then isn't a fair 
test of what the laptop did or did not hear.

Thanks
Jake Snyder


Sent from my iPhone

> On Aug 3, 2016, at 9:47 AM, James Andrewartha <jandrewar...@ccgs.wa.edu.au> 
> wrote:
> 
> I tried DTIM 3 (after reading that blog post), but it didn't help, the 
> laptop's wifi chipset still just went to sleep and missed packets. Plus, some 
> vendors (eg Meraki, Ruckus) don't let you change it anyway. One thing Ruckus 
> does do is broadcast to unicast conversion when an SSID has 5 or fewer 
> devices on an AP, which masks the issue.
> 
> A quick way to demonstrate the problem is to have Wireshark running on a Mac 
> with OS X 10.10 or 10.11, and another laptop (either running OS X 10.9 or 
> Windows) connected to the same AP, and filter by arp. The first Mac will see 
> between 10-40% of the ARP packets of the second laptop in my testing, 
> depending on the load.
> 
> James Andrewartha
> Network & Projects Engineer
> Christ Church Grammar School
> Claremont, Western Australia
> Ph. (08) 9442 1757
> Mob. 0424 160 877
> 
> From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
> <WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> on behalf of Jake Snyder 
> <jsnyde...@gmail.com>
> Sent: Wednesday, 3 August 2016 8:56 PM
> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> Subject: Re: [WIRELESS-LAN] How big are your wireless segments?
> 
> There was some talk about this with IOS a while back.  Something about Apple 
> wanting a longer dtim value (3 seems to be working for a lot of folks).  Dtim 
> of 1 seemed to give some grief.
> 
> http://www.sniffwifi.com/2016/05/go-to-sleep-go-to-sleep-go-to-sleep.html?m=1
> 
> 
> 
> Thanks
> Jake Snyder
> 
> 
> Sent from my iPhone
> 
>>> On Aug 2, 2016, at 9:04 PM, James Andrewartha <jandrewar...@ccgs.wa.edu.au> 
>>> wrote:
>>> 
>>> On 02/08/16 04:19, Peter P Morrissey wrote:
>>> Given my understanding of the way arp works, not sure I understand how
>>> it is possible for a large subnet to cause a client arp table to become
>>> exhausted unless that client for some reason is directly communicating
>>> with all of the other endpoints on the large subnet.
>>> 
>>> My understanding is that the table is only populated in response to arp
>>> queries that the client has initiated, even though it can “hear”
>>> responses from other clients that are sent as a broadcast. It is easy
>>> enough to verify this on Windows with an arp –a.
>>> 
>>> I also don’t believe that broadcast traffic can have a material impact
>>> on clients these days due to increases in CPU power at the magnitude of
>>> Moore’s Law.
>> 
>> Sadly there is no Moore's Law for batteries. OS X since 10.10 will
>> aggressively sleep and miss broadcast ARP packets. I have seen this on
>> four different AP vendors and have the wireless captures to prove it.
>> Generally it doesn't cause user-visible problems, and it can be worked
>> around by enabling proxy ARP on the APs/controller (if the vendor
>> supports it).
>> 
>> It will most likely present problems if the clients are trying to access
>> servers on the same subnet and it's the *server's* ARP cache that gets
>> exhausted (or simply expires the client). The client will resolve the
>> server's MAC address OK, send the SYN packet, then the server will send
>> a broadcast ARP request to resolve the client's MAC address, which can
>> be missed by the Mac laptop. Depending on the level of broadcast
>> traffic, it can take a minute or more with retries before a connection
>> is established.
>> 
>> For wireless designs where all data goes through the gateway and there's
>> no client communication to other devices on the same subnet you probably
>> won't notice a problem as the gateway's ARP cache will always be fresh.
>> We saw it because we have a campus-wide flat L2 network shared between
>> wired and wireless, and I also noticed a lot of ARP traffi

Re: [WIRELESS-LAN] How big are your wireless segments?

[James Andrewartha]

I tried DTIM 3 (after reading that blog post), but it didn't help, the laptop's 
wifi chipset still just went to sleep and missed packets. Plus, some vendors 
(eg Meraki, Ruckus) don't let you change it anyway. One thing Ruckus does do is 
broadcast to unicast conversion when an SSID has 5 or fewer devices on an AP, 
which masks the issue.

A quick way to demonstrate the problem is to have Wireshark running on a Mac 
with OS X 10.10 or 10.11, and another laptop (either running OS X 10.9 or 
Windows) connected to the same AP, and filter by arp. The first Mac will see 
between 10-40% of the ARP packets of the second laptop in my testing, depending 
on the load.

James Andrewartha
Network & Projects Engineer
Christ Church Grammar School
Claremont, Western Australia
Ph. (08) 9442 1757
Mob. 0424 160 877

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
<WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> on behalf of Jake Snyder 
<jsnyde...@gmail.com>
Sent: Wednesday, 3 August 2016 8:56 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] How big are your wireless segments?

There was some talk about this with IOS a while back.  Something about Apple 
wanting a longer dtim value (3 seems to be working for a lot of folks).  Dtim 
of 1 seemed to give some grief.

http://www.sniffwifi.com/2016/05/go-to-sleep-go-to-sleep-go-to-sleep.html?m=1



Thanks
Jake Snyder


Sent from my iPhone

>> On Aug 2, 2016, at 9:04 PM, James Andrewartha <jandrewar...@ccgs.wa.edu.au> 
>> wrote:
>>
>> On 02/08/16 04:19, Peter P Morrissey wrote:
>> Given my understanding of the way arp works, not sure I understand how
>> it is possible for a large subnet to cause a client arp table to become
>> exhausted unless that client for some reason is directly communicating
>> with all of the other endpoints on the large subnet.
>>
>> My understanding is that the table is only populated in response to arp
>> queries that the client has initiated, even though it can “hear”
>> responses from other clients that are sent as a broadcast. It is easy
>> enough to verify this on Windows with an arp –a.
>>
>> I also don’t believe that broadcast traffic can have a material impact
>> on clients these days due to increases in CPU power at the magnitude of
>> Moore’s Law.
>
> Sadly there is no Moore's Law for batteries. OS X since 10.10 will
> aggressively sleep and miss broadcast ARP packets. I have seen this on
> four different AP vendors and have the wireless captures to prove it.
> Generally it doesn't cause user-visible problems, and it can be worked
> around by enabling proxy ARP on the APs/controller (if the vendor
> supports it).
>
> It will most likely present problems if the clients are trying to access
> servers on the same subnet and it's the *server's* ARP cache that gets
> exhausted (or simply expires the client). The client will resolve the
> server's MAC address OK, send the SYN packet, then the server will send
> a broadcast ARP request to resolve the client's MAC address, which can
> be missed by the Mac laptop. Depending on the level of broadcast
> traffic, it can take a minute or more with retries before a connection
> is established.
>
> For wireless designs where all data goes through the gateway and there's
> no client communication to other devices on the same subnet you probably
> won't notice a problem as the gateway's ARP cache will always be fresh.
> We saw it because we have a campus-wide flat L2 network shared between
> wired and wireless, and I also noticed a lot of ARP traffic from laptops
> looking for Apple TV IP addresses.
>
> We have filed a ticket with Apple, radar://26488949 if anyone has any
> contacts to escalate it. The fastest resolution we've had for any Apple
> bug is 3 years, so I don't expect this to be fixed any time soon.
>
> --
> James Andrewartha
> Network & Projects Engineer
> Christ Church Grammar School
> Claremont, Western Australia
> Ph. (08) 9442 1757
> Mob. 0424 160 877
>
> **
> 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: [WIRELESS-LAN] How big are your wireless segments?

[Chuck Enfield]

Apple is battery-life obsessed.  I wouldn't take their advice about anything 
that affects network performance.

BTW, don’t interpret this as an opinion on the DTIM interval.  I have an 
opinion on that, but don’t know enough to share it publicly.  It's just an 
ad hominem attack.

Chuck Enfield
Manager, Wireless Engineering
Telecommunications & Networking Services
The Pennsylvania State University
110H, USB2, UP, PA 16802
ph: 814.863.8715
fx: 814.865.3988

-Original Message-
From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Lee H Badman
Sent: Wednesday, August 03, 2016 10:13 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] How big are your wireless segments?

But what's the penalty on non-Apple devices?



-Original Message-
From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Jake Snyder
Sent: Wednesday, August 03, 2016 8:56 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] How big are your wireless segments?

There was some talk about this with IOS a while back.  Something about Apple 
wanting a longer dtim value (3 seems to be working for a lot of folks). 
Dtim of 1 seemed to give some grief.

http://www.sniffwifi.com/2016/05/go-to-sleep-go-to-sleep-go-to-sleep.html?m=1



Thanks
Jake Snyder


Sent from my iPhone

>> On Aug 2, 2016, at 9:04 PM, James Andrewartha 
>> <jandrewar...@ccgs.wa.edu.au> wrote:
>>
>> On 02/08/16 04:19, Peter P Morrissey wrote:
>> Given my understanding of the way arp works, not sure I understand
>> how it is possible for a large subnet to cause a client arp table to
>> become exhausted unless that client for some reason is directly
>> communicating with all of the other endpoints on the large subnet.
>>
>> My understanding is that the table is only populated in response to
>> arp queries that the client has initiated, even though it can “hear”
>> responses from other clients that are sent as a broadcast. It is easy
>> enough to verify this on Windows with an arp –a.
>>
>> I also don’t believe that broadcast traffic can have a material
>> impact on clients these days due to increases in CPU power at the
>> magnitude of Moore’s Law.
>
> Sadly there is no Moore's Law for batteries. OS X since 10.10 will
> aggressively sleep and miss broadcast ARP packets. I have seen this on
> four different AP vendors and have the wireless captures to prove it.
> Generally it doesn't cause user-visible problems, and it can be worked
> around by enabling proxy ARP on the APs/controller (if the vendor
> supports it).
>
> It will most likely present problems if the clients are trying to
> access servers on the same subnet and it's the *server's* ARP cache
> that gets exhausted (or simply expires the client). The client will
> resolve the server's MAC address OK, send the SYN packet, then the
> server will send a broadcast ARP request to resolve the client's MAC
> address, which can be missed by the Mac laptop. Depending on the level
> of broadcast traffic, it can take a minute or more with retries before
> a connection is established.
>
> For wireless designs where all data goes through the gateway and
> there's no client communication to other devices on the same subnet
> you probably won't notice a problem as the gateway's ARP cache will always 
> be fresh.
> We saw it because we have a campus-wide flat L2 network shared between
> wired and wireless, and I also noticed a lot of ARP traffic from
> laptops looking for Apple TV IP addresses.
>
> We have filed a ticket with Apple, radar://26488949 if anyone has any
> contacts to escalate it. The fastest resolution we've had for any
> Apple bug is 3 years, so I don't expect this to be fixed any time soon.
>
> --
> James Andrewartha
> Network & Projects Engineer
> Christ Church Grammar School
> Claremont, Western Australia
> Ph. (08) 9442 1757
> Mob. 0424 160 877
>
> **
> 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: [WIRELESS-LAN] How big are your wireless segments?

[Lee H Badman]

But what's the penalty on non-Apple devices?



-Original Message-
From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Jake Snyder
Sent: Wednesday, August 03, 2016 8:56 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] How big are your wireless segments?

There was some talk about this with IOS a while back.  Something about Apple 
wanting a longer dtim value (3 seems to be working for a lot of folks).  Dtim 
of 1 seemed to give some grief.

http://www.sniffwifi.com/2016/05/go-to-sleep-go-to-sleep-go-to-sleep.html?m=1



Thanks
Jake Snyder


Sent from my iPhone

>> On Aug 2, 2016, at 9:04 PM, James Andrewartha <jandrewar...@ccgs.wa.edu.au> 
>> wrote:
>> 
>> On 02/08/16 04:19, Peter P Morrissey wrote:
>> Given my understanding of the way arp works, not sure I understand how
>> it is possible for a large subnet to cause a client arp table to become
>> exhausted unless that client for some reason is directly communicating
>> with all of the other endpoints on the large subnet.
>> 
>> My understanding is that the table is only populated in response to arp
>> queries that the client has initiated, even though it can “hear”
>> responses from other clients that are sent as a broadcast. It is easy
>> enough to verify this on Windows with an arp –a.
>> 
>> I also don’t believe that broadcast traffic can have a material impact
>> on clients these days due to increases in CPU power at the magnitude of
>> Moore’s Law.
> 
> Sadly there is no Moore's Law for batteries. OS X since 10.10 will
> aggressively sleep and miss broadcast ARP packets. I have seen this on
> four different AP vendors and have the wireless captures to prove it.
> Generally it doesn't cause user-visible problems, and it can be worked
> around by enabling proxy ARP on the APs/controller (if the vendor
> supports it).
> 
> It will most likely present problems if the clients are trying to access
> servers on the same subnet and it's the *server's* ARP cache that gets
> exhausted (or simply expires the client). The client will resolve the
> server's MAC address OK, send the SYN packet, then the server will send
> a broadcast ARP request to resolve the client's MAC address, which can
> be missed by the Mac laptop. Depending on the level of broadcast
> traffic, it can take a minute or more with retries before a connection
> is established.
> 
> For wireless designs where all data goes through the gateway and there's
> no client communication to other devices on the same subnet you probably
> won't notice a problem as the gateway's ARP cache will always be fresh.
> We saw it because we have a campus-wide flat L2 network shared between
> wired and wireless, and I also noticed a lot of ARP traffic from laptops
> looking for Apple TV IP addresses.
> 
> We have filed a ticket with Apple, radar://26488949 if anyone has any
> contacts to escalate it. The fastest resolution we've had for any Apple
> bug is 3 years, so I don't expect this to be fixed any time soon.
> 
> -- 
> James Andrewartha
> Network & Projects Engineer
> Christ Church Grammar School
> Claremont, Western Australia
> Ph. (08) 9442 1757
> Mob. 0424 160 877
> 
> **
> 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: [WIRELESS-LAN] How big are your wireless segments?

[Jake Snyder]

There was some talk about this with IOS a while back.  Something about Apple 
wanting a longer dtim value (3 seems to be working for a lot of folks).  Dtim 
of 1 seemed to give some grief.

http://www.sniffwifi.com/2016/05/go-to-sleep-go-to-sleep-go-to-sleep.html?m=1



Thanks
Jake Snyder


Sent from my iPhone

>> On Aug 2, 2016, at 9:04 PM, James Andrewartha  
>> wrote:
>> 
>> On 02/08/16 04:19, Peter P Morrissey wrote:
>> Given my understanding of the way arp works, not sure I understand how
>> it is possible for a large subnet to cause a client arp table to become
>> exhausted unless that client for some reason is directly communicating
>> with all of the other endpoints on the large subnet.
>> 
>> My understanding is that the table is only populated in response to arp
>> queries that the client has initiated, even though it can “hear”
>> responses from other clients that are sent as a broadcast. It is easy
>> enough to verify this on Windows with an arp –a.
>> 
>> I also don’t believe that broadcast traffic can have a material impact
>> on clients these days due to increases in CPU power at the magnitude of
>> Moore’s Law.
> 
> Sadly there is no Moore's Law for batteries. OS X since 10.10 will
> aggressively sleep and miss broadcast ARP packets. I have seen this on
> four different AP vendors and have the wireless captures to prove it.
> Generally it doesn't cause user-visible problems, and it can be worked
> around by enabling proxy ARP on the APs/controller (if the vendor
> supports it).
> 
> It will most likely present problems if the clients are trying to access
> servers on the same subnet and it's the *server's* ARP cache that gets
> exhausted (or simply expires the client). The client will resolve the
> server's MAC address OK, send the SYN packet, then the server will send
> a broadcast ARP request to resolve the client's MAC address, which can
> be missed by the Mac laptop. Depending on the level of broadcast
> traffic, it can take a minute or more with retries before a connection
> is established.
> 
> For wireless designs where all data goes through the gateway and there's
> no client communication to other devices on the same subnet you probably
> won't notice a problem as the gateway's ARP cache will always be fresh.
> We saw it because we have a campus-wide flat L2 network shared between
> wired and wireless, and I also noticed a lot of ARP traffic from laptops
> looking for Apple TV IP addresses.
> 
> We have filed a ticket with Apple, radar://26488949 if anyone has any
> contacts to escalate it. The fastest resolution we've had for any Apple
> bug is 3 years, so I don't expect this to be fixed any time soon.
> 
> -- 
> James Andrewartha
> Network & Projects Engineer
> Christ Church Grammar School
> Claremont, Western Australia
> Ph. (08) 9442 1757
> Mob. 0424 160 877
> 
> **
> 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: [WIRELESS-LAN] How big are your wireless segments?

[James Andrewartha]

On 02/08/16 04:19, Peter P Morrissey wrote:
> Given my understanding of the way arp works, not sure I understand how
> it is possible for a large subnet to cause a client arp table to become
> exhausted unless that client for some reason is directly communicating
> with all of the other endpoints on the large subnet.
>  
> My understanding is that the table is only populated in response to arp
> queries that the client has initiated, even though it can “hear”
> responses from other clients that are sent as a broadcast. It is easy
> enough to verify this on Windows with an arp –a.
>  
> I also don’t believe that broadcast traffic can have a material impact
> on clients these days due to increases in CPU power at the magnitude of
> Moore’s Law.

Sadly there is no Moore's Law for batteries. OS X since 10.10 will
aggressively sleep and miss broadcast ARP packets. I have seen this on
four different AP vendors and have the wireless captures to prove it.
Generally it doesn't cause user-visible problems, and it can be worked
around by enabling proxy ARP on the APs/controller (if the vendor
supports it).

It will most likely present problems if the clients are trying to access
servers on the same subnet and it's the *server's* ARP cache that gets
exhausted (or simply expires the client). The client will resolve the
server's MAC address OK, send the SYN packet, then the server will send
a broadcast ARP request to resolve the client's MAC address, which can
be missed by the Mac laptop. Depending on the level of broadcast
traffic, it can take a minute or more with retries before a connection
is established.

For wireless designs where all data goes through the gateway and there's
no client communication to other devices on the same subnet you probably
won't notice a problem as the gateway's ARP cache will always be fresh.
We saw it because we have a campus-wide flat L2 network shared between
wired and wireless, and I also noticed a lot of ARP traffic from laptops
looking for Apple TV IP addresses.

We have filed a ticket with Apple, radar://26488949 if anyone has any
contacts to escalate it. The fastest resolution we've had for any Apple
bug is 3 years, so I don't expect this to be fixed any time soon.

-- 
James Andrewartha
Network & Projects Engineer
Christ Church Grammar School
Claremont, Western Australia
Ph. (08) 9442 1757
Mob. 0424 160 877

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

RE: [WIRELESS-LAN] How big are your wireless segments?

[Tim Tyler]

So I am guessing from this conversation that the reason the bandwidth
consumption remains the same regardless of one or multiple vlans is because
the frequency still sees the broadcast even if most vlans do not.  And the
frequency is what counts.  {please correct me if I am wrong}.  Hence an arp
from a client uses the same amount of bandwidth regardless of the number of
total clients that see it because vlans share the same bandwidth
(frequency) with one another given any AP.



Even if bandwidth is not an issue, wouldn’t performance still remain an
issue if end devices have to process and drop/ignore higher volumes of
broadcast traffic on a regular basis?



And if one resolves that issue by blocking all broadcast traffic, does that
affect layer 2 apps like Chromecast?

Tim



*From:* The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] *On Behalf Of *Jake Snyder
*Sent:* Tuesday, July 26, 2016 11:25 AM
*To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
*Subject:* Re: [WIRELESS-LAN] How big are your wireless segments?



Actually, they don't have to "respond."  They have to process the incoming
frame.  If they aren't listening for that port, they will ignore or drop
the packet.



If you are talking about client impact to CPU/battery/etc, I agree.  If you
are talking about airtime, the sum of the broadcast traffic is the same.
Stopping broadcast over the air is the scalable way to solve



Thanks

Jake Snyder





Sent from my iPhone


On Jul 26, 2016, at 6:00 AM, Osborne, Bruce W (Network Services) <
bosbo...@liberty.edu <bosbo...@liberty.edu>> wrote:

Actually, you reduce the broadcast traffic with smaller subnets. Remember
that all clients on the subnet **must** respond to a broadcast.



Smaller subnets generally mean fewer clients responding to a given
broadcast. This leaves more airtime for productive Wi-Fi traffic.



​



*Bruce Osborne*

*Wireless Engineer*

*IT Network Services - Wireless*



*(434) 592-4229*



*LIBERTY UNIVERSITY*

*Training Champions for Christ since 1971*



*From:* Jake Snyder [mailto:jsnyde...@gmail.com <jsnyde...@gmail.com>]
*Sent:* Monday, July 25, 2016 1:28 PM
*Subject:* Re: How big are your wireless segments?



One thing to remember is that over the air you have the same amount of
broadcast whether it is one vlan or a pool of 4.

For Example: If you have 4 client segments that are a /24, and each AP has
a client on one of the 4 subnets, you still send the sum of 4x /24 network
broadcast over the air.  Meaning only on lightly loaded APs where you don't
have all 4 subuets do you get a net gain of airtime.  Same applies for
link-local multicast.  Smaller subnets in pools don't really gain you much
without the suppression techniques, and with the suppression techniques,
you don't need the smaller subnets.

The place where pools/groups of vlans are attractive is where you may be
using public IPs and don't have a large contiguous block of IPs in which to
place clients.  So picking 4 non-contiguous /24 networks is easier to do
than picking a full class B.





On Mon, Jul 25, 2016 at 11:04 AM, Tim Tyler <ty...@beloit.edu> wrote:

Brian,

  We have pools of /22 /23/ and /24.  We separate our pools from students
vs fac/staff (still on the same ssid).   It may be ok to do /16.   I know
that Aruba does a lot to prevent broadcast storms, but I feared the
overhead of one large segment might have on it.   We also give students a
different ip pool depending whether they are in a residential building vs
an academic/admin building.  This allows us to shape traffic differently.
But this will become less of an issue as we acquire more bandwidth
(hopefully).

   I am curious of those using /16, does that resolve your layer 2
issues?   Aruba does a good job of bridging many layer 2 solutions anyways,
but having one /16 vlan does seem enticing and perhaps unnecessary for
bridging protocols.  However, I am curious about other overhead efficiency
issues.

Tim



*From:* The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] *On Behalf Of *Brian Helman
*Sent:* Monday, July 25, 2016 10:22 AM
*To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
*Subject:* [WIRELESS-LAN] How big are your wireless segments?



We are in the process of moving from a controllerless vendor to Aruba.  Our
current design is very segmented, to keep wireless device broadcasts from
overwhelming the network and AP’s (we had this problem back in 11g days).
Presently, we’ve limited segments to /23’s (give or take).  In your
controller-based environments, how large have you let these segments go?
Is a /21, /20 … viable?



-Brian




*Brian Helman, M.Ed *|*  Director, ITS/Networking Services | *(: *978.542.7272
<978.542.7272>*

*Salem State University, 352 Lafayette St., Salem Massachusetts 01970*

*GPS: 42.502129, -70.894779*



** Participation and subscription i

Re: [WIRELESS-LAN] How big are your wireless segments?

[Jake Snyder]

Actually, they don't have to "respond."  They have to process the incoming 
frame.  If they aren't listening for that port, they will ignore or drop the 
packet.

If you are talking about client impact to CPU/battery/etc, I agree.  If you are 
talking about airtime, the sum of the broadcast traffic is the same.  Stopping 
broadcast over the air is the scalable way to solve

Thanks
Jake Snyder


Sent from my iPhone

> On Jul 26, 2016, at 6:00 AM, Osborne, Bruce W (Network Services) 
>  wrote:
> 
> Actually, you reduce the broadcast traffic with smaller subnets. Remember 
> that all clients on the subnet *must* respond to a broadcast.
>  
> Smaller subnets generally mean fewer clients responding to a given broadcast. 
> This leaves more airtime for productive Wi-Fi traffic.
>  
> ​
>  
> Bruce Osborne
> Wireless Engineer
> IT Network Services - Wireless
>  
> (434) 592-4229
>  
> LIBERTY UNIVERSITY
> Training Champions for Christ since 1971
>  
> From: Jake Snyder [mailto:jsnyde...@gmail.com] 
> Sent: Monday, July 25, 2016 1:28 PM
> Subject: Re: How big are your wireless segments?
>  
> One thing to remember is that over the air you have the same amount of 
> broadcast whether it is one vlan or a pool of 4.
> 
> For Example: If you have 4 client segments that are a /24, and each AP has a 
> client on one of the 4 subnets, you still send the sum of 4x /24 network 
> broadcast over the air.  Meaning only on lightly loaded APs where you don't 
> have all 4 subuets do you get a net gain of airtime.  Same applies for 
> link-local multicast.  Smaller subnets in pools don't really gain you much 
> without the suppression techniques, and with the suppression techniques, you 
> don't need the smaller subnets.
> 
> The place where pools/groups of vlans are attractive is where you may be 
> using public IPs and don't have a large contiguous block of IPs in which to 
> place clients.  So picking 4 non-contiguous /24 networks is easier to do than 
> picking a full class B.
>  
> 
>  
> On Mon, Jul 25, 2016 at 11:04 AM, Tim Tyler  wrote:
> Brian,
>   We have pools of /22 /23/ and /24.  We separate our pools from students vs 
> fac/staff (still on the same ssid).   It may be ok to do /16.   I know that 
> Aruba does a lot to prevent broadcast storms, but I feared the overhead of 
> one large segment might have on it.   We also give students a different ip 
> pool depending whether they are in a residential building vs an 
> academic/admin building.  This allows us to shape traffic differently.  But 
> this will become less of an issue as we acquire more bandwidth (hopefully).
>I am curious of those using /16, does that resolve your layer 2 issues?   
> Aruba does a good job of bridging many layer 2 solutions anyways, but having 
> one /16 vlan does seem enticing and perhaps unnecessary for bridging 
> protocols.  However, I am curious about other overhead efficiency issues.
> Tim
>  
> From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
> [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Brian Helman
> Sent: Monday, July 25, 2016 10:22 AM
> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> Subject: [WIRELESS-LAN] How big are your wireless segments?
>  
> We are in the process of moving from a controllerless vendor to Aruba.  Our 
> current design is very segmented, to keep wireless device broadcasts from 
> overwhelming the network and AP’s (we had this problem back in 11g days).  
> Presently, we’ve limited segments to /23’s (give or take).  In your 
> controller-based environments, how large have you let these segments go?  Is 
> a /21, /20 … viable?
>  
> -Brian
>  
> 
> Brian Helman, M.Ed |  Director, ITS/Networking Services | (: 978.542.7272
> Salem State University, 352 Lafayette St., Salem Massachusetts 01970
> GPS: 42.502129, -70.894779
>  
> ** 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/.

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

RE: [WIRELESS-LAN] How big are your wireless segments?

[Tim Tyler]

Brian,

  We have pools of /22 /23/ and /24.  We separate our pools from students
vs fac/staff (still on the same ssid).   It may be ok to do /16.   I know
that Aruba does a lot to prevent broadcast storms, but I feared the
overhead of one large segment might have on it.   We also give students a
different ip pool depending whether they are in a residential building vs
an academic/admin building.  This allows us to shape traffic differently.
But this will become less of an issue as we acquire more bandwidth
(hopefully).

   I am curious of those using /16, does that resolve your layer 2
issues?   Aruba does a good job of bridging many layer 2 solutions anyways,
but having one /16 vlan does seem enticing and perhaps unnecessary for
bridging protocols.  However, I am curious about other overhead efficiency
issues.

Tim



*From:* The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] *On Behalf Of *Brian Helman
*Sent:* Monday, July 25, 2016 10:22 AM
*To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
*Subject:* [WIRELESS-LAN] How big are your wireless segments?



We are in the process of moving from a controllerless vendor to Aruba.  Our
current design is very segmented, to keep wireless device broadcasts from
overwhelming the network and AP’s (we had this problem back in 11g days).
Presently, we’ve limited segments to /23’s (give or take).  In your
controller-based environments, how large have you let these segments go?
Is a /21, /20 … viable?



-Brian




*Brian Helman, M.Ed *|*  Director, ITS/Networking Services | *(:
*978.542.7272*

*Salem State University, 352 Lafayette St., Salem Massachusetts 01970*

*GPS: 42.502129, -70.894779*



** 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: [WIRELESS-LAN] How big are your wireless segments?

[Oliver Elliott]

The only real reason to segment these networks is to prevent broadcast
storms, and the wireless controllers tend to have built in broadcast
suppression rendering this harmless. I changed our main SSID from several
/22s to a single /16 a while ago to negate the need to keep adding more
subnets as the usage continues to grow. We've seen no problems with this
whatsoever so far. Keep it simple!

On 25 July 2016 at 16:32, Tony Skalski  wrote:

> We have about 50 /24s. The Aruba controllers hash the MAC address and drop
> users into one of the /24s. We are at about 5,000 daily users.
>
> We have broadcasts and multicasts turned off for these wireless nets. We
> don't use VLAN pools.
>
> ajs
>
>
>
> On Mon, Jul 25, 2016 at 10:21 AM, Brian Helman 
> wrote:
>
>> We are in the process of moving from a controllerless vendor to Aruba.
>> Our current design is very segmented, to keep wireless device broadcasts
>> from overwhelming the network and AP’s (we had this problem back in 11g
>> days).  Presently, we’ve limited segments to /23’s (give or take).  In your
>> controller-based environments, how large have you let these segments go?
>> Is a /21, /20 … viable?
>>
>>
>>
>> -Brian
>>
>>
>>
>> 
>> *Brian Helman, M.Ed *|*  Director, ITS/Networking Services | *(: 
>> *978.542.7272
>> <978.542.7272>*
>>
>> *Salem State University, 352 Lafayette St., Salem Massachusetts 01970*
>>
>> *GPS: 42.502129, -70.894779*
>>
>>
>> ** Participation and subscription information for this EDUCAUSE
>> Constituent Group discussion list can be found at
>> http://www.educause.edu/groups/.
>>
>>
>
>
> --
> Tony Skalski
> Systems Administrator
> a...@stolaf.edu
> 507-786-3227
> St. Olaf College
> Information Technology
> 1510 St. Olaf Avenue
> Northfield, MN55057-1097
>
> ** Participation and subscription information for this EDUCAUSE
> Constituent Group discussion list can be found at
> http://www.educause.edu/groups/.
>
>


-- 
Oliver Elliott
Senior Network Specialist
IT Services, University of Bristol
t: 0117 39 (41131)

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

Re: [WIRELESS-LAN] How big are your wireless segments?

[Tony Skalski]

We have about 50 /24s. The Aruba controllers hash the MAC address and drop
users into one of the /24s. We are at about 5,000 daily users.

We have broadcasts and multicasts turned off for these wireless nets. We
don't use VLAN pools.

ajs



On Mon, Jul 25, 2016 at 10:21 AM, Brian Helman 
wrote:

> We are in the process of moving from a controllerless vendor to Aruba.
> Our current design is very segmented, to keep wireless device broadcasts
> from overwhelming the network and AP’s (we had this problem back in 11g
> days).  Presently, we’ve limited segments to /23’s (give or take).  In your
> controller-based environments, how large have you let these segments go?
> Is a /21, /20 … viable?
>
>
>
> -Brian
>
>
>
> 
> *Brian Helman, M.Ed *|*  Director, ITS/Networking Services | *(: *978.542.7272
> <978.542.7272>*
>
> *Salem State University, 352 Lafayette St., Salem Massachusetts 01970*
>
> *GPS: 42.502129, -70.894779*
>
>
> ** Participation and subscription information for this EDUCAUSE
> Constituent Group discussion list can be found at
> http://www.educause.edu/groups/.
>
>


-- 
Tony Skalski
Systems Administrator
a...@stolaf.edu
507-786-3227
St. Olaf College
Information Technology
1510 St. Olaf Avenue
Northfield, MN55057-1097

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