Tracing BGP Protocol Traffic

Problem

You want to keep a running log of BGP protocol information so you can track any problems with your BGP peers.

Solution

When performing ongoing monitoring of BGP operations, set up tracing options (or traceoptions for short) to track BGP state changes globally for all BGP groups:

[edit protocols bgp] aviva@RouterF# set traceoptions flag state detail aviva@RouterF# set traceoptions file bgp-trace world-readable

To turn off BGP tracing, remove the traceoptions statement from the configuration:

[edit protocols bgp] aviva@RouterF# delete traceoptions

You can also deactivate the statement:

[edit protocols bgp] aviva@RouterF# deactivate traceoptions

Discussion

Its good practice to trace high-level BGP operations on an ongoing basis. If and when a problem arises, you can examine the resulting log to get the necessary information about the source of the problem. Then you can enable more detailed traceoptions flags to pinpoint the causes.

This recipe sets up tracing of BGP peer state exchanges, saving them to the file bgp-trace. The word-readable option allows anyone logged in to the router to read the file. This file is created on the routers hard disk in the directories /var/log (on M-series and T-series routers) and /cf/var/log (on J-series routers). The detail option provides additional information about abnormal events. This configuration creates 10 logfiles (the default) and uses the default trace file size of 10 MB, which is generally a useful size for logging events over a long period of time. If your BGP network is large, you might want to increase the file size so that you have time to review or archive the logfiles before the files start overwriting each other:

[edit protocols bgp] aviva@RouterF# set traceoptions file size 100M aviva@RouterF# show traceoptions { file bgp-trace size 100m world-readable; flag state detail; flag open; }

The following output shows the log results when a BGP peer drops and then re-establishes a session:

aviva@RouterF> show log bgp-trace Aug 6 19:07:18 trace_on: Tracing to "/var/log/bgp-trace" started Aug 6 19:07:53 bgp_recv: peer 10.0.31.1 (External AS 65505): received unexpected EOF Aug 6 19:07:53 bgp_peer_close: closing peer 10.0.31.1 (External AS 65505), state is 6 (Established) Aug 6 19:07:53 bgp_event: peer 10.0.31.1 (External AS 65505) old state Established event Closed new state Idle Aug 6 19:07:53 bgp_event: peer 10.0.31.1 (External AS 65505) old state Idle event Start new state Active Aug 6 19:07:57 bgp_event: peer 10.0.31.1 (External AS 65505) old state Active event Open new state OpenSent Aug 6 19:07:57 bgp_event: peer 10.0.31.1 (External AS 65505) old state OpenSent event RecvOpen new state OpenConfirm Aug 6 19:07:57 bgp_event: peer 10.0.31.1 (External AS 65505) old state OpenConfirm event RecvKeepAlive new state Established

The first line shows the abnormal event receive unexpected EOF when the BGP peer connection drops. The following lines show the transition through various states as BGP establishes the connection, from Idle, to Active, OpenSent, and OpenConfirm, and finally to Established.

Another useful tracing flag for ongoing monitoring of BGP is open, used to track when peer connections are established and torn down:

[edit protocols bgp] aviva@RouterF# set traceoptions flag open

When the BGP peer session drops and re-establishes, the log contains traces of the BGP Open messages:

aviva@RouterF> show log bgp-trace Aug 6 19:17:45 trace_on: Tracing to "/var/log/bgp-trace" started Aug 6 19:18:05 bgp_recv: peer 10.0.31.1 (External AS 65505): received unexpected EOF Aug 6 19:18:05 bgp_peer_close: closing peer 10.0.31.1 (External AS 65505), state is 6 (Established) Aug 6 19:18:05 bgp_event: peer 10.0.31.1 (External AS 65505) old state Established event Closed new state Idle Aug 6 19:18:05 bgp_event: peer 10.0.31.1 (External AS 65505) old state Idle event Start new state Active Aug 6 19:18:09 Aug 6 19:18:09 BGP RECV 10.0.31.1+4379 -> 10.0.31.2+179 Aug 6 19:18:09 BGP RECV message type 1 (Open) length 45 Aug 6 19:18:09 bgp_event: peer 10.0.31.1 (External AS 65505) old state Active event Open new state OpenSent Aug 6 19:18:09 bgp_send: sending 45 bytes to 10.0.31.1 (External AS 65505) Aug 6 19:18:09 Aug 6 19:18:09 BGP SEND 10.0.31.2+179 -> 10.0.31.1+4379 Aug 6 19:18:09 BGP SEND message type 1 (Open) length 45 Aug 6 19:18:09 bgp_event: peer 10.0.31.1 (External AS 65505) old state OpenSent event RecvOpen new state OpenConfirm Aug 6 19:18:09 bgp_event: peer 10.0.31.1 (External AS 65505) old state OpenConfirm event RecvKeepAlive new state Established

When debugging BGP, you can set one or more of the following trace flags to monitor BGP information:

[edit protocols bgp] aviva@RouterF# show traceoptions flag ? Possible completions: all Trace everything damping Trace BGP damping information general Trace general events keepalive Trace BGP keepalive packets normal Trace normal events open Trace BGP open packets packets Trace all BGP protocol packets policy Trace policy processing refresh Trace BGP refresh packets route Trace routing information state Trace state transitions task Trace routing protocol task processing timer Trace routing protocol timer processing update Trace BGP update packets

You can configure BGP traceoptions globally, per group, or per peer. For ongoing monitoring, enable them at the global level, as in this recipe. For more focused traceoptions for when you e troubleshooting a known problem, enable tracing at the appropriate level, either for an IBGP or EBGP group or for a specific peer. For example, the following commands log route changes from an EBGP peer:

[edit protocols bgp] aviva@RouterF# set group session-to-AS65505 traceoptions file bgp-log-CustomerA world-readable aviva@RouterF# set group session-to-AS65505 TRaceoptions flag route aviva@RouterF# set group session-to-AS65505 traceoptions flag state aviva@RouterF# show group session-to-AS65505 { type external; traceoptions { file bgp-log-CustomerA world-readable; flag route; flag state; } description "EBGP to Customer A"; …

The JUNOS software also provides a BGP configuration command, log-updown, to log peer state transitions to a standard system logging file (the default file is named messages):

[edit protocols bgp] aviva@RouterF# set log-updown

This command enables the logging globally, but you can also set it for an individual BGP group or peer. This is a useful way to keep basic system logging information in one file so you have to look only in one place to check router status. One disadvantage of this, however, is that BGP log entries are mixed into a system-wide logfile, so the BGP-specific messages can be buried in many other messages.

If you need to disable BGP tracing, either remove the TRaceoptions statement from the configuration with the delete configuration mode command or simply deactivate it. Deactivation leaves the statements in the configuration, but they are ignored when you issue a commit command. When you need to turn on BGP tracing again, restoring a deactivated portion of the configuration is very quick:

[edit protocols bgp] aviva@RouterF# activate traceoptions aviva@RouterF# commit

See Also

Recipe 5.10