03-19-2024 05:30 PM - edited 03-19-2024 05:32 PM
Hello Cisco Community,
I'm working on a project involving Cisco NSO and encountering challenges with customizing the CLI output for a service defined in a YANG model. My objective is to streamline the CLI presentation to improve usability and readability, particularly for configurations that involve nested structures.
To illustrate, part of my YANG model defines connections in a network fabric, including configurations for devices and interfaces. Here are the relevant excerpts from my model:
grouping interface-config {
leaf interface-type {
type interface-type;
}
leaf interface-name {
type string {
pattern "[0-9]/[0-9]+";
}
}
leaf ip-address {
type tailf:ipv4-address-and-prefix-length;
}
leaf mask {
config false;
type inet:ipv4-address;
description
"Auxiliary data populated by service code, represents network mask
corresponding to the prefix in the address field, e.g.: 255.255.255.0";
}
leaf description {
type string {
length "1..254";
}
}
}
grouping connection-grouping {
leaf device {
type leafref {
path "/ncs:devices/ncs:device/ncs:name";
}
}
uses interface-config;
}
list nfaas {
description "Service description";
key name;
leaf name {
tailf:info "Unique service id";
tailf:cli-allow-range;
type string;
}
uses ncs:service-data;
ncs:servicepoint nfaas-servicepoint;
container fabric-connections {
list fabric-connection {
key "name";
leaf name {
type string;
}
container connection-a {
uses connection-grouping;
}
container connection-z {
uses connection-grouping;
}
}
}
}
Currently, the CLI output for configuring these connections is more verbose and nested than I'd prefer.
admin@ncs# show running-config nfaas
nfaas DC1
fabric-connections fabric-connection SPINE1-Ethernet1/1::LEAF1-Ethernet1/1
connection-a device spine1
connection-a interface-type Ethernet
connection-a interface-name 1/1
connection-a ip-address 10.0.0.0/31
connection-a description SPINE1-Ethernet1/1::LEAF1-Ethernet1/1
connection-z device leaf1
connection-z interface-type Ethernet
connection-z interface-name 1/1
connection-z ip-address 10.0.0.1/31
connection-z description LEAF1-Ethernet1/1::SPINE1-Ethernet1/1
!
!
admin@ncs#
I'm aiming for a more compact representation that could potentially look something like this:
nfaas DC1
fabric-connections
fabric-connection SPINE1-Ethernet1/1::LEAF1-Ethernet1/1
connection-a
device spine1
interface-type Ethernet
interface-name 1/1
ip-address 10.0.0.0/31
description SPINE1-Ethernet1/1::LEAF1-Ethernet1/1
connection-z
device leaf1
interface-type Ethernet
interface-name 1/1
ip-address 10.0.0.1/31
description LEAF1-Ethernet1/1::SPINE1-Ethernet1/1
I'm seeking advice on the following points:
I appreciate any insights, suggestions, or references to documentation that could assist in addressing these challenges. How have others approached similar situations, and what lessons have been learned in customizing NSO CLI outputs for better service manageability?
Thank you for your time and assistance.
Solved! Go to Solution.
03-21-2024 03:11 PM
Hello Cisco Community,
I'm writing to update you on the status of my inquiry regarding CLI output customization for my NSO service model. I've taken some time to re-evaluate my approach and have decided to redesign my YANG model. This redesign effectively addresses my initial concerns and makes the specific customization I was exploring unnecessary.
Thank you.
03-21-2024 03:11 PM
Hello Cisco Community,
I'm writing to update you on the status of my inquiry regarding CLI output customization for my NSO service model. I've taken some time to re-evaluate my approach and have decided to redesign my YANG model. This redesign effectively addresses my initial concerns and makes the specific customization I was exploring unnecessary.
Thank you.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide