MDM site-level configuration

In the site-parameters, include the MDM credentials that you generated when installing MDM:

  • the CA certificate, static certificate, and static private key go into an mdm section of the site-parameters under the keys mdm:ca-certificate, mdm:static-certificate and mdm:private-key respectively

  • the public key from the SSH key pair goes into the ssh section of the site-parameters.

Include the option mdm:ssl-certificate-mangement with the value static.

Copy certificates and keys to the SDF in their plain-text Base64 format, including the BEGIN and END lines, and as a multi-line string using YAML’s |- block-scalar style that keeps all newlines except the final one.

Overall, it should look like this:

site-parameters:
  mdm:
    static-certificate: |-
    ---- BEGIN CERTIFICATE -----
    AAAA.....
    ---- END CERTIFICATE -----

    ca-certificate: |-
    ---- BEGIN CERTIFICATE -----
    BBBB.....
    ---- END CERTIFICATE -----

    private-key: |-
    ---- BEGIN PRIVATE KEY -----
    CCCC.....
    ---- END PRIVATE KEY -----

    ssl-certificate-management: static

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. 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 generated during MDM installation (for example, a UUID).

  • The custom topology data is a JSON blob describing which VNFCs in the deployment communicate with which other VNFCs. 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.

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-<node type 1>.<site_id>",
                            "neighbors": ["SAS-DATA"]
                        },
                        {
                            "group_name": "RVT-<node type 2>.<site_id>",
                            "neighbors": ["SAS-DATA"]
                        },
                        ...
                    ]
                }
    ...
Previous page Next page
Rhino VoLTE TAS VMs Version 4.0.0