Setting UCCX to 1000 full

[Sean McQuade]

Hi all,

I am using UCCX in HA connected to a 2960S Gigabit switch stack. The ports on the switch and on the UCCX are set to 100 Full. We have been suffering some performance issues with call mintoring and recording when using span ports so it has been suggested that we change the port speed to the full 1000.

I have accessed the CLI of the UCCX and see the following:

set network nic eth0 param [value]

param   mandatory   auto, speed, duplex

value   mandatory   for auto  : [en/dis]

                    for speed : [10/100]

                    for duplex: [half/full]

NOTE: 1000BASE-T can only be enabled via auto-negotiation

Does this mean that if I use the command "set network nic eth0 param auto" on the UCCX and set the switchport to speed auto, duplex auto that it should negotiate to the higher speed of 1000 full?

Best regards

Sean

[Anthony Holloway · Accepted solution]

Yes, you are reading that correctly.  You didn't mention what your UCCX server hardware is.  MCS?  Which one?

Auto/Auto should be the ideal configuration for gig anyway.

Also, are you spanning to the second NIC or the primary NIC?

Anthony Holloway

Please use the star ratings to help drive great content to the top of searches.

[Sean McQuade]

Hi Anthony,

The servers are MCS7825. All phones and servers are on VLAN 200 and the UCCX servers are connected to the switch via GI1/0/1 and GI2/0/1 so the way I have configured the spanning is:

monitor session 1 source vlan 200

monitor session 1 destination inter gi1/0/1 ingress vlan 200

monitor session 1 destination inter gi2/0/1 ingress vlan 200

Call quality is fine, but when attempting to monitor a call from CSD, it is garbled and very poor quality.

[Anthony Holloway]

You wouldn't want to send the RTP to both NICs.  Only the second NIC.  If you look in your postinstall.exe you should have a monitoring NIC/Adapter defined, and it should be that second NIC only.  This NIC should NOT have a routeable IP Address on it.  Something like 1.2.3.4 is preferred.

Anthony Holloway

Please use the star ratings to help drive great content to the top of searches.

[Sean McQuade]

Anthony, the two destinations above are NICs on different UCCX servers.

UCCX1 is 10.1.1.250

UCCX2 is 10.1.1.249

Both are span destinations and monitorting VLAN 200.

Then under desktop administration, I have set the monitoring server to 10.1.1.250 and disabled the desktop monitoring, as per TAC instructions. Are you saying I should have configured this differently?

Thanks

Sean

[Anthony Holloway]

Sorry, I missed the part where you have HA, and assumed you had two destinations for both NICs on one UCCX.

The only piece I would add for you, is to use the second NIC on each server as th SPAN port, with a non-routable IP addresses on each.

It's been ages (ok, like 3 years) since I deployed/troubleshot SPAN based recording/monitoring.

Anthony Holloway

Please use the star ratings to help drive great content to the top of searches.

[Sean McQuade]

Just to clarify, can I use one interface with the 10.1.1.250 address  and put 2.3.4.5 on the other interface. Then have the 2.3.4.5 interface  doing the monitoring, and have the clients connect to the 10.1.1.250 for  the monitoring service?

[Anthony Holloway · Accepted solution]

Correct.  You will need to restart the recording/monitoring service after the change though.

A helpful document you should read:

http://www.cisco.com/en/US/docs/voice_ip_comm/cust_contact/contact_center/cad_enterprise/non_release_docs/voip-mon-troubleshooting.pdf

A passage from that document:

The VoIP Monitor service explicitly specifies what NIC adapter to use for capturing audio packets, but it does not specify which NIC should be used when sending out packets. These outgoing packets would be going to either the Cisco Recording & Playback Service or a supervisor’s desktop that is live-monitoring an agent’s call. This is not a problem when using a single NIC for both sniffing and normal traffic. With two NICs, however, normal traffic should be restricted so that it does not go through the NIC used for sniffing. Otherwise, the sniffed RTP steams of a currently-monitored call might not reach the supervisor because the SPAN destination port does not allow outgoing traffic.
To resolve this, use the route command to customize the static routing tables so that normal traffic does not go through the sniffing NIC. Contact your network administrators for details.
An alternative solution is to give the sniffing NIC and IP address that no other host on the network uses, and a subnet mask of 255.255.255.0. Leave the default gateway field blank for this NIC’s TCP/IP binding.
In addition to these steps, the NIC that is used by the VoIP Monitor service must not be the first NIC in the network binding order. By default, the first NIC adapter in the binding order will be used by applications to send traffic out to the network. Contact your network administrator for details.

Anthony Holloway

Please use the star ratings to help drive great content to the top of searches.

[Sean McQuade]

Thanks for your help on this Anthony