Main Nav

Message from neil-johnson@uiowa.edu

We have a request to support Airplay/Apple TV's on our enterprise network so that instructors can mirror presentations from their iPad's to classroom and meeting room projectors. For performance reasons, we suppress multicast on our wireless networks and to conserve IP address space we dynamically assign users to wireless subnets so that two devices in a room may be on different IP subnets. So for right now it's not possible on our network. Of course the next question we get asked is if instructors can bring in their own "temporary" access points to do this. I'm wondering what other institutions responses are to request like these? Do you have an official policy? Thanks. -Neil -- Neil Johnson Network Engineer The University of Iowa Phone: 319 384-0938 Fax: 319 335-2951 Mobile: 319 540-2081 E-Mail: neil-johnson@uiowa.edu ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.

Comments

We have had similar requests / queries about this in particular, as well as other general "wireless server roles" for devices (e.g., printers, projectors). We also suppress multicast/broadcast, and are not equipped for wireless "servers". I shudder to think if Airplay was default open, just how long it would take some students to "project" something inappropriate to any/all available monitors... The "standalone AP" concept by itself would work, but unless you let the AP route to your network, would preclude the instructor's device from being on the network while connected to the "projection" AP. We have tried to get wired connectivity for all server offerings (printers, projectors, etc) and allow wireless to access them that way. You could support a wireless-only device with a standalone AP in bridging mode, but now you're pushing another SSID / channel / RF interference for the rest of your production wireless. Most of that also applies if you do a special SSID off of the campus wireless. So at this point we are strongly discouraging any wireless "server" resources. Jeff On 12/16/2011 12:16 PM, Johnson, Neil M wrote: > We have a request to support Airplay/Apple TV's on our enterprise network > so that instructors can mirror presentations from their iPad's to > classroom and meeting room projectors. > > For performance reasons, we suppress multicast on our wireless networks > and to conserve IP address space we dynamically assign users to wireless > subnets so that two devices in a room may be on different IP subnets. So > for right now it's not possible on our network. > > Of course the next question we get asked is if instructors can bring in > their own "temporary" access points to do this. > > I'm wondering what other institutions responses are to request like these? > Do you have an official policy? > > Thanks. > -Neil ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
Neil,

Here at Cal Poly there is a campuswide policy against bringing in any non-central-IT access points, due to security problems--you can't count on people to use proper security--and to keep the wireless experience consistent...we want only our SSIDs and not a million little ones all over the place.  If someone demonstrates a need for a non-standard AP, we have an exception policy that they can apply for.  We too got the request that you did, and like you we use IP address pooling.  We created a special AP group in our Aruba system and applied it to APs where people want to do Airplay...that special SSID uses one class C network, so that users will always be on the same subnet regardless of where they are on campus, as long as they requested the SSID to be activated in bldg X, room Y.  We might change the mask a bit to make the network bigger if we have to, but generally the demand for this so far hasn't been huge.  Also, we currently don't advertise the SSID on the WLAN...we'll see how that will play out.  One thing that did trip us up was IPv6 on Apple laptops...we had to disable that in order for things to work right with Airplay...the iPhone and iPads worked fine, but the laptops didn't as long as IPv6 was enabled on the client.  (We aren't on IPv6 yet.)  Anyway, so far so good, it has worked well for us.

-Aaron

This is where I daydream about the likes of several Apple engineers reading this list, thinking "Gee, maybe we should consider how to make our toys work in the actual enterprise. It seems that these higher ed folks have real networks that we don't always play well with at times." BYOD- bring your own dilemma. Lee H. Badman Wireless/Network Engineer, ITS Adjunct Instructor, iSchool Syracuse University 315.443.3003 ________________________________________
Here at Northwestern we have had few of the same requests. For the short term we have created a new SSID for that area which bridges traffic to a local network where multicast is enabled. We are talking to Aruba to help with a long term plan. Chris Hart Northwestern University, Evanston chart@northwestern.edu >
On 12/16/2011 12:47 PM, Lee H Badman wrote: > This is where I daydream about the likes of several Apple engineers reading this list, thinking "Gee, maybe we should consider how to make our toys work in the actual enterprise. It seems that these higher ed folks have real networks that we don't always play well with at times." > > BYOD- bring your own dilemma. Yes, we try to counter Bonjour and Rendezvous with Au Revoir :) Jeff ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
Message from jcoehoorn@york.edu

York College is installing an AppleTV in every networked classroom over the next year.  This is in support of a 1:1 iPod Touch program we use.  We're tiny relative to U of Iowa, but if any of this helps, here's how we're making it happen:

Classroom buildings are set so that users in the same building should be on the same subnet. We're small enough this is not a problem for us.

Where possible, we're using a wired connection to the AppleTV  and setting it to the same vlan as the wired network.  Right, that's only two rooms, but the thought of streaming video up to the access point and back to the AppleTV for a single device makes me cringe.

Most of our classrooms are in older buildings. There's only one wired network drop to the room, and adding more will be problematic. To alleviate this, we're looking into small switches in rooms, to support the instructor PC, a wireless access point, a byod network port, the AppleTV, and a projector connection, and in a few cases a printer all of the same original drop. At (count 'em) up to 6 devices per room plus the uplink, we think that will be the better way to go.

Multicast is enabled within each subnet. This is for every subnet across the board. Again, we try to keep it to exactly one subnet per building, and as an admin when I enter a building I know which subnet I should get. This is great for students, because their Apple toys all tend to work the way they want, but the amount of traffic across campus (especially on inter-building fiber links) is still reasonable. This is done mainly because of our 1:1 iPod Touch program... it just wouldn't do to have those and not be able to use them well, and even PC users will have iTunes. As a much larger institution, Iowa may need to think about dividing building into wings or floors, as well.

Make sure to set the AppleTVs to never sleep, and name them after the classroom.

Make sure to education faculty on how to switch inputs between the computer and AppleTV. Even faculty who never use the AppleTV will need to know how to switch a projector back to the computer input after the prior faculty member left it set to AppleTV.


Joel Coehoorn
IT Director
York College, Nebraska
402.363.5603
jcoehoorn@york.edu


     



If you combine the York plan with the separate SSID at Northwestern, you get what I’d like to do at PSU.  Our only problem is that we don’t have enough IPv4 to do it on a large scale, so I’m still looking for something that will work for us.

 

Chuck Enfield

Sr. Communications Engineer

Telecommunications & Networking Services

The Pennsylvania State University

110H, USB2, UP, PA 16802

ph: 814.863.8715

fx: 814.865-3988

 

From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Coehoorn, Joel
Sent: Friday, December 16, 2011 1:48 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] You knew it was coming...Airplay/Apple TV support for instructors.

 

York College is installing an AppleTV in every networked classroom over the next year.  This is in support of a 1:1 iPod Touch program we use.  We're tiny relative to U of Iowa, but if any of this helps, here's how we're making it happen:

 

Classroom buildings are set so that users in the same building should be on the same subnet. We're small enough this is not a problem for us.

 

Where possible, we're using a wired connection to the AppleTV  and setting it to the same vlan as the wired network.  Right, that's only two rooms, but the thought of streaming video up to the access point and back to the AppleTV for a single device makes me cringe.

 

Most of our classrooms are in older buildings. There's only one wired network drop to the room, and adding more will be problematic. To alleviate this, we're looking into small switches in rooms, to support the instructor PC, a wireless access point, a byod network port, the AppleTV, and a projector connection, and in a few cases a printer all of the same original drop. At (count 'em) up to 6 devices per room plus the uplink, we think that will be the better way to go.

 

Multicast is enabled within each subnet. This is for every subnet across the board. Again, we try to keep it to exactly one subnet per building, and as an admin when I enter a building I know which subnet I should get. This is great for students, because their Apple toys all tend to work the way they want, but the amount of traffic across campus (especially on inter-building fiber links) is still reasonable. This is done mainly because of our 1:1 iPod Touch program... it just wouldn't do to have those and not be able to use them well, and even PC users will have iTunes. As a much larger institution, Iowa may need to think about dividing building into wings or floors, as well.

 

Make sure to set the AppleTVs to never sleep, and name them after the classroom.

 

Make sure to education faculty on how to switch inputs between the computer and AppleTV. Even faculty who never use the AppleTV will need to know how to switch a projector back to the computer input after the prior faculty member left it set to AppleTV.

 

Joel Coehoorn
IT Director
York College, Nebraska
402.363.5603
jcoehoorn@york.edu

 

     



We here at Weber State have also had numerous Apple TV/Airplay Screen Sharing requests. The solution that we are working on long term is as follows: 1. Wired ports + DHCP reservations for the Apple TVs with a standardized naming convention (building code-room number-atvX) 2. Wide Area Bonjour/DNS-SD Service Discovery Records for every registered Apple TV 3. i* devices on the 802.1x wireless network with a search domain that references the DNS-SD servers We ran into a snag when our Infoblox appliances wouldn't let us add the funky PTR records needed to make WAB/DNS-SD work, and we haven't had time to get on the phone with their support to figure out a work around/put in a feature request. The big questions that remain (even if this hair brained plan works) are: 1. What happens when an i* device has dozens or hundreds of AppleTVs available to it? Is the UI designed in such a way to allow an instructor to quickly select the AppleTV for the room that they are in? 2. How do we keep the AppleTVs secure from bored or crafty students brute forcing the passwords? -Luke Jenkins Network Analyst Weber State University
I forgot to add background reading for anyone else crazy enough to try to get this working: Info on Wide Area Bonjour and setup instructions (OS X Server centric instructions): http://www.afp548.com/article.php?story=20090205204942121 http://www.afp548.com/article.php?story=20090225001154457 Setting up a Test Server to experiment with Wide-Area DNS-SD: http://www.dns-sd.org/ServerTestSetup.html Manually Adding DNS-SD Service Discovery Records to an Existing Name Server: http://www.dns-sd.org/ServerStaticSetup.html Best of luck to everyone. -Luke Jenkins Network Analyst Weber State University
Message from jhealy@logn.net

Message from neil-johnson@uiowa.edu

If we are going to do this, implementing static wide area bonjour entries seems the way to go. Thanks for the references, but the one thing I can't find is the format for the SRV and TXT records for an Apple TV. If anyone has those I'd be grateful for them, I have an Apple TV device in my hands now, so if someone has a suggestion on how to reverse engineer them, I'd appreciate it. Thanks. -Neil -- Neil Johnson Network Engineer The University of Iowa Phone: 319 384-0938 Fax: 319 335-2951 Mobile: 319 540-2081 E-Mail: neil-johnson@uiowa.edu On 12/16/11 3:31 PM, "Jason Healy" wrote: >
If you have access to a mac and an AppleTV, fire both up on a shared lan segment. Install and run Bonjour Browser (http://www.tildesoft.com/ ) and look for a service type that has your AppleTV listed as a client with that service. You could also get the same info with wireshark on any computer if you want to decode the bonjour packets. While heading into the office to help out is tempting, I have too much to get done this weekend. I'll do so on Monday and report back with the values. -Luke Jenkins Network Analyst Weber State University
It looks like an AppleTV2 running the latest code advertises _airplay._tcp and _raop._tcp. Here are some additional details using dns-sd on a mac running OS X 10.7. The AppleTV is named te-206d-atv1 and the mac address is partially obfuscated to XX:XX:DA:09:XX:XX- ~$ dns-sd -B _airplay._tcp Browsing for _airplay._tcp Timestamp A/R Flags if Domain Service Type Instance Name 10:50:32.624 Add 2 4 local. _airplay._tcp. te-206d-atv1 ~$ dns-sd -L te-206d-atv1 _airplay._tcp Lookup te-206d-atv1._airplay._tcp.local 10:47:10.757 te-206d-atv1._airplay._tcp.local. can be reached at te-206d-atv1.local.:7000 (interface 4) deviceid=XX:XX:DA:09:XX:XX features=0x39f7 model=AppleTV2,1 pw=1 srcvers=120.2 ~$ dns-sd -B _raop._tcp Browsing for _raop._tcp Timestamp A/R Flags if Domain Service Type Instance Name 10:50:23.129 Add 2 4 local. _raop._tcp. XXXXDA09XXXX@te-206d-atv1 ~$ dns-sd -L XXXXDA09XXXX@te-206d-atv1 _raop._tcp. Lookup XXXXDA09XXXX@te-206d-atv1._raop._tcp..local 10:51:42.277 XXXXDA09XXXX@te-206d-atv1._raop._tcp.local. can be reached at te-206d-atv1.local.:49152 (interface 4) txtvers=1 ch=2 cn=0,1,2,3 da=true et=0,3 md=0,1,2 pw=true sv=false sr=44100 ss=16 tp=UDP vn=65537 vs=120.2 am=AppleTV2,1 sf=0x4 Same details using Bonjour Browser (some details redacted)- http://imgur.com/lwRsh I hope this helps. -Luke Jenkins Network Analyst Weber State University
Message from neil-johnson@uiowa.edu

Thanks. Now I just have to convince our DNS admins to least try it out :-). I'm concerned about how scalable any solution is from a DNS (and device support) aspect. -Neil -- Neil Johnson Network Engineer The University of Iowa Phone: 319 384-0938 Fax: 319 335-2951 Mobile: 319 540-2081 E-Mail: neil-johnson@uiowa.edu On 12/19/11 11:57 AM, "Luke Jenkins" wrote: >It looks like an AppleTV2 running the latest code advertises >_airplay._tcp and _raop._tcp. > >Here are some additional details using dns-sd on a mac running OS X 10.7. >The AppleTV is named te-206d-atv1 and the mac address is partially >obfuscated to XX:XX:DA:09:XX:XX- >~$ dns-sd -B _airplay._tcp >Browsing for _airplay._tcp >Timestamp A/R Flags if Domain Service Type > Instance Name >10:50:32.624 Add 2 4 local. _airplay._tcp. > te-206d-atv1 >~$ dns-sd -L te-206d-atv1 _airplay._tcp >Lookup te-206d-atv1._airplay._tcp.local >10:47:10.757 te-206d-atv1._airplay._tcp.local. can be reached at >te-206d-atv1.local.:7000 (interface 4) > deviceid=XX:XX:DA:09:XX:XX features=0x39f7 model=AppleTV2,1 pw=1 >srcvers=120.2 > >~$ dns-sd -B _raop._tcp >Browsing for _raop._tcp >Timestamp A/R Flags if Domain Service Type > Instance Name >10:50:23.129 Add 2 4 local. _raop._tcp. > XXXXDA09XXXX@te-206d-atv1 >~$ dns-sd -L XXXXDA09XXXX@te-206d-atv1 _raop._tcp. >Lookup XXXXDA09XXXX@te-206d-atv1._raop._tcp..local >10:51:42.277 XXXXDA09XXXX@te-206d-atv1._raop._tcp.local. can be reached >at te-206d-atv1.local.:49152 (interface 4) > txtvers=1 ch=2 cn=0,1,2,3 da=true et=0,3 md=0,1,2 pw=true sv=false >sr=44100 ss=16 tp=UDP vn=65537 vs=120.2 am=AppleTV2,1 sf=0x4 > >Same details using Bonjour Browser (some details redacted)- >http://imgur.com/lwRsh > >I hope this helps. > >-Luke Jenkins >Network Analyst >Weber State University > > >
As with many of you, I've been tasked with the same thing. I manage the DNS servers so initially tried it with static entries. That didn't quite work so I then setup another server that allowed for dynamic updates. That didn't work either. After basically sniffing traffic between the Apple TV and other devices I was able to figure out the required records. And after that I found the magical dns-sd command: dns-sd -Z _appletv-v2._tcp that would spit out the exact records (in BIND format) that are needed. It seems that if you do a man on "dns-sd" you don't get all the actual options. Anyway, the important thing here is that I spoke with an Apple engineer and he said Apple specifically disabled streaming to/from an Apple TV. This was a concession they made to content providers and that no amount of DNS records or search domains would allow the Apple TV to be contacted/used from another network. In case anyone is interested, here's the records I gleaned from the Apple TV: $ORIGIN bonjour.utexas.edu. _airplay._tcp PTR utnet-appletv._airplay._tcp utnet-appletv._airplay._tcp SRV 0 0 7000 utnet-appletv.bonjour.utexas.edu. ; Replace with unicast FQDN of target host utnet-appletv._airplay._tcp TXT "deviceid=28:E7:CF:DB:6E:E0" "features=0x39f7" "model=AppleTV2,1" "pw=1" "srcvers=120.2" _raop._tcp PTR 28E7CFDB6EE0@utnet-appletv._raop._tcp 28E7CFDB6EE0@utnet-appletv._raop._tcp SRV 0 0 49152 utnet-appletv.bonjour.utexas.edu. ; Replace with unicast FQDN of target host 28E7CFDB6EE0@utnet-appletv._raop._tcp TXT "txtvers=1" "ch=2" "cn=0,1,2,3" "da=true" "et=0,3" "md=0,1,2" "pw=true" "sv=false" "sr=44100" "ss=16" "tp=UDP" "vn=65537" "vs=120.2" "am=AppleTV2,1" "sf=0x4" _appletv-v2._tcp PTR 35CF2488F02660B1._appletv-v2._tcp 35CF2488F02660B1._appletv-v2._tcp SRV 0 0 3689 utnet- appletv.bonjour.utexas.edu. ; Replace with unicast FQDN of target host 35CF2488F02660B1._appletv-v2._tcp TXT "txtvers=1" "hG=00000000-06f6-4f5d-0171-0bcc51d34d14" "MniT=167845888" "fs=2" "Name=utnet-appletv" "PrVs=65538" "DFID=2" "EiTS=1" "MiTPV=196611" _sleep-proxy._udp PTR 70-35-60-63\032utnet-appletv._sleep-proxy._udp 70-35-60-63\032utnet-appletv._sleep-proxy._udp SRV 0 0 55597 utnet-appletv.bonjour.utexas.edu. ; Replace with unicast FQDN of target host 70-35-60-63\032utnet-appletv._sleep-proxy._udp TXT "" Oscar Ricardo Silva The University of Texas at Austin On 12/20/2011 06:12 PM, Oscar Ricardo Silva wrote: > > > Subject: Re: You knew it was coming...Airplay/Apple TV support for > instructors. > From: "Johnson, Neil M" > Reply-To: The EDUCAUSE Wireless Issues Constituent Group Listserv > > Date: Mon, 19 Dec 2011 18:34:42 +0000 > Content-Type: text/plain > Parts/Attachments: > > text/plain (166 lines) > > > Thanks. > > Now I just have to convince our DNS admins to least try it out :-). > > I'm concerned about how scalable any solution is from a DNS (and device > support) aspect. > > -Neil > ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
Message from s.holland@neu.edu

My apologies to the group.  Forgot to make sure the message did not forward.

 

BTW.  What do people think about a mechanism to convert l2 Bonjour to DDNS updates that could update an apple DNS server?.

 

I suggested this to our vendor. I wonder what other vendors think about this problem.

 

Again my apologies….

 

Steve Holland

 

 

 

 

 

 

I actually setup a BIND DNS server that would allow for dynamic updates but that didn't work (could be I didn't set it up properly). This was done both on a remote server (not on the same L2 network) and one on the same network. In both cases, the Apple TV will only send updates for the ".local" domain and on 224.0.0.1. I am going to setup an OS X server to see if these records register properly. The only problem is whether the clients will query for these records. From looking at logs and packet captures, the clients don't do lookups for records in some of the subdomains: ex. _tcp.example.com or _appletv-v2._tcp.example.com. Oscar On 12/21/2011 12:57 PM, Holland, Stephen wrote: > My apologies to the group. Forgot to make sure the message did not forward. > > BTW. What do people think about a mechanism to convert l2 Bonjour to > DDNS updates that could update an apple DNS server?. > > I suggested this to our vendor. I wonder what other vendors think about > this problem. > > Again my apologies…. > > Steve Holland > > *
Message from kohster@northwestern.edu

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri Dec 16 2011 11:16:43 Central Time, "Johnson, Neil M" wrote: > > We have a request to support Airplay/Apple TV's on our enterprise network > so that instructors can mirror presentations from their iPad's to > classroom and meeting room projectors. This is only going to get more prevalent now that Mountain Lion will support Airplay mirroring from OS X machines. Gonna be fun.... - -- Julian Y. Koh Manager, Network Transport Telecommunications and Network Services Northwestern University PGP Public Key: -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAk9EBcgACgkQDlQHnMkeAWMf8wCfdfVsWgcll4cqUiIQRL/DClf5 w1IAnjvdC0e34jam3rguhn2fG/kUmm+p =Bd3x -----END PGP SIGNATURE----- ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
Isn't it amazing that they actually mention classrooms and conference rooms here, yet the geniuses at Apple probably have no clue about what is really involved? Pete M.
It's time for Apple step up. How many hundreds of hours are we going to spend on this? For the first time in a long time, we are saying "no" for the time being. Tim Cappalli, CCNA ACMA | IT Services | (802) 626-6456 > tim.cappalli@lyndonstate.edu | it.lyndonstate.edu PRIVACY & CONFIDENTIALITY NOTICE This message is for the designated recipient only and may contain privileged, confidential, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of an email received in error is prohibited. Sent from my BlackBerry(r) PlayBook(tm)
On 2/21/2012 4:36 PM, Cappalli, Tim G @ LSC-ITS wrote:
> It's time for Apple step up. How many hundreds of hours are we going to spend on this? For the first time in a long time, we are saying "no" for the time being.

Let's see Apple restrict it to just instructors :)

Jeff

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

Would be interesting to contemplate a petition or similar from the Educause members to Apple requesting that they catch up to the fact that their toys are invading the enterprise, that the enterprise doesn't run on AirPorts, and therefor they might develop towards the enterprise WLAN, Then again, I doubt they'd give a rip. It's a shame that the sexiest devices on the planet have such shallow network development behind them. -Lee ________________________________________ From: The EDUCAUSE Wireless Issues Constituent Group Listserv [WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] on behalf of Cappalli, Tim G @ LSC-ITS [Tim.Cappalli@LSC.VSC.EDU] Sent: Tuesday, February 21, 2012 4:36 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] You knew it was coming...Airplay/Apple TV support for instructors. It's time for Apple step up. How many hundreds of hours are we going to spend on this? For the first time in a long time, we are saying "no" for the time being. Tim Cappalli, CCNA ACMA | IT Services | (802) 626-6456 > tim.cappalli@lyndonstate.edu | it.lyndonstate.edu PRIVACY & CONFIDENTIALITY NOTICE This message is for the designated recipient only and may contain privileged, confidential, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of an email received in error is prohibited. Sent from my BlackBerry(r) PlayBook(tm)
Message from ahockett@warnerpacific.edu

Lee, I'm sure if we all emailed tcook@apple.com he would definitely do something..... like laugh hysterically as he rolls in all of the money he sleeps on. :) -Aaron
Had an Apple rep in recently and he stated Apple (Bonjour) has come a long way since Appletalk on their network protocols. I wanted to believe him and then I tried to use it on our campus. LAN only protocol that relies on mDNS registration to bridge networks assuming all your end devices support it of course. Reminds me of LAN/SOHO only protocols I worked with a decade ago. Why not allow the device being mirrored to specify the device you want to mirror to by IP address or FQDN. I don't think I'm asking for too much from the man but, alas, perhaps I am. Disappointed yet again by Apple network protocols, Brian
Message from kohster@northwestern.edu

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue Feb 21 2012 16:21:24 Central Time, "Kellogg, Brian D." wrote: > > Had an Apple rep in recently and he stated Apple (Bonjour) has come a long way since Appletalk on their network protocols. Well, to be fair, AppleTalk got a bad rep from people who didn't know how to set up zones and network number ranges correctly. :) Indeed, there are still things that AppleTalk could do in terms of easy and logical groupings of services and devices that you can't do with ZeroBonRendezJourConfVous. - -- Julian Y. Koh Manager, Network Transport Telecommunications and Network Services Northwestern University PGP Public Key: -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAk9EGgoACgkQDlQHnMkeAWNz3gCg2fZFRiD7uvXOWPUlgXTi7kzx 4jIAoJbOOwsN7yHHtCmrMqTuO/V71wG1 =WqAG -----END PGP SIGNATURE----- ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
Agreed. We are blocking bonjour between buildings, but not within. I wanted to block within, but there are apps out there that the faculty want to use that require it. That was the compromise I settled on... looking forward to 802.11ac now. I thought my days of dealing with AppleTalk, IPX and Netbeui were done. -Brian
Message from mowchafl@acu.edu

Loved the comment on ATK, IPX, Neteui. Like Yogi Berra said "this is like deja vu all over again!" At 08:54 AM 2/22/2012, you wrote: >Agreed. We are blocking bonjour between buildings, but not within. I wanted to block within, but there are apps out there that the faculty want to use that require it. That was the compromise I settled on... looking forward to 802.11ac now. > >I thought my days of dealing with AppleTalk, IPX and Netbeui were done. > >-Brian > >
Message from brian.david@bc.edu

We are faced with the same issues here at BC... We are starting to block it for all students but have not for the Faculty. Could you give more details on what apps the faculty needed bonjour for? -Brian Brian J David Network Systems Engineer Boston College
We will need Bonjour in order to allow faculty members to mirror their iPads/WhateverAppleProductElse to an AppleTV in a classroom for presentations wirelessly. Presently we block all mcast and bcast on our WLAN due to the channel use overhead this incurs (anywhere from 10% to 20%). We'll be moving to Aruba this summer where enabling bcast and mcast is not an all or nothing endeavor I believe. I think Aruba is integrating some stuff into their controller code to help with this problem or already has it. Someone who knows more about Aruba can correct me if I'm wrong. -Brian
On 2/22/2012 10:07 AM, Fred Mowchan wrote: > Loved the comment on ATK, IPX, Neteui. Like Yogi Berra said "this is like deja vu all over again!" Yes, "routing" breaks traditional AT, IPX, NetBEUI, etc. So what clown woke up and said "Hey! Let's just multicast it, that's routable..." Jeff ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.

Aruba will be addressing the Bonjour issue in a future release. I heard it is going into beta soon. If I remember correctly, they will provide a way to "tunnel" the bonjour traffic to the AppleTV without routing and without allowing all broadcast and multicast traffic.

 

 

Tim Cappalli, CCNA ACMA | IT Services | (802) 626-6456

» tim.cappalli@lyndonstate.edu | it.lyndonstate.edu

 



PRIVACY & CONFIDENTIALITY NOTICE
This message is for the designated recipient only and may

contain privileged, confidential, or otherwise private
information. If you have received it in error, please notify
the sender immediately and delete the original. Any other
use of an email received in error is prohibited.

 

Message from ceyre@mtroyal.ca

Hey All, We are looking into a similar solution but I'm more concerned about what others have thought about the following. 1. Management of the apple tv's 2. security of the devices 3. Non apple devices connecting? 4. Would you hardwire or do wifi for the apple tv box itself? We have roughly 300 classrooms with projectors and that seems like a management nightmare, but maybe I'm missing all the peices. Regards, Craig Eyre Network Analyst IT Services Department Mount Royal University 4825 Mount Royal Gate SW Calgary AB T2P 3T5 P. 403.440.5199 E. ceyre@mtroyal.ca "The difference between a successful person and others is not a lack of strength, not a lack of knowledge, but rather in a lack of will." Vincent T. Lombardi From: "Cappalli, Tim G @ LSC-ITS" To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Date: 02/22/2012 08:38 AM Subject: Re: [WIRELESS-LAN] You knew it was coming...Airplay/Apple TV support for instructors. Sent by: The EDUCAUSE Wireless Issues Constituent Group Listserv Aruba will be addressing the Bonjour issue in a future release. I heard it is going into beta soon. If I remember correctly, they will provide a way to "tunnel" the bonjour traffic to the AppleTV without routing and without allowing all broadcast and multicast traffic. Tim Cappalli, CCNA ACMA | IT Services | (802) 626-6456 » tim.cappalli@lyndonstate.edu | it.lyndonstate.edu (Embedded image moved to file: pic24778.jpg)Description: Description: T:\IT Staff\Lyndon ITS Logo Package\LyndonITS\LyndonITS_Md-emailsig.jpg PRIVACY & CONFIDENTIALITY NOTICE This message is for the designated recipient only and may contain privileged, confidential, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of an email received in error is prohibited.
Message from michael.goebel@wmich.edu

Has anyone actually tracked how much bandwidth/usage Bonjour coughs up across their wlan infrastructure? I haven't analyzed it, and while it could be bandwidth hungry, it appears to me that will be more with device to device. I'm playing devils advocate here, but is a 6 meg stream on an N access point both ways really going to be crunching anyone? I'd be worried about G yes, but N with a gig uplink? I do find it unnerving that all the bonjour devices are able to find each other and potentially create a lot of traffic, but 99.9% of the time I don't see anyone working any access point very hard. Mike Goebel Network Programmer Office of Information Technology Western Michigan University Phone: 269-387-0453 Email: michael.goebel@wmich.edu On 2/22/2012 10:18 AM, Kellogg, Brian D. wrote: > We will need Bonjour in order to allow faculty members to mirror their iPads/WhateverAppleProductElse to an AppleTV in a classroom for presentations wirelessly. Presently we block all mcast and bcast on our WLAN due to the channel use overhead this incurs (anywhere from 10% to 20%). We'll be moving to Aruba this summer where enabling bcast and mcast is not an all or nothing endeavor I believe. I think Aruba is integrating some stuff into their controller code to help with this problem or already has it. Someone who knows more about Aruba can correct me if I'm wrong. > > -Brian > >
To me, it's less about bandwidth than it is expectations that you'll change the network design to accommodate these things because some of the require all devices to be on the same class C subnet, don't do 1x for security, etc. -Lee
Message from michael.goebel@wmich.edu

I assumed with mDNS it didn't just hit it's local subnet. I've been on the nightmare side of getting Audio/Video stuff to talk over IP with hundreds of classrooms and that isn't a whole lot of fun either. Mike Goebel Network Programmer Office of Information Technology Western Michigan University Phone: 269-387-0453 Email: michael.goebel@wmich.edu On 2/22/2012 11:42 AM, Lee H Badman wrote: > To me, it's less about bandwidth than it is expectations that you'll change the network design to accommodate these things because some of the require all devices to be on the same class C subnet, don't do 1x for security, etc. > > > -Lee > > > > >
My concern isn't so much the bandwidth associated with active connections between these devices as it is the discovery process. All the bonjour enabled devices are constantly attempting to discover other such devices, most of which there's no value to the user in connecting to. If, like we do, you have large b-cast domains, that discovery traffic bogs down an 802.11n network and can cripple an a/g network. IP or FQDN access to these devices would allow clients to connect selectively to devices they need to use, while keeping the excessive discovery traffic of the network. Chuck Enfield Sr. Communications Engineer Telecommunications & Networking Services The Pennsylvania State University 110H, USB2, UP, PA 16802 ph: 814.863.8715 fx: 814.865-3988
So it's not just about the bandwidth. B'cast & M'cast use the lowest configured data rate of the AP - just like wireless management frames. This means that even for 300Mbps 802.11n network is reduced to 24Mbps or less. That also ties up airtime that could be given to faster clients as well, since transmitting data at a lower data rate consumes more time that transmitting data at a higher data rate. So even if it is a low bit-rate stream, it takes away more available bandwidth from other clients. Aruba has a method that takes b'cast & m'cast and converts it to higher speed unicast traffic to each client. This gives better results for about up to 12 clients on an AP/radio. >>-> Stan Brooks - CWNA/CWSP Emory University University Technology Services 404.727.0226 AIM/Y!/Twitter: WLANstan MSN: wlanstan@hotmail.com GoogleTalk: wlanstan@gmail.com
Yep Add to this the fact that if you enable mcast/bcast the vast majority of the traffic taking up that air time isn't of any use/worth; Bonjour ... SSDP. I'm thankful Aruba is addressing the issue, very, but unfortunately not surprised that Apple's solution thus far is to just deal with it. I honestly like Apple products and software, but they are not enterprise ready/worthy IMHO. Who am I to try and dissuade the emotional sea of consumer demand insisting enterprise adoption (interoperability anyone?). I asked the same Apple rep about running their server OS on VMware. I was not surprised by the answer; "sure, but only on our hardware". Lol, They kill me. -Brian Kellogg
Message from toivo@usf.edu

I assume this also correlates with the size of client subnets and your supported data rates. We're using /22s, so are a bit concerned.
Message from kohster@northwestern.edu

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed Feb 22 2012 09:24:46 Central Time, Jeff Kell wrote: > > Yes, "routing" breaks traditional AT, IPX, NetBEUI, etc. AppleTalk and IPX at least are totally routable protocols. :) - -- Julian Y. Koh Manager, Network Transport Telecommunications and Network Services Northwestern University PGP Public Key: -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAk9FUkwACgkQDlQHnMkeAWP/VgCfZiFj/jT2L7RcGdYE5wVkRfWb 6C0AoPMcsGfmyQiy3DbtGcOIEwnyXuLz =0Zuv -----END PGP SIGNATURE----- ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2/22/2012 3:38 PM, Julian Y Koh wrote: > On Wed Feb 22 2012 09:24:46 Central Time, Jeff Kell wrote: > > > Yes, "routing" breaks traditional AT, IPX, NetBEUI, etc. > > AppleTalk and IPX at least are totally routable protocols. :) Well, you and I know that, but the Appletalk and IPX people didn't necessarily know that... :) Jeff -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAk9FU0oACgkQiwXJq373XhZpEQCg9RhjrJXlwinLAofaT7Rjvh3U 7tUAnjuNM3UG93mnsVLR4bbATSiZv1xY =nO8G -----END PGP SIGNATURE----- ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
I haven't tracked it, but I'm blocking mcast in our dorms. I'm not tracking it, did see a noticeable performance increase after disabling it.  Not entirely sure if it was a decrease in the added traffic from all the discovery protocols though, as I also shut off 802.11b support and station to station traffic at the same time.

--
Heath Barnhart, CCNA
Network Administrator
Information Systems Services
Washburn University
Topeka, KS

On 2/22/2012 10:09 AM, Mike Goebel wrote:
Has anyone actually tracked how much bandwidth/usage Bonjour coughs up across their wlan infrastructure? I haven't analyzed it, and while it could be bandwidth hungry, it appears to me that will be more with device to device.

I'm playing devils advocate here, but is a 6 meg stream on an N access point both ways really going to be crunching anyone? I'd be worried about G yes, but N with a gig uplink?

I do find it unnerving that all the bonjour devices are able to find each other and potentially create a lot of traffic, but 99.9% of the time I don't see anyone working any access point very hard.

Mike Goebel
Network Programmer
Office of Information Technology
Western Michigan University
Phone: 269-387-0453
Email: michael.goebel@wmich.edu

On 2/22/2012 10:18 AM, Kellogg, Brian D. wrote:
We will need Bonjour in order to allow faculty members to mirror their iPads/WhateverAppleProductElse to an AppleTV in a classroom for presentations wirelessly.  Presently we block all mcast and bcast on our WLAN due to the channel use overhead this incurs (anywhere from 10% to 20%).  We'll be moving to Aruba this summer where enabling bcast and mcast is not an all or nothing endeavor I believe.  I think Aruba is integrating some stuff into their controller code to help with this problem or already has it.  Someone who knows more about Aruba can correct me if I'm wrong.

-Brian

It's my understanding, at least in the 7.x train of Cisco wireless, that multicast data is transmitted at the highest basic (required) rate. Management frames can also be set to use the highest basic rate and/or kept at the lowest basic rate. Of course, transmitting at the highest basic rate does require smaller cell sizes.
 
There is no client limit that I'm aware of, but even if it was 12 like Aruba, my cells are small enough that it would be rare to see that many clients on a single radio.
 
Cisco also introduced a new multicast optimization in 7.0.116, so when using VLAN pooling, you wind up with only a single multicast stream no matter how many VLANs are in the pool. This is a big plus if say you have 10 clients all on the same AP, but all in different VLANs. Instead of 10 copies (1 per VLAN) of the multicast stream going out over the air, there is only one that all clients listen to.
 
Jeff 

>>> On Wednesday, February 22, 2012 at 9:49 AM, in message <CB6A92F7.2586B%stan.brooks@emory.edu>, "Brooks, Stan" <stan.brooks@EMORY.EDU> wrote:
So it's not just about the bandwidth.  B'cast & M'cast use the lowest
configured data rate of the AP - just like wireless management frames.
This means that even for 300Mbps 802.11n network is reduced to 24Mbps or
less.  That also ties up airtime that could be given to faster clients as
well, since transmitting data at a lower data rate consumes more time that
transmitting data at a higher data rate.

So even if it is a low bit-rate stream, it takes away more available
bandwidth from other clients.

Aruba has a method that takes b'cast & m'cast and converts it to higher
speed unicast traffic to each client.  This gives better results for about
up to 12 clients on an AP/radio.

>>-> Stan Brooks - CWNA/CWSP
      Emory University
      University Technology Services
      404.727.0226
AIM/Y!/Twitter: WLANstan
           MSN: wlanstan@hotmail.com
    GoogleTalk: wlanstan@gmail.com



Message from jcoehoorn@york.edu

I just heard an interesting solution for this. Since AppleTV is already consumer tech and does not need Internet (their classroom use is pretty much just AirPlay), the person went out and bought a cheap $30 wireless router off the shelf at Walmart for each AppleTV. Each device is now on its own unrouted subnet, and bonjour can do what it wants in that space. Sent from my iPod
And a 35-50 mW noise maker sits among several low-power cells, where there is no such this as a "spare channel". Most WLAN policies cover RF and forbid this sort of thing... the wired network is part of the issue, competing wireless is another. -Lee -----Original Message----- From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Joel Coehoorn Sent: Wednesday, February 22, 2012 9:21 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] You knew it was coming...Airplay/Apple TV support for instructors. I just heard an interesting solution for this. Since AppleTV is already consumer tech and does not need Internet (their classroom use is pretty much just AirPlay), the person went out and bought a cheap $30 wireless router off the shelf at Walmart for each AppleTV. Each device is now on its own unrouted subnet, and bonjour can do what it wants in that space. Sent from my iPod
On 2/22/2012 9:21 PM, Joel Coehoorn wrote:
> > I just heard an interesting solution for this. Since AppleTV is already consumer tech and does not need Internet (their classroom use is pretty much just AirPlay), the person went out and bought a cheap $30 wireless router off the shelf at Walmart for each AppleTV. Each device is now on its own unrouted subnet, and bonjour can do what it wants in that space.

We considered that, but one or both of them (TV or instructor device) is going to want "internet too" but can only connect to one SSID, and you're adding to the unmanaged RF interference in a potentially noisy area already.

Jeff

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

Message from ceyre@mtroyal.ca

One of the scenarios I've been looking at is streaming/mirroring directly to the video projector and bypass buying another device. I'm not sure if people are asking to connect the appleTV to a projector or TV. Most projectors these days come with wired/wireless NICs built into them and you may be able to leverage that in some way. Take NEC for example (thats what we have) they have an image capture utility that can be installed on a PC or MAC and it completely mirrors the desktop of the device. So you could wire/wireless connect the projector and have your laptop on wifi and mirror your desktop. The NEC projectors support the latest enterprise authentication and encryption which is good as most of the other 3rd party steaming boxes only support personal authentication. This doesn't fix the whole ipad/tablet world but there are some apps out there like mobishow that could prove useful in getting these devices connected in a classroom environment. AppleTV only solves 1/2 the users concerns in my world and I know for a fact that if someone with another brand of tablet sees appletv, they'll want another solution. From what I've heard, most people want desktop mirroring to a tv/projector not just streaming. This is just some thoughts/notes from some preliminary testing. Regards, Craig Eyre Network Analyst IT Services Department Mount Royal University 4825 Mount Royal Gate SW Calgary AB T2P 3T5 P. 403.440.5199 E. ceyre@mtroyal.ca "The difference between a successful person and others is not a lack of strength, not a lack of knowledge, but rather in a lack of will." Vincent T. Lombardi From: Jeff Kell To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Date: 02/22/2012 07:29 PM Subject: Re: [WIRELESS-LAN] You knew it was coming...Airplay/Apple TV support for instructors. Sent by: The EDUCAUSE Wireless Issues Constituent Group Listserv On 2/22/2012 9:21 PM, Joel Coehoorn wrote: > > I just heard an interesting solution for this. Since AppleTV is already consumer tech and does not need Internet (their classroom use is pretty much just AirPlay), the person went out and bought a cheap $30 wireless router off the shelf at Walmart for each AppleTV. Each device is now on its own unrouted subnet, and bonjour can do what it wants in that space. We considered that, but one or both of them (TV or instructor device) is going to want "internet too" but can only connect to one SSID, and you're adding to the unmanaged RF interference in a potentially noisy area already. Jeff ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/. __________________________________________________________________________ This communication is intended for the use of the recipient to which it is addressed, and may contain confidential, personal, and or privileged information. Please contact the sender immediately if you are not the intended recipient of this communication, and do not copy, distribute, or take action relying on it. Any communication received in error, or subsequent reply, should be deleted or destroyed. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
Message from bosborne@liberty.edu

Where did you get that 12 client number?? At Liberty University, we have successfully had 20 students per AP with 5Mbit streams. In a Lab test situation, we had 30 clients all streaming on one AP-125 access point. Multicast on 802.11 uses the lowest rate which is 6Mbit for 5GHz networks. That is why Aruba developed their multicast technology. We have been using it since it was introduced. Bruce Osborne Network Engineer IT Network Services   (434) 592-4229   LIBERTY UNIVERSITY 40 Years of Training Champions for Christ: 1971-2011
Bruce - I was thinking of your installation when I responded as I was aware of your work with with Aruba to optimize b'cast/m'cast and converting b'cast/m'cast to unicast at the AP. I got the 12 client tradeoff point from something I remember for an Aruba AirHeads conference a couple of years ago. Granted, my memory may be fading, but I remember one of their engineers state that it is effective to do the conversion to unicast per client for up to ~12 clients, and after that, it's better to keep the packets m'cast. Sorry if I mis-spoke on the technology. >>-> Stan Brooks - CWNA/CWSP Emory University University Technology Services 404.727.0226 AIM/Y!/Twitter: WLANstan MSN: wlanstan@hotmail.com GoogleTalk: wlanstan@gmail.com
Message from wthompson@babson.edu

I would request a point of clarification: "20 students"? Or "20 devices"? As others have observed, everyone is carrying more AP-interested gear, thus 20 students could actually correspond to 40-60 devices. No longer a one-student-one-device world. Would it be correct to infer "20 devices"?