This link should give you a good overview of all the types of redundancy available for 6500 supervisors.
Jon thanks for your reply.Actually i m confused about this terms.let me put in this way.
if two sups are present in the chassis will they automatically become redundant..?
if not what will be their status..?
what does this commands makes impact i.e rpr,rpr+ etc on the sups,why we are using this commands.I havent work much on redundant chassis.
When 2 sups are inserted into a chassis presuming they have exact same hardware the first sup coming online will be in active stats and other sup will turn into standby state automatically running default redundancy mode and incase they have hardware mismatch then the second sup will be in UNKNOWN state or OTHER state.
When 2 supervisors have different IOS image then they will default run RPR mode but if the 2 sups coming online have same IOS image then they will rurn SSO by default (if the image supports sso) or else they will run rpr+ mode by default.
RPR supports a switchover time of 2 to 4 minutes and RPR+ supports a switchover time of 30 to 60 seconds and sso is even faster.
When RPR+ mode is used, the redundant supervisor engine is fully initialized and configured, which shortens the switchover time. The active supervisor engine checks the image version of the redundant supervisor engine when the redundant supervisor engine comes online. If the image on the redundant supervisor engine does not match the image on the active supervisor engine, RPR redundancy mode is used.
If you have any doubts please come with the same.
*Pls rate all helpfull post
In addition to Ankur's post, after RPR+ we instroduce SSO with SRM. SSO is a stateful switchover redundancy for L2 implemented on Sup engines. RPR+ switchover time was 30-60 seconds and want't scaling good in the network scennrio where HA requirement was very high. SSO give 0-3 seconds of failover at L2. With SSO, SRM was used for L3 MSFC redundancy but the switchover time was 30-60 seconds for the failover due to which L3/ routing table convergence was a kind of slow, neighbor adjacencies were lost, routing tables were learned again..
Starting with IOS 12.2(18)SX we have NSF with SSO for L2/L3 failover which gives Sub-mili second failober both a L2 and L3.An NSF-aware router understands the NSF graceful restart mechanisms: it does not tear down its neighbor relationships with the NSF-capable restarting router, and can help a neighboring NSF-capable router restart thus avoiding unnecessary route flaps and network instability
Thanks for the reply.As i was going through the document i came accross the requirements it mentions that 2 sups are needed for this but i am confused that a protocol should be there to syn the information.what is this protocol.
The protocol which that link is talking about is redundancy protocol which could be either SSO/RPR+/RPR.
As I mentioned in my previous post if your both sups have same IOS release and they support SSO (12.218SX) it will automatically work for SSO or else RPR+ but if you both sups does not have same IOS release it will work with RPR mode only.
*Pls rate all helpfull post
Thanks for u r reply i am getting it now.just one more question what does this commands have the impact.
mode cpu etc
During normal operation, the startup-config and config-registers configuration are synchronized by default between the two supervisor engines. In a switchover, the new active supervisor engine uses the current configuration.
To manually synchronize the configurations used by the two supervisor engines you have tp use these commands.
So does this mean that RPR / RPR+ will kick in even when the images in both the SUPs are in different flashes. eg. SUP-1 in bootflash and SUP-2 in Slot0/Disk0 etc. and whether the same will work with different flash sizes. 32 and 64 etc.
BR // Rajiv