Config

Leafs

class Interfaces.Interface.Subinterfaces.Subinterface.Config

Bases: Entity

Class Hierarchy : Interfaces Interface Subinterfaces Subinterface Config

This class represents configuration data.

Configurable items at the subinterface level

index

The index of the subinterface, or logical interface number. On systems with no support for subinterfaces, or not using subinterfaces, this value should default to 0, i.e., the default subinterface

type: int

range: 0..4294967295

default value: 0

name

[adapted from IETF interfaces model (RFC 7223)] The name of the interface. A device MAY restrict the allowed values for this leaf, possibly depending on the type of the interface. For system-controlled interfaces, this leaf is the device-specific name of the interface. The ‘config false’ list interfaces/interface[name]/state contains the currently existing interfaces on the device. If a client tries to create configuration for a system-controlled interface that is not present in the corresponding state list, the server MAY reject the request if the implementation does not support pre-provisioning of interfaces or if the name refers to an interface that can never exist in the system. A NETCONF server MUST reply with an rpc-error with the error-tag ‘invalid-value’ in this case. The IETF model in RFC 7223 provides YANG features for the following (i.e., pre-provisioning and arbitrary-names), however they are omitted here: If the device supports pre-provisioning of interface configuration, the ‘pre-provisioning’ feature is advertised. If the device allows arbitrarily named user-controlled interfaces, the ‘arbitrary-names’ feature is advertised. When a configured user-controlled interface is created by the system, it is instantiated with the same name in the /interfaces/interface[name]/state list

type: str

description

[adapted from IETF interfaces model (RFC 7223)] A textual description of the interface. A server implementation MAY map this leaf to the ifAlias MIB object. Such an implementation needs to use some mechanism to handle the differences in size and characters allowed between this leaf and ifAlias. The definition of such a mechanism is outside the scope of this document. Since ifAlias is defined to be stored in non-volatile storage, the MIB implementation MUST map ifAlias to the value of ‘description’ in the persistently stored datastore. Specifically, if the device supports ‘:startup’, when ifAlias is read the device MUST return the value of ‘description’ in the ‘startup’ datastore, and when it is written, it MUST be written to the ‘running’ and ‘startup’ datastores. Note that it is up to the implementation to decide whether to modify this single leaf in ‘startup’ or perform an implicit copy-config from ‘running’ to ‘startup’. If the device does not support ‘:startup’, ifAlias MUST be mapped to the ‘description’ leaf in the ‘running’ datastore

type: str

enabled

[adapted from IETF interfaces model (RFC 7223)] This leaf contains the configured, desired state of the interface. Systems that implement the IF-MIB use the value of this leaf in the ‘running’ datastore to set IF-MIB.ifAdminStatus to ‘up’ or ‘down’ after an ifEntry has been initialized, as described in RFC 2863. Changes in this leaf in the ‘running’ datastore are reflected in ifAdminStatus, but if ifAdminStatus is changed over SNMP, this leaf is not affected

type: bool

default value: true