Disclosure: I don't have much exposure to debugs for fearing of crashing a device.
I know you can redirect output to a file, but wasn't sure if I ran the elusive "router destroyer" command "debug ip all" and redirected it to a file if it would cause the same havoc. documentation below seems to indicate, based on my interpretation, that the printing the actual content itself on the screen is the issue. I am pretty sure that this is due to the return of the information to a singular variable in memory (I have a slight background in programming). Then again if that was the case, I would think there suggestion of redirecting to a log buffer would not be advised, as I can imagine a log buffer is also a singular variable in memory storing the output of the debug.
In the end, my question simplified is the following:
Is it the CPU/Memories processing of the debug command that causes the router issue's or is it the output of that information to a user in the CLI session that causes issues?
per cisco documentation: https://www.cisco.com/c/en/us/support/docs/dial-access/integrated-services-digital-networks-isdn-channel-associated-signaling-cas/10374-debug.html#warn
📷 Warning: Excessive debugs to the console port of a router can cause it to hang. This is because the router automatically prioritizes console output ahead of other router functions. Hence if the router is processing a large debug output to the console port, it may hang. Hence, if the debug output is excessive use the vty (telnet) ports or the log buffers to obtain your debugs. More information is provided below.
No comments:
Post a Comment