[dev] Continued Discussion of Error Codes for FRR
jchen1 at paloaltonetworks.com
Thu Aug 23 11:06:44 EDT 2018
It is good to know there are plan to do it. Our customers are getting increasing unhappy when we always ask them to reproduce an issue in order to get debug information. ;-)
I have done it before. If need help, let us know, we would love to contribute in any way.
On 8/23/18, 6:25 AM, "Donald Sharp" <sharpd at cumulusnetworks.com> wrote:
We've talked about implementing something like this. Just no-one has done it.
On Wed, Aug 22, 2018 at 1:50 PM, Jia Chen <jchen1 at paloaltonetworks.com> wrote:
> Hi Donald, All,
> On another note about inline trace to help live debug, to have a light weight trace always turned on. It has to be light weight, so it does not take much CPU.
> The main idea is to write raw data to memory directly, delay time-consuming operation like formatting, string, etc to display time. For example, IPv4 address will be an int when write to memory, only shows as “10.1.1.1/24” at later display.
> The problem to solve is following scenario:
> When BGP/IS-IS has a bug in production. The detailed log is not enabled. Therefore, to get the debug info, the debug log needs to be enabled first(at proper level), and then the problem need to be reproduced. Usually it is hard to do, and some bug can never be reproduced. On another hand, if the trace is always on, it leaves behind a trace, most time should be enough to get to the root cause of a problem already.
> If you think, there is a value, I can start design for BGP or IS-IS first for example, and develop a little later (by us). Of course, if there is already something similar, please let us know.
> On 8/22/18, 8:58 AM, "dev on behalf of Donald Sharp" <dev-bounces at lists.frrouting.org on behalf of sharpd at cumulusnetworks.com> wrote:
> Notes from meeting:
> 1) Having log messages that we can track down to individual error
> messages is a requirement as that end users may want to track what to
> do on a per message basis.
> 2) Having log messages that can be tracked uniquely to a error message
> as it evolves over time is a requirement as that users will not want
> to keep track of this information from release to release.
> We've also come up with a starting document on when to use what type
> of log message:
> On Tue, Aug 21, 2018 at 12:58 PM, Donald Sharp
> <sharpd at cumulusnetworks.com> wrote:
> > All -
> > In today's technical meeting we spent quite a bit of time discussing
> > David's error code PR:
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_FRRouting_frr_pull_2841&d=DwIGaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=yetdj-aXQpuqTCJGs-93hOpK3740MIRXowfUNLByeos&m=I65nWtU6LZ2pnlAmgBoQFOI3Ammecj0PIANrGCm69jU&s=O3pa4eIMVC2BQYQ_lnRIDSqZaZSJ-fjEbT4Sw2J0fIU&e=
> > Discussion centered around understanding out what it was and how we
> > want FRR to work with error codes. Due to time constraints we decided
> > to continue the discussion in a new meeting. This meeting will be
> > held on Aug 22, 9:30 am EDT tomorrow. If you are interested please
> > let me know and I'll add you to the meeting.
> > donald
> dev mailing list
> dev at lists.frrouting.org
More information about the dev