BIRD User's Guide: Protocols

6. Protocols

6.1 BFD

Introduction

Bidirectional Forwarding Detection (BFD) is not a routing protocol itself, it is an independent tool providing liveness and failure detection. Routing protocols like OSPF and BGP use integrated periodic "hello" messages to monitor liveness of neighbors, but detection times of these mechanisms are high (e.g. 40 seconds by default in OSPF, could be set down to several seconds). BFD offers universal, fast and low-overhead mechanism for failure detection, which could be attached to any routing protocol in an advisory role.

BFD consists of mostly independent BFD sessions. Each session monitors an unicast bidirectional path between two BFD-enabled routers. This is done by periodically sending control packets in both directions. BFD does not handle neighbor discovery, BFD sessions are created on demand by request of other protocols (like OSPF or BGP), which supply appropriate information like IP addresses and associated interfaces. When a session changes its state, these protocols are notified and act accordingly (e.g. break an OSPF adjacency when the BFD session went down).

BIRD implements basic BFD behavior as defined in RFC 5880 ftp://ftp.rfc-editor.org/in-notes/rfc5880.txt (some advanced features like the echo mode or authentication are not implemented), IP transport for BFD as defined in RFC 5881 ftp://ftp.rfc-editor.org/in-notes/rfc5881.txt and RFC 5883 ftp://ftp.rfc-editor.org/in-notes/rfc5883.txt and interaction with client protocols as defined in RFC 5882 ftp://ftp.rfc-editor.org/in-notes/rfc5882.txt.

Note that BFD implementation in BIRD is currently a new feature in development, expect some rough edges and possible UI and configuration changes in the future. Also note that we currently support at most one protocol instance.

BFD packets are sent with a dynamic source port number. Linux systems use by default a bit different dynamic port range than the IANA approved one (49152-65535). If you experience problems with compatibility, please adjust /proc/sys/net/ipv4/ip_local_port_range

Configuration

BFD configuration consists mainly of multiple definitions of interfaces. Most BFD config options are session specific. When a new session is requested and dynamically created, it is configured from one of these definitions. For sessions to directly connected neighbors, interface definitions are chosen based on the interface associated with the session, while multihop definition is used for multihop sessions. If no definition is relevant, the session is just created with the default configuration. Therefore, an empty BFD configuration is often sufficient.

Note that to use BFD for other protocols like OSPF or BGP, these protocols also have to be configured to request BFD sessions, usually by bfd option.

Some of BFD session options require time value, which has to be specified with the appropriate unit: num s|ms|us. Although microseconds are allowed as units, practical minimum values are usually in order of tens of milliseconds.

protocol bfd [<name>] {
        interface <interface pattern> {
                interval <time>;
                min rx interval <time>;
                min tx interval <time>;
                idle tx interval <time>;
                multiplier <num>;
                passive <switch>;
        };
        multihop {
                interval <time>;
                min rx interval <time>;
                min tx interval <time>;
                idle tx interval <time>;
                multiplier <num>;
                passive <switch>;
        };
        neighbor <ip> [dev "<interface>"] [local <ip>] [multihop <switch>];
}

interface pattern [, ...] { options }

Interface definitions allow to specify options for sessions associated with such interfaces and also may contain interface specific options. See interface common option for a detailed description of interface patterns. Note that contrary to the behavior of interface definitions of other protocols, BFD protocol would accept sessions (in default configuration) even on interfaces not covered by such definitions.

multihop { options }

Multihop definitions allow to specify options for multihop BFD sessions, in the same manner as interface definitions are used for directly connected sessions. Currently only one such definition (for all multihop sessions) could be used.

neighbor ip [dev "interface"] [local ip] [multihop switch]

BFD sessions are usually created on demand as requested by other protocols (like OSPF or BGP). This option allows to explicitly add a BFD session to the specified neighbor regardless of such requests.

The session is identified by the IP address of the neighbor, with optional specification of used interface and local IP. By default the neighbor must be directly connected, unless the the session is configured as multihop. Note that local IP must be specified for multihop sessions.

Session specific options (part of interface and multihop definitions):

interval time

BFD ensures availability of the forwarding path associated with the session by periodically sending BFD control packets in both directions. The rate of such packets is controlled by two options, min rx interval and min tx interval (see below). This option is just a shorthand to set both of these options together.

min rx interval time

This option specifies the minimum RX interval, which is announced to the neighbor and used there to limit the neighbor's rate of generated BFD control packets. Default: 10 ms.

min tx interval time

This option specifies the desired TX interval, which controls the rate of generated BFD control packets (together with min rx interval announced by the neighbor). Note that this value is used only if the BFD session is up, otherwise the value of idle tx interval is used instead. Default: 100 ms.

idle tx interval time

In order to limit unnecessary traffic in cases where a neighbor is not available or not running BFD, the rate of generated BFD control packets is lower when the BFD session is not up. This option specifies the desired TX interval in such cases instead of min tx interval. Default: 1 s.

multiplier num

Failure detection time for BFD sessions is based on established rate of BFD control packets (min rx/tx interval) multiplied by this multiplier, which is essentially (ignoring jitter) a number of missed packets after which the session is declared down. Note that rates and multipliers could be different in each direction of a BFD session. Default: 5.

passive switch

Generally, both BFD session endpoinds try to establish the session by sending control packets to the other side. This option allows to enable passive mode, which means that the router does not send BFD packets until it has received one from the other side. Default: disabled.

Example

protocol bfd {
        interface "eth*" {
                min rx interval 20 ms;
                min tx interval 50 ms;
                idle tx interval 300 ms;
        };
        interface "gre*" {
                interval 200 ms;
                multiplier 10;
                passive;
        };
        multihop {
                interval 200 ms;
                multiplier 10;
        };

        neighbor 192.168.1.10;
        neighbor 192.168.2.2 dev "eth2";
        neighbor 192.168.10.1 local 192.168.1.1 multihop;
}

6.2 BGP

The Border Gateway Protocol is the routing protocol used for backbone level routing in the today's Internet. Contrary to other protocols, its convergence does not rely on all routers following the same rules for route selection, making it possible to implement any routing policy at any router in the network, the only restriction being that if a router advertises a route, it must accept and forward packets according to it.

BGP works in terms of autonomous systems (often abbreviated as AS). Each AS is a part of the network with common management and common routing policy. It is identified by a unique 16-bit number (ASN). Routers within each AS usually exchange AS-internal routing information with each other using an interior gateway protocol (IGP, such as OSPF or RIP). Boundary routers at the border of the AS communicate global (inter-AS) network reachability information with their neighbors in the neighboring AS'es via exterior BGP (eBGP) and redistribute received information to other routers in the AS via interior BGP (iBGP).

Each BGP router sends to its neighbors updates of the parts of its routing table it wishes to export along with complete path information (a list of AS'es the packet will travel through if it uses the particular route) in order to avoid routing loops.

For IPv6, it uses the standard multiprotocol extensions defined in RFC 4760 ftp://ftp.rfc-editor.org/in-notes/rfc4760.txt and applied to IPv6 according to RFC 2545 ftp://ftp.rfc-editor.org/in-notes/rfc2545.txt.

Route selection rules

BGP doesn't have any simple metric, so the rules for selection of an optimal route among multiple BGP routes with the same preference are a bit more complex and they are implemented according to the following algorithm. It starts the first rule, if there are more "best" routes, then it uses the second rule to choose among them and so on.

Prefer route with the highest Local Preference attribute.
Prefer route with the shortest AS path.
Prefer IGP origin over EGP and EGP origin over incomplete.
Prefer the lowest value of the Multiple Exit Discriminator.
Prefer routes received via eBGP over ones received via iBGP.
Prefer routes with lower internal distance to a boundary router.
Prefer the route with the lowest value of router ID of the advertising router.

IGP routing table

BGP is mainly concerned with global network reachability and with routes to other autonomous systems. When such routes are redistributed to routers in the AS via BGP, they contain IP addresses of a boundary routers (in route attribute NEXT_HOP). BGP depends on existing IGP routing table with AS-internal routes to determine immediate next hops for routes and to know their internal distances to boundary routers for the purpose of BGP route selection. In BIRD, there is usually one routing table used for both IGP routes and BGP routes.

Configuration

Each instance of the BGP corresponds to one neighboring router. This allows to set routing policy and all the other parameters differently for each neighbor using the following configuration parameters:

local [ip] as number

Define which AS we are part of. (Note that contrary to other IP routers, BIRD is able to act as a router located in multiple AS'es simultaneously, but in such cases you need to tweak the BGP paths manually in the filters to get consistent behavior.) Optional ip argument specifies a source address, equivalent to the source address option (see below). This parameter is mandatory.

neighbor ip [port number] as number

Define neighboring router this instance will be talking to and what AS it's located in. In case the neighbor is in the same AS as we are, we automatically switch to iBGP. This parameter is mandatory.

direct

Specify that the neighbor is directly connected. The IP address of the neighbor must be from a directly reachable IP range (i.e. associated with one of your router's interfaces), otherwise the BGP session wouldn't start but it would wait for such interface to appear. The alternative is the multihop option. Default: enabled for eBGP.

multihop [number]

Configure multihop BGP session to a neighbor that isn't directly connected. Accurately, this option should be used if the configured neighbor IP address does not match with any local network subnets. Such IP address have to be reachable through system routing table. The alternative is the direct option. For multihop BGP it is recommended to explicitly configure the source address to have it stable. Optional number argument can be used to specify the number of hops (used for TTL). Note that the number of networks (edges) in a path is counted; i.e., if two BGP speakers are separated by one router, the number of hops is 2. Default: enabled for iBGP.

source address ip

Define local address we should use for next hop calculation and as a source address for the BGP session. Default: the address of the local end of the interface our neighbor is connected to.

next hop self

Avoid calculation of the Next Hop attribute and always advertise our own source address as a next hop. This needs to be used only occasionally to circumvent misconfigurations of other routers. Default: disabled.

next hop keep

Forward the received Next Hop attribute even in situations where the local address should be used instead, like when the route is sent to an interface with a different subnet. Default: disabled.

missing lladdr self|drop|ignore

Next Hop attribute in BGP-IPv6 sometimes contains just the global IPv6 address, but sometimes it has to contain both global and link-local IPv6 addresses. This option specifies what to do if BIRD have to send both addresses but does not know link-local address. This situation might happen when routes from other protocols are exported to BGP, or when improper updates are received from BGP peers. self means that BIRD advertises its own local address instead. drop means that BIRD skips that prefixes and logs error. ignore means that BIRD ignores the problem and sends just the global address (and therefore forms improper BGP update). Default: self, unless BIRD is configured as a route server (option rs client), in that case default is ignore, because route servers usually do not forward packets themselves.

gateway direct|recursive

For received routes, their gw (immediate next hop) attribute is computed from received bgp_next_hop attribute. This option specifies how it is computed. Direct mode means that the IP address from bgp_next_hop is used if it is directly reachable, otherwise the neighbor IP address is used. Recursive mode means that the gateway is computed by an IGP routing table lookup for the IP address from bgp_next_hop. Recursive mode is the behavior specified by the BGP standard. Direct mode is simpler, does not require any routes in a routing table, and was used in older versions of BIRD, but does not handle well nontrivial iBGP setups and multihop. Recursive mode is incompatible with sorted tables. Default: direct for direct sessions, recursive for multihop sessions.

igp table name

Specifies a table that is used as an IGP routing table. Default: the same as the table BGP is connected to.

bfd switch

BGP could use BFD protocol as an advisory mechanism for neighbor liveness and failure detection. If enabled, BIRD setups a BFD session for the BGP neighbor and tracks its liveness by it. This has an advantage of an order of magnitude lower detection times in case of failure. Note that BFD protocol also has to be configured, see BFD section for details. Default: disabled.

ttl security switch

Use GTSM (RFC 5082 - the generalized TTL security mechanism). GTSM protects against spoofed packets by ignoring received packets with a smaller than expected TTL. To work properly, GTSM have to be enabled on both sides of a BGP session. If both ttl security and multihop options are enabled, multihop option should specify proper hop value to compute expected TTL. Kernel support required: Linux: 2.6.34+ (IPv4), 2.6.35+ (IPv6), BSD: since long ago, IPv4 only. Note that full (ICMP protection, for example) RFC 5082 support is provided by Linux only. Default: disabled.

password string

Use this password for MD5 authentication of BGP sessions. Default: no authentication. Password has to be set by external utility (e.g. setkey(8)) on BSD systems.

passive switch

Standard BGP behavior is both initiating outgoing connections and accepting incoming connections. In passive mode, outgoing connections are not initiated. Default: off.

rr client

Be a route reflector and treat the neighbor as a route reflection client. Default: disabled.

rr cluster id IPv4 address

Route reflectors use cluster id to avoid route reflection loops. When there is one route reflector in a cluster it usually uses its router id as a cluster id, but when there are more route reflectors in a cluster, these need to be configured (using this option) to use a common cluster id. Clients in a cluster need not know their cluster id and this option is not allowed for them. Default: the same as router id.

rs client

Be a route server and treat the neighbor as a route server client. A route server is used as a replacement for full mesh EBGP routing in Internet exchange points in a similar way to route reflectors used in IBGP routing. BIRD does not implement obsoleted RFC 1863, but uses ad-hoc implementation, which behaves like plain EBGP but reduces modifications to advertised route attributes to be transparent (for example does not prepend its AS number to AS PATH attribute and keeps MED attribute). Default: disabled.

secondary switch

Usually, if an export filter rejects a selected route, no other route is propagated for that network. This option allows to try the next route in order until one that is accepted is found or all routes for that network are rejected. This can be used for route servers that need to propagate different tables to each client but do not want to have these tables explicitly (to conserve memory). This option requires that the connected routing table is sorted. Default: off.

add paths switch|rx|tx

Standard BGP can propagate only one path (route) per destination network (usually the selected one). This option controls the add-path protocol extension, which allows to advertise any number of paths to a destination. Note that to be active, add-path has to be enabled on both sides of the BGP session, but it could be enabled separately for RX and TX direction. When active, all available routes accepted by the export filter are advertised to the neighbor. Default: off.

allow local as [number]

BGP prevents routing loops by rejecting received routes with the local AS number in the AS path. This option allows to loose or disable the check. Optional number argument can be used to specify the maximum number of local ASNs in the AS path that is allowed for received routes. When the option is used without the argument, the check is completely disabled and you should ensure loop-free behavior by some other means. Default: 0 (no local AS number allowed).

enable route refresh switch

When BGP speaker changes its import filter, it has to re-examine all routes received from its neighbor against the new filter. As these routes might not be available, there is a BGP protocol extension Route Refresh (specified in RFC 2918) that allows BGP speaker to request re-advertisement of all routes from its neighbor. This option specifies whether BIRD advertises this capability and accepts such requests. Even when disabled, BIRD can send route refresh requests. Default: on.

graceful restart switch|aware

When a BGP speaker restarts or crashes, neighbors will discard all received paths from the speaker, which disrupts packet forwarding even when the forwarding plane of the speaker remains intact. RFC 4724 specifies an optional graceful restart mechanism to alleviate this issue. This option controls the mechanism. It has three states: Disabled, when no support is provided. Aware, when the graceful restart support is announced and the support for restarting neighbors is provided, but no local graceful restart is allowed (i.e. receiving-only role). Enabled, when the full graceful restart support is provided (i.e. both restarting and receiving role). Note that proper support for local graceful restart requires also configuration of other protocols. Default: aware.

graceful restart time number

The restart time is announced in the BGP graceful restart capability and specifies how long the neighbor would wait for the BGP session to re-establish after a restart before deleting stale routes. Default: 120 seconds.

interpret communities switch

RFC 1997 demands that BGP speaker should process well-known communities like no-export (65535, 65281) or no-advertise (65535, 65282). For example, received route carrying a no-adverise community should not be advertised to any of its neighbors. If this option is enabled (which is by default), BIRD has such behavior automatically (it is evaluated when a route is exported to the BGP protocol just before the export filter). Otherwise, this integrated processing of well-known communities is disabled. In that case, similar behavior can be implemented in the export filter. Default: on.

enable as4 switch

BGP protocol was designed to use 2B AS numbers and was extended later to allow 4B AS number. BIRD supports 4B AS extension, but by disabling this option it can be persuaded not to advertise it and to maintain old-style sessions with its neighbors. This might be useful for circumventing bugs in neighbor's implementation of 4B AS extension. Even when disabled (off), BIRD behaves internally as AS4-aware BGP router. Default: on.

capabilities switch

Use capability advertisement to advertise optional capabilities. This is standard behavior for newer BGP implementations, but there might be some older BGP implementations that reject such connection attempts. When disabled (off), features that request it (4B AS support) are also disabled. Default: on, with automatic fallback to off when received capability-related error.

advertise ipv4 switch

Advertise IPv4 multiprotocol capability. This is not a correct behavior according to the strict interpretation of RFC 4760, but it is widespread and required by some BGP implementations (Cisco and Quagga). This option is relevant to IPv4 mode with enabled capability advertisement only. Default: on.

route limit number

The maximal number of routes that may be imported from the protocol. If the route limit is exceeded, the connection is closed with an error. Limit is currently implemented as import limit number action restart. This option is obsolete and it is replaced by import limit option. Default: no limit.

disable after error switch

When an error is encountered (either locally or by the other side), disable the instance automatically and wait for an administrator to fix the problem manually. Default: off.

hold time number

Time in seconds to wait for a Keepalive message from the other side before considering the connection stale. Default: depends on agreement with the neighboring router, we prefer 240 seconds if the other side is willing to accept it.

startup hold time number

Value of the hold timer used before the routers have a chance to exchange open messages and agree on the real value. Default: 240 seconds.

keepalive time number

Delay in seconds between sending of two consecutive Keepalive messages. Default: One third of the hold time.

connect retry time number

Time in seconds to wait before retrying a failed attempt to connect. Default: 120 seconds.

start delay time number

Delay in seconds between protocol startup and the first attempt to connect. Default: 5 seconds.

error wait time number,number

Minimum and maximum delay in seconds between a protocol failure (either local or reported by the peer) and automatic restart. Doesn't apply when disable after error is configured. If consecutive errors happen, the delay is increased exponentially until it reaches the maximum. Default: 60, 300.

error forget time number

Maximum time in seconds between two protocol failures to treat them as a error sequence which makes error wait time increase exponentially. Default: 300 seconds.

path metric switch

Enable comparison of path lengths when deciding which BGP route is the best one. Default: on.

med metric switch

Enable comparison of MED attributes (during best route selection) even between routes received from different ASes. This may be useful if all MED attributes contain some consistent metric, perhaps enforced in import filters of AS boundary routers. If this option is disabled, MED attributes are compared only if routes are received from the same AS (which is the standard behavior). Default: off.

deterministic med switch

BGP route selection algorithm is often viewed as a comparison between individual routes (e.g. if a new route appears and is better than the current best one, it is chosen as the new best one). But the proper route selection, as specified by RFC 4271, cannot be fully implemented in that way. The problem is mainly in handling the MED attribute. BIRD, by default, uses an simplification based on individual route comparison, which in some cases may lead to temporally dependent behavior (i.e. the selection is dependent on the order in which routes appeared). This option enables a different (and slower) algorithm implementing proper RFC 4271 route selection, which is deterministic. Alternative way how to get deterministic behavior is to use med metric option. This option is incompatible with sorted tables. Default: off.

igp metric switch

Enable comparison of internal distances to boundary routers during best route selection. Default: on.

prefer older switch

Standard route selection algorithm breaks ties by comparing router IDs. This changes the behavior to prefer older routes (when both are external and from different peer). For details, see RFC 5004. Default: off.

default bgp_med number

Value of the Multiple Exit Discriminator to be used during route selection when the MED attribute is missing. Default: 0.

default bgp_local_pref number

A default value for the Local Preference attribute. It is used when a new Local Preference attribute is attached to a route by the BGP protocol itself (for example, if a route is received through eBGP and therefore does not have such attribute). Default: 100 (0 in pre-1.2.0 versions of BIRD).

Attributes

BGP defines several route attributes. Some of them (those marked with `I' in the table below) are available on internal BGP connections only, some of them (marked with `O') are optional.

bgppath bgp_path

Sequence of AS numbers describing the AS path the packet will travel through when forwarded according to the particular route. In case of internal BGP it doesn't contain the number of the local AS.

int bgp_local_pref [I]

Local preference value used for selection among multiple BGP routes (see the selection rules above). It's used as an additional metric which is propagated through the whole local AS.

int bgp_med [O]

The Multiple Exit Discriminator of the route is an optional attribute which is used on external (inter-AS) links to convey to an adjacent AS the optimal entry point into the local AS. The received attribute is also propagated over internal BGP links. The attribute value is zeroed when a route is exported to an external BGP instance to ensure that the attribute received from a neighboring AS is not propagated to other neighboring ASes. A new value might be set in the export filter of an external BGP instance. See RFC 4451 ftp://ftp.rfc-editor.org/in-notes/rfc4451.txt for further discussion of BGP MED attribute.

enum bgp_origin

Origin of the route: either ORIGIN_IGP if the route has originated in an interior routing protocol or ORIGIN_EGP if it's been imported from the EGP protocol (nowadays it seems to be obsolete) or ORIGIN_INCOMPLETE if the origin is unknown.

ip bgp_next_hop

Next hop to be used for forwarding of packets to this destination. On internal BGP connections, it's an address of the originating router if it's inside the local AS or a boundary router the packet will leave the AS through if it's an exterior route, so each BGP speaker within the AS has a chance to use the shortest interior path possible to this point.

void bgp_atomic_aggr [O]

This is an optional attribute which carries no value, but the sole presence of which indicates that the route has been aggregated from multiple routes by some router on the path from the originator.

clist bgp_community [O]

List of community values associated with the route. Each such value is a pair (represented as a pair data type inside the filters) of 16-bit integers, the first of them containing the number of the AS which defines the community and the second one being a per-AS identifier. There are lots of uses of the community mechanism, but generally they are used to carry policy information like "don't export to USA peers". As each AS can define its own routing policy, it also has a complete freedom about which community attributes it defines and what will their semantics be.

eclist bgp_ext_community [O]

List of extended community values associated with the route. Extended communities have similar usage as plain communities, but they have an extended range (to allow 4B ASNs) and a nontrivial structure with a type field. Individual community values are represented using an ec data type inside the filters.

quad bgp_originator_id [I, O]

This attribute is created by the route reflector when reflecting the route and contains the router ID of the originator of the route in the local AS.

clist bgp_cluster_list [I, O]

This attribute contains a list of cluster IDs of route reflectors. Each route reflector prepends its cluster ID when reflecting the route.

Example

protocol bgp {
        local as 65000;                      # Use a private AS number
        neighbor 198.51.100.130 as 64496;    # Our neighbor ...
        multihop;                            # ... which is connected indirectly
        export filter {                      # We use non-trivial export rules
                if source = RTS_STATIC then { # Export only static routes
                        # Assign our community
                        bgp_community.add((65000,64501));
                        # Artificially increase path length
                        # by advertising local AS number twice
                        if bgp_path ~ [= 65000 =] then
                                bgp_path.prepend(65000);
                        accept;
                }
                reject;
        };
        import all;
        source address 198.51.100.14;   # Use a non-standard source address
}

6.3 Device

The Device protocol is not a real routing protocol. It doesn't generate any routes and it only serves as a module for getting information about network interfaces from the kernel.

Except for very unusual circumstances, you probably should include this protocol in the configuration since almost all other protocols require network interfaces to be defined for them to work with.

Configuration

scan time number: Time in seconds between two scans of the network interface list. On systems where we are notified about interface status changes asynchronously (such as newer versions of Linux), we need to scan the list only in order to avoid confusion by lost notific