BGPD.CONF(5)

NAME
bgpd.conf - bgpd configuration file

SYNOPSIS
/usr/local/v6/etc/bgpd.conf

DESCRIPTION
The bgpd config file consists of a sequence of statements terminated by a semi-colon (`;'). Statements are composed of tokens separated by white space, which can be any combination of blanks, tabs and newlines. This structure simplifies identification of the parts of the configuration associated with each other and with specific protocols. Lines beginning with ‘#’ are comments.

Meta Syntax
Keywords and special characters that the parser expects exactly are displayed using the bold font. Parameters are specifying with underline. Parameters shown in square brackets (`[' and `]') are used to show optional keywords and parameters. The vertical bar (`|') is used to indicate between a choice of optional parameters. Parentheses (`(' and `)') are used to group keywords and parameters when necessary.

Interface specification
There are some statements that may or have to specify interface. Interfaces are specified in the form of "name unit", such as lo0 and ep1.

Specifying Log Level
    log option...; Specify debug messages to be printed out. Each option usually specifies a subset of the messages to be printed. If an option begins with no, it means that the set of the messages that are specified by the option will not be printed. For example, `all norip' means that all the messages except RIPng related ones will be printed. Valid options are aspath, bgpstate, bgpconnect, bgpinput, bgpoutput, bgproute, bgp, interface, inet6, rip, route, filter, timer, and all. The bgp option means all the BGP related options to be printed.

Specifying Dump File
    dumpfile filename; Specifies the name of the dump file (see bgpd(8)).

Specifying Filters
The following four route filters can be specified, each of which is for a RIPng interface or a BGP peer (see below).
filterin prefix;
    Specifies incoming route filtering. If an incoming route on the interface or from the peer matches the specified prefix, it will be ignored and will not be installed in the kernel.

    The prefixes are specified in the form of ‘address/prefix_length,’ such as 3ffe:509::/32 and 3ffe:501:100f::/48. The special string default can also be specified as a prefix, which means the default route. Note that the semantics of default is different from the semantics of ::/0. The former is to specify filtering the default route (exact match), but the latter is to specify filtering all routes that match ::/0, that is, filtering all incoming routes.
restrictin prefix;
    Specifies incoming route restriction. An incoming route on the interface or from the peer will be ignored unless it matches prefix. If this attribute is specified for more than one prefix, an incoming route will be required to match at least one prefix of them. Like the filterin attribute, the special string default can be specified as a prefix, which means that all non default routes will be ignored on the interface or from the peer.
filterout prefix;
    Specifies outgoing route filtering. If an outgoing route on the interface or to the peer matches the specified prefix, it will not be advertised. The special string default can also be specified for this attribute, which means that the default route will not be advertised on the interface nor to the peer. Note that the semantics of filterout ::/0 is different from the semantics of filterout default. The former means that all routes that match the prefix ::/0 will not be advertised on the interface. For a RIPng interface, it thus has the same meaning of the noripout. attribute.
restrictout prefix;
    Specifies outgoing route restriction. An outgoing route on the interface or to the peer will not be advertised unless it matches prefix. If this attribute is specified for more than one prefix, an outgoing route will be required to match at least one prefix of them. If the special string default is specified as a prefix, it means that only the default route will be advertised on the interface nor to the peer.

The BGP Related Statements
    autonomoussystem as_number; Sets the autonomous system number of this router to be autonomous system. This statement is required if BGP is in use. The AS number is assigned by the Network Information Center (NIC).
bgpsbsize size;
    Sets the size of socket write buffer for each BGP socket.
routerid router_id;
    Sets the router identifier for use by the BGP and OSPF protocols. The default is the address of the first interface encountered by bgpd except the loopback address(127.0.0.1).
clusterid cluster_id;
    Sets the cluster identifier for use as a BGP route reflector. The default is the address of the first interface encountered by bgpd except the loopback address(127.0.0.1).
IamRouteReflector;
    Specifies to act as a route reflector.
holdtime seconds;
    Specifies the BGP holdtime value to use when negotiating the connection with this peer, in seconds. According to BGP, if bgpd does not receive a keepalive, update, or notification message within the period specified in the Hold Time field of the BGP Open message, then the BGP connection will be closed. The value must be either 0 (no keepalives will be sent) or at least 3. The default value is 240 according to the RFC 1771.
    bgp (yes | no) { substatements }; Enables or disables BGP. By default BGP is disabled. The following two substatements can be appeared in the bgp statement.
group type external peeras remote_as_number {
        peer host [interface interface] [preference preference] [prepend [iteration]] [no synchronization] [lcladdr localaddress] [filters...]; };

    Specifies the IPv6 address and AS number of an individual EBGP peer. The interface on which the peer exists may also be specified. Interface specification may be necessary when the peer address is a link-local address. If the optional keyword preference is specified followed by a number, bgpd uses the value as the value of local preference when advertising reachable routes from the peer via IBGP. Currently, the value can only be specified per peer base. If the optional keyword prepend is specified, bgpd adds its AS number to the as path when advertising reachable routes to other EBGP peers. This keywords takes an optional argument, which specifies number of iteration of the addition. If the argument is omitted, bgpd treats it as 1. Note that prepend 1 makes each advertised AS path longer than usual. Typically, this keywords does not have to be set. If the optional keyword no synchronization is specified, bgpd will export each EBGP route to the peer without waiting for synchronization with RIPng for the route. The optional keyword lcladdr specifies the local(source) IPv6 address to connect the peer. If the node has multiple IPv6 addresses that can be used as the source address, the keyword should be specified. If a list of filters is specified, each of the filters is applied to the peer according to the semantics of each filter described above.
    group type internal [routerid router_id] { substatements }; Specifies a set of IBGP peers. The BGP identifier of the peer can be specified with the keyword routerid, but bgpd doesn't use the value for any significant purpose, e.g. authentication. Substatements include information of individual peers. Possible substatement is as follows.
        (peer | client) host [interface interface] [no synchronization] [nexthopself] [lcladdr localaddress]; Specifies the IPv6 address of an individual IBGP peer. If the peer is specified with the keyword client, bgpd will treat it as a route reflector client. Otherwise, the peer will be treated as a normal IBGP peer. The interface on which the peer exists may also be specified. Interface specification may be necessary when the peer address is a link-local address. If the optional keyword no synchronization is specified and bgpd act as a route reflector for the peer, it will reflect each IBGP route without waiting for synchronization with RIPng for the route. If the optional keyword nexthopself is specified, bgpd puts its own address to the next hop field of an MP_REACH_NLRI attributes when advertising a new route to the peer. lcladdr and filters can be specified for an IBGP peer as well as for an EBGP peer. The semantics of the keyrwords are same as ones for an EBGP peer.
    export proto bgp as as_number { export_list }; Controls exportation to EBGP. as_number, the autonomous system number of the EBGP peer, must be specified. The peer AS has to be defined by a group type external peeras substatement of the bgp statement somewhere before the export statement. The as_number may not be the AS number to which the bgpd itself belongs.

    The export list specifies export based on the origin of a route and the syntax varies depending on the source. Followings are the possible elements of the list.
        proto direct interface interface {all;}; Routes to directly attached interfaces.
        proto bgp as as_number {all;}; Routes advertised by the EBGP peer specified by the as_number.
        proto rip {all;}; Routes advertised via RIPng.
        proto ibgp {all;}; Routes advertised via IBGP.

The RIPng Related Statements
    rip (yes | no) { substatements }; Enables or disables RIPng. By default RIPng is disabled. Possible substatements are as follows.
    interface interface [attributes...]; Controls various attributes of sending or receiving RIP on specific interfaces. Multiple attributes can be specified in a single rip statement.

    The followings are the list of attributes.
    noripin
        Specifies that RIP packets received via the specified interface will be ignored. The default is to listen to RIP packets on all non-loopback interfaces.
    noripout
        Specifies that no RIP packets will be sent on the specified interfaces. The default is to send RIP on all interfaces.
    default originate
        Specifies to advertise the RIPng default route with metric 1 on the interface. If this attribute is specified, the incoming default route on the interface will be ignored.
    metricin metric
        Specifies metric which is added to any incoming RIPng routes before route calculation. Its value must be no less than 1 and no greater than 16.
sitelocal (yes | no);
    Specifies whether or not site-local prefixes should be accepted and advertised via RIPng. If yes is specified, all site-local prefixes will be accepted and advertised on all RIPng available interfaces unless a specific filter will filter them. If no is specified, any site-local prefixes will never be accepted nor advertised on any RIPng available interfaces despite of other specific filters. Note that bgpd does not care about site boundary. When it receives a site-local prefix on an interface and if it should be accepted by this statement, the prefix will be automatically advertised on all other interfaces, even if the receiving node is a site boundary. For this reason, site-local addresses are not allowed by default.

The Route Aggregation Statements
    aggregate prefix { substatements };

    Specifies route aggregation. Routes that match the specified prefix will be advertised in the aggregated form. That is, only the specified prefix will be advertised instead of each specific prefix.

    There are two type of substatements that can be appeared in an aggregate statement. One is specification of interfaces on which aggregated routes are advertised, and the other is to describe routes that should not be aggregated.

        proto direct interface interface {all;}; The substatement specifies interfaces to advertise aggregated route. By default, bgpd doesn't advertise aggregated routes on any interface even if there is an aggregate statement. To advertise aggregated routes, you should explicitly specify the interface by this substatement.
        explicit { prefix_1; prefix_2; ..., prefix_N; }; Exception to the aggregation can be specified as a list. Prefixes in the list will be advertised even if they match the prefix specified in the aggregate statement.

        In this list, each prefix is specified in the same form of the filterin statement.

EXAMPLE

    #AS number, which is mandatory for BGP4+
    autonomoussystem 2500;
    #RIPng settings
    rip yes {
    	# If you want to accept and advertise site-local addresses,
    	# uncomment below.
    	# XXX: there is no site-boundary consideration implemented.
    	#      be careful to uncomment this!
    	#sitelocal yes;
    	# It's better to add an appropriate cost for the interface
    	# since the serial line is slow
    	interface ntwo0 metricin 5;
    	# Typical setting for stab organizations;
    	#   advertise the default route only
    	#   listen to their prefix only
    	interface gif0 default originate
    			restrictout default
    			restrictin 3ffe:505::/32;
    	# Stop RIPng; EBGP only for the interface(see below)
    	interface gif1 noripin noripout;
    };
    # Aggregation settings for upriver routers of RIPng
    aggregate 3ffe:501:400::/40 {
    	proto direct interface ntwo1 {all;};
    	proto direct interface gif3 {all;};
    	proto direct interface gif4 {all;};
    };
    # Aggregate setting for an EBGP peer
    aggregate 3ffe:500::/24 {
    	proto direct interface gif1 {all;};
    };
    # BGP4+ settings
    bgp yes {
    	# IBGP peer:
    	# `no synchronization' means to advertise routes from IBGP w/o sync
    	# with RIPng
    	# specify the local address since we have multiple global addresses.
    	group type internal {
    		peer 3ffe:501:0:ffff:2a0:24ff:fe48:7a3c no synchronization
    		  lcladdr 3ffe:501:0:401:200:e8ff:fed5:8923;
    	};
    	# EBGP peer(global address)
    	group type external peeras 65500 {
    		peer 3ffe:ff00::1;
    	};
    	# EBGP peer(link-local address)
    	# in this case, the interface must be specified.
    	group type external peeras 65501 {
    		peer fe80::2a0:24ff:fe66:1350 interface pvc0;
    	};
    };
    # export list
    export proto bgp as 65500 {
    	proto rip {all;};
    	proto ibgp {all;};
    	proto bgp as 65501 {all;};
    };
    export proto bgp as 65501 {
    	proto direct interface de0 {all;};
    };

SEE ALSO
bgpd(8)

HISTORY
The bgpd.conf configuration file was first appeared in Toshiba IPv6 protocol stack kit. Older name was bgp6d.conf, but was renamed to be consistent with the name of the command(bgpd).

Some part of this document was derived from the GateDaemon(gated) manual document.