YANG : DEFINITION
Yang is a configuration and state data modeling language. IETF’S net mod has established the yang modeling language as a standard. In other words, the Yang language is more like a tree than an element. When storing parameters, configuration data is organized in the form of a tree.
This tree can contain various types of data, including lists and unions. Modules contain definitions, and each module can complete the tree in another module. There are strict rules for modifying modules. Yang can be translated from one encoding format to another, for example to XML or JSON.
OPEN & NATIVE MODELS
There are two types of model: Open and Native. Different teams are working on each.
Open models enable network devices to be configured in a standard way, regardless of the vendor who manufactures them. Vendors and standards bodies such as the IETF, ITU and OpenConfig create Open YANG templates.
Vendors themselves create native models. They focus on the features and configurations specific to a particular platform, and are built explicitly to interface with them.
THE BUILDING BLOCKS OF YANG
CONTAINER
MODULE
LIST
SHEET
TYPE
A container is a logically organized succession of information. It can be a configuration container and a status container, for example.
Multiple lists are possible within a single container.
Mean menu of available options. List items are linked by a key.
Our list includes the word “leaf”. Protecting and storing all our personal information.
For each leaf, there is a particular data type to which it belongs.
YANG DEPLOYMENT
Leaf nodes can be defined using one of two YANG instructions: leaf or leaf list. A leaf node has only one instance, while a leaf list node can have several.
leaf enable {
type Boolean;
default true;
}
Non-leaf nodes can be specified using YANG’s container and list instructions. Container nodes have a single instance, while list nodes can have any number of instances (list entries are identified by keys that distinguish them from one another).
container timeout {
leaf access-timeout {
type uint16;
}
leaf retries {
type uint8;
}
}
Résultat de la traduction
The IP address type, for example, is defined as the union of two additional derived types:
typedef ip-address {
type union {
type ipv4-address;
type ipv6-address;
}
}
A choice node can only select one choice at a time from a set of choices. Sub-instruction cases define the branches of a decision tree. The data tree contains only the nodes of a single choice branch (the choice node itself does not exist in the data tree).
choice route-distinguisher {
case ip-address-based {
leaf ip-address {
type ipv4-address;
}
leaf ip-address-number {
type uint16;
}
}
case asn32-based {
leaf asn32 {
type uint32;
}
leaf two-byte-number {
type uint16;
}
}
A cluster identifies a set of nodes that can be reused. A grouping of terminals with two leaf nodes is defined here
grouping endpoint {
leaf address {
type ip-address;
}
leaf port {
type port-number;
}
}
The “use” instruction is used to transfer the nodes indicated by a grouping definition from another schema tree into the current schema tree. In this way, for example, we can use the endpoint grouping to define the source and destination of the connection:
container connection {
container source {
uses endpoint {
refine port {
default 150;
}
}
}
container destination {
uses endpoint {
refine port {
default 150;
}
}
}
}
When you use the “must” statement, you’re expressing the requirements that each node in the structure must satisfy before it can be considered valid. To express “must” constraints, we use
XPath expressions. A non-192. * or non-127. * The network IP address is modeled as follows:
leaf mirrorIp {
type ip-address;
default 0.0.0.0;
must “false() = starts-with(current(), ‘192’)” {
error-message “The mirrorIp is in the forbidden “+
“192.* network”;
}
must “false() = starts-with(current(), ‘127’)” {
error-message “The mirrorIp is in the occupied “+
“127.* network”;
}
}
Yang at the service of networks
Yang at the service of Cisco
Cisco IOS XR supports data templates to programmatically configure and collect operational data from a network device. They replace the essentially text-based, proprietary manual configuration process. Data templates are written and published in an industry-defined language to automate configuration tasks and retrieve operational data from heterogeneous network devices.
Although CLI configurations are simpler, automating configuration using a model-driven program capability enables greater scale. Using a model-driven approach to device programming offers developers a user-friendly yet powerful framework. An IOS XR device can be interfaced with multiple transport, protocol and coding options using this framework. For greater adaptability, these options have been dissociated from the models.
NETCONF (Network Configuration Protocol)
An application running on an integrated management platform can request configuration or operating data structured according to the YANG standard via NETCONF, which provides the transport for connecting the OEM device. A user can design or request operating data in XML (Extensible Markup Language) programming. If part of the configuration request fails, the whole configuration request is cancelled. This is one of the contractual services it provides.
It uses an integrated RPC (Remote Procedure Call) method to facilitate client-server (Cisco switch or router) interaction. Secure Shell (SSH) remains the transmission layer between network devices. Some examples of NETCONF tasks are: Get, get-config, edit-config and RPC.
YANG MODELS FOR CISCO PLATFORMS
As a result, browsing the tree has never been so user-friendly. The aim is to automate the creation of these elements and eliminate the need to generate them manually
$ pyang -f tree openconfig-vlan.yang
module: openconfig-vlan
+--rw vlans
+--rw vlan* [vlan-id]
+--rw vlan-id -> ../config/vlan-id
+--rw config
| +--rw vlan-id? oc-vlan-types:vlan-id
| +--rw name? string
| +--rw status? enumeration
| +--rw tpid? identityref
+--ro state
| +--ro vlan-id? oc-vlan-types:vlan-id
| +--ro name? string
| +--ro status? enumeration
| +--ro tpid? identityref
+--rw members
+--ro member*
+--ro interface-ref
+--ro state
+--ro interface? -> /oc-if:interfaces/interface/name
+--ro subinterface? -> /oc-if:interfaces/interface[oc-if:name=current()/../interface]/subinterfaces/subinterface/index
augment /oc-if:interfaces/oc-if:interface/oc-if:subinterfaces/oc-if:subinterface:
+--rw vlan
+--rw config
| +--rw vlan-id? union
+--ro state
+--ro vlan-id? union
augment /oc-if:interfaces/oc-if:interface/oc-eth:ethernet:
+--rw switched-vlan
+--rw config
| +--rw interface-mode? oc-vlan-types:vlan-mode-type
| +--rw native-vlan? union
| +--rw access-vlan? union
| +--rw trunk-vlans* union
+--ro state
+--ro interface-mode? oc-vlan-types:vlan-mode-type
+--ro native-vlan? union
+--ro access-vlan? union
+--ro trunk-vlans* union
augment /oc-if:interfaces/oc-if:interface/oc-lag:aggregation:
+--rw switched-vlan
+--rw config
| +--rw interface-mode? oc-vlan-types:vlan-mode-type
| +--rw native-vlan? union
| +--rw access-vlan? union
| +--rw trunk-vlans* union
+--ro state
+--ro interface-mode? oc-vlan-types:vlan-mode-type
+--ro native-vlan? union
+--ro access-vlan? union
+--ro trunk-vlans* union
augment /oc-if:interfaces/oc-if:interface:
+--rw routed-vlan
+--rw config
| +--rw vlan? union
+--ro state
+--ro vlan? union
YAML: DEFINITION
Initially, the nickname given to YAML by the project’s creators was “Yet Another Markup Language”. Over time, however, the acronym evolved into “YAML Ain’t a MarkUp language”. YAML is a recursive acronym because it refers to itself. The YAML language can be used to store data and parameters in a form that can be easily assimilated by users. YAML has a relatively low learning curve. It is easy to follow and understand, thanks to its simple constructs.
YAML’s creators wanted to overcome the difficulties associated with understanding other markup languages, which are more difficult to grasp than YAML. We always base ourselves on a practical project to make learning more convenient. The present project is hosted on GitHub under an MIT license, making it freely available to anyone wishing to make modifications and send a pull request.
THE ADVANTAGES OF YAML
CREATING A YAML FILE
The following rules are fundamental to the creation of a YAML file:
YAML has a keyboard layout that is not case-sensitive.
There must be no tabs in these files, as YAML sams do not allow tabs when creating YAML files.
YAML ASSOCIATED WITH ANSIBLE
Computer processes can be orchestrated using Ansible playbooks. Each system has one or more playbooks, and these playbooks are used to define the desired state of the system. Each play can execute one or more tasks, with each task calling on a different Ansible module. In Ansible, automation tasks are executed using modules. Any language capable of returning JSON can create Ansible modules, including Ruby, Python and bash.
Maps and lists make up an Ansible playbook. YAML lists can generate playbooks by first creating a list with the play’s name, then listing all the play’s functions one by one in the list.
---
- name: Update web servers
hosts: webservers
remote_user: root
tasks:
- name: Ensure apache is at the latest version
ansible.builtin.yum:
name: httpd
state: latest
- name: Write the apache config file
ansible.builtin.template:
src: /srv/httpd.j2
dest: /etc/httpd.conf
- name: Update db servers
hosts: databases
remote_user: root
tasks:
- name: Ensure postgresql is at the latest version
ansible.builtin.yum:
name: postgresql
state: latest
- name: Ensure that postgresql is started
ansible.builtin.service:
name: postgresql
state: started
Remember that indentation does not necessarily indicate a logical order of inheritance. Assume that each line represents a YAML data type (a list or a map). Ansible users can automate repetitive activities using YAML templates, eliminating the need to learn a complex programming language.
From top to bottom, a playbook follows a set of instructions. Similarly, each play’s tasks are executed in chronological order, starting at the top and working down. For multi-machine installations, playbooks with multiple “plays” can run one play on your web servers, another on your database servers, then the third on your network infrastructure.
YAML ASSOCIATED WITH CISCO
The YANG model and YAML configuration file names are sent to a Python 1 send yaml.py script. To send the configuration to the device, it first creates an instance of the YdkModel class, then executes the create action. The following YAML configuration data is stored in a BGP.yaml file, as shown in the example :
+++
router:
bgp:
- id: 100
bgp:
router_id: 1.1.1.1
fast_external_fallover: null
update_delay: 15
neighbor:
- id: 2.2.2.2
remote_as: 200
- id: 3.3.3.3
remote_as: 300
redistribute:
connected: {}
Therefore, on an IOS XE device, the configuration would look like this:
router bgp 100
bgp router-id 1.1.1.1
bgp log-neighbor-changes
bgp update-delay 15
redistribute connected
neighbor 2.2.2.2 remote-as 200
neighbor 3.3.3.3 remote-as 300
