Network device config interfaces || CLI || RESTCONF || NETCONF ||

-

 







NETCONF - Network Configuration Protocol

                      get,get-conf

                      edit-conf

                      commit

                      delete


REST - Representational State Transfer

            CRUD operations - Create - POST

                                             Read - GET

                                             Update - PUT & PATCH

                                             Delete - DELETE


gNMI - GRPC network Management interface (google Remote procedure call)




1. NETCONF

Designed for config + validation.

Stateful, transactional → perfect for multi-step changes in production.

Not optimized for high-volume telemetry or web integration.


2. REST / RESTCONF

Lightweight, web-friendly → good for QA, automation scripts, web dashboards.

Limited transactional guarantees → not ideal for multi-step critical configs.


3. gNMI

Focused on telemetry & streaming data (real-time stats, counters, events).

Efficient for hundreds/thousands of devices.

Not meant for interactive CLI-style configuration.




REST-CONF Authentication mechanism




Comments

Post a Comment

Popular posts from this blog

gNMI_with_grafana on containerlabs

-
Image
  root@digi-oss:/home/labadmin/mohan/2jan26_grafana# cat sr_lab.clab.yml name: sr_lab topology:   nodes:     sr1 : {kind: nokia_srlinux, image: ghcr.io/nokia/srlinux:latest, startup-config: sr1.cfg}     sr2 : {kind: nokia_srlinux, image: ghcr.io/nokia/srlinux:latest, startup-config: sr2.cfg}     # gNMIc Collector     gnmic:       kind: linux       image: ghcr.io/openconfig/gnmic:latest       binds: [gnmic-config.yml:/app/gnmic-config.yml:ro]       cmd: "--config /app/gnmic-config.yml subscribe"     # Prometheus TSDB     prometheus:       kind: linux       image: prom/prometheus:latest       binds: [prometheus.yml:/etc/prometheus/prometheus.yml:ro]       ports: ["9090:9090"]     # Grafana Visualization     grafana:       kind: linux       image: grafa...
Read more

EVPN Route type-1 & type-4 in action

-
Image
 Route Type 1: Ethernet Auto-Discovery (A-D) A Type 1 route is advertised by a PE router on a per-Ethernet Segment Identifier (ESI) basis. It is triggered by the presence of a multihomed connection.  Purpose of Type 1 routes Aliasing:  In an all-active multihoming setup, a Type 1 route informs remote PE routers that an Ethernet segment is reachable via multiple PEs. This allows for load-balancing traffic to the same customer device over multiple paths. Fast convergence (Mass MAC Withdrawal):  If a local link to a multihomed customer device fails, the PE sends a withdrawal message for the Type 1 route. Remote PEs can then withdraw all MAC addresses associated with that Ethernet segment, instead of waiting for individual MAC withdrawals, which speeds up convergence. Split-horizon filtering:   The route carries an ESI label to prevent traffic loops in all-active mode. A PE router won't forward broadcast, unknown unicast, and multicast (BUM) traffic back to its sour...
Read more

BGP EVPN TYPE-1 & TYPE-4 in action

-
  🧠 Quick Recap Before Type-4 When an ESI (Ethernet Segment Identifier) is configured on dual-homed leafs: Each leaf advertises: ✅ Type-1 Per-ESI → ESI discovery & mass withdrawal ✅ Type-1 Per-EVI → VLAN (EVI) participation, per-VLAN control Remote VTEPs use these to know who shares the ESI. Now, to decide which leaf forwards BUM traffic (Broadcast, Unknown, Multicast) for each VLAN, they use Type-4 routes . ⚙️ What is a Type-4 Route? Route Type Name Purpose Type-4 Ethernet Segment Route (ES Route) Used for DF election between PEs sharing the same ESI 🔹 Content of Type-4 Route Each PE advertising a shared ESI sends: EVPN Type-4 Route ----------------- - ESI: 0000:0000:0000:0000:000010 - Originating Router’s IP (VTEP IP) - Route Distinguisher - Next Hop: VTEP IP - Extended Communities: - ES-Import RT (derived from ESI) - DF Algorithm (RFC7432 or RFC8584) 🧭 Putting It Together (Flow of Events) Let’s take this topology again: ...
Read more