Code Monkey home page Code Monkey logo

yang's Introduction

YANG

This repository contains a collection of YANG modules:

  • IETF standards-track YANG modules
  • IEEE experimental YANG modules
  • ETSI standard YANG modules
  • MEF standard YANG modules
  • Broadband Forum standard YANG modules
  • Vendor-specific YANG modules

Contribution Procedures

Direct Contributions

This is the preferred method of contribution. With this approach you pick where your models will reside in the directory hierarchy, and manage the files mainly in your own fork of the main repository, submitting a pull request when you wish to make public updated models. All push requests must be reviewed by at least one of the repository's Committers, so when pushing a PR, please assign it to one of the committers.

You can find a tutorial here for how to do push requests. Note that there are at least two different approaches to how to do Pull Requests: using a shell/commandline or using the web interface, so if you do not find what you need below, look elsewhere or ask the committers for pointers.

https://yangsu.github.io/pull-request-tutorial/

By convention, there should also be a check.sh script provided by the contributors, which should be referenced from the complete_check.yml file for CI builds. Multiple examples are already in place to copy and modify as required.

Contributions Via Submodules

Standards bodies or vendors may also provide models to the main repository via a git submodule. Examples of this can be see under standard directory, with the BBF and MEF submodules. By convention, if a submodule is used, there should also be an equivalent check.sh provided by the contributors, which should be referenced from the complete_check.yml file for CI builds. An example of this may be found in the BBF's submodule, and a sample invocation here.

Direct contributions to the top level of the repository are not encouraged; instead each "organization" should create a top-level folder as described above.

A summary of the suggested process is:

  1. Create a fork of https://github.com/YangModels/yang
  2. Enable Github Actions on your fork in the Actions tab
  3. Add your source git repository as a submodule to your fork:
    • Clone your fork
    • cd into vendor or standards directory (depending on the source of your models)
    • git submodule add https://github.com/<owner>/<repository>.git <name>
  4. Add appropriate entry to the complete_check.yml file to check your models.
  5. Note: this requires a call to a check.sh script provided by the contributors, which should be referenced from the complete_check.yml file for CI builds. Multiple examples are already in place to copy and modify as required, but in general, one is present at the top-most level of each major submodule area.
  6. Commit changes to your fork
  7. Test the Github Actions CI run of your fork as well as test it by running the testall.sh script from the top level directory.

After you've verified that the submodule addition and module checking is working ok, submit a PR to the main repository. This will take the latest commit from your repository and make it available as a submodule.

Subsequently, when an updated set of models needs to be released, fork, clone, update submodule, commit and submit PR, also ensuring that Github Actions are again enabled on your fork to allow pre-pull request checks.

All Pull Requests must be reviewed and as such one of the repository's Committers must review the request prior to actually committing the request. Changes may be suggested during this process, so patience is requested during this process.

Github Actions Jobs

In general, pull requests will not be accepted without check.sh scripts being in place and a clean Github Actions CI build being achieved. As can be seen from existing check scipts, all of which use pyang today, the bar is set fairly low. The minimum requirement is that the models contributed compile correctly such that pyang plugins such as the tree plugin will function correctly, and the schema tree is available for interrogation and tasks such as code generation.

As noted above, the check scripts today depend on pyang, and, as of writing, this tool does not support validation of content such as regular expressions or XPath constraints. As such, models available in this repository may not be accepted by tools that perform more complete semantic validation. An example of such a tool is the OpenDaylight controller.

Slack Group and Channels

To Subscribe and Browse Click Here

Models Directory Structure

The following directories are maintained for YANG models [license note in brackets]:

  • yang/experimental: contains experimental YANG modules [any]
  • yang/experimental/ietf: experimental modules intended for IETF submission [1]
  • yang/experimental/odp: experimental modules intended for OpenDaylight submission [2]
  • yang/standard: contains standards-track YANG modules [any]
  • yang/standard/ieee: standard modules (published or drafts) intended for IEEE submission [3]
  • yang/standard/ietf: standard IETF YANG modules [1]
  • yang/standard/ietf/DRAFT: work-in-progress IETF YANG modules [1]
  • yang/standard/ietf/RFC: completed IETF YANG modules [1]
  • yang/standard/odp: published modules for OpenDaylight [2]
  • yang/standard/bbf/draft: draft Broadband Forum YANG modules [6]
  • yang/standard/bbf/standard: standard Broadband Forum YANG modules [6]
  • yang/vendor: contains vendor-specific YANG modules [any]
  • yang/vendor/cisco: Cisco YANG modules [4]
  • yang/vendor/netconfcentral: Netconf Central YANG modules [4]
  • yang/vendor/yumaworks: YumaWorks YANG modules [4]

License Notes

[1] IETF Trust License (Note Well):

  • All files contained within this sub-directory are considered to be IETF Contributions.
  • All issues entered into the trouble ticket system for this directory are considered to be IETF Contributions.
  • All pull requests submitted for this directory are considered to be IETF Contributions.
  • All IETF Contributions are submitted under the terms of the IETF Note Well statement
  • All IETF Contributions are subject to the requirements and provisions of BCP 78 and BCP 79.

[2] OpenDaylight Eclipse License:

[3] IEEE License:

  • All files contained within this sub-directory are considered to be intended as IEEE Contributions.
  • All issues entered into the trouble ticket system for this directory are considered to be intended as IEEE Contributions.
  • All pull requests submitted for this directory are considered to be intended as IEEE Contributions.
  • All contributions to IEEE standards development (whether for an individual or entity standard) shall meet the requirements outlined in the IEEE-SA Copyright Policy
  • Copyright release for YANG modules: Users may freely reproduce the YANG modules contained under /standard/ieee/ so that they can be used for their intended purpose.

[4] Vendor Specific License:

  • All files contained within this sub-directory are provided under the terms of a license specified by the vendor that owns the YANG modules.

[5] Warrantees and Conditions

  • Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

[6] Broadband Forum License:

Code of Conduct

The Yang Models Repository follows The CNCF Code of Conduct.

yang's People

Contributors

aashaikh avatar abierman avatar alfred-leung avatar apoorvashastry avatar bclaise avatar cmoberg avatar dfedyk avatar einarnn avatar ivandean avatar jclarke-csco avatar koushik331 avatar kyoungyun avatar lisahuang avatar lisahuangcisco avatar marcholness avatar miroslavkovacpantheon avatar mxhajduczenia avatar paulcongdon avatar pgohite avatar rgwilton avatar richardfurness avatar rodneycummings avatar samans avatar skomajwa avatar slavomirmazurpantheon avatar srbuilds avatar tnadeau avatar wlupton avatar yang-catalog avatar yanzhuang avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

yang's Issues

Cisco-IOS-XR-aaa-locald-cfg problem with list key

Hi,

I will try to request the fix. Looks like "ordering-index" should not be a key.

Roque

admin@ncs> request devices device salerno sync-from
result false
info salerno: missing element: ordering-index in /ncs:devices/ncs:device[ncs:name='salerno']/ncs:config/aaa-lib-cfg:aaa/aaa-locald-cfg:usernames/aaa-locald-cfg:username
[ok][2018-06-06 17:35:21]
admin@ncs>

epnlab usergroup_read_only type5 $1$UPDN$XV6e7Pn0HvmwaX1Ewsbea/

Cisco IOS-XE porting route-map fails

Hi All,

I'm a network engineer that found out how to program a Cisco ISR1000v/ Cisco ASR, and was very happy is worked..

Now it got broken because of an Upgrade.. I decided to go Your wy, the YANG way now, but that seems to be pretty hard.

Together with a TAC engineer I managed to get a lot of information from the devices and to configure interfaces. Now I'd like to configure some route-map (That I can already download with the GET) but that fails and I can't find out why.

Is there anybody that can help me to get the right format for my RESTCONF configuration?

WORKING:
curl -i -k -u cisco:cisco -X GET -H "Content-Type: application/yang-data+xml" https://10.110.1.213/restconf/data/ietf-interfaces:interfaces

curl -i -k -u cisco:cisco -X POST -H "Content-Type: application/yang-data+xml" -d 'Loopback666ianaift:softwareLoopback' https://10.110.1.213/restconf/data/ietf-interfaces:interfaces

curl -k -u cisco:cisco -H "Accept: application/yang-data+json" https://cisco:[email protected]/restconf/data/Cisco-IOS-XE-native:native/route-map="ZOM-ROUTE-toLEAF_RM"

How to configure this route-map?? POST/ PUT/ PATCH

Thanks,
Brian

Promiscuous Neighbor Support

In bgp-neighbors, there doesn't seem to be any way to account for promiscuous neighbor mode. This might be too implementation specific -- don't know -- but it might be worth considering making the address and peering AS either able to contain a "magic number" (though I hate magic numbers) to indicate "this is a promiscuous peering point," or to make it into a group of items, one of which could be a marker indicating there's no ip address and peering AS here because this is a promiscuous attachment point.

Neighbor Set Ambiguity

Neighbor set apparently means "the set of neighbors from whom you've learned this route." This isn't a valid set for a link state protocol. For BGP it's useful, and for RIP/EIGRP it overlaps with the forwarding set. This needs to be addressed in some way, probably my marking this as explicitly optional for any given route, or describing it more fully.

Or does the "neighbor set," mean the set of neighbors for whom this filter applies?

archive of auto-converted MIB modules

Issue has been raised on EMAN WG mailing list about maintaining an archive
of YANG modules that have been converted from SMIv2 using RFC 6643.

Need procedure for adding modules and a new subtree in the yang repo
Need tools and scripts for submitting such modules for approval.
Need naming conventions for the converted modules

Plan for popular IETF MIB modules but no reason other SDO and vendor MIB modules
could not be archived as well.

Cannot retrieve IP SLA config or results

I am testing a couple of NETCONF-YANG models against an ASR9k router running IOS-XR 6.0.1.
Haven't gone through all of them, but so far so good, except:

  • cannot retrieve the configuration of the IP SLA probes using the model Cisco-IOS-XR-infra-sla-cfg, firing XML requests with the following structure (wrapped into the rpc tag, of course):
<get-config><source><running/></source><filter><sla xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-infra-sla-cfg"/></filter></get-config>

the device providing empty reply:

<rpc-reply message-id="urn:uuid:3d482929-2fde-4ffe-b2da-8bc99d12872e">
 <data/>
</rpc-reply>
<get><filter><sla xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-infra-sla-oper"/></filter></get>

the device replying again with empty body:

<rpc-reply message-id="urn:uuid:ac163174-fbf0-4056-b71a-f0b05dcac952">
 <data/>
</rpc-reply>

The device running quite a few probes - will paste only the first entries below.

  • config:
RP/0/RSP0/CPU0:edge03.mrs02#sh run ipsla
Sat Jul 23 23:20:00.614 UTC
ipsla
 operation 1
  type icmp echo
   tag probe1
   history
    lives 1
    filter all
    buckets 15
   !
   source address 1.1.1.1
   destination address 2.2.2.2
   timeout 2000
   frequency 3
  !
  • results:
RP/0/RSP0/CPU0:edge03.mrs02#sh ipsla stat
Sat Jul 23 23:24:08.868 UTC
Entry number: 1
    Modification time: 13:02:24.260 UTC Thu Jul 21 2016
    Start time       : 13:02:24.264 UTC Thu Jul 21 2016
    Number of operations attempted: 40230
    Number of operations skipped  : 29803
    Current seconds left in Life  : Forever
    Operational state of entry    : Active
    Operational frequency(seconds): 3
    Connection loss occurred      : FALSE
    Timeout occurred              : FALSE
    Latest RTT (milliseconds)     : 686
    Latest operation start time   : 23:23:57.042 UTC Sat Jul 23 2016
    Next operation start time     : 23:24:00.042 UTC Sat Jul 23 2016
    Latest operation return code  : OK
    RTT Values:
      RTTAvg  : 686        RTTMin: 686        RTTMax : 686
      NumOfRTT: 1          RTTSum: 686        RTTSum2: 470596

Is there anything I am missing?

Thanks,
Mircea

ietf-hardware.yang add reason for state

I am looking to use the draft ietf-hardware model and have a couple of comments that I would like feedback on.

I think it would make sense to add a field to the component state called reason or something similar to hold the error message casing the state. i.e FPC 0 Major Errors. What do you think?

Also I do not see a alarm-state for green, or good. How should this be modelled?

@wlupton I guess this is a question for you.

Routing Table ID Should be Included

On most devices, there is not just one "routing table," but rather several. Hence when a filter is installed, it needs to be installed per routing table -- and thus it would be nice to have a table id someplace within the model, or attached to each item, in some way.

Installer should also have process identifier

On many devices multiple instances of any given protocol process can run independently, each installing into a single forwarding table. To separate these, most implementations have a process id of some sort associated with each instance of a given process. This needs to be an option, at least, in the installer description.

Incorrectly formatted json data from openconfig data model

Hello @einarnn
With:
NX-OSv9K 7.0(3)I6(1)

capabilities: 
  capability: 
    - urn:ietf:params:netconf:base:1.0
    - urn:ietf:params:netconf:base:1.1
    - urn:ietf:params:netconf:capability:writable-running:1.0
    - urn:ietf:params:netconf:capability:rollback-on-error:1.0
    - urn:ietf:params:netconf:capability:candidate:1.0
    - urn:ietf:params:netconf:capability:validate:1.1
    - urn:ietf:params:netconf:capability:confirmed-commit:1.1
    - http://cisco.com/ns/yang/cisco-nx-os-device?revision=2017-05-16&module=cisco-nx-os-device&deviations=cisco-nx-os-device-deviations
    - http://openconfig.net/yang/bgp?revision=2016-06-06&module=openconfig-bgp&deviations=openconfig-bgp-deviations
    - http://openconfig.net/yang/bgp-multiprotocol?revision=2016-06-06&module=openconfig-bgp-multiprotocol&deviations=openconfig-bgp-multiprotocol-deviations
    - http://openconfig.net/yang/interfaces?revision=2016-05-26&module=openconfig-interfaces&deviations=openconfig-interfaces-deviations
    - http://openconfig.net/yang/interfaces/ip?revision=2016-05-26&module=openconfig-if-ip&deviations=openconfig-if-ip-deviations
    - http://openconfig.net/yang/local-routing?revision=2016-05-11&module=openconfig-local-routing&deviations=openconfig-local-routing-deviations
    - http://openconfig.net/yang/routing-policy?revision=2016-05-12&module=openconfig-routing-policy&deviations=openconfig-routing-policy-deviations
    - http://openconfig.net/yang/vlan?revision=2016-05-26&module=openconfig-vlan&deviations=openconfig-vlan-deviations

If I list OpenConfig interfaces with a RESTconf GET at restconf/data/openconfig-interfaces:interfaces?content=config, I get:

"data": {
...
    "content": "{\"interfaces\":{\"interface\":{\"config\":{\"name\":\"vlan1\"},\"name\":\"vlan1\",\"subinterfaces\":{\"subinterface\":{\"index\":\"0\"}}},\"interface\":{\"config\":{\"name\":\"eth1\\/39\"},\"name\":\"eth1\\/39\",\"subinterfaces\":{\"subinterface\":{\"index\":\"0\"}}},\"interface\":{\"config\":{\"name\":\"eth1\\/48\"},\"name\":\"eth1\\/48\",\"subinterfaces\":{\"subinterface\":{\"index\":\"0\"}}},\"interface\":{\"config\":{\"name\":\"eth1\\/42\"},\"name\":\"eth1\\/42\",\"subinterfaces\":{\"subinterface\":{\"index\":\"0\"}}},\"interface\":{\"config\":{\"name\":\"eth1\\/37\"},\"name\":\"eth1\\/37\",\"subinterfaces\":{\"subinterface\":{\"index\":\"0\"}}},\"interface\":{\"config\":{\"name\":\"eth1\\/35\"},\"name\":\"eth1\\/35\",\"subinterfaces\":{\"subinterface\":{\"index\":\"0\"}}},\"interface\":{\"config\":{\"name\":\"eth1\\/27\"},\"name\":\"eth1\\/27\",\"subinterfaces\":{\"subinterface\":{\"index\":\"0\"}}},\"interface\":{\"config\":{\"name\":\"eth1\\/3\"},\"name\":\"eth1\\/3\",\"subinterfaces\":{\"subinterface\":{\"index\":\"0\",\"ipv4\":{\"addresses\":{\"address\":{\"config\":{\"ip\":\"10.3.112.11\",\"prefix-length\":\"24\"},\"ip\":\"10.3.112.11\"}}}}},\"routed-vlan\":{\"ipv4\":{\"addresses\":{\"address\":{\"config\":{\"ip\":\"10.3.112.11\",\"prefix-length\":\"24\"},\"ip\":\"10.3.112.11\"}}}}},\"interface\":{\"config\":{\"name\":\"eth1\\/52\"},\"name\":\"eth1\\/52\",\"subinterfaces\":{\"subinterface\":{\"index\":\"0\"}}},\"interface\":{\"config\":{\"name\":\"eth1\\/54\"},\"name\":\"eth1\\/54\",\"subinterfaces\":{\"subinterface\":{\"index\":\"0\"}}},\"interface\":{\"config\":{\"name\":\"eth1\\/61\"},\"name\":\"eth1\\/61\",\"subinterfaces\":{\"subinterface\":{\"index\":\"0\"}}},\"interface\":{\"config\":{\"name\":\"eth1\\/58\"},\"name\":\"eth1\\/58\",\"subinterfaces\":{\"subinterface\":{\"index\":\"0\"}}},\"interface\":{\"config\":{\"name\":\"eth1\\/4\"},\"name\":\"eth1\\/4\",\"subinterfaces\":{\"subinterface\":{\"index\":\"0\",\"ipv4\":{\"addresses\":{\"address\":{\"config\":{\"ip\":\"10.3.113.11\",\"prefix-length\":\"24\"},\"ip\":\"10.3.113.11\"}}}},\"subinterface\":{\"index\":\"20\"},\"subinterface\":{\"index\":\"10\"}}},\"interface\":{\"config\":{\"name\":\"eth1\\/29\"},\"name\":\"eth1\\/29\",\"subinterfaces\":{\"subinterface\":{\"index\":\"0\"}}},\"interface\":{\"config\":{\"name\":\"eth1\\/47\"},\"name\":\"eth1\\/47\",\"subinterfaces\":{\"subinterface\":{\"index\":\"0\"}}},\"interface\":{\"config\":{\"name\":\"eth1\\/14\"},\"name\":\"eth1\\/14\",\"subinterfaces\":{\"subinterface\":{\"index\":\"0\"}}},\"interface\":{\"config\":{\"name\":\"eth1\\/9\"},\"name\":\"eth1\\/9\",\"subinterfaces\":{\"subinterface\":{\"index\":\"0\"}}},\"interface\":{\"config\":{\"name\":\"eth1\\/7\"},\"name\":\"eth1\\/7\",\"subinterfaces\":{\"subinterface\":{\"index\":\"0\",\"ipv4\":{\"addresses\":{\"address\":{\"config\":{\"ip\":\"10.3.116.11\",\"prefix-length\":\"24\"},\"ip\":\"10.3.116.11\"}}}},\"subinterface\":{\"index\":\"20\"},\"subinterface\":{\"index\":\"10\"}}},\"interface\":{\"config\":{\"name\":\"eth1\\/8\"},\"name\":\"eth1\\/8\",\"subinterfaces\":{\"subinterface\":{\"index\":\"0\"}}},\"interface\":{\"config\":{\"name\":\"eth1\\/25\"},\"name\":\"eth1\\/25\",\"subinterfaces\":{\"subinterface\":{\"index\":\"0\"}}},\"interface\":{\"config\":{\"name\":\"eth1\\/18\"},\"name\":\"eth1\\/18\",\"subinterfaces\":{\"subinterface\":{\"index\":\"0\"}}},\"interface\":{\"config\":{\"name\":\"eth1\\/40\"},\"name\":\"eth1\\/40\",\"subinterfaces\":{\"subinterface\":{\"index\":\"0\"}}},\"interface\":{\"config\":{\"name\":\"eth1\\/12\"},\"name\":\"eth1\\/12\",\"subinterfaces\":{\"subinterface\":{\"index\":\"0\"}}},\"interface\":{\"config\":{\"name\":\"eth1\\/36\"},\"name\":\"eth1\\/36\",\"subinterfaces\":{\"subinterface\":{\"index\":\"0\"}}},\"interface\":{\"config\":{\"name\":\"eth1\\/16\"},\"name\":\"eth1\\/16\",\"subinterfaces\":{\"subinterface\":{\"index\":\"0\"}}},\"interface\":{\"config\":{\"name\":\"eth1\\/1\"},\"name\":\"eth1\\/1\",\"subinterfaces\":{\"subinterface\":{\"index\":\"0\",\"ipv4\":{\"addresses\":{\"address\":{\"config\":{\"ip\":\"172.21.100.111\",\"prefix-length\":\"16\"},\"ip\":\"172.21.100.111\"}}}}},\"routed-vlan\":{\"ipv4\":{\"addresses\":{\"address\":{\"config\":{\"ip\":\"172.21.100.111\",\"prefix-length\":\"16\"},\"ip\":\"172.21.100.111\"}}}}},\"interface\":{\"config\":{\"name\":\"eth1\\/10\"},\"name\":\"eth1\\/10\",\"subinterfaces\":{\"subinterface\":{\"index\":\"0\"}}},\"interface\":{\"config\":{\"name\":\"eth1\\/49\"},\"name\":\"eth1\\/49\",\"subinterfaces\":{\"subinterface\":{\"index\":\"0\"}}},\"interface\":{\"config\":{\"name\":\"eth1\\/31\"},\"name\":\"eth1\\/31\",\"subinterfaces\":{\"subinterface\":{\"index\":\"0\"}}},\"interface\":{\"config\":{\"name\":\"eth1\\/53\"},\"name\":\"eth1\\/53\",\"subinterfaces\":{\"subinterface\":{\"index\":\"0\"}}},\"interface\":{\"config\":{\"name\":\"eth1\\/19\"},\"name\":\"eth1\\/19\",\"subinterfaces\":{\"subinterface\":{\"index\":\"0\"}}},\"interface\":{\"config\":{\"name\":\"eth1\\/38\"},\"name\":\"eth1\\/38\",\"subinterfaces\":{\"subinterface\":{\"index\":\"0\"}}},\"interface\":{\"config\":{\"name\":\"eth1\\/56\"},\"name\":\"eth1\\/56\",\"subinterfaces\":{\"subinterface\":{\"index\":\"0\"}}},\"interface\":{\"config\":{\"name\":\"eth1\\/43\"},\"name\":\"eth1\\/43\",\"subinterfaces\":{\"subinterface\":{\"index\":\"0\"}}},\"interface\":{\"config\":{\"name\":\"eth1\\/44\"},\"name\":\"eth1\\/44\",\"subinterfaces\":{\"subinterface\":{\"index\":\"0\"}}},\"interface\":{\"config\":{\"name\":\"eth1\\/5\"},\"name\":\"eth1\\/5\",\"subinterfaces\":{\"subinterface\":{\"index\":\"0\",\"ipv4\":{\"addresses\":{\"address\":{\"config\":{\"ip\":\"10.3.114.11\",\"prefix-length\":\"24\"},\"ip\":\"10.3.114.11\"}}}},\"subinterface\":{\"index\":\"10\"},\"subinterface\":{\"index\":\"20\"}}},\"interface\":{\"config\":{\"name\":\"eth1\\/34\"},\"name\":\"eth1\\/34\",\"subinterfaces\":{\"subinterface\":{\"index\":\"0\"}}},\"interface\":{\"config\":{\"name\":\"eth1\\/23\"},\"name\":\"eth1\\/23\",\"subinterfaces\":{\"subinterface\":{\"index\":\"0\"}}},\"interface\":{\"config\":{\"name\":\"eth1\\/21\"},\"name\":\"eth1\\/21\",\"subinterfaces\":{\"subinterface\":{\"index\":\"0\"}}},\"interface\":{\"config\":{\"name\":\"eth1\\/28\"},\"name\":\"eth1\\/28\",\"subinterfaces\":{\"subinterface\":{\"index\":\"0\"}}},\"interface\":{\"config\":{\"name\":\"eth1\\/22\"},\"name\":\"eth1\\/22\",\"subinterfaces\":{\"subinterface\":{\"index\":\"0\"}}},\"interface\":{\"config\":{\"name\":\"eth1\\/24\"},\"name\":\"eth1\\/24\",\"subinterfaces\":{\"subinterface\":{\"index\":\"0\"}}},\"interface\":{\"config\":{\"name\":\"eth1\\/55\"},\"name\":\"eth1\\/55\",\"subinterfaces\":{\"subinterface\":{\"index\":\"0\"}}},\"interface\":{\"config\":{\"name\":\"eth1\\/33\"},\"name\":\"eth1\\/33\",\"subinterfaces\":{\"subinterface\":{\"index\":\"0\"}}},\"interface\":{\"config\":{\"name\":\"eth1\\/11\"},\"name\":\"eth1\\/11\",\"subinterfaces\":{\"subinterface\":{\"index\":\"0\"}}},\"interface\":{\"config\":{\"name\":\"eth1\\/64\"},\"name\":\"eth1\\/64\",\"subinterfaces\":{\"subinterface\":{\"index\":\"0\"}}},\"interface\":{\"config\":{\"name\":\"eth1\\/41\"},\"name\":\"eth1\\/41\",\"subinterfaces\":{\"subinterface\":{\"index\":\"0\"}}},\"interface\":{\"config\":{\"name\":\"eth1\\/13\"},\"name\":\"eth1\\/13\",\"subinterfaces\":{\"subinterface\":{\"index\":\"0\"}}},\"interface\":{\"config\":{\"name\":\"eth1\\/45\"},\"name\":\"eth1\\/45\",\"subinterfaces\":{\"subinterface\":{\"index\":\"0\"}}},\"interface\":{\"config\":{\"name\":\"eth1\\/2\"},\"name\":\"eth1\\/2\",\"subinterfaces\":{\"subinterface\":{\"index\":\"0\",\"ipv4\":{\"addresses\":{\"address\":{\"config\":{\"ip\":\"10.3.111.11\",\"prefix-length\":\"24\"},\"ip\":\"10.3.111.11\"}}}}},\"routed-vlan\":{\"ipv4\":{\"addresses\":{\"address\":{\"config\":{\"ip\":\"10.3.111.11\",\"prefix-length\":\"24\"},\"ip\":\"10.3.111.11\"}}}}},\"interface\":{\"config\":{\"name\":\"eth1\\/63\"},\"name\":\"eth1\\/63\",\"subinterfaces\":{\"subinterface\":{\"index\":\"0\"}}},\"interface\":{\"config\":{\"name\":\"eth1\\/60\"},\"name\":\"eth1\\/60\",\"subinterfaces\":{\"subinterface\":{\"index\":\"0\"}}},\"interface\":{\"config\":{\"name\":\"eth1\\/62\"},\"name\":\"eth1\\/62\",\"subinterfaces\":{\"subinterface\":{\"index\":\"0\"}}},\"interface\":{\"config\":{\"name\":\"eth1\\/17\"},\"name\":\"eth1\\/17\",\"subinterfaces\":{\"subinterface\":{\"index\":\"0\"}}},\"interface\":{\"config\":{\"name\":\"eth1\\/59\"},\"name\":\"eth1\\/59\",\"subinterfaces\":{\"subinterface\":{\"index\":\"0\"}}},\"interface\":{\"config\":{\"name\":\"eth1\\/46\"},\"name\":\"eth1\\/46\",\"subinterfaces\":{\"subinterface\":{\"index\":\"0\"}}},\"interface\":{\"config\":{\"name\":\"eth1\\/50\"},\"name\":\"eth1\\/50\",\"subinterfaces\":{\"subinterface\":{\"index\":\"0\"}}},\"interface\":{\"config\":{\"name\":\"eth1\\/20\"},\"name\":\"eth1\\/20\",\"subinterfaces\":{\"subinterface\":{\"index\":\"0\"}}},\"interface\":{\"config\":{\"name\":\"eth1\\/57\"},\"name\":\"eth1\\/57\",\"subinterfaces\":{\"subinterface\":{\"index\":\"0\"}}},\"interface\":{\"config\":{\"name\":\"eth1\\/6\"},\"name\":\"eth1\\/6\",\"subinterfaces\":{\"subinterface\":{\"index\":\"0\",\"ipv4\":{\"addresses\":{\"address\":{\"config\":{\"ip\":\"10.3.115.11\",\"prefix-length\":\"24\"},\"ip\":\"10.3.115.11\"}}}},\"subinterface\":{\"index\":\"20\"},\"subinterface\":{\"index\":\"10\"}}},\"interface\":{\"config\":{\"name\":\"eth1\\/26\"},\"name\":\"eth1\\/26\",\"subinterfaces\":{\"subinterface\":{\"index\":\"0\"}}},\"interface\":{\"config\":{\"name\":\"eth1\\/51\"},\"name\":\"eth1\\/51\",\"subinterfaces\":{\"subinterface\":{\"index\":\"0\"}}},\"interface\":{\"config\":{\"name\":\"eth1\\/15\"},\"name\":\"eth1\\/15\",\"subinterfaces\":{\"subinterface\":{\"index\":\"0\"}}},\"interface\":{\"config\":{\"name\":\"eth1\\/32\"},\"name\":\"eth1\\/32\",\"subinterfaces\":{\"subinterface\":{\"index\":\"0\"}}},\"interface\":{\"config\":{\"name\":\"eth1\\/30\"},\"name\":\"eth1\\/30\",\"subinterfaces\":{\"subinterface\":{\"index\":\"0\"}}},\"xmlns\":\"http:\\/\\/openconfig.net\\/yang\\/interfaces\"}}", 
    "content_length": "8414", 
    "content_type": "application/yang.data+json", 
...

When saving the data to nice yaml or nice json with ansible, it appears that there may be duplicate keys so that only the last fields are kept:

interfaces:
    interface:
        config:
            name: eth1/30
        name: eth1/30
        subinterfaces:
            subinterface:
                index: '0'
    xmlns: http://openconfig.net/yang/interfaces

The whole discussion is available here about what I originally thought to be an ansible issue.

IOS-XR 6.2.1 openconfig no output from pyang

Attempting to execute pyang against several openconfig models results in no output, no errors, and return code 0.

pyang -f tree openconfig-mpls-sr.yang

The following have been confirmed with no output:

bash-3.2$ find . -name "openconfig-*.yang" | xargs -I'{}' bash check_output.sh '{}'
./openconfig-bgp-multiprotocol.yang
./openconfig-bgp-operational.yang
./openconfig-bgp-types.yang
./openconfig-extensions.yang
./openconfig-mpls-igp.yang
./openconfig-mpls-ldp.yang
./openconfig-mpls-rsvp.yang
./openconfig-mpls-sr.yang
./openconfig-mpls-static.yang
./openconfig-mpls-te.yang
./openconfig-mpls-types.yang
./openconfig-platform-types.yang
./openconfig-policy-types.yang
./openconfig-rib-bgp-types.yang
./openconfig-transport-types.yang
./openconfig-types.yang

The types probably shouldn't have any output - but I am surprised at the MPLS/BGP related models not having output. If this is expected, is there a way to see how they feed into another model?

Is there a recommended way of compiling or parsing openconfig files? If this looks like a pyang issue - then I will migrate this issue to pyang.

Missing 'aggregate-address' in router bgp

Running the following commands manually in equipment (XE 16.10):

router bgp 65001
 aggregate-address 10.90.0.0 255.255.0.0

The information appears when executing 'show running-config':

router bgp 65001
 bgp log-neighbor-changes
 aggregate-address 10.90.0.0 255.255.0.0
!

But executing get-config through netconf operation does not return the aggregate-address info:

...
<router>
	<bgp xmlns="http://cisco.com/ns/yang/Cisco-IOS-XE-bgp">
		<id>65001</id>
		<bgp>
			<log-neighbor-changes/>
		</bgp>
	</bgp>
</router>
...

ask the reason of removing nc-notifications.yang&notifications.yang

Hi, @mKunihiroIshiguro ,
i find these experimental yang files like notfications.yang/nc-notifications.yang were removed in this commit:
f30999e
if it have a newer yang to replace them?
or it will never have a notification1.0's yang file?
why they are being removed? I want to know about the backgroud.
thanks a lot!

sincerely yours.

Automatically synchronize the latest YANG models from OpenDaylight to this repo

In #554, @bclaise suggested:

posting the latest YANG modules

This isn't something I should manually clobber together once, but which should be automated... at the very least scripted so that anyone can do it manually, at best running nightly in a CI/CD somewhere.

I remember having seen emails with subject "Publishing ODL models to github" about this last year on the ODL TSC mailing list, but looks like it hasn't actually happened:

Different line endings CR LF in the same file.

Congratulation for the great repo.

Some files have different line endings, for example ietf-microwave-radio-link

$ cat -A experimental/ietf-extracted-YANG-modules/[email protected] | more
module ietf-microwave-radio-link {^M$
  yang-version 1.1;^M$
  namespace "urn:ietf:params:xml:ns:yang:ietf-microwave-radio-link";^M$
  prefix mrl;^M$
$
  import ietf-yang-types {^M$

You can see that after mrl; there is a ^M but in the new line exists only $

Avalanche of errors and warnings in Cisco Yang Modules when converted to tree format with pyang

@einarnn I've discovered many issues when trying to convert all Cisco Yang modules to tree format with pyang -f tree(pyang 1.7.1):

  • NX-OS modules: invalid regular expressions,
  • IOS-XE modules (1631): a few node ned::xxxxx is not found appeared.
  • IOX-XR modules (534-600-601-602-611-612-613-621): many errors popped up when when the search path is set at cisco/xr:
    • restriction require-instance not allowed for this base type ,
    • grouping "xxxxxx" not found in modulexxxx,
    • there is already a child node to "xxxxxx" at xxxx,
    • the list at "xxxxxxxxxx (at xr/600/xxxxxxxx)" needs at least one key because it is used as config,
    • type "xxxxxxxx" not found in module xxxxx.
    • node "xxxxxxxx" not found in module xxxxx.
    • extension "xxxxxx" is not defined in module xxxxxxx

Also, other errors appear when it is set at cisco/xr/<xr_version>.

I'm not even listing the ton of warnings for unnecessary imports regarding modules across the board.

The whole log is available here when search_path="cisco/<nos>".
The whole log is available here when search_path="cisco/<nos>/<nos_version>".

FYI, all latest official openconfig Yang modules (https://github.com/openconfig/public) pass the same conversion with flying colors.

Cisco-IOS-XE-Tunnel for postman

Hi,
Recently I am working with RESTCONF on Postman.
Today I was trying to send HTTP request via postman to IOS-XE-Tunnel using the below path:
https://XXX:XXX/restconf/data/Cisco-IOS-XE-tunnel:tunnel
Usually this should return the data within the container "tunnel", however I am getting the following message:
"error-message": "uri keypath not found", "error-tag": "invalid-value", "error-type": "application"
My goal is to get the data within the leaf "bandwidth" from this yang module. Can anyone help me with a correct path?

license model of Cisco Yang modules

Hello @einarnn
Please advise for the license model of Cisco modules, or please advise whom to contact for this.

I've found the license model (Apache 2.0) for modules by Huawei and Juniper, but can't find it for Yang modules by Cisco.

Thank you,
Andrei

IETF draft YANG extraction cronjob has stopped updating the repository

Hi,

I noticed recently that the daily cronjob for the IETF draft YANG module extraction from the draft IETF standards has stopped. I am specifically looking at the ietf-ptp.yang and the ietf-igmp-mld-snooping.yang. I believe these draft IETF modules have been updated recently. Was there an issue running the cronjob recently?

Thanks,
William Z

ietf-isis.yang is not in the latest version

Stephane Litkowski sent me the latest one, how is the update process for this file in this repo?
A pull request from my side was not possible, as I do not have the access rights

commit 3db9bdb84cee02a1a2 went to wrong repo

I messed up somehow.
Thought I was committing to abierman/yang-ab1 but it went to the real repo instead.

Changes should be safe.

moved ietf-restconf.yang from DRAFT to RFC
moved ietf-restconf-monitoring.yang from DRAFT to RFC
update modules with versions from RFC 8040

TypedefStatement Issue

I got an error when i use typedefstatement as a reference in the typestatement.

I get a reference error in my dsl editor.

I am expecting
type yang:object-identifier-128;

but it shows me
type yang:ietf-yang-types.object-identifier-128.

Is there anything wrong in my code or I missed any code?

I am only using xtext grammar from the file YANG.xtext

Thanks.

Length of vendor-oui is incorrect.

typedef vendor-oui {
  type yang:hex-string {
    length 6;
  }
  description "24-bit Organizationally Unique Identifier";
  reference
    "IEEE Std 802-2001, Clause 9";
}

The 'length' statement here applies to the base type string and not the length of the type hex-string. The type hex-string of the pattern xx:xx:xx ... so for a 3 byte OUI, overall length of the string is 8 inclusive of the : separators.

identity "bgp-capability" not found in module openconfig-bgp-types

Hello,

I am facing this error while trying to parse the yang file openconfig-bgp-operational. The bgp-capability it should be present in the openconfig-bgp-types.
"openconfig-bgp-operational.yang:160: error: identity "bgp-capability" not found in module openconfig-bgp-types"

Accept and Reject route aren't that simple

Reject and accept route aren't that simple. There is a difference between accepting the route into the local database of the routing protocol, and installing it into an actual forwarding table. In a link state protocol, for instance, it is routine to filter routes between the SPT and the routing table they're intended for.

Install Protocols Should be Identities

BGP, EIGRP, and I2RS, at least, should be included in the list. There are a number of other protocols in the MANET space that will eventually need to be added, as well as various other learning mechanisms, so there should be some space for new protocols and installs.

Backslash use in some models (with a patch)

A number of models seem to make incorrect use of the backslash in strings, which are typically either descriptions, or regular expressions (in pattern statements). Most frequently the problems are:

  • Forgetting to escape the backslash operation in double quote strings. Often regular expressions are copied as is, without escaping the '' character.
  • In a number of cases, multi-line strings use the backslash to terminate a line (similar to C code). This is not necessary, and it is also wrong.

I have fixed some of those problems (and few others) in the patches attached.
In retrospect, for the regular expressions, the better approach for many cases would have been to use single-quoted string; it was easier though to replace '' with '\'.

Many thanks for this repo. It is very useful!

-christos

SomeFixes-MostlyWithBackslash.zip

XR 6.3.2, tailf import missing

Hi,

Found this issue:

yang/Cisco-IOS-XR-sysadmin-entity-mib.yang:90: error: prefix 'tailf' not found
yang/Cisco-IOS-XR-sysadmin-entity-mib.yang:130: error: prefix 'tailf' not found

Roque

data model is missing "pce / disjoint-path / group-id (srlg-node) / lsp (1&2)"

Cisco IOS XRv 6.2.1 yang data model “Cisco-IOS-XR-infra-xtc-cfg.yang” does not list the SRLG-NODE disjointness type, and it does not list the LSPs under each group.

  container disjoint-path {
     description "Disjoint path configuration";
     container groups {                 <<<<<<<< the container “groups” only has 3 leaves: group-id, dp-type, and sub-id. It does not list the LSPs under each group
       description "Association configuration";
       list group {
         key "group-id dp-type sub-id";
         description "Association Group Configuration";
         leaf strict {
           type empty;
           description "Disable Fallback";
         }
         leaf group-id {
           type uint32 {
             range "1..65535";
           }
           description "Group ID";
         }
         leaf dp-type {
           type Pce-disjoint-path;               <<<<<<<<  see type definition below: it lists only LINK or NODE or SRLG, but not SRLG-NODE
           description "Disjoiness type";
         }
         leaf sub-id {
           type uint32 {
             range "0..65535";
           }
           description "Sub group ID, 0 to unset";
         }

 typedef Pce-disjoint-path {
   type enumeration {
     enum link {
       value 1;
       description "Link";
     }
     enum node {
       value 2;
       description "Node";
     }
     enum srlg {
       value 3;
       description "SRLG";
     }
   }
   description "Pce disjoint path";
 }


Here's the CLI Config on the IOS XR:
pce
disjoint-path
group-id 10 type srlg-node
lsp 1 pcc ipv4 1.1.1.1 lsp-name CUST-ABC-LSP-R1-R2-GRP10-SRLGNODE
lsp 2 pcc ipv4 4.4.4.4 lsp-name CUST-ABC-LSP-R4-R5-GRP10-SRLGNODE
!
group-id 14 type srlg
lsp 1 pcc ipv4 1.1.1.1 lsp-name CUST-ABC-LSP-R1-R2-GRP14-SRLG
lsp 2 pcc ipv4 4.4.4.4 lsp-name CUST-ABC-LSP-R4-R5-GRP14-SRLG
!
group-id 15 type link
lsp 1 pcc ipv4 1.1.1.1 lsp-name CUST-ABC-LSP-R1-R2-GRP15-LINK
lsp 2 pcc ipv4 4.4.4.4 lsp-name CUST-ABC-LSP-R4-R5-GRP15-LINK
!
group-id 16 type node
lsp 1 pcc ipv4 1.1.1.1 lsp-name CUST-ABC-LSP-R1-R2-GRP16-NODE
lsp 2 pcc ipv4 4.4.4.4 lsp-name CUST-ABC-LSP-R4-R5-GRP16-NODE


And, if I try to get the config via NETCONF:

<?xml version="1.0" encoding="utf-8"?>
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="21">
  <get-config>
    <source>
      <running/>
    </source>
    <filter type="subtree">
      <pce xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-infra-xtc-cfg">
        <disjoint-path/>
      </pce>
    </filter>
  </get-config>
</rpc>

NETCONF gives me only the following:

<?xml version="1.0" encoding="utf-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="21">
  <data>
    <pce xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-infra-xtc-cfg">
      <disjoint-path>
        <groups>
          <group>
            <group-id>14</group-id>
            <dp-type>srlg</dp-type>
            <sub-id>0</sub-id>
          </group>
          <group>
            <group-id>15</group-id>
            <dp-type>link</dp-type>
            <sub-id>0</sub-id>
          </group>
          <group>
            <group-id>16</group-id>
            <dp-type>node</dp-type>
            <sub-id>0</sub-id>
          </group>
        </groups>
      </disjoint-path>
    </pce>
  </data>
</rpc-reply>

pyang gives errors for undefined nodes for ietf-isis.yang.

sidhesh@flex-dev-1:~/yang$ pyang -f tree standard/ietf/DRAFT/ietf-isis.yang -p standard/ietf/RFC -p standard/ietf/DRAFT
standard/ietf/DRAFT/ietf-isis.yang:97: error: ietf-routing:routing-instance in the path for routing-protocol-instance-name at standard/ietf/DRAFT/ietf-isis.yang:1551 is not found
standard/ietf/DRAFT/ietf-isis.yang:97: error: ietf-routing:routing-instance in the path for routing-protocol-instance-name at standard/ietf/DRAFT/ietf-isis.yang:1614 is not found
standard/ietf/DRAFT/ietf-isis.yang:97: error: ietf-routing:routing-instance in the path for isis-instance-state-ref at standard/ietf/DRAFT/ietf-isis.yang:94 is not found
standard/ietf/DRAFT/ietf-isis.yang:129: warning: the escape sequence "." is unsafe in double quoted strings - pass the flag --lax-quote-checks to avoid this warning
standard/ietf/DRAFT/ietf-isis.yang:138: warning: the escape sequence "." is unsafe in double quoted strings - pass the flag --lax-quote-checks to avoid this warning
standard/ietf/DRAFT/ietf-isis.yang:139: warning: the escape sequence "." is unsafe in double quoted strings - pass the flag --lax-quote-checks to avoid this warning
standard/ietf/DRAFT/ietf-isis.yang:150: warning: the escape sequence "." is unsafe in double quoted strings - pass the flag --lax-quote-checks to avoid this warning
standard/ietf/DRAFT/ietf-isis.yang:241: error: node ietf-routing::active-route is not found
standard/ietf/DRAFT/ietf-isis.yang:1037: error: node ietf-routing::routing-instance is not found
standard/ietf/DRAFT/ietf-isis.yang:1148: error: ietf-routing:routing-instance in the path for name at standard/ietf/DRAFT/ietf-isis.yang:1145 is not found
standard/ietf/DRAFT/ietf-isis.yang:1255: error: node ietf-routing::routing-instance is not found
standard/ietf/DRAFT/ietf-isis.yang:1538: error: type "routing-instance-state-ref" not found in module ietf-routing
standard/ietf/DRAFT/ietf-isis.yang:1601: error: type "routing-instance-state-ref" not found in module ietf-routing

Remove old OpenDaylight internal config system (CSS) YANG models

Modes such as the opendaylight-dom-broker-impl.yang describe internal Java object wiring of OpenDaylight internal config system (CSS), and IMHO make no sense to / could never be of any real world interest outside of ODL's internal code...

Further and more importantly, these have long ago disappeared from OpenDaylight (me and others have replaced what this used to be used for by regular Java dependency injection; initially OSGi Blueprint XML and more recently even simpler @javax.annotation.Inject).

Would you guys like a PR to to git rm e.g. all of these ?

@tnadeau

how To Subscribe and Browse Click Here

When i click the To Subscribe and Browse Click Here link i'm unable to access yangmodels.slack.com with my slack account. How would i go about joining?

Thank You

Yang Viewer NoClassDefFoundError

I have built the yangviewer-project.
But it seems like there is missing a class in the repository.
I can build the jar with the pom.xml

But when i run "java -jar yang-viewer-1.0.0-SNAPSHOT-jar-with-dependencies.jar" it fails.

Exception in thread "main" java.lang.NoClassDefFoundError: org/opendaylight/yang
tools/yang/model/parser/api/YangContextParser
at org.brocade.yangviewer.Main.createJTree(Main.java:123)
at org.brocade.yangviewer.Main.main(Main.java:91)
Caused by: java.lang.ClassNotFoundException: org.opendaylight.yangtools.yang.mod
el.parser.api.YangContextParser
at java.net.URLClassLoader$1.run(Unknown Source)
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
... 2 more

Browsing NX-OS 9k installed yang models with RESTconf

NX-OS 9kv 7.0(3)I6(1)

Hello @einarnn
I'm having a hard time figuring out the URI(s) which must be used to attain the openconfig resources supported by this device.
Using yang-explorer, I can confirm that it does support openconfig:

urn:ietf:params:netconf:base:1.0
urn:ietf:params:netconf:base:1.1
urn:ietf:params:netconf:capability:candidate:1.0
urn:ietf:params:netconf:capability:confirmed-commit:1.1
urn:ietf:params:netconf:capability:rollback-on-error:1.0
urn:ietf:params:netconf:capability:validate:1.1
urn:ietf:params:netconf:capability:writable-running:1.0

http://cisco.com/ns/yang/cisco-nx-os-device?revision=2017-05-16&amp;module=cisco-nx-os-device&amp;deviations=cisco-nx-os-device-deviations
http://openconfig.net/yang/bgp-multiprotocol?revision=2016-06-06&amp;module=openconfig-bgp-multiprotocol&amp;deviations=openconfig-bgp-multiprotocol-deviations
http://openconfig.net/yang/bgp?revision=2016-06-06&amp;module=openconfig-bgp&amp;deviations=openconfig-bgp-deviations
http://openconfig.net/yang/interfaces/ip?revision=2016-05-26&amp;module=openconfig-if-ip&amp;deviations=openconfig-if-ip-deviations
http://openconfig.net/yang/interfaces?revision=2016-05-26&amp;module=openconfig-interfaces&amp;deviations=openconfig-interfaces-deviations
http://openconfig.net/yang/local-routing?revision=2016-05-11&amp;module=openconfig-local-routing&amp;deviations=openconfig-local-routing-deviations
http://openconfig.net/yang/routing-policy?revision=2016-05-12&amp;module=openconfig-routing-policy&amp;deviations=openconfig-routing-policy-deviations
http://openconfig.net/yang/vlan?revision=2016-05-26&amp;module=openconfig-vlan&amp;deviations=openconfig-vlan-deviations

I can also GET all vendor specific data returned by http://ip_address/restconf/data/Cisco-NX-OS-device:System?content=config: Cisco-NX-OS-device:System.yml

But what URI should I use to GET the openconfig data?
I tried all sorts of URIs, including

  • http://ip_address/restconf/data/Cisco-NX-OS-device:Openconfig?content=config
  • http://ip_address/restconf/data/Openconfig?content=config

Each time, I receive a 400: Bad Request.

Generally speaking, is there a method to automatically discover the URI of any Yang resource on any Cisco platform?

  • NX-OS
  • IOS-XE
  • IOS-XR
  • ASA

Invalid Patterns In CISCO Yang Models

Apologies in advanced if I am incorrect. I am trying to use libyang in conjunction with this library of yang models and I an unable to parse several of the CISCO/XR/602 models files.

For instance: Cisco-IOS-XR-types.yang

In troubleshooting this issue I've learned that libyang is complaining about the fact that the regex patterns in this file contain un-escaped backslashes in double quotes, rather than escaping the the backslashes or enclosing the pattern in single quotes.

I believe its the same issue documented here:

CESNET/libyang#283

Note that I have the same issue with the yang model retrieved from the Cisco Router itself, so its clearly a disconnect rather than a typo.

Thanks in advance for your help.

Cisco IOS XRv 6.5.1 || pce associations operational data not retrieved for type srlg-node

Hello

We are trying to retrieve the pce associations status from XRv 9k running 6.5.1 and the below configuration based on "Cisco-IOS-XR-infra-xtc-oper.yang" model

It seems that we can only retrieve data for type "node" only but not for other types

Topology:
Cisco XRv 9K + Opendaylight

Here's the CLI Config on the IOS XR:

pce
 address ipv4 3.3.3.3
 disjoint-path
  group-id 1 type node
   lsp 1 pcc ipv4 11.11.11.11 lsp-name a
   lsp 2 pcc ipv4 4.4.4.4 lsp-name b
  !
  group-id 10 type srlg-node
  lsp 1 pcc ipv4 1.1.1.1 lsp-name CUST-ABC-LSP-R1-R2-GRP10-SRLGNODE
  lsp 2 pcc ipv4 4.4.4.4 lsp-name CUST-ABC-LSP-R4-R5-GRP10-SRLGNODE
!
  group-id 14 type srlg
  lsp 1 pcc ipv4 1.1.1.1 lsp-name CUST-ABC-LSP-R1-R2-GRP14-SRLG
  lsp 2 pcc ipv4 4.4.4.4 lsp-name CUST-ABC-LSP-R4-R5-GRP14-SRLG
!
  group-id 15 type link
  lsp 1 pcc ipv4 1.1.1.1 lsp-name CUST-ABC-LSP-R1-R2-GRP15-LINK
  lsp 2 pcc ipv4 4.4.4.4 lsp-name CUST-ABC-LSP-R4-R5-GRP15-LINK
!
  group-id 16 type node
  lsp 1 pcc ipv4 1.1.1.1 lsp-name CUST-ABC-LSP-R1-R2-GRP16-NODE
  lsp 2 pcc ipv4 4.4.4.4 lsp-name CUST-ABC-LSP-R4-R5-GRP16-NODE

GET: http://{{ODL}}:8181/restconf/operational/network-topology:network-topology/topology/topology-netconf/node/PCE/yang-ext:mount/Cisco-IOS-XR-infra-xtc-oper:pce/association-infos/

Result:

<association-infos xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-infra-xtc-oper">
    <association-info>
        <group-id>1</group-id>
        <headends-swapped>0</headends-swapped>
        <status>0</status>
        <strict>false</strict>
        <association-type>2</association-type>
        <association-id>1</association-id>
        <association-source>
            <af-name>ipv4</af-name>
            <ipv4>0.0.0.0</ipv4>
        </association-source>
        <type>node</type>
        <sub-id>0.0.0.0</sub-id>
    </association-info>
</association-infos>

I also tried to retrieve same info using netconf get directly from the router with same results

<get>
  <filter>
    <pce-lsp-data xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-infra-xtc-oper"/>
  </filter>
</get>

Filtered Result

      <association-infos>
        <association-info>
          <group-id>1</group-id>
          <type>node</type>
          <sub-id>0.0.0.0</sub-id>
          <association-type>2</association-type>
          <association-id>1</association-id>
          <association-source>
            <af-name>ipv4</af-name>
            <ipv4>0.0.0.0</ipv4>
          </association-source>
          <strict>false</strict>
          <status>0</status>
          <headends-swapped>0</headends-swapped>
        </association-info>
      </association-infos>

`yang-viewer` not working

Hi,
I'm just getting started figuring out YANG with the view of describing the configuration for a small industrial device (which will use CoMI for configuration). In an effort to better understand what I was writing I tried getting yang-viewer working.

Out of the box it fails to find a snapshot, a problem solved by this patch:

diff --git a/tools/yang_viewer/pom.xml b/tools/yang_viewer/pom.xml
index 9a3d5a4e..789ae501 100755
--- a/tools/yang_viewer/pom.xml
+++ b/tools/yang_viewer/pom.xml
@@ -11,7 +11,7 @@
        <description>YANG parser</description>
 
        <properties>
-               <odl.yang.version>0.6.2-SNAPSHOT</odl.yang.version>
+               <odl.yang.version>0.6.3-Helium-SR1</odl.yang.version>
                <java.version.source>1.7</java.version.source>
                <java.version.target>1.7</java.version.target>
                <maven.compile.plugin.version>3.2</maven.compile.plugin.version>
@@ -231,4 +231,4 @@
                </repository>
        </repositories>
 
-</project>
\ No newline at end of file
+</project>

However, running the tool, it tells me to drag and drop the file. How does one do that in xterm?

ietf-*-types missing from repo for IOS XE < 16.5.1 and IOS XR < 6.0.2, 6.1.1

The ietf-inet-types.yang file appears to be missing from:
https://github.com/YangModels/yang/tree/master/vendor/cisco/xe/1631
https://github.com/YangModels/yang/tree/master/vendor/cisco/xe/1632
https://github.com/YangModels/yang/tree/master/vendor/cisco/xe/1641

This yields incomplete parsing.

EDIT:
The types are also not in the folders corresponding to IOS XR versions < 6.0.2. Revised title. This seems to be understood per IOS XE check and IOS XR check. Are items pre-"check"able reasonable to parse? Or something to ignore?

EDIT:
Also missing in IOS XR 6.1.1.

EDIT:
Other ietf-*-types modules are missing in various IOS XE repos as well. ietf-yang-types for instance. Have not validated other repos.

Remove 'maste' branch

I think this branch has been created by mistake. It's annoying because tab completion tends to "get stuck" on "maste" instead of "master" ;)

Cisco platform version folder naming convention is not accurate

The version folders in the platform folders under Cisco as a vendor do not match the actual version naming.

For example:
xr/621/ -> xr/6.2.1/

These little inconsistencies make it difficult to write parsing tools without an understanding of how to parse these folder names in to Cisco platform versions, which are unfortunately inconsistent in their versioning scheme as well.

Ideally, these folders should match the version names that they represent exactly.

BGP Policy Primitives

Not certain if the idea was to have a separate BGP policy model or not, but if not, none of the BGP policy primitives are included here, either in set or filter. Community strings (like tags in OSPF/IS-IS) are the most important. Setting the MED, Local Pref, AS Path attributes (strip private, remove AS from path, AS Path Prepend), and various others should be included if BGP is a target.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.