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.
Note |
---|
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. |
Caption |
---|
0 | Table |
---|
1 | Applications Referencing IP Interface Groups |
---|
|
= required = not required Application | IP Interface Group Reference | "Processor-Friendly" IP Interface Group |
---|
Signaling Port | ipInterfaceGroupName |
| 3GPP IMS access IPsec | ipInterfaceGroupName |
| Trunk Group | mediaIpInterfaceGroupName |
| IP ACL rule | ipInterfaceGroup |
| Other application access control refs (SSH, SNMP, DNS, etc). | |
|
|
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. |
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. |
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
Note |
---|
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:
Code Block |
---|
|
% 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:
Code Block |
---|
|
% 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:
Code Block |
---|
|
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.
Code Block |
---|
|
% 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.
Code Block |
---|
|
% 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. |