cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2567
Views
7
Helpful
2
Replies

CUCM & CUBE good network design?

louis0001
Level 3
Level 3

We have some voice gateways Cisco 2921's which run our ISDN30's. We are in the process of changing our network design as well as looking at phasing the ISDN30's out gradually with sip trunks on our MPLS network.

Our remote sites are all segregated with management, data, voice, guest vlans etc and our core structure has seperation for our servers etc

I'm wondering whether we should follow the same design with the voice side of things? eg  Pub, subs on their own subnet, CUBE in dmz, clientss on own subnet etc?

Is it bad practice to have the CUCM & CUBE on the same subnet?

1 Accepted Solution

Accepted Solutions

Ratheesh Kumar
VIP Alumni
VIP Alumni

Hi there

 

This SRND and Best practice white paper could help you.

https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/srnd/collab12/collab12/ovroutng.html

 

https://www.cisco.com/c/en/us/products/collateral/unified-communications/unified-border-element/white_paper_c11-620461.html

 

Network Design

Best practices in the area of network design include:

● Always use an SBC to terminate a service provider SIP trunk into your network, regardless of whether you use Cisco Unified Communications Manager, Cisco Unified Communications Manager Express or any other vendor’s call agent. An SBC offers security, demarcation, session management, and interworking features that protect your network from denial-of-service (DoS) and other SIP-based attacks, allow you to resolve troubleshooting problems, provide SIP trunk status monitoring tools, and aid in SIP manipulation to overcome myriad interoperability problems present in the industry. A Primary Rate Interface (PRI) gateway implicitly offers these same services into your network—but when migrating calls from PRI trunking (for PSTN access) to SIP trunking you lose these controls and security protection unless you use an SBC.

● Carefully consider the benefits and challenges of the centralized or distributed SIP trunk designs, even if the choice seems obvious. Centralized designs almost always look more attractive because of their cost savings. However, this choice has network design implications that may increase the overall cost, as well as make redundancy designs a much more serious consideration because the aggregated session counts are much higher than with a TDM gateway. A distributed design may be viable, especially if you already have a distributed Multiprotocol Label Switching (MPLS) network for your data network.

● For redundancy reasons you should consider having at least two SIP trunk entry points into your network. For medium and larger networks, these points should be geographically separated.

● Most SIP trunk providers allow only two IP addresses with the service, either as primary/secondary or in a load-balancing setup. If you have to load balance your calls over more than two devices for either scalability or redundancy reasons, you may have to insert a SIP proxy or load-balancer device in between to distribute the traffic. Some providers use Domain Name System (DNS), which offers more IP address destination choices for a single logical SIP trunk.

● Most SIP trunk providers currently do not use DNS, but instead use absolute IP addressing. This situation may influence your redundancy and load-balancing considerations.

● Load balancing over the two IP addresses the provider allows is generally a more dynamic and flexible call-routing configuration than a primary/secondary algorithm.

● Use a Layer 7 SIP OPTIONS ping to monitor SIP trunk status in addition to one of several Layer 3 mechanisms that may be available, such as Internet Control Message Protocol (ICMP) ping or IP service-level agreements (IP SLAs).

● Investigate troubleshooting tools and methods to determine the source of any voice quality concerns. If one is reported, decide how you will determine if it is present in your network or in the service provider’s network. Discuss with your provider how such problems will be investigated and resolved.

● Turn on Call Admission Control (CAC) features on your session border controller whether or not your provider offers an SLA, and especially so if your provider does not offer an SLA. Deploy CAC features to monitor both simultaneously active calls and call arrival rates.

 

SBC Best Practices

Best practices in the area of SBC deployment include:

● For small-site (or remote-office) SBC deployments that carry low traffic, use a single Cisco router with integrated services such as Cisco Unified Border Element, MTP, VoiceXML, firewall, and Survivable Remote Site Telephony (SRST) features.

● For larger-site (or campus or data center) SBC deployments that carry high traffic, use a dedicated router for Cisco Unified Border Element, and other dedicated routers for MTP or VoiceXML or any other service you may need at that site.

● Pay careful attention to performance engineering of SIP trunks into your network because this migration most likely changes the call flows as well as the bandwidth allocation to calls.

Whether you use H.323-SIP or SIP-SIP on Cisco Unified Border Element makes no difference to its session capacity.

DTMF interworking or Delayed Offer to Early Offer adds no significant extra load to Cisco UBE.

Using SIP profiles for normalization on Cisco Unified Border Element may have a performance effect depending on the number and complexity of the rules, but is not generally a significant performance factor.

Configuring MTPs on the same platform as Cisco Unified Border Element and using transcoding are CPU-intensive tasks and must be carefully engineered.

If you are using Cisco Unified Border Element platforms terminating fewer than 500 sessions (calls) per platform, most of the performance engineering needed is likely on the Cisco UBE platform itself and not elsewhere in your network. But if you are using high-end Cisco UBE platforms terminating 2000 or more sessions per Cisco UBE platform, the bottleneck may move to your Cisco Unified Communications Manager servers or IP private branch exchanges (PBXs) connected to Cisco UBE, and these systems must be included in the performance engineering work.

● Define explicit incoming and outgoing dial peers on your Cisco Unified Border Element device. SBC calls have two IP call legs (as opposed to a TDM gateway that has only one), so it is often necessary to have both dial peers to control the characteristics of each individual call leg—the default settings may not be what you need in your network. This practice also gives you additional control points to combat toll-fraud attacks.

● Do not co-locate Network Address Translation (NAT) services on the same router interface that carries Cisco Unified Border Element traffic. Cisco UBE provides topology hiding, so it already performs a “NAT” function on the voice streams.

 

 

Hope this helps!

Cheers
Rath!


***Please rate helpful posts***

 

 

View solution in original post

2 Replies 2

M02@rt37
VIP
VIP

 Hi @louis0001,

 

DMZ is the place to be for CUBE. It is the CUCM's proxy.

You maybe insert on your design firewall in input/output of your DMZ.

 

Then it's a bad pratice to have the CUCM and CUBE on the same subnet.

Best regards
.ı|ı.ı|ı. If This Helps, Please Rate .ı|ı.ı|ı.

Ratheesh Kumar
VIP Alumni
VIP Alumni

Hi there

 

This SRND and Best practice white paper could help you.

https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/srnd/collab12/collab12/ovroutng.html

 

https://www.cisco.com/c/en/us/products/collateral/unified-communications/unified-border-element/white_paper_c11-620461.html

 

Network Design

Best practices in the area of network design include:

● Always use an SBC to terminate a service provider SIP trunk into your network, regardless of whether you use Cisco Unified Communications Manager, Cisco Unified Communications Manager Express or any other vendor’s call agent. An SBC offers security, demarcation, session management, and interworking features that protect your network from denial-of-service (DoS) and other SIP-based attacks, allow you to resolve troubleshooting problems, provide SIP trunk status monitoring tools, and aid in SIP manipulation to overcome myriad interoperability problems present in the industry. A Primary Rate Interface (PRI) gateway implicitly offers these same services into your network—but when migrating calls from PRI trunking (for PSTN access) to SIP trunking you lose these controls and security protection unless you use an SBC.

● Carefully consider the benefits and challenges of the centralized or distributed SIP trunk designs, even if the choice seems obvious. Centralized designs almost always look more attractive because of their cost savings. However, this choice has network design implications that may increase the overall cost, as well as make redundancy designs a much more serious consideration because the aggregated session counts are much higher than with a TDM gateway. A distributed design may be viable, especially if you already have a distributed Multiprotocol Label Switching (MPLS) network for your data network.

● For redundancy reasons you should consider having at least two SIP trunk entry points into your network. For medium and larger networks, these points should be geographically separated.

● Most SIP trunk providers allow only two IP addresses with the service, either as primary/secondary or in a load-balancing setup. If you have to load balance your calls over more than two devices for either scalability or redundancy reasons, you may have to insert a SIP proxy or load-balancer device in between to distribute the traffic. Some providers use Domain Name System (DNS), which offers more IP address destination choices for a single logical SIP trunk.

● Most SIP trunk providers currently do not use DNS, but instead use absolute IP addressing. This situation may influence your redundancy and load-balancing considerations.

● Load balancing over the two IP addresses the provider allows is generally a more dynamic and flexible call-routing configuration than a primary/secondary algorithm.

● Use a Layer 7 SIP OPTIONS ping to monitor SIP trunk status in addition to one of several Layer 3 mechanisms that may be available, such as Internet Control Message Protocol (ICMP) ping or IP service-level agreements (IP SLAs).

● Investigate troubleshooting tools and methods to determine the source of any voice quality concerns. If one is reported, decide how you will determine if it is present in your network or in the service provider’s network. Discuss with your provider how such problems will be investigated and resolved.

● Turn on Call Admission Control (CAC) features on your session border controller whether or not your provider offers an SLA, and especially so if your provider does not offer an SLA. Deploy CAC features to monitor both simultaneously active calls and call arrival rates.

 

SBC Best Practices

Best practices in the area of SBC deployment include:

● For small-site (or remote-office) SBC deployments that carry low traffic, use a single Cisco router with integrated services such as Cisco Unified Border Element, MTP, VoiceXML, firewall, and Survivable Remote Site Telephony (SRST) features.

● For larger-site (or campus or data center) SBC deployments that carry high traffic, use a dedicated router for Cisco Unified Border Element, and other dedicated routers for MTP or VoiceXML or any other service you may need at that site.

● Pay careful attention to performance engineering of SIP trunks into your network because this migration most likely changes the call flows as well as the bandwidth allocation to calls.

Whether you use H.323-SIP or SIP-SIP on Cisco Unified Border Element makes no difference to its session capacity.

DTMF interworking or Delayed Offer to Early Offer adds no significant extra load to Cisco UBE.

Using SIP profiles for normalization on Cisco Unified Border Element may have a performance effect depending on the number and complexity of the rules, but is not generally a significant performance factor.

Configuring MTPs on the same platform as Cisco Unified Border Element and using transcoding are CPU-intensive tasks and must be carefully engineered.

If you are using Cisco Unified Border Element platforms terminating fewer than 500 sessions (calls) per platform, most of the performance engineering needed is likely on the Cisco UBE platform itself and not elsewhere in your network. But if you are using high-end Cisco UBE platforms terminating 2000 or more sessions per Cisco UBE platform, the bottleneck may move to your Cisco Unified Communications Manager servers or IP private branch exchanges (PBXs) connected to Cisco UBE, and these systems must be included in the performance engineering work.

● Define explicit incoming and outgoing dial peers on your Cisco Unified Border Element device. SBC calls have two IP call legs (as opposed to a TDM gateway that has only one), so it is often necessary to have both dial peers to control the characteristics of each individual call leg—the default settings may not be what you need in your network. This practice also gives you additional control points to combat toll-fraud attacks.

● Do not co-locate Network Address Translation (NAT) services on the same router interface that carries Cisco Unified Border Element traffic. Cisco UBE provides topology hiding, so it already performs a “NAT” function on the voice streams.

 

 

Hope this helps!

Cheers
Rath!


***Please rate helpful posts***