In this section:

Related articles:


Overview


In a CNF deployment, the IP addresses allocated to the secondary interfaces of SG, SLB and SC move (floats) around based on the RAC-assigned application role. Even for the OAM pod, the IP address on the management interface (secondary interface) gets allocated based on the installed application role. All the IP addresses configured for the secondary interfaces of various pods are configured through the network segment table.

The network service (NS) pod is responsible for the allocation and movement of the IP addresses for the secondary interfaces (pkt0/pkt1) of the SC pod (launched in the N: K redundancy model) based on the IPs configured in the network segment table with the network segment type as SC.

Because the SLB and SG pod are launched in a 1:1 redundancy model, only one pod will be running an active role at any given instance. Hence, the application running on these pods directly accesses the Network Segment configuration from the CDB and associates the IP address on their respective secondary (pkt0/pkt1) interfaces without the involvement of the Network Service pod. The user can modify the IP allocated to the SLB and SG pods' secondary interface by updating the network segment of type SLB and SG, respectively.

The Network Service pod consists of the following containers:

  • Network Service container 
  • Ribbon Telemetry Agent
  • OAM Proxy

After the OAM dashboard service activates for the SBC CNF deployment, network operators must manually populate the NST with IP address details. The NST (network segment table configuration) information includes the interface name, IP address, prefix, vlan ID, and so forth. 

The Network Service then retrieves the information from the NST through the config-agent. 

The active SC pods then contacts the NS instance assignment of these floating IPs. 

The SG/SLB pods, however, get the IP addresses directly through NST configurations without contacting the NS.


Network Segment Table Configuration

The user inputs the following configurations when launching the CNF (during the Helm install). The SBC CNe uses this information to configure the Network Segment feature.

  • Packet Port Redundancy – Enables port redundancy functionality for packet interfaces.
  • Signaling Packet Interfaces – Signaling packet interfaces are created on SLB POD. For every signaling packet interface, the following information will be taken as input from the user. Two signaling packet interfaces will be created on SLB POD.
    • If "Packet Port Redundancy is disabled"
      • Interface information for every signaling packet interface - (Network name)
    • If "Packet Port Redundancy is enabled"
      • Interface information for every signaling packet interface - (Primary Network name, Secondary Network Name)
  • Media Packet Interfaces - Two media packet interfaces will be created on the SC POD. For every media packet interface, the following information will be taken as input from the user.
    • If "Packet Port Redundancy is disabled"
      • Interface information for every media packet interface - (Network Name)
    • If "Packet Port Redundancy is enabled"
      • Interface information for every media packet interface - (Primary Network name, Secondary Network Name)
  • Management Interface - Management interface will be created only on OAM POD. For every management interface, the following information will be inputted from the user: One management interface will be created on OAM POD.
    • Interface information for every management interface -
    • (Primary Network name, Primary IP address, Secondary Network name, Secondary IP address, prefix, Gateway IP for the management interface, Either IPv4 or IPV6 would be allowed)
  • Primary Internal interface - (Network name)
  • Additional internal interface - (Network name) (Optional)

Notes:

  • All packets packet and management interfaces must be SRIOV interfaces. All internal interfaces need to be virtio interfaces.
  • You can assign the same network name to the media/signaling/management interface.
  • Additional internal interfaces are used only for communication between any service and the DB Cache. If additional interfaces are not provided, the service communication to the DB Cache occurs over the Primary internal interface.