1 Overview of the Adapt Cluster Tool
The SAPC configuration can be customized to be adapted to the customer network through the Adapt Cluster Tool. It is possible to modify, for example, the VIP addresses for O&M and traffic, the configuration of the SAPC as Diameter peer, or the IP addresses for the NTP servers.
The purpose of this document is to describe how to set up the Adapt Cluster Tool for the SAPC customization.
2 Prerequisites
- Good understanding and knowledge about networking and routing.
- Good understanding and knowledge about the SAPC networking. Refer to SAPC Network Description and, depending on the type of deployment (Physical Network Function (PNF) or Virtual Network Function (VNF)), BSP 8100 Network Configuration Guide, NSP 6.1 Network Configuration Guide, or SAPC VNF Network Configuration Guide.
- General knowledge about Linux systems and shell commands.
- General knowledge about virtualization and cloud concepts.
- For VNF deployments, the same machine referred in the SAPC VNF Descriptor Generator Tool as preparation server is needed to create the Adapt Cluster Tool configuration file.
3 Customization Tool Execution
The Adapt Cluster Tool execution depends on the SAPC deployment type. The tool needs a configuration file as input for its execution. This configuration file is called adapt_cluster.cfg and the way to create it also depends on the deployment type.
3.1 PNF Deployments
The Adapt Cluster Tool is automatically executed during the SAPC deployment.
Before the procedure execution is explained during this section, the PL_interfaces file has been properly generated.
The adapt_cluster_PNF_BSP.cfg and adapt_cluster_PNF_NSP.cfg configuration files are contained as examples inside the SAPC Virtual Delivery Package (VDP). For further details, refer to SAPC PNF Deployment Instruction. An adapt_cluster.cfg file is used (and also a previously generated PL_interfaces file) as input to generate the adapt_cluster.iso file, which is finally injected to the SAPC SC-1 virtual machine in a CD-ROM/DVD device.
The adapt_cluster.iso file is injected to the SAPC SC-1 virtual machine through the Config-Drive mechanism during deployment time. The Adapt Cluster Tool recognizes internally the injected adapt_cluster.cfg and PL_interfaces files inside the CD-ROM/DVD device and automatically starts its execution taking them as input, during the SC-1 boot-up to perform the customization.
- In the physical blade where the SC-1 virtual
machine is going to be hosted, create the file adapt_cluster.cfg by making a copy of the proper example available in the VDP.Attention!
At this stage, the procedure depends on the hardware.
- BSP 8100
Host_1:# cp /mnt/images/adapt_cluster_PNF_BSP.cfg /mnt/images/adapt_cluster.cfg
- NSP 6.1
Host_1:# cp /mnt/images/adapt_cluster_PNF_NSP.cfg /mnt/images/adapt_cluster.cfg
- BSP 8100
- Modify the adapt_cluster.cfg file,
with the values explained in Section 4:
Host_1:# vi adapt_cluster.cfg
- Generate the adapt_cluster.iso file by executing the following command:
Host_1:# genisoimage -r -joliet-long -o /mnt/images/adapt_cluster.iso /mnt/images/adapt_cluster.cfg /mnt/images/PL_interfaces
The resulting ISO file (/mnt/images/adapt_cluster.iso) already contains the configured adapt_cluster.cfg file and the generated PL_interfaces file, both of them mentioned as prerequisites to this step. The ISO file is ready to be injected to the SAPC SC-1 virtual machine during its boot. No additional intervention is needed to perform this injection.
- The customizations are automatically performed during the SAPC deployment, to be more precise, during the SC-1 boot.
3.2 VNF Deployments
The Adapt Cluster Tool is automatically executed during the SAPC deployment.
The following configuration files are contained as examples inside the SAPC Virtual Delivery Package (VDP). For further details, refer to SAPC VNF Deployment Instruction for VMware or SAPC VNF Deployment Instruction for OpenStack according to the specific configuration:
An adapt_cluster_template.cfg file is used as input and template by the Descriptor Generator Tool to generate, automatically, the adapt_cluster.cfg/.iso file, which is finally included in either the OVF package (.ova file) or the HOT package. See SAPC VNF Descriptor Generator Tool for details about how to use the tool.
For further details about the VDP content and the OVA/HOT package generation process, refer to SAPC VNF Descriptor Generator Tool.
The adapt_cluster.cfg contained in the OVF/HOT package file is injected to the SAPC vApp through the Config-Drive mechanism during deployment time. The Adapt Cluster Tool recognizes internally the injected adapt_cluster.cfg file and automatically starts its execution taking it as input, during the SC-1 boot-up to perform the customization. An analogous procedure is also started in the Virtual Routers (VR) Virtual Machines (when deployed), which are also receiving the adapt_cluster.cfg through Config-Drive to perform internal customizations.
- In the preparation server, save a copy of the original
template configuration file which is chosen to the editing, before
any changes are applied, and previous to the package generation:
PreparationServer:# cp adapt_cluster_template.cfg adapt_cluster_template.cfg_orig
- Modify the adapt_cluster_template.cfg configuration file, with the values explained in Section 4:
PreparationServer:# vi adapt_cluster_template.cfg
- Generate the deployment package according to the SAPC VNF Descriptor Generator Tool document. The resulting deployment package already contains the adapt_cluster.cfg/.iso file to be injected to the proper Virtual Machines in the SAPC.
- The customizations are automatically performed during the SAPC deployment.
adapt_cluster_template_noVr_upgrade.cfg and adapt_cluster_template_noVr_network_separation_upgrade.cfg apply when upgrade by replacement procedure is used to update the system.
3.3 Add Geographical Redundancy to a Live SAPC
Once the SAPC deployment has been performed and the Adapt Cluster Tool automatically executed as explained in Section 3.1 and Section 3.2, the tool can be manually executed in a live SAPC to add Geographical Redundancy.
For further details, refer to Add Active-Active Geographical Redundancy to a Live SAPCand Add Active-Standby Geographical Redundancy to a Live SAPC.
3.4 Adapt Cluster Tool Execution Verification
Once the SAPC has been deployed, it is recommended to check and verify that the Adapt Cluster Tool has performed a correct execution. In any other case, a wrong execution could lead to an improper customization of the SAPC. One of the symptoms is that, for example, there is no connectivity towards the SAPC VIP addresses from external machines.
To verify that the Adapt Cluster Tool has been properly executed and all the configuration parameters have been correctly customized:
- Access the SAPC SC-1 console using the root user-Id and password:
- Check that the output file generated by the Adapt Cluster Tool has
been properly generated. The resulting file is:
SC-1:~ # ls -lrt /cluster/storage/no-backup/adapt/adapt_cluster.cfg.processed
-r--r--r-- 1 root root 1117 Nov 13 11:47 /cluster/storage/no-backup/adapt/adapt_cluster.cfg.processed
If the previous file is not listed, there are two possible reasons:
- The Adapt Cluster Tool execution was erroneous.
- The Adapt Cluster Tool execution has not finished yet.
- Check the log generated by the Adapt Cluster Tool:
SC-1:~ # vi /var/log/adapt_cluster/adapt_cluster.log
- If more lines are being raised to the adapt_cluster.log file, this means that the Adapt Cluster Tool is still executing. Therefore,
wait some minutes more for it to finish.
This progress can be checked by executing:
SC-1:~ # tail -F /var/log/adapt_cluster/adapt_cluster.log
- If this file contains one or more lines like this:
SC-1:~ # ERROR: result code 1
And the following lines do not appear at the end of the file:
2016-11-13 11:47:02 Configuration file has been processed 2016-11-13 11:47:02 Rebooting the cluster ... 2016-11-13 11:47:47 See logs at: /var/log/adapt_cluster/logs
And the final line is:
Exiting ...
This means that there was an error during the Adapt Cluster Tool execution. Therefore, a new execution is manually forced:
SC-1:~ # adapt_cluster start
Wait for the Adapt Cluster Tool execution to finish, and then, repeat this whole procedure. If something is still wrong and the problem was not fixed, contact your next support level.
- Also check and read carefully this log file, looking
for possible error messages reporting an incorrect configuration in
the adapt_cluster.cfg file used for its execution.
In this case, there is a configuration issue:
- For PNF deployments:
- From the blade hosting the SC-1, bring
down all guests.
Host_1:# /mnt/store/SAPC/host-config/scripts/management/sapc_vm-manager_cxp9030138.sh -c stop
- Delete the erroneous adapt_cluster.iso.
Host_1:# rm -rf /mnt/images/adapt_cluster.iso
- Repeat the steps described in section Section 3.1, setting the right configuration in the adapt_cluster.cfg file, and generating the adapt_cluster.iso file again.
- Bring up all guests.
Host_1:# /mnt/store/SAPC/host-config/scripts/management/sapc_vm-manager_cxp9030138.sh -c restart
- From the blade hosting the SC-1, bring
down all guests.
- For VNF deployments:
- Correct the configuration issue in your adapt_cluster_template.cfg file.
- A new .ova file is generated containing a correct adapt_cluster.cfg, and then, a new SAPC deployment is performed using the new .ova file.
- For PNF deployments:
- If the Adapt Cluster Tool execution is correct, the final
lines in the adapt_cluster.log file are:
2017-12-20 11:15:00 Configuration file has been processed 2017-12-20 11:15:00 Rebooting the cluster ... 2017-12-20 11:15:32 See logs at: /var/log/adapt_cluster/logs 2017-12-20 11:18:23 CLUSTER ADAPTATION PROCEDURE 2017-12-20 11:18:23 Starting cluster adaptation ... 2017-12-20 11:18:23 Cluster adaptation configuration search priority: first VNF, then PNF version. 2017-12-20 11:18:23 CEE version: /media/ec2/latest/user-data 2017-12-20 11:18:23 VMWare version: /media/adapt_cluster.cfg 2017-12-20 11:18:23 PNF version: /cluster/storage/no-backup/adapt/adapt_cluster.cfg 2017-12-20 11:18:23 Detected version: /media/ec2/latest/user-data 2017-12-20 11:18:23 Same adaptation already took place. Nothing more to do. 2017-12-20 11:18:23 Exiting ...
- If more lines are being raised to the adapt_cluster.log file, this means that the Adapt Cluster Tool is still executing. Therefore,
wait some minutes more for it to finish.
Finally, contact your next support level if the adapt_cluster.cfg file seems to be correct according to the desired customizations by the customer, and the Adapt Cluster Tool has been properly executed but there are still connectivity problems or any other issues in the SAPC.
4 Adapt Cluster Configuration File Parameters
The Adapt Cluster Tool needs a configuration file as input for its execution. This configuration file is called adapt_cluster.cfg.
The adapt_cluster.cfg configuration
file uses .ini format. On this section,
the sub-sections and parameters to be configured in the adapt_cluster.cfg are detailed.
Some
characteristics provided for each parameter are explained here:
- Configurable: Some parameters are included in the Adapt Cluster Tool configuration file but their value is not configurable. A parameter can be configurable or not, depending on the deployment type (VNF/PNF) or, sometimes, the parameter is included in the configuration file just for information about its value but it cannot be modified.
- Mandatory: A parameter is considered mandatory when it must be explicitly included in the configuration file. For some mandatory parameters, a default value is included in the template configuration files.
- Optional: A parameter is considered optional when it is not necessary that it is included in the configuration file. This is because it has a default value automatically applied by the Adapt Cluster Tool or because it is not necessary for the deployment.
See Section 5 to check the templates provided as an example of this file. All the provided examples use IPv4 network, IPv6-only is also supported. Any IPv6 valid format according to RFC 4291 can be used for the input parameters.
- [Customer] Section
This section is mandatory in the adapt_cluster.cfg file.
|
Attribute |
Configurable |
VNF Deployments Only, PNF Deployments Only, All Deployments |
Mandatory (M), Optional (O) |
Description |
Example |
Default Value |
|---|---|---|---|---|---|---|
|
TIMEZONE |
Yes |
All deployments |
M |
The time zone to be considered by the SAPC as uniform standard time. |
TIMEZONE = Europe/Madrid |
The default value configured in the configuration files provided as examples is: Europe/Madrid |
|
ORIGIN_REALM |
Yes |
All deployments |
O |
Realm used by the SAPC in the Diameter messages. |
ORIGIN_REALM = operatorRealm.com |
The default value is: operatorRealm.com |
|
ORIGIN_HOST |
Yes |
All deployments |
O |
Hostname used by the SAPC in the Diameter messages. |
ORIGIN_HOST = sapcOwnHostId.operatorRealm.com |
The default value is: sapcOwnHostId.operatorRealm.com |
|
DIAMETER_GX_PORT |
Yes |
All deployments |
O |
Port used to listen to Diameter messages both in TCP and SCTP transport layers, for the Gx interface. |
DIAMETER_GX_PORT = 3868 |
The default value is: 3868 |
|
DIAMETER_RX_PORT |
Yes |
All deployments |
O |
Port used to listen to Diameter messages both in TCP and SCTP transport layers, for the Rx interface. |
DIAMETER_RX_PORT = 3869 |
The default value is: 3868 |
|
DIAMETER_SX_PORT |
Yes |
All deployments |
O |
Port used to listen to Diameter messages SCTP transport layers, for the Smp interface. |
DIAMETER_SX_PORT = 3869 |
The default value is: 3869 |
|
NTP_SERVER_IP |
Yes |
VNF deployments only |
O |
The IP address of the Network Time Protocol (NTP) server to be configured in the SAPC. Several NTP servers can be configured. Their IP addresses must be configured in the same line by space-separated. For PNF deployments, the configuration of NTP servers follows a different procedure detailed in SAPC PNF Deployment Instruction. |
NTP_SERVER_IP = 8.8.8.8 9.9.9.9 10.10.10.10 |
|
Attribute |
Configurable |
VNF Deployments Only, PNF Deployments Only, All Deployments |
Mandatory (M), Optional (O) |
Description |
Example |
Default Value |
|---|---|---|---|---|---|---|
|
TIPC_TIMER |
Yes |
All deployments |
O |
TIPC heartbeat. Default and recommended value is 9000 ms |
TIPC_TIMER = 1500 |
The default value is: 9000 milliseconds. |
- [Cluster] Section
This section is mandatory in the adapt_cluster.cfg file.
|
Attribute |
Configurable |
VNF Deployments Only, PNF Deployments Only, All Deployments |
Mandatory (M), Optional (O) |
Description |
Example |
Default Value |
|---|---|---|---|---|---|---|
|
INITIAL_PLS |
No |
All deployments |
M |
Number of PayLoad nodes deployed in the SAPC base installation. |
INITIAL_PLS = 2 |
The default and always delivered value is: 2 |
- [Interface] Section
This section is mandatory in the adapt_cluster.cfg file.
|
Attribute |
Configurable |
VNF Deployments Only, PNF Deployments Only, All Deployments |
Mandatory (M), Optional (O) |
Description |
Example |
Default Value |
|---|---|---|---|---|---|---|
|
SC_IFACE_INDEX |
All deployments |
M |
Number of network interfaces available in the System Controller nodes. In the case of PNF BSP 8100 deployments, there are four network interfaces. In the case of PNF NSP 6.1 deployments, there are three network interfaces. In the case of VNF deployments, this number is equal to 2 + n, where n is the number of Abstract Load Balancers (ALBs) deployed in System Controller nodes. |
|
The default value is included in the configuration files provided as examples. It must be left unchanged in PNF BSP 8100 and PNF NSP 6.1 deployments. It can be modified in VNF deployments only. | |
|
PL_IFACE_INDEX |
All deployments |
M |
Number of network interfaces available in the PayLoad nodes. In the case of PNF BSP 8100 deployments, there are four network interfaces. In the case of PNF NSP 6.1 deployments, there are three network interfaces. In the case of VNF deployments, this number is equal to 2 + n, where n is the number of Abstract Load Balancers (ALBs) deployed in Payload nodes. |
|
The default value is included in the configuration files provided as examples. It must be left unchanged in PNF BSP 8100 and PNF NSP 6.1 deployments. It can be modified in VNF deployments only. | |
|
SC_MAC_PREFIX |
Yes |
All deployments |
The initial four octets to be configured in the MAC addresses of the System Controller nodes. In the case of VNF deployments, this parameter is optional. If not included, System Controllers will be configured with MAC addresses provided by NFVI. If included, System Controllers will be configured with MAC addresses starting with the value of SC_MAC_PREFIX. |
SC_MAC_PREFIX = 02:10:20:3C |
The default value is included in the configuration files provided as examples.(1) | |
|
PL_MAC_PREFIX |
Yes |
All deployments |
The initial four octets to be configured in the MAC addresses of the PayLoad nodes. In the case of VNF deployments, this parameter is optional. If not included, PayLoad nodes will be configured with MAC addresses provided by NFVI. If included, PayLoad nodes will be configured with MAC addresses starting with the value of PL_MAC_PREFIX. |
PL_MAC_PREFIX = 02:10:40:3C |
The default value is included in the configuration files provided as examples. (1) | |
|
BACKPLANE_HA |
No |
PNF deployments only |
O |
NIC bonding at LDE level for the backplane interfaces to guarantee High Availability. |
BACKPLANE_HA = true |
The default and mandatory value is: true |
(1) In some cloud deployments,
this value will not be finally set, and the cloud infrastructure will
determine the MAC addresses to be used.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
Attribute |
Configurable |
VNF Deployments Only, PNF Deployments Only, All Deployments |
Mandatory (M), Optional (O) |
Description |
Example |
Default Value |
|---|---|---|---|---|---|---|
|
SAPC_OM_SC_SH3_NETWORK |
Yes |
PNF deployments only |
M |
Management network which connects the physical blades to their hosted System Controller Virtual Machines. The size of this network is fixed to /24 owing to a limitation in the software. |
SAPC_OM_SC_SH3_NETWORK = 192.168.100.0/24 |
The default value configured in the configuration files provided as examples is: 192.168.100.0/24 |
|
SAPC_OM_SC_SH3_GATEWAY |
Yes |
PNF deployments only |
O |
IP address for the gateway in the management network (SAPC_OM_SC_SH3_NETWORK). In case this parameter is not configured, the first IP address in the management network is considered as gateway. |
SAPC_OM_SC_SH3_NETWORK = 192.168.100.1 |
No value is configured in the configuration files provided as examples. In case this parameter is not configured, the first IP address in the management network is considered as gateway. |
|
SAPC_BOOT_SP_SH_NETWORK |
Yes |
PNF deployments only |
O |
LDE booting and scaling network. For PNF NSP 6.1 deployments, it is the internal network (SAPC_INT_SH_NETWORK). The size of this network is fixed to /24 owing to a limitation in the software. |
SAPC_BOOT_SP_SH_NETWORK = 169.254.69.0/24 |
No value is configured in the configuration files provided as examples. For PNF BSP 8100 deployments, the default value is 169.254.69.0/24 For PNF NSP 6.1 deployments, the default value is the internal network (SAPC_INT_SH_NETWORK). |
|
SAPC_INT_SH_NETWORK |
Yes |
All deployments |
M |
The IP network range and mask assigned to the Internal0 network in the SAPC node for internal communication among all the Virtual Machines. The size of this network is fixed to /24 owing to a limitation in the software. |
SAPC_INT_SH_NETWORK = 172.16.100.0/24 |
The default value configured in the configuration files provided as examples is: 172.16.100.0/24 |
|
Attribute |
Configurable |
VNF Deployments Only, PNF Deployments Only, All Deployments |
Mandatory (M), Optional (O) |
Description |
Example |
Default Value |
|---|---|---|---|---|---|---|
|
<OAM>_FEE_NODEtnoteALB_OAM |
No |
All deployments |
M |
The identifiers of the SAPC nodes with Front-End Elements (FEE) for OAM traffic. This parameter is referred to the System Controllers: SC-1 and SC-2. |
OAM_FEE_NODE = 1 2 |
The default value configured in the configuration files provided as examples is:
|
|
<OAM>_FEE_IFZ_INDEX(1) |
All deployments |
M |
The interface index in the System Controller (SC) nodes attached to the target <OAM>_FEE_NETWORK. (For example the interface index is 0 for nic0, 1 for nic1, and n for nicn.) For VNF deployments, index 0 and index 1 are reserved for Internal0 and Internal1 networks respectively. For VNF deployments, the interface index must match with the number of interfaces defined in SC_IFACE_INDEX. |
The default value is included in the configuration files provided as examples. | ||
|
<OAM>_FEE_VLAN_TAG(1) |
Yes |
PNF deployments only |
M |
VLAN tags for the Front-End Element (FEE) networks for OAM traffic. If the parameter OAM_FEE_HA is configured to true, then, High Availability for the FEEs for OAM traffic is desired. Two VLAN tags must be configured. This implies that two FEEs are created in each node configured in OAM_FEE_NODE, each one of the FEEs using one of the VLAN tags configured in this parameter. If the parameter OAM_FEE_HA is configured to false:
|
|
The default value configured in the configuration files provided (only for PNF deployments) as examples is: |
|
<OAM>_FEE_HA(1) |
No |
All deployments |
O |
If this parameter is configured to true, two Front-End Elements (FEE) are created to guarantee High Availability (HA). In this case, two OAM FEE Networks must be configured (see OAM_FEE_NETWORK parameter). If configured value is false, HA is not guaranteed for this FEE. The parameter is configurable for legacy purposes, but internally it is considered to be always false and it is not recommended to change it. |
OAM_FEE_HA = false |
The default value is:
|
|
<OAM>_FEE_NETWORK(1) |
Yes |
All deployments |
M |
The IP network ranges and masks, space-separated, assigned to the OamVip0 and OamVip1 networks respectively. This network range needs enough IP addresses available for all the defined nodes in OAM_FEE_NODE and for the gateways defined in OAM_FEE_GATEWAY. |
The default value configured in the configuration files provided as examples is: . | |
|
<OAM>_FEE_GATEWAY(1) |
Yes |
All deployments |
O |
The IP addresses of the gateways for the SAPC Front-End Elements (FEE) used in the OAM networks (OamVip0 and OamVip1). These IP addresses are respectively valid IPs in the network ranges configured in OAM_FEE_NETWORK. |
As default value, the Adapt Cluster Tool reserves the first address from each network to the correspondent gateway, so, considering the default networks, the default value is: | |
|
<OAM>_OSPF_AREA(1) |
Yes |
All deployments |
O |
The Open Shortest Path First (OSPF) area defined to include the SAPC OAM networks (OamVip0 and OamVip1) defined in OAM_FEE_NETWORK. For PNF BSP 8100 deployments, this OSPF area is internal. Therefore the default value can be used. For PNF NSP 6.1 deployments, this OSPF area is not internal only. Therefore, the value is configured to a different one from the default. For VNF deployments, this parameter is not applicable with static routing. |
The default value configured in the configuration files provided as examples is: |
(1) The tag <OAM> must match the name given to
the ALB, that is ALB_<OAM>.
Table 8. When different ALBs for traffic are configured during the VIPs configuration, for example, in traffic separation scenarios, the parameters included in next table must be configured for each ALB
|
Attribute |
Configurable |
VNF Deployments Only, PNF Deployments Only, All Deployments |
Mandatory (M), Optional (O) |
Description |
Example |
Default Value |
|---|---|---|---|---|---|---|
|
<TRF>_FEE_NODE(1) |
Yes |
All deployments |
M |
The identifiers of the SAPC nodes with Front-End Elements (FEE) for payload traffic. This parameter is referred to the PayLoad (PL) processors in which traffic FEEs are configured after initial deployment: PL-3, PL-4, PL-5, PL-6, PL-7, and PL-8. |
Example for no traffic separation: TRF_FEE_NODE = 3 4 5 6 7 8 Example for traffic separation: TRF_1_FEE_NODE = 3 4 5 6 7 8 TRF_2_FEE_NODE = 3 4 5 6 7 8 |
The default value configured in the configuration files provided as examples is: |
|
<TRF>_FEE_IFZ_INDEX(1) |
All deployments |
M |
The interface index in the PayLoad (PL) nodes attached to the target <TRF>_FEE_NETWORK. (For example the interface index is 0 for nic0, 1 for nic1, and n for nicn.) For VNF deployments, index 0 and index 1 are reserved for Internal0 and Internal1 networks respectively. For VNF deployments, the interface index must match with the number of interfaces defined in PL_IFACE_INDEX. |
Additional examples to illustrate traffic separation in VNF deployments:
|
The default value is included in the configuration files provided as examples. | |
|
<TRF>_FEE_VLAN_TAG(1) |
Yes |
PNF deployments only |
M |
VLAN tags for the Front End Element (FEE) networks for <TRF> traffic. If the parameter <TRF>_FEE_HA is configured to true, then, High Availability for the FEEs for <TRF> traffic is desired. Two VLAN tags must be configured. This implies that two FEEs are created in each node configured in <TRF>_FEE_NODE, each one of the FEEs using one of the VLAN tags defined in this parameter. If the parameter <TRF>_FEE_HA is configured to false:
|
|
The default value configured in the configuration files provided (only for PNF deployments) as examples is: |
|
<TRF>_FEE_HA(1) |
No |
All deployments |
O |
If this parameter is configured to true, two Front-End Elements (FEE) are created to guarantee High Availability (HA). If configured value is false, HA is not guaranteed for this FEE. The parameter is configurable for legacy purposes, but internally it is considered to be always false and it is not recommended to change it. |
Example for no traffic separation: TRF_FEE_HA = true Example for traffic separation: TRF_1_FEE_HA = true TRF_2_FEE_HA = true |
The default value is:
|
|
<TRF>_FEE_NETWORK(1) |
Yes |
All deployments |
M |
The IP network ranges and masks, space-separated, assigned to the Traffic VIP networks respectively. This network range needs enough IP addresses available for all the defined nodes in <TRF>_FEE_NODE and an extra one for the gateway defined in <TRF>_FEE_GATEWAY. For PNF BSP 8100 deployments, this network is internal. Therefore the default value can be used. For PNF NSP 6.1 deployments, this network is not internal only. Therefore, the value is configured to a different one from the default. In OpenStack cloud deployments, this network is created with a fixed name, IP address assignment, and a wider netmask, that might differ from the setting in adapt_cluster.cfg; this is intended to avoid scaling out errors because of limitations in networking management on the cloud infrastructure. For more information, refer toSAPC VNF Network Configuration Guide. |
Example for no traffic separation: Network ranges assigned to the TrafficVip0-0 and TrafficVip0-1 networks: TRF_FEE_NETWORK = 172.16.113.0/28 172.16.113.16/28 Example for traffic separation: TrafficVip0-0 and TrafficVip0-1 networks: TRF_1_FEE_NETWORK = 172.16.113.0/28 172.16.113.16/28 TrafficVip1-0 and TrafficVip1-1 networks: TRF_2_FEE_NETWORK = 172.16.113.32/28 172.16.113.48/28 |
The default value configured in the configuration files provided as examples is:
If there is traffic separation, the default value configured in the configuration files provided as examples (for VNF deployments), for the secondary Traffic ALB is: 172.16.113.16/28 |
|
<TRF>_FEE_GATEWAY(1) |
No |
All deployments |
O |
The IP addresses of the gateways for the SAPC Front-End Elements (FEE) used in the traffic VIP networks. These IP addresses are respectively valid IPs in the network ranges configured in <TRF>_FEE_NETWORK. |
Additional examples to illustrate the difference when traffic separation is desired (in this case, for VNF deployments): Example for no traffic separation: The IP address for the gateway in the traffic VIP network (TrafficVip0): TRF_FEE_GATEWAY = 172.16.113.1 Example for traffic separation: The IP address for the gateway in the traffic VIP network (TrafficVip0): TRF_1_FEE_GATEWAY = 172.16.113.1 The IP address for the gateway in the traffic VIP network (TrafficVip1): TRF_2_FEE_GATEWAY = 172.16.113.17 |
As default value, the Adapt Cluster Tool reserves the first address from each network to the correspondent gateway, so, considering the default networks, the default value is:
If there is traffic separation, the default value configured in the configuration files provided as examples (for VNF deployments), for the secondary Traffic ALB is: 172.16.113.17 |
|
<TRF>_OSPF_AREA(1) |
Yes |
All deployments |
O |
The Open Shortest Path First (OSPF) area defined to include the SAPC traffic VIP networks configured in <TRF>_FEE_NETWORK. For PNF BSP 8100 deployments, this OSPF area is internal. Therefore the default value can be used. For PNF NSP 6.1 deployments, this OSPF area is not internal only. Therefore, the value is configured to a different one from the default. For VNF deployments, this parameter is not applicable with static routing. |
Additional examples to illustrate the difference when traffic separation is desired (in this case, for VNF deployments with OSPF): Example for no traffic separation: TRF_1_OSPF_AREA = 10.1.13.2 Example for traffic separation: TRF_1_OSPF_AREA = 10.1.13.2 TRF_2_OSPF_AREA = 10.1.13.3 |
The default value configured in the configuration files provided as examples is: If there is traffic separation, the default value configured in the configuration files provided as examples (for VNF deployments with OSPF), for the secondary Traffic ALB is: 10.1.13.3 |
|
SCTP_ALB |
Yes |
All deployments (with traffic separation) |
M |
The name of the ALB for SCTP traffic. As Smp traffic is only supported for SCTP, this parameter shall always point to the ALB used for SX_VIP. |
SCTP_ALB = ALB_TRF_2 |
The default value configured in the configuration files provided as examples is: SCTP_ALB = ALB_TRF_2 |
(1) The tag <TRF> must match the name given
to the ALB, i. e., ALB_<TRF>.
Table 9. When different ALBs for traffic are configured during the VIPs configuration, for example, in traffic separation scenarios, the parameters related to these ALBs must be configured for each of them.
Table 9 describes advanced parameters for Internal-Use only. It is recommended not to use them except for specific purposes.
|
Attribute |
Configurable |
VNF Deployments Only, PNF Deployments Only, All Deployments |
Mandatory (M), Optional (O) |
Description |
Example |
Default Value |
|---|---|---|---|---|---|---|
|
TIPC_TAG |
Yes |
PNF deployments only |
O |
TIPC_TAG = 100 101 |
The default value configured in the configuration files provided (only for PNF deployments) as examples is: TIPC_TAG = 100 101 | |
|
MGMT_TAG |
Yes |
PNF deployments only |
M |
VLAN tag for the internal network for management. For PNF deployments, this VLAN is internal. Therefore the default value can be used. |
MGMT_TAG = 138 |
The default value configured in the configuration files provided (only for PNF deployments) as examples is: MGMT_TAG = 138 |
|
OAM_FEE_ADDRESS |
Yes |
All deployments |
O |
The IP addresses, space-separated, assigned to the FEE nodes in the OamVip0 and OamVip1 networks respectively. |
OAM_FEE_ADDRESS = 172.16.213.2 172.16.213.18 172.16.213.3 172.16.213.19 |
If the parameter is not defined, the Adapt Cluster Tool reserves the first address from each network to the correspondent gateway and from that point, assigns consecutively IP addresses from each OAM network to each FEE node, that is, 172.16.213.2 172.16.213.18 172.16.213.3 172.16.213.19 |
|
OAM_OSPF_HELLO |
Yes |
All deployments |
O |
The HELLO interval in seconds for Open Shortest Path First (OSPF) configured in the FEE nodes for the OamVip0 and OamVip1 networks. If modified, the OSPF configuration in the Virtual Routers must be manually updated accordingly. |
OAM_OSPF_HELLO = 3 |
The default value is: 3 seconds. |
|
OAM_OSPF_DEAD |
Yes |
All deployments |
O |
The DEAD interval in seconds for Open Shortest Path First (OSPF) configured in the FEE nodes for the OamVip0 and OamVip1 networks. Its value must be at least the double plus one second of the value configured in the OAM_OSPF_HELLO parameter. If modified, the OSPF configuration in the Virtual Routers must be manually updated accordingly. |
OAM_OSPF_DEAD = 9 |
The default value is: 9 seconds. |
|
OAM_OSPF_RETRANS |
Yes |
All deployments |
O |
The RETRANSMIT interval in seconds for Open Shortest Path First (OSPF) configured in the FEE nodes for the OamVip0 and OamVip1 networks. If modified, the OSPF configuration in the Virtual Routers must be manually updated accordingly. |
OAM_OSPF_RETRANS = 5 |
The default value is: 5 seconds. |
|
OAM_OSPF_DELAY |
Yes |
All deployments |
O |
The initial schedule DELAY in seconds for Open Shortest Path First (OSPF) configured in the FEE nodes for the OamVip0 and OamVip1 networks. If modified, the OSPF configuration in the Virtual Routers must be manually updated accordingly. |
OAM_OSPF_DELAY = 1 |
The default value is: 1 second. |
|
<TRF>_FEE_ADDRESS(1) |
Yes |
All deployments |
O |
The IP addresses, space-separated, assigned to every FEE node defined <TRF>_FEE_NODE in each of the Traffic VIP networks. |
<TRF>_FEE_ADDRESS = 172.16.113.2 172.16.113.18 172.16.113.3 172.16.113.19 |
If the parameter is not defined, the Adapt Cluster Tool reserves the first address from each network to the correspondent gateway and from that point, assigns consecutively IP addresses from each Traffic network to each FEE node, that is, 172.16.113.2 172.16.113.18 172.16.113.3 172.16.113.19 |
|
<TRF>_OSPF_HELLO(1) |
Yes |
All deployments |
O |
The HELLO interval in seconds for Open Shortest Path First (OSPF) configured in the FEE nodes for the Traffic VIP Networks. If modified, the OSPF configuration in the Virtual Routers must be manually updated accordingly. |
<TRF>_OSPF_HELLO = 3 |
The default value is: 3 seconds. |
|
<TRF>_OSPF_DEAD(1) |
Yes |
All deployments |
O |
The DEAD interval in seconds for Open Shortest Path First (OSPF) configured in the FEE nodes for the Traffic VIP Networks. Its value must be at least the double plus one second of the value configured in the OAM_OSPF_HELLO parameter. If modified, the OSPF configuration in the Virtual Routers must be manually updated accordingly. |
<TRF>_OSPF_DEAD = 9 |
The default value is: 9 seconds. |
|
<TRF>_OSPF_RETRANS(1) |
Yes |
All deployments |
O |
The RETRANSMIT interval in seconds for Open Shortest Path First (OSPF) configured in the FEE nodes for the Traffic VIP Networks. If modified, the OSPF configuration in the Virtual Routers must be manually updated accordingly. |
<TRF>_OSPF_RETRANS = 5 |
The default value is: 5 seconds. |
|
<TRF>_OSPF_DELAY(1) |
Yes |
VNF deployments only |
O |
The initial schedule DELAY in seconds for Open Shortest Path First (OSPF) configured in the FEE nodes for the Traffic VIP Networks. If modified, the OSPF configuration in the Virtual Routers must be manually updated accordingly. |
<TRF>_OSPF_DELAY = 1 |
The default value is: 1 second. |
(1) The tag <TRF> must much the name given to
the ALB, i. e., ALB_<TRF>
- [GeoRed] Section
This section is only mandatory in the adapt_cluster.cfg file for GeoRed configurations for both VNF and PNF deployments.
|
Attribute |
Configurable |
VNF Deployments Only, PNF Deployments Only, All Deployments |
Mandatory (M), Optional (O) |
Description |
Example |
Default Value |
|---|---|---|---|---|---|---|
|
LOCAL_REP_VIP |
Yes |
All deployments |
M |
The local Virtual IP address (VIP) configured for replication traffic between both GeoRed nodes, followed, space-separated, by the Abstract Load Balancer (ALB) to handle this traffic internally in the SAPC node. The ALB name is not configurable, only the VIP address. If a dedicated ALB is desired for replication traffic between both GeoRed nodes, to be created it must be configured according to the explanations provided in Table 8. |
LOCAL_REP_VIP = 200.200.200.201 ALB_REP_1 ATTENTION ALB_REP_1 must be previously configured according to the explanations provided in Table 8. |
No default value is assigned. Execution ended if not configured for GeoRed configurations. |
|
PEER_REP_IP |
Yes |
All deployments |
M |
The remote Virtual IP address (VIP) used for traffic replication between both GeoRed nodes. |
PEER_REP_IP = 200.200.200.202 |
No default value is assigned. Execution ended if not configured for GeoRed configurations. |
|
PREFERRED |
Yes |
All deployments |
M |
The GeoRed node elected as preferred to maintain its database in case of situations when it is not possible to know the node that holds the most up-to-date data. The preferred one is configured with the value 1 and the other one with 0. |
Preferred node in the GeoRed system to be the active one: PREFERRED = 1 In other case: PREFERRED = 0 |
No default value is assigned. Execution ended if not configured for GeoRed configurations. |
|
ACT_ACT |
Yes |
All deployments |
O |
If this parameter is configured to true, Active-Active Geographical redundancy solution is selected. If this parameter is not present, Active-Standby Geographical redundancy solution is selected. |
ACT_ACT = true |
No default value is assigned, so Active-Standby Geographical redundancy solution is the default. |
|
LOCAL_APP_VIP |
Yes |
All deployments |
O |
Only for Active-Active Geographical Redundancy configurations. The local Virtual IP address (VIP) configured for geographical redundancy supervision and control in the Traffic Channel link, followed, space-separated, by the Abstract Load Balancer (ALB) to handle this traffic internally in the SAPC. The VIP address and the ALB name are not configurable, select the VIP address and ALB configured for payload traffic in Table 5. |
LOCAL_APP_VIP = 10.58.31.137 ALB_TRF_1 |
No default value is assigned. Execution ended if not configured for Active-Active Geographical Redundancy configurations. |
|
PEER_APP_IP |
Yes |
All deployments |
O |
Only for Active-Active Geographical Redundancy configurations. The remote Virtual IP address (VIP) used for geographical redundancy supervision and control in the Traffic Channel link between both SAPCs. |
PEER_APP_IP = 10.58.31.138 |
No default value is assigned. Execution ended if not configured for Active-Active Geographical Redundancy configurations. |
- [extDB] Section
This section is only mandatory in the adapt_cluster.cfg file for External database configurations for both VNF and PNF deployments.
|
Attribute |
Configurable |
VNF Deployments Only, PNF Deployments Only, All Deployments |
Mandatory (M), Optional (O) |
Description |
Example |
Default Value |
|---|---|---|---|---|---|---|
|
EXTDB_VIP |
Yes |
All deployments |
M |
The Virtual IP address (VIP) configured for external database traffic, followed, space-separated, by the Abstract Load Balancer (ALB) to handle this traffic internally in the SAPC node. If a dedicated ALB is desired for external database traffic, to be created it must be configured according to the explanations provided in Table 8. |
EXTDB_VIP = 10.51.83.51 ALB_TRF_1 ATTENTION ALB_TRF_1 must be previously configured according to the explanations provided in Table 8. |
No default value is configured given that it depends on a configuration using External Database. If not provided, no External Database VIP is configured in the system. |
- [BusinessEvents] Section
This section is only mandatory in the adapt_cluster.cfg file for EBM configurations for both VNF and PNF deployments.
|
Attribute |
Configurable |
VNF Deployments Only, PNF Deployments Only, All Deployments |
Mandatory (M), Optional (O) |
Description |
Example |
Default Value |
|---|---|---|---|---|---|---|
|
EBM_VIP |
Yes |
All deployments |
M |
The Virtual IP address (VIP) configured for EBM notification streaming, followed, space separated, by the Abstract Load Balancer (ALB) to handle this traffic internally in the SAPC node. A dedicated ALB is desired for the EBM traffic because of the recommendation of configuring an IPSec tunnel between the SAPC and the EBM Server. |
EBM_VIP = 10.51.83.52 ALB_TRF_2 ATTENTION ALB_TRF_2 must be previously configured according to the explanations provided in Table 8. |
No default value is configured as it depends on the configuration that uses EBM. If not provided, no EBM VIP is configured in the system. |
- [VirtualRouters] Section
This section is only mandatory in the adapt_cluster.cfg file for VNF deployments, only if virtual routers are to be deployed.
|
Attribute |
Configurable |
VNF Deployments Only, PNF Deployments Only, All Deployments |
Mandatory (M), Optional (O), Conditional (C) |
Description |
Example |
Default Value |
|---|---|---|---|---|---|---|
|
EXT_OAM_NETWORK |
Yes |
VNF deployments only |
M |
The External OAM traffic network and mask defined from the Virtual Routers (VR) for OAM to the border gateway. |
EXT_OAM_NETWORK = 10.41.30.224/29 |
The default value configured in the configuration files provided as examples is: 10.41.30.224/29 |
|
EXT_OAM_GATEWAY |
Yes |
VNF deployments only |
O |
The IP address of the border gateway that connects the Virtual Routers (VR) for OAM towards outside. This IP address is a valid IP in the network range configured in EXT_OAM_NETWORK. |
EXT_OAM_GATEWAY = 10.41.30.225 |
Only the EXT_OAM_NETWORK definition is mandatory. Remaining parameters to specify the IPs for the gateway, the VRRP and the external interfaces of the VRs are optional. If none of them is statically assigned, then the Adapt Cluster Tool automatically reserves the first free IP address of the network for the gateway, the second for the VRRP between the virtual routers, and the third and fourth for the external interfaces of the Virtual Routers. If any of the parameters is assigned, then this order is modified accordingly. For example, if the gateway is statically assigned, then, the first free IP address of the network is reserved for the VRRP, the second and third for the external interfaces and so on. |
|
EXT_OAM_VRRP_VR |
Yes |
VNF deployments only |
O |
The IP address for the VRRP between both Virtual Routers (VR) for OAM. This IP address is a valid IP in the network range configured in EXT_OAM_NETWORK. |
EXT_OAM_VRRP_VR = 10.41.30.226 |
See EXT_OAM_network |
|
EXT_OAM_IP_VR |
Yes |
VNF deployments only |
O |
The IP addresses for the external interfaces of the Virtual Routers (VR) for OAM. This IP address is a valid IP in the network range configured in EXT_OAM_NETWORK. |
EXT_OAM_IP_VR = 10.41.30.229 10.41.30.230 |
See EXT_OAM_network |
|
EXT_OAM_OSPF_AREA |
Yes |
VNF deployments only |
M |
The Open Shortest Path First (OSPF) area defined among the Virtual Routers (VR) for OAM and the border gateway. |
EXT_OAM_OSPF_AREA = 0.0.0.0 |
The default value configured in the configuration files provided as examples is: 0.0.0.0 There are three possible uses of this parameter:
|
|
EXT_OAM_OSPF_HELLO |
Yes |
VNF deployments only |
O |
The HELLO interval in seconds for Open Shortest Path First (OSPF) in the Virtual Routers External OAM traffic network. |
EXT_OAM_OSPF_HELLO = 3 |
The default value is: 3 seconds. |
|
EXT_OAM_OSPF_DEAD |
Yes |
VNF deployments only |
O |
The DEAD interval in seconds for Open Shortest Path First (OSPF) in the Virtual Routers External OAM traffic network. |
EXT_OAM_OSPF_DEAD = 9 |
The default value is: 9 seconds. |
|
EXT_OAM_OSPF_RETRANS |
Yes |
VNF deployments only |
O |
The RETRANSMIT interval in seconds for Open Shortest Path First (OSPF) in the Virtual Routers External OAM traffic network. |
EXT_OAM_OSPF_RETRANS = 5 |
The default value is: 5 seconds. |
|
EXT_OAM_OSPF_DELAY |
Yes |
VNF deployments only |
O |
The initial schedule DELAY in seconds for Open Shortest Path First (OSPF) in the Virtual Routers External OAM traffic network. |
EXT_OAM_OSPF_DELAY = 1 |
The default value is: 1 second. |
|
EXT_<TRF>_NETWORK(1) |
Yes |
VNF deployments only |
M |
The External traffic network and mask defined from the Virtual Routers (VR) for payload traffic to the border gateway. |
Example for no traffic separation: EXT_TRF_1_NETWORK = 10.41.70.224/29 Example for traffic separation: EXT_TRF_1_NETWORK = 10.41.70.224/29 EXT_TRF_2_NETWORK = 10.41.90.224/29 |
The default value configured in the configuration files provided as examples is: 10.41.70.224/29 If there is traffic separation, the default value configured in the configuration files provided as examples, for the secondary Traffic network is: 10.41.90.224/29 |
|
EXT_<TRF>_GATEWAY(1) |
Yes |
VNF deployments only |
O |
The IP address of the border gateway that connects the Virtual Routers (VR) for payload traffic towards outside. This IP address is a valid IP in the network range configured in EXT_<TRF>_GX_NETWORK. |
Example for no traffic separation: EXT_TRF_1_GATEWAY = 10.41.70.225 Example for traffic separation: EXT_TRF_1_GATEWAY = 10.41.70.225 EXT_TRF_2_GATEWAY = 10.41.90.225 |
Only the EXT_<TRF>_NETWORK definition is mandatory. Remaining parameters to specify the IPs for the gateway, the VRRP and the external interfaces of the VRs are optional. If none of them is statically assigned, then the Adapt Cluster Tool automatically reserves the first free IP address of the network for the gateway, the second for the VRRP betweeen virtual routers and the third and fourth for the external interfaces of the Virtual Routers. If any of the parameters is assigned, then this order is modified accordingly. For example, if the gateway is statically assigned, then, the first free IP address of the network is reserved for the VRRP, the second and third for the external interfaces and so on. |
|
EXT_<TRF>_VRRP_VR(1) |
Yes |
VNF deployments only |
O |
The IP address for the VRRP between both Virtual Routers (VR) for Traffic. This IP address is a valid IP in the network range configured in EXT_<TRF>_NETWORK. |
Example for no traffic separation: EXT_TRF_1_VRRP_VR = 10.41.70.226 Example for traffic separation: EXT_TRF_1_VRRP_VR = 10.41.70.226 EXT_TRF_2_VRRP_VR = 10.41.90.226 |
See EXT_TRF_network |
|
EXT_<TRF>_IP_VR(1) |
Yes |
VNF deployments only |
O |
The IP addresses for the external interfaces of the Virtual Routers (VR) for Traffic. This IP address is a valid IP in the network range configured in EXT_<TRF>_NETWORK. |
Example for no traffic separation: EXT_TRF_1_IP_VR = 10.41.70.229 10.41.70.230 Example for traffic separation: EXT_TRF_1_IP_VR = 10.41.70.229 10.41.70.230 EXT_TRF_2_IP_VR = 10.41.90.229 10.41.90.230 |
See EXT_TRF_network |
|
EXT_<TRF>_OSPF_AREA(1) |
Yes |
VNF deployments only |
M |
The Open Shortest Path First (OSPF) area defined among the Virtual Routers (VR) for payload traffic and the border gateway. |
EXT_TRF_1_OSPF_AREA = 0.0.0.0 |
The default value configured in the configuration files provided as examples is: 0.0.0.0 If there is traffic separation, the default value configured in the configuration files provided as examples, for the secondary Traffic network is: 0.0.0.0 There are three possible uses of this parameter:
|
|
EXT_<TRF>_OSPF_HELLO(1) |
Yes |
VNF deployments only |
O |
The HELLO interval in seconds for Open Shortest Path First (OSPF) in the Virtual Routers External payload traffic network. |
EXT_TRF_1_OSPF_HELLO = 3 |
The default value is: 3 seconds. |
|
EXT_<TRF>_OSPF_DEAD(1) |
Yes |
VNF deployments only |
O |
The DEAD interval in seconds for Open Shortest Path First (OSPF) in the Virtual Routers External payload traffic network. |
EXT_TRF_1_OSPF_DEAD = 9 |
The default value is: 9 seconds. |
|
EXT_<TRF>_OSPF_RETRANS(1) |
Yes |
VNF deployments only |
O |
The RETRANSMIT interval in seconds for Open Shortest Path First (OSPF) in the Virtual Routers External payload traffic network. |
EXT_TRF_1_OSPF_RETRANS = 5 |
The default value is: 5 seconds. |
|
EXT_<TRF>_OSPF_DELAY(1) |
Yes |
VNF deployments only |
O |
The initial schedule DELAY in seconds for Open Shortest Path First (OSPF) in the Virtual Routers External payload traffic network. |
EXT_TRF_1_OSPF_DELAY = 1 |
The default value is: 1 second. |
|
EXT_<TRF>_ROUTES(1) |
Yes |
VNF deployments only |
C |
In case of using traffic separation this parameter is needed to configure the routes in the Virtual Routers to reach external entities. |
Example of just one OCS node in the Sy interface, and Sy traffic separated in a second external traffic network: EXT_TRF_2_ROUTES = 136.225.72.33/32 Example of just three external databases nodes in redundancy, and traffic separated in a third external traffic network: EXT_TRF_3_ROUTES = 136.225.72.9/32 136.225.72.17/32 136.225.72.25/32 |
No default value is provided. If the parameter is not present in the configuration file, no additional routes are configured in the Virtual Routers during deployment time. |
(1) The variable corresponds with the tag assigned
to the corresponding ALB_<TRF>
- [Upgrade] Section
This section is only mandatory in the adapt_cluster.cfg file for VNF deployments, when an upgrade by replacement is to be performed.
|
Attribute |
Configurable |
VNF Deployments Only, PNF Deployments Only, All Deployments |
Mandatory (M), Optional (O), Conditional (C) |
Description |
Example |
Default Value |
|---|---|---|---|---|---|---|
|
LOCAL_UPGRADE_VIP |
Yes |
VNF deployments only |
M |
The Virtual IP address (VIP) configured for OAM traffic in the destination SAPC, followed, space-separated, named the Abstract Load Balancer (ALB) to handle this traffic internally in the SAPC node (ALB_OAM). |
LOCAL_UPGRADE_VIP = 10.200.64.154 ALB_OAM |
No default value is provided. |
|
PEER_UPGRADE_VIP |
Yes |
VNF deployments only |
M |
The Virtual IP address (VIP) configured for OAM traffic in the origin SAPC, followed, space-separated, named the Abstract Load Balancer (ALB) to handle this traffic internally in the SAPC node (ALB_OAM). |
PEER_UPGRADE_VIP = 10.200.81.47 ALB_OAM |
No default value is provided. |
|
LOCAL_REP_VIP |
Yes |
VNF deployments only |
M |
The local Virtual IP address (VIP) configured for replication traffic between both local (destination SAPC) and peer (origin SAPC) nodes, followed, space-separated, by the Abstract Load Balancer (ALB) to handle this traffic internally in the SAPC node (ALB_TRF). |
LOCAL_REP_VIP = 200.200.200.220 ALB_TRF |
No default value is provided. |
|
PEER_REP_VIP |
Yes |
VNF deployments only |
M |
The remote Virtual IP address (VIP) configured for replication traffic between both local (destination SAPC) and peer (origin SAPC) nodes, followed, space-separated, by the Abstract Load Balancer (ALB) to handle this traffic internally in the SAPC node (ALB_TRF). |
PEER_REP_VIP = 200.200.200.219 ALB_TRF |
No default value is provided. |
5 Adapt Cluster Template Examples
Some examples of configuration files for the Adapt Cluster Tool are provided within the SAPC VDP. Once the VDP content is extracted, the adapt_cluster_<descriptive_message>.cfg files are provided to illustrate how a correct template looks, and to be taken as base to start the configuration according to the desired customizations.
Reference List
| Standards |
|---|
| [1] IP Version 6 Addressing Architecture, RFC 4291 |

Contents