Table of Contents
- Introduction
- What Is Network Automation?
- Network Automation Protocols
- What Are YANG and OpenConfig?
- Protocol Comparison
- Real-World Protocol Adoption
- Which Protocol Should You Choose?
- Recommendations
- Summary
Introduction
Modern computer networks are becoming increasingly complex. Managing network devices such as switches, routers, and wireless access points manually is time-consuming and prone to human error.
For this reason, many organizations are adopting Network Automation, which enables centralized management of network infrastructure and allows configuration changes to be performed quickly, consistently, and securely.
One of the key components of network automation is the communication protocol used between management systems and network devices.
In this article, we explain:
- what REST API, RESTCONF, NETCONF, gNMI, and SNMP are
- how these protocols work
- what they are commonly used for
- their advantages and limitations
- which protocol you should choose for network automation
What Is Network Automation?
Network automation is the use of software and programmable interfaces to:
- configure network devices
- monitor infrastructure health
- deploy configuration changes
- collect telemetry data
- respond to network events and failures
Instead of manually logging into each device through SSH and entering commands one by one, administrators can use APIs and automation protocols to perform operations centrally.
Example
Without automation:
- an administrator logs into 50 switches manually
- configuration changes are applied individually on each device
With automation:
- the system pushes the change to all devices simultaneously
- the process takes seconds instead of hours
-
the risk of configuration mistakes is significantly reduced
Network Automation Protocols
The most commonly used network automation protocols include:
- REST API
- RESTCONF
- NETCONF
- gNMI
- SNMP
Each protocol was designed for different use cases and environments.
What Are YANG and OpenConfig?
Modern network automation protocols such as RESTCONF, NETCONF, and gNMI commonly use YANG and OpenConfig models.
What Is YANG?
YANG is a data modeling language used to describe:
- network configuration
- operational device state
- telemetry information
YANG defines how data should be structured and exchanged between devices and automation systems.
What Is OpenConfig?
OpenConfig is a vendor-neutral collection of YANG models designed for multi-vendor network automation.
OpenConfig helps standardize how network devices expose data and configuration through APIs.
This allows automation systems to work with devices from multiple vendors using similar API structures.
What Is REST API?
REST API (Representational State Transfer Application Programming Interface) is one of the most widely used methods of communication between applications and devices.
REST API works similarly to a website:
- a client sends a request
- the device or application responds with data
Communication typically uses HTTP or HTTPS protocols.
How Does REST API Work?
REST APIs use standard HTTP methods:
| Method | Function |
|---|---|
| GET | retrieve data |
| POST | create data |
| PUT | update data |
| DELETE | remove data |
Example
GET https://switch-ip/api/interfaces
The device may return a list of network interfaces in JSON format.
The following REST API example are simplified generic example used for educational purposes.
Modern network operating systems such as SONiC often use RESTCONF and OpenConfig models instead of traditional vendor-specific REST APIs.
Use case: VLAN 100 configuration on the SONiC switch
Example - Adding VLAN 100
curl -X POST http://switch-ip:8080/api/v1/vlans \
-H "Content-Type: application/json" \
-d '{
"VLAN": {
"Vlan100": {
"vlanid": 100
}
}
}'
Legacy REST API vs Modern RESTCONF
In older, community versions of SONiC, a dedicated REST API wrapper was available under the /api/v1/ endpoint (typically listening on port 8080 or 8000). In modern Enterprise SONiC distributions, this legacy API has been completely deprecated and replaced by the unified RESTCONF framework.
Advantages of REST API
- simple to implement
- widely supported by vendors
- easy integration with applications
- human-readable JSON format
-
popular in cloud and DevOps environments
Limitations of REST API
- lack of standardization between vendors
- different API implementations
-
sometimes limited configuration capabilities
When Should You Use REST API?
REST API is a good choice when:
- integrating network devices with web applications
- building custom management portals
- working with DevOps platforms
- requiring a simple automation interface
What Is RESTCONF?
RESTCONF is a network automation protocol based on REST principles.
It was specifically designed for managing network devices.
RESTCONF uses:
- HTTP/HTTPS
- JSON or XML
-
YANG data models
How Does RESTCONF Work?
RESTCONF allows you to:
- retrieve configuration data
- modify configurations
- read operational device status
Unlike traditional REST APIs, RESTCONF uses standardized YANG data models.
This enables multiple vendors and devices to be managed in a more consistent way.
Example - Retrieving information about SONiC switch interfaces
curl -k \ -u admin:YourPaSsWoRd \ -H "Accept: application/yang-data+json" \ https://switch-ip/restconf/data/openconfig-interfaces:interfaces
Example - VLAN 100 configuration on the SONiC Switch
curl -k -X POST "https://switch-ip/restconf/data/openconfig-interfaces:interfaces" \
-H "Content-Type: application/yang-data+json" \
-u "admin:YourPaSsWoRd" \
-d '{
"openconfig-interfaces:interface": [
{
"name": "Vlan100",
"config": {
"name": "Vlan100"
}
}
]
}'
| Parameter | Description |
|---|---|
| -k | ignore self-signed SSL certificates |
| -X | An HTTP method used to create new resources |
| -H | A header informing the switch that we are sending structured data compliant with YANG models in JSON format |
| -u | username and password |
| -d | JSON payload containing OpenConfig VLAN configuration |
| Accept header | request JSON YANG-formatted data |
Advantages of RESTCONF
- more standardized than traditional REST APIs
- easier multi-vendor automation
- integration with YANG models
-
modern network management approach
Limitations of RESTCONF
- less widely supported than REST API
- some vendors implement only partial functionality
-
requires understanding of YANG models
When Should You Use RESTCONF?
RESTCONF is a good choice when:
- building modern automation platforms
- using devices with YANG support
- standardization is important
What Is NETCONF?
NETCONF (Network Configuration Protocol) is a protocol specifically designed for network device configuration management.
NETCONF operates over SSH and uses XML for data exchange.
It is commonly used by telecom operators and large enterprise or data center environments.
How Does NETCONF Work?
NETCONF provides:
- secure configuration management
- configuration validation before deployment
- rollback functionality
-
transactional configuration operations
Example Workflow
- The automation system sends a new configuration
- The device validates the configuration
- Changes are applied only after confirmation
This significantly reduces the risk of configuration errors.
Example - NETCONF XML Request
<get-config>
<source>
<running/>
</source>
</get-config>
Advantages of NETCONF
- strong security
- excellent configuration control
- transactional operations
- standardized architecture
-
YANG model support
Limitations of NETCONF
- more complex than REST APIs
- XML is less human-readable
-
requires greater technical knowledge
When Should You Use NETCONF?
NETCONF is well suited when:
- managing large infrastructures
- configuration reliability is critical
- change validation is required
- building carrier-grade environments
What Is gNMI?
gNMI (gRPC Network Management Interface) is a modern network automation and telemetry protocol.
It was designed for:
- data centers
- cloud environments
-
large-scale infrastructures
gNMI uses:
- gRPC
- Protocol Buffers (Protobuf)
-
YANG models
How Does gNMI Work?
gNMI enables:
- device configuration
- telemetry data collection
- real-time data streaming
The biggest difference compared to older protocols is continuous telemetry streaming.
Devices can automatically send network status updates without constant polling from monitoring systems.
Use case - Retrieving interface telemetry data on Broadcom SONiC
Example - Get interface stats
gnmic -a switch-ip:8080 \ -u admin \ -p YourPaSsWoRd \ --skip-verify \ get \ --path /interfaces/interface[name=Ethernet0]/state/counters \ -e json_ietf
Example - Real-time telemetry streaming
gnmic -a switch-ip:8080 \ -u admin \ -p password \ --insecure \ subscribe \ --path /openconfig-interfaces:interfaces/interface[name=Ethernet0]/state/counters \ --mode sample \ --sample-interval 5s
| Parameter | Description |
|---|---|
| -a <IP>:8080 | The switch's IP address and destination port. |
| -u and -p | Username and password. |
| --insecure or --skip-verify | A flag that bypasses TLS certificate verification (gRPC requires a secure encrypted channel by default; this option allows the use of self-signed certificates). |
| get | A gNMI operation type used to retrieve the configuration state or counters once. |
| --path | An XPath path pointing to a specific resource in the YANG model. |
| -e json_ietf | Specifies the output encoding format. Returns data in IETF-compliant JSON format based on OpenConfig/YANG models. |
| subscribe | gNMI operation type that establishes a continuous session to monitor data changes. |
| --mode sample | Forces the switch to periodically send data at a specified interval, regardless of whether the value has changed. |
| --sample-interval 5s | The time interval (e.g., 5 seconds) between subsequent data transmissions. |
Important Note
Before using the gnmic examples shown in this article, ensure that:
- the telemetry (gNMI) container is running on the SONiC switch;
- the gNMI service is listening on the configured TCP port;
- network connectivity exists between the management workstation and the switch;
- valid user credentials are available;
- the gnmic client is installed on the management workstation.
Advantages of gNMI
- very high performance
- real-time telemetry
- modern architecture
-
excellent scalability
Limitations of gNMI
- more complex deployment
- requires modern hardware and software support
-
limited compatibility with older infrastructure
When Should You Use gNMI?
gNMI is a good choice when:
- building modern data centers
- requiring real-time telemetry
- managing very large infrastructures
- scalability and performance are critical
What Is SNMP?
SNMP (Simple Network Management Protocol) is one of the oldest network management protocols.
For many years, it was the primary method used for monitoring network devices.
SNMP is still widely used in network monitoring systems today.
How Does SNMP Work?
SNMP enables:
- reading device parameters
- monitoring infrastructure status
-
receiving alarms and notifications (SNMP Traps)
Example
A monitoring system can collect:
- CPU utilization
- device temperature
- interface status
- packet error counters
Example - Checking interface status on SONiC switch
snmpwalk -v 2c -c public switch-ip IF-MIB::ifOperStatus
Alternative Example - Using RAW OID
snmpwalk -v 2c -c public switch-ip 1.3.6.1.2.1.2.2.1.8
| Component | Value / OID Description |
|---|---|
| SNMP Version | -v 2c (Standard community-based SNMPv2) |
| Community String | -c public (Default read-only community) |
| Target OID | 1.3.6.1.2.1.2.2.1.8 (Numerical equivalent of IF-MIB::ifOperStatus) |
Important Note
Before using the SNMP examples shown in this article, ensure that:
- SNMP is enabled on the SONiC switch.
- A read-only SNMP community is configured.
- The management workstation has network connectivity to the switch.
- SNMP utilities are installed on the management workstation.
- SNMP MIB packages are installed if symbolic names such as IF-MIB::ifOperStatus are used.
Security Recommendation
Modern environments should use SNMPv3 whenever possible due to improved authentication and encryption capabilities.
Advantages of SNMP
- extremely wide vendor support
- simple deployment
- compatibility with legacy hardware
-
commonly supported by monitoring systems
Limitations of SNMP
- limited configuration capabilities
- older architecture
- less efficient telemetry
-
security concerns in older SNMP versions
When Should You Use SNMP?
SNMP is a good choice when:
- monitoring legacy infrastructure
- using traditional NMS platforms
- requiring basic monitoring capabilities
Protocol Comparison
| Protocol | Main Purpose | Data Format | Security | Modernity |
|---|---|---|---|---|
| REST API | application integration | JSON | high | high |
| RESTCONF | network automation | JSON / XML / OpenConfig | high | high |
| NETCONF | device configuration | XML / OpenConfig | very high | high |
| gNMI | real-time telemetry | Protobuf / OpenConfig | very high | very high |
| SNMP | monitoring | MIB / OID | medium | low |
Real-World Protocol Adoption
| Environment | Common Protocol |
|---|---|
| Legacy enterprise | SNMP |
| Modern enterprise | RESTCONF |
| Service provider | NETCONF |
| Hyperscale datacenter | gNMI |
| DevOps integration | REST API |
Which Protocol Should You Choose?
There is no single perfect protocol for every environment.
The right choice depends on:
- infrastructure type
- network scale
- security requirements
- automation maturity
-
device compatibility
Recommendations
REST API
Choose when:
- simplicity is important
- integrating web applications
- building custom software platforms
RESTCONF
Choose when:
- standardization matters
- deploying modern automation platforms
- using YANG models
NETCONF
Choose when:
- reliable and secure configuration management is required
- managing large-scale networks
- configuration validation is important
gNMI
Choose when:
- real-time telemetry is required
- building cloud or hyperscale environments
- high scalability is needed
SNMP
Choose when:
- monitoring legacy environments
- using existing monitoring systems
- requiring simple infrastructure visibility
Summary
Network automation is becoming a standard requirement in modern IT environments.
REST API, RESTCONF, NETCONF, gNMI, and SNMP solve different problems and are often used together in the same infrastructure.
Key differences include:
- REST API provides simple application integration
- RESTCONF and NETCONF enable standardized configuration management
- gNMI delivers modern real-time telemetry
- SNMP remains widely used for traditional monitoring
Choosing the correct protocol should depend on your organization’s operational requirements and infrastructure capabilities.
If you have any questions related to this article, feel free to reach out to our technical support team.
Happy Networking!
Useful links
For more free resources, visit:
https://stordis.com/free-resources/
Still have questions? You can find more answers in our full FAQ - just follow the link below.
Comments 0
Comments
Please sign in to leave a comment.