bgpd.conf.5

同时支持IPv4和IPv6的BGP协议实现

.Ic 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.
.\"
.Bl -tag -width Ds -compact
.It Xo
.Ic (peer \(ba client) Ar host
.Op Ic interface Ar interface
.Op Ic no synchronization
.Op Ic nexthopself
.Op Ic lcladdr Ar localaddress
.Ic ;
.Xc
Specifies the IPv6 address of an individual IBGP peer.
If the peer is specified with the keyword
.Ic 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
.Ic 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
.Ic nexthopself
is specified,
.Nm bgpd
puts its own address to the next hop field of
an MP_REACH_NLRI attributes when advertising a new route to the peer.
.Ic lcladdr
and
.Ar 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.
.El
.\"
.\"
.It Xo
.Ic export proto bgp as Ar as_number
.Ic { Ar export_list
.Ic };
.Xc
Controls exportation to EBGP.
.Ar as_number,
the autonomous system number of the EBGP peer, must be specified.
The peer AS has to be defined by a
.Ic group type external peeras
substatement of the
.Ic bgp
statement somewhere before the
.Ic export
statement.
The
.Ar as_number
may not be the AS number to which the bgpd itself belongs.
.Pp
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.
.Bl -tag -width Ds -compact
.It Xo
.Ic proto direct interface Ar interface
.Ic {all;};
.Xc
Routes to directly attached interfaces.
.\"
.It Xo
.Ic proto bgp as Ar as_number
.Ic {all;};
.Xc
Routes advertised by the EBGP peer specified by the
.Ar as_number .
.\"
.It Xo
.Ic proto rip {all;};
.Xc
Routes advertised via RIPng.
.\"
.It Xo
.Ic proto ibgp {all;};
.Xc
Routes advertised via IBGP.
.El
.El
.Sh The RIPng Related Statements
.Bl -tag -width Ds -compact
.It Xo
.Ic rip (yes \(ba no) { Ar substatements
.Ic };
.Xc
Enables or disables RIPng.
By default RIPng is disabled.
Possible substatements are as follows.
.\"
.It Xo
.Ic interface Ar interface Op Ar attributes...
.Ic ;
.Xc
Controls various attributes of sending or receiving RIP on specific
interfaces.
Multiple attributes can be specified in a single
.Ic rip
statement.
.Pp
The followings are the list of attributes.
.Bl -tag -width Ds -compact
.It Ic 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.
.\"
.It Ic noripout
Specifies that no RIP packets will be sent on the specified
interfaces.
The default is to send RIP on all interfaces.
.\"
.It Ic 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.
.\"
.It Ic metricin Ar 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.
.El
.\"
.It Ic sitelocal (yes \(ba no);
Specifies whether or not site-local prefixes should be accepted and
advertised via RIPng.
If
.Ic 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
.Ic 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
.Nm 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.
.El
.\"
.Sh The Route Aggregation Statements
.Bl -tag -width Ds -compact
.It Xo
.Ic aggregate Ar prefix
.Ic { Ar substatements
.Ic };
.Xc
.Pp
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.
.Pp
There are two type of substatements that can be appeared in an
.Ic 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.
.Pp
.Bl -tag -width Ds -compact
.It Xo
.Ic proto direct interface Ar interface
.Ic {all;};
.Xc
The
.Ar substatement
specifies interfaces to advertise aggregated route.
By default, bgpd doesn't advertise aggregated routes on any interface
even if there is an
.Ic aggregate
statement.
To advertise aggregated routes, you should explicitly
specify the interface by this
.Ar substatement .
.It Xo
.Ic explicit { Ar prefix_1; prefix_2; ..., prefix_N;
.Ic };
.Xc
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
.Ic aggregate
statement.
.Pp
In this list, each prefix is specified in the same form of the
.Ic filterin
statement.
.El
.El
.\"
.Sh EXAMPLE
.Bd -literal -offset
#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;};
};
.Ed
.\"
.Sh SEE ALSO
.Xr bgpd 8
.\"
.Sh HISTORY
The
.Nm
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).
.Pp
Some part of this document was derived from the GateDaemon(gated)
manual document.