Telephone Jones and the Bridge to Nowhere

Today started like any normal Monday looking at the random tickets from over the weekend.  Then I decided to work on installing a new phone for our new IT team member.  Keep in mind that I am still supporting an ancient (that's being nice) Rolm/Siemens 9006i CBX (Computer Branch eXchange) for a phone system.  So unlike my lucky colleagues in the IP Telephony realm, a new phone is still a production number when it comes to layer 1.

For those not familiar with traditional phone systems, you have to have a copper path from the phone to the port on the phone system.  There are no intermediate switches like on the network side.  These paths are created using jumper wires between phone blocks like shown to the left.  As you can see, there is not much room for labeling.  To add insult to injury, through use, even with permanent markers, the labels tend to fade or disappear completely.  Of course this is why every telephony engineer carries a toner set and knows how to use it.

Today's adventure started at the user's cubical.  There were four telephone jacks labeled 22 A, 22 B, 22 C, and 22 D.  Generally when the jacks all have the same number and just a different letter, it is one 8 conductor (CAT5/CAT5e/CAT6) cable that has been split across four jacks.  Usually A represents the blue/white pair, B the orange/white pair, C the green/white pair and D the brown/white pair.  In my case the port labeled B was available so I plugged in my toner and ran off to the IDF to find the other end.

This is where it got fun.  Normally when toning out a cable, you will find one place on the other end that you hear the tone.  That being said, when I heard tone (keep in mind the labels had worn off) I assumed I was on the right cable.  I punched down my jumper from the phone system to the orange/white pair and went back to the cubical to check the phone.  Nothing.  The phone was as dead as it was before I plugged it in.

Thinking that maybe the B pair was damaged, I hooked the toner up to the D pair and repeated the process.  So this time though I found the tone on a different orange/white pair.  Remember when I said that D should go to brown/white?  Well at this point I got puzzled.

In my environment it is common for lines to have been abandoned without removing the old jumpers.  This turned out to be the case this time.  As I continued my troubleshooting I found the tone in 7 different places on the 66 block.  I noticed that there was a jumper cable on all of the terminals that had tone.  After following the jumper I found that all 7 locations were bridged for an old modem or fax line.

The solution to my problem was to remove the bridging jumper and voila my tones worked right and I was able to get my phone setup.  Unfortunately this whole process took 3 hours with interspersed other morning fires in the mix.

Hello? ¿Hola? No, Bonjour!

Last fall I helped a local school district install a Cisco wireless network consisting of 1142n APs and a 5508 controller.  All was working well until recently when one of their techs received the district's first AppleTV.

Of course my first question was what VLAN(s) the AppleTV and the iOS device were connected.  That was the first problem which was easily fixed by placing them on the same VLAN.  The next problem is how Apple's devices find other devices on the same layer 2 network.  Apple uses Multicast DNS (mDNS), which they call Bonjour, to locate devices.  Every device on a subnet advertises its capabilities to the multicast address 224.0.0.251.  By default these advertisements are set to have a Time To Live (TTL) of 1 which prevents them from crossing routed boundaries even if multicast routing is configured on the network.

It was easy enough to put the AppleTV onto the same wireless VLAN as the user devices so we didn't have to come up with a solution for that.  To get the two devices talking is actually quite simple.  By default Cisco WLCs have multicast disabled.  This of course prevents Bonjour's discovery process from functioning.  Enabling multicast is done under the Controller tab of the WLC web page.  There are three options, disabled, unicast and multicast.

You might wonder how you can have unicast multicast, but it's not a contradiction in terms.  Because of the way traffic is tunneled from the APs to the controller, the multicast traffic is actually sent to the APs using CAPWAP unicast packets.  If you switch to multicast multicast mode and the switches are properly configured, the CAPWAP packets containing the wireless multicast traffic is only sent to APs that have joined the multicast CAPWAP group.  In a larger environment this can cut down on the amount of traffic sent as well as eliminate traffic going to APs that don't need the packets.

Most of the major networking vendors have released or are planning to release solutions to the problems Bonjour faces in the enterprise network.  In addition there have been petitions online to Apple  for them to make their products work better in enterprise networks.  Hopefully soon these challenges will be a thing of the past and Apple products will "just work" at home and in the office.