Rayhaan JaufeerallyandClaude Opus 5.5
65f136048e
A peer that restarts keeps its routes with us, and we keep ours with our peers while we restart, so that a restart withdraws nothing across the network and the machine goes on forwarding. On by default for every peer; `graceful_restart` sets the restart time we give, caps how long a peer's routes are kept, or turns it off. When a peer restarts: its routes are marked stale in the routing table, and chosen as before, for at most its restart time. When it is back, what it sends again is fresh, and the stale routes of a family go at its End-of-RIB marker, or after the cap; at once for a family whose forwarding it did not keep. Only a connection that failed counts as a restart, and, with RFC 8538 agreed, an expired hold timer or a NOTIFICATION other than a Hard Reset. The stale mark is a bit of the route's word that selection never looks at. When we restart: SIGUSR1 leaves the kernel's routes where they are, closes the sessions without a word where graceful restart is agreed, and exits with status 75, on which the systemd unit starts us again. The next start finds the routes in the kernel, says so in its OPENs (R, and F where forwarding was kept), and has them go once every peer has sent its End-of-RIB. Our own End-of-RIB markers for learned routes wait for that too. SIGTERM still stops for good, now with a Hard Reset where RFC 8538 is agreed, as are errors of ours. The status page and API show what was agreed with each peer, the routes kept while a peer restarts, and which routes are stale. Tested against FRR and BIRD in a new phase of the interoperability lab, and with routes kept in a real kernel over a restart. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
3.4 KiB
+++ title = "Configuration Examples" description = "Provides complete configurations for a single-homed edge network, a network with an Internet exchange connection, and a transit network." weight = 8 +++
This topic provides complete configurations for three common deployments.
Each configuration is stored in the docs/examples/ directory of the
repository, and continuous integration validates each one with
bgp --check.
The examples use documentation addresses and AS numbers. Replace them with your own.
Note
Documentation prefixes such as
192.0.2.0/24and2001:db8::/32are bogon prefixes. In a production network, Ferrix rejects routes for them from neighbors by default.
Example: Edge Network with One Transit Provider
This configuration is for a network with one transit provider and one BGP session for each address family. It enables route origin validation, ASPA verification, and kernel route installation.
{{ example(name="edge") }}
Before you deploy this configuration, adjust the following statements:
max_prefixes: set a value above the number of routes that the provider advertises, with margin for growth.rpki: specify the address of your RPKI cache. See Running a Validator.- If the provider advertises only a default route, configure
accept_default_route: truein itsimportstatement, and reducemax_prefixesaccordingly.
Example: Network with an Internet Exchange Connection
This configuration is for a network with one transit provider, a session with an Internet exchange route server, and a bilateral session with one peer at the exchange. Routes learned at the exchange have a higher local preference than transit routes. Every accepted route is marked with a large community that records where it was learned.
{{ example(name="exchange") }}
The configuration has the following characteristics:
- The route server session includes
accept_any_first_as, because the route server does not prepend its AS number. The roleROUTE_SERVERpermits next hops other than the route server's address. - The bilateral peer can advertise only its registered prefixes and origin AS. See Generating Lists with bgpq4.
- Each import policy removes the local AS's informational communities before it adds its own.
Example: Transit Network
This configuration is for a network with two transit providers and one customer. The customer's routes are advertised to all neighbors. Routes from the providers are advertised to the customer only. The customer can restrict the advertisement of its routes with control communities.
{{ example(name="transit") }}
The configuration has the following characteristics:
- Every neighbor has a role. The roles prevent the advertisement of one provider's routes to the other provider. See Roles and Route Advertisement.
- The customer's routes have a local preference of 200, so that they are preferred over routes for the same prefixes from the providers.
- The
exportstatement oftransit-breplaces the top-levelexportstatement for that neighbor, and therefore repeatslearned_routes: true. - The customer's
remove_communitiesstatement removes only the64500:2:*communities, and retains the customer's control communities.