When a Netconf mount is required for instances such as testing a VNF configuration action the below procedure will guide you.

Create the xml required to build the Netconf mount

Example of a Netconf mount xml (vtrafficgen.xml)

vtraffigen.xml example 
<node xmlns="urn:TBD:params:xml:ns:yang:network-topology">
   <node-id>9e1f35bf-bc36-4cab-ae9f-baf44bddd673</node-id>
   <host xmlns="urn:opendaylight:netconf-node-topology">10.0.90.2</host>
   <port xmlns="urn:opendaylight:netconf-node-topology">2831</port>
   <username xmlns="urn:opendaylight:netconf-node-topology">admin</username>
   <password xmlns="urn:opendaylight:netconf-node-topology">admin</password>
   <tcp-only xmlns="urn:opendaylight:netconf-node-topology">false</tcp-only>
   <!-- non-mandatory fields with default values, you can safely remove these if you do not wish to override any of these values-->
   <reconnect-on-changed-schema xmlns="urn:opendaylight:netconf-node-topology">false</reconnect-on-changed-schema>
   <connection-timeout-millis xmlns="urn:opendaylight:netconf-node-topology">20000</connection-timeout-millis>
   <max-connection-attempts xmlns="urn:opendaylight:netconf-node-topology">0</max-connection-attempts>
   <between-attempts-timeout-millis xmlns="urn:opendaylight:netconf-node-topology">2000</between-attempts-timeout-millis>
   <sleep-factor xmlns="urn:opendaylight:netconf-node-topology">1.5</sleep-factor>
   <!-- keepalive-delay set to 0 turns off keepalives-->
   <keepalive-delay xmlns="urn:opendaylight:netconf-node-topology">120</keepalive-delay>
</node>


Submit the REST request to create the Netconf mount

Example curl command used to submit the REST request

Sample curl REST request submission
curl -v --noproxy '*' --user "admin":"Kp8bJ4SXszM0WXlhak3eHlcse2gAw84vaoGGmJvUy2U" -d @vtrafficgen.xml -H "Accept: application/xml" -H "Content-type: application/xml" -X PUT --trace trace.out http://10.12.5.69:8282/restconf/config/network-topology:network-topology/topology/topology-netconf/node/9e1f35bf-bc36-4cab-ae9f-baf44bddd673


Verify Netconf mount submission

Verify Netconf mount was submitted
curl -v --noproxy '*' --user "admin":"Kp8bJ4SXszM0WXlhak3eHlcse2gAw84vaoGGmJvUy2U" -d -H "Accept: application/xml" -H "Content-type: application/xml" -X GET http://10.12.5.69:8282/restconf/config/network-topology:network-topology/topology/topology-netconf/node/9e1f35bf-bc36-4cab-ae9f-baf44bddd673

Verify the Netconf mount was created and able to connect to the VNF


Test the Netconf mount


Follow the test note to the further action requests in APPC:

APPC ONAP Testing Requests




  • No labels

2 Comments

  1. Sudhakar Reddy

    Hi,

    While running Closed loop vFW usecase, Policy is sending Action as "Modifyconfig" on APPC-CL topic.

    This action is not there in VNF_DG_MAPPING table (but APPC accepts the request and configures the packet generator also)

    please help me understand which DG APP-C is calling and how it is resolving based on the action.

    APPC request body for reference: 

    "{ "CommonHeader": {
    "TimeStamp": 1531921685621,
    "APIver": "1.01",
    "RequestID": "7ccbfc1b-4455-4d06-8feb-0c56313eb286",
    "SubRequestID": "1",
    "RequestTrack": [],
    "Flags": [] },
    "Action": "ModifyConfig",
    "Payload": { "generic-vnf.vnf-id": "de068494-6495-4568-aed6-168837faa3f8",
    "pg-streams": {
    "pg-stream": [
    {
    "id": "fw_udp1",
    "is-enabled": "true"
    }
    ]
    }
    }
    }"

  2. Brian Freeman

    Is the example payload sent to the LCM_API via the config-modify operation the same in Casablanca as in Beijing ?