Controlling ExaBGP : possible options for process

Overview

The following options are valid under the process subsection :

• run program-name;
• encoder valid-encoder ( PLEASE - do NOT rely on the default encoder)
• neighbor-changes
• receive-routes
• receive-packets
• send-packets
• experiemental : receive-operational

Every option is disabled unless explicitly enabled.

To allow the api/helper programs to close gracefully, shutdown messages are always sent when the process is going to be killed (ie, on exabgp shutdown)

run

The only mandatory option for the process section is the "run" option which indicate which program to execute.

process {
	run ./my-program;
}

The program can be quoted or unquoted, quotes are required if your path contains spaces

process {
	run "./my folder/my-program";
}

encoder

The encoder indicate how you want the data to be serialised before being sent to ExaBGP, the default encoder is 'text'.

process {
	encoder text;
}

process {
	encoder json;
}

The data format depend on the encoder used and will be defined in the wiki page related to that encoder.

neighbor-changes

This option provides the program with neighbor events ( TCP connection established/closed, successful OPEN negotiation - ie: OPENCONFIRM ).

process {
	run ./my-program;
	neighbor-changes;
}

receive-routes

The will send the UPDATE received by ExaBGP as decoded by the specified encoder. In most case, the string can be used to resent the same update back to the peer.

There is a one case where it is not possible : FlowSpec routes with Next-Hop rewrite where the syntax can differ (NOTE : check if the printed syntax is accepted by the parser as input or not - doubt here).

process {
	run ./my-program;
	receive-routes;
}

receive-packets

This indicate to ExaBGP that we want to be informed of received of the raw data received by ExaBGP from its peers, it is useful if you do not want to use the BGP parser included by ExaBGP or need the unparsed data (like for writing an MRT dumper).

Please keep in mind that the encoding is specific to the negotiated capabilities with the peer and therefore in most case it is preferable to use the decoded representation.

send-packets

This will send to your application the packets which were sent by ExaBGP to its peers. It could be useful to record and later replay the packets which were sent to a router part of a test suite for example.

receive-operational

As ExaBGP is the only implementation of operational, feel free to play with it to see what it does :-)

Multiple options

The options can be cumulated (it is possible to enable more than one type of notification).

process {
	run ./my-program;
	neighbor-changes;
	receive-routes;
}

Deprecation

The commands "parse-routes" and "peer-updates" are now deprecated and are legacy alias for neighbor-changes and receive-routes (due to a initial bad implementation).

Summary, Event to message relation

The following message are sent for each option :

neighbor-changes

tcp connection established
tcp connection closed
BGP negotiation successful (OPENCONFIRM state)

receive-routes

textual or JSON representation of routes received from peers
End of Rib received from peers (currently but will change)

send-packets

every packet sent to the peer

receive-packets

every packet received from the peer

always

closing the program (JSON only)