|
RSVP neighbor
|
Number of neighbors about which
the router has learned. Each neighbor has one line of output.
|
All levels
|
|
via
|
Name of the interface where the
neighbor has been detected. In the case of generalized MPLS (GMPLS)
LSPs, the name of the peer where the neighbor has been detected.
|
detail
|
|
Address
|
Address of a learned neighbor.
|
All levels
|
|
Idle
|
Length of time the neighbor has
been idle, in seconds.
|
All levels
|
|
Up/Dn
|
Number of neighbor up or down transitions
detected by RSVP hello packets. If the up count is 1 greater than
the down count, the neighbor is currently up. Otherwise, the neighbor
is down. Neighbors that do not support RSVP hello packets, such as
routers running JUNOS software Release 3.2 or earlier, are not
reported as up or down.
|
All levels
|
|
Up cnt and Down cnt
|
Number of neighbor up or down transitions
detected by RSVP hello packets. If the up count is 1 greater than
the down count, the neighbor is currently up. Otherwise, the neighbor
is down. Neighbors that do not support RSVP hello packets, such as
routers running JUNOS software Release 3.2 or earlier, are not
reported as up or down.
|
detail
|
|
status
|
State of the RSVP neighbor:
-
Up—Router can detect RSVP Hello messages
from the neighbor.
-
Down—Router has received one of the following
indications:
- Communication failure from the neighbor.
- Communication from IGP that the neighbor is unavailable.
- Change in the sequence numbers in the RSVP Hello messages
sent by the neighbor.
-
Restarting—RSVP neighbor is unavailable
and might be restarting. The neighbor remains in this state until
it has restarted or is declared dead. This state is possible only
when graceful restart is enabled.
-
Restarted—RSVP neighbor has restarted and
is undergoing state recovery (graceful restart) procedures.
-
Dead—Router has lost all communication
with the RSVP neighbor. Any RSVP sessions with that neighbor are torn
down.
|
detail
|
|
LastChange
|
Time elapsed since the neighbor
state changed either from up to down or from down to up. The format
is hh:mm:ss.
|
All levels
|
|
Last changed time
|
Time elapsed since the neighbor
state changed either from up to down or from down to up.
|
detail
|
|
HelloInt
|
Frequency at which RSVP hellos
are sent on this interface (in seconds).
|
All levels
|
|
HelloTx/Rx
|
Number of hello packets sent to
and received from the neighbor.
|
All levels
|
|
Hello
|
Number of RSVP hello packets that
have been sent to and received from the neighbor.
|
detail
|
|
Message received
|
Number of Path and Resv messages
that this router has received from the neighbor.
|
detail
|
|
Remote Instance
|
Identification provided by the
remote router during Hello message exchange.
|
detail
|
|
Local Instance
|
Identification sent to the remote
router during Hello message exchange.
|
detail
|
|
Refresh reduction
|
Measure of processing overhead
requests of refresh messages. Refresh reduction extensions improve
router performance by reducing the process overhead, thus increasing
the number of LSPs a router can support. Refresh reduction can have the following values:
-
operational—All four RSVP refresh reduction
extensions—message ack, bundling, summary refresh, and staged
refresh timer—are functional between the two neighboring
routers. For a detailed explanation of these extensions, see RFC 2961.
-
incomplete—Some RSVP refresh reduction
extensions are functional between the two neighboring routers.
-
no operational—Either the refresh reduction
feature has been turned off, or the remote router cannot support the
refresh reduction extensions.
|
detail
|
|
Remote end
|
Neighboring router's status in
regard to refresh reduction:
-
enabled—Remote router has requested refresh
reduction during RSVP message exchanges.
-
disabled—Remote router does not require
refresh reduction.
|
detail
|
|
Ack-extension
|
An RSVP refresh reduction extension:
-
enabled—Both local and remote routers support
the ack-extension (RFC 2961).
-
disabled—Remote router does not support
the ack-extension.
|
detail
|
|
Link protection
|
Status of the MPLS fast reroute
mechanism that protects traffic from link failure:
-
enabled—Link protection feature has been
turned on, protecting the neighbor with a bypass LSP.
-
disabled—No link protection feature has
been enabled for this neighbor.
|
detail
|
|
LSP name
|
Name of the bypass LSP.
|
detail
|
|
Bypass LSP
|
Status of the bypass LSP. It can
have the following values:
-
does not exist—Bypass LSP is not available.
-
connecting—Router is in the process of
establishing a bypass LSP, and the LSP is not available for link protection
at the moment.
-
operational—Bypass LSP is up and running.
-
down—Bypass LSP has gone down, with the
most probable cause a node or a link failure on the bypass path.
|
detail
|
|
Backup routes
|
Number of user LSPs (or routes)
that are being protected by a bypass LSP (before link failure).
|
detail
|
|
Backup LSPs
|
Number of LSPs that have been temporarily
established to maintain traffic by refreshing the downstream LSPs
during link failure (not a one-to-one correspondence).
|
detail
|
|
Bypass explicit route
|
Explicit route object's (ERO) path
that is taken by the bypass LSP.
|
detail
|
|
Restart time
|
Length of time a neighbor waits
to receive a Hello from the restarting node before declaring the node
dead and deleting the states (in milliseconds).
|
detail
|
|
Recovery time
|
Length of time during which the
restarting node attempts to recover its lost states with help from
its neighbors (in milliseconds). Recovery time is advertised by the
restarting node to its neighbors, and applies to nodal faults. The
restarting node considers its graceful restart complete after this
time has elapsed.
|
detail
|