cancel
Showing results for 
Search instead for 
Did you mean: 
cancel

Migrating from RSP440 to RSP880 on ASR9000

21733
Views
15
Helpful
42
Comments

Migrating from RSP440 to RSP880 on ASR9000

 

1) Prerequisites:

 

Console access to the router and Router must be running release 5.3.2 or (5.3.1 with engineering SMU)

System must not have 800G (tomahawk) line cards, (see caveat (a) in list below)

RSP1 is the active RSP440 (see caveat(b) in list below)

This process only works when upgrading RSP-440-TR/SE to RSP-880. This process does NOT apply to A9K-RSP-4G or A9K-RSP-8G(AKA RSP2), an upgrade from RSP2 to RSP880 is not graceful.

Before the upgrade process starts, and prior to removing any RSP from the chassis, make sure that “show redundancy” shows NSR and standby card is ready.

Make sure any none 5.3.x software is removed from the system (ie install remove *4.3.4*)

Enable console logging on the router and on the terminal application (optional)

 

2) Caveats:

 

The system must NOT have Tomahawk (400G or 800G) Line cards in the chassis prior to attempting this as the EOBC link between Tomahawk and newly inserted RSP880 will be down which will interfere with the failover from RSP440 to RSP880. If there are Tomahawk cards in the chassis, they need to be removed or powered down for the upgrade to be successful.  ‘admin-config #hw-module power disable location 0/1/cpu0’


While doing RSP440 to RSP880 upgrade, Active RSP440 must be in slot 1, else the user will observe online diag fabric punt failure to LC on the newly standby RSP880.

 

Remove Trident Linecards from the system as they are incompatible with the RSP880.

 

3) Upgrade process:

 

 

 RSP1 is the active RSP440 running 5.3.2 or 5.3.1 + SMU

If RSP0 slot is active and RSP1 is standby then first OIR/Remove RSP0 slot card (or do redundancy switchover from RSP0 to RSP1) to make RSP1 as active and then insert RSP880 in slot0.

 

Issue show redundancy and make sure NSR and Standby card is ready

 

RP/0/RSP0/CPU0:vkg7RO#show redundancy summary

Wed Jun 17 11:18:51.391 PST

  Active/Primary   Standby/Backup

  --------------   --------------

  0/RSP0/CPU0(A)   0/RSP1/CPU0(S) (Node Ready, NSR: Ready)

  0/RSP0/CPU0(P)   0/RSP1/CPU0(B) (Proc Group Ready, NSR: Ready)

RP/0/RSP0/CPU0:vkg7RO#       

 

RP/0/RSP0/CPU0:vkg7RO#show redundancy

Wed Jun 17 11:20:19.086 PST

Redundancy information for node 0/RSP0/CPU0:

==========================================

Node 0/RSP0/CPU0 is in ACTIVE role

Node Redundancy Partner (0/RSP1/CPU0) is in STANDBY role

Standby node in 0/RSP1/CPU0 is ready

Standby node in 0/RSP1/CPU0 is NSR-ready

Node 0/RSP0/CPU0 is in process group PRIMARY role

Process Redundancy Partner (0/RSP1/CPU0) is in BACKUP role

Backup node in 0/RSP1/CPU0 is ready

Backup node in 0/RSP1/CPU0 is NSR-ready

 

Group            Primary         Backup          Status

---------        ---------       ---------       ---------

v6-routing       0/RSP0/CPU0     0/RSP1/CPU0     Ready

mcast-routing    0/RSP0/CPU0     0/RSP1/CPU0     Ready

netmgmt          0/RSP0/CPU0     0/RSP1/CPU0     Ready

v4-routing       0/RSP0/CPU0     0/RSP1/CPU0     Ready

central-services 0/RSP0/CPU0     0/RSP1/CPU0     Ready

dlrsc            0/RSP0/CPU0     0/RSP1/CPU0     Ready

dsc              0/RSP0/CPU0     0/RSP1/CPU0     Ready

 

Reload and boot info

----------------------

A9K-RSP440-SE reloaded Fri Jun 12 14:40:22 2015: 4 days, 20 hours, 39 minutes ago

Active node booted Fri Jun 12 20:52:24 2015: 4 days, 14 hours, 27 minutes ago

Last switch-over Mon Jun 15 10:43:34 2015: 2 days, 36 minutes ago

Standby node boot Mon Jun 15 10:44:53 2015: 2 days, 35 minutes ago

Standby node last went not ready Mon Jun 15 10:46:27 2015: 2 days, 33 minutes ago

Standby node last went ready Mon Jun 15 10:47:27 2015: 2 days, 32 minutes ago

There have been 3 switch-overs since reload

 

Active node reload "Cause: Initiating switch-over."

Standby node reload "Cause: Initiating switch-over."

 

RP/0/RSP0/CPU0:vkg7RO#                                                       

 

 

3)     Remove the standby RSP440 (RSP0)

 

4)      Insert RSP880 (A) in slot 0.

 

5)      Issue Ctrl-c to break into ROMMON of inserted RSP880

                (If this is missed, the RSP880 will go into a boot cycle loop, and there will be another chance to break into rommon on the next bootup, no side effects apart from syslog msgs on the active RSP).

 

 

NOTE: if your running 5.3.x and greater releases, you may get a menu to choose various boot options, you will need to select "boot IOS XR in 32-bit mode", if the requirement is to stat on 32 bit XR. 

 

6)      From ROMMON prompt on RSP880 (A), set ROMMON variable to force 1GE Mode for Peer RSP communication (RSP_LINK_1G=1), and check config register is set correctly in ROMMON

               rommon B1> RSP_LINK_1G=1

               rommon B1> sync

 

7)      Reset RSP880 (A) card, it will boot up to standby state which will synchronize configuration from Active RSP440 in Slot 1

               rommon B1> reset -h

 

8)      Verify the RSPs have reached full synchronization with “show redundancy” command and the groups are in “ready” state.

               show redundancy

 

9)      Verify the RSPs have synchronized the SNMP engine ID and SNMP ifindex-table

                #more disk0:snmp/ifindex-table loc 0/rsp0/cpu0

                #more disk0:snmp/ifindex-table loc 0/rsp1/cpu0

                #more disk0:snmp/snmp_persist loc 0/rsp0/cpu0

                #more disk0:snmp/snmp_persist loc 0/rsp1/cpu0

               manually copy any eem scripts from RSP440 to RSP880 disks if applicable

 

 

10)      Failover from active RSP440 (slot 1) to standby RSP880 in (Slot0)

                “redundancy switchover”

 

 NOTE: A CLI switchover is needed, a physical OIR of the RP will not do the trick.

 

11)       Verify the RSP880 becomes active RSP and configuration is present

                At this point the RSP440 must be removed/eject from slot 1.

 

12)      Insert RSP880 (B) and allow it to boot to standby.  Do *not* set the ROMMON variable

 

13)      Issue show redundancy to confirm the RSPs have sync’d up and in correct state

 'show platform’

 'show redundancy'

  manually copy any eem scripts from Active RSP to Standby disks if applicable

 

  

              14)      On Active RSP880 Clear ROMMON variable from XR

run nvram_rommonvar RSP_LINK_1G 0

               more nvram:/classic-rommon-var

 

In case newly inserted second RSP880 fails to boot up, park standby RSP880 in Rommon.

Type “set” to list Rommon variables. Check for the presence of Rommon variable “RSP_LINK_1G=1”.

If set, unset RSP_LINK_1G and reset card by following below steps.

 

rommon B1> priv

rommon B1> unset RSP_LINK_1G

rommon B1> sync

rommon B1> sync

rommon B1> reset -h

 

               15)    Perform FPD upgrade on the RSP880 (optional)

admin upgrade hw-module fpd all location 0/rsp0/cpu0

               admin upgrade hw-module fpd all location 0/rsp1/cpu0

 

               16)    Deactivate and remove the SMU.

 

               17)    Check the EOBC ports are running at 10G with the following four commands, the output should be “10G/KR/1-lane”

show controllers epm-switch port-status 54 loc 0/rsp0/cpu0 | in Mode

show controllers epm-switch port-status 55 loc 0/rsp0/cpu0 | in Mode

show controllers epm-switch port-status 54 loc 0/rsp1/cpu0 | in Mode

show controllers epm-switch port-status 55 loc 0/rsp1/cpu0 | in Mode

 

              18)    Final checks to ensure system is optional and functional

 

          Note; this operation has been tested to be graceful with NSR configured

 

 

Comments
Aleksandar Vidakovic
Cisco Employee

This procedure of RSP440->RSP880 migration is not dependent on line card type.

/Aleksandar

Tom Prevost
Beginner

One more question:

Step 16 states:

 16)    Deactivate and remove the SMU.

What SMU are you talking about here?

Aleksandar Vidakovic
Cisco Employee

hi Tom,

This SMU applies only to 5.3.1. See the "prerequisites" at the very start of the doc.

/Aleksandar

prarepal
Cisco Employee

Hi Eddie,

This document was really helpful. It worked for us to migrate from RSP440 to RSP880.

But even after  power disable Tomahawk line card once stand-by RSP880 boots Tomahawk is up and interrupts migration.

we have to remove Tomahawk from chassis and then start migrating

Not applicable

Hi There,

Can i know which Engineering SMU that need to install on the IOS XR 5.3.1 version?

Aleksandar Vidakovic
Cisco Employee

hi Anwar,

why would you need the 5.3.1 Engineering SMU? Our generic recommendation for all asr9k deployments is 5.3.4 or 6.1.4:

https://supportforums.cisco.com/document/13212901/ios-xr-release-strategy-and-deployment-recommendation

regards,

/Aleksandar

Carlos A. Silva
Beginner

Hi, Eddie:

I would like to ask you if this part number:

A9K-RSP880-RL-TR

will work with versions 5.3.2 and 5.3.4.

Thanks!

c.

ys173p
Beginner

Hi Eddie,

Thanks for your document, 

-Is this MOP is valid for RSP440 TR to RSP880 TR with SW 5.3.3? as my understanding no SMU should be removed since router is on 5.3.3

-How about variable setting, all should be done during migration?

Thanks

ntperdana
Beginner

Hi,

 

I was wondering if anyone has similar experinces with me as follows.

 

Oneof our customers currently uses RSP440-SE for their BNG network. They want to buy RSP880 and was wondering if we do the upgrade process above, would all the licenses be automatically copied to the new RSP880 during RSP synch? 

 

Thanks.

Yufeng Xu
Cisco Employee
Hi Eddie, Is this procedure applicable for RSP880-LT as well? Thanks, William
jesimard@cisco.com
Cisco Employee

For the rollback in case of problems, can we follow the same procedure in reverse order (to avoid impact on traffic) or is the only option to pull the 880s out and insert the 440s back in (basically reload)?

alvaro.orrego
Beginner

Hello. Some time has passed since this was published and now I have a few concerns regarding software versions.

 

Scenario is like this:

I have 2 routers running RSP440-TR with cXR 6.1.4 that will be upgraded to RSP880-TR so that the MOD80 with 20x1G and 4x10G I currently have will be replaced by MOD400-CM with 2x100G and 20x10G, after the RSP upgrade is successful, of course.

In other hand, the recommended target version of cXR for me from Advanced Services is now 6.2.3. I assume eXR is out of the question because of the 20x10G-CM MPAs.

 

My questions are:

- I currently don't know what code are the RSP880 running since they just arrived from factory. Do I have to prepare them with 6.1.4 in advance, or can I insert the brand new RSP880 right out the box in step 4?

- Upgrade to 6.2.3 should be done before or after RSP880 are up and running?

- I wish to keep the same SNMP Ifindex for TenGigE interfaces after replacing 4x10G on 0/0/1/X with 20x10G on the same location on the new MOD400. Is that possible?

 

I really hope someone can answer this on time. Thanks!

Content for Community-Ad

This widget could not be displayed.