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


Router Configuration and File Management

Basic Router Security and Access Control

IPSec

SNMP

Logging

NTP

Router Interfaces

IP Routing

Routing Policy and Firewall Filters

RIP

IS-IS

OSPF

BGP

MPLS

VPNs

IP Multicast



JUNOS Cookbook
Junos Cookbook (Cookbooks (OReilly))
ISBN: 0596100140
EAN: 2147483647
Year: 2007
Pages: 290
Authors: Aviva Garrett

Flylib.com © 2008-2020.
If you may any questions please contact us: flylib@qtcs.net