[dev] Continued Discussion of Error Codes for FRR

Jia Chen jchen1 at paloaltonetworks.com
Wed Aug 22 13:50:34 EDT 2018

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 “” 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 mailing list