The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
RESTCONF is a REST-like protocol that provides access over HTTP to the two data stores that the controller maintains: the config data store and the operational data store. While you can use the Open SDN Controller GUI to add, modify, delete, or retrieve information stored within those data stores, there are some items that you can access or perform only by submitting a RESTCONF request. We recommend you use a REST client (such as Postman) to simplify the submission of RESTCONF requests.
The following topics describe how to make a RESTCONF request and provide examples of requests that you may need to make:
To make a request using Postman:
The following topics provide RESTCONF requests that you may need to make during the day-to-day administration of your network.
To add devices to the BGPLS Manager topology, complete the following procedure. Before you continue, note the following:
You need to complete Step 4 for every BGP application peer that is connected to a BGP speaker.
In Step 4b, the value you specify for the bgp-peer-id parameter is used by the BGP Best Path Selection algorithm.
Before every RESTCONF request you make, you must first generate a security token. See Making RESTCONF Requests for more information.
Step 1 | Configure the
RIB module on a BGP speaker by making the following POST request, updating the
values for the bgp-rib-id and local-as parameters with the correct values for
the BGP speaker:
(URL—use this for all of the requests in this procedure) https://token:$token@<controller-IP-address>/controller/restconf/config/opendaylight-inventory:nodes/node/controller-config/ yang-ext:mount/config:modules/ (Payload) <module xmlns="urn:opendaylight:params:xml:ns:yang:controller:config"> <type xmlns:x="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">x:rib-impl</type> <name>example-bgp-rib</name> <bgp-rib-id xmlns="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">192.0.2.2</bgp-rib-id> <local-as xmlns="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">64496</local-as> </module> |
Step 2 | If the BGP
speaker supports linkstate attribute type 29, make the following POST request
to change the iana-linkstate-attribute-type value to
true.
Otherwise, proceed to Step 3.
(Payload) <module xmlns="urn:opendaylight:params:xml:ns:yang:controller:config">
<type xmlns:x="urn:opendaylight:params:xml:ns:yang:controller:bgp:linkstate">x:bgp-linkstate</type>
<name>bgp-linkstate</name>
<iana-linkstate-attribute-type xmlns="urn:opendaylight:params:xml:ns:yang:controller:bgp:linkstate">true</iana-linkstate-attribute-type>
</module>
|
Step 3 | Configure the
bgp-peer module on the BGP speaker by making the following POST request,
updating the values for the host and holdtimer parameters for the module (if
necessary):
(Payload) <module xmlns="urn:opendaylight:params:xml:ns:yang:controller:config"> <type xmlns:x="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">x:bgp-peer</type> <name>example-bgp-peer</name> <host xmlns="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">192.0.2.1</host> <holdtimer xmlns="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">180</holdtimer> <rib xmlns="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl"> <type xmlns:x="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:cfg">x:rib</type> <name>example-bgp-rib</name> </rib> <peer-registry xmlns="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl"> <type xmlns:x="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">x:bgp-peer-registry</type> <name>global-bgp-peer-registry</name> </peer-registry> <advertized-table xmlns="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl"> <type xmlns:x="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">x:bgp-table-type</type> <name>ipv4-unicast</name> </advertized-table> <advertized-table xmlns="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl"> <type xmlns:x="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">x:bgp-table-type</type> <name>ipv6-unicast</name> </advertized-table> <advertized-table xmlns="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl"> <type xmlns:x="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">x:bgp-table-type</type> <name>linkstate</name> </advertized-table> </module> |
Step 4 | Register every
BGP application peer that is connected to the BGP speaker you just configured:
|
The following RESTCONF requests are the ones you will most likely make for the OpenFlow-enabled devices in your network. Before every request you make, you must first generate a security token. See Making RESTCONF Requests for more information.
HTTP method—GET
URL—https://token:$token@<controller-IP-address>/controller/restconf/operational/opendaylight-inventory:nodes
HTTP method—GET
URL—https://token:$token@<controller-IP-address>/controller/restconf/operational/network-topology:network-topology/
HTTP method—PUT
URL—https://token:$token@<controller-IP-address>/controller/restconf/config/opendaylight-inventory:nodes/node/openflow:
<OpenFlow-device-ID>/table/<table-ID>/flow/<Flow-ID>
Payload—
<?xml version="1.0" encoding="UTF-8" standalone="no"?> <flow xmlns="urn:opendaylight:flow:inventory"> <strict>false</strict> <flow-name>Flow1</flow-name> <id>1</id> <cookie_mask>255</cookie_mask> <cookie>1</cookie> <idle-timeout>1000</idle-timeout> <table_id>0</table_id> <priority>2</priority> <hard-timeout>1200</hard-timeout> <installHw>false</installHw> <instructions> <instruction> <order>0</order> <apply-actions> <action> <order>0</order> <output-action> <output-node-connector>49</output-node-connector> <max-length>60</max-length> </output-action> </action> </apply-actions> </instruction> </instructions> <match> <ethernet-match> <ethernet-type> <type>2048</type> </ethernet-type> <ethernet-destination> <address>ff:ff:ff:11:12:13</address> </ethernet-destination> <ethernet-source> <address>aa:aa:aa:11:12:13</address> </ethernet-source> </ethernet-match> <ipv4-source>192.0.2.211/8</ipv4-source> <ipv4-destination>203.0.113.137/16</ipv4-destination> <ip-match> <ip-protocol>6</ip-protocol> <ip-dscp>2</ip-dscp> </ip-match> <tcp-source-port>25364</tcp-source-port> <tcp-destination-port>8080</tcp-destination-port> </match> </flow>
Note the following:
HTTP method—GET
URL—https://token:$token@<controller-IP-address>/controller/restconf/config/opendaylight-inventory:nodes/node/openflow:
<Openflow-device-ID>/table/<table-ID>/flow/<Flow-ID>
HTTP method—DELETE
URL—https://token:$token@<controller-IP-address>/controller/restconf/config/opendaylight-inventory:nodes/node/openflow:
<OpenFlow-Device-ID>/table/<table-ID>/flow/<flow-ID>
HTTP method—GET
URL—https://token:$token@<controller-IP-address>/controller/restconf/operational/opendaylight-inventory:nodes/node/openflow:
<OpenFlow-device-ID>/table/<table-ID>/flow/<flow-ID>