Junos traceoptions: Debug BGP Without Guessing

Junos deliberately discourages global debugging, but traceoptions are the exception that pays for itself during a BGP incident: they log, at protocol level, what a session is actually doing. The catch is that traceoptions are easy to leave running and quietly fill /var, and the output is only useful if you configure the right flags and a bounded file size. This article covers a production-safe traceoptions configuration, how to read it, and how to remove it cleanly when the incident ends.

The Configuration Shape

[edit protocols bgp group my-internal-group]
lab@vMX-2# set traceoptions file bgp-my-int-group
lab@vMX-2# set traceoptions file size 1m
lab@vMX-2# set traceoptions file files 10
lab@vMX-2# set traceoptions flag all

lab@vMX-2# show | compare
[edit protocols bgp group my-internal-group]
+     traceoptions {
+         file bgp-my-int-group size 1m files 10;
+         flag all;
+     }
lab@vMX-2# commit
commit complete

Three options do the safety work: size bounds each file, files bounds rotation (10 files of 1 MB keeps a hard ceiling of 10 MB), and placing traceoptions under a group or a single neighbour limits the blast radius - a neighbour-level trace logs only that session, which is what you usually want in a change window.

Reading the Output

show log bgp-my-int-group
show log bgp-my-int-group | last 50
show log bgp-my-int-group | match "state|error|Notification"
show log messages | last 20
monitor log messages

Useful flags for a session problem include the state machine and packet-level flags; flag all is convenient for finding an unknown problem but verbose, so narrow it once you know which stage is failing. Rotated files appear as .0, .1, .2 and so on - the newest is the unnumbered file.

What to Look For

• TCP versus BGP: if no session-level entries appear at all, the problem is transport (route, firewall, MTU) rather than BGP.
• Notification messages: a NOTIFICATION with a specific error code explains most idle-state transitions, and traceoptions is where you see the code rather than the summarised state.
• Keepalive and hold-time evolution: flapping that is invisible in show bgp summary is obvious in sequence.
• The messages log usually suffices: check show log messages before enabling traceoptions, because commit, interface and RPD complaints are logged there without any extra configuration.

Housekeeping

1. Never leave flag all with an unbounded file on a busy peering router; use a small size limit and a file count.
2. Remove the trace when done: delete protocols bgp group GROUP traceoptions, then commit, then delete /var/log/bgp-my-int-group* if the files are no longer needed.
3. Record the trace output in the ticket before deleting it - traceoptions survive reboots and are the easiest thing for the next engineer to leave running.
4. For routing-table scale problems, prefer show route summary, show bgp summary | no-more and RIB high-watermark messages in the log before resorting to traces.

Related reading: Junos BGP flap damping parameters, Junos interface flapping: hold time and damping and BGP neighbour flapping root causes.

原文链接：Network Curiosity: Junos BGP establishment troubleshooting