06-13-2020 07:48 AM
Hi, All:
I'm installing an ASR 9912 from scratch for the first time. Because of an IOS downgrade and SMUs, I've seen it boot 3 times and every time it starts with RP1 as the primary processor. I've software tested redundancy switchover and everything seems to be fine, as far as I can tell.
I thought I'd ask: is is normal for RP1 to be the primary every time it boots up? I have never seen it before with an ASR9000. Maybe a command controls this now. Any ideas?
Thanks!
/c.
06-13-2020 03:11 PM
That is odd, RP0, specifically RP0 on rack0, is given preference in ASR9K (as well as CRS). In both platforms there is a timer that other RPs have to wait for RP0 to start, if RP0 doesn't start and isn't detected by the other RPs within that time then they will assume mastership. It's possible RP0 took longer to reload or to boot back up and validate its MBI.
Note I can't tell you the time the RPs wait for RP0 because that has changed over the years and between ASR9K and CRS.
Sam
06-15-2020 08:03 AM
06-18-2020 12:27 PM
Sorry my response was for 32-bit, and you are running 64-bit where I just found that the behavior is different.
active RP elect when boot up depends on which RP is 1st boot, it doesn’t have mandatory sequence that must RP0 boot up 1st then boot up RP1, a possibility is RP1 booted up before RP0 start booting, and RP0 detected RP1 when it booting up and try to acquire master
So its all about which card is quicker to boot, no timer to wait for RP0 in 64-bit as multichassis systems don't exist in 64-bit.
Sam
06-18-2020 12:33 PM
Also what happens if RP1 is active and you do the admin reload rack 0? Do you get the same result?
It makes sense when RP0 is active and you reload as we would want to reload all other cards first before the active RP.
Sam
06-18-2020 01:08 PM
06-19-2020 08:22 AM
I'll let Yuriry the TAC engineer respond further via email, but from what I can tell eXR behaves differently and it appears to be behaving appropriately here. Why it is always RP1 is something we will raise with BU though to double check, I'll work with him on that request.
One test to perform is to physically change RP0 and RP1 and see if the issue follows the hardware or still behaves the same with RP1 always taking over.
Sam
06-19-2020 08:50 AM
06-19-2020 11:41 AM - edited 06-19-2020 11:42 AM
I don’t know what to say. I guess, one of the RPs is just faster than the other.
We switched them and the same RP became active.
RP/0/RP0/CPU0:XXXXXX#show platform
Fri Jun 19 13:32:13.259 CDT
Node Type State Config state
--------------------------------------------------------------------------------
0/RP0/CPU0 A99-RP3-TR(Active) IOS XR RUN NSHUT <--
0/RP1/CPU0 A99-RP3-TR(Standby) IOS XR RUN NSHUT
0/FT0 ASR-9912-FAN OPERATIONAL NSHUT
0/FT1 ASR-9912-FAN OPERATIONAL NSHUT
0/FC0 A99-SFC3 OPERATIONAL NSHUT
0/FC1 A99-SFC3 OPERATIONAL NSHUT
0/FC2 A99-SFC3 OPERATIONAL NSHUT
0/FC3 A99-SFC3 OPERATIONAL NSHUT
0/FC4 A99-SFC3 OPERATIONAL NSHUT
0/FC5 A99-SFC3 OPERATIONAL NSHUT
0/FC6 A99-SFC3 OPERATIONAL NSHUT
0/PT0 A9K-DC-PEM-V3 OPERATIONAL NSHUT
0/PT1 A9K-DC-PEM-V3 OPERATIONAL NSHUT
0/PT2 A9K-DC-PEM-V3 OPERATIONAL NSHUT
RP/0/RP0/CPU0:XXXXX#
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide