These are some of my notes on my IIUC studies.  Since I am a novice as voice stuff, please let me know what I get wrong.

An ephone is a representation of a phone.  It’s basically a structure of features that a phone will have. 

Configuration in CME:

R1(config)#ephone 34  <– This is just a tag and has nothing to do with an extension or phone
R1(config-ephone)#mac-address 1111.2222.3333    <– Assigns this ephone to the phone with that MAC address

Feel free to correct anything that is wrong or incomplete.

• Power over Ethernet (PoE)

  • Can provide power to a Cisco phone, access point, security camera, etc., through the network cabling, eliminating the need to plug the phone into the wall for power.
  • Generic term for providing power on the Ethernet cable
  • Provides centralized power that can be put on a UPS
  • Allows devices to be located away from power outlets
  • Removes cabling clutter at the user’s desk
  • Can be provided through PoE-enabled switches, power panels or inline couplers (power injectors)
  • Oversubscription is common
    • If every device on a switch asks for full power, the switch may not be able to handle the load.
  • Of course, devices can be powered with a power brick at the desk

• 802.3af

Feel free to correct.  No need to sugar-coat it; I’m pretty new at this stuff.  :)

• Advantages of VoIP

  • Reduces costs of communications:  Eliminates/reduces long distance and international call tolls
  • Reduces costs of cabling:  No need for second network of phone lines
  • Integrates all voice into one large network:  All your remote offices can be implemented/maintained/controlled centrally
  • Provides mobility:  Moves, adds, and changes (MACs) are (nearly) eliminated since your phone is just a network node
  • Allows use of IP Softphones
  • Unifies emails, voice mails, and faxes:  All these can be treated as a single box for user messages
  • Increases productivity:  Ringing multiple devices at the same time eliminates phone tag.   <— pushing it, eh?
  • Enhances communications:  Applications can be launched/updated from a voice call through application servers
  • Provides open, compatible standards:  You can connect different vendor devices into the same VoIP network.   <— I’ve never seen that happen

• Cisco VoIP Structure

I’m way behind in talking about this, but Jeremy Stretch over at Packetlife.net has a community lab that is free to use.  This is a great resource for those of us who are too poor to have their own physical devices for Cisco studies.  All you need is an account on the site and a sense of community.

There are two labs to reserve, and each contains a firewall, routers, and switches.  This is plenty of stuff to get your feet wet with the gear, let you research some functionality that Cisco promised is great, and to lab out something you’re looking to implement.  The lab is offered for free, but Jeremy is giving his time and money for this lab.  I think it would be a great idea to drop a few dollars to him via his donate link if you use his stuff.   If you’re a regular user and don’t donate, I ask that you do a moral inventory on yourself so you might see just how bad you are being.

I’ve done it.  You’ve done it.  We’ve all done it.  You turn up another EtherChannel bundle and realize the hard way that your interface descriptions aren’t accurate.  Or you’ve swapped out a piece-of-crap 3750 and didn’t notice that the labels on the cables were wrong.  In either case, we all know that EtherChannel bundles don’t really work if the links aren’t plugged into the right switches.

So, what do you to make sure that your links are cabled the way you think they are?  Personally, I don’t trust any label at all - no matter if I did it or not.  At some point, someone has changed something on a switch, and that just might have been a change to where the port is question is cabled.  If I was onsite, I would hand-trace the cabling from one end to the other then do it again to make sure I didn’t hose it up the first time.  The big problem with this technique is that I’m not everywhere at the same time, and the travel budget isn’t very big these days.  If I can’t get my hands on the cables, I relegate myself to using CDP to see what’s on the other end of links when putting ports into EtherChannel bundles.

I was thinking about firing off some GNS3 labs as exercises for everyone to use.  My thought was that I could generate a few small networks with a requirements doc and have people do the leg work as practice or for a study aid.  You know, configure OSPF over this frame relay network or GLBP for load-balancing gateways.  I gave up on that dream (like I do a lot of them), and wound up clicking around on GNS3 Vault.  Rene Molenaar has already thought ahead and developed about 60 labs exercises that can be downloaded.

These are the notes I’ve taken as I read through the study materials.  Feel free to correct anything you see.

• Analog phone signaling

  • Misc
    • Ground = positive = tip
    • Battery = negative = ring
    • Signaling uses specific frequencies for specific events
  • Loop start signaling
    • When a circuit in the phone is completed (i.e., you take it off-hook), the CO detects it and provides services.
    • Susceptible to glare, where the phone requests dialtone at the same time that the CO sends a call.
      • Can connect two different calls if in a business with multiple lines
  • Ground start signaling
    • The circuit is temporarily completed to signal the CO for services
    • Doesn’t connect any call to any phone directly
    • Used in PBXes.
  • Supervisory signaling
    • On-hook:  Circuit is open
    • Off-hook:  Circuit is completed
    • Ringing:  AC current generated by CO to tell the phone to ring
  • Informational signaling
    • Gives information for the caller to use
    • Dial tone
    • Busy
    • Ringback: the ring you hear when you call
    • Confirmation:  the call is being attempted
    • Congestion:  no lines available to make the call
    • Receiver off-hook
    • Reorder:  can’t make the call
    • No such number:  can’t find the endpoint
  • Address signaling
    • Used to send digits
    • Dual-tone multifrequency (DTMF):  uses two electrical signals to indicate a digit; touch tone
    • Pulse:  flashes the circuit to indicate a digit; rotary dial
  • Disadvantages of analog signaling
    • Attenuation
    • Repeaters can’t differentiate between call and noise
    • One cable pair for each call; think about a pair for each call taking place in Manhattan right now

• Digitizing voice

I posed the philosophical question on Twitter the other day asking if single trunk links should be in an EtherChannel bundle just in case you need to expand later.  I didn’t really expect an answer, but the ever-verbose @WannabeCCIE pointed out (in not so many words) that you should watch your IDBs.  What is that?

That’s an interface descriptor block.  I admit that I’m not intimately familiar with them, bu they’re data structs in IOS used to keep track of the interfaces on that device.  They come in two flavors - hardware and software.  HWIDBs usually represent a physical interface but they also represent tunnels, SVIs, PortChannels, subinterfaces, and any other virtual interface that you can configure.  The SWIDBs represent the layer-2 encapsulation of each HWIDB, so you’ll see entries talking about Ethernet, HDLC, PPP, etc.  That means that every interface you have on a router consumes two IDBs (there are always exceptions).  That’s important because each platform and IOS version combination has a limit to the number IDBs that device supports.

Last week, @fletcherjoyce posted an article on his blog about his positive experiences with Cisco’s 3750 switches.  If you follow my complaints tweets, you know that I’ve had quite the opposite experience with them.  I would never pick on anyone, but I had to throw in my 2 cents.

I’m guessing here, but we have about 50 3750 stacks in the enterprise.  Most of them are pairs, you wind up with roughly 120 switches.  Since we’ve done about 20 replacements over the last 5 years, that means we have a 17% failure rate.  That’s pretty horrible, isn’t it?

Another year of Aaron’s Worthless Words has come and gone.  This month marks the third full year of blog posts for me, and things sure have changed since the beginning.

At first, this blog was just for my personal rants, but no one cares about that stuff (thus the title), so I looked to move on to something else.  I decided that I would go into the non-technical side of the network field, so I started talking about the Principle of Least Privilege and about cabling standards.  That got a bit boring, so I started puking out information on the Content Switching Module from Cisco since I couldn’t find anything worth a cracker outside of the documentation.  That was a hit, and the topics started expanding and expanding until we got to where we are now.  Today, the articles are published in online magazine and are being translated into other languages around the world.  Quite a change from complaining about drivers stopping in the crosswalk.  :)