Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Good Day Friends - need Cisco VoIP Network best practices please 2

Status
Not open for further replies.

reelbigfish

IS-IT--Management
Aug 1, 2008
80
US
Hello - would someone be so kind to point us in the right dirction? We are looking for Cisco's best practices when configuring Cisco switch ports to Cisco VoIP phones to client PC. Cisco 3750 switch--->Cisco 7960 phone--->Client PC. We are interested in all considerations - QoS, Duplex settings, phone stettings, client PC settings and etc. The problem is the environement runs slow for the client PCs and we seems to be uncertain on the formentioned. Things work well for the client PCs when they are at 100 full on both the switch and PC, but as soon as a phone is in place things slow down and packet loss is happening.


We will also appreciate the same information for WANs too.
 
Here is a example of how I most of the time configure the switch ports with auto QOS. But I have to say these are fairly small environments (around max. 100 users). But none the less it does it job without any trouble.

interface FastEthernet0/1
description ***User Access port***
switchport mode access
switchport voice vlan 200
srr-queue bandwidth share 10 10 60 20
priority-queue out
mls qos trust device cisco-phone
mls qos trust cos
auto qos voip cisco-phone
spanning-tree portfast
service-policy input AutoQoS-Police-CiscoPhone
 
Thanks - the PC behind the phone seems to get it's packtes requeued, as a result we have latency for the PC user. Could it a a Duplex/Full-Duplex thing?

What is the QOS command to extend the QoS trust to the PC port on the phone?
 
Unless you are having network congestion your slowness is not because of the QoS commands. either way trusting the PC port would defeat all purpose of QoS.
Go into one of the phones and look into the switch ports and the PC port and see if they are running in half-duplex to the pc.
If it is change it from auto to 100/full and hardcode that.

I have seen that on older phones but it's been a long time and it was with 6500 switches.
What does the 3750 tell you the ports are running? Any collisions or duplex mismatches?

Are you running a new code on the 3750 and is the firmware on the phones updated?
 
Thanks whkap - I'll check it out and let you know. Thanks
 
IDF06-2# show version
Cisco IOS Software, C3750 Software (C3750-IPSERVICES-M), Version 12.2(35)SE5, RELEASE SOFTWARE (fc1)

IDF06-2#show int fa1/0/6
FastEthernet1/0/6 is up, line protocol is up (connected)
Hardware is Fast Ethernet, address is 0011.bbe5.6a88 (bia 0011.bbe5.6a88)
Description: IP Phones and PCs
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 100Mb/s, media type is 10/100BaseTX
input flow-control is off, output flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:59, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 6000 bits/sec, 9 packets/sec
59262230 packets input, 12298166094 bytes, 0 no buffer
Received 1094673 broadcasts (0 multicasts)
0 runts, 0 giants, 0 throttles
4 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 898634 multicast, 0 pause input
0 input packets with dribble condition detected
3415796632 packets output, 448251951045 bytes, 0 underruns
0 output errors, 641 collisions, 3 interface resets
0 babbles, 4741 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 PAUSE output
0 output buffer failures, 0 output buffers swapped out

Cisco Phone-
MAC Address 001200681E18
Host Name SEP001200681E18
Phone DN 25966
App Load ID Jar70sccp.8-3-0-50.sbn
Boot Load ID 7970_64060118.bin
Version SCCP70.8-3-1S
Expansion Module 1
Expansion Module 2
Hardware Revision 1.1
Serial Number INM083512Y7
Model Number CP-7970G
Message Waiting No
UDI phone
Cisco IP Phone 7970G, Global
CP-7970G
 
I'm not exactly the top troubleshooter, but I noticed the high late collision number and googled it for you.

This is what it says (take a good look at the 2nd part):

Late Collision in computer networking is a type of collision found in the CSMA/CD protocol standard. If a collision error occurs after the first 512 bit times of data are transmitted by the transmitting station[1], a late collision is said to have occurred. Importantly, late collisions are not re-sent by the NIC unlike collisions occurring before the first 64 octets; it is left for the upper layers of the protocol stack to determine that there was loss of data.

As a correctly set up CSMA/CD network link should not have late collisions, the usual possible causes are full-duplex/half-duplex mismatch, exceeded Ethernet cable length limits, or defective hardware such as incorrect cabling, non-compliant number of hubs in the network, or a bad NIC.
 

interface FastEthernet1/0/6
description IP Phones and PCs
switchport trunk encapsulation dot1q
switchport trunk native vlan 103
switchport trunk allowed vlan 12,102,103
switchport mode trunk
switchport voice vlan 12
mls qos trust device cisco-phone
mls qos trust cos
no mdix auto
spanning-tree portfast
 
so did you check your ports on the phone itself for connectivity and make sure the pc and the phone are connected at 100 full and not half?
 
At this point eveything is set to auto and we still get segment re-queueing. we plan to set everything to 100full for a test. Thanks
 
With everthing at 100 full we get much better through-put. However we still see some packet re-queueing. We plan on updating the firmware on the phones. any other ideas?
 
have you tried setting the PC port on the phone to 100-full from auto as i suggested earlier?
 
yes - it's better but we still get some packet requeue. Thanks
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top