BGP YANG Model and Configuration

YANG Data Modeling Language

Yet Another Next Generation (YANG) RFC 6020 is standard-based data modeling language for the NETCONF management protocol. YANG is used to create device configuration requests or requests for operational data.  NETCONF and YANG provide the tool that network admins use to automate configuration tasks across devices from different vendors.

YANG is a module-driven language such as Python. A module defines a single data model. The module can import external YANG modules or include one or more sub-modules. For example, Cisco-IOS-XE-bgp.yang vendor-specific module imports five external modules (Figure 1).

Figure 1 – YANG BGP Module for Cisco IOS-XE

The YANG data model defines the configuration and state data, notifications, and RPCs for use by NETCONF. For example, a data model for a network device will control interfaces, while the model configuring a service will be used to configure services such as BGP.

YANG models data using a hierarchical tree-based structure consisting of nodes (Figure 2). The RFC 6020 defines four types of YANG nodes. Each node has a name, and depending on the node type, the node may either define a value or contain a set of child nodes.

• Leaf – a node with a single value having no children
• Leaf-list – a node containing the sequence of leafs with no children
• Container – a node which groups nodes and has no type or value containing only child nodes, which can be any of the four types
• Lists – the series of data instances generally with one or more keys

Figure 2 shows the YANG data model example with the appropriate CLI configuration on the right. The data model has a hierarchical configuration, and it is human readable.

Figure 2 – YANG Data Model Example
Source: https://www.ciscolive.com/c/dam/r/ciscolive/emea/docs/2020/pdf/BRKSPG-2303.pdf

Where are the YANG Modules Stored?

YANG models are installed automatically on devices such as CSR1000v (IOS-XE) and can be updated on some devices. They can also be downloaded from Github and uploaded to the device.

Native Versus Standard/OpenConfig YANG Data Models

YANG has been widely adopted by key standard organizations such as the IETF and working groups such as OpenConfig.

The IETF standardized YANG data models provide limited functionality but can be used across multiple vendors.

The OpenConfig YANG data models are built by an OpenConfig group (network operators from large service providers or web companies). Similar to IETF models, these have limited feature coverage, offer multi-vendor support, and allow vendor-specific extensions.

Native or vendor-specific YANG data models provide the greatest feature coverage, but they work only on specific vendor devices. For Cisco devices, the models are OS unique. For example, there are separate YANG data models for IOS-XE, IOS-XR, NX-OS, etc.

IETF BGP YANG Model

The YANG data model for the BGP-4 protocol described in the IETF draft is defined across several YANG modules and covers:

• Base protocol configuration – configuration affecting BGP protocol-related operations, defined at various levels of hierarchy
• Multiprotocol configuration – configuration affecting individual address-families within BGP multiprotocol extensions for BGP-4
• Neighbor configuration – configuration affecting an individual neighbor within BGP.
• Neighbor multiprotocol configuration – configuration affecting individual address families for a neighbor within BGP.
• Policy configuration – hooks for application of the policies defined in a YANG Data Model for Routing Policy Management RFC9067 that act on routes sent (received) to (from) peers or other routing protocols and BGP-specific policy features.
• Operational state – variables used for monitoring and management of BGP operations.

The model is vendor-neutral to allow operators to manage BGP configuration in environments with routers supplied by multiple vendors.

YANG Models and XML/JSON

YANG models do not contain data or Extensible Markup Language (XML); they are used as templates for generating structured data in different formats such as XML or JSON. YANG models are used in conjunction with the Network Configuration Protocol (NETCONF) and RESTCONF protocols for configuring networking equipment.

YANG and NETCONF

The YANG data modeling language has been developed for specifying NETCONF (RFC 6241) data models and protocol operations.

NETCONF is a standard-based XML encoded network management protocol. NETCONF provides the transport via SSH protocol to communicate the YANG formatted configuration or operational data request from an application that runs on a management workstation (NETCONF client) to the network device (NETCONF server) that a user wishes to configure or request operational data from.

BGP Configuration Using YANG/NETCONF

In our example, the CSR1000v router running Cisco IOS-XE 16.07.01 is used as the NETCONF server. This is the device that is configured and from which data (show command output) is being collected from via NETCONF/YANG.

A virtualized Ubuntu server is a NETCONF client which acts as the centralized management platform by utilizing the Cisco YANG Suite application. It is the device creating the YANG formatted requests sent to the CSR1000v via NETCONF RPC (Remote Procedure Call) messages to configure and collect data from the NETCONF server.

1. Configuration of CSR1000v to Support NETCONF/YANG Data Modeling

 r1(config)# username admin privilege 15 secret 0 cisco
 r1(config)# ip domain-name test.com
 r1(config)# crypto key generate rsa  
 r1(config)# ip ssh version 2

Enable NETCONF/YANG globally:

 r1(config)# netconf-yang

Use SSH to establish NETCONF session:

 R1(config)# netconf ssh

SSH access Verification for NETCONF:

 $ admin@192.168.88.102 -p 830 netconf

2. YANG Suite Installation and Configuration

2.1 YANG Suite Installation

Install Prerequisites:

We must install Docker on the system where we want to run YANG Suite. In addition, since this YANG Suite repository uses Docker Compose, or system needs Docker Compose.

 $ sudo apt install docker-compose git

Clone YANG suite repository with the command:

$ git clone https://github.com/CiscoDevNet/yangsuite.git

$ cd yangsuite/docker

Run bash script start_yang_suite.sh or sudo docker-compose up if you already ran the start_yang_suite.sh. The script start_yang_suite.sh will ask to set the username, password, e-mail address, and certificate details.

$ sudo ./start_yang_suite.sh

The output should look like below (Figure 3):

Figure 3 – Successful YANG Suite Installation

Now we can access the YANG Suite at http://localhost. Log in with the username and pass you entered during installation.

2.2. YANG Suite Configuration

2.2.1 Creating Device Profile

Configure YANG Suite to connect to CSR1000v “Setup –> Device profiles”. Click “Create new device” and fill the “General Info” path and “NETCONF” configuration (Figure 4). We can check if we can connect to CSR1000v by clicking the Check connectivity button.

Figure 4 – Creating New Device Profile – CSR100v-I

2.2.2 Creating YANG Repository

Clone YANG models from the Github repository:

$ git clone https://github.com/YangModels/yang.git

Now we need to upload YANG model files from our computer to YANG Suite at “Setup –> YANG files and repositories”.

Navigate to Setup-> “YANG files and repositories”. Select the “Upload” Tab and click the “Browse” button. Navigate to the path where yang files are saved (Figure 5). Select modules that you need.

Figure 5 – Selecting YANG Modules

Click the “Upload files to repository” button. Add modules to repository-> Upload (Figure 6).

Figure 6 – Uploading YANG Modules to Repository my_repo

2.2.3 Create the YANG Set

Once we have provided YANG models to YANG Suite, we can then proceed to define sets of YANG models of interest or the entire models at “Setup –> YANG module sets” (Figure 7).

Figure 7 – Creating New Yang Set – my-ds

Click the “Add entire” button (Figure 8).

Figure 8 – Adding Modules to Data Set – my-ds

Once this is done, we can proceed to learn how to explore the contents of these YANG models at “Explore –> YANG”, or use these models to send NETCONF at “Protocols –> NETCONF”.

3. BGP Configuration Example

Navigate to Protocols-> NETCONF. Select YANG Set “my-ds” and the device “CSR1000v”. Enter the module “Cisco-IOS-XE-bgp” and click “Load Module(s)”.

The desired operation is selected from the left side of the Explorer section of the Yang Suite application GUI. In our case, to configure BGP is required on the CSR1000v and so Config (for configuration) is selected, followed by the required operational parameters under the ios-bgp:bgp drop-down menus (Figure 9).

Figure 9 – Building YANG Formatted NETCONF RPC

Once you have finished BGP configuration, press “Build RPC” to generate the YANG formatted (human-readable) NETCONF RPC that must be sent to the CSR1000v via NETCONF to execute the configuration task.

After the YANG formatted NETCONF RPC message is generated, press “Run RPC(s)” to send it to the router. The CSR1000v replies with a YANG formatted (human-readable) message that states that the configuration operation was successful (ok) (Figure 10).

Figure 10 – Sending NETCONF RPC Message to CSR1000v

In order to confirm that the change took place, the configuration can be checked using the get-config operation.

4. CSR1000v CLI Display of BGP Configuration

After the NETCONF RPC message is received that contains the YANG formatted request to configure BGP, the operation is completed, and the running configuration is modified to reflect this (Figure 11). This also demonstrates how the software process on the CSR1000v converts the received YANG formatted NETCONF RPC message into standard Cisco IOS CLI.

A user can still use regular Cisco IOS CLI to modify the configuration and execute show commands in addition to using NETCONF/YANG to do the same.

Figure 11 – BGP Configuration on CSR1000v Using NETCONF/YANG

Conclusion

YANG data models and NETCONF provide an alternate and centralized way to configure networking equipment instead of using the Command Line Interface (CLI) or Simple Network Management Protocol (SNMP) and collect operational data with the show commands from devices.

As the data models are standards-based, the same procedure can be used to configure or collect data from different vendors’ devices. Therefore, they are ideal for customers with a network infrastructure built from multi-vendor devices.

NETCONF has been developed to overcome SNMP issues. It can backup and store configurations from network devices, and unlike SNMP, NETCONF messages are encrypted using SSH. NETCONG also has the ability to test configurations before commit or provisioning.

In the future, however, we will see if NETCONF will be really used to install, update and delete device configuration and not just get operational data like SNMP when configuration management with SNMP was abandoned.