ISSU MPLS Clients
First Published: April 16, 2004
Last Updated: November 14, 2008
MPLS applications can be upgraded using the In Service Software Upgrade (ISSU) process and the enhanced Fast Software Upgrade (eFSU) process. Thus, MPLS applications are considered ISSU's MPLS clients. The ISSU process allows Cisco IOS software at the router level to be updated or otherwise modified while packet forwarding continues. At the line-card level, the eFSU process minimizes line-card downtime during such upgrades to between 30 and 90 seconds, by loading the new line-card image before the ISSU switchover occurs from the active to the standby Route Processor (RP).
Finding Feature Information
Your software release may not support all the features documented in this module. For the latest feature information and caveats, see the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the "Feature Information for ISSU MPLS Clients" section.
Use Cisco Feature Navigator to find information about platform support and Cisco IOS and Catalyst OS software image support. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Contents
•Prerequisites for ISSU MPLS Clients
•Restrictions for ISSU MPLS Clients
•Information About ISSU MPLS Clients
•How to Verify that an MPLS Client Can Support an In Service Software Upgrade
•Configuration Examples for ISSU MPLS Clients
•Additional References
•Feature Information for ISSU MPLS Clients
•Glossary
Prerequisites for ISSU MPLS Clients
Before you perform an upgrade, you need to verify that the clients you are concerned about are compatible with the intended switchover. Use the commands listed in the "Verifying the ISSU Process for an MPLS Client" section to determine compatibility.
The success performance of some clients in the upgraded network will depend upon their compatibility with other clients as described in Table 1.
Table 1 MPLS Client Interdependencies
|
...can only work when this client is shown to be compatible
|
MPLS VPN |
LSD Label Manager High Availability |
LDP |
LSD Label Manager High Availability |
VRF ("Table ID") |
LSD Label Manager High Availability |
LSD Label Manager High Availability |
Base clients: Checkpointing and Redundancy Facility |
MFI Pull |
XDR |
MFI Push |
XDR |
LSPV Push within OAM |
XDR |
TE |
Base clients: •Checkpointing and Redundancy Facility •MPLS TE High Availability |
Restrictions for ISSU MPLS Clients
Because line cards in the Cisco series 7600 routers do not support Minimum Disruption Restart (MDR), they reset when eFSU is performed. That causes IGP adjacencies to flap (adjacent routes are advertised as unavailable and then available again in quick sequence), bringing down the MPLS traffic engineering (TE) tunnels. Therefore, after an eFSU operation, it may take as long as two minutes for TE tunnels to be resignaled and reestablished.
For this reason, we recommend that before you begin eFSU you first disable Resource Reservation Protocol Graceful Restart (RSVP GR) full mode. If this mode is not disabled, RSVP can inadvertently delay the reestablishment of TE tunnels while it waits for the recovery of the preexisting TE tunnel state.
To see how long each line card will be placed out of service during the eFSU process, use the show issu outage slot all command as described in the "Determining Impending Line-Card Outage Periods During an ISSU" section.
Information About ISSU MPLS Clients
Before examining ISSU coordination of MPLS clients, you should understand the following concepts:
•ISSU-Capable Protocols and Applications: Clients
•ISSU-Capable MPLS Feature Sets
This section provides information about upgrading MPLS-related applications through ISSU and eFSU. Those MPLS applications are considered ISSU's MPLS "clients."
For information on the entire ISSU and eFSU procedure, please see the document, Cisco IOS In Service Software Upgrade and Enhanced Fast Software Upgrade Process.
For information specific to eFSU on the Cisco 7600 series router, please refer to the "ISSU and eFSU on Cisco 7600 Series Routers" chapter in the Cisco 7600 Series Router Cisco IOS Software Configuration Guide, Release 12.2SR.
ISSU-Capable Protocols and Applications: Clients
Protocols and applications that can be upgraded through the ISSU process are considered clients of ISSU. These include at least the following:
•Address Resolution Protocol (ARP)
•Asynchronous Transfer Mode (ATM)
•Cisco Express Forwarding
•Dynamic Host Configuration Protocol (DHCP)
•EtherChannel—port aggregration protocol (PagP) and Link Aggregration Control Protocol (LACP)
•Frame Relay (FR)
•Gateway Load Balancing Protocol (GLBP)
•High-Level Data Link Control (HDLC)
•Hot Standby Router Protocol (HSRP)
•IEEE 802.1x and 802.3af
•Internet Group Management Protocol (IGMP) snooping
•IP host
•Intermediate System-to-Intermediate System (IS-IS)
•Multiprotocol Label Switching (MPLS)
•PPP and Multilink PPP
•Port security
•Quality of service (QoS)
•Remote File System (RFS) versioning
•Simple Network Management Protocol (SNMP)
•Spanning Tree Protocol (STP)
ISSU-Capable MPLS Feature Sets
Within the MPLS technology, ISSU supports the following feature sets as clients:
•Label Distribution Protocol (LDP)
•MPLS Virtual Private Network (MPLS VPN)
•VPN routing and forwarding (VRF), also called the "Table ID" client
•Label Switching Database Label Manager for high availability, usually called "LSD Label Manager for HA"
•MPLS Forwarding Infrastructure Pull, called "MFI Pull"
•MPLS Forwarding Infrastructure Push, called "MFI Push"
Beginning with Cisco IOS Release 12.2(33)SRB1, the following MPLS features are also supported as ISSU clients:
•Label Switched Path Verification Push within Operation, Administration, and Management (OAM), called "LSPV Push"
•TE
How to Verify that an MPLS Client Can Support an In Service Software Upgrade
This section contains the following procedures:
•Determining Impending Line-Card Outage Periods During an ISSU (required)
•Verifying the ISSU Process for an MPLS Client (required)
Determining Impending Line-Card Outage Periods During an ISSU
Perform this task to determining impending line-card outage periods during an ISSU.
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.
Note For the complete task sequence that accomplishes ISSU and eFSU, please see the document entitled, Cisco IOS In Service Software Upgrade and Enhanced Fast Software Upgrade Process.
Prerequisites
Ensure that you have successfully loaded new Cisco IOS software onto the standby processor as described in Cisco IOS In Service Software Upgrade and Enhanced Fast Software Upgrade Process.
SUMMARY STEPS
1. enable
2. show issu outage slot all
DETAILED STEPS
|
|
|
Step 1 |
enable
Router> enable |
Enables privileged EXEC mode. •Enter your password if prompted. |
Step 2 |
show issu outage slot all
Router# show issu outage slot all
|
Determines the maximum length of time each line card could be down when use of the issu runversion command will trigger eFSU. |
Examples
The following is sample output from the show issu outage command:
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
The column "Max Outage Time" shows the longest downtime that should be expected for each of the four listed line card types:
Note When there is no eFSU to be performed, and only ISSU will result from the use of the issu runversion command, the MDR Mode column in this display shows "NSF_RELOAD" for each line card, to indicate that the line card will not be restarted during the upgrade and therefore will not experience any downtime.
If you happen to enter the show issu outage command outside of the ISSU command sequence, the MDR Mode column in this display shows "INVALID".
Verifying the ISSU Process for an MPLS Client
Perform this task to verify that a particular MPLS client can be upgraded successfully during a particular ISSU session. The commands in this task also can be used to display other details about the ISSU MPLS clients, and should be entered in the order described.
SUMMARY STEPS
1. enable
2. show issu clients
3. show issu sessions clientID
4. show issu negotiated version sessionID
5. show issu negotiated capability sessionID
6. show issu message types clientID
DETAILED STEPS
|
|
|
Step 1 |
enable
Router> enable |
Enables privileged EXEC mode. •Enter your password if prompted. |
Step 2 |
show issu clients
Router# show issu clients |
Lists network applications and protocols currently supported by ISSU. You can use this command to discover the client ID that you will need to enter in Steps 3 and 6. |
Step 3 |
show issu sessions clientID
Router# show issu sessions 2002 |
Tells whether a particular client is compatible with the intended upgrade. You can use this command to discover the session ID that you will need to enter in Steps 4 and 5. |
Step 4 |
show issu negotiated version sessionID
Router# show issu negotiated version
33
|
Displays details of the session's negotiated message version. |
Step 5 |
show issu negotiated capability sessionID
Router# show issu negotiated
capability 33
|
Displays results of a negotiation about the client application's capabilities. |
Step 6 |
show issu message types clientID
Router# show issu message types 2002 |
Displays the message formats ("types") and versions supported by the specified client. |
Configuration Examples for ISSU MPLS Clients
This section presents the following examples:
•Verifying the ISSU Process for an MPLS LDP Client: Example
•Verifying the ISSU Process for an MPLS VPN Client: Example
•Verifying the ISSU Process for an MPLS VRF ("Table ID") Client: Example
•Verifying the ISSU Process for an MPLS LSD Label Manager HA Client: Example
•Verifying the ISSU Process for an MPLS MFI Pull Client: Example
•Verifying the ISSU Process for an MPLS MFI Push Client: Example
•Verifying the ISSU Process for an MPLS LSPV Push Client: Example
•Verifying the ISSU Process for an MPLS TE Client: Example
To examine any ISSU client, you must specify its unique client ID when entering the show issu sessions command. If you do not already know that client ID, enter the show issu clients command in user EXEC or privileged EXEC mode. Each ISSU client on the network will then be listed, with its client ID and client name on the same line, as shown in the following example:
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 = 2053, Client_Name = ISSU MPLS TE Client, Entity_Count = 1
Client_ID = 2054, Client_Name = ISSU process client, Entity_Count = 1
Client_ID = 2089, Client_Name = MPLS LSPV Push 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
Client_Name = ISSU rfs client
Client_Name = ISSU ifs client
Client_Name = ISSU EM client
Client_Name = ISSU Platform Medialayer Client
Client_Name = ISSU FM Client
Client_Name = ISSU TCAM Manager Client
Client_Name = ISSU L2 Cmn Client
Client_Name = ISSU L3 Manager HA Client
Client_Name = ISSU L3 Manager Client
Client_Name = ISSU CFIB BASE Client
Client_Name = ISSU PF CONFIG SYNC Client
Client_Name = ISSU MLS CEF Client
Client_Name = ISSU Cat6k Logger Client
Verifying the ISSU Process for an MPLS LDP Client: Example
This example shows how to verify the ISSU process for an LDP client.
The first command shows you whether the LDP client's old and new software versions are compatible, and therefore are able to make use of the ISSU opportunity:
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
Now you can take the session ID displayed in the previous command's output and enter it into the next command, in order to see the negotiated message version:
Router# show issu negotiated version 46
Message_Type = 1, Negotiated_Version = 2, Message_MTU = 20
Message_Type = 2, Negotiated_Version = 2, Message_MTU = 20
Message_Type = 3, Negotiated_Version = 2, Message_MTU = 4
Next you can enter the same session ID into the following command to display the capability negotiation result:
Router# show issu negotiated capability 46
Finally, to see which message types and versions are supported by this particular client, you enter the client ID into the following command:
Router# show issu message types 2011
---------------------------------------------------------------------
Client_ID = 2011, Entity_ID = 1 :
Message_Type = 1, Version_Range = 2 ~ 2
Message_Ver = 2, Message_Mtu = 20
Message_Type = 2, Version_Range = 2 ~ 2
Message_Ver = 2, Message_Mtu = 20
Message_Type = 3, Version_Range = 2 ~ 2
Message_Ver = 2, Message_Mtu = 4
Verifying the ISSU Process for an MPLS VPN Client: Example
This example shows how to verify the ISSU process for an MPLS VPN client.
The first command shows you whether the VPN client's old and new software versions are compatible, and therefore are able to make use of the ISSU opportunity:
Router# show issu sessions 2009
---------------------------------------------------------------------
Client_ID = 2009, Entity_ID = 1 :
*** Session_ID = 39, Session_Name = MPLS VPN ISSU Session :
Peer Peer Negotiate Negotiated Cap Msg Session
UniqueID Sid Role Result GroupID GroupID Signature
3 33 PASSIVE COMPATIBLE 1 1 0
Negotiation Session Info for This Message Session:
Nego_Session_Name = MPLS VPN ISSU Session
Now you can take the session ID displayed in the previous command's output and enter it into the next command, in order to see the negotiated message version:
Router# show issu negotiated version 39
Message_Type = 1, Negotiated_Version = 1, Message_MTU = 32
Next you can enter the same session ID into the following command to display the capability negotiation result:
Router# show issu negotiated capability 39
Finally,= to see which message types and versions are supported by this particular client, you enter the client ID into the following command:
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
Verifying the ISSU Process for an MPLS VRF ("Table ID") Client: Example
This example shows how to verify the ISSU process for an MPLS VRF ("Table ID") client.
The first command shows you whether the VRF client's old and new software versions are compatible, and therefore are able to make use of the ISSU opportunity:
Router# show issu sessions 2008
---------------------------------------------------------------------
Client_ID = 2008, Entity_ID = 1 :
*** Session_ID = 19, Session_Name = TABLEID ISSU CF :
Peer Peer Negotiate Negotiated Cap Msg Session
UniqueID Sid Role Result GroupID GroupID Signature
4 13 PRIMARY COMPATIBLE 1 1 0
Negotiation Session Info for This Message Session:
Nego_Session_Name = TABLEID ISSU CF
Now you can take the session ID displayed in the previous command's output and enter it into the next command, in order to see the negotiated message version:
Router# show issu negotiated version 19
Message_Type = 1, Negotiated_Version = 1, Message_MTU = 44
Message_Type = 2, Negotiated_Version = 1, Message_MTU = 4
Next you can enter the same session ID into the following command to display the capability negotiation result:
Router# show issu negotiated capability 19
Finally, to see which message types and versions are supported by this particular client, you enter the client ID into the following command:
Router# show issu message types 2008
---------------------------------------------------------------------
Client_ID = 2008, Entity_ID = 1 :
Message_Type = 1, Version_Range = 1 ~ 1
Message_Ver = 1, Message_Mtu = 44
Message_Type = 2, Version_Range = 1 ~ 1
Message_Ver = 1, Message_Mtu = 4
Verifying the ISSU Process for an MPLS LSD Label Manager HA Client: Example
This example shows how to verify the ISSU process for an MPLS LSD Label Manager HA client.
The first command shows you whether the LSD client's old and new software versions are compatible, and therefore are able to make use of the ISSU opportunity:
Router# show issu sessions 2007
---------------------------------------------------------------------
Client_ID = 2007, Entity_ID = 1 :
*** Session_ID = 40, Session_Name = lsd_ha :
Peer Peer Negotiate Negotiated Cap Msg Session
UniqueID Sid Role Result GroupID GroupID Signature
4 30 PRIMARY COMPATIBLE 1 1 0
Negotiation Session Info for This Message Session:
Nego_Session_Name = lsd_ha
Compat_Result: raw_result = COMPATIBLE, policy_result = COMPATIBLE
Now you can take the session ID displayed in the previous command's output and enter it into the next command, in order to see the negotiated message version:
Router# show issu negotiated version 40
Message_Type = 1, Negotiated_Version = 2, Message_MTU = 8
Next you can enter the same session ID into the following command to display the capability negotiation result:
Router# show issu negotiated capability 40
---------------------------------------------------
Client_ID = 2007, Entity_ID = 1, Session_ID = 40 :
Finally, to see which message types and versions are supported by this particular client, you enter the client ID into the following command:
Router# show issu message types 2007
---------------------------------------------------------------------
Client_ID = 2007, Entity_ID = 1 :
Message_Type = 1, Version_Range = 1 ~ 2
Message_Ver = 1, Message_Mtu = 12
Message_Ver = 2, Message_Mtu = 8
Verifying the ISSU Process for an MPLS MFI Pull Client: Example
This example shows how to verify the ISSU process for an MPLS MFI Pull client.
The first command shows you whether the MFI Pull client's old and new software versions are compatible, and therefore are able to make use of the ISSU opportunity:
Router# show issu sessions 2030
---------------------------------------------------------------------
Client_ID = 2030, Entity_ID = 1 :
*** Session_ID = 131073, Session_Name = MFI Pull (6):
Peer Peer Negotiate Negotiated Cap Msg Session
UniqueID Sid Role Result GroupID GroupID Signature
7 35 PRIMARY COMPATIBLE 1 1 0
Negotiation Session Info for This Message Session:
Nego_Session_Name = MFI Pull (6)
Now you can take the session ID displayed in the previous command's output and enter it into the next command, in order to see the negotiated message version:
Router# show issu negotiated version 131073
Message_Type = 1006, Negotiated_Version = 1, Message_MTU = 4
Message_Type = 3003, Negotiated_Version = 1, Message_MTU = 12
Next you can enter the same session ID into the following command to display the capability negotiation result:
Router# show issu negotiated capability 131073
Finally to see which message types and versions are supported by this particular client, you enter the client ID into the following command:
Router# show issu message types 2030
---------------------------------------------------------------------
Client_ID = 2030, Entity_ID = 1 :
Message_Type = 1006, Version_Range = 1 ~ 1
Message_Ver = 1, Message_Mtu = 4
Message_Type = 2004, Version_Range = 1 ~ 1
Message_Ver = 1, Message_Mtu = 12
Verifying the ISSU Process for an MPLS MFI Push Client: Example
This example shows how to verify the ISSU process for an MPLS MFI Push client.
The first command shows you whether the MFI Push client's old and new software versions are compatible, and therefore are able to make use of the ISSU opportunity:
Router# show issu sessions 2031
---------------------------------------------------------------------
Client_ID = 2031, Entity_ID = 1 :
*** Session_ID = 196646, Session_Name = MFI Push (6):
Peer Peer Negotiate Negotiated Cap Msg Session
UniqueID Sid Role Result GroupID GroupID Signature
7 36 PRIMARY COMPATIBLE 1 1 0
Negotiation Session Info for This Message Session:
Nego_Session_Name = MFI Push (6)
Now you can take the session ID displayed in the previous command's output and enter it into the next command, in order to see the negotiated message version:
Router# show issu negotiated version 196646
Message_Type = 101, Negotiated_Version = 1, Message_MTU = 17
Message_Type = 105, Negotiated_Version = 1, Message_MTU = 31
Next you can enter the same session ID into the following command to display the capability negotiation result:
Router# show issu negotiated capability 196646
Finally to see which message types and versions are supported by this particular client, you enter the client ID into the following command:
Router# show issu message types 2031
---------------------------------------------------------------------
Client_ID = 2031, Entity_ID = 1 :
Message_Type = 5002, Version_Range = 1 ~ 2
Message_Ver = 1, Message_Mtu = 10
Message_Type = 5018, Version_Range = 1 ~ 1
Message_Ver = 1, Message_Mtu = 39
Verifying the ISSU Process for an MPLS LSPV Push Client: Example
This example shows how to verify the ISSU process for an MPLS LSVP Push client.
The first command shows you whether the LSPV Push client's old and new software versions are compatible, and therefore are able to make use of the ISSU opportunity:
Router# show issu sessions 2089
---------------------------------------------------------------------
Client_ID = 2089, Entity_ID = 1 :
*** Session_ID = 45, Session_Name = MPLS LSPV Push (6 ):
Peer Peer Negotiate Negotiated Cap Msg Session
UniqueID Sid Role Result GroupID GroupID Signature
7 36 PRIMARY COMPATIBLE 1 1 0
Negotiation Session Info for This Message Session:
Nego_Session_Name = MPLS LSPV Push ( 6)
Now you can take the session ID displayed in the previous command's output and enter it into the next command, in order to see the negotiated message version:
Router# show issu negotiated version 45
Message_Type = 0, Negotiated_Version = 1, Message_MTU = 74
Message_Type = 1, Negotiated_Version = 1, Message_MTU = 120
Message_Type = 2, Negotiated_Version = 1, Message_MTU = 120
Message_Type = 3, Negotiated_Version = 1, Message_MTU = 5122
Message_Type = 4, Negotiated_Version = 1, Message_MTU = 6
Next you can enter the same session ID into the following command to display the capability negotiation result:
Router# show issu negotiated capability 45
Cap_Type = 0 Cap_Result = 1 No cap value assigned
Finally to see which message types and versions are supported by this particular client, you enter the client ID into the following command:
Router# show issu message types 2089
---------------------------------------------------------------------
Client_ID = 2089, Entity_ID = 1 :
Message_Type = 0, Version_Range = 1 ~ 1
Message_Ver = 1, Message_Mtu = 74
Message_Type = 1, Version_Range = 1 ~ 1
Message_Ver = 1, Message_Mtu = 120
Message_Type = 2, Version_Range = 1 ~ 1
Message_Ver = 1, Message_Mtu = 120
Message_Type = 3, Version_Range = 1 ~ 1
Message_Ver = 1, Message_Mtu = 5122
Message_Type = 4, Version_Range = 1 ~ 1
Message_Ver = 1, Message_Mtu = 6
Verifying the ISSU Process for an MPLS TE Client: Example
This example shows how to verify the ISSU process for an MPLS TE client.
The first command shows you whether the TE client's old and new software versions are compatible, and therefore are able to make use of the ISSU opportunity:
Router# show issu sessions 2053
---------------------------------------------------------------------
Client_ID = 2053, Entity_ID = 1 :
*** Session_ID = 84, Session_Name = RSVP HA Session :
Peer Peer Negotiate Negotiated Cap Msg Session
UniqueID Sid Role Result GroupID GroupID Signature
22 94 PRIMARY COMPATIBLE 1 1 0
Negotiation Session Info for This Message Session:
Nego_Session_Name = RSVP HA Session
Now you can take the session ID displayed in the previous command's output and enter it into the next command, in order to see the negotiated message version:
Router# show issu negotiated version 84
Message_Type = 1, Negotiated_Version = 2, Message_MTU = 1024
Next you can enter the same session ID into the following command to display the capability negotiation result:
Router# show issu negotiated capability 84
Cap_Type = 0, Cap_Result = 1 No cap value assigned
Finally to see which message types and versions are supported by this particular client, you enter the client ID into the following command:
Router# show issu message types 2053
---------------------------------------------------------------------
Client_ID = 2053, Entity_ID = 1 :
Message_Type = 1, Version_Range = 1 ~ 2
Message_Ver = 1, Message_Mtu = 1024
Message_Ver = 2, Message_Mtu = 1024
Additional References
Related Documents
Standards
MIBs
|
|
None |
To locate and download MIBs for selected platforms, Cisco IOS releases, and feature sets, use Cisco MIB Locator found at the following URL: http://www.cisco.com/go/mibs |
RFCs
Technical Assistance
|
|
The Cisco Support website provides extensive online resources, including documentation and tools for troubleshooting and resolving technical issues with Cisco products and technologies. To receive security and technical information about your products, you can subscribe to various services, such as the Product Alert Tool (accessed from Field Notices), the Cisco Technical Services Newsletter, and Really Simple Syndication (RSS) Feeds. Access to most tools on the Cisco Support website requires a Cisco.com user ID and password. |
http://www.cisco.com/techsupport |
Feature Information for ISSU MPLS Clients
Table 2 lists the release history for this feature.
Not all commands may be available in your Cisco IOS software release. For release information about a specific command, see the command reference documentation.
Use Cisco Feature Navigator to find information about platform support and software image support. Cisco Feature Navigator enables you to determine which Cisco IOS and Catalyst OS software images support a specific software release, feature set, or platform. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Note Table 2 lists only the Cisco IOS software release that introduced support for a given feature in a given Cisco IOS software release train. Unless noted otherwise, subsequent releases of that Cisco IOS software release train also support that feature.
Table 2 Feature Information for ISSU MPLS Clients
|
|
|
ISSU MPLS Clients |
12.2(28)SB 12.2(33) SRB-1 |
MPLS applications can be upgrading using the In Service Software Upgrade (ISSU) process and the enhanced Fast Software Upgrade (eFSU) process. Thus, MPLS applications are considered ISSU's MPLS clients. The ISSU process allows Cisco IOS software at the router level to be updated or otherwise modified while packet forwarding continues. At the line-card level, the eFSU process minimizes line-card downtime during such upgrades to between 30 and 90 seconds, by loading the new line-card image before the ISSU switchover occurs from the active to the standby Route Processor (RP). In 12.2(28)SB, the ISSU feature was introduced. In 12.2(33)SRB-1, the LSPV Push and TE clients and the eFSU functionality were added. The following commands were introduced or modified: show issu clients, show issu entities, show issu message types, show issu negotiated, show issu outage, show issu sessions. |
Glossary
eFSU—enhanced Fast Software Upgrade.
IS—intermediate system.
ISSU—In Service Software Upgrade.
LACP—Link Aggregration Control Protocol.
LDP—Label Distribution Protocol.
MFI—Multiprotocol Label Switching Forwarding Infrastructure.
MPLS—Multiprotocol Label Switching.
OAM—Operation, Administration, and Management.
PagP—port aggregation Protocol.
PPP—Point to Point protocol.
RP—Route Processor.
RSVP GR—Resource Reservation Protocol graceful restart.
TE—traffic engineering.
VPN—Virtual Private Network.
VRF—virtual routing and forwarding.
Cisco and the Cisco Logo are trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and other countries. A listing of Cisco's trademarks can be found at www.cisco.com/go/trademarks. Third party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1005R)
Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and coincidental.
© 2004-2010 Cisco Systems, Inc. All rights reserved.