MDM site-level configuration

In the site-parameters, include the MDM credentials that you generated when installing MDM, in the form of a single certificate-type secret. The field name is mdm-certificate-id.

The secret must have all three parameters included: CA certificate, static certificate, and static private key.

In addition, to access MDM, add one or more public keys from the SSH key pair(s) to the ssh section of each MDM instance.

MDM service group

Define one service group containing details of all the MDM VMs.

Networks for the MDM service group

MDM requires two traffic types: management and signaling, which must be on separate subnets.

Note MDM v3.0 or later only requires the management traffic type. Refer to the MDM Overview Guide for further information.

Each MDM instance needs one IP address on each subnet. The management subnet does not necessarily have to be the same as the management subnet that the RVT VMs are assigned to, but the network firewalling and topology does need to allow for communication between the RVT VMs' management addresses and the MDM instances' management addresses, and as such it is simplest to use the same subnet as a matter of practicality.

Product options for the MDM service group

For MDM product options, you must include the consul token and custom topology data.

  • The consul token is an arbitrary, unique string of up to 40 characters (for example, a UUID). Generate it once during MDM installation.

Note

If you are using MDM version 3.0.1 or later, you must specify the consul token as a freeform-type secret. Add it to QSG along with the credentials (certificates and key). In the example snippet of the SDF below, replace the field consul-token with consul-token-id, and the plaintext token value with the secret ID of your secret for the consul token.

  • The custom topology data is a JSON blob describing which VNFCs in the deployment communicate with which other VNFCs through MDM. See the example below. You need to add an entry for group name DNS with no neighbours, and one for each node type in the deployment with the neighbour SAS-DATA. The VMs will be unable to communicate with MDM if the topology is not configured as described.

Note

The group_name syntax is: RVT-<node type>.<site_id>. For example: RVT-tsn.DC1

Use YAML’s |- block-scalar style for the JSON blob, which will keep all newlines except the final one. Overall, the product options should look like this:

vnfcs:
...
- name: mdm
  product-options:
    mdm:
      consul-token: 01234567-abcd-efab-cdef-0123456789ab
      custom-topology: |-
        {
          "member_groups": [
            {
              "group_name": "DNS",
              "neighbors": []
            },
            {
              "group_name": "RVT-tsn.<site_id>",
              "neighbors": ["SAS-DATA"]
            },
            {
              "group_name": "RVT-mag.<site_id>",
              "neighbors": ["SAS-DATA"]
            },
            {
              "group_name": "RVT-shcm.<site_id>",
              "neighbors": ["SAS-DATA"]
            },
            {
              "group_name": "RVT-mmt-gsm.<site_id>",
              "neighbors": ["SAS-DATA"]
            },
            {
              "group_name": "RVT-smo.<site_id>",
              "neighbors": ["SAS-DATA"]
            }
          ]
        }
Previous page Next page
Rhino VoLTE TAS VMs Version 4.1