Network Design and Engineering

SBC Geographic Redundancy

Deployment Guide
An Implementation Guide
for the Sonus SBC

Revision 1.1, March 16, 2017

Copyright
Copyright © 2017 Sonus and/or its affiliates. All rights reserved.
This document may not be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without
the prior written consent of Sonus.

4 Technology Park Drive

Westford, MA 01886
Phone: +1-978-614-8100
Web: http://www.sonus.net
SBC Geographic Redundancy Deployment Guide i

Document Revision History

Revision Date Author Description

1.1 March 16, 2017 G. Matey Minor update for SWe support in 5.1.1

Applicability

The instructions, commands and references in this document apply to the Sonus
Core portfolio consisting of the 5000 Series, the 7000 Series, and the Sonus SBC
Software Edition (SWe) platforms.

This document does not apply to the Sonus 1000 or 2000 SBC systems.

Sonus Network Design and Engineering

Copyright © 2017, Sonus and/or its affiliates. All rights reserved.
SBC Geographic Redundancy Deployment Guide ii

Table of Contents
1. Introduction .........................................................................................................................1
1.1. Audience........................................................................................................................1
1.2. Requirements .................................................................................................................1
2. Reference Network Deployment.......................................................................................2
2.1. Separation Nomenclature for Deployment.................................................................3
3. SBC Geographic Redundancy and High Availability .....................................................4
3.1. SBC High Availability Primer .........................................................................................5
3.1.1. HA Links.............................................................................................................................................................................. 5
3.1.2. Layer 2 Redundancy....................................................................................................................................................... 6
3.2. HA Network Cabling and Configuration .....................................................................7
3.2.1. SBC Configuration ........................................................................................................................................................... 7
3.2.2. Network Cabling.............................................................................................................................................................. 8
3.2.3. Additional Considerations for the SBC 7000 Series ....................................................................................................9
3.3. Inter-Site Connectivity.................................................................................................11
4. GR Design Considerations................................................................................................12
4.1. SBC Routing Policy.......................................................................................................12
4.2. Design Question Examples .........................................................................................12
5. Alternatives........................................................................................................................14
6. Conclusion.........................................................................................................................16

Sonus Network Design and Engineering

Copyright © 2017, Sonus and/or its affiliates. All rights reserved.
SBC Geographic Redundancy Deployment Guide iii

Sonus Network Design and Engineering

Copyright © 2017, Sonus and/or its affiliates. All rights reserved.
SBC Geographic Redundancy Deployment Guide 1

1. Introduction
This document provides a guide for deploying a single Sonus SBC Core platform
(Session Border Controller) in a Geographic Redundant manner.
While this document attempts to document some best practices and
configuration examples for deploying Sonus SBC Platforms, deployments done
under the auspices of the Sonus Network Design group should always take
precedence over generic recommendations if there are any differences. Sonus
Network Design provides a variety of consulting services and if design assistance
is desired, contact your Sonus Sales Representative about Sonus Network Design
Consulting.

1.1. Audience
This document is intended for design engineers, system engineers and
operations staff for the purpose of deploying a Sonus SBC.
Although this document provides some coverage on the concepts involved, the
reader is expected to have a basic understanding of RTP media and SIP
signaling. In addition, understanding Ethernet, VLANs, IP Addressing, and IP
Routing are also necessary for planning and deploying an SBC.
For any questions regarding this document or the content herein, please
contact your maintenance and support provider.

1.2. Requirements
This document is applicable to the Sonus SBC Core consisting of the Sonus SBC
Software Edition (SWe) running software release 5.1.1 or later or the 5000 Series
and the SBC 7000 Series, running software release 5.0.1 or later.

Sonus Network Design and Engineering

Copyright © 2017, Sonus and/or its affiliates. All rights reserved.
SBC Geographic Redundancy Deployment Guide 2

2. Reference Network Deployment

A Session Border Controller (SBC) is essentially a VoIP firewall: non-VoIP traffic is
not forwarded while specific VoIP traffic (SIP/H.323 and RTP) may be allowed via
configuration. Like a general purpose data firewall, an SBC is typically, but not
exclusively, deployed on the perimeter of one or more networks.
SBCs and firewalls do differ in several aspects. General purpose data firewalls
have historically had poor SIP support and have been known to cause problems
with SIP call-flows. Another weak spot for firewalls is Real Time Protocol (RTP)
support. If a firewall can’t automatically open and close UDP ports for RTP
(signaled within SIP, which could be a SIP limitation of the firewall), then the
firewall will need a large range of UDP ports to be forced open.
Another consideration for a firewall is in performance and throughput for RTP
flows. Regardless of RTP UDP port support (dynamic or static), the firewall must
also be sized appropriately for all the simultaneous RTP flows the network must
sustain. A firewall properly sized for RTP traffic may be significantly more
expensive than a firewall that does not need to deal with VoIP.
Most networks using VoIP will likely deploy both firewalls and SBCs, but because
an SBC is essentially a VoIP firewall and general purpose firewalls can perform
poorly for VoIP, in most networks an SBC is deployed in parallel, rather than in
series, with a normal data firewall.

Figure 1 – Classic SBC Network Deployment

Sonus Network Design and Engineering

Copyright © 2017, Sonus and/or its affiliates. All rights reserved.
SBC Geographic Redundancy Deployment Guide 3

An SBC can certainly be deployed in series with general purpose firewalls and a
small percentage of customers do choose that deployment model for some
Sonus SBC systems.

Figure 2 – Popular Carrier-focused Network Deployment

Another popular deployment scenario of Sonus SBC systems is where a single

switch pair provides connectivity to both Internal and External networks. This
deployment scenario is more common among Carriers than Enterprises. The
SBC supports all deployment scenarios discussed. Example cabling and
configuration diagrams will show separate switch pairs for clarity purposes.

2.1. Separation Nomenclature for Deployment

Like a firewall, an SBC is typically deployed on the perimeter of one or more
networks. This document will use the terms Internal and External to differentiate
between the networks the SBC is connected to and their trust relationships.
While there is a common Sonus convention, SBC Media ports do not have
dedicated Internal/External roles. “Internal” and “External” are merely labels
that Sonus will use throughout this document. Other popular descriptive labels
include:
• Inside/Outside
• Trusted/Untrusted
• Private/Public
• Core/Peer (or Core/Access)

Sonus Network Design and Engineering

Copyright © 2017, Sonus and/or its affiliates. All rights reserved.
SBC Geographic Redundancy Deployment Guide 4

3. SBC Geographic Redundancy and High Availability

The two nodes of a Sonus SBC High Availability (HA) pair may be deployed in
separate physical locations if the following requirements are met:
 Delay and packet loss between the nodes must be less than the
documented maximums
 HA links must be directly connected or use transparent, full-bandwidth,
single-SBC-pair dedicated layer 2 connections
 The management, signaling, and media networks must use transparent,
layer 2 connections between sites (multiple SBCs can share these VLANs)

SBC Platform Maximum HA Link Round-Trip Delay

SBC Software Edition 110 ms

SBC 51x0 Series 110 ms
SBC 52x0 Series 60 ms
SBC 7000 Series 20 ms

Table 1 – HA Round Trip Delay Requirements – Release 5.1.1

Delay Maximum Packet Loss

5 ms 1%
10 ms 0.3%
30 ms 0.2%
50 ms 0.1%
75 ms 0.001%
100 ms 0.0005%

Table 2 – HA Packet Loss Requirements – Release 5.1.1

For the latest Delay and Packet Loss Requirements, refer to the SBC Redundancy
section of the Sonus SBC Core Documentation of the software release used.
For the SBC 5000 Series and SBC Software Edition (SWe), the Geographically
Redundant (GR) SBC system is conceptually identical to the singe site

Sonus Network Design and Engineering

Copyright © 2017, Sonus and/or its affiliates. All rights reserved.
SBC Geographic Redundancy Deployment Guide 5

deployment of an SBC HA pair (the only physical difference is that the SBC
Software-Edition has only one HA port).
The SBC 7000 Series is also fundamentally the same, but the deployment should
take into account that platform’s ability to have local standby media ethernet
ports. This document will cover that in a separate section.
In order to understand the GR caveats and requirements, it is essential to first
understand the underlying HA mechanism for the Sonus SBC.

3.1. SBC High Availability Primer

A quick primer, or refresher, of Sonus SBC High Availability (HA) should help
provide context for the subsequent sections. A Sonus SBC can be deployed as a
single-node (Stand Alone; SA) system or as a two-node HA system.
An HA system provides node/box-level redundancy in an active-standby (non-
configurable) manner with the standby node providing a "hot" backup with no
stable call/session loss during switchover.
SBC High Availability is provided by a combination of two mechanisms.
 SBC node state synchronization (via links between each node’s HA ports)
 Preservation of Signaling and Media addressing (via Layer 2 redundancy)

3.1.1. HA Links
SBC active and standby nodes are kept in sync via state replication over the HA
port links. The HA links themselves operate in an active/standby manner and
both links should be deployed for link redundancy.
If the HA ports are not directly cabled, then they must be in their own private,
non-routable VLAN (i.e. L3 VPNs and routers cannot be used and no filtering
should be done on this VLAN). As both IP and non-IP protocols (TIPC, ARP) are
used between the SBC nodes, completely transparent and unfiltered layer 2
connectivity is required between the HA ports.
If multiple SBC pairs are deployed in this manner, then each pair must be in its
own private HA VLAN (Sonus SBC Software Edition nodes may all share an HA
VLAN among themselves, but then require unique addressing to be configured
by the user). The HA ports do not support VLAN tagging so the directly
connected switch should be configured as untagged or “access” ports. The
active/standby nature of the HA links are transparent to any connected

Sonus Network Design and Engineering

Copyright © 2017, Sonus and/or its affiliates. All rights reserved.
SBC Geographic Redundancy Deployment Guide 6

switches; switch-level link aggregation (IEEE 802.1AX / 802.3ad) is not supported

or needed.
The HA ports will automatically configure themselves in an (active-standby)
ethernet bond and use the 169.154.0.0/16 address space for IP-based inter-node
communication. The Sonus SBC Software Edition (SWe) nodes allow their HA IP
addresses to be configured (along with the HA system’s TIPC value). This is to
allow for multiple HA systems to share the same HA VLAN. If the SWe systems do
not share a HA VLAN, then the user should accept the HA default addressing. If
the HA VLAN is shared, unique IP address should be configured out of the
169.254.0.0/16 subnet for each HA pair in addition to a unique TIPC value. Use of
HA addressing outside of the 169.254.0.0 IP space is not recommended.
The SBC nodes also use non-IP protocols for communication which necessitate
the use of transparent, unfiltered layer1/layer 2 connectivity.
The reliability and quality of HA connectivity should be equivalent to that
provided by local, direct fiber. At this time, only full-bandwidth links are
supported for HA purposes (e.g. for the SBC 5000 Series, each gigabit ethernet
HA port should have access to 1 gigabit of bandwidth, while 10 gigabit links are
required for each HA port on the SBC 7000 Series).

3.1.2. Layer 2 Redundancy

While state replication ensures that the standby node is always in sync and
ready to switchover, the use of layer 2 redundancy ensures that signaling and
media network addresses are preserved so that remote peers are essentially
unaware that the call or session is now being serviced by the standby node.
Gratuitous ARP is used for the signaling and media addresses after an SBC
switchover to notify the network that those addresses have physically moved.
The Sonus SBC Software Edition system preserves the IP addresses, while the
hardware-based Sonus SBC systems preserve both the IP and MAC addresses.
This mechanism requires a contiguous ethernet broadcast domain for the
signaling and media networks and implemented by the directly connected
ethernet devices via their switching/bridging (802.1D) functionality.
Although not in the path for call/session establishment, the SBC Management
subnet has a similar requirement that all ethernet ports are connected to a layer
2 switching elements.
For more details on Network Switch and Router Requirements, review the
Network Deployment Guide specific to the Sonus SBC Series used.

Sonus Network Design and Engineering

Copyright © 2017, Sonus and/or its affiliates. All rights reserved.
SBC Geographic Redundancy Deployment Guide 7

3.2. HA Network Cabling and Configuration

A Geographically Redundant (GR) SBC system is conceptually identical to the
singe site deployment of an SBC HA pair. While there are no configuration
parameters to functionally enable GR, there are some recently added
parameters that modifies some SBC functionality HA behavior to make it more
robust when deployed in a GR environment.

3.2.1. SBC Configuration

In 5.0.1R1, a script (geoRedundHa.sh) when enabled through a special Method
Of Procedure (MOP), modified the SBC functionality for GR deployments. The
script was not available or applicable to the SBC SWe.
In release 5.1, the script and MOP have been deprecated with the functionality
separated into its two independently configurable component parts:
 HA bond monitoring mechanism
o direct-connect (default) → network-connect
 HA leader election algorithm
o Standard (default) → enhanced

request system <system name> setHaConfig

bondMonitoring <currentValue | direct-connect | network-connect>
leaderElection <currentValue | enhanced | standard>

request system sbx1 setHaConfig bondMonitoring network-connect leaderElection enhanced

show table system haConfig

LEADER BOND
SERVER NAME ELECTION MONITORING
--------------------------------------------------
SBC01A enhanced network-connect
SBC01B enhanced network-connect

CLI Configuration 1 – SBC HA Configuration for GR in release 5.1

The SBC defaults to the direct-connect bond monitoring behavior which is best
suited for when the HA pair are (obviously) directly connected. This is also
applicable for transport scenarios (e.g. DWDM using dedicated wavelengths for
each HA link) which exactly replicate directly cabled connectivity. Network-
connect applies to scenarios which do not exactly replicate directly cabled
connectivity; as this functionality utilizes ARP polling, it requires the transparent

Sonus Network Design and Engineering

Copyright © 2017, Sonus and/or its affiliates. All rights reserved.
SBC Geographic Redundancy Deployment Guide 8

layer 2 connectivity. The bondMonitoring parameter and its setting does not
apply to the SBC SWe as its single HA port does not use a bond.
The leader election algorithm was modified to change the node recovery
decision on which SBC node survives a “split-brain” scenario (network
segmentation/isolation), This was introduced from experience that HA link loss in
a GR scenario was more likely due to data center isolation than a simple HA link
specific issue. The leaderElection parameter and its setting applies to all SBC
platforms. The use of the enhanced election algorithm outside of a GR
deployment is an area for further study.

3.2.2. Network Cabling

The figure below attempts to visually illustrate the difference between a
standard HA deployment of an SBC 5110 in a single site (local), and an HA
deployment in two different sites (GR).
Common to both diagrams are the management (blue), internal
signaling/media (green), external signaling/media (yellow), and HA (purple)
networks. While there is flexibility in the network configuration and cabling of a
Sonus SBC, this document will focus on one common configuration for simplicity.

Figure 3 – Local HA vs. GR HA – Side-by-Side

A GR deployment is basically a standard HA deployment, but “stretched”

across two sites. But as noted in the prior section, the HA ports don’t necessarily

Sonus Network Design and Engineering

Copyright © 2017, Sonus and/or its affiliates. All rights reserved.
SBC Geographic Redundancy Deployment Guide 9

require a direct connection. For inter-site connectivity, it would actually be

uncommon for HA (direct fiber) to be provided differently than the other
network connectivity (Internal/External/Management), so many GR
deployments could look like the following:

Figure 4 – SBC GR Without Direct HA Fiber Links

In a deployment where direct HA fiber links are not used, it is critical that full
bandwidth, transparent layer 2 connectivity is used between SBC nodes.

3.2.3. Additional Considerations for the SBC 7000 Series

One significant networking difference in the SBC Core portfolio of platforms is
that the SBC 7000 Series supports standby media interfaces on the active SBC
node, which provides some interface redundancy without requiring an SBC
node switchover event.
This unique capability of the SBC 7000 Series is what drives the difference in the
general cabling recommendations for the platform (use of these two additional
10G interfaces are optional, but recommended, and can only be used for
standby purposes).

Sonus Network Design and Engineering

Copyright © 2017, Sonus and/or its affiliates. All rights reserved.
SBC Geographic Redundancy Deployment Guide 10

Figure 5 – SBC 7000 Series Recommended Cabling

Sonus Network Design generally recommends that local standby Media ports be
cabled to the opposite switch that the local primary Media ports are cabled to.
That cabling configuration ensures that a switch failure doesn’t necessarily
cause an SBC 7000 switchover.
(As mentioned in the SBC 5000 Series Network Deployment Guide, cross-linking
of Management ports, can be done like the SBC7000 Series recommendation,
but is not done in the general case, to simplify many deployments.)
When the SBC 7000 nodes are co-located, the use of cross-links for Media ports is
trivial and a “no brainer” in most scenarios. When geographically separated,
these 10 gig cross-links may come as a considerable cost and realistically
require additional transport-level (e.g. optical, DWDM, etc…) connectivity. Care
must be taken to ensure that the standby cross-link does not share the same
fate as the active media link in the case of local equipment failure. If that
cannot be assured then the standby Media port should still be used, but with the
understanding that will only provide protection from local port or cable failures.

Sonus Network Design and Engineering

Copyright © 2017, Sonus and/or its affiliates. All rights reserved.
SBC Geographic Redundancy Deployment Guide 11
3.3. Inter-Site Connectivity
Whether or not HA connectivity is provided by direct fiber or not, it should be
transparent to the behavior of the SBC. If the network connectivity demarcation
point to the SBC is at the network/VLAN level, then the inter-site connectivity
would likely be aggregated via VLAN trunks.

Figure 6 – Example of Underlying Inter-Site VLAN Connectivity for an HA System

What ultimately transparently transports those VLANs and their traffic between
sites could be provided by the user’s own equipment, a carrier’s Metro Ethernet
service (E-Line or E-LAN), DWDM/optical equipment, SONET/SDH equipment, or
some combination of all of the above. As long as it meets the SBC requirements
of latency, transparent L2 connectivity, reliability, availability, quality, and
bandwidth, the exact mechanisms of how they are provided are outside the
purview of the SBC. Similarly, Sonus cannot provide guidance or
recommendations on carrier-specific products that may provide inter-site
transport services.
For many real-time media solutions requiring hot-standby Geographic
Redundancy, the SBC deployment itself is fairly straight forward, but there are
other design criteria and behaviors that must be considered.

Sonus Network Design and Engineering

Copyright © 2017, Sonus and/or its affiliates. All rights reserved.
SBC Geographic Redundancy Deployment Guide 12
4. GR Design Considerations
The Sonus SBC is but one component in a real-time media solution requiring hot-
standby Geographic Redundancy. The benefit of such solutions are primarily for
entire site failures, so consideration must be given to the other components and
services that reside at a site and/or communicate with a site.
Consideration should also be given to partial site failures (e.g. losing all external
SIP connectivity at one site). Some failure scenarios may benefit from having a
separate SBC HA system at the other site rather than splitting a single HA pair.
The different failure scenarios and points of failures should be considered to
ensure that the benefits of an SBC GR hot-standby can be realized.
Types of Failure Scenarios
 Complete Site Failures
 Partial Site Failures
Points of Failure
 Carrier SIP Trunks
 Network Connectivity to Carrier SIP Trunks
 Network Connectivity to Internal SIP servers and PBX systems
 Location and HA capabilities of Internal SIP servers and PBX systems

4.1. SBC Routing Policy

The location and capabilities of the routing policy for the Sonus SBC should also
be considered in a GR deployment. If the SBC uses the Embedded Routing
Engine (ERE) or embedded PSX (ePSX) policy options, then there are no external
dependencies for routing calls. If the deployment requires that SBC query an
external PSX Policy Server, then each site will need its own unique PSX Policy
Server capable of call processing.

4.2. Design Question Examples

If a carrier SIP trunk is provided by a dedicated IP/MPLS connection from them
to the main site, how does that same SIP trunk traffic reach the standby SBC,
when the entire main site is dark and/or underwater?

Sonus Network Design and Engineering

Copyright © 2017, Sonus and/or its affiliates. All rights reserved.
SBC Geographic Redundancy Deployment Guide 13
Does the carrier preserve the network addressing for their SIP trunk redundancy,
or are the carrier’s backup SIP trunk is provided by a different carrier SBC (using
its own unique addressing)? If the carrier cannot preserve the same network
addressing, then the Sonus SBC will see that other SBC as a different SIP peer
than the primary and calls/sessions will not be preserved.
For some partial failures, can the network adequately support hair-pinned
sessions and media between sites?
What devices are co-located at the same site as the SBC? What about the
endpoints that are being serviced by the SBC? If the endpoints themselves
experience a service interruption due to a site failure, then there would be little
or no benefit of a hot-standby SBC (i.e. SBC preserving calls/sessions of
endpoints that they themselves fail).
No document can completely catalog all the possible design considerations
and their relevance to any arbitrary organization’s network deployment.
Similarly, the various cost-benefit ratios of various services and their survivability
will vary not just by the organization, but within the organization. For specific
insight for your organization, Sonus Network Design provides a variety of
consulting services and if design assistance is desired, contact your Sonus Sales
Representative about Sonus Network Design Consulting.

Sonus Network Design and Engineering

Copyright © 2017, Sonus and/or its affiliates. All rights reserved.
SBC Geographic Redundancy Deployment Guide 14
5. Alternatives
If some of the criteria for a “hot-standby” GR solution is not met (e.g. a carrier’s
backup SIP trunk does not support being a hot-standby for active calls and
preservation of IP network addressing), then alternatives should warrant serious
consideration.
The most common solution is a dual-HA pair model, where each unique SBC HA
pair is deployed as the “backup” for the other pair. This warm-standby model,
typically referred to as Disaster Recovery (DR), eliminates the GR dependencies
between all the solution components. While calls/sessions are not preserved
between DR sites, the technical and/or economic aspects of a warm-standby
DR solution tend to provide far more upsides. Outside of session licensing, DR
itself is not a specific SBC feature or option, but simply how an SBC is deployed
and maintained in the overall network.

Figure 7 – Common Dual SBC HA Pair Deployment

This solution provides multiple levels of SBC redundancy: both “hot” local
redundancy and “warm” remote redundancy, without all the network and
carrier caveats. Another benefit of the dual SBC HA solution is that both SBC
pairs are fully operational and providing service. This significantly increases the
likelihood that the remote pair can reliably take over for the failed one, since

Sonus Network Design and Engineering

Copyright © 2017, Sonus and/or its affiliates. All rights reserved.
SBC Geographic Redundancy Deployment Guide 15
the SBC, routers and switches, carrier SIP trunks, and PBX SIP trunks are already
actively supporting traffic.
While the SBC systems are deployed as two separate HA pairs, they can be
provisioned to take over the capacity of the other through the use of Disaster
Recovery (DR) session licenses or in the near future, network-based (rather than
node-based) session licenses. Contact your Sonus Sales Representative to
discuss these licensing options.

Figure 8 – Dual SBC HA Deployment with Carrier Call Distribution

The dual SBC HA deployment is also supported by all carrier SIP trunks and will
typically have carrier services to assist in the crankback or rerouting of calls
between locations. Many times this is part of a carrier’s basic call distribution
service for multiple locations. The site destination and call distribution from the
carrier can be based on the dialed number (dial plan), load-sharing (e.g. toll-
free contact center), or a combination. And even the most basic SIP-capable
PBX can support primary and secondary routes for the dual SBC HA pairs.

Sonus Network Design and Engineering

Copyright © 2017, Sonus and/or its affiliates. All rights reserved.
SBC Geographic Redundancy Deployment Guide 16
6. Conclusion
As shown in this guide, while the Sonus SBC can be deployed fairly easily in a GR
manner itself, but it is just a component of a Geographically Redundant real-
time media solution. Geographic Redundancy must be viewed holistically to
ensure that all components provide the same level of functionality and
availability in the same manner. Many network considerations, such as the
functionality, bandwidth, behavior, and layer 2 transparency of the underlying
transport between the geographically separate sites, the particulars of the
carrier’s SIP trunks and routing are critical criteria in determining the viability of
the overall GR solution
For specific insight for your network deployment, Sonus Network Design provides
a variety of consulting services and if design assistance is desired, contact your
Sonus Sales Representative about Sonus Network Design Consulting.
Although Sonus cannot provide recommendations on carrier-specific transport
or SIP products, Sonus Network Design provides a variety of consulting services
and can work with you and your carrier in the design and inclusion of a Sonus
SBC in a Geographically Redundant solution. If design assistance is desired,
contact your Sonus Sales Representative about Sonus Network Design
Consulting.

Sonus Network Design and Engineering

Copyright © 2017, Sonus and/or its affiliates. All rights reserved.