Last updated on: 2023-08-29 10:06:08.

Frequently asked questions

Consult the following general VNFM and CGNAT Offering-specific frequently asked questions.

What Hypervisors/VIMs are supported?

  • VMware vSphere ESXi Version 6.5
  • VMware Integrated OpenStack (VIO) v5.1
  • OpenStack Newton Version 10
  • OpenStack Queens Version 13

For VNFM version compatibility, consult the Virtual Infrastructure Manager (VIM) compatibility matrix.

For each Service Layer, what module(s) are licenced/provisioned on BIG-IP?

  • CGNAT Offering solution has one layer, the CGNAT Offering layer. Devices in this layer have AFM provisioned.
  • Gi LAN solution has one VNF layer with AFM and PEM provisioned.
  • Gi Firewall solution has one VNF layer with AFM provisioned.
  • DNS solution has one DNS layer with GTM provisioned.
  • DNS Security solution has one DNS-SEC layer with AFM and GTM provisioned.
  • DAG layer has LTM provisioned.

What are the recommended/minimum VM sizes for each component?

Component VM size recommendation
VNFM
  • vCPUs: 4 minimum, 8 recommended
  • RAM: 8GB minimum, 16GB recommended
  • Root Disk Storage: 160GB minimum
DAG
  • vCPUs: 8 minimum
  • RAM: 16GB minimum
  • Root Disk Storage: 160GB
VNF layer
  • vCPUs: 8GB minimum
  • RAM: 16GB minimum
  • Root Disk Storage: 160GB minimum
Nagios
  • vCPUs: 4 minimum
  • RAM: 8GB minimum
  • Root Disk Storage: 60GB minimum

Find this information for OpenStack and VMware in our deployment procedures.

How many VNFM instances are created for the initial deployment in each blueprint solution?

For all solution blueprints (except CGNAT Offering), the following instances are created for the initial deployment:

  • 1 Nagios
  • 2 DAG
  • 1 master and 2 slaves

For CGNAT Offering blueprint solution:

  • 1 Nagios
  • 1 CGNAT Offering VE (configurable by defining the cgnat_ve_default_instances input)

What does Nagios measure for each blueprint to determine scale-out?

For Measure parameters
DAG
  • Traps include:
    • F5-BIGIP-COMMON-MIB::bigipTrafficGroupOffline
    • F5-BIGIP-COMMON-MIB::bigipTrafficGroupForcedOffline
    • F5-BIGIP-COMMON-MIB::bigipLogEmerg
  • Measures: CPU
  • Checks: ICMP
Master VNF
  • Traps include:
    • F5-BIGIP-COMMON-MIB::bigipTrafficGroupOffline
    • F5-BIGIP-COMMON-MIB::bigipTrafficGroupForcedOffline
    • F5-BIGIP-COMMON-MIB::bigipLogEmerg
  • CGNAT Trap: INET_PORT_EXHAUSTION (only for Gi LAN integrated with CGNAT)
  • Measures: CPU
  • Checks: ICMP
Slave VNF
  • Traps include:
    • F5-BIGIP-COMMON-MIB::bigipLogEmerg
    • F5-BIGIP-COMMON-MIB::bigipTrafficGroupOffline
    • F5-BIGIP-COMMON-MIB::bigipTrafficGroupForcedOffline
  • Measures: CPU
  • Checks: ICMP
VNF layer
  • Measures: CPU
VNF group
  • Measures: Throughput

CGNAT Offering

How many VNFM instances are created for the initial deployment of the CGNAT Offering solution blueprint?

  • 1 Nagios
  • 1 CGNAT Offering VE

You can configure the number of CGNAT VE’s you want to create in the initial deployment by using the cgnat_ve_default_instances input. The CGNAT Offering solution will always instantiate only 1 service layer, on the initial deployment as it is impossible to scale the CGNAT Offering layer.

The CGNAT Offering solution differs from the Gi LAN solution in the following ways:

  • No HA across the CGNAT layer
  • Only one group and only one layer that contains all the NAT devices
  • CGNAT Offering layer consists of CGNAT VE’s only, all of which are equal and no split exists between Master and Slave like there is for the Gi LAN solution (no master-slave pairings)

For CGNAT, which translations can be used: BIG-IP VE supports NAPT, PBA, deterministic?

F5 has tested only the port block allocation (PBA) translation mode.

How is redundancy and config sync performed in each CGNAT Offering blueprint?

All blueprints have HA configured EXCEPT the CGNAT Offering solution. The master holds the configuration. If a new instance of slave is added or its configuration is changed, then the master sends its configuration to all instances in the HA group using a forced sync process.

Note

BIG-IP auto-sync process is disabled by default for VNF Manager (VNFM supports BIG-IP manual sync mode only).

How is traffic connected for PGW and PDN in CGNAT Offering blueprint, specifically what are the differences between PGW-side DAG, PDN-side DAG, and DAG-less blueprints?

A CGNAT Offering system does not utilize the PGW_DAG_NET or PDN_DAG_NET networks like the CGNAT for GiLAN/Firewall solutions. Instead, the CGNAT Offering VNF’s are directly connected to the PGW, and PDN networks. The CGNAT-Offering solutions lasks primary or secondary/subordinate nodes, but instead deploys just CGNAT VNF’s in a single scale group. Consult the Post deployment system overview for CGNAT Offering solution diagram for complete connection details.

Can you scale service layers; specifically, scaling Service Layer Groups with no DAG?

The concept of Service Layer groups change with regard to the CGNAT Offering solution as it has no DAG layer. Group and layer scaling is not possible, so you will always have one group and one layer. Scaling is only possible inside the layer (for example, you can add instances to an existing layer for a CGNAT layer by running the scale out workflow on the cgnat_offering_layer type).

What’s Next?

Set up VNFM