In this section:
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 52x0 and SBC 7000 Interfaces
The basic media Ethernet ports structure for the various SBC 5000 and SBC 7000 series systems 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 51x0 Interface
The SBC 51x0 includes two Ethernet ports serviced by processor 1 as shown below. Processor 1 services Pkt0 and Pkt1.
SBC 51x0 Interface Group Diagram
SBC 52x0 Interface
The SBC 52x0 includes four Ethernet ports serviced by processors 1 and 2 as shown below. Processor 1 services Pkt0 and Pkt1, and processor 2 services Pkt2 and Pkt3.
SBC 52x0 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 52x0 and SBC 7000 are enhanced to ease some restrictions on which IP Interfaces may coexist in an IP Interface Group.
These rules do not apply to the SBC 51x0 systems which have only two physical media ports (see Figure 1). IP interfaces from the two physical ports may be configured within the same IP Interface Groups without restriction.
Feature Functionality From 4.2 Onwards
The previous restrictions are relaxed in certain cases beginning with release 4.2. The user may now 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
= required
= not required
Application | IP Interface Group Reference | "Processor-Friendly" |
|---|---|---|
Signaling Port | ipInterfaceGroupName |
|
| 3GPP IMS access IPsec | ipInterfaceGroupName |
|
Trunk Group | mediaIpInterfaceGroupName |
|
IP ACL rule | ipInterfaceGroup |
|
Other application access control refs |
|
SBC 52x0 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.
Overview
Content Tools