Interpreting Basic YANG Models

Mental model

Cisco objective 5.11 says “Interpret basic YANG models”. You get a 15 to 30 line YANG snippet; name the parts and build a path.

The four node kinds

container system {              // 1. container groups things
  leaf hostname {               // 3. leaf = one value
    type string;
    mandatory true;
  }
  leaf-list dns-server {        // 4. leaf-list = many values of a simple type
    type inet:ipv4-address;
  }
  list ntp-server {             // 2. list = keyed collection
    key "address";
    leaf address { type inet:ipv4-address; }
    leaf prefer  { type boolean; default "false"; }
  }
}

• container — groups child nodes. No value of its own.
• list — a collection of entries. Each entry has key-named leaves.
• leaf — a single typed value.
• leaf-list — a sequence of simple values (strings, numbers), not full entries.

The example in English

• system is a container.
• Inside: hostname (one string, required).
• dns-server (several IPv4 addresses, order usually matters).
• ntp-server (a list, keyed by address). Each entry has address (the key) and prefer (boolean, defaulting to false).

Building a path

Given the model above:

• Path to the hostname: /system/hostname
• Path to the first DNS server: /system/dns-server[1] (or just /system/dns-server for the whole list)
• Path to a specific NTP server: /system/ntp-server[address="10.0.0.1"]
• Path to that NTP server’s prefer flag: /system/ntp-server[address="10.0.0.1"]/prefer

In RESTCONF URL form, this becomes: /restconf/data/example-system:system/ntp-server=10.0.0.1/prefer

(The list key goes after an = in the URL path.)

Leaf types you will see

Config vs state

Each node is either config (writable) or state (read-only).

container interfaces {
  list interface {
    key "name";
    leaf name    { type string; }
    leaf enabled { type boolean; config true; default "true"; }   // writable
  }
}
container interfaces-state {
  list interface {
    key "name";
    leaf name        { type string; }
    leaf oper-status {                                             // read-only
      type enumeration { enum up; enum down; enum testing; }
      config false;
    }
  }
}

• enabled lives under /interfaces (config). You can PUT / PATCH to change it.
• oper-status lives under /interfaces-state (operational). GET-only.

Reading a snippet on the exam

Follow this checklist:

1. Spot the top node. Is it a container or a list?
2. If list, find the key. Note what identifies each entry.
3. Walk child nodes. For each: name, kind (container / list / leaf / leaf-list), type.
4. Build the path to any field they ask about.
5. Config or state? Check for config false.

Mini practice

Given:

container acl {
  list access-list {
    key "name";
    leaf name  { type string; }
    list ace {
      key "sequence";
      leaf sequence { type uint32; }
      leaf action   { type enumeration { enum permit; enum deny; } }
      leaf source-ip { type inet:ipv4-address; }
    }
  }
}

Questions and answers:

• “What identifies an access-list entry?” → the name leaf (the list key).
• “What identifies an ACE?” → sequence (nested list’s key).
• “Can action be drop?” → No, enumeration only has permit and deny.
• “Path to the action of ACE 10 in access-list MYACL?” → /acl/access-list[name='MYACL']/ace[sequence=10]/action.

FAQ

What is a grouping? A reusable set of nodes you can uses elsewhere, like a function in programming. Reduces copy-paste in big models.

What is augment? A way to add new nodes to someone else’s model without modifying it. ietf-ip augments ietf-interfaces to add IPv4/IPv6 to each interface.

What is must and when? Constraints and conditionals. must "/system/hostname != ''" would reject a config where hostname is empty. The exam asks you to recognise, not write them.

Is YANG only for Cisco? No. YANG is an IETF standard (RFC 7950). Juniper, Arista, Nokia all publish YANG models. OpenConfig is a vendor-neutral YANG set used across the industry.