cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements

2941
Views
24
Helpful
12
Replies
lohjintiam
Enthusiast

UCCX v8: Is NIC teaming supported?

Hi all,

How can i achieve/setup NIC teaming in UCCX v8?

Thanks!

-JT-

12 REPLIES 12
Amer rajai Sha'er
Rising star

Hello,

Cisco Unified CCX does not support Interface Bonding (NIC teaming).

Check the below , page 11

http://www.cisco.com/en/US/docs/voice_ip_comm/cust_contact/contact_center/crs/express_8_0/installation/guide/uccx801ig.pdf

Amer

Is it because of how licensing works in UCCX? What other methods can be used to achieve some level of network redundancy?

-JT-

Hello,

No i don't think so , i guess it is becuase of the VOS platform .

As for network redundancy , i don't think there is a way to do it , the best thing is to buy the HA license with additional license especially that UCCX 8.0 is now supported to be over the WAN (one server in every location).

Amer

Have you actually tried it? If memory serves, it works fine, I'm 90% confident I've set it up for a customer recently. UCCX 8.0 has the same underlying Cisco VOS (modified RedHat Linux) platform as all the other Cisco UC applications, and should support the same NIC configuration. The only thing special about UCCX is that you might need that second interface for server-based SPAN recording and silent monitoring, but most installs aren't using that method anymore, they're using CAD client-side capture or WFO QM or another solution.

To be clear, we're talking about redundancy for failover, not load balancing.  None of the Cisco VOS platforms support bonding interfaces for higher  bandwidth, only switching back and forth to recover from failures. This  is commonly known as Network Fault Tolerance, as opposed to bonding or  Etherchannel.

Try using 'set network failover' from the SSH/console CLI. Check the CUCM platform CLI reference for more info. There's a CLI reference for UCCX, but it mainly only documents the UCCX differences from the CUCM CLI.

Robert W. Rogier
Cisco Employee

Hello JT,

   I work for Cisco TAC on the UCCX product line.  The NIC teaming on the UCCX platform is definitely not supported.  The command is there because it share a common platform with the other VOS products, but it is explicitly not supported per page 10 of the guide "Installing Contact Center Express Release 8.0(x)" (uccx801ig.pdf) on the Cisco Support site.  I don't have firm guidance from the developers on why this feature is just not supported, but it definitely is not.  Also, be aware that if you enable teaming and then call in for support to Cisco TAC, you will need to break the team before continuing with most support sessions.  I can definitely tell you from experience that anything that TAC escalates to the developers will get sent back if teaming is configured.  The servers need to be in a "fully supported state" per the install guide, SRND, and admin guides.

  Maybe I can make a little sense of why we don't support this.  In the UCCX world, there shouldn't be a single point of failure.  We generally recommend that this platform be installed in an HA configuration with 1 "Master" and 1 "Subordiate" node.  During normal operations, all services should be equally active on each node.  However, if a failure occurs on the primary or the "Master" node, then the services will automatically switch to node 2.  This will cause up to a 5 minute outage in call center operations, you will loose calls in queue and agents will need to close CAD and login most of the time, but an agent actively on a call won't lose that call.  The key here is that Cisco is putting the emphasis on survivability of answered/handled calls and will hope that those waiting in queue will just call back.  While this isn't a perfect solution, it doesn't require the minimum of 6 servers to get the UCC Enterprise platform installed even for a small installation (and using 5 means you're combining services which really shouldn't be and is likely going to introduce other points of failure.)  The UCCE product also has a much higher price tag for that level of redundancy; but I feel that pretty much every business will know when they are at "that point" where loss of customers in queue and 5 minutes of outage during a day is a higher cost than that to purchase, design, implement, and MAINTAIN (with trained people) the UCCE product.  Please let me know if you have other questions or want any further recommendations on what you might look at for systems survivability. 

  I think at the end of the day, too many engineers are focused on the LAN/WAN model where we always bought 2 and configured HSRP, VRRP, BGP, etc to have total redundancy.  In the server/software realm (which is really what UCC is) you should be monitoring your overall server health and be able to predict failures.  You obviously won't prevent the tornados, hurricanes, fires, and thefts, but really, that's not what NIC teaming would buy you anyway.  If you instead shift focus to watching the physical components of the server, do simple SNMP traps and SYSLOG messages, that will get you going in the right direction.  The key is you have to READ what you are sending out.  If you have a nice server full of SNMP and SYSLOG so that Tuesday afternoon you can tell everyone what was failing on Friday that wasn't caught, that's not as good as having a report each day and email/pager alerts on critical items to see what's about to break and then move the "Master" to node 2 gracefully, afterhours when no one notices and just repair the main issue.   I could write a whole book on this, but I'll stop here as I think I've answered the original question as thoroughly as possible.

Regards,

Robert W. Rogier

Robert W. Rogier
Technical Consulting Engineer – Contact Center Enterprise
E2E Lead | Subject Matter Expert – ECE, CCMP, CCDM
Phone: +1 919 574 5993
Email: rorogier@cisco.com
Business Hours: 8AM to 5PM ET

Robert,

Interesting information. I hadn't noticed that part of the installation guide.

I have one particular customer, with NFT definitely enabled (just checked) which TAC has been in half a dozen times, and DE at least two of those times if not three. Nobody's said a single word about NFT. None of the concerns were network related. I'd be curious to hear more about why DE says it's unsupported. The only things I can think of are timing interactions between NFT failover and LAN clustering, or issues with SPAN recording.

If DE's position is that you can't use NFT on UCCX, then it's a plain and simple bug to allow it. Different Cisco VOS platforms add and drop all sorts of commands from the platform CLI, they can do it for NFT. Is there a bug ID?

Following up to the stuff you added to your post...

  Maybe I can make a little sense of why we don't support this.  In the UCCX world, there shouldn't be a single point of failure.  We generally recommend that this platform be installed in an HA configuration with 1 "Master" and 1 "Subordiate" node.  During normal operations, all services should be equally active on each node.  However, if a failure occurs on the primary or the "Master" node, then the services will automatically switch to node 2.  This will cause up to a 5 minute outage in call center operations, you will loose calls in queue and agents will need to close CAD and login most of the time, but an agent actively on a call won't lose that call.  The key here is that Cisco is putting the emphasis on survivability of answered/handled calls and will hope that those waiting in queue will just call back.  While this isn't a perfect solution, it doesn't require the minimum of 6 servers to get the UCC Enterprise platform installed even for a small installation (and using 5 means you're combining services which really shouldn't be and is likely going to introduce other points of failure.)  The UCCE product also has a much higher price tag for that level of redundancy; but I feel that pretty much every business will know when they are at "that point" where loss of customers in queue and 5 minutes of outage during a day is a higher cost than that to purchase, design, implement, and MAINTAIN (with trained people) the UCCE product.  Please let me know if you have other questions or want any further recommendations on what you might look at for systems survivability. 


This hasn't got anything at all to do with UCCX's application-level failover. The requirement for NFT is totally unrelated to application failures and only marginally related to server hardware failures. Server NIC failures are vanishingly rare. NFT mainly kicks in for the occasional cabling failure, or much more often, planned maintenance or other issues with the upstream switch. Any large enterprise with a modern (less than ten years old) data center/service switching block will be designed for dual uplink of all devices, not only for protection against failure but to allow continued operations during network maintenance.

  I think at the end of the day, too many engineers are focused on the LAN/WAN model where we always bought 2 and configured HSRP, VRRP, BGP, etc to have total redundancy.  In the server/software realm (which is really what UCC is) you should be monitoring your overall server health and be able to predict failures.  You obviously won't prevent the tornados, hurricanes, fires, and thefts, but really, that's not what NIC teaming would buy you anyway.  If you instead shift focus to watching the physical components of the server, do simple SNMP traps and SYSLOG messages, that will get you going in the right direction.  The key is you have to READ what you are sending out.  If you have a nice server full of SNMP and SYSLOG so that Tuesday afternoon you can tell everyone what was failing on Friday that wasn't caught, that's not as good as having a report each day and email/pager alerts on critical items to see what's about to break and then move the "Master" to node 2 gracefully, afterhours when no one notices and just repair the main issue.   I could write a whole book on this, but I'll stop here as I think I've answered the original question as thoroughly as possible.

More of the same; NFT isn't being used to address issues with the application. You're correct in that SNMP monitoring of the UCCX hardware platform is one of several monitoring strategies that should be in place, to pick up the occasional redundant power supply or fan failure.

UCCX application-level failover cannot be the sole means of dealing with a single network link drop. This was fully supported in UCCX 7.0 and going back all the way to at least 3.5/3.1. Network connectivity picked back up within a few milliseconds; callers and agents would perceive nothing. The idea that Cisco invested all this time and effort into 8.0/8.5 WAN clustering, but now says a single network link drop requires you slam-dunk a hundred or more customers in-queue, start operating off a server that's quite likely on the other end of a WAN link at a DR site or alternate data-center, and wait an entire minute or more for the abandoned callers and agents to get back in, doesn't pass the laugh test.

This is a bug, one way or another:

  1. If NFT is unsupported, it needs to be disabled in the platform CLI at a minimum.
  2. If NFT is truly problematic, it needs to be repaired and then be supported.
  3. If NFT is supported, the install guide needs to be fixed.

Sorry to tear your head off on your first foray into the forum (just noticed your post counter, welcome!) but I felt strongly about the issue once I read more.

Dan,

     As I stated above, NIC teaming is not supported.  What we do provide for fault tolerance is having an HA system.  With this, you have two servers that keep track of each other through the network.  When one experiences a failure, the secondary takes over.  This is explained in the administration guide and there are step by step guidelines for changing your deployment type from standalone or SA to high-availability which is HA.  Please let me know if this answers your question or if you have another question about this.  Thank you and have a great day.

Robert W. Rogier
Technical Consulting Engineer – Contact Center Enterprise
E2E Lead | Subject Matter Expert – ECE, CCMP, CCDM
Phone: +1 919 574 5993
Email: rorogier@cisco.com
Business Hours: 8AM to 5PM ET

Dan,

     As I stated above,  NIC teaming is not supported.  What we do provide for fault tolerance  is having an HA system.  With this, you have two servers that keep track  of each other through the network.  When one experiences a failure, the  secondary takes over.  This is explained in the administration guide  and there are step by step guidelines for changing your deployment type  from standalone or SA to high-availability which is HA.  Please let me  know if this answers your question or if you have another question about  this.  Thank you and have a great day.

Regards,

Robert W. Rogier

Robert W. Rogier
Technical Consulting Engineer – Contact Center Enterprise
E2E Lead | Subject Matter Expert – ECE, CCMP, CCDM
Phone: +1 919 574 5993
Email: rorogier@cisco.com
Business Hours: 8AM to 5PM ET

+1. I have exactly the same issue with a customer. They are very unimpressed that they can't turn on NIC teaming on a core server. They have HAoWAN and frankly failover due to a switch outage is painful ( we have an open TAC case for failover issues). They had recording issues when teaming was enabled which was when TAC mentioned that it was (probably) an issue. It should be fixed and if not disabled in VOS.

Here's the deal, to my knowledge:

  • Yes, UCCX NIC teaming is unsupported by TAC.
  • Yes, UCCX NIC teaming works just fine in the real world, except if you need (R)SPAN based recording.

If you need (R)SPAN recording, you need a dedicated NIC for RTP traffic monitoring, and all the supported platforms only have two. Therefore you can't team the two for network access. CAD based recording within UCCX should work fine. Also, recording using WFO Quality Management in any mode would be fine as it doesn't use the UCCX recording mechanisms, although the WFO QM server itself would be subject to similar restrictions if used in SPAN mode.

Hello Robert,

I want made ​​ NIC redundancy for UCCX 5, I saw that NIC is not supported, what other solution I can use

Could you give me some advices?

All the best,

Dan

Content for Community-Ad