BGPD.CONF(5) BSD Programmer's Manual BGPD.CONF(5)NAMEbgpd.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 as-
sociated with each other and with specific protocols. Lines beginning
with `#' are comments.
Meta Syntax
Keywords and special characters that the parser expects exactly are dis-
played using the bold font. Parameters are specifying with underline.
Parameters shown in square brackets (`[' and `]') are used to show op-
tional keywords and parameters. The vertical bar (`|') is used to indi-
cate 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. Inter-
faces 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 speci-
fied 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 speci-
fied 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 con-
nection 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 fol-
lowing 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 speci-
fied. Interface specification may be necessary when the peer ad-
dress 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 advertis-
ing reachable routes to other EBGP peers. This keywords takes an
optional argument, which specifies number of iteration of the ad-
dition. 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 option-
al 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 speci-
fied, 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. Sub-
statements 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 in-
terface 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 be-
longs.
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. Possi-
ble substatements are as follows.
interface interface [attributes...] ;
Controls various attributes of sending or receiving RIP on spe-
cific interfaces. Multiple attributes can be specified in a sin-
gle rip statement.
The followings are the list of attributes.
noripin
Specifies that RIP packets received via the specified in-
terface 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 speci-
fied interfaces. The default is to send RIP on all in-
terfaces.
default originate
Specifies to advertise the RIPng default route with met-
ric 1 on the interface. If this attribute is specified,
the incoming default route on the interface will be ig-
nored.
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 ad-
vertised on any RIPng available interfaces despite of other spe-
cific 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 automat-
ically 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 aggre-
gated route. By default, bgpd doesn't advertise aggre-
gated 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 ALSObgpd(8)HISTORY
The bgpd.conf configuration file was first appeared in Toshiba IPv6 pro-
tocol stack kit. Older name was bgp6d.conf, but was renamed to be con-
sistent with the name of the command(bgpd).
Some part of this document was derived from the GateDaemon(gated) manual
document.
KAME May 17, 1998 6
