Table Of Contents
show ip pim neighbor
show ip protocols
show ip rpf events
show ip rsvp hello
show ip rsvp hello instance detail
show ip rsvp hello instance summary
show ip rsvp hello statistics
show ip rsvp high-availability counters
show ip rsvp interface detail
show ip rsvp request
show ip rsvp reservation
show ip rsvp sender
show isis nsf
show issu
show issu clients
show issu comp-matrix
show issu entities
show issu message types
show issu negotiated
show issu outage
show issu patch
show issu rollback timer
show issu sessions
show issu state
show mdr download image
show mpls ip binding
show mpls ip iprm counters
show mpls ip iprm ldm
show mpls l2transport checkpoint
show mpls ldp bindings
show mpls ldp checkpoint
show mpls ldp graceful-restart
show mpls ldp neighbor
show mpls traffic tunnel backup
show mpls traffic-eng tunnels
show mpls traffic-eng tunnels summary
show policy-map control-plane
show ppp subscriber statistics
show ip pim neighbor
To display information about Protocol Independent Multicast (PIM) neighbors discovered by PIMv1 router query messages or PIMv2 hello messages, use the show ip pim neighbor command in user EXEC or privileged EXEC mode.
show ip pim [vrf vrf-name] neighbor [interface-type interface-number]
Syntax Description
vrf vrf-name
|
(Optional) Displays information about PIM neighbors associated with the Multicast Virtual Private Network (MVPN) routing and forwarding (MVRF) instance specified for the vrf-name argument.
|
interface-type
|
(Optional) Interface type.
|
interface-number
|
(Optional) Interface number.
|
Command Default
Information about all PIM neighbors is displayed.
Command Modes
User EXEC (>)
Privileged EXEC (#)
Command History
Release
|
Modification
|
10.0
|
This command was introduced.
|
12.0(22)S
|
This command was modified. The command output was updated to display the PIM protocol version.
|
12.0(23)S
|
This command was modified. The vrf keyword and vrf-name argument were added.
|
12.2(13)T
|
This command was modified. The vrf keyword and vrf-name argument were added.
|
12.2(14)S
|
This command was integrated into Cisco IOS Release 12.2(14)S.
|
12.2(18)SXE
|
Support for this command was introduced on the Supervisor Engine 720.
|
12.0(30)S
|
This command was modified. The "P" flag was added.
|
12.2(28)SB
|
This command was integrated into Cisco IOS Release 12.2(28)SB.
|
12.2(33)SRA
|
This command was modified. The "P" flag was added.
|
12.2(31)SB2
|
This command was modified. The "P" flag was added.
|
12.2(33)SXH
|
This command was modified. The "P" flag was added.
|
12.4(20)T
|
This command was modified. The "P" flag was added.
|
12.2(33)SXI
|
This command was modified. The "G" flag was added.
|
12.2(33)SRE
|
This command was modified. The "G" flag was added.
|
Usage Guidelines
Use this command to display PIM neighbors discovered by PIMv1 router query messages or PIMv2 hello messages.
Use the optional interface-type and interface-number argument to restrict the output to only display information about the PIM neighbor reachable on the specified interface.
Examples
The following is sample output from the show ip pim neighbor command:
Router# show ip pim neighbor
Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,
S - State Refresh Capable
Neighbor Interface Uptime/Expires Ver DR
10.0.0.1 GigabitEthernet10/2 00:01:29/00:01:15 v2 1 / S
10.0.0.3 GigabitEthernet10/3 00:01:15/00:01:28 v2 1 / DR S P
Table 77 describes the significant fields shown in the display.
Table 77 show ip pim neighbor Field Descriptions
Field
|
Description
|
Neighbor Address
|
IP address of the PIM neighbor.
|
Interface
|
Interface type and number on which the neighbor is reachable.
|
Uptime
|
The total uptime of the neighbor (in hours:minutes:seconds).
|
Expires
|
The time before a neighbor is timed out and until the next PIM hello is received (in hours:minutes:seconds).
|
Ver
|
The version of PIM running on the neighbor's interface.
|
DR Prio
|
The priority of the PIM interface for DR election. The possible values that can be displayed under this column are as follows: a value from 0 to 4294967294 or the "N" flag. The default DR priority is set to 1.
Note  The DR priority can be modified using the ip pim dr-priority in interface configuration mode.
When a DR is a candidate for election, the following conditions apply:
•The router with the highest priority value configured on an interface will be elected as the DR. If this priority value is the same on multiple routers, then the router with the highest IP address configured on an interface will be elected as the DR.
•If a router does not advertise a priority value in its hello messages, the router is regarded as having the highest priority and will be elected as the DR. If there are multiple routers with this priority status, then the router with the highest IP address configured on an interface will be elected as the DR.
|
| |
Note For interoperability, if a PIM neighbor is running a legacy Cisco IOS release (a legacy release prior to Cisco IOS Release 12.1(2)T, which does not support the DR priority feature), the "DR Prio" column displays the "N" flag. If the neighbor is the only router displaying the "N" flag for a PIM interface, it becomes the DR regardless of which router actually has the highest IP address. If there are several PIM neighbors with the "N" flag listed under this column, the tie breaker is the highest IP address among them.
|
Mode
|
Information about the DR and other PIM capabilities:
•DR—Indicates that the PIM neighbor is acting as the DR.
•B—Indicates that the PIM neighbor is bidirectional PIM (bidir-PIM) capable. In a bidir-PIM network, this capability is necessary for the routers to successfully perform the designated forwarder election process. If a router detects through PIM hello messages that one of its PIM neighbors is not bidir-PIM capable, the designated forwarder election process is aborted and forwarding of bidir-PIM traffic to and from that interface would stop.
•P—Indicates that the neighbor has announced through PIM hello messages its capability to handle RPF Vectors in PIM join messages. All Cisco IOS versions that support the PIM RPF Vector feature announce this PIM hello option. An RPF Vector is only included in PIM messages when all PIM neighbors on an RPF interface support it.
•S—Indicates that the PIM neighbor supports PIM-DM state refresh capabilities (applies only to PIM neighbors running in dense mode). This flag was introduced in support of the PIM Dense Mode State Refresh feature. PIM-DM state refresh capabilities protect pruned state in PIM dense mode from timing out by periodically forwarding a control message down the source-based distribution tree. The control message refreshes the prune state on the outgoing interfaces of each router in the distribution tree. By default, all PIM routers that are operating in dense mode (and are running a Cisco IOS software release that supports the PIM Dense Mode State Refresh feature) automatically process and forward state refresh control messages.
•G—Indicates that the PIM neighbor supports Generation ID (GenID) capabilities, which enable fast PIM multicast route (mroute) reconvergence times after a switchover.
|
Related Commands
Command
|
Description
|
ip pim state-refresh disable
|
Disables the processing and forwarding of PIM dense mode state refresh control messages on a PIM router.
|
ip pim state-refresh origination-interval
|
Configures the origination of and the interval for the PIM dense mode state refresh control messages on a PIM router.
|
show ip pim interface
|
Displays information about interfaces configured for PIM.
|
show ip protocols
To display the parameters and current state of the active routing protocol process, use the show ip protocols command in privileged EXEC mode.
show ip protocols
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC (#)
Command History
Release
|
Modification
|
10.0
|
This command was introduced.
|
12.2(15)T
|
Support for the route-hold timer was integrated into the output.
|
12.2(28)SB
|
This command was integrated into Cisco IOS 12.2(28)SB.
|
12.2(33)SRA
|
This command was integrated into Cisco IOS Release 12.2(33)SRA.
|
12.2SX
|
This command is supported in the Cisco IOS Release 12.2SX train. Support in a specific 12.2SX release of this train depends on your feature set, platform, and platform hardware.
|
Usage Guidelines
The information displayed by the show ip protocols command is useful in debugging routing operations. Information in the Routing Information Sources field of the show ip protocols output can help you identify a router suspected of delivering bad routing information.
Examples
The following is sample output from the show ip protocols command that shows EIGRP process 77:
Router# show ip protocols
*** IP Routing is NSF aware ***
Routing Protocol is "eigrp 3"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Default networks flagged in outgoing updates
Default networks accepted from incoming updates
EIGRP-IPv4 VR(test) Address-Family Protocol for AS(3)
Metric weight K1=1, K2=0, K3=1, K4=0, K5=0
NSF-aware route hold timer is 240
Distance: internal 90 external 170
Maximum metric variance 1
Automatic Summarization: disabled
Routing Information Sources:
Gateway Distance Last Update
Distance: internal 90 external 170
Table 78 describes the significant fields shown in the display.
Table 78 show ip protocols Field Descriptions
Field
|
Description
|
Routing Protocol is...
|
Name and autonomous system number of the currently running routing protocol.
|
Outgoing update filter list for all interfaces...
|
Indicates whether a filter for outgoing routing updates has been specified with the distribute-list out command.
|
Incoming update filter list for all interfaces...
|
Indicates whether a filter for incoming routing updates has been specified with the distribute-list in command.
|
Redistributing:
|
Indicates whether route redistribution has been enabled with the redistribute command.
|
EIGRP-IPv4 Protocol for AS(10)
|
EIGRP instance and AS number.
|
Metric weight
|
EIGRP metric calculations.
|
NSF-aware route hold timer...
|
Route-hold timer value for an NSF-aware router.
|
Router-ID: 1.1.1.1
|
Router ID.
|
Topology
|
Number of entries in the EIGRP topology table.
|
Active Timer
|
EIGRP routing active time limit.
|
Distance
|
Internal and external administrative distance.
|
Maximum path
|
Maximum number of parallel routes that the EIGRP can support.
|
Maximum hopcount
|
Maximum hop count (in decimal).
|
Maximum metric variance
|
Metric variance used to find feasible paths for a route.
|
Automatic network summarization...
|
Indicates whether route summarization has been enabled with the auto-summary command.
|
Routing for Networks:
|
Networks for which the routing process is currently injecting routes.
|
Routing Information Sources:
|
Lists all the routing sources that the Cisco IOS software is using to build its routing table. The following is displayed for each source:
•IP address
•Administrative distance
•Time the last update was received from this source
|
Distance
|
Internal and external distances of the router. Internal distance is the degree of preference given to EIGRP internal routes. External distance is the degree of preference given to EIGRP external routes.
|
IS-IS Example
The following is sample output from the show ip protocols command that shows an Intermediate System-to-Intermediate System (IS-IS) process:
Router# show ip protocols
Routing Protocol is "isis"
Sending updates every 0 seconds
Invalid after 0 seconds, hold down 0, flushed after 0
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Routing Information Sources:
Distance: (default is 115)
Table 79 describes the significant fields shown in the display.
Table 79 show ip protocols Field Descriptions for an IS-IS Process
Field
|
Description
|
Routing Protocol is "isis"
|
Specifies the routing protocol used.
|
Sending updates every 0 seconds
|
Specifies the time between sending updates.
|
Invalid after 0 seconds
|
Specifies the value of the invalid parameter.
|
hold down 0
|
Specifies the current value of the hold-down parameter.
|
flushed after 0
|
Specifies the time (in seconds) after which the individual routing information will be thrown out (flushed).
|
Outgoing update ...
|
Specifies whether the outgoing filtering list has been set.
|
Incoming update ...
|
Specifies whether the incoming filtering list has been set.
|
Default networks
|
Specifies how these networks will be handled in both incoming and outgoing updates.
|
Redistributing
|
Lists the protocol that is being redistributed.
|
Routing
|
Specifies the networks for which the routing process is currently injecting routes.
|
Routing Information Sources
|
Lists all the routing sources the Cisco IOS software is using to build its routing table. For each source, you will see the following displayed:
•IP address
•Administrative distance
•Time the last update was received from this source
|
RIP Example
The following is sample output from the show ip protocols command that shows Routing Information Protocol (RIP) processes:
Router# show ip protocols
Routing Protocol is "rip"
Sending updates every 30 seconds, next due in 2 seconds
Invalid after 180 seconds, hold down 180, flushed after 240
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Default version control: send version 2, receive version 2
Interface Send Recv Key-chain
Routing Information Sources:
Gateway Distance Last Update
Distance: (default is 120)
Table 80 describes the significant fields shown in the display.
Table 80 show ip protocols Field Descriptions for a RIP Process
Field
|
Description
|
Routing Protocol is "rip"
|
Specifies the routing protocol used.
|
Sending updates every 30 seconds
|
Specifies the time between sending updates.
|
next due in 2 seconds
|
Precisely when the next update is due to be sent.
|
Invalid after 180 seconds
|
Specifies the value of the invalid parameter.
|
hold down for 180
|
Specifies the current value of the hold-down parameter.
|
flushed after 240
|
Specifies the time (in seconds) after which the individual routing information will be thrown (flushed) out.
|
Outgoing update ...
|
Specifies whether the outgoing filtering list has been set.
|
Incoming update ...
|
Specifies whether the incoming filtering list has been set.
|
Default version control:
|
Specifies the version of RIP packets that are sent and received.
|
Redistributing
|
Lists the protocol that is being redistributed.
|
Routing
|
Specifies the networks for which the routing process is currently injecting routes.
|
Routing Information Sources
|
Lists all the routing sources the Cisco IOS software is using to build its routing table. For each source, you will see the following displayed:
•IP address
•Administrative distance
•Time the last update was received from this source
|
EIGRP NSF Awareness Verification Example
The following is sample output from the show ip protocols command. The output shows that the router is running EIGRP, is NSF-aware, and that the route-hold timer is set 240 seconds, which is the default value for the route-hold timer.
Router# show ip protocols
Routing Protocol is "eigrp 101"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Default networks flagged in outgoing updates
Default networks accepted from incoming updates
EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0
EIGRP maximum hopcount 100
EIGRP maximum metric variance 1
Redistributing: eigrp 101
EIGRP NSF-aware route hold timer is 240s
Automatic network summarization is in effect
Routing Information Sources:
Gateway Distance Last Update
Distance: internal 90 external 170
Table 81 describes the significant fields shown in the display.
Table 81 show ip protocols Field Descriptions for an EIGRP NSF-Aware Process
Field
|
Description
|
Routing Protocol is "eigrp 101"
|
Specifies the routing protocol used.
|
Outgoing update ...
|
Specifies whether the outgoing filtering list has been set.
|
Incoming update ...
|
Specifies whether the incoming filtering list has been set.
|
Default networks...
|
Specifies how these networks will be handled in both incoming and outgoing updates.
|
EIGRP...
|
Specifies the value of the K0-K5 metrics, and the maximum hop count.
|
Redistributing
|
Lists the protocol that is being redistributed.
|
EIGRP NSF-Aware...
|
Displays the route-hold timer value.
|
Automatic network summarization...
|
Specifies that automatic summarization is enabled.
|
Routing
|
Specifies the networks for which the routing process is currently injecting routes.
|
Routing Information Sources
|
Lists all the routing sources the Cisco IOS software is using to build its routing table. For each source, you will see the following displayed:
•IP address
•Administrative distance
•Time the last update was received from this source
|
show ip rpf events
To display the last 15 triggered multicast Reverse Path Forwarding (RPF) check events, use the show ip rpf events command in user EXEC or privileged EXEC mode.
show ip rpf [vrf vrf-name] events
Syntax Description
vrf
|
(Optional) Supports the multicast VPN routing and forwarding (VRF) instance.
|
vrf-name
|
(Optional) Name assigned to the VRF.
|
Command Modes
User EXEC
Privileged EXEC
Command History
Release
|
Modification
|
12.0(22)S
|
This command was introduced.
|
12.0(23)S
|
The vrf keyword and vrf-name argument were added.
|
12.2(14)S
|
The vrf keyword and vrf-name argument were added.
|
12.2(15)T
|
This command was integrated into Cisco IOS Release 12.2(15)T.
|
12.2(33)SRA
|
This command was integrated into Cisco IOS Release 12.2(33)SRA.
|
12.2SX
|
This command is supported in the Cisco IOS Release 12.2SX train. Support in a specific 12.2SX release of this train depends on your feature set, platform, and platform hardware.
|
Usage Guidelines
Use this command to determine the most recent triggered multicast RPF check events.
Examples
The following is sample output from the show ip rpf events command:
Router# show ip rpf events
Last 15 triggered multicast RPF check events
RPF backoff delay:500 msec
DATE/TIME BACKOFF PROTOCOL EVENT RPF CHANGES
Mar 7 03:24:10.505 500 msec Static Route UP 0
Mar 7 03:23:11.804 1000 sec BGP Route UP 3
Mar 7 03:23:10.796 500 msec ISIS Route UP 0
Mar 7 03:20:10.420 500 msec ISIS Route Down 3
Mar 7 03:19:51.072 500 msec Static Route Down 0
Mar 7 02:46:32.464 500 msec Connected Route UP 3
Mar 7 02:46:24.052 500 msec Static Route Down 0
Mar 7 02:46:10.200 1000 sec Connected Route UP 3
Mar 7 02:46:09.060 500 msec OSPF Route UP 3
Mar 7 02:46:07.416 500 msec OSPF Route Down 0
Mar 7 02:45:50.423 500 msec EIGRP Route UP 3
Mar 7 02:45:09.679 500 msec EIGRP Route Down 0
Mar 7 02:45:06.322 500 msec EIGRP Route Down 2
Mar 7 02:33:09.424 500 msec Connected Route UP 0
Mar 7 02:32:28.307 500 msec BGP Route UP 3
The following is sample output from the show ip rpf events command when the ip multicast rpf backoff command is used with the disable keyword, disabling the triggered RPF check function:
Router# show ip rpf events
Last 15 triggered multicast RPF check events
Note:Triggered RPF disabled!
RPF backoff delay:50 msec
DATE/TIME BACKOFF PROTOCOL EVENT RPF CHANGES
Sep 4 06:25:31.707 500 msec Connected Route UP 0
Sep 4 06:25:30.099 500 msec Connected Route UP 0
Table 82 describes the significant fields shown in the display.
Table 82 show ip rpf events Field Descriptions
Field
|
Description
|
RPF backoff delay
|
The configured amount of time (in milliseconds) allowed for the initial backoff delay.
|
RPF maximum delay
|
The maximum configured amount of time (in seconds) allowed for a backoff delay.
|
DATE/TIME
|
The date and time (in hours:minutes:seconds) an RPF event occurred.
|
BACKOFF
|
The actual backoff delay (in milliseconds) after which the RPF check was done.
|
PROTOCOL
|
The protocol that triggered the RPF check.
|
EVENT
|
This RPF check was caused by a route that went up or down, or was modified.
|
RPF CHANGES
|
The number of multicast routes that were affected by the RPF change.
|
show ip rsvp hello
To display hello status and statistics for Fast Reroute, reroute (hello state timer), and graceful restart, use the show ip rsvp hello command in user EXEC or privileged EXEC mode.
show ip rsvp hello
Syntax Description
This command has no arguments or keywords.
Command Modes
User EXEC (>)
Privileged EXEC (#)
Command History
Release
|
Modification
|
12.0(22)S
|
This command was introduced.
|
12.0(29)S
|
The command output was modified to include graceful restart, reroute (hello state timer), and Fast Reroute information.
|
12.2(18)SXD1
|
This command was integrated into Cisco IOS Release 12.2(18)SXD1.
|
12.2(33)SRA
|
The command output was modified to show whether graceful restart is configured and full mode was added.
|
12.2(31)SB2
|
This command was integrated into Cisco IOS Release 12.2(31)SB2.
|
12.2(33)SRC
|
The command output was modified to include Bidirectional Forwarding Detection (BFD) protocol information.
|
12.4(20)T
|
This command was integrated into Cisco IOS Release 12.4(20)T.
|
Examples
The following is sample output from the show ip rsvp hello command:
Router# show ip rsvp hello
RSVP Hello for Fast-Reroute/Reroute: Enabled
BFD for Fast-Reroute/Reroute: Enabled
RSVP Hello for Graceful Restart: Disabled
Table 83 describes the significant fields shown in the display. The fields describe the processes for which hello is enabled or disabled.
Table 83 show ip rsvp hello Field Descriptions
Field
|
Description
|
RSVP Hello for Fast-Reroute/Reroute
|
Status of Fast-Reroute/Reroute:
•Disabled—Fast reroute and reroute (hello for state timer) are not activated (disabled).
•Enabled—Fast reroute and reroute (hello for state timer) are activated (enabled).
|
Statistics
|
Status of hello statistics:
•Disabled—Hello statistics are not configured.
•Enabled—Statistics are configured. Hello packets are time-stamped when they arrive in the hello input queue for the purpose of recording the time required until they are processed.
•Shutdown—Hello statistics are configured but not operational. The input queue is too long (that is, more than 10,000 packets are queued).
|
BFD for Fast-Reroute/Reroute
|
Status of BFD for Fast-Reroute/Reroute:
•Disabled—BFD is not configured.
•Enabled—BFD is configured.
|
Graceful Restart
|
Restart capability:
•Disabled—Restart capability is not activated.
•Enabled—Restart capability is activated for a router (full mode) or its neighbor (help-neighbor).
|
Related Commands
Command
|
Description
|
ip rsvp signalling hello (configuration)
|
Enables hello globally on the router.
|
ip rsvp signalling hello statistics
|
Enables hello statistics on the router.
|
show ip rsvp hello statistics
|
Displays how long hello packets have been in the hello input queue.
|
show ip rsvp hello instance detail
To display detailed information about a hello instance, use the show ip rsvp hello instance detail command in user EXEC or privileged EXEC mode.
show ip rsvp hello instance detail [filter destination ip-address]
Syntax Description
filter destination ip-address
|
(Optional) IP address of the neighbor node.
|
Command Modes
User EXEC
Privileged EXEC
Command History
Release
|
Modification
|
12.0(22)S
|
This command was introduced.
|
12.0(29)S
|
The command output was modified to include graceful restart, hello state timer (reroute), and fast reroute information.
|
12.2(18)SXD1
|
This command was integrated into Cisco IOS Release 12.2(18)SXD1.
|
12.2(33)SRA
|
This command was integrated into Cisco IOS Release 12.2(33)SRA.
|
12.2(31)SB2
|
This command was integrated into Cisco IOS Release 12.2(31)SB2.
|
12.4(20)T
|
This command was integrated into Cisco IOS Release 12.4(20)T.
|
Usage Guidelines
Use the show ip rsvp hello instance detail command to display information about the processes (clients) currently configured.
Examples
The following is sample output from the show ip rsvp hello instance detail command:
Router# show ip rsvp hello instance detail
Neighbor 10.0.0.3 Source 10.0.0.2
Type: Active (sending requests)
State: Up (for 2d19h2d19h)
Missed acks: 4, IP DSCP: 0x30
Statistics: (from 40722 samples)
Waverage: 6000 (Weight = 0.8)
Last sent Src_instance: 0xE617C847
Last recv nbr's Src_instance: 0xFEC28E95
Communication with neighbor lost:
Neighbor disabled Hello: 0
Neighbor 10.0.0.8 Source 10.0.0.7
Type: Passive (responding to requests)
Last sent Src_instance: 0xF7A80A52
Last recv nbr's Src_instance: 0xD2F1B7F7
Table 84 describes the significant fields shown in the display.
Table 84 show ip rsvp hello instance detail Field Descriptions
Field
|
Description
|
Neighbor
|
IP address of the adjacent node.
|
Source
|
IP address of the node that is sending the hello message.
|
Type
|
Values are Active (node is sending a request) and Passive (node is responding to a request).
|
I/F
|
Interface from which hellos are sent for this instance. Any means that the hellos can be sent out any interface.
|
State
|
Status of communication. Values are as follows:
•Up—Node is communicating with its neighbor.
•Lost—Communication has been lost.
•Init—Communication is being established.
|
Clients
|
Clients that created this hello instance; they include graceful restart, ReRoute (hello state timer), and Fast Reroute.
|
LSPs protecting
|
Number of LSPs that are being protected by this hello instance.
|
Missed acks
|
Number of times that communication was lost due to missed acknowledgments (ACKs).
|
IP DSCP
|
IP differentiated services code point (DSCP) value used in the hello IP header.
|
Refresh Interval (msec)
|
The frequency (in milliseconds) with which a node generates a hello message containing a Hello Request object for each neighbor whose status is being tracked.
|
Configured
|
Configured refresh interval.
|
Statistics
|
Refresh interval statistics from a specified number of samples (packets).
|
Min
|
Minimum refresh interval.
|
Max
|
Maximum refresh interval.
|
Average
|
Average refresh interval.
|
Waverage
|
Weighted average refresh interval.
|
Current
|
Current refresh interval.
|
Last sent Src_instance
|
The last source instance sent to a neighbor.
|
Last recv nbr's Src_instance
|
The last source instance field value received from a neighbor.
(0 means none received.)
|
Counters
|
Incremental information relating to communication with a neighbor.
|
Num times
|
Total number of times that communication with a neighbor was lost.
|
Reasons
|
Subsequent fields designate why communication with a neighbor was lost.
|
Missed acks
|
Number of times that communication was lost due to missed ACKs.
|
Bad Src_Inst received
|
Number of times that communication was lost due to bad source instance fields.
|
Bad Dst_Inst received
|
Number of times that communication was lost due to bad destination instance fields.
|
I/F went down
|
Number of times that the interface became unoperational.
|
Neighbor disabled Hello
|
Number of times that a neighbor disabled hello messages.
|
Msgs Received
|
Number of messages that were received.
|
Sent
|
Number of messages that were sent.
|
Suppressed
|
Number of messages that were suppressed due to optimization.
|
Related Commands
Command
|
Description
|
ip rsvp signalling hello (configuration)
|
Enables hello globally on the router.
|
ip rsvp signalling hello statistics
|
Enables hello statistics on the router.
|
show ip rsvp hello
|
Displays hello status and statistics for Fast reroute, reroute (hello state timer), and graceful restart.
|
show ip rsvp hello instance summary
|
Displays summary information about a hello instance.
|
show ip rsvp hello instance summary
To display summary information about a hello instance, use the show ip rsvp hello instance summary command in user EXEC or privileged EXEC mode.
show ip rsvp hello instance summary
Syntax Description
This command has no arguments or keywords.
Command Modes
User EXEC
Privileged EXEC
Command History
Release
|
Modification
|
12.0(22)S
|
This command was introduced.
|
12.0(29)S
|
The command output was modified to include graceful restart, reroute (hello state timer), and fast reroute information.
|
12.2(18)SXD1
|
This command was integrated into Cisco IOS Release 12.2(18)SXD1.
|
12.2(33)SRA
|
This command was integrated into Cisco IOS Release 12.2(33)SRA.
|
12.2(31)SB2
|
This command was integrated into Cisco IOS Release 12.2(31)SB2.
|
12.4(20)T
|
This command was integrated into Cisco IOS Release 12.4(20)T.
|
Examples
The following is sample output from the show ip rsvp hello instance summary command:
Router# show ip rsvp hello instance summary
Client Neighbor I/F State LostCnt LSPs Interval
RR 10.0.0.3 Se2/0 Up 0 1 6000
GR 10.1.1.1 Any Up 13 1 10000
GR 10.1.1.5 Any Lost 0 1 10000
GR 10.2.2.1 Any Init 1 0 5000
Active = Actively tracking neighbor state on behalf of clients:
RR = ReRoute, FRR = Fast ReRoute, or GR = Graceful Restart
Passive = Responding to hello requests from neighbor
Table 85 describes the significant fields shown in the display.
Table 85 show ip rsvp hello instance summary Field Descriptions
Field
|
Description
|
Active Instances
|
Active nodes that are sending hello requests.
|
Client
|
Clients on behalf of which hellos are sent; they include GR (graceful restart), RR (reroute = hello state timer), and FRR (Fast Reroute).
|
Neighbor
|
IP address of the adjacent node. For graceful restart, this is the neighbor router's ID; for Fast Reroute and hello state timer (reroute), this is one of the neighbor's interface addresses.
|
I/F
|
Interface from which hellos are sent for this instance. Any means that the hellos can be sent out any interface.
|
State
|
Status of communication. Values are as follows:
•Up—Node is communicating with its neighbor.
•Lost—Communication has been lost.
•Init—Communication is being established.
|
LostCnt
|
Number of times that communication was lost with the neighbor.
|
LSPs
|
Number of label-switched paths (LSPs) protected by this hello instance.
|
Interval
|
Hello refresh interval in milliseconds.
|
Passive Instances
|
Passive nodes that are responding to hello requests.
|
Neighbor
|
IP address of adjacent node. For graceful restart, this is the neighbor router's ID; for Fast Reroute and hello state timer (reroute), this is one of the neighbor's interface addresses.
|
I/F
|
Interface from which hellos are sent for this instance. Any means that the hellos can be sent out any interface.
|
Related Commands
Command
|
Description
|
ip rsvp signalling hello (configuration)
|
Enables hello globally on the router.
|
ip rsvp signalling hello statistics
|
Enables hello statistics on the router.
|
show ip rsvp hello
|
Displays hello status and statistics for fast reroute, reroute (hello state timer), and graceful restart.
|
show ip rsvp hello instance detail
|
Displays detailed information about a hello instance.
|
show ip rsvp hello statistics
To display how long hello packets have been in the Hello input queue, use the show ip rsvp hello statistics command in privileged EXEC mode.
show ip rsvp hello statistics
Syntax Description
This command has no arguments or keywords.
Command Default
Information about how long hello packets have been in the Hello input queue is not displayed.
Command Modes
Privileged EXEC
Command History
Release
|
Modification
|
12.0(22)S
|
This command was introduced.
|
12.2(18)SXD1
|
This command was integrated into Cisco IOS Release 12.2(18)SXD1.
|
12.2(33)SRA
|
This command was integrated into Cisco IOS Release 12.2(33)SRA.
|
12.2(31)SB2
|
This command was integrated into Cisco IOS Release 12.2(31)SB2.
|
12.4(20)T
|
This command was integrated into Cisco IOS Release 12.4(20)T
|
Usage Guidelines
You can use this command to determine if the Hello refresh interval is too small. If the interval is too small, communication may falsely be declared as lost.
Examples
The following is sample output from the show ip rsvp hello statistics command:
Router# show ip rsvp hello statistics
Weighted Average:0 (weight = 0.8)
Current length: 0 (max:500)
Number of samples taken: 2398525
Table 86 describes the significant fields shown in the display.
Table 86 show ip rsvp hello statistics Field Descriptions
Field
|
Description
|
Status
|
Indicator of whether Hello has been enabled globally on the router.
|
Current
|
Amount of time, in milliseconds, that the current hello packet has been in the Hello input queue.
|
Average
|
Average amount of time, in milliseconds, that hello packets are in the Hello input queue.
|
Max
|
Maximum amount of time, in milliseconds, that hello packets have been in the Hello input queue.
|
Current length
|
Current amount of time, in milliseconds, that hello packets have been in the Hello input queue.
|
Number of samples taken
|
Number of packets for which these statistics were compiled.
|
Related Commands
Command
|
Description
|
clear ip rsvp hello instance statistics
|
Clears Hello statistics for an instance.
|
clear ip rsvp hello statistics
|
Globally clears Hello statistics.
|
ip rsvp signalling hello refresh interval
|
Configures the Hello request interval.
|
ip rsvp signalling hello statistics
|
Enables Hello statistics on the router.
|
show ip rsvp high-availability counters
To display all Resource Reservation Protocol (RSVP) traffic engineering (TE) high availability (HA) counters that are being maintained by a Route Processor (RP), use the show ip rsvp high-availability counters command in user EXEC or privileged EXEC mode.
show ip rsvp high-availability counters
Syntax Description
This command has no arguments or keywords.
Command Modes
User EXEC
Privileged EXEC
Command History
Release
|
Modification
|
12.2(33)SRA
|
This command was introduced.
|
12.2(33)SRB
|
Support for In-Service Software Upgrade (ISSU) was added.
|
12.2(33)SXH
|
This command was integrated into Cisco IOS Release 12.2(33)SXH.
|
Usage Guidelines
Use the show ip rsvp high-availability counters command to display the HA counters, which include state, ISSU, checkpoint messages, resource failures, and errors.
The command output differs depending on whether the RP is active or standby. (See the "Examples" section for more information.)
Use the clear ip rsvp high-availability counters command to clear all counters.
Examples
The following is sample output from the show ip rsvp high-availability counters command on the active RP:
Router# show ip rsvp high-availability counters
Checkpoint Messages (Items) Sent
Checkpoint Messages Transformed:
Table 87 describes the significant fields shown in the display.
Table 87 show ip rsvp high-availability counters—Active RP Field Descriptions
Field
|
Description
|
State
|
The RP state:
•Active—Active RP.
|
Bulk sync
|
The number of requests made by the standby RP to the active RP to resend all write database entries:
•Initiated—The number of bulk sync operations initiated by the standby RP since reboot.
|
Send timer
|
The write database timer.
|
Checkpoint Messages (Items) Sent
|
The details of the bundle messages or items sent since booting.
|
Succeeded
|
The number of bundle messages or items sent from the active RP to the standby RP since booting. Values are the following:
•Acks accepted—The number of bundle messages or items sent from the active RP to the standby RP.
•Acks ignored—The number of bundle messages or items sent by the active RP, but rejected by the standby RP.
•Nacks—The number of bundle messages or items given to the checkpointing facility (CF) on the active RP for transmitting to the standby RP, but failed to transmit.
|
Failed
|
The number of bundle messages or items the active RP attempted to send the standby RP when the send timer updated, but received an error back from CF.
|
Buffer alloc
|
Storage space allocated.
|
Buffer freed
|
Storage space available.
|
ISSU
|
In-Service Software Upgrade (ISSU) counters.
|
Checkpoint Messages Transformed
|
The details of the bundle messages or items transformed (upgraded or downgraded for compatibility) since booting so that the active RP and the standby RP can interoperate.
|
On Send
|
The number of messages sent by the active RP that succeeded, failed, or were transformations.
|
On Recv
|
The number of messages received by the active RP that succeeded, failed, or were transformations.
|
Negotiation
|
The number of times that the active RP and the standby RP have negotiated their interoperability parameters.
|
Started
|
The number of negotiations started.
|
Finished
|
The number of negotiations finished.
|
Failed to Start
|
The number of negotiations that failed to start.
|
Messages
|
The number of negotiation messages sent and received. These messages can be succeeded or failed.
•Send succeeded—Number of messages sent successfully.
•Send failed—Number of messages sent unsuccessfully.
•Buffer allocated—Storage space allowed.
•Buffer freed—Storage space available.
•Buffer alloc failed—No storage space available.
|
Init
|
The number of times the RSVP ISSU client has successfully and unsuccefully (failed) initialized.
|
Session Registration
|
The number of session registrations, succeeded and failed, performed by the active RP whenever the standby RP reboots.
|
Session Unregistration
|
The number of session unregistrations, succeeded and failed, before the standby RP resets.
|
Errors
|
The details of errors or caveats.
|
The following is sample output from the show ip rsvp high-availability counters command on the standby RP:
Router# show ip rsvp high-availability counters
Checkpoint Messages (Items) Received
Checkpoint Messages Transformed:
Table 88 describes the significant fields shown in the display.
Table 88 show ip rsvp high-availability counters—Standby RP Field Descriptions
Field
|
Description
|
State
|
The RP state:
•Standby—Standby (backup) RP.
|
Checkpoint Messages (Items) Received
|
The details of the messages or items received by the standby RP. Values are the following:
•Valid—The number of valid messages or items received by the standby RP.
•Invalid—The number of invalid messages or items received by the standby RP.
•Buffer freed—Amount of storage space available.
|
ISSU
|
ISSU counters.
Note For descriptions of the ISSU fields, see Table 87.
|
Errors
|
The details of errors or caveats.
|
Related Commands
Command
|
Description
|
clear ip rsvp high-availability counters
|
Clears (sets to zero) the RSVP-TE HA counters that are being maintained by an RP.
|
show ip rsvp high-availability database
|
Displays the contents of the RSVP-TE HA read and write databases used in TE SSO.
|
show ip rsvp high-availability summary
|
Displays summary information for an RSVP-TE HA RP.
|
show ip rsvp interface detail
To display the interface configuration for hello, use the show ip rsvp interface detail command in user EXEC or privileged EXEC mode.
show ip rsvp interface detail [interface]
Syntax Description
interface
|
(Optional) Name of the interface for which you want to show the hello configuration.
|
Command Default
The interface configuration for hello is not displayed.
Command Modes
User EXEC (>)
Privileged EXEC (#)
Command History
Release
|
Modification
|
12.0(22)S
|
This command was introduced.
|
12.2(18)SXD1
|
This command was integrated into Cisco IOS Release 12.2(18)SXD1.
|
12.2(33)SRA
|
This command was integrated into Cisco IOS Release 12.2(33)SRA.
|
12.2(31)SB2
|
This command was integrated into Cisco IOS Release 12.2(31)SB2.
|
12.2(33)SRC
|
This command was integrated into Cisco IOS Release 12.2(33)SRC.
|
12.4(20)T
|
This command was integrated into Cisco IOS Release 12.4(20)T.
|
Examples
The following is sample output from the show ip rsvp interface detail command:
Router# show ip rsvp interface detail GigabitEthernet 9/47
Curr allocated: 0 bits/sec
Max. allowed (total): 0 bits/sec
Max. allowed (per flow): 0 bits/sec
Max. allowed for LSP tunnels using sub-pools (pool 1): 0 bits/sec
Set aside by policy (total): 0 bits/sec
DSCP value used in RSVP msgs: 0x3F
Number of refresh intervals to enforce blockade state: 4
Backup Path: Configured (or "Not Configured")
Refresh Interval: FRR: 200 , Reroute: 2000
Missed Acks: FRR: 4 , Reroute: 4
DSCP in HELLOs: FRR: 0x30 , Reroute: 0x30
Table 89 describes the significant fields shown in the display.
Table 89 show ip rsvp interface detail Field Descriptions
Field
|
Description
|
RSVP
|
Status of the Resource Reservation Protocol (RSVP) protocol (Enabled or Disabled).
|
Interface State
|
Status of the interface (Up or Down).
|
Curr allocated
|
Amount of bandwidth (in bits per second [bps]) currently allocated.
|
Max. allowed (total)
|
Total maximum amount of bandwidth (in bps) allowed.
|
Max. allowed (per flow)
|
Maximum amount of bandwidth (in bps) allowed per flow.
|
Max. allowed for LSP tunnels using sub-pools
|
Maximum amount of bandwidth permitted for label switched path (LSP) tunnels that obtain their bandwidth from subpools.
|
DSCP value used in RSVP msgs
|
The differentiated services code point (DSCP) value that is in RSVP messages.
|
BFD Extension State
|
State (Enabled or Disabled) of Bidirectional Forwarding Detection (BFD) extension.
|
RSVP Hello Extension State
|
State (Enabled or Disabled) of hello extension.
|
Missed Acks
|
Number of sequential acknowledgments that the node did not receive.
|
DSCP in HELLOs
|
The DSCP value that is in hello messages.
|
Related Commands
Command
|
Description
|
ip rsvp signalling hello (interface)
|
Enables hello on an interface where you need Fast Reroute protection.
|
ip rsvp signalling hello dscp
|
Sets the DSCP value that is in the IP header of the hello message sent out from an interface.
|
ip rsvp signalling hello refresh interval
|
Configures the hello request interval.
|
show ip rsvp request
To display Resource Reservation Protocol (RSVP)-related request information currently in the database, use the show ip rsvp request command in user EXEC or privileged EXEC mode.
Syntax for T, 12.2S, 12.2SB, 12.2(33)SRD, and Earlier Releases
show ip rsvp request [detail] [filter [destination ip-address | hostname] [dst-port port-number]
[source ip-address | hostname] [src-port port-number]] [vrf {* | vrf-name}]
Syntax for 12.2(33)SRE with Filtering Session Type all
show ip rsvp request [detail] [filter [session-type all]]
Syntax for 12.2(33)SRE with Filtering Session Type 1
show ip rsvp request [detail] [filter [session-type session-type-number]] [destination ip-address
| hostname] [dst-port port-number] [source ip-address | hostname] [src-port port-number]]
Syntax for 12.2(33)SRE with Filtering Session Type 7 or 13
show ip rsvp request [detail] [filter [session-type session-type-number]] [destination ip-address
| hostname] [lsp-id lsp-id] [sender ip-address | hostname] [tunnel-id tunnel-id]]
Syntax Description
detail
|
(Optional) Specifies additional receiver information.
|
filter
|
(Optional) Specifies a subset of the receivers to display.
|
session-type session-type-number
|
(Optional) Specifies the type of RSVP sessions to display. Valid values are:
•1 for IPv4 sessions
•7 for IPv4 point-to-point (P2P) traffic engineering (TE) label switched path (LSP) tunnel sessions
•13 for IPv4 point-to-multipoint (P2MP) TE LSP tunnel sessions.
|
all
|
(Optional) Specifies all types of RSVP sessions.
|
destination ip-address
|
(Optional) Specifies the destination IP address.
|
hostname
|
(Optional) Hostname of the destination.
|
dst-port port-number
|
(Optional) Specifies the destination port number. Valid destination port numbers can be in the range of 0 to 65535.
|
lsp-id lsp-id
|
(Optional) Specifies the label switched path ID. Valid numbers can be in the range of 0 to 65535.
|
sender ip-address
|
(Optional) Specifies the IP address of the tunnel head.
|
hostname
|
(Optional) Hostname of the tunnel head.
|
source ip-address
|
(Optional) Specifies the source IP address of the source.
|
hostname
|
(Optional) Hostname of the source.
|
src-port port-number
|
(Optional) Specifies the source port number. Valid source port numbers can be in the range of 0 to 65535.
|
tunnel-id tunnel-id
|
(Optional) Specifies the tunnel ID number. Valid numbers can be in the range of 0 to 65535.
|
vrf *
|
(Optional) Displays all the configured virtual routing and forwarding (VRF) instances.
|
vrf vrf-name
|
(Optional) Name of a specified VRF.
|
Command Modes
User EXEC (>)
Privileged EXEC (#)
Command History
Release
|
Modification
|
11.2
|
This command was introduced.
|
12.2
|
This command was integrated into Cisco IOS Release 12.2. The detail keyword was added to display additional request information.
|
12.0(22)S
|
This command was integrated into Cisco IOS Release 12.0(22)S. This command was enhanced to show Fast Reroute information when a link-state packet (LSP) is actively using a backup tunnel that terminates at this node (that is, when a node is the merge point.) The command is supported on the Cisco 10000 series Edge Services Router (ESR).
|
12.2(18)SXD1
|
This command was integrated into Cisco IOS Release 12.2(18)SXD1.
|
12.2(33)SRA
|
This command was integrated into Cisco IOS Release 12.2(33)SRA.
|
12.2(31)SB2
|
This command was integrated into Cisco IOS Release 12.2(31)SB2.
|
12.2(33)SRC
|
The command output was modified to display RSVP aggregation information.
|
12.4(20)T
|
This command was integrated into Cisco IOS Release 12.4(20)T.
|
15.0(1)M
|
This command was modified. The vrf and * keywords and the vrf-name argument were added.
|
12.2(33)SRE
|
This command was modified. The session-type keyword was added to display specific types of tunnels. The output was modified to display Multiprotocol (MPLS) TE P2MP information.
|
Usage Guidelines
Use the show ip rsvp request command to display the RSVP reservations currently being requested upstream for a specified interface or all interfaces. The received reservations may differ from requests because of aggregated or refused reservations. If desired, information for only a single tunnel or a subset of tunnels can be displayed.
Limiting the Display
When hundreds or thousands of tunnels exist and you are interested in only a few, you can display the output for only a single tunnel or a subset of tunnels. To request a limited display, enter the show ip rsvp request command with the appropriate keyword (called an output filter): destination, dst-port, source, and src-port. You can enter any or all of the output filters, and you can enter them whether or not you specify the detail keyword.
You can also limit the display to a particular VRF by using the show ip rsvp request vrf vrf-name command.
Examples
RSVP Aggregation Example 1
The following is sample output from the show ip rsvp request command when RSVP aggregation is configured:
Router# show ip rsvp request
To From Pro DPort Sport Next Hop I/F Fi Serv BPS
192.168.5.1 192.168.2.1 TCP 222 222 192.168.40.1 Se1/0 FF RATE 80K
192.168.50.1 192.168.40.1 0 46 0 10.10.10.4 Se1/0 FF LOAD 300K
Table 90 describes the significant fields shown in the display.
Table 90 show ip rsvp request Field Descriptions
Field
|
Description
|
To
|
IP address of the end-to-end (E2E) receiver or deaggregator.
|
From
|
IP address of the E2E sender or aggregator.
|
Pro
|
Protocol code.
•TCP indicates Transmission Control Protocol.
•Code 0 indicates an aggregate reservation.
|
DPort
|
Destination port number.
•DSCP for aggregate reservations.
|
Sport
|
Source port number.
•0 for aggregate reservations.
|
Next Hop
|
IP address of the next hop.
•Aggregator for E2E reservations mapped onto aggregates.
•Next hop RSVP node for aggregate or E2E reservations onto an interface.
|
I/F
|
Interface of the next hop.
|
Fi
|
Filter (Wildcard Filter, Shared Explicit, or Fixed Filter).
|
Serv
|
Service (value can be rate or load).
|
BPS
|
The rate, in bits per second, in the RSVP reservation request for a reservation.
Note In the example, the top one is the E2E reservation signaled at 80 bps and the corresponding aggregate request at 300 bps.
|
RSVP Aggregation Example 2
The following is sample output from the show ip rsvp request detail command when RSVP aggregation is configured:
Router# show ip rsvp request detail
RSVP Reservation. Destination is 192.168.5.1, Source is 192.168.2.1,
Protocol is TCP, Destination port is 222, Source port is 222
Prev Hop: 192.168.40.1 on Serial1/0
Reservation Style is Fixed-Filter, QoS Service is Guaranteed-Rate
Average Bitrate is 80K bits/sec, Maximum Burst is 5K bytes
Request ID handle: 0100040E.
Policy: Forwarding. Policy source(s): Default
Priorities - preempt: 0, defend: 0
PSB Handle List [1 elements]: [0x19000407]
RSB Handle List [1 elements]: [0x17000409]
3175 Aggregation: RSVP 3175 AggResv 192.168.40.1->192.168.50.1_ef(46)
RSVP Reservation. Destination is 192.168.50.1, Source is 192.168.40.1,
Protocol is 0 , Destination port is 46, Source port is 0
Prev Hop: 10.10.10.4 on Serial1/0
Reservation Style is Fixed-Filter, QoS Service is Controlled-Load
Average Bitrate is 300K bits/sec, Maximum Burst is 300K bytes
Request ID handle: 0100040B.
Policy: Forwarding. Policy source(s): Default
Priorities - preempt: 0, defend: 0
PSB Handle List [1 elements]: [0x9000408]
RSB Handle List [1 elements]: [0x100040A]
Table 91 describes the significant fields shown in the display.
Table 91 show ip rsvp request detail—RSVP Aggregation Field Descriptions
Field
|
Description
|
RSVP Reservation
|
Destination—Receiver's IP address of the E2E RESV message.
Source—Sender's IP address of the E2E RESV message.
|
Protocol
|
Protocol—IP protocol used; TCP—Transmission Control Protocol.
•0 for aggregate reservations.
|
Destination port
|
Receiver's port number.
•DSCP for aggregate reservations.
|
Source port
|
Sender's port number.
•0 for aggregate reservations.
|
Previous Hop
|
IP address of the previous hop on the specified interface.
Note This is the aggregator's IP address in the case of an E2E reservation mapped onto an aggregate as seen at the deaggregator.
|
Reservation Style
|
Multi-reservations sharing of bandwidth; values include Fixed-Filter, Shared-Explicit, and Wildcard-Filter.
|
QoS Service
|
Type of quality of service (QoS) configured; values include Guaranteed-Rate and Controlled-Load.
|
Average Bitrate
|
Average rate requested, in bits per second, for the data.
|
Maximum Burst
|
Largest amount of data allowed in kilobytes.
|
Request ID handle
|
Internal database ID assigned to the request by RSVP for bookkeeping purposes.
|
Policy
|
Policy status: Forwarding—RSVP RESV messages are being accepted and forwarded.
|
Policy source(s)
|
Type of local policy in effect; values include Default, Local, and MPLS/TE.
|
Priorities
|
RSVP preemption and hold priorities of the reservation; default is 0.
|
PSB Handle List
|
Path state block (PSB) internal database identifier assigned by RSVP for bookkeeping purposes.
|
RSB Handle List
|
Reservation state block (RSB) internal database identifier assigned by RSVP for bookkeeping purposes.
|
3175 Aggregation
|
RSVP aggregation as defined in RFC 3175, Aggregation of RSVP for IPv4 and IPv6 Reservations.
Note This E2E reservation is mapped onto an RSVP aggregate reservation with an aggregator (source) IP address of 192.168.40.1, a destination (deaggregator) IP address of 192.168.50.1, and a DSCP value of expedited forwarding (EF).
|
Merge Point Examples
The following is sample output from the show ip rsvp request detail command when the command is entered on the merge point before and after a failure.
Figure 1 illustrates the network topology for the RSVP configuration example.
Figure 1 Network Topology for the RSVP Configuration Example
Example 1: The command is entered on the merge point before a failure.
Router# show ip rsvp request detail
RSVP Reservation. Tun Dest: 10.2.2.1 Tun Sender: 10.2.2.0,
Next Hop is 10.1.1.5 on POS0/1
Reservation Style is Shared-Explicit, QoS Service is Controlled-Load
Average Bitrate is 0G bits/sec, Maximum Burst is 1K bytes
Example 2: The command is entered on the merge point after a failure.
Router# show ip rsvp request detail
RSVP Reservation. Tun Dest: 10.2.2.1 Tun Sender: 10.2.2.0,
Next Hop is 10.1.1.5 on POS0/1
Reservation Style is Shared-Explicit, QoS Service is Controlled-Load
Average Bitrate is 0G bits/sec, Maximum Burst is 1K bytes
FRR is in progress (we are Merge Point)
RSVP Reservation. Tun Dest: 10.2.2.1 Tun Sender: 10.2.2.0,
Next Hop is 10.0.0.0 on POS0/1
Reservation Style is Shared-Explicit, QoS Service is Controlled-Load
Average Bitrate is 0G bits/sec, Maximum Burst is 1K bytes
FRR is in progress (we are Merge Point)
Notice that after the failure, there are two entries for the rerouted LSP.
The first entry continues to show the prefailure information (that is, RESV messages are being sent to 10.1.1.5 on POS0/1). This state is for the RESV being sent upstream before the failure, in response to path messages sent before the failure. This state may time out quickly, or it may continue to be refreshed for a few minutes if, for example, an upstream node is unaware of the failure.
The second entry shows the post-failure information (that is, RESV messages are being sent to 10.0.0.0 on POS0/1). This state is for the RESV messages being sent upstream after the failure (to the point of local repair [PLR]), and will remain and be refreshed as long as the LSP is rerouted.
In example 2, the merge point is also the tail of the LSP. There is no record route object (RRO) information because there are no nodes downstream.
MPLS Traffic Engineering Point-to-Multipoint Examples
The following is sample output from the show ip rsvp request detail command, which shows MPLS TE P2MP information:
Router# show ip rsvp request detail
P2MP ID: 22 Tun ID: 22 Ext Tun ID: 10.1.1.201
Tun Sender: 10.1.1.201 LSP ID: 1 SubGroup Orig: 10.1.1.201
S2L Destination : 10.1.1.203
Prev Hop:10.1.1.205 on Ethernet1/1
Reservation Style is Shared-Explicit, QoS Service is Controlled-Load
Average Bitrate is 500K bits/sec, Maximum Burst is 1K bytes
Request ID handle: 0100042C.
Policy: Forwarding. Policy source(s): MPLS/TE
PSB Handle List [1 elements]: [0x1000427]
RSB Handle List [1 elements]: [0x100042B]
Table 92 describes the significant fields shown in the display.
Table 92 show ip rsvp request—MPLS TE P2MP Field Descriptions
Field
|
Description
|
P2MP ID
|
A 32-bit number that identifies the set of destinations of the P2MP tunnel.
|
Tun ID
|
Tunnel identification number.
|
Ext Tun ID
|
Extended tunnel identification number.
|
Tun Sender
|
IP address of the sender.
|
LSP ID
|
Label switched path identification number.
|
SubGroup Orig
|
LSP headend router ID address.
|
SubGroup ID
|
An incremental number assigned to each sub-LSP signaled from the headend router.
|
S2L Destination
|
LSP tailend router ID address.
|
The following is sample output from the show ip rsvp request filter session-type 13 command, which shows RSVP RESV requests for point-to-multipoint traffic:
Router# show ip rsvp request filter session-type 13
Destination Tun Sender TunID LSPID P2MP-ID SubID Next Hop I/F BPS
192.168.5.1 10.1.1.201 22 1 22 1 192.168.40.1 Se1/0 80K
Related Commands
Command
|
Description
|
show ip rsvp reservation
|
Displays RSVP PATH-related receiver information currently in the database.
|
show ip rsvp sender
|
Displays RSVP RESV-related receiver information currently in the database.
|
show ip rsvp reservation
To display Resource Reservation Protocol (RSVP)-related receiver information currently in the database, use the show ip rsvp reservation command in user EXEC or privileged EXEC mode.
Syntax for T, 12.2S, 12.2SB, 12.2(33)SRD, and Earlier Releases
show ip rsvp reservation [detail] [filter [destination ip-address | hostname]
[dst-port port-number] [source ip-address | hostname] [src-port port-number]] [vrf {* |
vrf-name}]
Syntax for 12.2(33)SRE with Filtering Session Type all
show ip rsvp reservation [detail] [filter [session-type all]]
Syntax for 12.2(33)SRE with Filtering Session Type 1
show ip rsvp reservation [detail] [filter [session-type session-type-number]] [destination
ip-address | hostname] [dst-port port-number] [source ip-address | hostname] [src-port
port-number]]
Syntax for 12.2(33)SRE with Filtering Session Type 7 or 13
show ip rsvp reservation [detail] [filter [session-type session-type-number]] [destination
ip-address | hostname] [lsp-id lsp-id] [sender ip-address | hostname] [tunnel-id tunnel-id]]
Syntax Description
ip-address
|
(Optional) Destination IP address.
|
hostname
|
(Optional) Hostname of the receiver.
|
detail
|
(Optional) Specifies additional receiver information.
|
filter
|
(Optional) Specifies a subset of the receivers to display.
|
session-type session-type-number
|
(Optional) Specifies the type of RSVP sessions to display. Valid values are:
•1 for IPv4 sessions
•7 for IPv4 point-to-point (P2P) traffic engineering (TE) label switched path (LSP) tunnel sessions
•13 for IPv4 point-to-multipoint (P2MP) TE LSP tunnel sessions.
|
all
|
(Optional) Specifies all types of RSVP sessions.
|
destination ip-address
|
(Optional) Specifies the destination IP address of the receiver.
|
hostname
|
(Optional) Hostname of the receiver.
|
dst-port port-number
|
(Optional) Specifies the destination port number. The destination port number range is from 0 to 65535.
|
source ip-address
|
(Optional) Specifies the source IP address of the receiver.
|
hostname
|
(Optional) Hostname of the receiver.
|
src-port port-number
|
(Optional) Specifies the source port number. The source port number range is from 0 to 65535.
|
vrf *
|
(Optional) Displays all the configured virtual routing and forwarding (VRF) instances.
|
vrf vrf-name
|
(Optional) Name of a specified VRF.
|
Command Modes
User EXEC (>)
Privileged EXEC (#)
Command History
Release
|
Modification
|
11.2
|
This command was introduced.
|
12.2
|
This command was integrated into Cisco IOS Release 12.2. The detail keyword was added to display additional reservation information.
|
12.0(22)S
|
This command was integrated into Cisco IOS Release 12.0(22)S. The command displays Fast Reroute information when a link-state packet (LSP) is actively using a backup tunnel at this node (that is, when a node is the Point of Local Repair [PLR]). If desired, information for only a single tunnel or a subset of tunnels can be displayed. The command is supported on the Cisco 10000 series Edge Services Router (ESR).
|
12.2(18)SXD1
|
This command was integrated into Cisco IOS Release 12.2(18)SXD1.
|
12.4(4)T
|
This command was integrated into Cisco IOS Release 12.4(4)T, and its output was modified to display application ID information.
|
12.2(33)SRA
|
This command was integrated into Cisco IOS Release 12.2(33)SRA.
|
12.2(31)SB2
|
This command was integrated into Cisco IOS Release 12.2(31)SB2.
|
12.2(33)SRC
|
The command output was modified to display tunnel-based admission control (TBAC) and RSVP aggregation information.
|
15.0(1)M
|
This command was modified. The vrf and * keywords and the vrf-name argument were added.
|
12.2(33)SRE
|
This command was modified. The session-type keyword was added to display specific types of tunnels. The output was modified to display MPLS TE P2MP information.
|
Usage Guidelines
Use the show ip rsvp reservation command to display the current receiver (RESV) information in the database for a specified interface or all interfaces. This information includes reservations aggregated and forwarded from other RSVP routers.
Limiting the Display
When hundreds or thousands of tunnels exist and you are interested in only a few, you can display the output for only a single tunnel or a subset of tunnels. To request a limited display, enter the show ip rsvp reservation command with the appropriate keyword (called an output filter): destination, dst-port, source, and src-port. You can enter any or all of the output filters, and you can enter them whether or not you specify the detail keyword.
You can also limit the display to a particular VRF by using the show ip rsvp reservation vrf vrf-name command.
Examples
show ip rsvp reservation Example
The following is sample output from the show ip rsvp reservation command:
Router# show ip rsvp reservation
To From Pro DPort Sport Next Hop I/F Fi Serv
172.16.1.49 172.16.4.53 1 0 0 172.16.1.49 Se1 FF LOAD
Table 93 describes the significant fields shown in the display.
Table 93 show ip rsvp reservation Field Descriptions
Field
|
Descriptions
|
To
|
IP address of the receiver.
|
From
|
IP address of the sender.
|
Pro
|
Protocol code. UDP = User Data Protocol.
|
DPort
|
Destination port number.
|
Sport
|
Source port number.
|
Next Hop
|
IP address of the next hop.
|
I/F
|
Interface of the next hop.
|
Fi
|
Filter (Wildcard Filter, Shared-Explicit, or Fixed-Filter).
|
Serv
|
Service (value can be RATE or LOAD).
|
Application ID Example
The following is sample output from the show ip rsvp reservation detail command with application ID information:
Router# show ip rsvp reservation detail
RSVP Reservation. Destination is 192.168.104.3, Source is 192.168.104.1,
Protocol is UDP, Destination port is 4444, Source port is 4444
Next Hop is 192.168.106.2, Interface is ATM1/0.1
Reservation Style is Fixed-Filter, QoS Service is Guaranteed-Rate
Resv ID handle: 0A00040B.
Created: 12:18:32 UTC Sat Dec 4 2004
Average Bitrate is 5K bits/sec, Maximum Burst is 1K bytes
Min Policed Unit: 0 bytes, Max Pkt Size: 0 bytes
Policy: Forwarding. Policy source(s): Default
Priorities - preempt: 5, defend: 2
Application ID: 'GUID=www.cisco.com, VER=10.1.1.2, APP=voice, SAPP=h323'
'/usr/local/bin/CallManager'
Table 94 describes the significant fields shown in the display.
Table 94 show ip rsvp reservation detail—Application ID Field Descriptions
Field
|
Descriptions
|
RSVP Reservation
|
Destination—Receiver's IP address of the RESV message.
Source—Sender's IP address of the RESV message.
|
Protocol
|
Protocol—IP protocol used; UDP—User Data Protocol.
|
Destination port
|
Receiver's port number.
|
Source port
|
Sender's port number.
|
Next Hop
|
IP address of the next hop.
|
Interface
|
Interface type of the next hop.
|
Reservation Style
|
Multireservations sharing of bandwidth; values include Fixed-Filter, Shared-Explicit, and Wildcard-Filter.
|
QoS Service
|
Type of qulaity of service (QoS) configured; values include Guaranteed-Rate and Controlled Load.
|
Resv ID handle
|
Internal database ID assigned to the RESV message by RSVP for bookkeeping purposes.
|
Created
|
Time and date when the reservation was created.
|
Average Bitrate
|
Average rate, in bits per second, for the data.
|
Maximum Burst
|
Largest amount of data allowed in kilobytes.
|
Min Policed Unit
|
Size of the smallest packet generated by the application in bytes, including the application data and all protocol headers at or above the IP level.
|
Max Pkt Size
|
Largest packet allowed in bytes.
|
Status
|
Status of the local policy; values are Proxied and Proxy-terminated.
Note A blank status field means you issued the command on a midpoint for that reservation.
|
Policy
|
Policy status: Forwarding—RSVP RESV messages are being accepted and forwarded.
|
Policy source(s)
|
Type of local policy in effect; values include Default, Local, and MPLS/TE.
|
Priorities
|
Preemption priorities in effect.
•preempt: the startup priority; values are 0 to 7 for traffic engineering (TE) reservations with 0 being the highest. Values are 0 to 65535 for non-TE reservations with 0 being the lowest.
•defend: the hold priority; values are the same as preempt.
|
Application ID
|
A quotable string that identifies the sender application and can be used to match on local policies. The string includes the policy locator in the X.500 Distinguished Name format and the application or filename of the sender application.
|
TBAC Example
The following is sample output from the show ip rsvp reservation detail command when TBAC is configured:
Router# show ip rsvp reservation detail
RSVP Reservation. Destination is 10.4.0.1, Source is 10.1.0.1,
Protocol is UDP, Destination port is 100, Source port is 100
Next Hop: 10.4.0.1 on Tunnel1, out of band
Reservation Style is Fixed-Filter, QoS Service is Guaranteed-Rate
Resv ID handle: 0100040D.
Created: 11:59:53 IST Tue Mar 20 2007
Average Bitrate is 10K bits/sec, Maximum Burst is 1K bytes
Min Policed Unit: 0 bytes, Max Pkt Size: 0 bytes
Policy: Forwarding. Policy source(s): Default
Table 95 describes the significant fields shown in the display.
Table 95 show ip rsvp reservation detail—TBAC Field Descriptions
Field
|
Descriptions
|
RSVP Reservation
|
Destination—Receiver's IP address of the RESV message.
Source—Sender's IP address of the RESV message.
|
Protocol
|
Protocol—IP protocol used; UDP—User Data Protocol.
|
Destination port
|
Receiver's port number.
|
Source port
|
Sender's port number.
|
Next Hop
|
IP address of the next hop on tunnel interface with out-of-band signaling.
|
Reservation Style
|
Multireservations sharing of bandwidth; values include Fixed-Filter, Shared-Explicit, and Wildcard-Filter.
|
QoS Service
|
Type of QoS configured; values include Guaranteed-Rate and Controlled Load.
|
Resv ID handle
|
Internal database ID assigned to the RESV message by RSVP for bookkeeping purposes.
|
Created
|
Time and date when the reservation was created.
|
Average Bitrate
|
Average rate, in bits per second, for the data.
|
Maximum Burst
|
Largest amount of data allowed in kilobytes.
|
Min Policed Unit
|
Size of the smallest packet generated by the application in bytes, including the application data and all protocol headers at or above the IP level.
|
Max Pkt Size
|
Largest packet allowed in bytes.
|
Status
|
Status of the local policy; values are Proxied and Proxy-terminated.
Note A blank status field means you issued the command on a midpoint for that reservation.
|
Policy
|
Policy status: Forwarding—RSVP RESV messages are being accepted and forwarded.
|
Policy source(s)
|
Type of local policy in effect; values include Default, Local, and MPLS/TE.
|
RSVP Aggregation Example
The following is sample output from the show ip rsvp reservation detail command when RSVP aggregation is configured:
Router# show ip rsvp reservation detail
RSVP Reservation. Destination is 192.168.5.1, Source is 192.168.2.1,
Protocol is TCP, Destination port is 222, Source port is 222
Next Hop: 192.168.50.1 on Serial1/0
Reservation Style is Fixed-Filter, QoS Service is Guaranteed-Rate
Resv ID handle: 0600040A.
Created: 20:27:58 EST Thu Nov 29 2007
Average Bitrate is 80K bits/sec, Maximum Burst is 5K bytes
Min Policed Unit: 0 bytes, Max Pkt Size: 0 bytes
DiffServ Integration: DSCPs: 46
Policy: Forwarding. Policy source(s): Default
3175 Aggregation: RSVP 3175 AggResv 192.168.40.1->192.168.50.1_ef(46)
RSVP Reservation. Destination is 192.168.50.1, Source is 192.168.40.1,
Protocol is 0 , Destination port is 46, Source port is 0
Next Hop: 10.30.1.1 on Serial1/0
Reservation Style is Fixed-Filter, QoS Service is Controlled-Load
Resv ID handle: 03000408.
Created: 20:27:50 EST Thu Nov 29 2007
Average Bitrate is 300K bits/sec, Maximum Burst is 300K bytes
Min Policed Unit: 20 bytes, Max Pkt Size: 0 bytes
Policy: Forwarding. Policy source(s): Default
Table 96 describes the significant fields shown in the display.
Table 96 show ip rsvp reservation detail—RSVP Aggregation Field Descriptions
Field
|
Descriptions
|
RSVP Reservation
|
Destination—Receiver's IP address of the RESV message.
•Deaggregator for aggregate reservations.
Source—Sender's IP address of the RESV message.
•Aggregator for aggregate reservations.
|
Protocol
|
Protocol—IP protocol used; TCP—Transmission Control Protocol.
•0 for aggregate reservations.
|
Destination port
|
Receiver's port number.
•DSCP for aggregate reservations.
|
Source port
|
Sender's port number.
•0 for aggregate reservations.
|
Next Hop
|
IP address of the next hop on a specified interface.
•Deaggregator IP address for E2E reservations mapped onto an aggregate as seen at the aggregator.
•None for aggregate reservations as seen at the deaggregator.
|
Reservation Style
|
Multireservations sharing of bandwidth; values include Fixed-Filter, Shared-Explicit, and Wildcard-Filter.
|
QoS Service
|
Type of QoS Service configured; values include Guaranteed-Rate and Controlled Load.
|
Resv ID handle
|
Internal database ID assigned to the RESV message by RSVP for bookkeeping purposes.
|
Created
|
Time and date when the reservation was created.
|
Average Bitrate
|
Average rate requested, in bits per second, for the data.
|
Maximum Burst
|
Largest amount of data allowed in kilobytes.
|
Min Policed Unit
|
Size of the smallest packet generated by the application in bytes, including the application data and all protocol headers at or above the IP level.
•Always 0 or 20 on a node configured for RSVP aggregation.
|
Max Pkt Size
|
Largest packet allowed in bytes.
•Always 0 on a node configured for RSVP aggregation.
|
Status
|
Status of the local policy; policy source and preemption values.
Note A blank status field means you issued the command on a midpoint for that reservation.
Note Preemption values are shown only if RSVP preemption is enabled on the router.
|
Policy
|
Policy status: Forwarding—RSVP RESV messages are being accepted and forwarded.
|
Policy source(s)
|
Type of local policy in effect; values include default, local, and Multiprotocol Label Switching (MPLS)/Traffic Engineering (TE).
|
3175 Aggregation: agg_info
|
Aggregated reservation on which this E2E reservation is mapped with source (aggregator) and destination (deaggregator) endpoints, IP addresses, and aggregate reservation DSCP.
|
PLR Examples
The following is sample output from the show ip rsvp reservation detail command when the command is entered on the PLR before and after a failure.
Figure 2 illustrates the network topology for the RSVP configuration example.
Figure 2 Network Topology for the RSVP Configuration Example
Example 1: The command is entered on the PLR before a failure.
Router# show ip rsvp reservation detail
RSVP Reservation. Tun Dest: 10.2.2.1 Tun Sender: 10.2.2.0,
Next Hop is 10.1.1.4 on POS1/2
Reservation Style is Shared-Explicit, QoS Service is Controlled-Load
Average Bitrate is 0G bits/sec, Maximum Burst is 1K bytes
10.1.1.5/32, Flags:0x0 (No Local Protection)
Label record: Flags 0x1, ctype 1, incoming label 18
10.1.1.6/32, Flags:0x0 (No Local Protection)
Label record: Flags 0x1, ctype 1, incoming label 0
Example 2: The command is entered on the PLR after a failure.
Router# show ip rsvp reservation detail
RSVP Reservation. Tun Dest: 10.2.2.1 Tun Sender: 10.2.2.0,
FRR is in progress: (we are PLR)
Bkup Next Hop is 10.0.0.1 on POS1/1
Orig Next Hop was 10.1.1.4 on POS1/2
Reservation Style is Shared-Explicit, QoS Service is Controlled-Load
Average Bitrate is 0G bits/sec, Maximum Burst is 1K bytes
10.2.2.1/32, Flags:0x0 (No Local Protection)
Label record: Flags 0x1, ctype 1, incoming label 0
Notice the following (see italicized text) in Examples 1 and 2:
•At the PLR, you see "Fast Reroute (FRR) is in progress (we are PLR)" when an LSP has been rerouted (that is, it is actively using a backup tunnel).
•RESV messages arrive on a different interface and from a different next hop after a failure. The prefailure display shows the original NHOP and arriving interface; the post-failure display shows both the original and the new (Bkup) NHOP and arriving interface. The label is also shown.
•The Record Route Object (RRO) in arriving RESV messages changes after the failure, given that the RESV messages will avoid the failure (that is, it will traverse different links or hops).
MPLS Traffic Engineering Point-to-Multipoint Examples
The following is sample output from the show ip rsvp reservation detail command, which shows point-to-multipoint information:
Router# show ip rsvp reservation detail
P2MP ID: 22 Tun ID: 22 Ext Tun ID: 10.1.1.201
Tun Sender: 10.1.1.201 LSP ID: 1 SubGroup Orig: 10.1.1.201
S2L Destination : 10.1.1.203
Next Hop: 10.0.0.205 on Ethernet0/0
Reservation Style is Shared-Explicit, QoS Service is Controlled-Load
Resv ID handle: 0100042A.
Created: 09:13:16 EST Tue Jun 30 2009
Average Bitrate is 500K bits/sec, Maximum Burst is 1K bytes
Min Policed Unit: 0 bytes, Max Pkt Size: 1500 bytes
10.1.1.205/32, Flags:0x20 (No Local Protection, Node-id)
Label subobject: Flags 0x1, C-Type 1, Label 20
10.1.1.202/32, Flags:0x20 (No Local Protection, Node-id)
Label subobject: Flags 0x1, C-Type 1, Label 17
10.1.1.203/32, Flags:0x20 (No Local Protection, Node-id)
Label subobject: Flags 0x1, C-Type 1, Label 16
Policy: Accepted. Policy source(s): MPLS/TE
Table 97 describes the significant fields shown in the display.
Table 97 show ip rsvp reservation detail—MPLS TE P2MP Field Descriptions
Field
|
Description
|
P2MP ID
|
A 32-bit number that identifies the set of destinations of the P2MP tunnel.
|
Tun ID
|
Tunnel identification number.
|
Ext Tun ID
|
Extended tunnel identification number.
|
Tun Sender
|
IP address of the sender.
|
LSP ID
|
Label switched path identification number.
|
SubGroup Orig
|
LSP headend router ID address.
|
SubGroup ID
|
An incremental number assigned to each sub-LSP signaled from the headend router.
|
S2L Destination
|
LSP tailend router ID address.
|
The following is sample output from the show ip rsvp reserveration filter session-type 13 command, which shows RSVP RESV messages for point-to-multipoint traffic:
Router# show ip rsvp reservation filter session-type 13
Destination Tun Sender TunID LSPID P2MP-ID SubID Next Hop I/F BPS
10.1.1.203 10.1.1.201 22 1 22 1 10.0.0.205 Et0/0 500K
10.1.1.206 10.1.1.201 22 1 22 2 10.0.0.205 Et0/0 500K
10.1.1.213 10.1.1.201 22 1 22 3 10.0.0.205 Et0/0 500K
10.1.1.214 10.1.1.201 22 1 22 4 10.0.1.202 Et0/1 500K
10.1.1.216 10.1.1.201 22 1 22 5 10.0.1.202 Et0/1 500K
10.1.1.217 10.1.1.201 22 1 22 6 10.0.1.202 Et0/1 500K
Related Commands
Command
|
Description
|
clear ip rsvp hello instance counters
|
Clears (refreshes) the values for Hello instance counters.
|
ip rsvp reservation
|
Enables a router to simulate RSVP RESV message reception from the sender.
|
show ip rsvp sender
|
Displays RSVP RESV-related receiver information currently in the database.
|
show ip rsvp sender
To display Resource Reservation Protocol (RSVP) PATH-related sender information currently in the database, use the show ip rsvp sender command in user EXEC or privileged EXEC mode.
Syntax for T, 12.2S, 12.2SB, 12.2(33)SRD, and Earlier Releases
show ip rsvp sender [detail] [filter [destination ip-address | hostname] [dst-port port-number]
[source ip-address | hostname] [src-port port-number]] [vrf {* | vrf-name}]
Syntax for 12.2(33)SRE with Filtering Session Type all
show ip rsvp sender [detail] [filter [session-type all]]
Syntax for 12.2(33)SRE with Filtering Session Type 1
show ip rsvp sender [detail] [filter [session-type session-type-number]] [destination ip-address |
hostname] [dst-port port-number] [source ip-address | hostname] [src-port port-number]]
Syntax for 12.2(33)SRE with Filtering Session Type 7 or 13
show ip rsvp sender [detail] [filter [session-type session-type-number]] [destination ip-address |
hostname] [lsp-id lsp-id] [sender ip-address | hostname] [tunnel-id tunnel-id]]
Syntax Description
detail
|
(Optional) Specifies additional sender information.
|
filter
|
(Optional) Specifies a subset of the senders to display.
|
session-type session-type-number
|
(Optional) Specifies the type of RSVP sessions to display. Valid values are:
•1 for IPv4 sessions.
•7 for IPv4 point-to-point (P2P) traffic engineering (TE) label switched path (LSP) tunnel sessions.
•13 for IPv4 point-to-multipoint (P2MP) TE LSP tunnel sessions.
|
all
|
(Optional) Specifies all types of RSVP sessions.
|
destination ip-address
|
(Optional) Specifies the destination IP address of the sender.
|
hostname
|
(Optional) Hostname of the sender.
|
dst-port port-number
|
(Optional) Specifies the destination port number. The range is from 0 to 65535.
|
source ip-address
|
(Optional) Specifies the source IP address of the sender.
|
hostname
|
(Optional) Hostname of the sender.
|
src-port port-number
|
(Optional) Specifies the source port number. The range is from 0 to 65535.
|
vrf *
|
(Optional) Displays all the configured virtual routing and forwarding (VRF) instances.
|
vrf vrf-name
|
(Optional) Name of a specified VRF.
|
Command Modes
User EXEC (>)
Privileged EXEC (#)
Command History
Release
|
Modification
|
11.2
|
This command was introduced.
|
12.0(22)S
|
The command output was modified to display Fast Reroute information, and support was introduced for the Cisco 10000 series Edge Services Router (ESR).
|
12.2(18)SXD1
|
This command was integrated into Cisco IOS Release 12.2(18)SXD1.
|
12.4(4)T
|
The command output was modified to display application ID information.
|
12.2(33)SRA
|
This command was integrated into Cisco IOS Release 12.2(33)SRA.
|
12.2(31)SB2
|
This command was integrated into Cisco IOS Release 12.2(31)SB2.
|
12.2(33)SRB
|
The command output was modified to display fast local repair (FLR) information.
|
12.2(33)SRC
|
The command output was modified to display tunnel-based admission control (TBAC) and RSVP aggregation information.
|
15.0(1)M
|
This command was modified. The vrf and * keywords and the vrf-name argument were added.
|
12.2(33)SRE
|
This command was modified. The session-type keyword was added to display specific types of tunnels. The output was modified to display MPLS TE P2MP information.
|
Usage Guidelines
Use the show ip rsvp sender command to display the RSVP sender (PATH) information currently in the database for a specified interface or for all interfaces.
The show ip rsvp sender command is very useful for determining the state of RSVP signaling both before and after a label switched path (LSP) has been fast rerouted. The show ip rsvp sender command is especially useful when used at the point of local repair (PLR) or at the merge point (MP).
Limiting the Display
When hundreds or thousands of tunnels exist and you are interested in only a few, you can display output for only a single tunnel or a subset of tunnels. To request a limited display, enter the show ip rsvp sender command with the appropriate keyword (called an output filter): destination, dst-port, source, and src-port. You can enter any or all of the output filters, and you can enter them whether or not you specify the detail keyword.
Fast Local Repair (FLR) Statistics
Use the show ip rsvp sender detail command to display FLR statistics before, during, and after an FLR procedure. This command shows when a path state block (PSB) was repaired and can be used to determine when the cleanup began after the FLR procedure has finished. However, this command does not display old PLR or MP segments.
Examples
show ip rsvp sender Example
The following is sample output from the show ip rsvp sender command:
Router# show ip rsvp sender
To From Pro DPort Sport Prev Hop I/F BPS
172.16.1.49 172.16.4.53 1 0 0 172.16.3.53 Et1 80K
172.16.2.51 172.16.5.54 1 0 0 172.16.3.54 Et1 80K
192.168.50.1 192.168.40.1 0 46 0 none none 17179868160
Table 98 describes the significant fields shown in the display.
Table 98 show ip rsvp sender Field Descriptions
Field
|
Description
|
To
|
IP address of the receiver.
|
From
|
IP address of the sender.
|
Pro
|
Protocol code.
•Code 1 indicates an IP protocol such as TCP or UDP.
•Code 0 indicates an aggregate reservation.
|
DPort
|
Destination port number.
•The DSCP for an aggregate reservation.
|
Sport
|
Source port number.
•0 for an aggregate reservation.
|
Prev Hop
|
IP address of the previous hop.
•None if the node is an aggregator for this reservation.
|
I/F
|
Interface of the previous hop.
•None if the node is an aggregator for this reservation.
|
BPS
|
As specified in the sender_tspec characteristics of the sender data flow—specified bit rate, in bits per second.
•Always 17179868160 for an aggregate reservation.
|
Application ID Example
The following is sample output from the show ip rsvp sender detail command with application IDs configured:
Router# show ip rsvp sender detail
PATH Session address: 192.168.104.3, port: 4444. Protocol: UDP
Sender address: 192.168.104.1, port: 4444
Inbound from: 192.168.104.1 on interface:
Traffic params - Rate: 5K bits/sec, Max. burst: 1K bytes
Min Policed Unit: 0 bytes, Max Pkt Size 4294967295 bytes
Path ID handle: 09000408.
Incoming policy: Accepted. Policy source(s): Default
Priorities - preempt: 5, defend: 2
Application ID: 'GUID=www.cisco.com, VER=10.1.1.2, APP=voice, SAPP=h323'
'/usr/local/bin/CallManager'
Output on ATM1/0.1. Policy status: Forwarding. Handle: 04000409
Policy source(s): Default
Table 99 describes the significant fields shown in the display.
Table 99 show ip rsvp sender detail Field Descriptions
Field
|
Descriptions
|
PATH Session address
|
Destination IP address of the PATH message.
•port—Number of the destination port.
•Protocol—IP protocol used.
|
Sender address
|
Source IP address of the PATH message.
•port—Number of the source port.
|
Inbound from
|
IP address of the sender and the interface name.
Note A blank interface field means that the PATH message originated at the router on which the show command is being executed (the headend router). A specified interface means that the PATH message originated at an upstream router.
|
Traffic params
|
Traffic parameters in effect:
•Rate—Speed, in kilobits per second.
•Max. burst—Largest amount of data allowed, in kilobytes.
•Min Policed Unit—Size, in bytes, of the smallest packet generated by the application, including the application data and all protocol headers at or above the IP level.
•Max Pkt Size—Largest packet allowed in bytes.
|
PATH ID handle
|
Internal database ID assigned to the PATH message by RSVP for bookkeeping purposes.
|
Incoming policy
|
State of the incoming policy:
•Accepted—RSVP PATH messages are being accepted, but not forwarded.
•Not Accepted—RSVP PATH messages are being rejected.
|
Policy source(s)
|
Type of local policy in effect; values include Default, Local, and MPLS/TE.
|
Priorities
|
Preemption priorities in effect:
•preempt—The startup priority; values are 0 to 7 for traffic engineering (TE) reservations with 0 being the highest. Values are 0 to 65535 for non-TE reservations with 0 being the lowest.
•defend—The hold priority; values are the same as for preempt.
|
Application ID
|
A quotable string that identifies the sender application and can be used to match on local policies. The string includes the policy locator in the X.500 Distinguished Name format and the application or filename of the sender application.
|
Status
|
Status of the local policy:
•Proxied—Head.
•Proxy-terminated—Tail.
•Blockaded—Tail or midpoint and an RESVERROR message has recently been received; therefore, the PSB enters the blockaded state.
|
Output on interface
|
Policy status (on the outbound interface):
•Forwarding—Inbound PATH messages are being forwarded.
•Not Forwarding—Outbound PATH messages are being rejected.
•Handle—Internal database ID assigned to the PATH message by RSVP for bookkeeping purposes.
|
Policy source(s)
|
Type of local policy in effect; values include Default, Local, and MPLS/TE.
|
Before FLR Example
The following is sample output from the show ip rsvp sender detail command before FLR has occurred:
Router# show ip rsvp sender detail
Destination 192.168.101.21, Protocol_Id 17, Don't Police , DstPort 1
Sender address: 10.10.10.10, port: 1
arriving: from PHOP 172.16.31.34 on Et0/0 every 30000 msecs
Traffic params - Rate: 9K bits/sec, Max. burst: 9K bytes
Min Policed Unit: 0 bytes, Max Pkt Size 2147483647 bytes
Path ID handle: 01000401.
Incoming policy: Accepted. Policy source(s): Default
Output on Ethernet1/0. Policy status: Forwarding. Handle: 02000400
Policy source(s): Default
Table 100 describes the significant fields shown in the display.
Table 100 show ip rsvp sender detail Field Descriptions—Before FLR
Field
|
Descriptions
|
PATH
|
PATH message information:
•Destination IP address.
•Protocol ID number.
•Policing.
•Destination port number.
|
Sender address
|
Source IP address of the PATH message.
•port—Number of the source port.
|
Path refreshes
|
Refresh information:
•IP address of the source (previous hop [PHOP]).
•Interface name and number.
•Frequency, in milliseconds (msec).
|
Traffic params
|
Traffic parameters in effect:
•Rate—Speed, in kilobits per second.
•Max. burst—Largest amount of data allowed, in kilobytes.
•Min Policed Unit—Size, in bytes, of the smallest packet generated by the application, including the application data and all protocol headers at or above the IP level.
•Max Pkt Size—Largest packet allowed, in bytes.
|
PATH ID handle
|
Internal database ID assigned to the PATH message by RSVP for bookkeeping purposes.
|
Incoming policy
|
State of the incoming policy:
•Accepted—RSVP PATH messages are being accepted, but not forwarded.
•Not Accepted—RSVP PATH messages are being rejected.
|
Policy source(s)
|
Type of local policy in effect; values include Default, Local, and MPLS/TE.
|
Status
|
Status of the local policy:
•Proxied—Head.
•Proxy-terminated—Tail.
•Blockaded—Tail or midpoint and an RESVERROR message has recently been received; therefore, the PSB enters the blockaded state.
Note A blank field means none of the above.
|
Output on interface
|
Policy status (on the outbound interface):
•Forwarding—Inbound PATH messages are being forwarded.
•Not Forwarding—Outbound PATH messages are being rejected.
•Handle—Internal database ID assigned to the PATH message by RSVP for bookkeeping purposes.
|
Policy source(s)
|
Type of local policy in effect; values include Default, Local, and MPLS/TE.
|
Path FLR
|
Never repaired—Indicates that the node has never been a point of local repair (PLR) and, therefore, has never repaired the PSB.
|
At the PLR During FLR Example
Note A node that initiates an FLR procedure is the point of local repair or PLR.
The following is sample output from the show ip rsvp sender detail command at the PLR during an FLR procedure:
Router# show ip rsvp sender detail
Destination 192.168.101.21, Protocol_Id 17, Don't Police , DstPort 1
Sender address: 10.10.10.10, port: 1
arriving: from PHOP 172.16.31.34 on Et0/0 every 30000 msecs
Traffic params - Rate: 9K bits/sec, Max. burst: 9K bytes
Min Policed Unit: 0 bytes, Max Pkt Size 2147483647 bytes
Path ID handle: 01000401.
Incoming policy: Accepted. Policy source(s): Default
Path FLR: PSB is currently being repaired...try later
Output on Ethernet1/0, nhop 172.16.36.34
Time before expiry: 2 refreshes
Policy status: Forwarding. Handle: 02000400
Policy source(s): Default
Table 101 describes the significant fields shown in the display.
Table 101 show ip rsvp sender detail Field Descriptions—at the PLR During FLR
Field
|
Descriptions
|
PATH
|
PATH message information including the following:
•Destination IP address.
•Protocol ID number.
•Policing.
•Destination port number.
|
Sender address
|
Source IP address of the PATH message.
•port—Number of the source port.
|
Path refreshes
|
Refresh information:
•IP address of the source (previous hop [PHOP]).
•Interface name and number.
•Frequency, in milliseconds (msec).
|
Traffic params
|
Traffic parameters in effect:
•Rate—Speed, in kilobits per second.
•Max. burst—Largest amount of data allowed, in kilobytes.
•Min Policed Unit—Size, in bytes, of the smallest packet generated by the application, including the application data and all protocol headers at or above the IP level.
•Max Pkt Size—Largest packet allowed, in bytes.
|
PATH ID handle
|
Internal database ID assigned to the PATH message by RSVP for bookkeeping purposes.
|
Incoming policy
|
State of the incoming policy:
•Accepted—RSVP PATH messages are being accepted, but not forwarded.
•Not Accepted—RSVP PATH messages are being rejected.
|
Policy source(s)
|
Type of local policy in effect; values include Default, Local, and MPLS/TE.
|
Status
|
Status of the local policy:
•Proxied—Head.
•Proxy-terminated—Tail.
•Blockaded—Tail or midpoint and an RESVERROR message has recently been received; therefore, the PSB enters the blockaded state.
Note A blank field means none of the above.
|
Path FLR
|
PSB is currently being repaired. FLR is in process.
|
PLR - Old Segments
|
The number of old segments or interfaces after the PLR initiated the FLR procedure. For each old segment, the following information displays:
•Output on interface—Outbound interface after the FLR and the next-hop IP address.
•Time before expiry—Number of PATH messages sent on a new segment before the old route (segment) expires.
•Policy status (on the outbound interface):
–Forwarding—Inbound PATH messages are being forwarded.
–Not Forwarding—Outbound PATH messages are being rejected.
–Handle—Internal database ID assigned to the PATH message by RSVP for bookkeeping purposes.
Policy source(s)—Type of local policy in effect; values include Default, Local, and MPLS/TE.
|
At the MP During an FLR Example
Note The node where the old and new paths (also called segments or interfaces) meet is the merge point (MP).
The following is sample output from the show ip rsvp sender detail command at the MP during an FLR procedure:
Router# show ip rsvp sender detail
Destination 192.168.101.21, Protocol_Id 17, Don't Police , DstPort 1
Sender address: 10.10.10.10, port: 1
arriving: from PHOP 172.16.37.35 on Et1/0 every 30000 msecs
Traffic params - Rate: 9K bits/sec, Max. burst: 9K bytes
Min Policed Unit: 0 bytes, Max Pkt Size 2147483647 bytes
Path ID handle: 09000406.
Incoming policy: Accepted. Policy source(s): Default
Input on Serial2/0, phop 172.16.36.35
Time before expiry: 9 refreshes
Table 102 describes the significant fields shown in the display.
Table 102 show ip rsvp sender detail Field Descriptions—at the MP During FLR
Field
|
Descriptions
|
PATH
|
PATH message information:
•Destination IP address.
•Protocol ID number.
•Policing.
•Destination port number.
|
Sender address
|
Source IP address of the PATH message.
•port—Number of the source port.
|
Path refreshes
|
Refresh information:
•IP address of the source (previous hop [PHOP]).
•Interface name and number.
•Frequency, in milliseconds (msec).
|
Traffic params
|
Traffic parameters in effect:
•Rate—Speed, in kilobits per second.
•Max. burst—Largest amount of data allowed, in kilobytes.
•Min Policed Unit—Size, in bytes, of the smallest packet generated by the application, including the application data and all protocol headers at or above the IP level.
•Max Pkt Size—Largest packet allowed, in bytes.
|
PATH ID handle
|
Internal database ID assigned to the PATH message by RSVP for bookkeeping purposes.
|
Incoming policy
|
State of the incoming policy:
•Accepted—RSVP PATH messages are being accepted, but not forwarded.
•Not Accepted—RSVP PATH messages are being rejected.
|
Policy source(s)
|
Type of local policy in effect; values include Default, Local, and MPLS/TE.
|
Status
|
Status of the local policy:
•Proxied—Head.
•Proxy-terminated—Tail.
•Blockaded—Tail or midpoint and an RESVERROR message has recently been received; therefore, the PSB enters the blockaded state.
Note A blank field means none of the above.
|
Path FLR
|
Never repaired—Indicates that the node has never been a PLR and, therefore, has never repaired the PSB.
|
MP - Old Segments
|
The number of old segments or interfaces on the MP before the PLR initiated the FLR procedure. For each old segment, the following information displays:
•Input on interface—Inbound interface and the previous-hop IP address.
•Time before expiry—Number of PATH messages to be received on other segments before this segment expires.
|
At the PLR After an FLR Example
The following is sample output from the show ip rsvp sender detail command at the PLR after an FLR procedure:
Router# show ip rsvp sender detail
Destination 192.168.101.21, Protocol_Id 17, Don't Police , DstPort 1
Sender address: 10.10.10.10, port: 1
arriving: from PHOP 172.16.31.34 on Et0/0 every 30000 msecs
Traffic params - Rate: 9K bits/sec, Max. burst: 9K bytes
Min Policed Unit: 0 bytes, Max Pkt Size 2147483647 bytes
Path ID handle: 05000401.
Incoming policy: Accepted. Policy source(s): Default
Output on Serial3/0. Policy status: Forwarding. Handle: 3B000406
Policy source(s): Default
Path FLR: Started 12:56:16 EST Thu Nov 16 2006, PSB repaired 532(ms) after.
Resv/Perr: Received 992(ms) after.
Table 103 describes the significant fields shown in the display.
Table 103 show ip rsvp sender detail Field Descriptions—at the PLR After FLR
Field
|
Descriptions
|
PATH
|
PATH message information including the following:
•Destination IP address.
•Protocol ID number.
•Policing.
•Destination port number.
|
Sender address
|
Source IP address of the PATH message.
•port—Number of the source port.
|
Path refreshes
|
Refresh information including the following:
•IP address of the source (previous hop [PHOP]).
•Interface name and number.
•Frequency, in milliseconds (msec).
|
Traffic params
|
Traffic parameters in effect:
•Rate—Speed, in kilobits per second.
•Max. burst—Largest amount of data allowed, in kilobytes.
•Min Policed Unit—Size, in bytes, of the smallest packet generated by the application, including the application data and all protocol headers at or above the IP level.
•Max Pkt Size—Largest packet allowed, in bytes.
|
Path ID handle
|
Internal database ID assigned to the PATH message by RSVP for bookkeeping purposes.
|
Incoming policy
|
State of the incoming policy:
•Accepted—RSVP PATH messages are being accepted, but not forwarded.
•Not Accepted—RSVP PATH messages are being rejected.
|
Policy source(s)
|
Type of local policy in effect; values include Default, Local, and MPLS/TE.
|
Status
|
Status of the local policy:
•Proxied—Head.
•Proxy-terminated—Tail.
•Blockaded—Tail or midpoint and an RESVERROR message has recently been received; therefore, the PSB enters the blockaded state.
Note A blank field means none of the above.
|
Output on interface
|
Policy status (on the outbound interface):
•Forwarding—Inbound PATH messages are being forwarded.
•Not Forwarding—Outbound PATH messages are being rejected.
•Handle—Internal database ID assigned to the PATH message by RSVP for bookkeeping purposes.
|
Policy source(s)
|
Type of local policy in effect; values include Default, Local, and MPLS/TE.
|
Path FLR
|
FLR statistics that show when RSVP received the notification from RIB and how long thereafter the PATH message was sent. This delay can result when the interface on which the PATH message was sent had a wait time configured or when other PSBs were processed before this one or a combination of both. The statistics also show when an associated RESV or PATHERROR message was received.
Note This delay tells you the time when QoS was not honored for the specified flow.
|
TBAC Example
The following is sample output from the show ip rsvp sender detail command when TBAC is configured:
Router# show ip rsvp sender detail
Destination 10.0.0.3, Protocol_Id 17, Don't Police , DstPort 2
Sender address: 10.0.0.1, port: 2
arriving: from PHOP 10.1.1.1 on Et0/0 every 30000 msecs. Timeout in 189 sec
Traffic params - Rate: 10K bits/sec, Max. burst: 10K bytes
Min Policed Unit: 0 bytes, Max Pkt Size 2147483647 bytes
Path ID handle: 02000412.
Incoming policy: Accepted. Policy source(s): Default
Output on Tunnel1, out of band. Policy status: Forwarding. Handle: 0800040E
Policy source(s): Default
Table 104 describes the significant fields shown in the display.
Table 104 show ip rsvp sender detail Field Descriptions—with TBAC
Field
|
Descriptions
|
PATH
|
PATH message information:
•Destination IP address.
•Protocol ID number.
•Policing.
•Destination port number.
|
Sender address
|
Source IP address of the PATH message.
•port—Number of the source port.
|
Path refreshes
|
Refresh information:
•IP address of the source (previous hop [PHOP]).
•Interface name and number.
•Frequency, in milliseconds (msec).
Note A blank field means no refreshes have occurred.
|
Traffic params
|
Traffic parameters in effect:
•Rate—Speed, in kilobits per second.
•Max. burst—Largest amount of data allowed, in kilobytes.
•Min Policed Unit—Size, in bytes, of the smallest packet generated by the application, including the application data and all protocol headers at or above the IP level.
•Max Pkt Size—Largest packet allowed, in bytes.
|
PATH ID handle
|
Internal database ID assigned to the PATH message by RSVP for bookkeeping purposes.
|
Incoming policy
|
State of the incoming policy:
•Accepted—RSVP PATH messages are being accepted, but not forwarded.
•Not Accepted—RSVP PATH messages are being rejected.
|
Policy source(s)
|
Type of local policy in effect; values include Default, Local, and MPLS/TE.
|
Status
|
Status of the local policy:
•Proxied—Head.
•Proxy-terminated—Tail.
•Blockaded—Tail or midpoint and an RESVERROR message has recently been received; therefore, the PSB enters the blockaded state.
Note A blank field means none of the above.
|
Output on tunnel
|
Policy status (on the outbound tunnel with out-of-band signaling):
•Forwarding—Inbound PATH messages are being forwarded.
•Not Forwarding—Outbound PATH messages are being rejected.
•Handle—Internal database ID assigned to the PATH message by RSVP for bookkeeping purposes.
|
Policy source(s)
|
Type of local policy in effect; values include Default, Local, and MPLS/TE.
|
Path FLR
|
Never repaired—Indicates that the node has never been a point of local repair (PLR) and, therefore, has never repaired the PSB.
|
RSVP Aggregation Example
The following is sample output from the show ip rsvp sender detail command when RSVP aggregation is configured:
Router# show ip rsvp sender detail
Destination 10.10.10.21, Protocol_Id 17, Don't Police , DstPort 1
Sender address: 10.10.10.11, port: 1
arriving: from PHOP 10.10.10.34 on Et1/0 every 30000 msecs
Traffic params - Rate: 10K bits/sec, Max. burst: 10K bytes
Min Policed Unit: 0 bytes, Max Pkt Size 2147483647 bytes
Path ID handle: 0F000406.
Incoming policy: Accepted. Policy source(s): Default
3175 Aggregation: agg_info : AggResv 10.10.10.34->10.10.10.2_46
Output on Serial2/0. Policy status: Forwarding. Handle: 09000405
Policy source(s): Default
Deaggregator 10.10.10.2, DSCP 46, Don't Police
Aggregator address: 10.10.10.34
arriving: from PHOP 192.168.34.36 on Et1/0 every 30000 msecs
Traffic params - Rate: 17179868160 bits/sec, Max. burst: 536870784 bytes
Min Policed Unit: 1 bytes, Max Pkt Size 2147483647 bytes
Path ID handle: 1500040A.
Incoming policy: Accepted. Policy source(s): Default
Table 105 describes the significant fields shown in the display.
Table 105 show ip rsvp sender detail Field Descriptions—with RSVP Aggregation
Field
|
Descriptions
|
PATH
|
PATH message information for E2e reservations:
•Destination IP address.
•Protocol ID number.
•Policing.
–Always Don't Police.
•Destination port number.
|
Sender address
|
Source IP address of the PATH message.
•port—Number of the source port.
|
Path refreshes
|
Refresh information:
•IP address of the source (previous hop [PHOP]).
•Interface name and number.
•Frequency, in milliseconds (msec).
Note A blank field means no refreshes have occurred.
|
Traffic params
|
Traffic parameters in effect:
•Rate—Speed, in kilobits per second.
–Always MAX rate possible for aggregate reservations.
•Max. burst—Largest amount of data allowed, in kilobytes.
–Always MAX burst possible for aggregate reservations.
•Min Policed Unit—Size, in bytes, of the smallest packet generated by the application, including the application data and all protocol headers at or above the IP level.
•Max Pkt Size—Largest packet allowed, in bytes.
|
PATH ID handle
|
Internal database ID assigned to the PATH message by RSVP for bookkeeping purposes.
|
Incoming policy
|
State of the incoming policy:
•Accepted—RSVP PATH messages are being accepted, but not forwarded.
•Not Accepted—RSVP PATH messages are being rejected.
|
Policy source(s)
|
Type of local policy in effect; values include Default, Local, and MPLS/TE.
|
Status
|
Status of the local policy:
•Proxied—Head.
•Proxy-terminated—Tail.
•Blockaded—Tail or midpoint and an RESVERROR message has recently been received; therefore, the PSB enters the blockaded state.
Note A blank field means none of the above.
|
3175 Aggregation: agg_info
|
IP address of the aggregated reservation on which this E2E reservation is mapped with specified source (aggregator) and destination (deaggregator) endpoints and DSCP.
|
Output on interface
|
Policy status (on the outbound interface):
•Forwarding—Inbound PATH messages are being forwarded.
•Not Forwarding—Outbound PATH messages are being rejected.
•Handle—Internal database ID assigned to the PATH message by RSVP for bookkeeping purposes.
|
Policy source(s)
|
Type of local policy in effect; values include Default, Local, and MPLS/TE.
|
Path FLR
|
Never repaired—Indicates that the node has never been a point of local repair (PLR) and, therefore, has never repaired the PSB.
|
PATH
|
PATH message information for aggregate reservations:
•Deaggregator IP address.
•Differentiated Services Code Point (DSCP) value.
•Policing.
–Always Don't Police.
•Aggregator IP address.
Note Remaining parameters are defined in the preceding fields.
|
PLR and MP Examples
The following is sample output from the show ip rsvp sender detail command under these circumstances:
•The command is entered at the point of local repair (PLR) before a failure (Example 1).
•The command is entered at the PLR after a failure (Example 2).
•The command is entered at the merge point (MP) before a failure (Example 3).
•The command is entered at the MP after a failure (Example 4).
•The command output shows all senders (Example 5).
•The command output shows only senders who have a specific destination (Example 6).
•Show more detail about a sender who has a specific destination (Example 7).
Figure 3 illustrates the network topology for the RSVP configuration example.
Figure 3 Network Topology for the RSVP Configuration Example
Example 1: The command is entered at the PLR before a failure.
The following is sample output from the show ip rsvp sender detail command when it is entered at the PLR before a failure:
Router# show ip rsvp sender detail
Tun Dest: 10.2.2.1 Tun ID: 1 Ext Tun ID: 10.2.2.0
Tun Sender: 10.2.2.0, LSP ID: 126
Path refreshes arriving on POS1/0 from PHOP 10.1.1.1
Path refreshes being sent to NHOP 10.1.1.4 on POS1/1
Setup Prio: 0, Holding Prio: 0
Flags: Local Prot desired, Label Recording, SE Style
Session Name:tagsw4500-23_t1
10.1.1.4 (Strict IPv4 Prefix, 8 bytes, /32)
10.1.1.5 (Strict IPv4 Prefix, 8 bytes, /32)
10.1.1.6 (Strict IPv4 Prefix, 8 bytes, /32)
10.2.2.1 (Strict IPv4 Prefix, 8 bytes, /32)
Traffic params - Rate: 0G bits/sec, Max. burst: 1K bytes
Fast-Reroute Backup info:
Outbound FRR: Ready -- backup tunnel selected
Backup Tunnel: Tu2 (label 0)
Tun Sender: 10.0.0.0, LSP ID: 126
Tun Sender: 10.0.0.0, LSP ID 126
Table 106 describes the significant fields shown in the display.
Note The Flags field is important for Fast Reroute. For information about flags that must be set, see the Flags field description in Table 106.
Table 106 show ip rsvp sender detail Field Descriptions—on PLR Before Failure
Field
|
Description
|
The first five fields provide information that uniquely identifies the LSP.
The first three fields identify the LSP's session (that is, the contents of the SESSION object in arriving PATH messages).
|
Tun Dest
|
IP address of the destination of the tunnel.
|
Tun ID
|
Tunnel identification number.
|
Ext Tun ID
|
Extended tunnel identification number.
|
The next two fields identify the LSP's sender (SENDER_TEMPLATE object of arriving PATH messages).
|
Tun Sender
|
Tunnel sender.
|
LSP ID
|
LSP identification number.
|
The remaining fields indented under PATH provide additional information about this LSP.
|
Session Attr—Session attributes. Refers to information included in the SESSION_ATTRIBUTE object of arriving PATH messages, such as the Setup and Holding Priorities, Flags, and the Session Name.
|
Setup Prio
|
Setup priority.
|
Holding Prio
|
Holding priority.
|
Flags
|
An LSP must have the "Local protection desired" flag of the SESSION_ATTRIBUTE object set for the LSP to use a backup tunnel (that is, in order to receive local protection). If this flag is not set, you have not enabled Fast Reroute for this tunnel at its headend (by entering the tunnel mpls traffic-eng fast-reroute command). Next-next hop (NNHOP) backup tunnels rely on label recording, so LSPs should have the "label recording desired" flag set too. This flag is set if the tunnel was configured for Fast Reroute.
|
ERO—Refers to the EXPLICIT_ROUTE Object (ERO) of the PATH messages. This field displays the contents of the ERO at this node. As a PATH message travels from the sender (headend) to the receiver (tailend), each node removes its own IP address from the ERO. The displayed value reflects the remainder of hops between this node and the tail.
|
Fast-Reroute Backup info—Information that is relevant to Fast Reroute for this LSP.
|
Inbound FRR
|
If this node is downstream from a rerouted LSP (for example, at a merge point for this LSP), the state is Active.
|
Outbound FRR
|
If this node is a PLR for an LSP, there are three possible states:
•Active—This LSP is actively using its backup tunnel, presumably because there has been a downstream failure.
•No Backup—This LSP does not have local (Fast Reroute) protection. No backup tunnel has been selected for it to use in case of a failure.
•Ready—This LSP is ready to use a backup tunnel in case of a downstream link or node failure. A backup tunnel has been selected for it to use.
|
Backup Tunnel
|
If the Outbound FRR state is Ready or Active, this field indicates the following:
•Which backup tunnel has been selected for this LSP to use in case of a failure.
•The inbound label that will be prepended to the LSP's data packets for acceptance at the backup tunnel tail (the merge point).
|
Bkup Sender Template
|
If the Outbound FRR state is Ready or Active, SENDER_TEMPLATE and FILTERSPEC objects are shown. These objects will be used in RSVP messages sent by the backup tunnel if the LSP starts actively using the backup tunnel. They differ from the original (prefailure) objects only in that the node (the PLR) substitutes its own IP address for that of the original sender. For example, PATH and PATHTEAR messages will contain the new SENDER_TEMPLATE. RESV and RESVTEAR messages will contain the new FILTERSPEC object. If this LSP begins actively using the backup tunnel, the display changes.
|
Bkup FilerSpec
|
If the Outbound FRR state is Ready or Active, SENDER_TEMPLATE and FILTERSPEC objects are shown. These objects will be used in RSVP messages sent by the backup tunnel if the LSP starts actively using the backup tunnel. They differ from the original (prefailure) objects only in that the node (the PLR) substitutes its own IP address for that of the original sender. For example, PATH and PATHTEAR messages will contain the new SENDER_TEMPLATE. RESV and RESVTEAR messages will contain the new FILTERSPEC object. If this LSP begins actively using the backup tunnel, the display changes as shown in Example 2.
|
Example 2: The command is entered at the PLR after a failure.
If the LSP begins actively using the backup tunnel and the command is entered at the PLR after a failure, the display changes as shown below.
Router# show ip rsvp sender detail
Tun Dest: 10.2.2.1 Tun ID: 1 Ext Tun ID: 10.2.2.0
Tun Sender: 10.2.2.0, LSP ID: 126
Path refreshes arriving on POS1/0 from PHOP 10.1.1.1
Path refreshes being sent to NHOP 10.2.2.1 on Tunnel2
Setup Prio: 0, Holding Prio: 0
Flags: Local Prot desired, Label Recording, SE Style
Session Name:tagsw4500-23_t1
10.2.2.1 (Strict IPv4 Prefix, 8 bytes, /32)
10.2.2.1 (Strict IPv4 Prefix, 8 bytes, /32)
Traffic params - Rate: 0G bits/sec, Max. burst: 1K bytes
Fast-Reroute Backup info:
Outbound FRR: Active -- using backup tunnel
Backup Tunnel: Tu2 (label 0)
Tun Sender: 10.0.0.0, LSP ID: 126
Tun Sender: 10.0.0.0, LSP ID 126
10.1.1.4 (Strict IPv4 Prefix, 8 bytes, /32)
10.1.1.5 (Strict IPv4 Prefix, 8 bytes, /32)
10.1.1.6 (Strict IPv4 Prefix, 8 bytes, /32)
10.2.2.1 (Strict IPv4 Prefix, 8 bytes, /32)
Once an LSP is actively using a backup tunnel, the following changes occur:
•PATH refreshes are no longer sent to the original NHOP out the original interface. They are sent through the backup tunnel to the node that is the tail of the backup tunnel (NHOP or NNHOP).
•The ERO is modified so that it will be acceptable upon arrival at the NHOP or NNHOP.
•The display shows both the original ERO and the new one that is now being used.
•The display shows the original output interface (that is, the interface from which PATH messages were sent for this LSP before the failure).
Example 3: The command is entered at the MP before a failure.
If the same show ip rsvp sender command is entered at the merge point (the backup tunnel tail), the display changes from before to after the failure. The following is sample output before a failure:
Router# show ip rsvp sender detail
Tun Dest: 10.2.2.1 Tun ID: 1 Ext Tun ID: 10.2.2.0
Tun Sender: 10.2.2.0, LSP ID: 126
Path refreshes arriving on POS0/0 from PHOP 10.1.1.5
Setup Prio: 0, Holding Prio: 0
Flags: Local Prot desired, Label Recording, SE Style
Session Name:tagsw4500-23_t1
Traffic params - Rate: 0G bits/sec, Max. burst: 1K bytes
Fast-Reroute Backup info:
Outbound FRR: No backup tunnel selected
Example 4: The command is entered at the MP after a failure.
After a failure, the following changes occur:
•The interface and previous hop (PHOP) from which PATH messages are received will change.
•The inbound FRR becomes Active.
•The original PHOP and the original input interface are displayed as shown below.
The following is sample output after a failure:
Router# show ip rsvp sender detail
Tun Dest: 10.2.2.1 Tun ID: 1 Ext Tun ID: 10.2.2.0
Tun Sender: 10.2.2.0, LSP ID: 126
Path refreshes arriving on POS0/1 from PHOP 10.0.0.0 on Loopback0
Setup Prio: 0, Holding Prio: 0
Flags: Local Prot desired, Label Recording, SE Style
Session Name:tagsw4500-23_t1
Traffic params - Rate: 0G bits/sec, Max. burst: 1K bytes
Fast-Reroute Backup info:
Now using Bkup Filterspec w/ sender: 10.0.0.0 LSP ID: 126
Outbound FRR: No backup tunnel selected
Notice the following changes:
•After a failure, PATH refreshes arrive on a different interface and from a different PHOP.
•The original PHOP and input interface are shown under Fast-Reroute Backup information, along with the FILTERSPEC object that will now be used when sending messages (such as RESV and RESVTEAR).
Example 5: The command output shows all senders.
In the following example, information about all senders is displayed.
Router# show ip rsvp sender
To From Pro DPort Sport Prev Hop I/F BPS Bytes
10.2.2.1 10.2.2.0 1 1 59 10.1.1.1 Et1 0G 1K
10.2.2.1 172.31.255.255 1 2 9 0G 1K
10.2.2.1 10.2.2.0 1 3 12 10.1.1.1 Et1 0G 1K
10.2.2.1 172.31.255.255 1 3 20 0G 1K
172.16.0.0 172.31.255.255 1 0 23 0G 1K
172.16.0.0 172.31.255.255 1 1 22 0G 1K
172.16.0.0 172.31.255.255 1 1000 22 0G 1K
Table 107 describes the significant fields shown in the display.
Table 107 show ip rsvp sender Field Descriptions
Field
|
Description
|
To
|
IP address of the receiver.
|
From
|
IP address of the sender.
|
Pro
|
Protocol code. Code 1 indicates Internet Control Message Protocol (ICMP).
|
DPort
|
Destination port number.
|
Sport
|
Source port number.
|
Prev Hop
|
IP address of the previous hop.
|
I/F
|
Interface of the previous hop.
|
BPS
|
Reservation rate, in bits per second, that the application is advertising it might achieve.
|
Bytes
|
Bytes of burst size that the application is advertising it might achieve.
|
Example 6: The command output shows only senders having a specific destination.
To show only information about senders having a specific destination, specify the destination filter as shown below. In this example, the destination is 172.16.0.0.
Router# show ip rsvp sender filter destination 172.16.0.0
To From Pro DPort Sport Prev Hop I/F BPS Bytes
172.16.0.0 172.31.255 1 0 23 0G 1K
172.16.0.0 172.31.255 1 1 22 0G 1K
172.16.0.0 172.31.255 1 1000 22 0G 1K
Example 7: Show more detail about a sender having a specific destination.
To show more detail about the sender whose destination port is 1000 (as shown in Example 6), specify the command with the destination port filter:
Router# show ip rsvp sender filter detail dst-port 1000
Tun Dest 172.16.0.0 Tun ID 1000 Ext Tun ID 172.31.255.255
Tun Sender: 172.31.255.255, LSP ID: 22
Path refreshes being sent to NHOP 10.1.1.4 on Ethernet2
Setup Prio: 7, Holding Prio: 7
Session Name:tagsw4500-25_t1000
10.1.1.4 (Strict IPv4 Prefix, 8 bytes, /32)
172.16.0.0 (Strict IPv4 Prefix, 8 bytes, /32)
Traffic params - Rate: 0G bits/sec, Max. burst: 1K bytes
Fast-Reroute Backup info:
Outbound FRR: No backup tunnel selected
VRF Example
The following is sample output from the show ip rsvp sender vrf myvrf detail command showing all the senders associated with the VRF named myvrf:
Router# show ip rsvp sender vrf myvrf detail
Destination 10.10.10.21, Protocol_Id 17, Don't Police , DstPort 1
Sender address: 10.10.10.11, port: 1
Traffic params - Rate: 10K bits/sec, Max. burst: 10K bytes
Min Policed Unit: 0 bytes, Max Pkt Size 2147483647 bytes
Path ID handle: 0F000406.
Incoming policy: Accepted. Policy source(s): Default
Output on Serial2/0. Policy status: Forwarding. Handle: 09000405
Policy source(s): Default
Table 108 describes the significant fields shown in the display.
Table 108 show ip rsvp sender detail Field Descriptions—with VRF
Field
|
Descriptions
|
PATH
|
PATH message information for E2E reservations:
•Destination IP address.
•Protocol ID number.
•Policing.
–Always Don't Police.
•Destination port number.
|
Sender address
|
Source IP address of the PATH message.
•port—Number of the source port.
|
Path refreshes
|
Refresh information:
•IP address of the source (previous hop [PHOP]).
•Interface name and number.
•Frequency, in milliseconds (msec).
Note A blank field means no refreshes have occurred.
|
Traffic params
|
Traffic parameters in effect:
•Rate—Speed, in kilobits per second.
–Always MAX rate possible for aggregate reservations.
•Max. burst—Largest amount of data allowed, in kilobytes.
–Always MAX burst possible for aggregate reservations.
•Min Policed Unit—Size, in bytes, of the smallest packet generated by the application, including the application data and all protocol headers at or above the IP level.
•Max Pkt Size—Largest packet allowed, in bytes.
|
PATH ID handle
|
Internal database ID assigned to the PATH message by RSVP for bookkeeping purposes.
|
Incoming policy
|
State of the incoming policy:
•Accepted—RSVP PATH messages are being accepted, but not forwarded.
•Not Accepted—RSVP PATH messages are being rejected.
|
Policy source(s)
|
Type of local policy in effect; values include Default, Local, and MPLS/TE.
|
Status
|
Status of the local policy:
•Proxied—Head.
•Proxy-terminated—Tail.
•Blockaded—Tail or midpoint and an RESVERROR message has recently been received; therefore, the PSB enters the blockaded state.
Note A blank field means none of the above.
|
Output on interface
|
Policy status (on the outbound interface):
•Forwarding—Inbound PATH messages are being forwarded.
•Not Forwarding—Outbound PATH messages are being rejected.
•Handle—Internal database ID assigned to the PATH message by RSVP for bookkeeping purposes.
|
Policy source(s)
|
Type of local policy in effect; values include Default, Local, and MPLS/TE.
|
Path FLR
|
Never repaired—Indicates that the node has never been a point of local repair (PLR) and, therefore, has never repaired the PSB.
|
VRF
|
Name of the VRF for which senders are displayed.
|
MPLS Traffic Engineering Point-to-Multipoint Examples
The following is sample output from the show ip rsvp sender detail command, which shows point-to-multipoint information:
Router# show ip rsvp sender detail
P2MP ID: 22 Tun ID: 22 Ext Tun ID: 10.1.1.201
Tun Sender: 10.1.1.201 LSP ID: 1 SubGroup Orig: 10.1.1.201
S2L Destination : 10.1.1.203
sent: to NHOP 10.0.0.205 on Ethernet0/0
Setup Prio: 7, Holding Prio: 7
Flags: (0xF) Local Prot desired, Label Recording, SE Style, Bandwidth Prot desired
10.1.1.201 (Strict IPv4 Prefix, 8 bytes, /32)
10.0.0.201 (Strict IPv4 Prefix, 8 bytes, /32)
10.0.0.205 (Strict IPv4 Prefix, 8 bytes, /32)
10.1.1.205 (Strict IPv4 Prefix, 8 bytes, /32)
10.1.1.202 (Strict IPv4 Prefix, 8 bytes, /32)
10.1.0.202 (Strict IPv4 Prefix, 8 bytes, /32)
10.1.0.203 (Strict IPv4 Prefix, 8 bytes, /32)
10.1.1.203 (Strict IPv4 Prefix, 8 bytes, /32)
10.0.0.205 (Strict IPv4 Prefix, 8 bytes, /32)
10.1.1.205 (Strict IPv4 Prefix, 8 bytes, /32)
10.1.1.202 (Strict IPv4 Prefix, 8 bytes, /32)
10.1.0.202 (Strict IPv4 Prefix, 8 bytes, /32)
10.1.0.203 (Strict IPv4 Prefix, 8 bytes, /32)
10.1.1.203 (Strict IPv4 Prefix, 8 bytes, /32)
Traffic params - Rate: 500K bits/sec, Max. burst: 1K bytes
Min Policed Unit: 1 bytes, Max Pkt Size 2147483647 bytes
Fast-Reroute Backup info:
Outbound FRR: Ready -- backup tunnel selected
Backup Tunnel: Tu666 (label 20)
Tun Sender: 10.0.2.201 LSP ID: 1 SubGroup Orig: 10.1.1.201
Tun Sender: 10.0.2.201, LSP ID: 1, SubGroup Orig: 10.1.1.201
Path ID handle: 01000414.
Incoming policy: Accepted. Policy source(s): MPLS/TE
Output on Ethernet0/0. Policy status: Forwarding. Handle: 02000413
Policy source(s): MPLS/TE
Table 109 describes the significant fields shown in the display.
Table 109 show ip rsvp sender—MPLS TE P2MP Field Descriptions
Field
|
Description
|
P2MP ID
|
A 32-bit number that identifies the set of destinations of the P2MP tunnel.
|
Tun ID
|
Tunnel identification number.
|
Ext Tun ID
|
Extended tunnel identification number.
|
Tun Sender
|
IP address of the sender.
|
LSP ID
|
Label switched path identification number.
|
SubGroup Orig
|
LSP headend router ID address.
|
SubGroup ID
|
An incremental number assigned to each sub-LSP signaled from the headend router.
|
S2L Destination
|
LSP tailend router ID address.
|
The following is sample output from the show ip rsvp sender filter session-type 13 command, which shows RSVP RESV requests for point-to-multipoint traffic:
Router# show ip rsvp sender filter session-type 13
Session Type 13 (te-p2mp-lsp)
Destination Tun Sender TunID LSPID P2MP-ID SubID I/F BPS
10.1.1.203 10.1.1.201 22 1 22 1 none 500K
10.1.1.206 10.1.1.201 22 1 22 2 none 500K
10.1.1.213 10.1.1.201 22 1 22 3 none 500K
10.1.1.214 10.1.1.201 22 1 22 4 none 500K
10.1.1.216 10.1.1.201 22 1 22 5 none 500K
10.1.1.217 10.1.1.201 22 1 22 6 none 500K
Related Commands
Command
|
Description
|
ip rsvp sender
|
Enables a router to simulate RSVP PATH message reception from the sender.
|
show ip rsvp reservation
|
Displays RSVP PATH-related receiver information currently in the database.
|
show isis nsf
To display current state information regarding Intermediate System-to-Intermediate System (IS-IS) Cisco nonstop forwarding (NSF), use the show isis nsf command in user EXEC mode.
show isis nsf
Syntax Description
This command has no arguments or keywords.
Command Modes
User EXEC
Command History
Release
|
Modification
|
12.0(22)S
|
This command was introduced.
|
12.2(18)S
|
This command was integrated into Cisco IOS Release 12.2(18)S.
|
12.2(20)S
|
Support for the Cisco 7304 router was added.
|
12.2(28)SB
|
This command was integrated into Cisco IOS Release 12.2(28)SB.
|
12.2(33)SRA
|
This command was integrated into Cisco IOS Release 12.2(33)SRA.
|
12.2(33)SXH
|
This command was integrated into Cisco IOS Release 12.2(33)SXH.
|
Usage Guidelines
The show isis nsf command can be used with both Cisco proprietary IS-IS NSF and Internet Engineering Task Force (IETF) IS-IS NSF. The information displayed when this command is entered depends on which protocol has been configured. To configure nsf for a specific routing protocol, use the router bgp, router ospf, or router isis commands in global configuration mode.
Examples
The following example shows state information for an active RP that is configured to use Cisco proprietary IS-IS NSF:
NSF enabled, mode 'cisco'
RP is ACTIVE, standby ready, bulk sync complete
NSF interval timer expired (NSF restart enabled)
Checkpointing enabled, no errors
Local state:ACTIVE, Peer state:STANDBY HOT, Mode:SSO
Table 110 describes the significant fields shown in the display.
Table 110 show isis nsf Field Descriptions
Field
|
Description
|
NSF enabled, mode 'cisco'
|
NSF is enabled in the default cisco mode.
|
RP is ACTIVE, standby ready, bulk sync complete
|
Status of the active RP, standby RP, and the synchronization process between the two.
|
NSF interval timer expired (NSF restart enabled)
|
NSF interval timer has expired, allowing NSF restart to be active.
|
Checkpointing enabled, no errors
|
Status of the checkpointing process.
|
Local state:ACTIVE, Peer state:STANDBY HOT, Mode:SSO
|
State of the local RP, the peer RP, and the operating mode these RPs are using.
|
The following example shows state information for a standby RP that is configured to use Cisco proprietary IS-IS NSF:
NSF enabled, mode 'cisco'
RP is STANDBY, chkpt msg receive count:ADJ 2, LSP 314
NSF interval timer notification received (NSF restart enabled)
Checkpointing enabled, no errors
Local state:STANDBY HOT, Peer state:ACTIVE, Mode:SSO
The following example shows state information when the networking device is configured to use IETF IS-IS NSF:
NSF is ENABLED, mode IETF
NSF L1 active interfaces:0
NSF interfaces awaiting L1 CSNP:0
NSF L2 active interfaces:0
NSF interfaces awaiting L2 CSNP:0
NSF L1 Restart state:Running
NSF p2p Restart retransmissions:0
Maximum L1 NSF Restart retransmissions:3
L1 NSF ACK requested:FALSE
L1 NSF CSNP requested:FALSE
NSF L2 Restart state:Running
NSF p2p Restart retransmissions:0
Maximum L2 NSF Restart retransmissions:3
L2 NSF ACK requested:FALSE
Interface:GigabitEthernet2/0/0
NSF L1 Restart state:Running
NSF L1 Restart retransmissions:0
Maximum L1 NSF Restart retransmissions:3
L1 NSF ACK requested:FALSE
L1 NSF CSNP requested:FALSE
NSF L2 Restart state:Running
NSF L2 Restart retransmissions:0
Maximum L2 NSF Restart retransmissions:3
L2 NSF ACK requested:FALSE
L2 NSF CSNP requested:FALSE
Related Commands
Command
|
Description
|
debug isis nsf
|
Displays information about the IS-IS state during an NSF restart.
|
nsf (IS-IS)
|
Configures NSF operations for IS-IS.
|
nsf t3
|
Specifies the methodology used to determine how long IETF NSF will wait for the LSP database to synchronize before generating overloaded link state information for itself and flooding that information out to its neighbors.
|
nsf interface wait
|
Specifies how long a NSF restart will wait for all interfaces with IS-IS adjacencies to come up before completing the restart.
|
nsf interval
|
Specifies the minimum time between NSF restart attempts.
|
show clns neighbors
|
Displays both ES and IS neighbors.
|
show issu
To display Enhanced Fast Software Upgrade (eFSU) information, use the show issu command.
show issu {outage slot {all | num} | patch context | patch type image | platform states}
Syntax Description
outage slot all
|
Displays an average estimate of the traffic outage for all slots during the upgrade or downgrade.
|
outage slot num
|
Displays an average estimate of the traffic outage to expect per a specific slot during the upgrade/downgrade.
|
patch context
|
Displays the patch context during the patch installation and activation.
|
patch type image
|
Displays patch information about the image that you are about to upgrade to.
|
platform states
|
Displays the state of the platform specific eSFU data.
|
Command Default
None
Command Modes
User EXEC (>)
Privileged EXEC (#)
Command History
Release
|
Modification
|
12.2(33)SXI
|
Support for this command was introduced.
|
Examples
The following example shows how to display an average estimate of the traffic outage for all slots during the upgrade or downgrade:
Router# show issu outage slot all
Slot # Card Type MDR Mode Max Outage Time
------ ------------------------------------- ----------- ---------------
1 CEF720 24 port 1000mb SFP WARM_RELOAD 300 secs
2 1-subslot SPA Interface Processor-600 WARM_RELOAD 300 secs
3 4-subslot SPA Interface Processor-400 WARM_RELOAD 300 secs
4 2+4 port GE-WAN RELOAD 360 secs
Related Commands
Command
|
Description
|
issu
|
Sets up an Enhanced Fast Software Upgrade (eFSU).
|
show issu clients
To display a list of the current In Service Software Upgrade (ISSU) clients—that is, the network applications and protocols supported by ISSU—use the show issu clients command in user EXEC or privileged EXEC mode.
show issu clients
Syntax Description
This command has no arguments or keywords.
Command Modes
User EXEC (>)
Privileged EXEC (#)
Command History
Release
|
Modification
|
12.2(28)SB
|
This command was introduced.
|
12.2(33)SRB1
|
ISSU is supported on the Cisco 7600 series routers in Cisco IOS Release 12.2(33)SRB1.
|
12.2(33)SRE
|
This command was integrated into Cisco IOS Release 12.2(33)SRE.
|
Usage Guidelines
This command lists all ISSU clients currently operating in the network, along with their Client ID numbers and the number of entities each client contains.
You should enter this command before you enter the issu runversion command, because if a client (application or protocol) that needs to continue operating in the network does not appear in the displayed list, you will know not to continue the software upgrade (because proceeding further with ISSU would then halt the operation of that application or protocol).
Examples
The following example shows a client list displayed by entering this command:
Router# show issu clients
Client_ID = 2, Client_Name = ISSU Proto client, Entity_Count = 1
Client_ID = 3, Client_Name = ISSU RF, Entity_Count = 1
Client_ID = 4, Client_Name = ISSU CF client, Entity_Count = 1
Client_ID = 5, Client_Name = ISSU Network RF client, Entity_Count = 1
Client_ID = 7, Client_Name = ISSU CONFIG SYNC, Entity_Count = 1
Client_ID = 8, Client_Name = ISSU ifIndex sync, Entity_Count = 1
Client_ID = 9, Client_Name = ISSU IPC client, Entity_Count = 1
Client_ID = 10, Client_Name = ISSU IPC Server client, Entity_Count = 1
Client_ID = 11, Client_Name = ISSU Red Mode Client, Entity_Count = 1
Client_ID = 12, Client_Name = ISSU EHSA services client, Entity_Count = 1
Client_ID = 100, Client_Name = ISSU rfs client, Entity_Count = 1
Client_ID = 110, Client_Name = ISSU ifs client, Entity_Count = 1
Client_ID = 1001, Client_Name = OC3POS-6, Entity_Count = 4
Client_ID = 1002, Client_Name = C10K ATM, Entity_Count = 1
Client_ID = 1003, Client_Name = C10K CHSTM1, Entity_Count = 1
Client_ID = 1004, Client_Name = C10K CT3, Entity_Count = 1
Client_ID = 1005, Client_Name = C10K GE, Entity_Count = 1
Client_ID = 1006, Client_Name = C10K ET, Entity_Count = 1
Client_ID = 1007, Client_Name = C10K CHE1T1, Entity_Count = 1
Client_ID = 1009, Client_Name = C10K MFE, Entity_Count = 1
Client_ID = 1010, Client_Name = C10K APS, Entity_Count = 1
Client_ID = 1013, Client_Name = C10K CARD OIR, Entity_Count = 1
Client_ID = 2002, Client_Name = CEF Push ISSU client, Entity_Count = 1
Client_ID = 2003, Client_Name = ISSU XDR client, Entity_Count = 1
Client_ID = 2004, Client_Name = ISSU SNMP client, Entity_Count = 1
Client_ID = 2005, Client_Name = ISSU HDLC Client, Entity_Count = 1
Client_ID = 2006, Client_Name = ISSU QoS client, Entity_Count = 1
Client_ID = 2007, Client_Name = ISSU LSD Label Mgr HA Client, Entity_Count = 1
Client_ID = 2008, Client_Name = ISSU Tableid Client, Entity_Count = 1
Client_ID = 2009, Client_Name = ISSU MPLS VPN Client, Entity_Count = 1
Client_ID = 2010, Client_Name = ARP HA, Entity_Count = 1
Client_ID = 2011, Client_Name = ISSU LDP Client, Entity_Count = 1
Client_ID = 2012, Client_Name = ISSU HSRP Client, Entity_Count = 1
Client_ID = 2013, Client_Name = ISSU ATM Client, Entity_Count = 1
Client_ID = 2014, Client_Name = ISSU FR Client, Entity_Count = 1
Client_ID = 2015, Client_Name = ISSU REDSSOC client, Entity_Count = 1
Client_ID = 2019, Client_Name = ISSU TCP client, Entity_Count = 1
Client_ID = 2020, Client_Name = ISSU BGP client, Entity_Count = 1
Client_ID = 2021, Client_Name = XDR Int Priority ISSU client, Entity_Count = 1
Client_ID = 2022, Client_Name = XDR Proc Priority ISSU client, Entity_Count = 1
Client_ID = 2023, Client_Name = FIB HWIDB ISSU client, Entity_Count = 1
Client_ID = 2024, Client_Name = FIB IDB ISSU client, Entity_Count = 1
Client_ID = 2025, Client_Name = FIB HW subblock ISSU client, Entity_Count = 1
Client_ID = 2026, Client_Name = FIB SW subblock ISSU client, Entity_Count = 1
Client_ID = 2027, Client_Name = Adjacency ISSU client, Entity_Count = 1
Client_ID = 2028, Client_Name = FIB IPV4 ISSU client, Entity_Count = 1
Client_ID = 2030, Client_Name = MFI Pull ISSU client, Entity_Count = 1
Client_ID = 2031, Client_Name = MFI Push ISSU client, Entity_Count = 1
Client_ID = 2051, Client_Name = ISSU CCM Client, Entity_Count = 1
Client_ID = 2052, Client_Name = ISSU PPP SIP CCM Client, Entity_Count = 1
Client_ID = 2054, Client_Name = ISSU process client, Entity_Count = 1
Client_Name = ISSU Proto client
Client_Name = ISSU CF client
Client_Name = ISSU Network RF client
Client_Name = ISSU CONFIG SYNC
Client_Name = ISSU ifIndex sync
Client_Name = ISSU IPC client
Client_Name = ISSU IPC Server client
Client_Name = ISSU Red Mode Client
Client_Name = ISSU EHSA services client
Table 110 describes the significant fields shown in the display.
Table 111 show issu clients Field Descriptions
Field
|
Description
|
Client_ID
|
The identification number used by ISSU for that client.
|
Client_Name
|
A character string describing the client.
"Base Clients" are a subset, which includes:
•Inter-Process Communications (IPC)
•Redundancy Framework (RF)
•Checkpoint Facility (CF)
•Cisco Express Forwarding
•Network RF (for IDB stateful switchover)
•EHSA Services (including ifIndex)
•Configuration Synchronization.
|
Entity_Count
|
The number of entities within this client. An entity is a logical group of sessions with some common attributes.
|
Related Commands
Command
|
Description
|
show issu message types
|
Displays the formats, versions, and size of ISSU messages supported by a particular client.
|
show issu negotiated
|
Displays results of a negotiation that occurred concerning message versions or client capabilities.
|
show issu sessions
|
Displays detailed information about a particular ISSU client, including whether the client status is compatible for the impending software upgrade.
|
show issu comp-matrix
To display information regarding the In Service Software Upgrade (ISSU) compatibility matrix, use the show issu comp-matrix command in user EXEC or privileged EXEC mode.
show issu comp-matrix {negotiated | stored}
Syntax Description
negotiated
|
Displays negotiated matrix information.
|
stored
|
Displays stored matrix information.
|
Command Modes
User EXEC (>)
Privileged EXEC (#)
Command History
Release
|
Modification
|
12.2(28)SB
|
This command was introduced.
|
12.2(31)SGA
|
This command was integrated into Cisco IOS Release 12.2(31)SGA.
|
12.2(33)SRB1
|
ISSU is supported on the Cisco 7600 series routers in Cisco IOS Release 12.2(33)SRB1.
|
12.2(33)SRE
|
This command was integrated into Cisco IOS Release 12.2(33)SRE.
|
Usage Guidelines
Before attempting an ISSU, you should know the compatibility level between the Cisco IOS software versions on the active and the standby Route Processors (RPs). ISSU will not work if the two versions are incompatible. Use the show issu comp-matrix command with the negotiated keyword to display information on the negotiation of the compatibility matrix data between two software versions on a given system.
Compatibility matrix data is stored with each Cisco IOS software image that supports the ISSU capability. Use the show issu comp-matrix command with the stored keyword to display stored compatibility matrix information.
Examples
The following example shows how to display stored compatibility matrix information:
Router# show issu comp-matrix stored
show issu entities
To display information about entities within one or more In Service Software Upgrade (ISSU) clients, use the show issu entities command in user EXEC or privileged EXEC mode.
show issu entities [client-id]
Syntax Description
client-id
|
(Optional) The identification number of a single ISSU client.
|
Command Modes
User EXEC
Privileged EXEC
Command History
Release
|
Modification
|
| |
This command was introduced.
|
12.2(33)SRB1
|
ISSU is supported on the Cisco 7600 series routers in Cisco IOS Release 12.2(33)SRB1.
|
Usage Guidelines
An entity is a logical group of sessions that possess some common attributes. Enter a Client_ID if you are interested in seeing information only about one client's entities. If a Client_ID is not specified, the command will display all ISSU clients' entities known to the device.
If you are not sure of the precise Client_ID number to enter for the client you are interested in, use the show issu clients command to display the current list of clients with their names and ID numbers.
Examples
The following example shows detailed information about the entities within the virtual routing and forwarding (VRF) ("Table ID") client:
Router# show issu entities 2008
Entity_ID = 1, Entity_Name = Tableid Entity :
MsgType MsgGroup CapType CapEntry CapGroup
Count Count Count count Count
Table 112 describes the significant field shown in the display.
Table 112 show issu entities Field Descriptions
Field
|
Description
|
Client_ID
|
The identification number used by ISSU for the specified client.
|
Entity_ID
|
The identification number used by ISSU for each entity within this client.
|
Entity_Name
|
A character string describing the entity.
|
MsgType Count
|
The number of message types within the identified entity.
|
MsgGroup Count
|
The number of message groups within the identified entity. A message group is a list of message types.
|
CapType Count
|
The number of capability types within the identified entity.
|
CapEntry Count
|
The number of capability entries within the identified entity. A capability entry is a list of all mutually dependent capability types within a particular client session and, optionally, other capability types belonging to that client session.
|
CapGroup Count
|
The number of capability groups within the identified entity. A capability group is a list of capability entries given in priority sequence.
|
Related Commands
Command
|
Description
|
show issu clients
|
Lists the current ISSU clients—that is, the applications and protocols on this network supported by ISSU.
|
show issu sessions
|
Displays detailed information about a particular ISSU client—including whether the client status for the impending software upgrade is COMPATIBLE.
|
show issu message types
To display formats ("types"), versions, and maximum packet size of the In Service Software Upgrade (ISSU) messages supported by a particular client, use the show issu message types command in user EXEC or privileged EXEC mode.
show issu message types client-id
Syntax Description
client-id
|
The identification number used by ISSU for a client application.
|
Command Modes
User EXEC
Privileged EXEC
Command History
Release
|
Modification
|
| |
This command was introduced.
|
12.2(33)SRB1
|
ISSU is supported on the Cisco 7600 series routers in Cisco IOS Release 12.2(33)SRB1.
|
Usage Guidelines
If you are not sure of the Client_ID number to enter into this command, use the show issu clients command. It displays the current list of clients, along with their names and ID numbers.
Examples
The following example displays the message type, version, and maximum message size supported by the Multiprotocol Label Switching (MPLS) Virtual Private Network (VPN) client:
Router# show issu message types 2009
Client_ID = 2009, Entity_ID = 1 :
Message_Type = 1, Version_Range = 1 ~ 1
Message_Ver = 1, Message_Mtu = 32
Table 113 describes the significant fields shown in the display.
Table 113 show issu message types Field Descriptions
Field
|
Description
|
Client_ID
|
The identification number used by ISSU for this client.
|
Entity_ID
|
The identification number used by ISSU for this entity.
|
Message_Type
|
An identification number that uniquely identifies the format used in the ISSU messages conveyed between the two endpoints.
|
Version_Range
|
The lowest and highest message-version numbers contained in the client application.
|
Message_Ver
|
Message version. Because each client application contains one or more versions of its messages, ISSU needs to discover these versions and negotiate between the new and old system software which version to use in its preparatory communications.
|
Message_Mtu
|
Maximum size (in bytes) of the transmitted message.
A value of 0 means there is no restriction on size; fragmentation and reassembly are therefore being handled in a manner transparent to the ISSU infrastructure.
|
Related Commands
Command
|
Description
|
show issu clients
|
Lists the current ISSU clients—that is, the applications on this network supported by ISSU.
|
show issu negotiated
|
Displays results of a negotiation that occurred concerning message versions or client capabilities.
|
show issu sessions
|
Displays detailed information about a particular ISSU client, including whether the client status is compatible for the impending software upgrade.
|
show issu negotiated
To display details of the session's negotiation about message version or client capabilities, use the show issu negotiated command in user EXEC or privileged EXEC mode.
show issu negotiated {version | capability} session-id
Syntax Description
version
|
Displays results of a negotiation about versions of the messages exchanged during the specified session, between the active and standby endpoints.
|
capability
|
Displays results of a negotiation about the client application's capabilities for the specified session.
|
session-id
|
The number used by In Service Software Upgrade (ISSU) to identify a particular communication session between the active and the standby devices.
|
Command Modes
User EXEC
Privileged EXEC
Command History
Release
|
Modification
|
| |
This command was introduced.
|
12.2(33)SRB1
|
ISSU is supported on the Cisco 7600 series routers in Cisco IOS Release 12.2(33)SRB1.
|
Usage Guidelines
If you are not sure of the session_ID number to enter into this command, enter the show issu sessions command. It will display the session_ID.
Examples
The following example displays the results of a negotiation about message versions:
router# show issu negotiated version 39
Message_Type = 1, Negotiated_Version = 1, Message_MTU = 32
Table 114 describes the significant fields shown in the display.
Table 114 show issu negotiated version Field Descriptions
Field
|
Description
|
Session_ID
|
The identification number of the session being reported on.
|
Message_Type
|
An identification number that uniquely identifies the format that was used by the ISSU messages conveyed between the two endpoints.
|
Negotiated_Version
|
The message version that was decided upon, for use during the software upgrade process.
|
Message_Mtu
|
Maximum size (in bytes) of the transmitted message.
A value of 0 means there is no restriction on size. In that case, fragmentation and reassembly are handled in a manner transparent to the ISSU infrastructure.
|
The following example displays the results of a negotiation about the client application's capabilities:
router# show issu negotiated capability 39
Table 115 describes the significant fields shown in the display.
Table 115 show issu negotiated capability Field Descriptions
Field
|
Description
|
Session_ID
|
The identification number of the session being reported on.
|
Negotiated_Cap_Entry
|
A numeral that stands for a list of the negotiated capabilities in the specified client session.
|
Related Commands
Command
|
Description
|
show issu clients
|
Lists the current ISSU clients—that is, the applications on this network supported by ISSU.
|
show issu message types
|
Displays the formats, versions, and maximum packet size of ISSU messages supported by a particular client.
|
show issu sessions
|
Displays detailed information about a particular ISSU client, including whether the client status is compatible for the impending software upgrade.
|
show issu outage
To display the maximum outage time for installed line cards during an in service software upgrade (ISSU), use the show issu outage command from the switch processor (SP) console.
show issu outage slot {slot-num | all}
Syntax Description
slot-num
|
Displays the maximum outage time for the line card in the specified slot.
|
all
|
Displays the maximum outage time for all installed line cards.
|
Command Modes
SP console
Command History
Release
|
Modification
|
12.2(33)SRB1
|
This command was introduced on Cisco 7600 series routers.
|
Usage Guidelines
Once the new software is downloaded onto the router (after you issue the issu loadversion command), you can issue show issu outage slot all from the SP console to display the maximum outage time for installed line cards.
During an ISSU, the router preloads line card software onto line cards that support enhanced Fast Service Upgrade (eFSU). Then, when the switchover occurs between active and standby processors, the line cards that support eFSU are restarted with the new, preloaded software, which helps to minimize outage time during the upgrade. Line cards that do not support eFSU undergo a hard reset at switchover, and the software image is loaded after the line card is restarted.
The output for the show issu outage command shows the type of reload that the line card will perform along with the maximum outage time (see the "Examples" section).
Note In the MDR Mode field of the command output, NSF_RELOAD indicates that the line card will not be reloaded, which means that outage time will be 0 to 3 seconds. NSF_RELOAD applies only to ISSU upgrades between two software releases that have the same line card software.
Examples
The following command examples show the maximum outage time for installed line cards:
Router# show issu outage slot all
Slot # Card Type MDR Mode Max Outage Time
------ ------------------------------------------- ----------- ---------------
1 CEF720 4 port 10-Gigabit Ethernet NSF_RELOAD 3 secs
2 FRU type (0x6003, 0x3F8(1016)) NSF_RELOAD 3 secs
3 4-subslot SPA Interface Processor-200 NSF_RELOAD 3 secs
Router# show issu outage slot all
Slot # Card Type MDR Mode Max Outage Time
------ ------------------------------------- ----------- ---------------
1 CEF720 24 port 1000mb SFP WARM_RELOAD 300 secs
2 1-subslot SPA Interface Processor-600 WARM_RELOAD 300 secs
3 4-subslot SPA Interface Processor-400 WARM_RELOAD 300 secs
4 2+4 port GE-WAN RELOAD 360 secs
Table 116 describes the fields in the display.
Table 116 show issu outage Field Descriptions
Field
|
Description
|
Slot
|
The chassis slot number in which the line card is installed.
|
Card Type
|
The type of line card installed in the slot.
|
MDR Mode
|
The type of software reload that the line card will perform after the ISSU switchover:
•NSF_RELOAD indicates that the line card will undergo an SSO/NSF type of switchover, which means that the line card will not be restarted or reloaded. This option applies only to ISSU upgrades between two software releases that have the same line card software.
•WARM_RELOAD indicates that software was preloaded onto the line card, but the line card must be restarted with the new software. This option is equivalent to a soft reset of the line card.
•RELOAD indicates that software was not preloaded onto the line card, which means that the line card will be reloaded. This option is equivalent to a hard reset of the line card.
•INVALID indicates that you entered the show issu outage command outside the ISSU command sequence.
|
Max Outage Time
|
The length of time the line card will be unavailable after it is restarted.
|
Related Commands
Command
|
Description
|
issu loadversion
|
Starts the ISSU process.
|
show issu patch
To provide information about upgrade installation on both active and standby routers, use the show issu patch command in privileged EXEC mode.
show issu patch {pending {disk} | context | type {image | patch}}
Syntax Description
pending
|
Provides information about the impact of a pending upgrade.
|
disk
|
The disk on which the upgrade will occur.
|
context
|
Provides information about the installation and upgrade during the upgrade procedure.
|
type
|
Provides information about the patch or image to which the system is being upgraded.
|
image
|
Provides information about the image to which the system is being upgraded.
|
patch
|
Provides information about the upgrade.
|
Command Default
No information about the upgrade is displayed.
Command Modes
Privileged EXEC
Command History
Release
|
Modification
|
12.2(33)SXI
|
This command was introduced.
|
Usage Guidelines
The show issu patch command provides an overview of the impact on a system upgrade before and during the upgrade procedure.
Examples
The following example provides information about a pending upgrade on disk0:
Router# show issu patch pending disk0:/sys
Overall Impact of the pending upgrade:
Type of upgrade: New base image
Slot # Card Type Impacted
------ ------------------------------------------- -----------
1 48 port 10/100 mb RJ-45 ethernet Yes
2 SFM-capable 16 port 1000mb GBIC Yes
3 48 port 10/100 mb RJ-45 ethernet Yes
4 CEF720 48 port 10/100/1000mb Ethernet Yes
8 CEF720 48 port 10/100/1000mb Ethernet Yes
9 Intrusion Detection System Yes
Table 117 describes significant fields shown in the display.
.
Table 117 show issu patch Descriptions
Field
|
Description
|
Overall Impact of the pending upgrade:
|
The command output shows the overall impact of an upgrade on a specified disk.
|
Search Root: disk0:/sys
|
Disk on which the upgrade will occur.
|
Type of upgrade: New base image
|
Type of upgrade. The upgrade could be a new image or a patch.
|
Action: Go Standby
|
Activates the upgrade on the standby router.
|
Slot #
|
Slot number on the router.
|
Card type
|
Type of card installed in the specified slot.
|
Impacted
|
States whether or not the card in the specified slot is affected by the upgrade.
|
show issu rollback timer
To display the current setting of the In Service Software Upgrade (ISSU) rollback timer, use the show issu rollback timer command in user EXEC or privileged EXEC mode.
show issu rollback timer
Syntax Description
This command has no arguments or keywords.
Command Default
The default rollback timer value is 45 minutes.
Command Modes
User EXEC (>)
Privileged EXEC (#)
Command History
Release
|
Modification
|
12.2(28)SB
|
This command was introduced.
|
12.2(28)SB2
|
Enhanced Fast Software Upgrade (eFSU) support was added on the Cisco 7500 series routers.
|
12.2(33)SRB1
|
ISSU is supported on the Cisco 7600 series routers in Cisco IOS Release 12.2(33)SRB1.
|
12.2(33)SRE
|
This command was integrated into Cisco IOS Release 12.2(33)SRE.
|
Usage Guidelines
If the ISSU rollback timer value has never been set, then the default rollback timer value of 45 minutes is displayed.
Examples
The following example shows the default rollback timer value:
Router# show issu rollback-timer
Rollback Process State = Not in progress
Configured Rollback Time = 45:00
Table 118 describes the significant fields shown in the display.
Table 118 show issu rollback-timer Field Descriptions
Field
|
Description
|
Rollback Process State = Not in progress
|
State of the rollback process.
|
Configured Rollback Time = 45:00
|
Rollback timer value.
|
Related Commands
Command
|
Description
|
configure issu set rollback timer
|
Configures the rollback timer value.
|
show issu sessions
To display detailed information about a particular In Service Software Upgrade (ISSU) client—including whether the client status for the impending software upgrade is compatible—use the show issu sessions command in user EXEC or privileged EXEC mode.
show issu sessions client-id
Syntax Description
client-id
|
The identification number used by ISSU for the client.
|
Command Modes
User EXEC (>)
Privileged EXEC (#)
Command History
Release
|
Modification
|
12.2(28)SB
|
This command was introduced.
|
12.2(33)SRB1
|
ISSU is supported on the Cisco 7600 series routers in Cisco IOS Release 12.2(33)SRB1.
|
12.2(33)SRE
|
This command was integrated into Cisco IOS Release 12.2(33)SRE.
|
Usage Guidelines
If you are not sure of the Client_ID number to enter into this command, use the show issu clients command to display the current list of clients with their names and ID numbers.
Examples
The following example shows detailed information about the LDP Client:
Router# show issu sessions 2011
Client_ID = 2011, Entity_ID = 1 :
*** Session_ID = 46, Session_Name = LDP Session :
Peer Peer Negotiate Negotiated Cap Msg Session
UniqueID Sid Role Result GroupID GroupID Signature
4 34 PRIMARY COMPATIBLE 1 1 0
Negotiation Session Info for This Message Session:
Nego_Session_Name = LDP Session
Table 119 describes the significant fields shown in the display.
Table 119 show issu sessions Field Descriptions
Field
|
Description
|
Client_ID
|
The identification number used by ISSU for that client.
|
Entity_ID
|
The identification number used by ISSU for each entity within this client.
|
Session_ID
|
The identification number used by ISSU for this session.
|
Session_Name
|
A character string describing the session.
|
Peer UniqueID
|
An identification number used by ISSU for a particular endpoint, such as a Route Processor or line card (could be a value based on slot number, for example).
The peer that has the smaller unique_ID becomes the Primary (initiating) side in the capability and message version negotiations.
|
Peer Sid
|
Peer session ID.
|
Negotiate Role
|
Negotiation role of the endpoint: either PRIMARY (in which case the device initiates the negotiation) or PASSIVE (in which case the device responds to a negotiation initiated by the other device).
|
Negotiated Result
|
The features ("capabilities") of this client's new software were found to be either COMPATIBLE or INCOMPATIBLE with the intended upgrade process.
("Policy" means that an override of the negotiation result has been allowed by the software. Likewise, "no policy" means that no such override is present to be invoked).
|
Cap GroupID
|
Capability group ID: the identification number used for a list of distinct functionalities that the client application contains.
|
Msg GroupID
|
Message group ID: the identification number used for a list of formats employed when conveying information between the active device and the standby device.
|
Session Signature
|
Session signature: a unique ID to identify a current session in a shared negotiation scenario.
|
Nego_Session_ID
|
Negotiation session ID: the identification number used by ISSU for this negotiation session.
|
Nego_Session_Name
|
Negotiation session name: a character string describing this negotiation session.
|
Transport_Mtu
|
Maximum packet size (in bytes) of the ISSU messages conveyed between the two endpoints.
A value of 0 means there is no restriction on size; in this case, fragmentation and reassembly then are handled in a manner transparent to the ISSU infrastructure.
|
Related Commands
Command
|
Description
|
show issu clients
|
Lists the current ISSU clients—that is, the applications on this network supported by ISSU.
|
show issu message types
|
Displays the formats, versions, and maximum packet size of ISSU messages supported by a particular client.
|
show issu negotiated
|
Displays results of a negotiation that occurred concerning message versions or client capabilities.
|
show issu state
To display the state and current version of the Route Processor
