All_About_Netconf

-

 



Transport-level keepalive

  • NETCONF over SSH (most common)  Uses SSH keepalive
  • NETCONF over TLS Uses TLS keepalive / TCP keepalive
  • NETCONF over TCP Relies on TCP keepalive
  • Application-level “soft keepalive” (common practice)**Although not mandated, many clients periodically send lightweight RPCs:


Hello-Message Exchange 'Capabilities'

  1. base:1.0
  2. base:1.1
  3. candidate -Enables candidate → commit workflow, Safer than editing running directly
  4. writable-running -Allows editing running directly
  5. confirmed-commit   - Auto-rollback if device becomes unreachable
  6. rollback-on-error  - Roll back changes if any error occurs in <edit-config>
  7. lock  -Prevents concurrent config edits
  8. xpath  - Filtering & Query Critical for large YANG models
  9. notification - Enables event subscriptions
  10. validate - Validate config before commit

1️.Standard NETCONF Datastores (RFC 6241)
These are the core datastores defined by NETCONF.
🔹 running
Active configuration
Always present
🔹 candidate
Staged configuration
Optional
🔹 startup
Boot-time configuration


Optional

2️.Operational Datastore (<operational> / <state>)
🔹 Operational / State datastore
Read-only
Holds runtime state, not configuration

Examples:
Interface counters
Routing table
BGP neighbors
CPU / memory
Accessed via:
<get/>
Often called:
state
operational
running-state (vendor term)
Not editable

3️.Ephemeral Datastore (RFC 8072)
🔹 ephemeral
Temporary configuration
Lost on:
Reboot
Session end
Used for:
Dynamic policies
Temporary ACLs
SDN controller pushes
Capability:
urn:ietf:params:netconf:capability:ephemeral:1.0
Rare but important in modern controllers

4.Intended Datastore (RFC 8342)
🔹 intended
Describes desired configuration
Used in model-driven telemetry
Helps detect config drift
Read-only
Mostly conceptual but increasingly supported

5️.Dynamic Datastores (Advanced / Vendor-Specific)
🔹 dynamic
Generated from multiple sources
Used internally by device
Read-only
📌 Vendor-defined (not standard)

6️.Vendor-Specific Datastores (Common in real devices)
Examples:
factory-default
golden-config
rollback-1, rollback-2
baseline
Not standardized
Exposed via vendor YANG models

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

Network Automation with ROBOT Framework

-
Image
  Folder-structure Scripts testcase_with_keywordsLibrary.robot *** Settings *** Documentation    Test Case With Keyword Resource         Resources/Keywords/common.robot Resource          Resources/Keywords/vxlanInstance.robot Test Setup        Open Connection Test Teardown    Close Connection *** Test Cases *** [Documentation] Step 1: Verify VXLAN Interface Status     VXLAN Interface Status [Documentation] Step 2: Verify VXLAN VNI to VLAN Mapping     VXLAN VNI to VLAN Mapping Resources/Keywords/common.robot *** Settings *** Documentation    Common Keyword Library Library          ../../Libraries/commonLib.py Variables        ../Variables/veosLeaf01.yaml *** Variables *** ${devType}         ${virtualBox}[vmType] ${ipAddr}          ${virtualBox}[vmManagement][hostIp] ${po...
Read more