{"activeVersionTag":"latest","latestAvailableVersionTag":"latest","collection":{"info":{"_postman_id":"399bd54b-e075-49a1-b6c3-ce09cc9d388c","name":"OpenConfig Modules in RESTCONF","description":"## Composition\n\n\n\n## Models\n\n\"OpenConfig%20Models\"\n\n## Triangulation\n\n\n\n\n\n### Multi-Vendor Network Automation\n\n\n\n### Publication / Subscription\n\n\"\"\n\n### QoS\n\n\n\nWhen a packet arrives at an interface it is initially classified according to the classifier that is described under /qos/interfaces/interface/input/classifier. A classifier consists of a set of term entries, that match on the specified conditions. The actions thatare applied for each classification rule results in assignment to a forwarding-group, along with an optional remark action. A forwarding-group is internal to the device, used for internal (in this case, cross-fabric) scheduling. At the egress interface, a set of queue entries are instantiated based on a scheduler-policy, which defines the set of scheduling actions that are to be applied to packets forwarded on this interface. Queues are created based on the input entries of the different scheduler definitions within the scheduler-policy. A scheduler may set packet markings based on its actions, e.g., marking packets falling within a particular colour within a two-rate three-color (2r3c) scheduler, and packets may optionally be reclassified on egress.\n\nIn the case that a device also implements ingress scheduling - the same primitives are used to describe the behaviour. In this case, rather than queuing and scheduling the packets at the egress forwarding complex, the classified packets are queued and drained by schedulers that are defined at the ingress. The ingress scheduler outputs packets into forwarding groups that are then queued as per the top example in the diagram.\n\nStatistics within the QoS model are related to interfaces - and stored in state containers in /qos/interfaces/interface. This includes statistics that relate to virtual output queues that are instantiated for remote interfaces. In this case, statistics for each egress interface are reported within the ingress interface’s entry in the /qos/interfaces/interface list.\n\n##### Example\n\n``` json\n{\n #\n # The standard definition of an interface, assumed to be facing the customer.\n # \n \"interfaces\": {\n \"interface\": [\n {\n \"config\": {\n \"name\": \"Ethernet42\"\n },\n \"name\": \"Ethernet42\",\n \"subinterfaces\": {\n \"subinterface\": [\n {\n \"config\": {\n \"index\": 0\n },\n \"index\": 0\n }\n ]\n }\n }\n ]\n },\n \"qos\": {\n \"classifiers\": {\n #\n # The specification for the classifier to be applied to an interface.\n # The classifier is applied to IPv4 packets.\n #\n \"classifier\": [\n {\n \"config\": {\n \"name\": \"IN_CUSTOMERIF\",\n \"type\": \"IPV4\"\n },\n \"name\": \"IN_CUSTOMERIF\",\n #\n # The set of terms that are present in the classifier. A\n # logical AND is applied to each condition within the term.\n # If a term is not matched, then the next term is evaluated.\n #\n \"terms\": {\n \"term\": [\n {\n \"conditions\": {\n \"ipv4\": {\n \"config\": {\n \"dscp\": 18\n }\n }\n },\n \"actions\": {\n \"config\": {\n #\n # Packets matching this term (i.e., are DSCP AF21\n # as specified below) are grouped into the 'LOW'\n # forwarding-group.\n #\n \"target-group\": \"LOW\"\n }\n },\n \"config\": {\n \"id\": \"DSCP_AF21\"\n },\n \"id\": \"DSCP_AF21\"\n },\n {\n \"conditions\": {\n \"ipv4\": {\n \"config\": {\n \"dscp\": 30\n }\n }\n },\n \"actions\": {\n \"config\": {\n \"target-group\": \"MEDIUM\"\n }\n },\n \"config\": {\n \"id\": \"DSCP_AF33\"\n },\n \"id\": \"DSCP_AF33\"\n },\n {\n \"conditions\": {\n \"ipv4\": {\n \"config\": {\n \"dscp\": 36\n }\n }\n },\n \"actions\": {\n \"config\": {\n \"target-group\": \"HIGH\"\n }\n },\n \"config\": {\n \"id\": \"DSCP_AF41\"\n },\n \"id\": \"DSCP_AF41\"\n },\n {\n \"conditions\": {\n \"ipv4\": {\n \"config\": {\n \"dscp\": 38\n }\n }\n },\n \"actions\": {\n \"config\": {\n \"target-group\": \"HIGH\"\n }\n },\n \"config\": {\n \"id\": \"DSCP_AF42\"\n },\n \"id\": \"DSCP_AF42\"\n },\n {\n \"conditions\": {\n \"ipv4\": {\n \"config\": {\n \"dscp\": 46\n }\n }\n },\n \"actions\": {\n \"config\": {\n \"target-group\": \"LLQ\"\n }\n },\n \"config\": {\n \"id\": \"DSCP_EF\"\n },\n \"id\": \"DSCP_EF\"\n }\n ]\n }\n }\n ]\n },\n #\n # The definition of the forwarding groups. Each forwarding\n # group has a name, and an output queue. This queue is subsequently\n # serviced based on a particular scheduler.\n #\n \"forwarding-groups\": {\n \"forwarding-group\": [\n {\n \"config\": {\n \"name\": \"HIGH\",\n \"output-queue\": \"GOLD\"\n },\n \"name\": \"HIGH\"\n },\n {\n \"config\": {\n \"name\": \"LLQ\",\n \"output-queue\": \"PRIORITY\"\n },\n \"name\": \"LLQ\"\n },\n {\n \"config\": {\n \"name\": \"LOW\",\n \"output-queue\": \"BRONZE\"\n },\n \"name\": \"LOW\"\n },\n {\n \"config\": {\n \"name\": \"MEDIUM\",\n \"output-queue\": \"SILVER\"\n },\n \"name\": \"MEDIUM\"\n }\n ]\n },\n #\n # For configuration, the interfaces container specifies the\n # binding between the specified classifiers/schedulers and\n # an interface. \n #\n \"interfaces\": {\n \"interface\": [\n {\n \"config\": {\n \"interface-id\": \"Ethernet42.0\"\n },\n #\n # An input classifier is applied to the interface by\n # referencing the classifier name within the /qos/interfaces\n # list.\n #\n \"input\": {\n \"classifers\": {\n \"classifier\": [\n {\n \"config\": {\n \"name\": \"IN_CUSTOMERIF\",\n \"type\": \"IPV4\"\n },\n \"type\": \"IPV4\"\n }\n ]\n }\n },\n \"interface-id\": \"Ethernet42.0\",\n #\n # The scheduler policy to be used for output is referenced below.\n # A single scheduler policy can be applied per interface. The \n # referencing of a scheduler policy also implies that the queues\n # that it drains are created for the interface (or corresponding\n # VoQs on the input interfaces) and telemetry is exported for them.\n #\n \"output\": {\n \"scheduler-policy\": {\n \"config\": {\n \"name\": \"OUT_CUSTOMERIF\"\n }\n }\n }\n }\n ]\n },\n #\n # Queue specifications that will be instantiated on an interface\n # based on the scheduler policy. The queues in this example have no specific\n # configuration, but could have specified buffer sizes, or queue\n # management disciplines.\n #\n \"queues\": {\n \"queue\": [\n {\n \"config\": {\n \"name\": \"BRONZE\"\n },\n \"name\": \"BRONZE\"\n },\n {\n \"config\": {\n \"name\": \"GOLD\"\n },\n \"name\": \"GOLD\"\n },\n {\n \"config\": {\n \"name\": \"PRIORITY\"\n },\n \"name\": \"PRIORITY\"\n },\n {\n \"config\": {\n \"name\": \"SILVER\"\n },\n \"name\": \"SILVER\"\n }\n ]\n },\n #\n # The specification of the scheduler policy. A scheduler policy\n # consists of a set of schedulers, which have a specified sequence.\n # The schedulers describe a set of queueing approaches.\n #\n #\n \"scheduler-policies\": {\n \"scheduler-policy\": [\n {\n \"config\": {\n \"name\": \"OUT_CUSTOMERIF\"\n },\n \"name\": \"OUT_CUSTOMERIF\",\n \"schedulers\": {\n \"scheduler\": [\n {\n \"config\": {\n \"priority\": \"STRICT\",\n \"sequence\": 0\n },\n #\n # The inputs to each scheduler determine the queue(s)\n # that is to be drained by the scheduler term.\n #\n \"inputs\": {\n \"input\": [\n {\n \"config\": {\n \"id\": \"PRIORITY_CLASS\",\n \"queue\": \"PRIORITY\"\n },\n \"id\": \"PRIORITY_CLASS\"\n }\n ]\n },\n #\n # This scheduler term defines a 1r2c policer with a\n # specified CIR which drops packets that exceed the\n # CIR.\n #\n \"one-rate-two-color\": {\n \"config\": {\n \"bc\": 10000,\n \"cir\": \"32000\"\n },\n \"exceed-action\": {\n \"config\": {\n \"drop\": true\n }\n }\n },\n \"sequence\": 0\n },\n {\n \"config\": {\n \"sequence\": 1\n },\n #\n # In this scheduler term, a set of WRR queues are defined\n # to be serviced.\n #\n \"inputs\": {\n \"input\": [\n {\n \"config\": {\n \"id\": \"BRONZE_CLASS\",\n \"queue\": \"BRONZE\",\n \"weight\": \"10\"\n },\n \"id\": \"BRONZE_CLASS\"\n },\n {\n \"config\": {\n \"id\": \"GOLD_CLASS\",\n \"queue\": \"GOLD\",\n \"weight\": \"50\"\n },\n \"id\": \"GOLD_CLASS\"\n },\n {\n \"config\": {\n \"id\": \"SILVER_CLASS\",\n \"queue\": \"SILVER\",\n \"weight\": \"40\"\n },\n \"id\": \"SILVER_CLASS\"\n }\n ]\n },\n \"sequence\": 1\n }\n ]\n }\n }\n ]\n }\n }\n}\n\n ```\n\n### Network Use Cases\n\nThere exist three different network element types which typically exist in today’s networks:\n\n#### Flat L2 switches\n\nThese devices typically have a single 4K VLAN space, provide only Ethernet switching capabilities, and no IP routing. They \ntypically have limited ability to manipulate VLANs. They may support QinQ - and in this case may have the ability to switch on outer-tag, or the (outer,inner) network elements such as OLTs which provide Ethernet-only switching for subscriber traffic.\n\n#### PE routers\n\nThese devices typically act as IP/MPLS provider edge devices - where ports or interfaces can be terminated Layer 2 bridging domains (which may be local-only, or connected to other bridging domains through some form of backbone encapsulation - such as MPLS). In these devices, there is \nessentially the concept of a per-service VLAN space - and more complex VLAN operations may be performed (push, pop, swap etc.).\n\n#### Hybrid Switch Router\n\nThese are network elements that combine both the ability to have switched VLANs within a global VLAN space, with the ability to terminate VLANs into a certain L2 or L3 forwarding table. Essentially, these devices tend to operate as a hybrid between the **PE router** device type and **Flat L2 switch** types defined here - with some implementation-specific complexities.\n\n#### Use Case: Flat Switch, VLAN-aware L2VPN, or Virtual Switch\n\nPicture a flat Layer 2 switch with the following:\n\n- An access interface – where untagged frames should map to a ‘red’ VLAN.\n \n- A trunk interface – which carries two VLANs - green and orange.\n \n\n\n\n##### Example\n\n``` json\n{\n # The global interface list is configured with two interfaces - which are\n # entire ports in this case. These interfaces have no subinterfaces, and\n # simply specify mappings to 802.1q tags on each interface.\n \"interfaces\": {\n \"interface\": {\n \"g0/0/0\": {\n \"ethernet\": {\n \"switched-vlan\": {\n \"config\": {\n # The 'access' interface is marked as such and\n # the VLAN with which untagged frames are associated\n # marked as ID 1042.\n \"interface-mode\": \"ACCESS\",\n \"access-vlan\": 1042\n }\n }\n },\n \"config\": {\n \"description\": \"ACCESS PORT\",\n \"name\": \"g0/0/0\"\n },\n \"name\": \"g0/0/0\"\n },\n \"g1/0/42\": {\n \"ethernet\": {\n \"switched-vlan\": {\n \"config\": {\n # The trunk interface is marked as such, and a list of\n # the VLANs to be accepted on this trunk specified.\n \"trunk-vlans\": [\n 2048,\n 2049\n ],\n \"interface-mode\": \"TRUNK\"\n }\n }\n },\n \"config\": {\n \"description\": \"TRUNK PORT\",\n \"name\": \"g1/0/42\"\n },\n \"name\": \"g1/0/42\"\n }\n }\n },\n \"network-instances\": {\n \"network-instance\": {\n # Despite the fact that the device is a flat switch, a single\n # \"default\" network instance is created, this has the type of\n # 'DEFAULT' - which is specified to mean the global instance in\n # the network-instance model.\n \"DEFAULT\": {\n \"interfaces\": {\n \"interface\": {\n # The interfaces configured globally are associated with\n # this network instance, and hence the VLAN namespace\n # inside it. The port, rather than a subinterface is\n # specified here, as these are switched interfaces.\n \"g0/0/0\": {\n \"config\": {\n \"interface\": \"g0/0/0\",\n \"id\": \"g0/0/0\"\n },\n \"id\": \"g0/0/0\"\n },\n \"g1/0/42\": {\n \"config\": {\n \"interface\": \"g1/0/42\",\n \"id\": \"g1/0/42\"\n },\n \"id\": \"g1/0/42\"\n }\n }\n },\n # Each VLAN which is used in the switch is configured within\n # the network instance.\n \"vlans\": {\n \"vlan\": {\n \"2048\": {\n \"vlan-id\": 2048,\n \"config\": {\n \"vlan-id\": 2048,\n \"name\": \"GREEN\"\n }\n },\n \"2049\": {\n \"vlan-id\": 2049,\n \"config\": {\n \"vlan-id\": 2049,\n \"name\": \"ORANGE\"\n }\n },\n \"1042\": {\n \"vlan-id\": 1042,\n \"config\": {\n \"vlan-id\": 1042,\n \"name\": \"RED\"\n }\n }\n }\n },\n \"config\": {\n \"name\": \"DEFAULT\",\n \"type\": \"DEFAULT\"\n },\n \"name\": \"DEFAULT\"\n }\n }\n }\n}\n\n ```\n\n#### Flat Switch\n\nPicture the following:\n\n- A VLAN terminating into the global table, with IP configuration.\n \n- A VLAN terminating into a Layer 2 switched virtual instance carrying \n multiple VLANs.\n \n- A VLAN terminating into a PWE service.\n \n - A VLAN terminating into a L2VPN service carrying a single VLAN.\n \n - A VLAN terminating into a L3VPN.\n \n\n\n\nIt is notable that in this case, no use of the access-vlan or trunk-vlan leaves is made. Essentially, it is possible to ignore these ‘switched-vlan’ leaves in the case that an explicit network instance is required to forward traffic between ports. This is typical of service provider PE edge devices.\n\nIf there is no case in which a device needs to match multiple VLANs that cannot be specified with a single vlan encapsulation statement, then there is essentially no need to support access-vlan and trunk-vlan on these platforms. The operator does not lose any functionality.\n\nThe vlan leaf is relatively flexible, for example:\n\n- x.y can be used to match outer tag x, inner tag y.\n \n- x.\\* can be used to match all inner tags of outer tag x.\n \n- x..y.z can be used to match inner tag z with outer tags ranging from x to y.\n \n- x..y.a..b can be used to match out tags x to y with inner tags in the range a to b.\n \n- \\*.y can be used to match inner tag y with any outer tag.\n \n\nSome of these options are obviously more flexible than particular hardware may be able to implement, in this case, it is envisaged that the implementation returns a NACK/NOK message to the client - rather than provide a deviation from the model.\n\n##### Example\n\n``` json\n{\n \"config\": {\n \"hostname\": \"asr1k.lon-1a\"\n },\n #\n # The global list of interfaces - in this case, subinterfaces\n # are used for all interfaces whether they are L2 or L3 config\n #\n \"interfaces\": {\n \"interface\": {\n \"t0/12/116\": {\n \"config\": {\n \"description\": \"PE Interface 0\",\n \"name\": \"t0/12/116\"\n },\n \"name\": \"t0/12/116\",\n \"subinterfaces\": {\n \"subinterface\": {\n \"2048\": {\n #\n # A subinterface specified to match on VLAN 2048\n # on the parent \"t0/1/2/116\" interface\n #\n \"index\": 2048,\n \"vlan\": {\n \"config\": {\n \"vlan-id\": 2048\n }\n },\n \"config\": {\n \"index\": 2048,\n \"description\": \"red VLAN instance in L3VRF\"\n },\n #\n # Since this is a L3 interface, it has configuration\n # for IPv4 and IPv6 that correspond to this subint.\n #\n \"ipv4\": {\n \"address\": {\n \"84.18.192.124\": {\n \"ip\": \"84.18.192.124\",\n \"config\": {\n \"ip\": \"84.18.192.124\",\n \"prefix-length\": 24\n }\n }\n }\n },\n \"ipv6\": {\n \"address\": {\n \"2001:4c20::1\": {\n \"ip\": \"2001:4c20::1\",\n \"config\": {\n \"ip\": \"2001:4c20::1\",\n \"prefix-length\": 64\n }\n }\n }\n }\n },\n #\n # The simple L2 interface on the same interface does not\n # use any 'access' or 'trunk' VLAN configuration, but rather\n # specifies the VLAN that it matches. Mapping to the\n # network instance is done explicitly inside the network instance.\n #\n \"1042\": {\n \"index\": 1042,\n \"vlan\": {\n \"config\": {\n \"vlan-id\": 1042\n }\n },\n \"config\": {\n \"index\": 1042,\n \"description\": \"purple VLAN instance in L2VSI\"\n }\n }\n }\n }\n },\n \"g0/0/0\": {\n \"config\": {\n \"description\": \"PE Interface 1\",\n \"name\": \"g0/0/0\"\n },\n \"name\": \"g0/0/0\",\n \"subinterfaces\": {\n \"subinterface\": {\n \"1400\": {\n \"index\": 1400,\n \"vlan\": {\n \"config\": {\n \"vlan-id\": 1400\n }\n },\n \"config\": {\n \"index\": 1400,\n \"description\": \"blue VLAN instance in L2VSI\"\n }\n },\n \"1042\": {\n \"index\": 1042,\n \"vlan\": {\n \"config\": {\n \"vlan-id\": 1042\n }\n },\n \"config\": {\n \"index\": 1042,\n \"description\": \"pink VLAN instance in GLOBAL\"\n },\n \"ipv4\": {\n \"address\": {\n \"192.168.1.2\": {\n \"ip\": \"192.168.1.2\",\n \"config\": {\n \"ip\": \"192.168.1.2\",\n \"prefix-length\": 24\n }\n }\n }\n },\n \"ipv6\": {\n \"address\": {\n \"2001:db8::1\": {\n \"ip\": \"2001:db8::1\",\n \"config\": {\n \"ip\": \"2001:db8::1\",\n \"prefix-length\": 64\n }\n }\n }\n }\n },\n #\n # For the L2 P2P interface, mapping is done in exactly\n # the same way that it is for the L2VSI service above,\n # and again, this is on a subinterface with no config\n # that relates to the access/trunk VLANs\n #\n \"1500\": {\n \"index\": 1500,\n \"vlan\": {\n \"config\": {\n \"vlan-id\": 1500\n }\n },\n \"config\": {\n \"index\": 1500,\n \"description\": \"cyan VLAN instance in L2P2P\"\n }\n }\n }\n }\n },\n \"g0/10/114\": {\n \"config\": {\n \"description\": \"PE Interface 2\",\n \"name\": \"g0/10/114\"\n },\n \"name\": \"g0/10/114\",\n \"subinterfaces\": {\n #\n # This subinterface uses a QinQ match condition such that\n # the frames that are accepted into it are double-tagged.\n # NB: The L2 P2P service could be made to match all inner\n # tags with a match condition on 1042.* - and can be specified\n # with ranges, so that a subset of VLANs can be mapped into\n # the L2 service.\n #\n # Some discussion may be merited as what this means for VLAN\n # re-write within the service, at the moment, we assume that\n # this is implicitly enabled based on the fact that there are\n # different encapsulations at each end of the PWE3 service.\n #\n \"subinterface\": {\n \"10421042\": {\n \"index\": 10421042,\n \"vlan\": {\n \"config\": {\n \"vlan-id\": \"1042.1042\"\n }\n },\n \"config\": {\n \"index\": 10421042,\n \"description\": \"orange VLAN instance in L2P2P\"\n }\n }\n }\n }\n }\n }\n },\n \"hostname\": \"asr1k.lon-1a\",\n #\n # The set of network instances is then specified on the device.\n #\n #\n \"network-instances\": {\n \"network-instance\": {\n \"L2VSI\": {\n #\n # Each network instance has a list of associated interfaces,\n # the matches can be done based on interface (where there is\n # no specific match of encapsulation - as per the previous\n # example), or based on subinterface.\n #\n # The interface/subinterface leaves are separate to allow this\n # to be flexible, and a free-text ID is given to the user to\n # name this connection if req'd.\n #\n \"interfaces\": {\n \"interface\": {\n \"g0/0/0.1400\": {\n \"config\": {\n \"interface\": \"g0/0/0\",\n \"id\": \"g0/0/0.1400\",\n \"subinterface\": 1400\n },\n \"id\": \"g0/0/0.1400\"\n },\n \"t0/12/116.1042\": {\n \"config\": {\n \"interface\": \"t0/12/116\",\n \"id\": \"t0/12/116.1042\",\n \"subinterface\": 1042\n },\n \"id\": \"t0/12/116.1042\"\n }\n }\n },\n \"config\": {\n \"name\": \"L2VSI\"\n },\n \"name\": \"L2VSI\"\n },\n \"L3VRF\": {\n \"interfaces\": {\n \"interface\": {\n \"t0/12/116.2048\": {\n \"config\": {\n \"interface\": \"t0/12/116\",\n \"id\": \"t0/12/116.2048\",\n \"subinterface\": 2048\n },\n \"id\": \"t0/12/116.2048\"\n }\n }\n },\n \"config\": {\n \"name\": \"L3VRF\"\n },\n \"name\": \"L3VRF\"\n },\n \"GLOBAL\": {\n \"interfaces\": {\n \"interface\": {\n \"g0/0/0.1042\": {\n \"config\": {\n \"interface\": \"g0/0/0\",\n \"id\": \"g0/0/0.1042\",\n \"subinterface\": 1042\n },\n \"id\": \"g0/0/0.1042\"\n }\n }\n },\n \"config\": {\n \"name\": \"GLOBAL\"\n },\n \"name\": \"GLOBAL\"\n },\n \"L2P2P\": {\n \"interfaces\": {\n \"interface\": {\n \"g0/0/0.1500\": {\n \"config\": {\n \"interface\": \"g0/0/0\",\n \"id\": \"g0/0/0.1500\",\n \"subinterface\": 1500\n },\n \"id\": \"g0/0/0.1500\"\n },\n \"g0/10/114.1042.1042\": {\n \"config\": {\n \"interface\": \"g0/10/114\",\n \"id\": \"g0/10/114.1042.1042\",\n \"subinterface\": \"1042.1042\"\n },\n \"id\": \"g0/10/114.1042.1042\"\n }\n }\n },\n \"config\": {\n \"name\": \"L2P2P\"\n },\n \"name\": \"L2P2P\"\n }\n }\n }\n}\n\n ```\n\n### Switch / Router Hybrid\n\nIn the case of a switch/router hybrid device it is possible to have switched VLANs on an interface, which then has accompanying subinterfaces that are routed into a particular network instance.\n\nA device which has a trunk port switching VLAN IDs 1024-1030 within the global network instance, and also routes VLAN 100 on the same interface into a private L3 forwarding instance uses the following configuration:\n\n``` json\n{\n \"config\": {\n \"hostname\": \"asr1k.lon-1a\"\n },\n \"interfaces\": {\n \"interface\": {\n \"g0/0/0\": {\n #\n # The switched VLANs are configured directly on the interface\n # such that these packets are associated with the interface\n # which is associated with the top-level interface.\n #\n \"ethernet\": {\n \"switched-vlan\": {\n \"config\": {\n \"trunk-vlans\": [\n 1024,\n 1025,\n \"1026..1030\"\n ],\n \"interface-mode\": \"TRUNK\"\n }\n }\n },\n \"config\": {\n \"name\": \"g0/0/0\"\n },\n \"name\": \"g0/0/0\",\n #\n # Subinterfaces are configured such that the encapsulation matches\n # VLANs that are not specified on the top-level interface. A config\n # which attempts to configure the same interface in multiple contexts\n # is an error.\n #\n \"subinterfaces\": {\n \"subinterface\": {\n \"100\": {\n \"index\": 100,\n \"vlan\": {\n \"config\": {\n \"vlan-id\": 100\n }\n },\n \"config\": {\n \"index\": 100\n },\n \"ipv6\": {\n \"address\": {\n \"2001:DB8::12\": {\n \"ip\": \"2001:DB8::12\",\n \"config\": {\n \"ip\": \"2001:DB8::12\",\n \"prefix-length\": 127\n }\n }\n }\n }\n }\n }\n }\n }\n }\n },\n \"hostname\": \"asr1k.lon-1a\",\n \"network-instances\": {\n \"network-instance\": {\n #\n # The default network instance is configured - the\n # type is DEFAULT-INSTANCE in the top level configuration.\n #\n \"GLOBAL\": {\n \"interfaces\": {\n \"interface\": {\n #\n # The entire interface is then associated with the\n # instance to pick up the 'switched' VLANs on that interface\n #\n \"g0/0/0\": {\n \"config\": {\n \"interface\": \"g0/0/0\",\n \"id\": \"g0/0/0\"\n },\n \"id\": \"g0/0/0\"\n }\n }\n },\n #\n # By configuring VLANs within the network instance, the FDB for each\n # VLAN within the default instance is created.\n #\n \"vlans\": {\n \"vlan\": {\n \"1024\": {\n \"vlan-id\": 1024,\n \"config\": {\n \"vlan-id\": 1024,\n \"name\": \"vlan1024\"\n }\n },\n \"1025\": {\n \"vlan-id\": 1025,\n \"config\": {\n \"vlan-id\": 1025,\n \"name\": \"vlan1025\"\n }\n },\n \"1026\": {\n \"vlan-id\": 1026,\n \"config\": {\n \"vlan-id\": 1026,\n \"name\": \"vlan1026\"\n }\n },\n \"1027\": {\n \"vlan-id\": 1027,\n \"config\": {\n \"vlan-id\": 1027,\n \"name\": \"vlan1027\"\n }\n },\n \"1028\": {\n \"vlan-id\": 1028,\n \"config\": {\n \"vlan-id\": 1028,\n \"name\": \"vlan1028\"\n }\n },\n \"1029\": {\n \"vlan-id\": 1029,\n \"config\": {\n \"vlan-id\": 1029,\n \"name\": \"vlan1029\"\n }\n }\n }\n },\n \"config\": {\n \"type\": \"nit:DEFAULT-INSTANCE\",\n \"name\": \"GLOBAL\"\n },\n \"name\": \"GLOBAL\"\n },\n #\n # If the subinterface is to be associated with a non-default instance\n # this association is configured within that instance.\n #\n \"SOME_VPN\": {\n \"interfaces\": {\n \"interface\": {\n \"SALT-LAKE-CITY-OFFICE\": {\n \"config\": {\n \"interface\": \"g0/0/0\",\n \"id\": \"SALT-LAKE-CITY-OFFICE\",\n \"subinterface\": 100\n },\n \"id\": \"SALT-LAKE-CITY-OFFICE\"\n }\n }\n },\n \"config\": {\n \"type\": \"L3VRF\",\n \"name\": \"SOME_VPN\"\n },\n \"name\": \"SOME_VPN\"\n }\n }\n }\n}\n\n ```\n\n### Routing\n\nOpenConfig models interconnection of RIBs through an explicit `table-connection` list within the `network-instance` model. In order to redistribute routes within protocol A to protocol B, an explicit connection between the tables corresponding to protocol A and protocol B is created.\n\nAn OpenConfig `routing-policy` is specified along with the connection - allowing an operator to apply policies to routes being imported into the destination protocol’s RIB. Such policies are evaluated such that:\n\n- Routes that are rejected by the protocol are not imported into the destination RIB.\n \n- Modifications to attributes of matching routes result in the imported routes in the destination protocol’s RIB being modified, but do not modify the source protocol’s RIB.\n \n\nIt is expected that protocol-specific attributes (e.g., BGP communities) are set by such an import policy, allowing routes that are redistributed to carry information relating to their source (e.g., an IGP route may be tagged with a specific community using policy to indicate its provenance).\n\nIn the absense of an import-policy for table-connections, default-import-policy should take effect. In the absence of both, no routes should be allowed to be redistributed.\n\n### Messaging\n\nThis module is part of the system management model. The Messages module does not itself replace the necessity to configure which messages (eg Severity) are sent to traditional Syslog collectors. That is still done utilizing the /system/logging/remote-servers’ path. This module will however allow for configuration of which messages (eg Severity) are sent over the telemetry interface to the Subscriber.\n\n\n\n```\n+--rw system\n +--rw messages\n +--rw config\n # Config leaf for the Severity of the messages which are sent\n # over the telemetry interface.\n | +--rw severity? syslog-severity\n +--ro state\n | +--ro severity? syslog-severity\n # State leaf for the Syslog message payload (eg the String of data).\n # This is used for both debugging and non-debugging strings.\n | +--ro messages? string\n +--rw debug-entries\n +--rw debug-service* [service]\n +--rw service -> ../config/service\n +--rw config\n # This is the Base identity for configuring a list of debugging\n # operations. For example \"ip ospf hello\".\n | +--rw service? identityref\n # Whether any configured debug services are enabled, and therefore\n # being sent to Subscribers.\n | +--rw enabled? boolean\n +--ro state\n +--ro service? identityref\n +--ro enabled? boolean\n\n ```\n\n### Ethernet VPN\n\nThis page documents how the Openconfig Yang data models can be used to \nimplement different Ethernet VPN (EVPN) solutions. Current \nimplementation covers the following use cases:\n\n- BGP MPLS-Based \n Ethernet VPNs [RFC 7432](https://datatracker.ietf.org/doc/html/rfc7432) \n with VLAN based service.\n \n- Provider Backbone Bridging Combined with \n Ethernet VPN (PBB-EVPN) [RFC
7263](https://datatracker.ietf.org/doc/html/rfc7263) with VLAN based \n service.\n \n- Network Virtualization Overlay (NVO) EVPN [RFC
8365](https://datatracker.ietf.org/doc/html/rfc8365) with VLAN based \n service and symmetric IRB.\n \n\n#### MAC-VRF\n\nA MAC-VRF (A Virtual Routing and Forwarding table for Media Access Control (MAC) addresses) on a Provider Edge (PE) device with EVPN support is instantiated by creating a network instance with the ’type = oc-ni-types:L2VSI’ in combination with the parameters under the ‘/network-instances/network-instance/evpn’ container.\n\nThe presence of the evpn container during the netconf/gRPC request is the indication for the device of the EVPN support in that VRF.\n\n#### EVPN Instance\n\nA PE device can participate in one or more EVPN Instances (EVI). An EVPN Instance spans several PE devices. For each EVI in which the PE participates, a new entry of the evpn-instance container within evpn needs to be created. This enables multi-domain and Data center interconnect use cases.\n\nFor each EVPN Instance the following items can be configured:\n\n- **Unique EVPN Instance Identifier (EVI-ID)**.\n \n- **Data plane encapsulation** (MPLS or NVO (VXLAN) EVPN):\n \n - In each EVPN instance, the type of encapsulation of the traffic between PEs can be selected. This is performed via the ‘**network-instance/evpn/evpn-instances/evpn-instance/config/encapsulation-type**’ container. Note that Currently “**oc-ni-types:MPLS**” and “**oc-ni-types:VXLAN**” can be selected.\n \n - Note that, in the EVPN case, the ´**network-instance/config/encapsulation-typ**e’ has to be ignored. Hence, it allows the creation of two EVPN Instances one EVI with VXLAN and another one with MPLS for a data center interconnect use case.\n \n- **Service type** EVPN defines three different Service Types (VLAN BASED, VLAN BUNDLE and VLAN AWARE). In the current version of EVPN Model in Openconfig, VLAN_BASED is supported.\n \n- **Multicast group and multicast mask** Multicast group address and mask for BUM traffic.\n \n- **Replication mode** The PE may use ingress replication for flooding BUM (Broadcast, Unicast or Multicast) traffic.\n \n- **Route Distinguisher (RD)** associated to the evpn-instance. An RD MUST be unique across all evpn-instances on a PE. The RD is configured using the parameter ‘route-distinguisher’ at this level. It overrides the route-distinguisher value defined under ’network-instance/config’. \n Import and Export Route Target (RT). In order to participate in an EVPN Instance, it is neede to indicate, in the import-export-policy container, the values of the Route Target for import and export.\n \n- **VXLAN** In case VXLAN is used as the data plane encapsulation, use the ‘vxlan’ container to configure the VNI and overlay end point reference.\n \n- **PBB** In case Provider Backbone Bridging (PBB) is combined with Ethernet VPN, use the pbb container to configure the b (backbone) and i components.\n \n\n##### EVPN Instances\n\n``` json\n{\n \"evpn-instances\": {\n \"evpn-instance\": {\n \"config\": {\n \"evi\": \"1001\",\n \"encapsulation-type\": \"oc-ni-types:MPLS\",\n \"service-type\": \"oc-evpn-types:VLAN_BASED\",\n \"route-distinguisher\": \"65000:2\"\n }\n }\n }\n}\n\n ```\n\n#### Ethernet Segment\n\nA customer site is connected to one or more PEs via a set of Ethernet links. That set of links is referred to as an ‘Ethernet segment’ (see RFC 7432 section 5 ) . The Ethernet segments that are associated to the VRF are listed in the ‘/network-instances/network-instance/evpn/ethernet-segments’ container. Each ethernet segment needs the following information:\n\n##### Name\n\nUniquely identifies the ethernet segment. It has only local meaning.\n\n##### ESI Type\n\nRFC 7432 defines several types of identifiers, with explicit rules for the ESI value assignment. Use this field to select the desired type (see table below for the values).\n\n###### ESI Types\n\n| [ESI Type](https://datatracker.ietf.org/doc/html/rfc7432#section-5) | Typedef value | ESI |\n| --- | --- | --- |\n| Type 0 | TYPE_0_OPERATOR_CONFIGURED | Directly configured by the operator |\n| Type 1 | TYPE_1_LACP_BASED | AUTO enum must be used |\n| Type 2 | TYPE_2_BRIDGE_PROTOCOL_BASED | AUTO enum must be used |\n| Type 3 | TYPE_3_MAC_BASED | Directly configured or AUTO enum must be used |\n| Type 4 | TYPE_4_ROUTER_ID_BASED | Directly configured or AUTO enum must be used |\n| Type 5 | TYPE_5_AS_BASED | Directly configured or AUTO enum must be used |\n\n##### ESI\n\nThe ethernet segment identifier can be auto assigned or explicitly configured. In case of autoasign, choose the autotype, otherwise, indicate the identifier.\n\n##### Example of Ethernet segment with directly configured ESI by the operator of type 0\n\n``` json\n{\n \"ethernet-segments\": {\n \"ethernet-segment\": {\n \"name\": \"esi-1\",\n \"config\": {\n \"name\": \"esi-1\",\n \"esi-type \": \"oc-evpn-types:TYPE_0_OPERATOR_CONFIGURED \",\n \"esi\": \"01:00:00:00:00:71:00:00:00:01\",\n \"redundancy-mode\": \"oc-evpn-types:SINGLE_ACTIVE\"\n }\n }\n }\n} \n\n ```\n\n##### Example of Ethernet segment with auto-generated ESI using LACP\n\n``` json\n{\n \"ethernet-segments\": {\n \"ethernet-segment\": {\n \"name\": \"esi-1\",\n \"config\": {\n \"name\": \"esi-2\",\n \"esi-type \": \"oc-evpn-types:TYPE_1_LACP_BASED \",\n \"esi\": \"AUTO\",\n \"redundancy-mode\": \"oc-evpn-types:SINGLE_ACTIVE\"\n }\n }\n }\n}\n\n ```\n\n##### Example of Ethernet segment with directly configured ESI by the operator of type 0 and DF election method preference\n\n``` json\n{\n \"ethernet-segments\": {\n \"ethernet-segment\": {\n \"name\": \"esi-1\",\n \"config\": {\n \"name\": \"esi-1\",\n \"esi-type \": \"oc-evpn-types:TYPE_0_OPERATOR_CONFIGURED\",\n \"esi\": \"01:00:00:00:00:71:00:00:00:01\",\n \"redundancy-mode\": \"oc-evpn-types:SINGLE_ACTIVE\"\n },\n \"df-election\": {\n \"config\": {\n \"df-election\": \"PREFERENCE\",\n \"preference\": \"1\",\n \"revertive\": \"true\",\n \"election-wait-time\": \"3\"\n }\n }\n }\n }\n}\n\n ```\n\n### Telemetry\n\nOpenConfig devices will often have gNMI provisioning and telemetry\n\nHere is the sequence of events that is being addressed in this post. I am starting with Telegraf gathering and collecting gNMI data from network devices. This is being processed into Prometheus metrics that will be scraped by a Prometheus server. Then Grafana will generate graphs on the data that is gathered and processed appropriately.\n\n\n\n
Telegraf Configuration
\n\n``` erlang\n[[inputs.cisco_telemetry_gnmi]]\n addresses = [\"dallas.create2020.ntc.cloud.tesuto.com:50000\"]\n username = \n password = \n ## redial in case of failures after\n redial = \"10s\"\n tagexclude = [\"openconfig-network-instance:/network-instances/network-instance/protocols/protocol/name\"]\n [[inputs.cisco_telemetry_gnmi.subscription]]\n origin = \"openconfig-interfaces\"\n path = \"/interfaces/interface\"\n subscription_mode = \"sample\"\n sample_interval = \"10s\"\n [[inputs.cisco_telemetry_gnmi.subscription]]\n name = \"bgp_neighbor\"\n origin = \"openconfig-network-instance\"\n path = \"/network-instances/network-instance/protocols/protocol/bgp/neighbors/neighbor/state\"\n subscription_mode = \"sample\"\n sample_interval = \"10s\"\n[[outputs.prometheus_client]]\n listen = \":9011\"\n\n ```\n\n##### Focuses on 2 YANG models\n\n- openconfig-interfaces\n \n- openconfig-network-instance\n \n\n\n\n##### gNMI Output – BGP\n\n```\n# HELP bgp_neighbor_messages_received_UPDATE Telegraf collected metric\n# TYPE bgp_neighbor_messages_received_UPDATE untyped\nbgp_neighbor_messages_received_UPDATE{device=\"dallas\",identifier=\"BGP\",name=\"default\",neighbor_address=\"10.0.0.1\",peer_type=\"EXTERNAL\",role=\"leaf\"} 9\nbgp_neighbor_messages_received_UPDATE{device=\"dallas\",identifier=\"BGP\",name=\"default\",neighbor_address=\"10.0.0.17\",peer_type=\"EXTERNAL\",role=\"leaf\"} 0\nbgp_neighbor_messages_received_UPDATE{device=\"dallas\",identifier=\"BGP\",name=\"default\",neighbor_address=\"10.0.0.25\",peer_type=\"EXTERNAL\",role=\"leaf\"} 9\nbgp_neighbor_messages_received_UPDATE{device=\"dallas\",identifier=\"BGP\",name=\"default\",neighbor_address=\"10.0.0.9\",peer_type=\"EXTERNAL\",role=\"leaf\"} 9\n\n ```\n\n\n\n##### gNMI Output - Interfaces\n\n```\ninterface_state_counters_in_octets{device=\"dallas\",name=\"GigabitEthernet0/0/0/0\",role=\"leaf\"} 3.2022595e+07\ninterface_state_counters_in_octets{device=\"dallas\",name=\"GigabitEthernet0/0/0/1\",role=\"leaf\"} 3.077077e+06\ninterface_state_counters_in_octets{device=\"dallas\",name=\"GigabitEthernet0/0/0/2\",role=\"leaf\"} 1.5683204947e+10\ninterface_state_counters_in_octets{device=\"dallas\",name=\"GigabitEthernet0/0/0/3\",role=\"leaf\"} 1.627459e+06\ninterface_state_counters_in_octets{device=\"dallas\",name=\"GigabitEthernet0/0/0/4\",role=\"leaf\"} 1.523158e+06\ninterface_state_counters_in_octets{device=\"dallas\",name=\"GigabitEthernet0/0/0/5\",role=\"leaf\"} 35606\ninterface_state_counters_in_octets{device=\"dallas\",name=\"GigabitEthernet0/0/0/6\",role=\"leaf\"} 35318\ninterface_state_counters_in_octets{device=\"dallas\",name=\"GigabitEthernet0/0/0/7\",role=\"leaf\"} 35550\ninterface_state_counters_in_octets{device=\"dallas\",name=\"GigabitEthernet0/0/0/8\",role=\"leaf\"} 35878\ninterface_state_counters_in_octets{device=\"dallas\",name=\"GigabitEthernet0/0/0/9\",role=\"leaf\"} 36684\ninterface_state_counters_in_octets{device=\"dallas\",name=\"MgmtEth0/RP0/CPU0/0\",role=\"leaf\"} 2.2033861e+07\ninterface_state_counters_in_octets{device=\"dallas\",name=\"Null0\",role=\"leaf\"} 0\ninterface_state_counters_in_octets{device=\"dallas\",name=\"SINT0/0/0\",role=\"leaf\"} 0\n\n ```\n\n#### Outcome\n\n\n\n### REST Verbs\n\nWe are providing full API for configurational data which can be edited (by POST, PUT, PATCH and DELETE). \nFor operational data we only provide GET API.\n\nFor majority of request you can see only config data in examples. That's because we can show only one example per request. The exception when you can see operational data in example is when data are representing operational (config false) container with no config data in it.","schema":"https://schema.getpostman.com/json/collection/v2.0.0/collection.json","isPublicCollection":false,"owner":"11528456","team":1088250,"collectionId":"399bd54b-e075-49a1-b6c3-ce09cc9d388c","publishedId":"2sAYJAfxqx","public":true,"publicUrl":"https://openconfig.etisoftware.com","privateUrl":"https://go.postman.co/documentation/11528456-399bd54b-e075-49a1-b6c3-ce09cc9d388c","customColor":{"top-bar":"FFFFFF","right-sidebar":"303030","highlight":"FF6C37"},"documentationLayout":"classic-double-column","customisation":{"metaTags":[{"name":"description","value":""},{"name":"title","value":""}],"appearance":{"default":"light","themes":[{"name":"dark","logo":null,"colors":{"top-bar":"212121","right-sidebar":"303030","highlight":"FF6C37"}},{"name":"light","logo":null,"colors":{"top-bar":"FFFFFF","right-sidebar":"303030","highlight":"FF6C37"}}]}},"version":"8.10.1","publishDate":"2025-01-08T18:30:44.000Z","activeVersionTag":"latest","documentationTheme":"light","metaTags":{"title":"","description":""},"logos":{"logoLight":null,"logoDark":null}},"statusCode":200},"environments":[],"user":{"authenticated":false,"permissions":{"publish":false}},"run":{"button":{"js":"https://run.pstmn.io/button.js","css":"https://run.pstmn.io/button.css"}},"web":"https://www.getpostman.com/","team":{"logo":"https://res.cloudinary.com/postman/image/upload/t_team_logo_pubdoc/v1/team/52de83af874f462001674ddb9bdc1bfca2ae7a02c72a76650e1d6907bc6253c0","favicon":"https://etisoftware.com/favicon.ico"},"isEnvFetchError":false,"languages":"[{\"key\":\"csharp\",\"label\":\"C#\",\"variant\":\"HttpClient\"},{\"key\":\"csharp\",\"label\":\"C#\",\"variant\":\"RestSharp\"},{\"key\":\"curl\",\"label\":\"cURL\",\"variant\":\"cURL\"},{\"key\":\"dart\",\"label\":\"Dart\",\"variant\":\"http\"},{\"key\":\"go\",\"label\":\"Go\",\"variant\":\"Native\"},{\"key\":\"http\",\"label\":\"HTTP\",\"variant\":\"HTTP\"},{\"key\":\"java\",\"label\":\"Java\",\"variant\":\"OkHttp\"},{\"key\":\"java\",\"label\":\"Java\",\"variant\":\"Unirest\"},{\"key\":\"javascript\",\"label\":\"JavaScript\",\"variant\":\"Fetch\"},{\"key\":\"javascript\",\"label\":\"JavaScript\",\"variant\":\"jQuery\"},{\"key\":\"javascript\",\"label\":\"JavaScript\",\"variant\":\"XHR\"},{\"key\":\"c\",\"label\":\"C\",\"variant\":\"libcurl\"},{\"key\":\"nodejs\",\"label\":\"NodeJs\",\"variant\":\"Axios\"},{\"key\":\"nodejs\",\"label\":\"NodeJs\",\"variant\":\"Native\"},{\"key\":\"nodejs\",\"label\":\"NodeJs\",\"variant\":\"Request\"},{\"key\":\"nodejs\",\"label\":\"NodeJs\",\"variant\":\"Unirest\"},{\"key\":\"objective-c\",\"label\":\"Objective-C\",\"variant\":\"NSURLSession\"},{\"key\":\"ocaml\",\"label\":\"OCaml\",\"variant\":\"Cohttp\"},{\"key\":\"php\",\"label\":\"PHP\",\"variant\":\"cURL\"},{\"key\":\"php\",\"label\":\"PHP\",\"variant\":\"Guzzle\"},{\"key\":\"php\",\"label\":\"PHP\",\"variant\":\"HTTP_Request2\"},{\"key\":\"php\",\"label\":\"PHP\",\"variant\":\"pecl_http\"},{\"key\":\"powershell\",\"label\":\"PowerShell\",\"variant\":\"RestMethod\"},{\"key\":\"python\",\"label\":\"Python\",\"variant\":\"http.client\"},{\"key\":\"python\",\"label\":\"Python\",\"variant\":\"Requests\"},{\"key\":\"r\",\"label\":\"R\",\"variant\":\"httr\"},{\"key\":\"r\",\"label\":\"R\",\"variant\":\"RCurl\"},{\"key\":\"ruby\",\"label\":\"Ruby\",\"variant\":\"Net::HTTP\"},{\"key\":\"shell\",\"label\":\"Shell\",\"variant\":\"Httpie\"},{\"key\":\"shell\",\"label\":\"Shell\",\"variant\":\"wget\"},{\"key\":\"swift\",\"label\":\"Swift\",\"variant\":\"URLSession\"}]","languageSettings":[{"key":"csharp","label":"C#","variant":"HttpClient"},{"key":"csharp","label":"C#","variant":"RestSharp"},{"key":"curl","label":"cURL","variant":"cURL"},{"key":"dart","label":"Dart","variant":"http"},{"key":"go","label":"Go","variant":"Native"},{"key":"http","label":"HTTP","variant":"HTTP"},{"key":"java","label":"Java","variant":"OkHttp"},{"key":"java","label":"Java","variant":"Unirest"},{"key":"javascript","label":"JavaScript","variant":"Fetch"},{"key":"javascript","label":"JavaScript","variant":"jQuery"},{"key":"javascript","label":"JavaScript","variant":"XHR"},{"key":"c","label":"C","variant":"libcurl"},{"key":"nodejs","label":"NodeJs","variant":"Axios"},{"key":"nodejs","label":"NodeJs","variant":"Native"},{"key":"nodejs","label":"NodeJs","variant":"Request"},{"key":"nodejs","label":"NodeJs","variant":"Unirest"},{"key":"objective-c","label":"Objective-C","variant":"NSURLSession"},{"key":"ocaml","label":"OCaml","variant":"Cohttp"},{"key":"php","label":"PHP","variant":"cURL"},{"key":"php","label":"PHP","variant":"Guzzle"},{"key":"php","label":"PHP","variant":"HTTP_Request2"},{"key":"php","label":"PHP","variant":"pecl_http"},{"key":"powershell","label":"PowerShell","variant":"RestMethod"},{"key":"python","label":"Python","variant":"http.client"},{"key":"python","label":"Python","variant":"Requests"},{"key":"r","label":"R","variant":"httr"},{"key":"r","label":"R","variant":"RCurl"},{"key":"ruby","label":"Ruby","variant":"Net::HTTP"},{"key":"shell","label":"Shell","variant":"Httpie"},{"key":"shell","label":"Shell","variant":"wget"},{"key":"swift","label":"Swift","variant":"URLSession"}],"languageOptions":[{"label":"C# - HttpClient","value":"csharp - HttpClient - C#"},{"label":"C# - RestSharp","value":"csharp - RestSharp - C#"},{"label":"cURL - cURL","value":"curl - cURL - cURL"},{"label":"Dart - http","value":"dart - http - Dart"},{"label":"Go - Native","value":"go - Native - Go"},{"label":"HTTP - HTTP","value":"http - HTTP - HTTP"},{"label":"Java - OkHttp","value":"java - OkHttp - Java"},{"label":"Java - Unirest","value":"java - Unirest - Java"},{"label":"JavaScript - Fetch","value":"javascript - Fetch - JavaScript"},{"label":"JavaScript - jQuery","value":"javascript - jQuery - JavaScript"},{"label":"JavaScript - XHR","value":"javascript - XHR - JavaScript"},{"label":"C - libcurl","value":"c - libcurl - C"},{"label":"NodeJs - Axios","value":"nodejs - Axios - NodeJs"},{"label":"NodeJs - Native","value":"nodejs - Native - NodeJs"},{"label":"NodeJs - Request","value":"nodejs - Request - NodeJs"},{"label":"NodeJs - Unirest","value":"nodejs - Unirest - NodeJs"},{"label":"Objective-C - NSURLSession","value":"objective-c - NSURLSession - Objective-C"},{"label":"OCaml - Cohttp","value":"ocaml - Cohttp - OCaml"},{"label":"PHP - cURL","value":"php - cURL - PHP"},{"label":"PHP - Guzzle","value":"php - Guzzle - PHP"},{"label":"PHP - HTTP_Request2","value":"php - HTTP_Request2 - PHP"},{"label":"PHP - pecl_http","value":"php - pecl_http - PHP"},{"label":"PowerShell - RestMethod","value":"powershell - RestMethod - PowerShell"},{"label":"Python - http.client","value":"python - http.client - Python"},{"label":"Python - Requests","value":"python - Requests - Python"},{"label":"R - httr","value":"r - httr - R"},{"label":"R - RCurl","value":"r - RCurl - R"},{"label":"Ruby - Net::HTTP","value":"ruby - Net::HTTP - Ruby"},{"label":"Shell - Httpie","value":"shell - Httpie - Shell"},{"label":"Shell - wget","value":"shell - wget - Shell"},{"label":"Swift - URLSession","value":"swift - URLSession - Swift"}],"layoutOptions":[{"value":"classic-single-column","label":"Single Column"},{"value":"classic-double-column","label":"Double Column"}],"versionOptions":[],"environmentOptions":[{"value":"0","label":"No Environment"}],"canonicalUrl":"https://openconfig.etisoftware.com/view/metadata/2sAYJAfxqx"}