In this section:


IMPORTANT

The SBC 5100, SBC 5110, SBC 5200, and SBC 5210 platforms are no longer supported beginning with the SBC Core 10.0.0R0 release. This release supports SBC 5400/7000/SWe/Cloud Native edition (CNe) platforms. Contact Ribbon Sales for upgrade information.

An IP Interface Group is a named object containing one or more IP interfaces (IP addresses). The IP Interface Group is Address Context-specific (e.g. permanently bound to a particular Address Context), and is the primary tool to manage disjointed networks (separate networks that are not designed to communicate directly). An IP Interface Group is the local manifestation of a segregated network domain. The service section of an IP trunk group and a Signaling Port typically reference an IP Interface Group in order to restrict signaling and/or media activity to that IP Interface Group.

SBC 5400 and SBC 7000 Interfaces

The basic media Ethernet ports structure for the various SBC 7000 series system is shown below.

An IP interface group is "processor-friendly" if all of the interfaces in the group are on physical ports serviced by the same processor.

SBC 5400 Interfaces

The SBC 5400 includes four Ethernet ports serviced by processor 1 as shown below.  Processor 1 services Pkt0, Pkt1, Pkt2, and Pkt3 when configured in 4 x1 Gb interface mode, or it services Pkt0 and Pkt1 if configured in either 2x10 or 2x1 GB mode. Refer to SBC 5400 Media Ports and Operational Modes for more information on the different modes.

SBC 5400 Interface Group Diagram

SBC 7000 Interfaces

The SBC 7000 contains two active/standby Ethernet port pairs (Pkt 0 and Pkt 1) serviced by processors 1 and 2 as shown below.

SBC 7000 Interface Group Diagram

Configuring IP Interface Groups

Previous Behavior

Prior to release 4.2.0, creating IP Interface Groups that were not "processor friendly" was completely disallowed. IP interfaces carried on a physical Ethernet port served by processor 1 could not be combined in an IP Interface Group with IP interfaces carried on a physical Ethernet port served by processor 2.

The SBC 7000 is enhanced to ease some restrictions on which IP Interfaces may coexist in an IP Interface Group.

Feature Functionality From 4.2 Onwards

The previous restrictions are relaxed in certain cases beginning with release 4.2. The user may create IP Interface Groups containing sets of IP interfaces that are not "processor friendly" (i.e. carried on physical Ethernet ports served by separate processors). However, restrictions exist regarding the usage of such Interface Groups.

The new IP Interface Group membership and usage rules are listed below:

  • Each “Application” capable of referencing an interface group is permanently identified as requiring or not requiring processor-friendly groups.
  • Applications requiring processor-friendly groups may only have a configuration reference to processor-friendly groups.
  • Applications not requiring processor-friendly groups may have a configuration reference to any IP Interface group.
Any addition or deletion of an IP Interface to a group, and any creation or deletion of a reference to a group, is permitted at any time as long as the rules above are not violated.

Applications Referencing IP Interface Groups

(tick) = required
(error) = not required

Application

IP Interface Group Reference

"Processor-Friendly"
IP Interface Group

Signaling Port

ipInterfaceGroupName

(tick)

3GPP IMS access IPsecipInterfaceGroupName

(tick)

Trunk Group

mediaIpInterfaceGroupName

(error)

IP ACL rule

ipInterfaceGroup

(tick)

Other application access control refs
(SSH, SNMP, DNS, etc).


(tick)

SBC 5400 Tip

Using ports 0-1 on one side and 2-3 on the other side in a typical inside/outside deployment avoids ill effects of any potential interface group restrictions.

SBC 7000 Tip

Using ports 0 on one side and 1 on the other side in a typical inside/outside deployment avoids ill effects of any potential interface group restrictions.

Configuring Media Interfaces

An IP interface group can be heterogeneous to facilitate configuring a media interface group with mixed IP versions. This is useful to support different versions of signaling and media legs in the same call:

  • SIP Signaling Port will point to IP Interface group for Signaling
  • SIP Trunk group will point to IP Interface group for Media
When creating a SIP signaling port, the default ACL allows all connection types including SSH. User must create a custom ACL to block all connection types to the port except SIP. See CLI Reference Guide for command syntax and examples.

Configuration Examples

CLI examples for creating interfaces and interface group:

% set addressContext default ipInterfaceGroup INTERNAL_IPIG ipInterface IPIF2_200 ceName SonusSBC01A portName pkt2 ipAddress 10.2.2.4 prefix 28 mode outOfService state disabled vlanTag 200 
% set addressContext default ipInterfaceGroup INTERNAL_IPIG ipInterface IPIF3_200 ceName SonusSBC01A portName pkt3 ipAddress 10.2.2.5 prefix 28 mode outOfService state disabled vlanTag 200 
% set addressContext default ipInterfaceGroup EXTERNAL_IPIG ipInterface IPIF0_300 ceName SonusSBC01A portName pkt0 ipAddress 10.3.3.4 prefix 28 mode outOfService state disabled vlanTag 300 
% set addressContext default ipInterfaceGroup EXTERNAL_IPIG ipInterface IPIF1_300 ceName SonusSBC01A portName pkt1 ipAddress 10.3.3.5 prefix 28 mode outOfService state disabled vlanTag 300  
% commit

Enabling media/packet interfaces:

% set addressContext default ipInterfaceGroup INTERNAL_IPIG ipInterface IPIF2_200 mode inService state enabled 
% set addressContext default ipInterfaceGroup INTERNAL_IPIG ipInterface IPIF3_200 mode inService state enabled 
% set addressContext default ipInterfaceGroup EXTERNAL_IPIG ipInterface IPIF0_300 mode inService state enabled 
% set addressContext default ipInterfaceGroup EXTERNAL_IPIG ipInterface IPIF1_300 mode inService state enabled
% commit

Assigning an interface group for media usage:

set addressContext default zone ZONE_EXTERNAL sipTrunkGroup TG_SIP_EXTERNAL media mediaIpInterfaceGroupName EXTERNAL_IPIG
% commit

Configuration Error Examples

The following example shows the error received when attempting to provision a non-media application on a non-friendly interface group. In this example, "LIG3" is configured with interfaces hosted on different ports that span multiple processors.

% set addressContext default zone ZONE_AS sipSigPort 4 state enabled ipAddressV4 10.7.14.179 portNumber 5060 ipInterfaceGroupName LIG3
% commit
Aborted: 'addressContext default zone ZONE_AS sipSigPort': SIP Signaling port cannot use interface group with interfaces on multiple processors.

The following example shows the error received when attempting to add an interface hosted on a different processor to an existing processor-friendly group. All interfaces in the existing group LIG1 are hosted on the same packet port with SIP signaling ports defined.  When an attempt is made to add an interface hosted on another packet port that is serviced by a different processor  (i.e making it processor-unfriendly), the operation is disallowed because applications are already using the group.

% set addressContext default ipInterfaceGroup LIG1 ipInterface LIF1A ceName sbx103.eng.sonusnet.com portName pkt3 ipAddress 10.7.214.178 prefix 16 mode inService state enabled
% commit
Aborted: 'addressContext default ipInterfaceGroup LIG1 ipInterface LIF1A': All IP interfaces in a group must be on the same Network Processor when the group is used by non-media application.

 

  • No labels