Migration from 3.4 to 4.x

This documents is a WIP.

Configuration

Configuration will need changing with 4.0. The largest changes are:

• the way templating works.
• the way the processes are configured

A new inherit keyword is now used to associate block of configuration located in the template section of the configuration.

The processes now requires two parts:

• configuration of the program to run
• association of the program with particular neighbour with a definition of which BGP message and event to relay

Route announcement should not be done using the static section (but it will still work) but announce.

  announce {
    ipv4 {
      unicast 10.0.4.0/24 next-hop 10.0.255.254 local-preference 200;
      ...
    }
  }

The syntax of the route after the safi (here unicast) is the same that for the route command in 3.4. The same will (as of 4.0.1 - this is not yet done) also be the case for the API.

Examples are available in the etc/exabgp folder of the repository to show you how this should be done.

API

The API now ack message sent with a 'done' or 'error' string back. program written for ExaBGP 3.4 will not expect to have to handle it.

If enough message are sent without being consumed by the api application, the PIPE can become blocking, resulting in ExaBGP stopping to do anything.

The solution is to make sure the environment value exabgp.api.ack is set to false, either using then environment like env exabgp.api.ack=false exabgp configuration or adding it the .env environment file.

This setting does not affect the pipes created for the CLI, so if you use them (and warning you should not), then this option will have no effect and your code will have to ack messages.

If an application written for ExaBGP 3.4 or earlier does not consume the acknowledgement messages sent in response to API command and if ExaBGP is started without the exabgp.api.ack option, at some point this will cause ExaBGP to lock.

Memory usage

By default, ExaBGP 4.0 enable its adj-rib-in. Therefore memory usage for installation receiving route can dramatically increase (as noticed in issue #714). Users can disable the usage of the rib using adj-rib-in false; under the relevant neighbour.