The MIB module to manage and provision the Nokia SROS LDP NG protocol
features.
Copyright 2013-2018 Nokia. All rights reserved. Reproduction of this
document is authorized on the condition that the foregoing copyright
notice is included.
This SNMP MIB module (Specification) embodies Nokia's
proprietary intellectual property. Nokia retains
all title and ownership in the Specification, including any
revisions.
Nokia grants all interested parties a non-exclusive license to use and
distribute an unmodified copy of this Specification in connection with
management of Nokia products, and without fee, provided this copyright
notice and license appear on all copies.
This Specification is supplied 'as is', and Nokia makes no warranty,
either express or implied, as to the use, operation, condition, or
performance of the Specification.
[CAUSE] The vRtrLdpNgIpv4InstStateChange is generated when the IPv4
LDP instance changes state operationally as specified by
vRtrLdpNgGenIPv4OperState.
[EFFECT] Based on the vRtrLdpNgGenIPv4OperDownReason reason code, the
system may not be able to accept new requests from peers.
[RECOVERY] Based on the vRtrLdpNgGenIPv4OperDownReason reason code,
appropriate configuration changes in LDP may be required.
vRtrLdpNgAddrFecCommMismatch
.1.3.6.1.4.1.6527.3.1.3.91.0.11
[CAUSE] A vRtrLdpNgAddrFecCommMismatch notification is generated when
two or more peer routers advertising labels for the given address FEC
have been assigned differing communities, or some have been assigned
communities and some have not. It will also be generated if multiple
LDP peer routers have been configured to advertise their local LSR-ID
as a FEC, and those peer routers have been assigned differing communities.
This notification is rate-limited to at most one notification every 60 seconds.
[EFFECT] This condition indicates that the network is misconfigured,
and it is likely that the affected address FEC is not being advertised
to the routers which the operator intends.
[RECOVERY] Analyze, check and fix the community configuration for all
LDP session-parameters and LDP targeted-session peer-templates in the
network to find the error. Start with the configuration on the router
generating the notification, and if this is correct, look next at the
routers advertising the labels to see if their configuration is correct.
vRtrLdpNgIpv6InstStateChange
.1.3.6.1.4.1.6527.3.1.3.91.0.2
[CAUSE] The vRtrLdpNgIpv6InstStateChange is generated when the IPv6
LDP instance changes state operationally as specified by
vRtrLdpNgGenIPv6OperState.
[EFFECT] Based on the vRtrLdpNgGenIPv6OperDownReason reason code, the
system may not be able to accept new requests from peers.
[RECOVERY] Based on the vRtrLdpNgGenIPv6OperDownReason reason code,
appropriate configuration changes in LDP may be required.
vRtrLdpNgIfStateChange
.1.3.6.1.4.1.6527.3.1.3.91.0.3
[CAUSE] The vRtrLdpNgIfStateChange notification is generated when the
LDP interface changes state either administratively or operationally.
[EFFECT] Based on the vRtrLdpNgIfOperDownReason reason code, the
system may not be able to accept new requests from peers over this
interface.
[RECOVERY] Based on the vRtrLdpNgIfOperDownReason reason code,
appropriate configuration changes in LDP may be required.
vRtrLdpNgInetIfStateChange
.1.3.6.1.4.1.6527.3.1.3.91.0.4
[CAUSE] The vRtrLdpNgInetIfStateChange notification is generated when
the LDP sub-interface changes state either administratively or
operationally.
[EFFECT] Based on the vRtrLdpNgInetIfOperDownReason reason code, the
system may not be able to accept new requests over this interface.
[RECOVERY] Based on the vRtrLdpNgInetIfOperDownReason reason code,
appropriate configuration changes in LDP may be required.
vRtrLdpNgTargPeerStateChange
.1.3.6.1.4.1.6527.3.1.3.91.0.5
[CAUSE] The vRtrLdpNgTargPeerStateChange notification is generated
when the LDP peer changes state either administratively or
operationally.
[EFFECT] Based on the vRtrLdpNgTargPeerOperDownReason reason code, the
system may not be able to accept new requests from this peer.
[RECOVERY] Based on the vRtrLdpNgTargPeerOperDownReason reason code,
appropriate configuration changes in LDP may be required.
vRtrLdpNgSessionStateChange
.1.3.6.1.4.1.6527.3.1.3.91.0.6
[CAUSE] The vRtrLdpNgSessionStateChange notification is generated when
the LDP Overload Notification message is sent to or received from the
peer vRtrLdpNgPeerLdpId for the combination of
vRtrLdpNgSessOverloadFecType and vRtrLdpNgSessOvldFecTypeSubTyp while
vRtrLdpNgSessState remains 'operational'.
[EFFECT] Once the Local LSR has sent the LDP Overload Notification
message to the peer vRtrLdpNgPeerLdpId for fec and sub type fec
indicated by vRtrLdpNgSessOverloadFecType and
vRtrLdpNgSessOvldFecTypeSubTyp and vRtrLdpNgSessOverloadState has the
value of 'true', then new Label Mapping Messages received for this
peer for the given combination of fec and sub type fec is returned
with a Label Release Message.
If the Local LSR has received an LDP Overload Notification message
from the peer vRtrLdpNgPeerLdpId for fec and sub type fec indicated by
vRtrLdpNgSessOverloadFecType and vRtrLdpNgSessOvldFecTypeSubTyp and
vRtrLdpNgSessOverloadState has the value of 'true', no new Label
Mapping Message for the given combination of fec and sub type fec will
be sent to this peer.
If the Local LSR has received an LDP Overload Notification message
from the peer vRtrLdpNgPeerLdpId for fec and sub type fec indicated by
vRtrLdpNgSessOverloadFecType and vRtrLdpNgSessOvldFecTypeSubTyp and
vRtrLdpNgSessOverloadState has the value of 'false', then the Local
LSR will send all pending and any new Label Mapping Message for the
given combination of fec and sub type fec to this peer.
[RECOVERY] In case the Local LSR sent the LDP Overload Notification
message to the peer vRtrLdpNgPeerLdpId and vRtrLdpNgSessOverloadState
has the value of 'true' for fec and sub type fec indicated by
vRtrLdpNgSessOverloadFecType and vRtrLdpNgSessOvldFecTypeSubTyp, then
appropriate LDP configuration changes may be required on the Local
and/or Remote LSR.
Once the Local LSR is not overloaded anymore, an LDP Overload
Notification message is sent to the peer vRtrLdpNgPeerLdpId and
vRtrLdpNgSessOverloadState has the value of 'false' for given fec and
sub type fec.
vRtrLdpNgSessMaxFecThresChanged
.1.3.6.1.4.1.6527.3.1.3.91.0.7
[CAUSE] A vRtrLdpNgSessMaxFecThresChanged notification is generated
when the number of FECs accepted from the peer has exceeded or drops
below vRtrLdpNgSessOperMaxFecThreshold percent of the value specified
by vRtrLdpNgSessParamMaxFec.
New notification will not be generated if multiple internal change
events occur for the same level indicated by
vRtrLdpNgSessOperThresLevel during a 2 minute interval.
If any parameter in FEC limit configuration changes then we would
always raise this trap if current number of FECs are above the
configured threshold or has crossed the threshold downwards. If we
remain on or below the configured threshold before and after the
configuration changes then no trap would be generated.
[EFFECT] No direct effect but if the peer LSR continues to send
further Label Mapping Message, then the number of FECs may exceed the
configured maximum (vRtrLdpNgSessParamMaxFec) resulting in the
generation of vRtrLdpNgSessMaxFecLimitReached notification.
[RECOVERY] Appropriate Configuration changes in local or peer LSR will
be required.
vRtrLdpNgSessMaxFecLimitReached
.1.3.6.1.4.1.6527.3.1.3.91.0.8
[CAUSE] A vRtrLdpNgSessMaxFecLimitReached notification is generated
when the number of FECs accepted from the peer has reached the value
specified by vRtrLdpNgSessParamMaxFec.
If the current number of FECs go below the limit but higher than the
configured threshold and again start to increase and hit the limit a
second time, we will raise a trap if 2 or more minutes have elapsed
since the first vRtrLdpNgSessMaxFecLimitReached trap was sent.
If any parameter in FEC limit configuration changes and the current
number of FECs are equal to or higher than the limit specified by
vRtrLdpPeerMaxFec, then we would always raise the
vRtrLdpNgSessMaxFecLimitReached trap.
[EFFECT] When the number of FECs exceed the configured maximum
(vRtrLdpNgSessParamMaxFec) it results in any of the following:
(1) If vRtrLdpNgSessParamMaxFecLogOnly is set to 'false' and LSR
Overload Capability is supported, then Overload procedure will take
place.
(2) If vRtrLdpNgSessParamMaxFecLogOnly is set to 'false' and LSR
Overload Capability is not supported, Label Mapping Message will be
returned with Label Release Message.
(3) If vRtrLdpNgSessParamMaxFecLogOnly is set to 'true', no action
will be taken.
[RECOVERY] Appropriate Configuration changes in local or peer LSR will
be required.
vRtrLdpNgResourceExhaustion
.1.3.6.1.4.1.6527.3.1.3.91.0.9
[CAUSE] The vRtrLdpNgResourceExhaustion notification is generated when
CPM or data path resource required for FEC resolution is exhausted.The
new notification will not be generated if multiple internal change
events occur during a 10 minute interval.
[EFFECT] The system may not be able to accept new request from peers.
[RECOVERY] Appropriate configuration changes in LDP may be required.