EXOS Stacking and sys-recovery-level
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Get Direct Link
- Report Inappropriate Content
‎02-18-2016 12:01 PM
Over the last time i have some problems that X450-G2 Stacks and mysterious reboots. Through deeper investigation sometime we have some problems with daemons (for example netlogin / policy daemon). Another reboot was happening as we replace a member stack unit.
Currently i suspect the sys-recovery-level which is set to "reset". Is it possible that if some error happens on a stack member that the master unit of a stack is reseting (because of sys-recovery-level) ??
Does it make sense to change sys-recovery-level from reset to none? Any experience which that on recent EXOS Stacks ?
Mainly i use the EXOS 16.1.x version.
recommendations are welcome.
Currently i suspect the sys-recovery-level which is set to "reset". Is it possible that if some error happens on a stack member that the master unit of a stack is reseting (because of sys-recovery-level) ??
Does it make sense to change sys-recovery-level from reset to none? Any experience which that on recent EXOS Stacks ?
Mainly i use the EXOS 16.1.x version.
recommendations are welcome.
4 REPLIES 4
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Get Direct Link
- Report Inappropriate Content
‎02-19-2016 05:14 AM
Hi Prashanth,
thanks for the answer - now i am able to estimate what is best for my environment (regarding sys-recovery-level).
Regards
thanks for the answer - now i am able to estimate what is best for my environment (regarding sys-recovery-level).
Regards
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Get Direct Link
- Report Inappropriate Content
‎02-18-2016 01:04 PM
Hi Mathias,
Check if the below article helps your query.
Sys-recovery-level options and their explanation
It is better to leave this setting to default in a stack as the switch resets the slot upon any HW failure or any critical slot failure messages.
Note: The explanation in the command reference guide is applicable to a summit stack as well!
Hope this helps!
Check if the below article helps your query.
Sys-recovery-level options and their explanation
It is better to leave this setting to default in a stack as the switch resets the slot upon any HW failure or any critical slot failure messages.
Note: The explanation in the command reference guide is applicable to a summit stack as well!
Hope this helps!
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Get Direct Link
- Report Inappropriate Content
‎02-18-2016 12:42 PM
Hi Prashanth,
my concern for this post is to understand the purpose and function of sys-recovery-level. What does this command do espacially on a EXOS Stack (for example X450-G2). in manual only the standard chassis / slot system is metioned.
Does it make sense to change the default setting of sys-recovery-level especially on a stack ?
Regards
my concern for this post is to understand the purpose and function of sys-recovery-level. What does this command do espacially on a EXOS Stack (for example X450-G2). in manual only the standard chassis / slot system is metioned.
Does it make sense to change the default setting of sys-recovery-level especially on a stack ?
Regards
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Get Direct Link
- Report Inappropriate Content
‎02-18-2016 12:28 PM
Hi Mathias,
Sys-recovery-level should not be a concern here. Because, this configuration would be triggered only for the errors related to the failure of hardware/ any slot failure messages.
Are you referring to any process crashes when you refer to the netlogin/policy daemon issues?
It would be interesting to analyze the logs prior to the reboot and understand the cause of the reboots.
Sys-recovery-level should not be a concern here. Because, this configuration would be triggered only for the errors related to the failure of hardware/ any slot failure messages.
Are you referring to any process crashes when you refer to the netlogin/policy daemon issues?
It would be interesting to analyze the logs prior to the reboot and understand the cause of the reboots.
