From: Marvin Greenlee (marvingreenlee@yahoo.com)
Date: Thu Jun 17 2004 - 10:38:55 GMT-3
Whether it uses the 'extra pair' or the 'same pair'
depends on if you are using a power patch panel or a
switch that provides power.
Understanding the Cisco IP Phone 10/100 Ethernet
In-Line Power Detection Algorithm
http://www.cisco.com/en/US/products/hw/phones/ps379/products_tech_note09186a00801189b5.shtml
"...The following method for detecting that a Cisco IP
Phone is connected to a 10/100 Ethernet port is used
by the Cisco Catalyst 6000, Cisco Catalyst 4000, and
Cisco Catalyst 3524-PWR-XL Switches.
The port starts the phone-discovery algorithm by
sending a special Fast Link Pulse (FLP) signal to any
device that might be connected to it.
The port waits to see if the special FLP signal is
forwarded back by a connected device. The only devices
that are designed to do this are devices that expect
to receive in-line power.
If a Cisco 79xx IP Phone is connected to the 10/100
Ethernet port, it will forward the special FLP signal
back to the 10/100 Ethernet port on the Cisco Catalyst
switch. It is capable of doing this because it has a
special relay that connects its Ethernet receive pair
with its Ethernet transmit pair. This relay is closed
when no power is being supplied to the phone. Once
power is supplied, this relay remains in an open
state.
Now that the Cisco Catalyst switch has determined that
it needs to power the port (the special FLP signal was
received back from the attached Cisco IP Phone), the
Network Management Processor (NMP) is queried to
determine if there is any power available to power the
IP phone. Since the NMP does not know how much power
the Cisco IP Phone will need, it uses the configured
default power allocation. Later on it will adjust this
allocation based on what the attached Cisco IP Phone
tells the switch it really needs.
The port then provides power to the Cisco IP Phone
over pairs 1 and 2 as a common mode current.
The port is taken out of phone-discovery mode and
changed to normal 10/100 Ethernet auto-negotiation
mode.
The instant that the switch applies power to the port,
the relay inside the phone opens and power begins to
flow to the Cisco IP Phone.
At this point a 'wait for link' timer in the switch
starts also. The phone has five seconds to establish
link integrity on its Ethernet port. If the switch
does not detect link integrity on the port within five
seconds, it will shut off power to the port and start
the phone-discovery process all over again. The switch
has to wait at least five seconds so that the switch
has enough time to detect all devices.
If the switch detects a link within the five second
window, it will continue to supply power to the Cisco
IP Phone until it detects a link down event.
Once the phone has booted up, it will send a CDP
message with a Type, Length, Value object (TLV) that
tells the switch how much power it really needs. The
NMP sees this and adjusts the power allocation for the
port accordingly..."
*****Inline Power Patch Panel*****
"...The In-line Power Patch Panel (IPPP) uses the
unused Ethernet pairs to provide in-line power. The
IPPP has four rows of RJ-45 connectors each with 24
ports in a row. The top two rows are the powered ports
used to connect to the end device (for example, a
Cisco 79xx IP Phone). The bottom two rows are used to
connect to the switch which will be providing the
Ethernet connectivity.
Internally, the IPPP will directly connect the
Ethernet pairs from the bottom switch port to the
corresponding phone port on the top. The in-line power
patch panel does not interfere with pins 1, 2, 3, and
6 in any way. It does not monitor link and does not
care about speed/duplex, because it is completely
passive..."
Marvin Greenlee
Network Learning, Inc.
marvin@ccbootcamp.com
--- Noble <noble@inserviceindia.com> wrote:
> Just a clarification, power is not using the extra
> pair...it uses the same
> pair.
>
> Thanks!!!
>
> Noble
__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail
This archive was generated by hypermail 2.1.4 : Sat Jul 03 2004 - 19:40:43 GMT-3