DO NOT SHARE THESE DOCS WITH CUSTOMERS!
This is an LA release that will only be provided to a select number of PLM-sanctioned customers (PDFs only). Contact PLM for details.
In this section:
The SBC 51xx and SBC 52xx platforms are not supported from release 11.0.0 onwards. This release supports the SBC 5400, SBC 7000 and SBC SWe platforms.
The basic media Ethernet ports structure for the various SBC 5000 and SBC 7000 series systems is shown below.
The SBC 51x0 includes two Ethernet ports serviced by processor 1 as shown below. Processor 1 services Pkt0 and Pkt1.
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.
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.
The SBC 7000 contains two active/standby Ethernet port pairs (Pkt 0 and Pkt 1) serviced by processors 1 and 2 as shown below.
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.
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:
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.
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:
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
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.