Config
Leafs
- class Interfaces.Interface.Config
Bases:
EntityClass Hierarchy :
InterfacesInterfaceConfigThis class represents configuration data.
Configurable items at the global, physical interface
level
- type
[adapted from IETF interfaces model (RFC 7223)] The type of the interface. When an interface entry is created, a server MAY initialize the type leaf with a valid value, e.g., if it is possible to derive the type from the name of the interface. If a client tries to set the type of an interface to a value that can never be used by the system, e.g., if the type is not supported or if the type does not match the name of the interface, the server MUST reject the request. A NETCONF server MUST reply with an rpc-error with the error-tag ‘invalid-value’ in this case
type: one of the below values:
IanaInterfaceType
- mtu
Set the max transmission unit size in octets for the physical interface. If this is not set, the mtu is set to the operational default -- e.g., 1514 bytes on an Ethernet interface
type: int
range: 0..65535
- 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